Action Item recommendation


Subject: Action Item recommendation
From: Jonathan Sanders (jons@cadence.com)
Date: Mon Jan 28 2002 - 09:41:44 PST


Verilog-AMS committee,

Committee, here is the recommendation on portnames of digital primitives:

AI:  Jon to check with the cadence elab guys to see why it is necessary and whether the problem could be got around with having port names for digital primitives.

ANS:  Looking at #2 in section 8.8.5 of the LRM (below) for split we find that the port name is required for this case.   Without a portname the user is unable to pass parameters to this specific connect module independently (while mentioned in 8.8.5 no example given in LRM, see my 1st presentation, slide 27).  Without a unique name the user is unable to do the following:

module set_parameters();

  top.I1.I2.I3.mixednet__i0__in1.vcc = 3.3 ;  // set supply to 3.3 in this specific CM
  top.I1.I2.I3.mixednet__i0__in2.vcc = 2.9 ;  // set supply to 2.9 in this specific CM
  top.I1.I2.I3.mixednet__i0__clk.dly = 1n ;  // set dly to 1nS in this specific CM

endmodule

This is an extremely valuable feature in debugging design which probably would be lost for digital primitives if we support them and do not add back a naming mechanism like in early drafts of the LRM.  For example two digital primitive and has the following descriptions:

and instname(output, input1 <,  input2, ...., inputN> ); //  1st term is out, others inputs
buf  instname(input, output1 <, output2, ...., outputN>);  // 1st term is in, others outputs

So what is the unique name of the following since these digital primitives ports have no names?

and #2 a1(out, in, out);
buf  #1 b1(in, out1, out2, out3);

So now the answer to the original question, do digital primitives need portnames?

The answer is NO but a unique name is needed for naming the connect module instance name in split mode.  Without this the user is prevented from overriding the parameters of a connect module on an instance by instance basis. 

Thus the recommendation is that pseudo portnames (essentially an alias) be provided to the ports of digital primitives only for the following two purposes:

1) The instance name of auto inserted connect modules
2) To override the value of a connect module parameter via a defparam statement.

The above means we would not be supporting instantiation of digital primitives by portname.

Section 7.6.1 would be added to the auto inserted naming section in chapter 8.   It would be modified as follows:
8.8.5.1  Port Names for Verilog Built-in Primitives  (NEW TO ADD TO LRM)
In the cases of instances of modules and instances of UDPs port names are well defined.  In these cases the port name is the name of the signal at the lower connection of the port.  In the case of built in digital primitives, however, IEEE 1364 does not define port names. In order to support the unique naming of auto inserted connect modules and the ability to override the parameters of those connect modules, built-in digital primitives ports will be provided predictable names.   These names are only for the purpose of naming the connect modules and do not define actual  port names.  These port names may not be used to instantiate or to do access of these primitives.  

The following naming conventions will be used when generating connect modules instance names that are connected to built-in digital primitive.

1. For N-input gates (and, nand, nor, or, xnor, xor) the output will be named out, and the inputs reading from left to right will be in1, in2, in3, etc.

2. For N-output gates (buf, not) The input will be named in, and the outputs reading from left to right will be named out1, out2, out3, etc.

3. For 3 port MOS switches (nmos, pmos, rnmos, rpmos) the ports reading from left to right will be named source, drain, gate.

4. For 4 port MOS switches (cmos, rcmos) the ports reading from left to right will be named source, drain, ngate, pgate.

5. For bidirectional pass switches (tran, tranif1, tranif0, rtran, rtranif1, rtranif) the ports reading from left to right will be named source, drain, gate.

6. For single port primitives (pullup, pulldown) the port will be named out.



Jon

From an early draft of the 2.0 LRM

7.6.1 Port Names for Verilog Built-in Primitives
In the cases of instances of modules and instances of UDPs port names are well defined.  In these cases the port name is the name of the signal at the lower connection of the port. in the case of built in primitives, however, Verilog-D does not define port names. It is, thus necessary to define port names for the ports of built in primitives in Verilog-MS.

The following conventions will be used for naming Verilog Ports.

1. For N-input gates (and, nand, nor, or, xnor, xor) the output will be named out, and the inputs reading from left to right will be in1, in2, in3, etc.
2. For N-output gates (buf, not) The input will be named in, and the outputs reading from left to right will be named out1, out2, out3, etc.
3. For 3 port MOS switches (nmos, pmos, rnmos, rpmos) the ports reading from left to right will be named source, drain, gate.
4. For 4 port MOS switches (cmos, rcmos) the ports reading from left to right will benamed source, drain, ngate, pgate.
5. For bidirectional pass switches (tran, tranif1, tranif0, rtran, rtranif1, rtranif) the ports reading from left to right will be named source, drain, gate.
6. For single port primitives (pullup, pulldown) the port will be named out.


From the 2.0 LRM

8.8.5 Instance names for auto-inserted instances
Parameters of auto-inserted connect instances can be set on an instance-by-instance basis with the use of the
defparam statement. This produces predictable instance names for the auto-inserted modules. The following naming scheme is employed to unambiguously distinguish the connector modules for the case of auto-inserted instances.

1. merged
In the merged case, one or more ports have a given discipline at their bottom connection, call it
BottomDiscipline, and a common signal, call it SigName, of another discipline at their top connection. A single connect module, call it ModuleName, is placed between the top signal and the bottom signals. In this case, the instance name of the connect module is derived from the signal name, module name, and the bottom discipline:

SigName__ModuleName__BottomDiscipline

2. split
In the split case, one or more ports have a given discipline at their bottom connection and a common signal of another discipline, call it
TopDiscipline,at their top connection. One module instance is instantiated for each such port. In this case, the instance name of the connect module is

SigName__InstName__PortName

where InstName and PortName are the local instance name of the port and its instance respectively.

Note: The
__ between the elements of these generated instance names is a double underscore.


***********************************************************
Jonathan L. Sanders                  
Product Engineering Director
Custom IC Solutions
Cadence Design Systems, Inc.     
555 River Oaks Pkwy
San Jose, CA. 95134
 INTERNET:jons@cadence.com    Tel: (408) 428-5654      Fax : (408) 944-7265
***********************************************************



This archive was generated by hypermail 2b28 : Mon Jan 28 2002 - 09:42:46 PST