Issue 19: Representation Stops

- + Issue 19: Representation Stops

[Kevin Cameron, 02 Jan 2001]

Rationale

In order to avoid having to translate netlists into slightly different forms for different purposes, or doing nasty things with `define/`ifdef, it would be useful to have a "representation stop" in the language (first mentioned by Kim Hailey [Metasoftware] ~1996).

A "representation stop" mechanism indicates what a module call represents to different simulator kernels or secondary tools. In particular it allows netlists translated from Spice to be used with different simulator models for transistors or used in a digital simulator with switch level models.

An official "representation stop" mechanism also allows different versions to be simultaneously visible (unlike `ifdef) and declares them to be different views of the same object which makes it is easier for a smart tool to check that they are consistent.

Proposal A.

Augment "external module" and "macromodule" definitions with a "simulator class", a suggested syntax is:

     <repstop> ::= (extern module|macromodule)
                           [<simulator class::>]<module name> [(<ports>)];
                        ....


See also the "external module" proposal.

Usage

Declaring an external "Spice" transistor:

     extern module spice::nmos(drain,gate,source,back);
         parameter model = "NMOS3"; 
         parameter l     = length ; // translate parameter 
         parameter w     = width ;  // translate parameter 

         // this component is primitive of the simulator

     endmodule;

The simulator would use the parameters "model","l" and "w" as stated and calculated from the actual instance.

Alternative "digital" transistor version of the above for pure digital simulation:

     macromodule digital::nmos(drain,gate,source,back);
           rnmos(drain, source, gate); // use digital primitive
     endmodule;

Simulators and tools would ignore class definitions that they do not understand, and would default to a particular behavior as directed by the user (or Verilog 2000 configuration directives, considering the "simulator class" as the view), if they can handle more than one.

Proposal B.

Seperate represention-stop declaration.
Syntax:

     <repstop> ::= repstop <module name> [(<ports>)];
                                     {<parm>}
                                     {<alias>{[,<alias>]}} endrepstop
     <alias>   ::= alias [<tool>::]<alt module name> [(<alt ports>)];
                                     {<parm>} endalias

See message #104 for an example.

Usage

The "rep-stops" for a given simulator would be bundled with it as a header file in the same directory as other standard include files, e.g.:

     #include <repstop.h>

Example contents:


     repstop sp_nmos(d,g,s,b); 

        alias spectre::mos(d,g,s,b);
              parameter device = "NMOS";
              parameter model  = "BSIM3.3";
        endalias; 

     endrepstop

A translated Spice netlist may include a default rep-stop:


     repstop sp_nmos(d,g,s,b); 

	parameter length;

        alias spice::mos(d,g,s,b); // if we are handling spice 
              parameter model = "NMOS3"; 
              parameter l     = length ; // translate parameter 
        endalias; 

     endrepstop

The tool 'spectre' would use the spectre definition, others may take the 'spice' definition. As with proposal A, simulators and tools would ignore class definitions that they do not understand, and would default to a particular behavior as directed by the user or configuration.

"Aliases" without a tool specified are potential substitute (macro) modules that tools should search for in the order presented. Any module reference that is not a known primitive or described in a repstop would be illegal.