7. Timing DB Construction

7. 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.

7. 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, HITAS 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.

7. 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, HITAS can also take .lib files as input, but it should be understood that HITAS is primarily designed for digital transistor-level analysis, and that providing .lib files should only apply to parts of the netlist where HITAS 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

7. 1. 3. Parasitics

HITAS 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.

7. 1. 4. Vectorization

HITAS 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.

7. 1. 5. Ignoring Elements

For a reason or another, some elements in the source files may be unsupported by HITAS or may not respect standard format syntax. To work around those elements, HITAS 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.

7. 2. DB Construction

7. 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.

HITAS 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   

7. 2. 2. Defining Simulation Thresholds

By default, the slope is defined between 20% and 80% of Vdd. It is possible to change those values with the simVthLow and simVthHigh variables. Delays are always computed with a threshold of 50%.

7. 2. 3. Defining Simulation Temperature

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

7. 2. 4. Invoking DB Construction

The timing DB construction routine are invoked by the hitas 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 signalis associated with. The typical Tcl command for invoking timing DB construction is:

set fig [hitas 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 timing DB containing DTX, STM, RCX files.

7. 3. Output Files

7. 3. 1. REP file

Once the Timing DB has been constructed, it is important to have a look at the .rep file. This file is a report of the disassembly process. The essential thing to check here is that latches have been correctly detected. Ideally, all the latches have been automatically detected by the Boolean analysis of the gate loops. However, the report file lists all the loops between gates that have been identified during the disassembly process, and if they have been associated with a latch. A complete list of the warnings issued in the .rep is available in the reference manual.

7. 3. 2. LOOP file

Ideally the .loop file does not exist, as it is created only if the path searching algorithm detects combinational loops in the design. Note that the path searching algorithm is performed after the disassembly process, and therefore the occurrence of combinational loops is heavily dependant on the correct recognition of the latches in the design.

7. 3. 3. 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 tasGenerateConeFile yes

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

avt_config avtVerboseConeFile yes

7. 3. 4. DTX and STM files

The default configuration generates the .dtx file (timing arcs) and .stm file /9timing models).

7. 4. Latch Detection and Modeling

HITAS handles the following types of latches:

All those types of latches are recognized and modeled automatically during the partitioning phase. If automatic detection were to fail, manual identification is still possible. User-defined tags may be applied on nodes in the design.

7. 4. 1. Detection Sequences

Manual Identification

If latch/command tags on specific nodes are set in the configuration file, those tags will be applied and will disable any subsequent automatic analysis upon those nodes.

Simple Detection

Simple detection is based upon pattern matching. If activated, this sequence uses simple patterns and rules to quickly detect the simplest latch structures. This sequence is to be used with caution. It permits to quickly detect the most common latches but also uses some heuristics which may not be correct for more complex latches. This sequence is particularly useful (time saving) when dealing with static memories (SRAM) containing a large number of 6T bit-cells. Latches detected at that point will be:

Automatic Detection

Automatic detection is based upon loop analysis. This sequence recognizes any kind of fully static latch designed using an active feedback loop, and containing any number of clock inputs as well as asynchronous set and reset inputs. Within this sequence, specific algorithms may be further applied to model RS latches, asynchronous set and reset within D-latches and symmetric latches.

Dynamic Latches Detection

7. 4. 2. Enabling Detection Sequences

The detection sequences are controlled by the following variables:

Manual Identification

inf_MarkSignal

inf_MarkTrans

Simple Detection

yagSimpleLatchDetection=memsym|levelhold|latch

Automatic Detection yagAutomaticLatchDetection=yes
RS Latches

yagAutomaticLatchDetection=yes

yagAutomaticRSDetection=mark|latch|legal|illegal

Asynchronous Signals

yagAutomaticLatchDetection=yes

yagSetResetDetection=yes|remove

Symmetric Latches

yagAutomaticLatchDetection=yes

yagAutomaticMemsymDetection=yes|remove

Dynamic Latches yagDynamicLatchDetection=yes

See HITAS Reference Guide for a more detailed description of those configuration variables.

7. 5. Static Latch Modeling

Latches such as the one described below are well recognized with the automatic algorithm controlled by yagAutomaticLatchDetection. In this example HITAS recognizes a latch around the node master (and another one around the node slave - for the sake of simplicity we only discuss here the first latch). This node is tagged in the database as a Latch node (see .cnv file).

Each Latch node is controlled by Command transistors. Here the Command transistors for node master are tn0 and tp0 - they control the writing of the data - and tp1 and tp2 - they control the reset of the latch.

7. 5. 1. Asynchronous Set and Reset

The modeling of static latches can be refined in order to cope with the set and reset signals. This is controlled by yagSetResetDetection, and disabled by default (set to no). Whwn set to yes, the transistor tp1 is no longer considered to be a command and tp2 is marked Async. This prevents the construction of asynchronous timings arcs between the reset signal and memory node - between RN and master here - which otherwise clutter the reports.

7. 5. 2. Manual Configuration

The following manual configuration would lead to the same modeling as the one generated by the automatic detection. We present it as an example of what should be done in order to model latches which would not be automatically recognized. The following lines describe the configuration to be used for tagging the masterLatch node and associated Command transistors.

inf_MarkSignal master Latch+Master
inf_MarkTransistor tn0 Command
inf_MarkTransistor tp0 Command
inf_MarkTransistor tn1 Feedback+NonFunctional
inf_MarkTransistor tn2 Feedback+NonFunctional
inf_MarkTransistor tn3 Feedback+NonFunctional
inf_MarkTransistor tp1 Command+NonFunctional
inf_MarkTransistor tp2 Command
inf_MarkTransistor tp3 Feedback+NonFunctional

HITAS performs latch-based analysis, so the MASTER tag is optional

Timing Arcs

HITAS constructs the following timing arcs:

DATA: D (R) -> master (F), enabled by ICKN (R) 
DATA: D (F) -> master (R), enabled by ICK (F)
ACCESS: ICK (F) -> master (R)
ACCESS: ICKN (R) -> master (F)

7. 5. 3. Intrinsic Setup and Hold

Setup and hold timing checks are performed at the memory node itself - the master node. For both setup and hold timing checks, HITAS also adds correction margins which further ensure the robustness of the analysis. These margins are called intrinsic setup and intrinsic hold times.

SETUP: master (R) -> ICKN(R) - closing event of the command 
SETUP: master (F) -> ICK(F)
HOLD: master (R) -> ICKN(R) - closing event of the command 
HOLD: master (F) -> ICK(F)

Intrinsic Setup

For setup, HITAS checks that the latest possible switching time of the memory node - caused by the switching of the data - occurs before the earliest possible closing time of the latch in the next cycle - here the earliest time between ICK rising and ICKN falling - so that the data is always memorized in the next cycle. This reads:

D->mastermax < min(CK->ICKNmin, CK->ICKmin) + cycle_time

The setup slack is then defined as:

Setup_slack = min(CK->ICKNmin, CK->ICKmin) + cycle_time - D->mastermax

Or in a simpler way:

Setup_slack = clock_path_min + cycle_time - data_path_max

In fact, HITAS does not calculate the latest possible switching time of the memory node, but the latest possible switching time of the feedback node, further ensuring that the data has been properly stored in the latch. This gives:

D->mastermax + master->feedback < min(CK->ICKNmin, CK->ICKmin) + cycle_time

The setup slack is then defined as:

Setup_slack = min(CK->ICKNmin, CK->ICKmin) + cycle_time - D->mastermax - master->feedback

Or in a simpler way:

Setup_slack = clock_path_min + cycle_time - data_path_max - intrinsic_setup

From a modeling point of view, this translates to the addition of a setup timing arc, between the memory node and each of the signals driving a gate of a command transistor, whose value is the propagation delay between the memory node and the feedback node.

Intrinsic Hold

For hold, HITAS checks that the earliest possible switching time of the memory node - caused by the switching of the data - occurs after the latest possible closing time of the latch in the same cycle - here the latest time between ICK rising and ICKN falling - so that no other data is accidentally memorized in the same cycle.

D->mastermin > max(CK->ICKNmax, CK->ICKmax)

The hold slack is defined as:

Hold_slack = D->mastermin - max(CK->ICKNmax, CK->ICKmax)

Or in a simpler way:

Hold_slack = data_path_min - clock_path_max

Actually, HITAS does estimates latest possible closing time of the latch not at Vdd/2, as it is done for all other propagation delays, but at the Vt of the Command transistors. This assumes that the data may still be stored, even if the Command transistors are in a low-conducting mode. Preventing this adds robustness to the analysis.

D->mastermin > max(CK->ICKNmax, CK->ICKmax) + max(slopeICKN vdd/2->vt, slopeICK vdd/2->vt)

The hold slack is defined as:

Hold_slack = D->mastermin - max(CK->ICKNmax, CK->ICKmax) - max(slopeICKN vdd/2->vt, slopeICK vdd/2->vt)

Or in a simpler way:

Hold_slack = data_path_min - clock_path_max - intrinsic_hold

From a modeling point of view, this translates in the addition of a hold timing arc, between the memory node and each of the signals driving a gate of a Command transistor, which value is the portion between Vdd/2 and Vt of the slope on the signal driving the gate.

7. 6. RS-Latches

HITAS automatically recognizes and models NAND-based and NOR-based RS structures. Only the RS structures where NAND or NOR building gates directly loop on each other (with no intermediary inverter or buffer present) are automatically recognized. However, manual recognition is still possible, and the same range of modeling methods can be applied on manually-defined RS structures.

Automatic recognition of RS structures is enabled by switching on the variable yagAutomaticRSDetection:

avt_config yagAutomaticRSDetection mark

This enables HITAS to detect NAND-based and NOR-based RS structures having an arbitrary number of inputs, providing that the constituent NAND or NOR gates loop directly onto each other. Below is an example of such a structure.

With this configuration, HITAS only marks the looping nodes as RS (see .cnv file), and issues a message in the .rep file. For this NOR-based RS structure, the following timing arcs are then created:

S (rising) to QB (falling)
S (falling) to QB (rising)
R (rising) to Q (falling)
R (falling) to Q (rising)
Q (rising) to QB (falling)
Q (falling) to QB (rising)
QB (rising) to Q (falling)
QB (falling) to Q (rising)

This leads to combinational loops the tool is not able to handle, for example:

S (rising) to QB (falling) to Q (rising) to QB (falling) to ...

The study of the truth tables of the NOR gate tells us that such loops actually cannot occur, as some transitions cannot be excited. We will detail this in the next section. Regarding NAND-based RS structures, here is an example of what HITAS properly detects:

Here, the created timing arcs are the following ones:

S (rising) to Q (falling)
S (falling) to Q (rising)
R (rising) to QB (falling)
R (falling) to QB (rising)
Q (rising) to QB (falling)
Q (falling) to QB (rising)
QB (rising) to Q (falling)
QB (falling) to Q (rising)

They also lead to combinational loops.

7. 6. 1. Modeling of NOR-based structures

All States Allowed

Let's study the truth table of the NOR-based design:

Let's consider the timing arcs from Q to QB. As stated above, we have the following timing arcs, which we can also identify from the truth table:

Q (rising) to QB (falling)
Q (falling) to QB (rising)
QB (rising) to Q (falling)
QB (falling) to Q (rising)

Now we must keep in mind that we are dealing with NOR gates, and that a NOR propagates a transition from one of its inputs only if the others inputs are all 0. In a situation where NOR gates are looped on each others, some transitions cannot be excited. If we look at the truth table above, we see that the only way to have Q (rising) is to perform the set operation, where S is 1 and R is 0. But if S is now 1, no transition can propagate through the NOR gate: Q (rising) to QB (falling) can never be excited.

We have the symmetrical situation for QB (rising) to Q (falling) in the reset operation. The following timing arcs finally remain, and prevent the occurrence of combinational loops:

S (rising) to QB (falling)
S (falling) to QB (rising)
R (rising) to Q (falling)
R (falling) to Q (rising)
Q (falling) to QB (rising)
QB (falling) to Q (rising)

This way of modeling is enabled by switching the yagAutomaticRSDetection to "mark+illegal":

avt_config  yagAutomaticRSDetection "mark+illegal"

Legal States Only

The configuration described above only removes timing arcs that can never be excited. It allows timing arcs used when entering an illegal state: when both S and R are set to 1, Q and QB are both 0. It is the only situation where the NOR gate can have its R (resp. S) input set to 1 and its Q (resp. QB) input is set to 0, and thus propagate a falling transition from R or S:

S (falling) to QB (rising)
R (falling) to Q (rising)

Depending on the surrounding logic of the RS structure, this situation may or may not occur. However, the tool is not able to analyze it. If you desire to consider RS structures always remaining in the legal state, you should state it explicitly:

avt_config  yagAutomaticRSDetection "mark+legal"

Only the following transitions remain:

S (rising) to QB (falling)
R (rising) to Q (falling)
Q (falling) to QB (rising)
QB (falling) to Q (rising)

7. 6. 2. Modeling of NAND-based structures

All States Allowed

The same reasoning applies for a NAND-based structure, based on its truth table:

The NAND gate propagates a transition from one of its inputs only if the other inputs are all 1. Removing the unexcited timing arcs leads to the following arcs remaining:

S (rising) to Q (falling)
S (falling) to Q (rising)
R (rising) to QB (falling)
R (falling) to QB (rising)
Q (rising) to QB (falling)
QB (rising) to Q (falling)

Legal States Only

If only legal states are allowed, the following timing arcs remain:

S (rising) to Q (falling)
R (rising) to QB (falling)
Q (rising) to QB (falling)
QB (rising) to Q (falling)

7. 6. 3. Fine Tuning

The yagAutomaticRSDetection variable defines a global behavior for all the RS structures encountered and properly detected. However, one may wish to define a specific behavior for a given RS structure encountered. For example, on 100 RS structures in a design, 94 may be treated as always remaining in legal state, 4 may be treated as possibly entering an illegal state, and the 2 remaining ones may be treated as pulse generators. One should then wish to override a global configuration for given RS structures. It is therefore possible in HITAS with the inf_DefineRS Tcl command, as done in the following script, referring to the example above:

avt_config yagAutomaticRSDetection "mark+legal"
inf_DefineRS nand1.S illegal  
inf_DefineRS nand2.S illegal  
inf_DefineRS nand3.S illegal  
inf_DefineRS nand4.S illegal  
inf_DefineRS pulsegen1.S mark_only  
inf_DefineRS pulsegen2.S mark_only  

7. 6. 4. Manual Tuning

Situations arise where timing arcs should be removed manually: when RS structures are not automatically detected, and when they are used for purposes not covered by the modeling options described above (typically in pulse generators).

When RS structures are not properly detected, timing arcs should be removed in the same way they are removed when automatically handled. Arc removal should be done with inf_DisableTimingArc Tcl function. The following script describes manual removal of timing arcs for the NOR-based RS latch described above, in the "Legal States Only" situation:

inf_DisableTimingArc S QB du
inf_DisableTimingArc R Q du
inf_DisableTimingArc Q QB ud
inf_DisableTimingArc QB Q ud

7. 7. Symmetric Latches

HITAS considers latches symmetric when it is possible to write on both sides of the memorizing loop. Latches which fall into this category are symmetric pulldowns, symmetric bitcells and asymmetric pulldowns, as described below.

HITAS considers both sides - m and mb of the symmetric latc being Latch nodes. A supplementary Memsym tag is added on each Latch node. Timing checks - setup and hold - are performed on both sides of the symmetric latch.

Intrinsic setup and hold times are added on each Latch node in the same way as they are on a D-Latch Latch node. The next sections detail modeling of symmetric latches

7. 7. 1. Symmetric Pulldown

Typical Structure

Latch Nodes and Commands

The latch nodes are here m and mb. The Command transistors are the ones which gate is controlled by ck.

Timing Arcs

Timing arcs are the following:

DATA: D (R) -> m (F), enabled by CK (R) 
DATA: D (F) -> mb (F), enabled by CK (R)
DATA: m (F) -> mb (R) 
DATA: mb (F) -> m (R)
ACCESS: CK (R) -> mb (R) - through the feedback loop
ACCESS: CK (R) -> m (R) - through the feedback loop
SETUP: m (F) -> CK (F)
SETUP: mb (F) -> CK (F)
HOLD: m (F) -> CK (F) - closing event of the command 
HOLD: mb (F) -> CK (F)

As it is for the D-Latch, the intrinsic setup time is the propagation delay of the inverter between m and mb and m and mb - for Latch nodes m and mb respectively.

7. 7. 2. Symmetric Bitcell

Typical Structure

Latch Nodes and Commands

The latch nodes are here m and mb. The Command transistors are the ones which gate is controlled by ck.

Timing Arcs

Timing arcs are the following:

DATA: D (R) -> m (F), enabled by CK (R) 
DATA: D (F) -> mb (F), enabled by CK (R)
DATA: m (F) -> mb (R) 
DATA: mb (F) -> m (R)
ACCESS: CK (R) -> mb (R) - through the feedback loop
ACCESS: CK (R) -> m (R) - through th efeedback loop
SETUP: m (F) -> CK (F)
SETUP: mb (F) -> CK (F)
HOLD: m (F) -> CK (F) - closing event of the command 
HOLD: mb (F) -> CK (F)

The following timing arcs are disabled: the NMOS transistors drive only a weak current in the latch node - considering a rising transition on the latch node.

DATA: D (R) -> m (R), enabled by CK (R) 
DATA: D (F) -> mb (R), enabled by CK (R)

However, the contribution of the current through the NMOS is taken into account when evaluating the delays of the inverters in the loop. These delays are further used for computing intrinsic setup and hold times. HITAS just assumes that transitions on d and db are simultaneous.

7. 7. 3. Asymmetric Pulldown

Typical Structure

Latch Nodes and Commands

The latch nodes are here m and mb. The Command transistors are the ones which gate is controlled by ck.

Timing Arcs

Timing arcs are the following:

DATA: D (R) -> m (F), enabled by CK (R) 
DATA: D (F) -> mb (F), enabled by CK (R)
DATA: m (F) -> mb (R) 
DATA: mb (F) -> m (R)
ACCESS: CK (R) -> mb (R) - through the feedback loop
ACCESS: CK (R) -> m (R) - through th efeedback loop
SETUP: m (F) -> CK (F)
SETUP: mb (F) -> CK (F)
HOLD: m (F) -> CK (F) 
HOLD: mb (F) -> CK (F)

The following timing arc is disabled: the NMOS transistor drive only a weak current in the latch node m - considering a rising transition on the latch node.

DATA: D (R) -> m (R), enabled by CK (R) 

However, the contribution of the current through the NMOS is taken into account when evaluating the delay of the inverter between mb and m. This delay is further used for computing intrinsic setup and hold times.

7. 8. 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 yagMarkTristateMemory configuration variable.

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

7. 9. Special Elements

7. 9. 1. Transmission Gates

Transmission gate characterization is natively handled by HITAS, and most of the times it requires no additional configuration. However, there are some cases where correct characterization of the transmission gates depends on the functional behavior of the design, and therefore those cases can not be perfectly handled by static tool. The following diagram illustrates this typical case:

The difficulty here is to properly estimate the amount of capacitance C to be used for the computation of the propagation delay of the inverter 1. The value of this capacitance depends on the logic levels of P1 and P2 driving the transmission gates, while circuit is operating. It is then practically impossible for a static tool to determine exactly the amount of capacitance to be used, as C can change with different combinations of logic levels on P1 and P2. The best thing a static tool can do is to compute min and max capacitances, corresponding to 'all transmission gates closed' and 'all transmission gates opened'.

However, the combinations of logic levels on signals driving the transmission-gates may be limited, and may obviously not lead to the worst case situation, e.g. where all the transmission gates are opened. For example in the case of multiplexers or routing matrices, only one of N transmission gates is opened at a time. HITAS does not provide an automatic mechanism to detect those kinds mutual exclusion situations, but provides two variables to control them manually:

tasPathCapacitanceFactor globally controls the ratio of transmission-gates that can be opened at the same time, when determining the capacitance to be used to compute maximum propagation delays. Minimum propagation delays are computed with a ratio of 0.

tasSwitchCapacitanceFactor globally controls the ratio of transmission-gates that can be opened at the same time, when determining the capacitance to be associated with input connectors.

7. 9. 2. Transmission Gate Multiplexers

The detection of multiplexors is done purely algorithmically. The cone partitioning strategy implemented in HITAS 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.

7. 9. 3. Domino Precharge

The following configuration enables the automatic precharge detection algorithm.

avt_config yagDetectPrecharge yes

However, precharged elements and latches may present very similar structures, and it is not impossible that the tool mix up between them. In this case, it is more careful to define manually the pre-charged structures. Example is given for a precharged signal named pre1, within a design named my_design:

inf_SetFigureName my_design
inf_DefinePrecharge "pre1"
inf_DefineDirout "pre1"

In any case, the following configuration line should be added to enable HITAS to perform special treatment on the precharged signals.

avt_config tasTreatPrecharge yes

7. 10. Case Analysis

Case analysis, such as Scan Mode analysis or Functional mode analysis, is available in the HITAS 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

7. 11. Integrating External Timing Abstractions

The most straightforward way to integrate 3rd party abstractions is to preload them with avt_LoadFile function. In the following example, the transistor-level description of the sub-circuit mult is not available. A .lib file is used as substitution.

avt_LoadFile charac/mult.lib lib
avt_LoadFile cells/*.spi spice
avt_LoadFile my_design.spi spice
set fig [hitas my_design]

It is important that the mult sub-circuit is not among the sub-circuits loaded in Spice format, i.e. in the my_design.spi file. If the mult sub-circuit has been loaded in Spice format, it should be blackboxed, using either the BLACKBOX file mechanism or the avt_SetBlackBoxes Tcl function.

The BLACKBOX file mechanism works as follow:

As soon as a BLACKBOX file exists in one the directories reachable from HITAS (i.e. the directories specified by the avtLibraryDirs variable), HITAS systematically reads it and blackboxes all the sub-circuits it contains. No variable controls the effective blackboxing of the sub-circuits the BLACKBOX file contains. The mere presence of the BLACKBOX file presence is a sufficient condition.

If avt_SetBlackBoxes Tcl function is used, the BLACKBOX file mechanism is disabled.

If BLACKBOX file is required, the following line should appear in it:

mult

In addition, the following line should appear in the script:

avt_config tasTreatBlacboxHierarchically yes