[sv-bc] RE: Mantis 210 Use Cases

To expand on this a little, consider the following definitions of the interfaces:

`ifdef BUS_GEN2
`define USE_SIDEBAND
`endif

interface bus_if;
    logic signal1;
`ifdef BUS_GEN2
    logic signal2;
`endif
    ...
endinterface

`ifdef BUS_GEN2
interface sideband_if;
    logic signal1;
endinterface
    ...
`endif

Here I have two different generations of the bus specification: Gen1 and Gen2. In the 2nd generation, another signal is added to the main bus, and the sideband is introduced.

Suppose I want to create an SoC that wants to control two external instances of such a bus, one for Gen1 and one for Gen2. (Assume I've added appropriate I/O to module 'top' to create an interface controller.) I now need to instantiate both a Gen1 controller and a Gen2 controller. I want to replace all of my conditional `ifdef behavior with parametric behavior. With current SystemVerilog, I need to run an external preprocessor to generate modules top_gen1, top_gen2 (and two versions of all of the submodules) with different values for `define BUS_GEN2. Each user can do this, but it won't lead to very standard source code, especially as the configurability gets more complicated. (You can standardize the flow using IP-XACT generator chains though.)

~ Dave

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gates, David
Sent: Monday, February 14, 2011 8:59 AM
To: sv-bc@eda.org
Subject: [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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.