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.
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.
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 |
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.
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.
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.
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 |
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%.
Temperature can be deined either with the simTemperature configuration variable or through a .TEMP statement in the Spice file.
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.
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.
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.
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 |
The default configuration generates the .dtx file (timing arcs) and .stm file /9timing models).
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.
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 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 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.
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.
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.
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.
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) |
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) |
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.
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.
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.
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" |
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) |
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) |
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) |
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 |
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 |
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
The latch nodes are here m and mb. The Command transistors are the ones which gate is controlled by ck.
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.
The latch nodes are here m and mb. The Command transistors are the ones which gate is controlled by ck.
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.
The latch nodes are here m and mb. The Command transistors are the ones which gate is controlled by ck.
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.
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
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.
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.
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 |
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 |
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 |