| |
Module Design Manifesto
last modified 5/23/00
This page describes the limitations we place on Cadence schematics and layout for
modules in order to ease the development of a "push-button" design flow. There
have been many changes recently, so for convenience, here's a link to the old module design manifesto.
Topics:
Naming Restrictions
Many CAD tools place restrictions on names, making it rather difficult to translate
design data between tools. In order to make sure that your designs can be used by as many
CAD tools as possible, all libraries, cells, ports, pins, nets, instances, modules, etc.
should adhere to the following naming restrictions:
- Names must be 1 to 255 characters in length (preferably 5 or fewer characters).
- Names must begin with a letter of the alphabet.
- Names can contain letters, digits, and the underscore character "_". No other
characters should be used.
- Names must be treated as case-sensitive.
- Names must be unique within their scope, even if a tool treats them as case-insensitive.
For example, a library should not contain two cells named "adder12" and
"Adder12".
- Single-Indexed names are allowed for pins and nets only, using the angle-brackets
"< >". For example "in<0>" and
"in<1>" are allowed, but not "in<0><1>".
Basic Module Requirements
Our modules should adhere to the following basic requirements:
- Include symbol, and schematic views.
- Have port names names which are consistent between all three views.
- Be targeted for one or more of the following three possible "back end
styles":
- Hard - the generator produces a layout view
- Soft - the generated schematic view contains cells which adhere
to the back-end
standards for standard cell place & route.
- Firm - the generator produces an autoLayout view with placement
information. As with the soft-style, the schematic and autoLayout
views must contain only cells which adhere to the back-end standards.
- For the hard & firm back-end styles, schematic and layout/autoLayout views
must have consistent hierarchies. For example, if a cell's
layout view contains an instance of the NAND2 cell's layout, then the schematic view
should contain an instance of the NAND2 cell's symbol. (This is not as obvious a
requirement as it may seem). This requirement may be relaxed for the case of routing cells
i.e. cells which contain only wires need not have corresponding schematic and
symbol views.
If modules do not meet these requirements, then they will NOT BE USED!
Schematic Limitations
Basically, we limit ourselves to the same style as the CORELIB standard cell library.
This translates to the following restrictions:
- Schematics for the lowest level of hierarchy should be called cmos_sch and
contain elements from the following list only:
| Library |
Cell |
Description |
| STlib |
ipin |
Input pin |
| STlib |
opin |
Output pin |
| STlib |
vdd |
Positive supply rail |
| STlib |
gnd |
Negative supply rail |
| devices_symbols |
nmos |
3-terminal NMOSfet |
| devices_symbols |
nmos4 |
4-terminal NMOSfet |
| devices_symbols |
pmos |
3-terminal PMOSfet |
| devices_symbols |
pmos4 |
4-terminal PMOSfet |
| devices_symbols |
dn |
N-diffusion, P-well diode |
| devices_symbols |
dp |
P-diffusion, N-well diode |
- Schematics for higher levels of hierarchy should be called schematic and contain no
elements from the preceding list, or any other elements from the devices_symbols or
STlib libraries. If you decide that you need include a basic element in a higher-level
schematic, then see me. We need to decide on a good way to handle this special case.
Layout Limitations
Allowed Layers & Devices
As with schematics, these limitations are based on the CORELIB standard cell library.
These limitations will be updated as we learn more about our router.
- Layout should not contain pcells (we may change this later)
- Layout should not contain polygons from the via layers ("contact",
"v1", "v2", etc.). Rather, symbolic vias should be created with the Create
-> Contact... command.
- Layout should use as few metal layers as possible. This conserves routing resources for
later. Use m1-3, or m1-2, if possible.
- Cells should be surrounded by a rectangle in the "prBoundary"
"drawing" layer. This rectangle must enclose all metalization, poly-silicon, and
active areas. Wells and diffusions may overlap the boundary.
- Pins should be created with the "pin" purpose.
- Pin names should be created with the "pintext" purpose.
- Layers from the following list only should be used in layout:
| Layer - Purpose |
Layer - Purpose |
Layer - Purpose |
| nwell - drawing |
pplus - drawing |
active - drawing |
| poly - drawing |
prBoundary - drawing |
|
| metal1 - drawing |
metal1 - pin |
metal1 - pintext |
| metal2 - drawing |
metal2 - pin |
metal2 - pintext |
| metal3 - drawing |
metal3 - pin |
metal3 - pintext |
| metal4 - drawing |
metal4 - pin |
metal4 - pintext |
| metal5 - drawing |
metal5 - pin |
metal5 - pintext |
| metal6 - drawing |
metal6 - pin |
metal6 - pintext |
Let me know if we need to add layers to this list. Also remember that metals 4,5,
& 6 should be strongly avoided, even though they are mentioned in this list.
Signal Pin Requirements
Signal pins have slightly different requirements, depending on whether they are flush
with the prBoundary or on the interior of the cell. All pins, however, must adhere
to the following requirements:
- The metal around a pin must contain no "jogs" within the minimum metal spacing
distance of the pin.
| Metal Layer |
Min Space (um) |
Metal Layer |
Min Space (um) |
Metal Layer |
Min Space (um) |
| metal1 |
0.4 |
metal3 |
0.4 |
metal5 |
1.0 |
| metal2 |
0.4 |
metal4 |
0.4 |
metal6 |
1.8 |
- The pin must cover the entire width of the metal trace.
- Boundary Pins (pins which are flush with the prBoundary)
A. do not have to be square
B. can be in any metal layer
C. must have length and width greater than or equal to the minimum metal width.
| Metal Layer |
Min Width (um) |
Metal Layer |
Min Width (um) |
Metal Layer |
Min Width (um) |
| metal1 |
0.4 |
metal3 |
0.4 |
metal5 |
1.0 |
| metal2 |
0.4 |
metal4 |
0.4 |
metal6 |
1.0 |
- Interior Pins (pins which are not flush with the prBoundary)
A. must be square
B. must be in the highest metal layer used by the module
C. must have length and width equal to the symbolic contact dimension for that layer
| Metal Layer |
Contact Dim. (um) |
Metal Layer |
Contact Dim. (um) |
Metal Layer |
Contact Dim. (um) |
| metal1 |
0.5 |
metal3 |
0.6 |
metal5 |
1.0 |
| metal2 |
0.6 |
metal4 |
0.6 |
metal6 |
1.0 |
Power Pin Requirements
- should be called vdd! and gnd! (NOTE: all lower case)
- must be in the highest metal layer used by the module
- must span the longer dimension of the module
- Since connections to power pins will be made by vias from higher metal layers, they must
have a width greater than or equal to the symbolic contact dimension (as with Interior
Pins, above).
Bitsliced/Datapath Module Conventions
The following are suggestions, not requirements:
- Inputs should be named with letters from the beginning of the alphabet (a,b,c...)
- Outputs should be named with letters from the end of the alphabet (z,y,x...)
- Pins should be annotated with "r" or "i" for real and imaginary
values.
- Inputs should be on the top of the module, with outputs on the bottom and control
signals on the sides.
- Bit 0 (LSB) should be the right-most I/O pins, and the highest bit (MSB) should be to
the left.
- Real and imaginary bits should be interleaved, beginning with real, from right to left
The following picture illustrates these conventions. Bear in mind that these pin
naming conventions are suggestions. These pin names must ultimately be the same as
their Simulink counterparts.
Module Generator Format
Format Specifications
- Choose a name for the module. This name should adhere to the naming restrictions as
described in this manifesto.
- The leafcells for the module should be placed in a Cadence library located in the
directory /tools/designs/SCR1/modules/dfII. The name of this
library should be [initials]Lib. For example, Ryan H. Tu's library is called rhtLib.
- The code for the entire module generator should be in one file called generate[module
name].il which should be placed in the directory /tools/designs/SCR1/modules/skill.
This file should contain a header which specifies
- the module name
- your name & the date
- descriptions of the parameters
- dependencies, including SKILL files which must be loaded, names of libraries containing
leaf-cells, and the leaf-cell names.
- The top level generator function should be called bjcGenerate[module name]
- The first parameter to the generator function should be a string which specifies the
destination library for the module.
- All remaining parameters should be keyed (using the @key directive in SKILL)
- All module generators are required to include the following parameters:
- cellname - a string containing the name of the top-level cell.
The default should be nil, indicating that the module generator should create a
unique name
- backEndStyle - a string containing the value
"Hard", "Soft", or "Firm" depending on
the desired back-end style (as described in the Basic
Module Requirements).
- logfile - a string containing the name of a file for printing log
messages. The default should be nil, indicating that log messages will be printed to
stdout. This parameter is used by the logf() function described below.
- loglevel - the relative number of log messages to print. If
loglevel is 0, only fatal error messages should be printed. Larger numbers mean that
more messages are printed. This parameter can have any default value. It
is used by the logf() function described below.
- logindent - the number of tab "\t" characters to print in
front of every log message. This parameter is also used by the logf()
function. It should have a default value of zero.
- All numerical input port dimensions must be specified by a "fixed point port
descriptor" parameter. The format of these descriptors is based on the syntax
of the Simulink Fixed Point types sfrac and ufrac. The module generators
must sign-extend or zero-fill the high- and low-order input bits as necessary to line-up
the various inputs. It is NOT necessary that every possible combination of fixed
point input port descriptors be supported by the module generators. However, it IS
necessary that all combinations are accepted and that informative error messages are
printed when an unsupported case arises. The descriptor will be a SKILL list with
the following elements:
list( IsSigned MantBits GuardBits )
- IsSigned (integer) - 1 if the port is a signed number, 0 if not
- MantBits (integer) - the bit width (mantissa bits) of the port
- GuardBits (integer) - the number of bits which represent a whole number
i.e. the number of bits to the left of the decimal point, not including the sign bit.
- All numerical output port dimensions must also be specified by a "fixed point port
descriptor" parameter. These descriptors are similar to input port descriptors
except that they also specify what to do in the case of truncation of the high- and
low-order bits in the result. The module generators must also sign-extend or
zero-fill the output as necessary when high- and low-order bits are added to the result.
Again, not every combination of input and output port descriptors needs to be
supported, but informative error messages must be printed when an unsupported case arises.
The descriptor will be a SKILL list with the following elements:
list( IsSigned MantBits GuardBits RoundTowards Saturate )
- IsSigned, MantBits, GuardBits - as for the fixed point input port
descriptor
- RoundTowards (string) - specifies what to do if low-order result bits
are truncated. Possible values are "Floor", "Nearest",
"Zero", and "Ceiling".
- Saturate (integer) - specifies what to do if high-order result bits are
truncated. This parameter will be 1 if the result is to saturate at the
maximum/minimum value, or 0 if the result is to overflow (no saturation)
- Any number of other parameters may be added to the module generator call, as needed.
- The generator function should return the name of the top-level cell as a string.
The function should return nil if the module generation was not successful.
- The generator must create layout, schematic, and symbol views.
- The top-level symbol for the module may not contain any port arrays. For example,
a port named "A<5:0>" would have to be split into the ports
"A<5>" "A<4>" ... "A<0>". It is
still acceptable for the top-level schematic and lower-level symbols/schematics to contain
pin arrays
- If the generator creates any subcells, these subcell names must be unique so that all
module generators can be run with the same target library. The general format of
these subcell names should be gen_[module name]_[parameters]
where [parameters] is a list of parameters separated by underscores, using the
same order used by the bjcGenerate[module name] function.
Skill Function Calls
We support a set of SKILL function calls to make module generation easier. These
function calls are implemented in the file "def.il" which is loaded
automatically.
Right now, only these function calls are supported:
- addCell( inCell outCell direction rotation ?xOffset xOverlap ?yOffset yOverlap
?pinInfo pinInfoList)
- Adds a leafcell layout to the destination cellview, placing it either to the right or
on top, using the prBoundary polygons to determine how cells should be stacked.
- Returns t on success, nil on failure
?pinInfo list('("gnd!") '("vdd!" "vdd2!")
list("busPin" "din" data_count "RIGHT")
list("cin<2>" "cout" 3))
list( ) - creates a list from the contents in the parentheses but evaluates the
variables and equations inside first
list("datain" "dataout" 1+4 sideVar) -> ("datain"
"dataout" 5 "TOP")
'( ) - creates a list from the contents but uses the contents literally and doesn't
evaluate variables and equations
'("datain" "dataout" 1+4 sideVar) -> ("datain"
"dataout" 1+4 sideVar)
'("gnd!") - takes all pins with the name gnd! in inCell and adds them
to outCell
'("vdd!" "vdd2!") - takes all pins with the name vdd! in inCell
and adds them to outCell with the name vdd2!
list("busPin" "din" data_count "RIGHT") - takes pins
named busPin on the right side of inCell and adds them to outCell with
the name din<data_count> (in a case like this data_count would be a number from a
for loop or something similar)
list("cin<2>" "cout" 3) - takes pins named cin<2> in inCell
and adds them to outCell with the name cout<3>
- addSch( inSymbol outSchematic pinToNetConnectionList instName)
- Adds a leafcell symbol to the destination cellview schematic, placing symbols
progressively higher on the right side of the origin. It also adds net connections
to the pins listed.
- Returns t on success, nil on failure
- outSchematic - the destination schematic, opened with dbOpenCellViewByType
- inSymbol - the symbol to add, also opened with dbOpenCellViewByType
- pinToNetConnectionList - list that specifies the what pins on the symbol added
should be connected to in the schematic and follows the format:
(("symbol_pin_name" "schematic_net_name")
(next pin/net info) ...)
- symbol_pin_name - name of the pin of the cell added
- schematic_net_name - net name that will connect the symbol's pin to the schematic
examples:
list('("bit" "bit<0>") list("word" word_name)) -
takes pin "bit" and connects a net "bit<0>" to it in the
schematic, "word" is connect to what the string variable "word_name"
represents
- instName - a string specifying the name of the symbol instance.
If this parameter is omitted or set to nil, a unique name will be chosen for the
instance
- addPins( outSchematic pinList)
- Adds pins to a schematic.
- Returns t on success, nil on failure
- outSchematic - the destination schematic, opened with dbOpenCellViewByType
- pinList - list that specifies the pins to add to the schematic and follows the
format:
(("pin_name" "direction") (next pin info) ...)
- pin_name - name of the pin to be added
- direction - direction that the pin will be (input, output, or inputOuput)
examples:
list('("bit<1:0>" "inputOutput") list(word_name
"input")) - places pin "bit<1:0>" as an "inputOutput"
and string variable "word_name" pin as input in the schematic
- createSymbol( libName cellName pinList)
- Creates a symbol for a cell.
- Returns t on success, nil on failure
- libName - the library name where the symbol is to be located
- cellName - the cell name for the symbol
- pinList - list that specifies the pins to appear in the symbol (
identical to the pinList for the addPins function described above)
examples:
bitCellData = (cellInfo bitCell_l "R0)
bitCellData~>BX (equals say... 0.5)
bitCellData~>TX (equals say... 1.5)
bitCellData~>Width (equals say... 1)
note, this function is useful to allow the amount of overlap for the ?xOverlap or
?yOverlap in addCell to be dependant on the cellview added (in other words, not hard coded
by the skill programmer)
- logopen()
- Opens the logfile (specified in the variable logfile) for writing and stores
the file descriptor in the variable logport. Also sets the logprefix
variable to a string of tab characters, depending on the logindent variable.
- logclose()
- Closes the logfile specified in the logport variable.
- logf( level format arg1 arg2 ... )
- As with printf, prints the format string and arguments to the logfile specified
by the logport variable, only if the value of loglevel is greater than
or equal to the value of level.
Example Generators
- generateTest.il - a general case which shows an example header,
function call/parameters, and use of the logging functions but doesn't produce any cell
views. You can find it in /tools/designs/SCR1/modules/skill/.
Pin Ambiguities regarding Clocking
Module pin names must be consistent between layout/schematic and Simulink
views. Unfortunately, since Simulink has abstracted away the clock, we can't
maintain complete consistency in pin names. The exceptions are detailed here.
- clk, clkb - All modules which have "state" (i.e.
registers, modules with embedded registers) in Simulink will need to have a clock input,
even though no clock input appears on the Simulink symbol. The form of these clock
inputs will be determined by the up-and-comming Clocking Methodology Page.
- enable, enableb - Positive and negative enable signals on Simulink blocks will
become gated clocks in the final layout. Because of the dangers associated
with using gated clocks, these signals will be handled by a centralized clock generator
and not in the individual modules. Thus, module designers should ignore pins named
"enable" and "enableb".
- set, setb, reset, resetb - Set and reset signals can be either synchronous or
asynchronous. In order for a module to accurately model Simulink behavior, sets and
resets must be synchronous. But asynchronous sets and resets can lead to smaller,
lower-power logic. Thus, these signals will be sent through a centralized
synchronizer block similar to the one used for gated clocks. For the module
designer, this means that pins named "set", "setb", "reset",
and "resetb" should be assumed asynchronous.
maintained by Rhett Davis
wrdavis@eecs.berkeley.edu
| |
