The VHDL which is automatically generated by Yagle is an RTL level zero delay data-flow description. It contains a list of concurrent assignment statements which represent the behavior of the simple gates which are neither high impedance nor conflictual. Distinct VHDL process blocks are used to describe those gates which represent identified memory elements as well as those gates for which Yagle was unable to verify the duality.
The declarations within the VHDL file conform to those of the IEEE STD_LOGIC package. This makes the VHDL readily exploitable by most commercial simulation, formal proof and synthesis tools.
The VHDL produced if FCL is used remains similar since a given behavioral description is parsed to generate an internal behavioral model, however this model can contain delay information, specified through the use of the AFTER attribute. However, if the full hierarchical pattern recognition is used, then any kind of behavioral description can be produced. Here we can only describe the VHDL which is automatically generated.
Latches and registers are described using separate VHDL processes, to allow easy latch inference by any subsequent parser. A cascaded "IF ... THEN ... ELSIF ... ... END IF" statement is used to represent separate driving conditions. For example a latch with two clocks would be represented by :
REG1: PROCESS (ck1,ck2) BEGIN IF ck1 = '1' THEN latch <= data1; ELSIF ck2 = '1' THEN latch <= data2; END IF; END PROCESS; |
It should be noted that the lexical construction guarantees that the latch is not conflictual, and that the memory signal is incompletely assigned. This allows straightforward latch inference.
Registers are differentiated from latches through the use of the EVENT attribute on one (and only one) of the clock signals. For example, a positive-edge triggered flip-flop with an asynchronous reset would be represented by :
REG1: PROCESS (ck,reset) BEGIN IF reset = '1' THEN reg <= '0'; ELSIF (ck = '1' and ck'EVENT) THEN reg <= data; END IF; END PROCESS; |
Both high impedance and conflictual nodes are modeled by two process blocks. One process describes the condition for the assignment of logic '1', whilst the other describes the condition for the assignment of logic '0'. For example a simple tri-state gate would be described as follows :
BUS0: PROCESS (enable,data) BEGIN IF (enable = '1' and data = '1') THEN out <= '1'; ELSE out <= 'Z'; END IF; END PROCESS; BUS1: PROCESS (enable, data) BEGIN IF (enable = '1' and data = '0') THEN out <= '0'; ELSE out <= 'Z'; END IF; END PROCESS; |
The "IF ... THEN ... ELSE ... END IF" configuration is used to ensure that the tri-state signal is completely defined. This is necessary to avoid the tri-state node being mistaken for a latch.
No additional vectorization is deduced by Yagle. Connector and signal declarations can be optionally vectorized or devectorized. All assignment expressions are given on a bit by bit basis.
The following example of a VHDL file generated by Yagle illustrates the typical structure :
-- VHDL data flow description generated from `addaccu` -- date : Tue Jul 18 20:08:28 2000 library IEEE; use IEEE.std_logic_1164.all; -- Entity Declaration ENTITY addaccu IS PORT ( a : in std_logic_vector (3 DOWNTO 0); b : in std_logic_vector (3 DOWNTO 0); ck : in std_logic; s : inout std_logic_vector (3 DOWNTO 0); sel : in std_logic; vdd : in std_logic; vss : in std_logic ); END addaccu; -- Architecture Declaration ARCHITECTURE RTL OF addaccu IS SIGNAL accu : STD_LOGIC_VECTOR (3 DOWNTO 0); SIGNAL oper : STD_LOGIC_VECTOR (3 DOWNTO 0); SIGNAL carry : STD_LOGIC_VECTOR (2 DOWNTO 1); BEGIN carry (1) <= ((oper (1) and ((oper (0) and (a (1) or a (0))) or a (1))) or (oper (0) and a (1) and a (0))); carry (2) <= ((a (2) and (carry (1) or oper (2))) or (carry (1) and oper (2))); oper (0) <= ((b (0) and (accu (0) or not (sel))) or (accu (0) and sel)); oper (1) <= ((b (1) and (accu (1) or not (sel))) or (accu (1) and sel)); oper (2) <= ((b (2) and (accu (2) or not (sel))) or (accu (2) and sel)); oper (3) <= ((b (3) and (accu (3) or not (sel))) or (accu (3) and sel)); REG0: PROCESS (ck) BEGIN IF (ck = '0' and ck'EVENT) THEN accu (0) <= s (0); END IF; END PROCESS; REG1: PROCESS (ck) BEGIN IF (ck = '0' and ck'EVENT) THEN accu (1) <= s (1); END IF; END PROCESS; REG2: PROCESS (ck) BEGIN IF (ck = '0' and ck'EVENT) THEN accu (2) <= s (2); END IF; END PROCESS; REG3: PROCESS (ck) BEGIN IF (ck = '0' and ck'EVENT) THEN accu (3) <= s (3); END IF; END PROCESS; s (0) <= not ((a (0) xor oper (0))); s (1) <= (a (1) xor oper (1) xor (not (oper (0)) or not (a (0)))); s (2) <= (a (2) xor oper (2) xor not (carry (1))); s (3) <= (a (3) xor oper (3) xor not (carry (2))); END; |
In this section, we provide details of the main underlying data structure manipulated by Yagle. The heart of the disassembly procedure is, in fact the transformation of a transistor netlist into the disassembled gates represented by this so-called CNS data structure. It is this data structure which is functionally characterized in order to automatically generate the VHDL from a transistor net-list.
These details are provided to help the reader understand the task performed by Yagle and to aid in the comprehension of the information provided in the CNS output file.
The CNS (acronym for Cone Net-list Structure) data structure is designed to represent extracted gate net-lists. It has evolved out of the need for a common data structure for CAD-VLSI verification tools such as: formal verification, timing and power analysis, and logico-temporal simulation.
These tools require efficient data structures which can directly support fast algorithms, since the volume of data to be treated is generally very high. Yet they also require enough structural and electrical details of the circuit for the verification results to accurately reflect the final circuit. An extracted transistor net-list effectively contains all the electrical characteristics required, however, the lack of orientation of the net-list renders unfeasible the verification of circuits of any reasonable size.
The CNS data structure attempts to combine the precision advantage of a transistor net-list with the speed advantage of a logical gate net-list. This is achieved by representing the circuit as a directed acyclic graph representing signal-flow within the circuit. Each node of this graph is a type of pseudo logical gate known as a cone. A graph representation of the circuit allows the direct implementation of rapid traversal algorithms useful in simulation and timing analysis.
The fundamental element of this data structure is the Cone. The Cone represents a means of cutting-up the transistor net-list such that the influences on every transistor gate are well-defined. In effect, a cone contains the set of current paths to the power supplies or external connectors for the gate of every transistor. Since transistor gates represent the cone to cone boundaries, and the gate current of MOS transistors is negligible, there is no current transfer between cones. This characteristic makes the cone conceptually ideal for the analysis of any kind of circuit behavior which depends on charge transfer, for example timing and power consumption.
Since the most common means of obtaining a CNS representation of a circuit is through the disassembly of a transistor net-list, an understanding of the principles of disassembly is useful in the comprehension of the CNS data structure. This section, therefore, briefly explains the basics of the disassembly process.
The disassembly of a circuit is based on the principle of obtaining the equations which define the state of each transistor gate. In order to obtain these equations, the circuit representation is converted from a transistor net-list to a cone net-list (see figure 9.1), it is this representation which is stored in the CNS data structure.
A cone is defined as being, for each circuit node which is connected to at least one transistor gate, the set of branches which, from this node, attain a power supply or an external connector on the traversal of transistor source-drain junctions. Each branch consists of links which correspond to the transistors traversed. These branches therefore reveal the signals which govern the state of the transistor gate(s) for which the cone is being constructed.
A set of cones is therefore obtained (completely defining the state of all transistor gates and drivable external connectors), each of which contain a set of branches. For the example of figure 9.1, the two cones E and F are made up of the branches shown in figure 9.2.
This set of branches allows us to express the behavior of the cone and hence generate a Boolean expression for the state of the corresponding transistor gate. This expression is in fact composed of two parts: the function which represents the conditions necessary for Vdd to impose (Sup), and the equivalent for Vss (Sdn).
In reality these conditions have to verified globally, this means that Sup and Sdn are expressed in terms of the logic surrounding the cone. The depth, in terms of logic gates, used for the expansion is defined by the user.
The top-level data structure of CNS is called the CNS figure and is declared in 'C' as a cnsfig_list. This, in common with all the other CNS objects, is a linked-list structure, the first element of the structure being a pointer to the next element in the list. This is provided mainly for memory management purposes, since it allows block allocation of cnsfig_list structures.
The CNS figure is the global description of the entire disassembled circuit. In common with the MBK lofig_list logical net-list representation, it contains the list of external connectors, and the list of transistors. However, the internal structure of the circuit is represented by the list of cones as opposed to a list of instances.
In addition to the above, the CNS figure also contains a number of optional fields. The first of these is a list of cells, each cell corresponding to a grouping of cones. The next two fields are filled in by the circuit disassembler if requested, but are currently not supported by the parser of the CNS figure. These are: a pointer to a global behavioral figure for the circuit, and a logical net-list for the circuit. The logical net-list is hierarchical since each instance of the logical figure corresponds to a cone, and cones of similar physical structure are grouped into identical models for which the disassembler generates separate behavioral descriptions. The final field is the USER field, which allows the addition of user-defined information to the structure.
The fundamental object of CNS is the cone, this is the disassembled equivalent of a logical gate. It is made up (as described in §9.3.2) of branches, a branch corresponding to a path from the node on which the cone is built to an external port across transistor source-drain junctions.
Each cone contains up to four sets of branches but at least one. These sets correspond to the type of external port on which the branch ends. The four types are: VDD, VSS, EXT and GND, corresponding to branches terminating on Vdd or Vss power supplies, external connectors, or ground (for GaAs compatibility) respectively. Note that for external connector branches, the final link of the branch points to the corresponding connector.
The connectivity between cones is represented by edges. Each cone contains two lists of edges: one for the inputs, and one for the outputs. An edge contains a pointer to an object to which the cone is connected (cone or external connector) and a type indicating the type of object and certain characteristics of the connection.
CNS contains a mechanism for the grouping of cones, this is useful in the detection of complex gates by pattern recognition. This mechanism is accommodated by means of the list of cells in the CNS figure. Each cell contains the list of cones contained within the cell, a type indicating what the grouping correspond to, and an optional behavioral figure.
The CNS data structure is an inhomogeneous, hierarchical data structure, that is each level of the hierarchy contains specific types of objects, which are different to the types found on other levels. The complete hierarchy is shown in figure 9.3.
The most notable feature revealed in figure 3 is the looped nature of the hierarchy. It is this characteristic which gives CNS its flexibility in traversal, hence allowing implementation of efficient algorithms.
A detailed explanation of the various parts of the CNS figure is given in §9.4.1. The figure is defined as a cnsfig_list structure which is summarized in table 9.1.
Field Name | Description |
NEXT | link to next CNS figure in list |
NAME | name of the figure |
LOCON | list of external connectors |
LOTRS | list of transistors |
CONE | list of cones |
CELL | list of cells (cone groups) |
LOFIG | hierarchical logical net-list |
BEFIG | global behavioral figure |
USER | user-defined |
Table 9.1: Summary of the CNS figure
This, in common with all the other CNS objects is a linked-list data structure, for reasons of memory management. The last four fields can be NULL.
The link object, of type link_list, is made up of the following fields:
struct link *NEXT | Pointer to the following link in the branch's list of links. |
long TYPE | The logical sum of masks indicating the type and nature of the link. |
union ulink ULINK | Pointer to the object to which the link refers, LOTRS, LOCON or PTR. |
float CAPA | The capacitance of the node at which the link is built. |
struct ptype *USER | User defined information. |
Note that the ULINK field is a union since it can point to a transistor (field LOTRS of type lotrs_list*) or a connector (field LOCON of type locon_list*). In addition the union contains a field for a generic pointer (PTR of type void*) to facilitate pointer comparison.
CNS_IN | An external connector link corresponding to an input only connector. |
CNS_INOUT | An external connector link corresponding to a bidirectional connector. |
CNS_2EQUIP | A generic type corresponding to devices with only two equipotentials, e.g. diode or resistance links. |
CNS_3EQUIP | A generic type corresponding to devices with three equipotentials, e.g. MOS transistors. |
CNS_SWITCH | A link corresponding to part of a CMOS transmission gate. |
CNS_COMMAND | A link corresponding to a transistor, within a latch cone, whose gate is driven by the command signal of the latch. |
CNS_ACTIVE | A generic type corresponding to any active device. |
CNS_PASSIVE | A generic type corresponding to any passive device. |
CNS_DOWN CNS_UP | Generic types indicating the orientation of non-symmetric devices links, e.g. diodes. UP corresponding to towards the power supply, and DOWN corresponding to away from the power supply. |
CNS_SW | A generic type indicating any active switching device, usually a transistor. |
CNS_PULL | A link corresponding to a passive pull up or pull down resistance. |
CNS_DRIV_PULL | A link corresponding to an active pull-up or pull-down resistance. |
CNS_DIODE_UP CNS_DIODE_DOWN | A link corresponding to a diode oriented according to the generic orientation masks. |
CNS_RESIST | A link corresponding to a passive resistance, e.g. an MOS transistor whose gate is connected to a power supply. |
CNS_CAPA | A link corresponding to a capacitance, e.g. an MOS transistor whose source and drain are connected to the same equipotential. |
CNS_DIPOLE | A link corresponding to a dipole. |
A large number of the above masks are generic types, they are rarely used in the affectation of a type to a link since the are included in the non-generic types. For example the type CNS_RESIST includes the masks CNS_PASSIVE and CNS_2EQUIP.
The generic types are included to facilitate the testing of links, since they allow certain type groups of links to be tested for using a comparison with a single mask.
The branch object, of type branch_list, is made up of the following fields:
struct branch *NEXT | Pointer to the following branch in the cone's list of branches. |
long TYPE | The logical sum of masks indicating the type and nature of the branch. |
struct link *LINK | The list of links which make up the branch. |
struct ptype *USER | User defined information. |
CNS_VSS CNS_VDD | |
A branch corresponding to a path from the cone output node to the Vdd(Vss) power supply. | |
CNS_VDD | |
A branch corresponding to a path from the cone output node to the Vdd(Vss) power supply. | |
CNS_GND | |
A branch corresponding to a path from the cone output node to ground (exists only in GaAs). | |
CNS_EXT | |
An external connector branch, i.e. a path from the cone output node to an external connector. Note that the final link of the branch is the external connector. | |
CNS_NOT_FUNCTIONAL | |
A branch which does not contribute to the functionality of the cone, for example: a pull-up resistance or a bleeder. | |
CNS_BLEEDER | |
A branch corresponding to one of the forms of figure 5a. | |
CNS_DEGRADED | |
A branch which degrades the output level of the cone, i.e. a Vdd branch containing an N-type transistor or a Vss branch containing a P-type transistor. | |
CNS_PARALLEL | |
A branch for which there exists one or more parallel branches within the cone. See §9.3.2 for the definition of parallel branches | |
CNS_PARALLEL_INS | |
For any given set of parallel branches, all but one are marked with the type PARALLEL_INS. This allows algorithms which traverse the list of branches to consider only one of the set of parallel branches by ignoring those of type PARALLEL_INS. | |
CNS_FEEDBACK | |
A branch which corresponds to part of the feedback loop in a latch cone. |
The link object, of type link_list, is made up of the following fields:
struct link *NEXT | Pointer to the following link in the branch's list of links. |
long TYPE | The logical sum of masks indicating the type and nature of the link. |
union ulink ULINK | Pointer to the object to which the link refers, LOTRS, LOCON or PTR. |
float CAPA | The capacitance of the node at which the link is built. |
struct ptype *USER | User defined information. |
Note that the ULINK field is a union since it can point to a transistor (field LOTRS of type lotrs_list*) or a connector (field LOCON of type locon_list*). In addition the union contains a field for a generic pointer (PTR of type void*) to facilitate pointer comparison.
CNS_IN | An external connector link corresponding to an input only connector. |
CNS_INOUT | An external connector link corresponding to a bidirectional connector. |
CNS_2EQUIP | A generic type corresponding to devices with only two equipotentials, e.g. diode or resistance links. |
CNS_3EQUIP | A generic type corresponding to devices with three equipotentials, e.g. MOS transistors. |
CNS_SWITCH | A link corresponding to part of a CMOS transmission gate. |
CNS_COMMAND | A link corresponding to a transistor, within a latch cone, whose gate is driven by the command signal of the latch. |
CNS_ACTIVE | A generic type corresponding to any active device. |
CNS_PASSIVE | A generic type corresponding to any passive device. |
CNS_DOWN CNS_UP | Generic types indicating the orientation of non-symmetric devices links, e.g. diodes. UP corresponding to towards the power supply, and DOWN corresponding to away from the power supply. |
CNS_SW | A generic type indicating any actice switching device, usually a transistor. |
CNS_PULL | A link corresponding to a passive pull up or pull down resistance. |
CNS_DRIV_PULL | A link corresponding to an active pull-up or pull-down resistance. |
CNS_DIODE_UP CNS_DIODE_DOWN | A link corresponding to a diode oriented according to the generic orientation masks. |
CNS_RESIST | A link corresponding to a passive resistance, e.g. an MOS transistor whose gate is connected to a power supply. |
CNS_CAPA | A link corresponding to a capacitance, e.g. an MOS transistor whose source and drain are connected to the same equipotential. |
CNS_DIPOLE | A link corresponding to a dipole. |
A large number of the above masks are generic types, they are rarely used in the affectation of a type to a link since the are included in the non-generic types. For example the type CNS_RESIST includes the masks CNS_PASSIVE and CNS_2EQUIP.
The generic types are included to facilitate the testing of links, since they allow certain type groups of links to be tested for using a comparison with a single mask.
The edge object, of type edge_list, is made up of the following fields:
struct link *NEXT | Pointer to the following edge in the cone's list of edges. |
long TYPE | The logical sum of masks indicating the type and nature of the edge. |
union uedge UEDGE | Pointer to the object to which the edge refers, CONE, LOCON or PTR. |
struct ptype *USER | User defined information. |
Note that the UEDGE field is a union since it can point to a transistor (field CONE of type cone_list*) or a connector (field LOCON type locon_list).
CNS_VSS CNS_VDD | An edge corresponding to a cone built on a Vdd(Vss) power supply node. |
CNS_GND | An edge corresponding to a cone built on a ground node (exists only in GaAs). |
CNS_EXT | Indicates that the edge is an external connector and hence that the pointer in the UEDGE union is of type locon_list*. |
CNS_CONE | Indicates that the edge is a cone and hence that the pointer in the UEDGE union is of type cone_list*. |
CNS_BLEEDER | Indicates that the edge corresponds to the input, or corresponding output of a bleeder loop (see figure 5a). |
CNS_COMMAND | Indicates that the edge corresponds to a command input of a latch cone. |
CNS_LOOP | Indicates that the edge forms part of a two cone loop. |
CNS_FEEDBACK | Indicates that the edge corresponds to the input, or corresponding output of a latch feedback loop |
The CNS transistor object uses the same data structure as MBK, the lotrs_list structure, hence the reader is referred to the MBK documentation for details. CNS does however define its own TYPE masks as well as additional USER types for the transistors.
The TYPE masks are:
CNS_TN | defined as TRANSN |
CNS_TP | defined as TRANSP |
The additional USER types are:
CNS_INDEX | |
A unique number for the transistor wihin the circuit, used by the parser/driver in order to refer to individual transistors. | |
CNS_LINKTYPE | |
Contains the TYPE affected to any links referring to the transisitor. | |
CNS_DRIVINGCONE | |
Contains a pointer to the cone built on the equipotential to which the transistor gate is connected. | |
CNS_CONE | |
Contains a chain_list of the cones containing links referring to the transistor. This field is rarely created due to reasons of memory efficiency. |
The CNS connector object uses the same data structure as MBK, the locon_list structure, hence the reader is referred to the MBK documentation for details. CNS does, however, define additional USER types for the connectors.
The additional USER types are:
CNS_INDEX | A unique number for the connector within the circuit, used by the parser/driver in order to refer to individual connectors. |
CNS_EXT | Contains a pointer to the cone built on the equipotential connected to the external connector. |
CNS_CONE | Contains a chain_list of the cones containing links referring to the external connector. This field is rarely created due to reasons of memory efficiency. |
The cell object, of type cell_list, is made up of the following fields:
struct link *NEXT | Pointer to the following cell in the figure's list of cells. |
long TYPE | The logical sum of masks indicating the type of the cell. |
chain_list *CONES | The list of cones contained within the cell. |
struct befig *BEFIG | The behavioral description of the cell. |
struct ptype *USER | User defined information. |
A number of standard cell types have been defined in the CNS header to deal with the recognition of GaAs cone configurations, it is possible that this list will be extended to include certain standard CMOS forms.
The convention for adding a user defined cell type so that it is recognized as such by the CNS driver is to sum a desired type reference number with the constant CNS_UNKNOWN. This allows the driver to identify that the cell is not defined within CNS but is nonetheless a legal type, hence the cell is identified within the CNS file by the index and not by a name as is the case for the predefined types.