|
EDIF netlists follow a strict "declaration before use" rule. Every component
must be defined in a library before the component can be used. This means that an EDIF
netlist of LPM modules will have a number of cell definitions before the netlist itself
appears. These cell definitions can be thought of as "fully described modules"
of the (LPM) parameterized modules. Once defined, any number of these "fully
described modules" can be instantiated within the netlist. The declaration serves two
purposes: it indicates that the module is to be used and it also fixes the values of the
parameters to be used (e.g., the AND gate is 4 bits wide). However a design may need both
4-input and 2-input AND gates. Both of these have to be declared and clearly they need to
have names that distinguish between them. In addition there may be several instances of
use of the same type of gate (e.g., the 2-input AND gate may be used 5 times). Thus LPM
has three types of names for each module. These are:
This is a name specified by property LPM_TYPE. These cell names are listed in chapter four and prefixed with "LPM_". For example, LPM_COUNTER is the LPM TYPE name in the following example. (property LPM_TYPE (string "LPM_COUNTER"))
This is a name when the module, a "cell" in EDIF terminology, is declared. For example, addsub_4 is the EDIF cell name in the following example. EDIF 2 0 0 example: (cell addsub_4 (cellType generic) (view view1 (viewType netlist) (interface . . . . EDIF 3 0 0 example: (cell addsub_4 (cellHeader ...) (cluster . . . (interface . . . .
This is the name used by the instance construct when the cell is instantiated. Instance name refers to a unique use of a EDIF Cell name that has already been declared. For example, addsub_4 is the EDIF cell name in the following example. EDIF 2 0 0 example: (instance addsub1 (viewRef view1 (cellRef addsub_4))) EDIF 3 0 0 example: (instance addsub1 (clusterRef C1 (cellRef addsub_4))) |
Copyright © 1998 University of Manchester |