4. Performing the Abstraction

4. 1. File Loading

The purpose of this section is to show how to load files containing:

File loading is done with the Tcl command avt_LoadFile. Depending on the file format being read, and on the netlist specificities (such as vectors, connector order,...), additional configuration is sometimes required. Additional configuration should be set with avt_config Tcl commands, before invoking avt_LoadFile.

4. 1. 1. Transistor Technology Models

Transistor technology models are necessary to compute timings. If those transistor models appear in a separate file, they should be loaded in the Tcl script with the avt_LoadFile function. The avt_LoadFile function takes as first argument the name of the file to load, and as second argument its format. A typical loading of a technology file will be such as:

avt_LoadFile ../models/bsim3.tech spice

If the technology file makes inclusions of other files then inclusion paths should be absolute. If paths are relative, further configuration will be needed to specify the location of those files:

avt_config avtLibraryDirs .:../models

Technology file can also appear as an inclusion (.INCLUDE or .LIB) in a Spice netlist. In such a case, it will be loaded at the time the Spice netlist is loaded.

Different industry-standard electrical simulators have different interpretations of the parameters of .MODEL statement, which also deviate from the Berkeley model (see Berkeley's BSIM3v3.2.4 or BSIM4.3.0 MOSFET Model User's Manual). This can lead to significant differences in the results given by different simulators.

Besides, the LEVEL parameter which appears in the model files is not discriminant enough. Different simulators may interpret differently a same LEVEL value (as it is the case for LEVEL 49, differently interpreted by HSPICE and ELDO). Therefore, it is necessary to specify the targetted simulator of the transistor model. It should be done with the following variable:

avt_Config simToolModel ELDO

If the simToolModel variable is not specified, Yagle will interpret the transistor model as HSPICE does (default value), and check the LEVEL against the following list:

TOOL hspice 
BSIM3V3  param level   49 
BSIM3V3  param level   53 
BSIM4    param level   54 
PSP      param level 1020 
PSPB     param level 1021 
 
TOOL eldo 
BSIM3V3  param level   49 
BSIM3V3  param level   53 
BSIM4    param level   60 
PSP      param level 1020 
PSPB     param level 1021 
 
TOOL ngspice 
BSIM3V3  param level    8 
BSIM4    param level   14 
 
 
TOOL titan 
BSIM3V3  model BSM3 setdefault version 3.0 
BSIM3V3  model BS32 setdefault version 3.24 
BSIM4    model BS4  setdefault version 4.2 
BSIM4    model BS41 setdefault version 4.1 
BSIM4    model BS42 setdefault version 4.21 

If there is a conflict, for example if LEVEL=60 is given and simToolModel is not specified (defaulted to HSPICE), the tool will exit. User needs to properly set the simToolModel value.

4. 1. 2. Input Netlist

In a way or another, one must always provide a transistor-level description of the design. If impossible to give a transistor description for some parts of the netlist, Yagle can also take .lib files as input, but it should be understood that Yagle is primarily designed for digital transistor-level analysis, and that providing .lib files should only apply to parts of the netlist where Yagle does not apply, e.g. analog parts. Integration of .lib files will be discussed later.

A transistor level description can be provided within the following formats:

Flat-transistor Spice netlist

A flat-transistor extracted Spice netlist is simply loaded with the following command:

avt_LoadFile my_design.spi spice

The file can contain parasitics, and preferably contains a .SUBCKT statement. If not, an implicit top-level is created, with all the nodes in the netlist reported on the interface. This can lead to computational explosion in further steps of the analysis.

Hierarchical Spice netlist

A hierarchical Spice netlist can be represented by several files. Those files can be loaded either through possibly recursive .INCLUDE statements, or through several avt_LoadFile commands. However, at least one avt_LoadFile command must appear in the Tcl script. The netlist is automatically flattened to the transistor-level, when all the dependancies have been resolved, e.g. when all instanciated sub-circuits correspond to a sub-circuit definition.

In a separate avt_LoadFile command, sub-circuit definition can appear after its instanciation, the order is not relevant. For example, the following file can be loaded by avt_LoadFile my_design.spi spice:

.SUBCKT my_design ...
...
.ENDS my_design
 
.INCLUDE ../leaf_cells/n1_y.spi
.INCLUDE ../leaf_cells/o3_y.spi
.INCLUDE ../leaf_cells/mx2_y.spi

Order is relevant if sub-circuit definitions appear in files read by separate avt_LoadFile commands. In that case reading the files containing sub-circuit definitions must be done before reading the files containing their instanciation, as shown in the follwing example:

avt_LoadFile leaf_cells/n1_y.spi spice
avt_LoadFile leaf_cells/o3_y.spi spice
avt_LoadFile leaf_cells/mx2_y.spi spice
avt_LoadFile my_design.spi spice

Hierarchical Verilog/VHDL netlist

The same example applies to a Verilog netlist and Spice transistor-level leaf-cells:

avt_LoadFile leaf_cells/n1_y.spi spice
avt_LoadFile leaf_cells/o3_y.spi spice
avt_LoadFile leaf_cells/mx2_y.spi spice
avt_LoadFile my_design.v verilog

or

avt_LoadFile my_design.vhd vhdl

4. 1. 3. Parasitics

Yagle treats parasitics files of two kinds:

Back-annotation

When a parasitic file is used to back-annotate a schematic netlist, the schematic netlist must be loaded first, through a separate avt_LoadFile command. Just invoking the load of the parasitic file afterwards is enough to perform the back-annotation:

avt_loadfile my_design.spi spice
avt_loadfile parasitics.spef spef

or

avt_loadfile my_design.spi spice
avt_loadfile parasitics.spf dspf

When using back-annotation, special attention should be paid to name consistency between netlist and parasitics, especially regarding vectors (see next chapter).

Connectivity

If the parasitics file is necessary to ensure the connectivity of the netlist, the parasitics and netlist files should be loaded through a single avt_LoadFile command. Parasitic files should be included at appropriate levels of hierarchy with .INCLUDE statements.

4. 1. 4. Vectorization

Yagle has two operating modes regarding vectors. One can choose between a mode where vectors are represented internally as they appear in the source file, and a mode where they are identified as special signals and represented internally accordingly. When a vector is identified as a special signal, the internal representation is a string containing the radical and the index separated by a space character. For example the vector dummy[0] is represented as dummy 0.

Different delimiters can be used to represent vectors. Configuration of legal delimiters, as well as the choice to treat vectors as special, should be done with the avtVectorize configuration variable:

avt_config avtVectorize "[],<>"

Treating vectors as special signals is usefull when the same vectors can appear with different delimiters in different files. For example if a vector is referred to as dummy[0] in a Verilog file, and as dummy<0> in a SPEF file, the previous configuration is necessary to make the correspondance between the two names.

4. 1. 5. Ignoring Elements

For a reason or another, some elements in the source files may be unsupported by Yagle or may not respect standard format syntax. To work around those elements, Yagle provides the means to ignore them during the parse of the source netlist. The elements that can be ignored are instances, transistors, resistances and capacitances. For further information please refer to the inf_DefineIgnore command documentation.

4. 2. General Configuration

4. 2. 1. Defining Power Supplies

Special attention should be paid to the definition of power supply and ground nodes (avtVddName, avtVssName and simPowerSupply variables). Indeed, the disassembly process is heavily dependant on the naming of those nodes, as the algorithm is looking for current paths towards power supply and ground. Bad specification of these nodes can lead to the construction of an exponential number of wrong current paths. Power supply and ground definition is the first thing to check if the disassembly process seems to loop infinitely.

Yagle also supports V cards for the definition of power supply and ground nodes. One can distinguish between two cases:

The power supply and ground node appear on the interface of the .SUBCKT, and the subcircuit is instanciated. The V cards should refer to the names used in the instanciation:

Vsupply vdd gnd DC 1.2V
Vground gnd 0   DC 0V
   
.SUBCKT my_design a b c vdd_int gnd_int
...   
.ENDS my_design   
   
X0 a b c vdd gnd my_design

The power supply and ground node does not appear on the interface of the .SUBCKT, or the subcircuit is not instanciated. The V cards should refer to the names used within the subcircuit, or appearing on the interface of the .SUBCKT, together with .GLOBAL statements:

.GLOBAL vdd gnd
   
Vsupply vdd gnd DC 1.2V
Vground gnd 0   DC 0V
   
.SUBCKT my_design a b c vdd gnd
...   
.ENDS my_design   

4. 3. Invoking Functional Abstraction

The functional abstraction routine is invoked by the yagle command, which takes as argument the name of a sub-circuit. The sub-circuit must be among the previously loaded netlists. If the sub-circuit contains instances it will be flattened to the transistor-level. In such a case, signal naming respects the hierarchical paths. The name of a signal is the concatenation of the names of the successive instances that appear in the hierarchical path leading to the physical node the signal is associated with. The typical Tcl command for invoking functional abstraction is:

yagle my_design

where my_design is the name of the .SUBCKT to treat. If flatten is impossible (i.e. transistor level sub-circuits are missing for leaf cells), with no further configuration, the tool will issue an error and exit.

The default configuration creates a VHDL description.

4. 4. Timing Back-Annotation

4. 4. 1. Defining Simulation Temperature

Temperature can be deined either with the simTemperature configuration variable or through a .TEMP statement in the Spice file.

4. 4. 2. Back-Annotation Level

The level of accuracy used for the back-annotation is yagleTasTiming

4. 5. Output Files

4. 5. 1. CNS, CNV files

The .cns file describes the partitions (cones), and their interconnections, resulting from the disassembly process. This file is very useful for debugging purposes, and necessary for the spice deck generation of timing paths. The file can be generated with the following configuration:

avt_config yagleGenerateConeFile yes

The .cns file is intented to be re-read by Yagle and therefore is not very human-readable. A more friendly version can be generated by setting:

avt_config avtVerboseConeFile yes

4. 5. 2. VHDL and Verilog files

VHDL file is generated in default mode. a Verilog file can be generated instead by using the following configuration:

avt_config avtOutputBehaviorFormat vlg

4. 6. Special Elements

4. 6. 1. Transmission Gate Multiplexers

The detection of multiplexors is done purely algorithmically. The cone partitioning strategy implemented in Yagle perfectly fits with the detection and modeling of transmission-gate based multiplexers, provided that the correlations between the commands can be resolved within the design. The only reason why detection may fail, is because the schematic of the design itself prevents to identify those correlations, for example when commands are input pins. In such a case, correlations (mutual exclusion) should be set externally with INF commands.

The following diagram shows two situations. In the left-hand design, the mutual exclusion between sel and nsel is not ensured by the design. There is no way for the tool to identify inputs and outputs, and it constructs false current paths. In the right-hand design, the mutual exclusion between sel and nsel is ensured by the invertor, and therefore the tool correctly models the multiplexer.

To avoid the construction of false current paths in the left-hand design, the following mutual exclusion configuration should be set:

inf_DefineMutex cmpUP {sel nsel}

If the transmission gate toppology is more complex, and setting of mutual exclusion constraints become too much difficult, another orientation mechanism is available. Let's consider the next design:

Here orientation can be done by setting levels on signals i0, i1, s and out. The transistors are oriented by assuming the current is going from the signals with the higher level to the signals with the lower level. Levels should be set as follow:

inf_DefineDirout i0  3
inf_DefineDirout i1  3
inf_DefineDirout s   2
inf_DefineDirout out 1

The default orientation value of signals is -1.

4. 6. 2. Latches

Two algorithms exist in Yagle to detect latches. The first one is based on pattern-matching. The tool tries to match in the design built-in latch patterns. This algorithm is enabled with the yagleStandardLatchDetection (default behavior is enabled). The second algorithm is based upon the Boolean analysis of gate loops and an electrical analysis of conflicts. This algorithm is enabled with the yagleAutomaticLatchDetection variable (default behavior is not enabled). The two algorithms can be enabled together, in such a case the standard latch detection is performed before the automatic latch detection.

4. 6. 3. Dynamic Latches

Dynamic latches are typically tristate nodes followed by a capacitance. In default mode, tristate nodes are not marked as latches. This behavior can be changed with the yagleMarkTristateMemory configuration variable.

Dynamic latches can also be identified with the INF commands inf_DefineDLatch and inf_DefineNotDLatch

4. 7. Case Analysis

Case analysis, such as Scan Mode analysis or Functional mode analysis, is available in the Yagle platform. It is performed by sticking input connectors or internal signals to logical low or logical high values. It is done by adding in the Tcl script the SDC command set_case_analysis.

The logical value stuck on the input connector or logical signal is propagated through the design, with regard to the behavior of the gates it crosses. A report of the stuck signals is available in the .rep file:

[WRN 30] Signal 'ram_na3' is stuck at Zero
[WRN 31] Signal 'ram_a43r_net6' is stuck at One