[sv-bc] RE: Mantis 210 Use Cases

For my action item for the 1/31 meeting, I tried to figure out how to use interfaces with internal generate statements, but ran into the problem that we are internally using conditional interface ports.

Here is a cooked-up example that uses `ifdef instead of parameters.

module bus_master(
    bus_if.master B
`ifdef USE_SIDEBAND
    , sideband_if.master SB
`endif
)
endmodule

module bus_slave(
    bus_if.slave B
`ifdef USE_SIDEBAND
    , sideband_if.slave SB
`endif
);
endmodule

`ifdef USE_SIDEBAND
module bus_sideband_helper(
    sideband_if.slave SBI,
    sideband_if.master SBO
);
endmodule
`endif

module top();
    bus_if B1();
`ifdef USE_SIDEBAND
    sideband_if SB1(), SB2();
`endif
    bus_master bm(
        .B(B1)
`ifdef USE_SIDEBAND
        , .SB(SB1)
`endif
    );
    bus_slave bs(
        .B(B1)
`ifdef USE_SIDEBAND
        , .SB(SB2)
`endif
    );
`ifdef USE_SIDEBAND
    bus_sideband_helper bsh( .SBI(SB1), .SBO(SB2) );
`endif
endmodule

I don't see how using generate statements inside an interface can describe this situation parametrically.

~ Dave

From: Gates, David
Sent: Friday, January 28, 2011 11:01 AM
To: 'sv-bc@eda.org'
Subject: Mantis 210 Use Cases

I polled internally at AMD and uncovered the following 5 use cases where language support for configurable module port lists would be useful:

1. Modules that need different views (RTL, DFT) at different points in the design cycle. Additional ports are added as the view is refined. A typical case might be a flip-flop with or without scan ports.

2. Modules that appear multiple times in the design with different ports. This can happen when different generations of a common module are used in different parts of an SoC.

3. Modules that appear in multiple SoCs in the same family, with differences controlled by per-design features. Here the desire is to maintain a single codebase for all variants.

4. Modules that might have the same types of ports, but where the port names are changed to indicate the actual client. This customizes the design to make debugging / tracing of signals easier.

5. Modules that have lists of ports with indexed names, because a parameterized port array cannot be or is not used for other reasons.

I think generated ports/connections would be usable in the first 3 cases. The second case really isn't possible to cover using a global `ifdef, but I believe the SV configuration mechanism could be used to alias two different modules to the same name in different parts of a design. For the 4th & 5th cases, you'd need a more complex interaction between the SV lexer/parser, such that a parsed parameter can modify a lexical name. I don't think generate would solve that.

Largely through the use of external preprocessors (aka language extensions), all 5 of these use cases appear within AMD designs, some of them extensively.

One other note: although the description doesn't state this, a followup comment makes it clear you'll need generate for module instantiations as well to take advantage of this language change.

~ Dave

// David A. Gates, Ph.D. 408.749.4497
// Fellow, Design Automation
// Advanced Micro Devices www.amd.com<http://www.amd.com/>
// The Doctor is IN. Primum non nocere.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.