The syntax of the SPICE subset supported by HITAS is given here in Backus-Naur Form. The meta-symbols of BNF are:
::= | meaning "is defined as" |
| | meaning "or" |
<> | angle brackets used to surround category names. The angle brackets distinguish syntax rules names (also called non-terminal symbols) from terminal symbols which are written exactly as they are to be represented. |
[] | Enclose optional items |
{} | Enclose repetitive items (zero or more times) |
A value is refered to as <val>. A value can be associated with the following units, and is scaled accordingly:
ff | 1e-15 |
pf | 1e-12 |
f | 1e-15 |
p | 1e-12 |
n | 1e-9 |
u | 1e-6 |
m | 1e-3 |
k | 1e+3 |
meg | 1e+6 |
mi | 25.4e+6 |
g | 1e+9 |
v | 1 |
ns | 1e-9 |
ps | 1e-12 |
s | 1 |
An expression is refered to as <expr>, and should appear enclosed in '', () or {}. Carriage returns are ignored within expressions and treated as white spaces, which means that an expression can be continued on subsequent lines without using the + sign.
The following mathematical functions supported within <expr> are valif, max, dmax, min, dmin, trunc, int, sqrt, exp, log, sin, cos, tan, asin, acos, atan, atan2, sinh, cosh, tanh, log10, ceil, floor, fabs, abs, pow and pwr
HITAS supports user-defined functions when specified through the .FUNC card. The example below illustrates the syntax supported:
.FUNC my_func(a,b) a*b+pow(2,a) |
Mxx <ND> <NG> <NS> <NB> <MNAME> [L=<val>] [W=<val>] + [AD=<val>] [AS=<val>] [PD=<val>] [PS=<val>] + {[<param>=<val>|<expr>]} [$X=<val>] [$Y=<val>] |
Parameters:
xx | MOS transistor name |
<ND> | Drain node |
<NG> | Gate node |
<NS> | Source node |
<NB> | Bulk node |
<MNAME> | Model name, described in a .MODEL card |
Optional parameters:
L=<val> | Channel length in meters (unless specified unit) |
W=<val> | Channel width in meters (unless specified unit) |
AD=<val> | Drain area in sq. meters (unless specified unit) |
AS=<val> | Source area in sq. meters (unless specified unit) |
PD=<val> | Drain Perimeter in meters (unless specified unit) |
PS=<val> | Source Perimeter in meters (unless specified unit) |
$X=<val> | X coordinate |
$Y=<val> | Y coordinate |
<param>=<val>|<expr> | Instantiation specific parameters, for example nrs, nrd, mulu0, delvt0, sa, sb, sd, nf, nfing, m |
If AD, AS, PD or PS are not specified, they are calculated with the GEOMOD parameter (only BSIM4, otherwise value is 0).
.MODEL <MNAME> <nmostype>|<pmostype> + [(] [<param>=<val>|<expr>] [)] <nmostype> ::= NMOS|NMOSBSIM3|NMOSBS32|NMOSBS4| + NMOSBS41|NMOSBS42|NMOSBS43|NMOSBS44|NMOSBS45|NMOSBS46 <pmostype> ::= PMOS|PMOSBSIM3|PMOSBS32| + PMOSBS4|PMOSBS41|PMOSBS42|PMOSBS43|PMOSBS44|PMOSBS45|PMOSBS46 |
MOS types
NMOS,PMOS | N-Channel, P-Channel MOSFET model |
NMOSBSIM3,PMOSBSIM3 | N-Channel, P-Channel BSIM3v3.0 Berkeley MOSFET model |
NMOSBS32,PMOSBS32 | N-Channel, P-Channel BSIM3v3.2.4 Berkeley MOSFET model |
NMOSBS4,PMOSBS4 | N-Channel, P-Channel BSIM4.0 Berkeley MOSFET model |
NMOSBS41,PMOSBS41 | N-Channel, P-Channel BSIM4.1 Berkeley MOSFET model |
NMOSBS42,PMOSBS42 | N-Channel, P-Channel BSIM4.2 Berkeley MOSFET model |
NMOSBS43,PMOSBS43 | N-Channel, P-Channel BSIM4.3 Berkeley MOSFET model |
NMOSBS44,PMOSBS44 | N-Channel, P-Channel BSIM4.4 Berkeley MOSFET model |
NMOSBS45,PMOSBS45 | N-Channel, P-Channel BSIM4.5 Berkeley MOSFET model |
NMOSBS46,PMOSBS46 | N-Channel, P-Channel BSIM4.6 Berkeley MOSFET model |
Supported BSIM and PSP levels:
LEVEL=8 | NGSPICE Berkeley BSIM3v3 model, up to BSIM3v3.2.4 (VERSION=32) |
LEVEL=49 | HSPICE BSIM3v3 model, up to BSIM3v3.2.4 (VERSION=32) |
LEVEL=53 | ELDO BSIM3v3 model, up to BSIM3v3.2.4 (VERSION=32) |
LEVEL=14 | NGSPICE Berkeley BSIM4 model, up to BSIM4.3 (VERSION=43) |
LEVEL=54 | HSPICE BSIM4 model, up to BSIM4.3 (VERSION=43) |
LEVEL=60 | ELDO BSIM4 model, up to BSIM4.3 (VERSION=43) |
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 |
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.
With no simToolModel variable set, HITAS uses the HSPICE model. Otherwise, HITAS interprets the parameters in the .MODEL statement with regard to the value of the simToolModel variable, and uses the model of the corresponding simulator.
The HSPICE BSIM3v3 model (LEVEL=49, simToolModel = HSPICE) used by HITAS deviates from the Berkeley BSIM3v3 model with regard to the following parameters (only if parameter ACM=0-3):
CJSWG | ignored, CJGATE used instead |
MJSWG | ignored, MJSW used instead |
PBSW | ignored, PHP used instead |
PBSWG | ignored, PHP used instead |
NF | the W of the is divided by NF to choose the appropriate model in the techno file |
The ELDO BSIM4 (LEVEL=60, simToolModel = ELDO) model used by HITAS deviates from the Berkeley BSIM4 model with regard to the initialization of the binning parameters of LPEB (lateral non uniform doping on K1):
LLEPB=0 | instead of LLEPB=LLPE0 |
WLEPB=0 | instead of WLEPB=WLPE0 |
PLEPB=0 | instead of PLEPB=PLPE0 |
NF | the W of the is not divided by NF to choose the appropriate model in the techno file |
The TITAN BSIM models used by HITAS are fully compliant with Berkeley BSIM models. The only special behavior relates to NF
NF | the W of the is not divided by NF to choose the appropriate model in the techno file |
Jxx <ND> <NG> <NS> <MNAME> {[<param>=<val>|<expr>]} + [$X=<val>] [$Y=<val>] |
Parameters:
xx | JFET transistor name |
<ND> | Drain node |
<NG> | Gate node |
<NS> | Source node |
<MNAME> | Model name, described in a .MODEL card |
Optional parameters:
$X=<val> | X coordinate |
$Y=<val> | Y coordinate |
<param>=<val>|<expr> | Instantiation specific parameters |
Warning: JFETs are parsed but are not suuported as transistors. They can only be interpreted as resistances. See avtSpiJFETisResistance.
Dxx NP NN MNAME [AREA=<val>] [PJ|PERI=<val>] + {[<param>=<val>|<expr>]} [$X=<val>] [$Y=<val>] |
Parameters:
xx | Diode name |
<NP> | Positive node |
<NN> | Negative node |
<MNAME> | Model name, described in a .MODEL card |
Optional parameters:
$X=<val> | X coordinate |
$Y=<val> | Y coordinate |
<param>=<val>|<expr> | Instantiation specific parameters |
Rxx N1 N2 [R=]<val>|<expr> [TC1=<val>|<expr>] + [TC2=<val>|<expr>] {[<param>=<val>|<expr>]} |
Parameters:
xx | Resistance name |
<N1>, <N2> | Resistance nodes |
[R=]<val>|<expr> | Value of resistance in Ohm |
Optional parameters:
TC1=<val>|<expr> | Parsed but not supported |
TC2=<val>|<expr> | Parsed but not supported |
<param>=<val>|<expr> | Parsed but not supported |
Cxx <N1> <N2> [C|VALUE=]<val>|<expr> [POLY=<val>|<expr>] + {[<param>=<val>|<expr>]} |
Parameters:
xx | Capacitance name |
<N1>, <N2> | Capacitance nodes |
[C|VALUE=]<val>|<expr> | Value of capacitance in Farads |
Optional parameters:
POLY=<val>|<expr> | Parsed but not supported |
<param>=<val>|<expr> | Parsed but not supported |
Xxx {<NN>} <MNAME> {[<param>=<val>|<expr>]} + [$X=<val>] [$Y=<val>] [$T=<Tx> <Ty> <R> <A>] |
Parameters:
xx | Instance name |
{<NN>} | list of nodes. Number must be the same as the subcircuit being instantiated |
<MNAME> | Subcircuit being instantiated |
Optional parameters:
$X=<val> | X coordinate |
$Y=<val> | Y coordinate |
$T=<Tx> <Ty> <R> <A> | Transform of the placement (X translation, Y translation, reflexion and rotation). Parsed but not supported |
<param>=<val>|<expr> | Instantiation specific parameters, updating subcircuit parameters |
Vxx <NP> <NN> DC [=] + <expr>|<pwl_function>|<pulse_function> <pwl_function> ::= PWL (<TN> <VN> {<TN> <VN>} [TD] [SHIFT=<val>]) <pulse_function> ::= PULSE (<V0> <V1> <TD> <TR> <TF> <PW> <PER>) |
Parameters:
xx | Voltage source name |
<NP> | Positive node. The node may be hierarchical, up to one level of hierarchy |
<NN> | Negative node. The node may be hierarchical, up to one level of hierarchy |
Piece Wise Linear function parameters:
<TN> | Time Ti in seconds (unless specified unit) |
<VN> | Value Vi of the source in volts at time Ti |
<TD> | Negative node |
SHIFT=<val> | Value added to all time values specified in the PWL card |
Pulse function parameters:
<VO> | Initial value in volts of DC voltage |
<V1> | Pulse magnitude in volts |
<TD> | Delay time in seconds (unless specified unit) |
<TR> | Rise time in seconds (unless specified unit) |
<PW> | Pulse width in seconds (unless specified unit) |
<PER> | Pulse period in seconds (unless specified unit) |
The PWL and PULSE functions can be used to define clocks as an alternative to the INF or SDC constraint files. However, care should be taken to ensure that enough of the waveform is specified for the parser to be able to deduce the rise/fall clock instants and the period.
The DC function can be used to specify power supply values. If the specified negative node is the node 0, or a node for which a supply value has been associated, then the supply value given by the sum of the DC value and the negative node supply value is associated to the positive node. Fairly complex multi-voltage configurations are possible, since multiple Vcards are possible and they can be resolved in any order.
The DC function, especially in combination with the .GLOBAL directive is a powerful mechanism for specifying which nodes are power supplies. Supplies can be completely determined using these cards without using any configuration variables. A node for which the supply value is superior to avtVddVssThreshold is considered to be a VDD node, else the node is considered to be a VSS node.
.GLOBAL inh_VDD inh_GND Vsup inh_VDD inh_GND 1.2V Vgnd inh_GND 0 0V .SUBCKT inv A B inh_VDD inh_GND MP0 B A inh_VDD inh_VDD PCH MN0 B A inh_GND inh_GND NCH .ENDS |
Vgnd GND 0 0V Vsup VDD GND 1.2V .SUBCKT INV A B inh_VDD inh_GND MP0 B A inh_VDD inh_VDD PCH MN0 B A inh_GND inh_GND NCH .ENDS Xinv0 A B VDD GND INV |
Vgnd GND 0 0V .SUBCKT INV A B inh_VDD inh_GND Vsup inh_VDD inh_GND 1.2V MP0 B A inh_VDD inh_VDD PCH MN0 B A inh_GND inh_GND NCH .ENDS Xinv0 A B VDD GND INV |
Vgnd GND 0 0V Vsup12 VDD GND 1.2V .SUBCKT INV A B inh_VDD inh_GND Vsup14 inh_VDD inh_GND 1.4V MP0 B A inh_VDD inh_VDD PCH MN0 B A inh_GND inh_GND NCH .ENDS Xinv0 A B VDD GND INV |
Vsup14 is ignored
Vgnd GND 0 0V Vsup12 VDD GND 1.2V Vsup14 VDD GND 1.4V .SUBCKT INV A B inh_VDD inh_GND MP0 B A inh_VDD inh_VDD PCH MN0 B A inh_GND inh_GND NCH .ENDS Xinv0 A B VDD GND INV |
Vsup12 is ignored
Vgnd Xinv0.inh_GND 0 0V Vsup12 Xinv0.inh_VDD 0 1.2V .SUBCKT INV A B MP0 B A inh_VDD inh_VDD PCH MN0 B A inh_GND inh_GND NCH .ENDS Xinv0 A B INV |
The following syntax is not supported:
Vsup12 Xinv0.inh_VDD Xinv1.inh_GND 1.2V
.LIB|.LIBRARY LNAME [<LIBTYPE>] .INCLUDE <FILENAME> |
HITAS has a limited support of relative paths: when the path is not absolute, the path is assumed to be relative to the working directory of HITAS (the directory where it has been invoked from). Contrary to other simulators, it is not assumed to be relative to the directory of the file which makes the inclusion. This limitation can be overwhelmed by the variable avtLibraryDirs
.SUBCKT <NAME> <NN> {<NN>} [PARAM:]{[<param>=<val>|<expr>]} {<component>} .ENDS [<NAME>] <component> ::= M|J|D|R|C|X|V|.SUBCKT|.LIB|.INCLUDE|.MODEL|.PARAM |
Parameters:
<NAME> | Name of the subcircuit |
<NN> | Node name. Nodes with the same name followed by period and number are considered to be on the same net, even if they are not connected in the subcircuit. For example, in .SUBCKT nand2 in out out.1 out.2 vss vdd out.3 the nodes out, out.1, out.2 and out.3 are considered to be the same signal. See also avtSpiMergeConnector and avtSpiConnectorSeparator. |
<param>=<val>|<expr> | Default parameters |
HITAS supports the declaration of subcircuits within subcircuits. However, if subcircuit A is defined within a subcircuit, instantiations of subcircuit A must not occur before in the file. This is not true if subcircuit A is defined at top-level.
.PARAM {<param>=<val>|<expr>} |
.TEMP <val>|<expr> .OPTION TEMP <val>|<expr> |
.SCALE <val>|<expr> |
Scales MOSFET parameters.
L=L*<val> | |
W=W*<val> | |
PD=PD*<val> | |
PS=PS*<val> | |
SA=SA*<val> | |
SB=SB*<val> | |
SD=SD*<val> | |
AD=AD*<val>*<val> | |
AS=AS*<val>*<val> |
.GLOBAL {node} |
When using the TCL interface, one should take care that the validity of .GLOBAL statement is limited to the context of the avt_LoadFile function call. For example, let's suppose a .GLOBAL statement defined in globals.spi, and a netlist defined in netlist.spi:
avt_LoadFile globals.spi spice avt_LoadFile netlist.spi spice |
With such a script, the .GLOBAL statement will not be available in netlist.spi. If it is not the intended behavior, prefer .INCLUDE globals.spi in netlist.spi.
HITAS supports the structural subset of the Verilog Hardware Description Language. For more information see the IEEE P1364 standard
HITAS supports the structural subset of the VHDL Hardware Description Language. For more information see the IEEE P1076 standard.
If the DSPF is used for connectivity purpose (the SPICE netlist is not connected without the DSPF, connectivity is ensured by the R elements), use .INCLUDE parasitics.dspf inside .SUBCKT
If there is no BUSBIT construct, only identifiers containing [] or < > are considered as vectors.
HITAS supports the Standard Prasitic Exchange Format Language, used for parasitic back-annotation putpose. For more information see the IEEE 1481-1999 standard.
HITAS supports the Liberty version 2000.11 (.lib) Open Source standard for integrating external timing characterization.
Supported statements are:
For more information see the Liberty User Guide.
HITAS supports the Cadence Timing Library Format versions 3 and 4, for integrating external timing characterization.
Supported TLF statements are:
The .inf file is an ASCII file with different sections. Blank lines, lines starting with '#' or any character between '/*' and '*/' are considered as comments. Most of the sections, except the header, are defined with a section name and the information related to this section are enclosed with Begin and End;. The syntax for each section depends on the section itself. The sections are not depending on each other so they can be declared out of order and several times.
The syntax is case insensitive for the keywords. The signal names can be given without quotes but to enable the use of signal names with special characters or unfortunately matching a keyword, they are required.
It is also possible to use units. For timing values with no specified unit, the Pico-second will be used. Valid units are: ps, ns, ms. For the capacitance values with no unit is specified, the Femto-farad will be used. Valid units are: pf, ff.
The information file gives information for the abstraction, database construction and static timing analysis tools. The information file name does not need to be related to a subcircuit name. In fact, the first token that should be set in the information file is "name" followed by the subcircuit name the information are given for. If this information is not given, the information file parser will guess the name of the subcircuit from the file name.
For a subcircuit, several information files can be given. They will be loaded in a particular order and the information will be merged. Actually, there are 2 different information files that can be generated by our tools and loaded, by default, with the following precedence:
The SDC command will be translated in the appropriate information file sections.
The order of loading and the files to load can be set by modifying the variable avtReadInformationFile. The files are separated by commas and the special character '$' will be replaced by the subcircuit name. Regular expressions can be used there to handle more complicated naming. Its default value is $.spice.inf,$.sdc.inf,$.inf. The '\' before the '.' simply indicates to the regular expression matching algorithm not to interpret '.' as any characters but as the character '.'. The names are from the less priority to the more priority. If the value is set to no, no information file will be loaded.
It is necessary to specify the design name. This is done by using the section "name". Optionally, a version for the information file can be given.
NAME mysubckt; VERSION 1.2; |
If some components must be removed from the original netlist for any reason, it is possible to specify the component type and names in the IGNORE section. Th ere are 4 component types: Instances, Transistors, Resistances, Capacitances. Th e component names can be given using regular expressions.
IGNORE BEGIN Instances: *fake, top.instancetoremove; Capacitances: toolowcapa*; ... END; |
At the moment, it is possible to remove resistances and capacitances only in the top level figure. To overcome this limitation, an information file can be wr itten for the sub-circuits.
To perform analysis in a specific case, the user can apply static logic levels on the input connectors with the CONSTRAINT section. It contains internal or external signals constrained by "one" or "zero". The static logic levels are propagated through the netlist before databse construction.
CONSTRAINT BEGIN sig1: 0; sig2: 1; sig3: 0; ... END; |
If some of the input connectors are mutually exclusive, this should be indicated in the MUTEX section using:
muxUP{term1, term2, ...} | to express that one port at most in the list is "one". |
muxDN{term1, term2, ...} | to express that one port at most in the list is "zero". |
cmpUP{term1, term2, ...} | to express that one and only one port in the list is "one". |
cmpDN{term1, term2, ...} | to express that one and only one port in the list is "zero". |
MUTEX BEGIN muxUP{a,...,d}; muxDN{m,...,p}; cmpUP{i,...,l}; cmpDN{x,...,z}; ... END; |
User can specify connectors which should be considered as inputs. The disassembling process uses this information to inhibit the construction of cone branches from these connectors. This directive is essentially useful when dealing with RAMs, when the user wants to inhibit the construction of the reading bus.
INPUTS BEGIN connector0; connector1; ... END; |
User can specify a list of signals which should be considered as stop points for the functional analysis phase of the disassembly. This means that any logic preceding the stop points will not be used in order to analyze the behavior of any gate following the stop point.
STOP BEGIN sig1; sig2; sigs*; ... END; |
It is possible to use the wildcard '*' as for signal renaming.
In order to orient transistors, user can specify a list of signals, each one identifying the source or drain of a transistor. Transistors are then oriented towards these signals. Orientation of successive transistors is done by associating a level with each signal identifying a source or drain. Transistors are then oriented from higher level signals to lower level signals.
Transistor orientation is useful to avoid false branches construction, especially when dealing with pass-transistors.
DIROUT BEGIN sig2: "1"; sig3: "2"; ... END; |
If no DIROUT level is specified, default level is -1.
It is possible to use the wildcard '*' as for signal renaming.
The DIROUT directive is equivalent to the NETOUTPUT directive in FCL. If a signal name is preceded by the '~' character then this signal will not be treated as an output, this is to deal with the case of signals whose names end in "_s" and must not be considered as output terminals.
Some internal tri-state nodes have to be considered to be dynamic latches for functional modeling and timing analysis purposes.
If only a few number of that tri-state nodes have to be taken into account, specify the list of corresponding signals into a DLATCH section. On the contrary, if the variable yagleMarkTristateMemory is set to yes in the configuration file and a few of tri-state nodes must not be taken into account, specify the list of corresponding signals into a DLATCH section, preceding each signal by a '~' character.
DLATCH BEGIN sig1; ~ sig2; ... END; |
It is possible to use the wildcard '*' as for signal renaming.
By default the latch recognition phase performed during the circuit disassembly does not require that external clocks be specified. Latches are identified either by structure (yagleStandardLatchDetection) or by Boolean analysis of combinatorial loop stability (yagleAutomaticLatchDetection).
However, it is sometimes necessary to constrain the latch recognition to identify only those latches for which the local clocks lie on a genuine clock path. To do this, specify the list of external connectors (or internal signals) in a CKLATCH section.
It is also possible to specify that an external connector (or internal signal) is definitely not a clock by preceding the name by a '~' character. In this case, any latch input at the end of a timing path originating from this connector (or signal) is considered to be a data input.
CKLATCH BEGIN connector1; sig1; ~ sig2; ... END; |
It is possible to use the wildcard '*' as for signal renaming.
Signals whose names end in "_p" are considered to be precharged and therefore dealt with differently by the tool. If any other signals should be considered precharged these can be specified in the PRECHARGE section.
PRECHARGE BEGIN sig1; ~ sig2; ... END; |
If a signal name is preceded by the '~' character then this signal will not be treated as a precharge, this is to deal with the case of non-precharge signals whose names end in "_p".
Disables the detection of latch on given signal.
NOTLATCH BEGIN sig1; ... END; |
If a signal name is preceded by the '~' character then this signal will not be treated as a precharge, this is to deal with the case of non-precharge signals whose names end in "_p".
Allows to set special markings on signals (nets). Especially useful for custom latch recognition. Available markings are:
LATCH | Signal corresponds to a latch memory-point. |
FLIPFLOP | Signal corresponds to a flip-flop memory-point. |
MASTER | Signal corresponds to the master memory-point of a flip-flop. |
SLAVE | Signal corresponds to the slave memory-point of a flip-flop. |
MEMSYM | Signal corresponds to one side of a symmetric memory. |
RS | Signal corresponds to one side of an RS bistable. |
VDD | Signal corresponds to an alimentation. |
VSS | Signal corresponds to ground. |
BLOCKER | No branch of a cone can go through the signal. |
STOP | Cannot exploit logic beyond this point for functional analysis in the disassembler. |
SENSITIVE | Marks the signal as a particularly sensitive signal. If a timed behavioral model of this signal is produced then the most precise (but cumbersome) model will be generated. |
Example:
MARKSIG BEGIN sig1: LATCH+MASTER sig2: STOP ... END; |
Allows to set special markings on transistors. Especially useful for custom latch recognition. Available markings are:
BLEEDER | Transistor corresponds to a bleeder. |
FEEDBACK | Transistor corresponds to a feedback transistor of a memory-point. |
COMMAND | Transistor corresponds to a command transistor of a memory-point, i.e driven by command signal. |
NOT_FUNCTIONAL | Transistor should be ignored when calculating gate functionality. |
BLOCKER | No branch of a cone can contain this transistor unless it is the first transistor of the branch. |
UNUSED | No branch of a cone can contain this transistor. |
SHORT | The transistor is considered short-circuited, the gate signal no longer contributes to the list of inputs. |
Example:
MARKTARNS BEGIN trans1: FEEDBACK+NOT_FUNCTIONAL trans2: COMMAND ... END; |
For the static timing analysis, verification of setup and hold constraints is only performed at reference points, i.e. external connectors, latch and precharge data input, latch and precharge command. However, it may be necessary to perform verifications on other points. These so-called break points are specified in the BREAK section.
BREAK BEGIN sig1; sig2; ... END; |
The break point mechanism can also be used to handle internally generated clocks, since a signal can be declared a break point and then declared a clock in the static timing analysis file.
To eliminate some critical paths, a BYPASS section should be used.
BYPASS BEGIN sig1; sig2 <; sig3 >; ... END; |
If a signal appears with no argument, the tool eliminates all paths which cross it. With the '>' argument, all paths which end on the signal will be suppressed and with the '<' argument, all paths beginning on the signal are suppressed. With the '!' argument, all paths passing through an input/output tri-state connector are suppressed.
During the static timing analysis, it is possible to specify that certain timing paths are false paths using the FALSEPATH section. Each line in this section describes a path to be ignored by the static timing analysis. A line is made up of the list of signals through which the path passes. The first signal in the list must be the start of a timing path and the last one must be the end of a timing path. It is possible to add the following tokens to the list in order to further constrain the path matching:
<UP> | must match rise transition on net given by preceding name. |
<DOWN> | must match fall transition on net given by preceding name. |
<VOID> | means signal given by preceding name must de directly followed by signal given by succeeding name. |
: <HZ> | at the end of the list means must match a high impedance transition at the end of the path. |
: <NOTHZ> | at the end of the list means must NOT match a high impedance transition at the end of the path. |
FALSEPATH BEGIN sig1 sig2 sig3; sig1 sig4 <UP> sig5 <DOWN>; sig1 sig2 sig6 <VOID> sig7; sig1 sig2 sig6 sig7 : <HZ>; ... END; |
In order to reduce the number of critical paths identified by the tool, it can sometimes be useful to specify that certain internal signals be considered as though they were reference points. The list of these intermediary points is specified in the INTER section. Correct choice of these points can lead to factorization of the critical paths, and hence a significant reduction in the size of the output file generated.
INTER BEGIN sig1; sig2; ... END; |
The PINSLOPE section describes the slopes to be applied on input connectors. Rise is the rising slope and fall is the falling slope. A single value is the slope applied for rising and falling. Slopes are given in Pico-seconds.
PINSLOPE BEGIN sig1: rise = 100 fall = 200; sig2: rise = 150 fall = 180; sig3: 200; default: rise = 120 fall = 140; ... END; |
It is possible to add an uncertainty margin to the paths, using the PATH DELAY MARGIN section. The modification is done by applying a factor and a delta to the path delay. So the new delay value is old_delay*factor+delta. The path delay won't be affected directly but the path margin will affect the stability analysis results.
The selection of the paths is done with the name of the signal at the end of the path and the type of the path: "clockpath", "datapath", "min", "max", "rise" and "fall". Mixing those values is possible. If the path type is not specified, all the paths arriving on the signal will be affected. The path ending signal can also be defined by a type: "latch", "prech" (precharge), "break" (breakpoint), "con" (connector) or "any".
PATH DELAY MARGIN BEGIN prech data_P: factor=1 delta=10ps; latch *: factor=1.1 delta=0 datapath max; any *sig*: factor=1 delta=-7 clockpath; ... END; |
The factor and the delta are needed and must appear in this order.
In certain cases, it is necessary to prevent the propagation of timing events, for example from glitch generators in which we are only interested in either the up or down event. The list of signals for which to suppress the down event is given in the NOFALLING section. The list of signals for which to suppress the up event is given in the NORISING section.
NOFALLING BEGIN sig1; sig2; ... END NORISING BEGIN sig1; sig2; ... END; |
If it is necessary to modify connectors direction in the timing database (DTX and TTX), the CONNECTOR DIRECTIONS section can be used. Connector names can be regular expressions. Supported connector directions are: Input, Output, InOut, Tristate, HZ, Unknown.
CONNECTOR DIRECTIONS BEGIN input: sig1, sig2; hz: sig3; ... END; |
To enable or disable RC delay calculations for individual signals, use the RC and NORC sections.
RC BEGIN sig1; sig2; ... END NORC BEGIN sig1; sig2; ... END; |
NOCHECK BEGIN sig; sig ALL; sig SETUP; sig HOLD; ... END; |
Disables any path crossing specified latch or command.
DONOTCROSS BEGIN sig1; sig2; ... END; |
Lookup tables defined for timing paths depend on input slopes and output capacitances. The SLOPEIN and CAPAOUT sections provide various means for specifying the ranges of slopes and capacitances applied on external connectors. Ranges can be set for selected connectors, but a default range can also be given, using the keyword 'default'. Ranges can be set by enumeration, using the syntax:
signal: (slope_0, slope_1, ... , slope_n); |
Ranges can also be set by specifying a lower bound, an upper bound, and a step, using the syntax:
signal: (lower_bound: upper_bound: step); |
The SLOPEIN section describes the slopes to be applied on input connectors. Slopes are given in pico-seconds.
SLOPEIN BEGIN sig1: (100, 400, 900, 1500, 2200, 3000); sig2: (100: 1000: 100); default: (100, 400, 900, 1500, 2200, 3000); ... END; |
The CAPAOUT section describes the capacitances to be applied on output connectors. To specify capacitances, a scaling factor is available. The range of capacitance can be given for specific length and width of transistors. The capacitances really applied on the connector are then scaled by the ratio between the given length and width, and the characteristic length and width of the transistors of the cell driving the pin. Capacitances are given in Femto-farads, lengths are given microns.
CAPAOUT BEGIN sig1: (0.7, 80.5, 190.0, 300.5); sig2: (0: 250: 25); default: (0.3, 38.5, 147.0, 311.5) L=0.18 W=0.6; ... END; |
Clocks must be declared in the information file in order to compute setup and hold constraints. These clocks are specified in the CLOCK CONNECTORS section.
CLOCK CONNECTORS BEGIN sig1; sig2; ... END; |
The eight sections in the information file concerning the stability information are:
A wildcard can be used for any of the specified node names. The character '*' matches any legal character string.
For example:
com* matches com1, com2, command, etc. |
The format of the header is as follows:
PERIOD <value>; SETUP <value>; HOLD <value>; |
The name is the name of the circuit the information are given for. The period is the default clock period for clocks whose period is not specified. SETUP and HOLD are additional constraints on setup and hold slacks verifications.
It is possible to omit the default period specification so long as each clock has a period associated with its definition or via the domain definition.
This section is used to define all the external clock signals. The waveforms at each external clock connector must be specified over a single period.
The syntax is as follows:
CLOCK CONNECTORS BEGIN {[ideal] [virtual] [!] <ck1>: down (<min>:<max>)|<value>; up (<min>:<max>)|<value>; [latency down (<min>:<max>)|<value>;] [latency up (<min>:<max>)|<value>;] [period <value>;]} END; |
For each of the external clock connectors, four parameters must be given: the earliest and latest instant of the falling edge, and the earliest and latest instant of the rising edge. The order is irrelevant. Actual values themselves are used to order the clock phases within the period.
It is not necessary to specify which of the clock edges corresponds to the reference phase. This is automatically detected by HITAS.
The period can optionally be specified here individually for all the clocks. If it is not specified here the clock must have a period via either a domain specification or a default period in the header.
If '!' is added before the clock specification, the values set for the rising and falling slope time of the clock will be swapped.
If 'virtual' is added before the clock specification, that indicates the clock is not associated to a real circuit connector.
If 'ideal' is added before the clock specification, that indicates no propagated delay will be considered for this clock. Nevertheless, the user can specify latency for each clock edge.
A clock can be define from the characteristics of another clock 'refclock', multiplying its period and/or shifting its edges. The syntax is as follow:
CLOCK CONNECTORS BEGIN { <ck2>: clock <refclock> [* <mult_factor>] [+|- <delta>];} END; |
This section allows the user to assign clock connectors to clock domains. Timing checks are only performed on paths which do not cross domain boundaries. Each domain must be given a name. However the name itself is purely informative.
The syntax is as follows:
ASYNCHRONOUS CLOCK GROUPS BEGIN {<domain1>: <clock1> [,<clock2>,...,<clockn>]; [period <value>;]} END; |
Each domain contains the list of clock connectors (defined in the clock specification section) which make up the domain.
The period of the clocks can be specified here, since clocks in the same domain must have identical periods.
This section allows the user to indicate that separate clock connectors should be treated as having identical phases.
The syntax is as follows:
EQUIVALENT CLOCK GROUPS BEGIN {<group1>: <clock1> [,<clock2>,...,<clockn>];} END; |
Each group contains the list of clock connectors (defined in the clock specification section) which make up the equivalent group.
This section allows the user to specify which clock should be considered as having the priority in the case of clocked signals (latches, flip-flops or precharges) which depend on multiple clocks.
Defining priority clocks is useful in the case of multiple clocks due to multiple operating modes (e.g. test mode or functional mode).
The syntax is as follows:
MULTIPLE CLOCK PRIORITY BEGIN {<clocked_signal>: <clock_connector>;} END; |
Each line associates a clocked signal with its highest priority clock connector.
This section is used to specify the stability intervals at the input terminals. If this section is omitted for any of the inputs, then they are assumed to become unstable at the earliest instant of the last phase and stabilized at the latest possible instant of the last phase.
The syntax is as follows:
SPECIFY INPUT CONNECTORS BEGIN {[<input> [rising|falling] [from <phase>]: unstable <value> [after|before <phase>]; stable <value> [after|before <phase>];]} | default [rising|falling] [from <phase>]: unstable <value> [after|before <phase>]; stable <value> [after|before <phase>]; END; |
For each input connector, the instants it becomes unstable and stable must be given. The phase of origin of the data can optionally be specified after the input connector name. A phase identifier has the format:
<ckname> [rising|falling] |
where ckname refers to a specified external clock. In the case of a clock for which the rising and falling edge refer to different phases, it is necessary to specify the edge, in order to uniquely identify the phase. By default the phase of origin is assumed to be the last phase.
The 'default' stability is used for all inputs for which the stability has not been explicitly specified.
The instants of stability and instability are specified in picoseconds. The values can either be absolute or relative to a specified phase. If the values are absolute then they are considered to be the result of the phase of origin. The values are specified relative to a particular phase using the keywords after and before. In general, you use the keyword 'after' to express that the relative time is as a result of the specified clock phase.
If the keyword 'before' is used, then the relative time is assumed to be for the preceding clock cycle (i.e. 'for' rather than 'as a result of' the specified phase).
This section is used to specify arrival times to be verified at output connectors. If this section is omitted for any of the outputs, then setup and hold slacks will not be calculated.
The syntax is as follows:
VERIFY OUTPUT CONNECTORS BEGIN {[<output> [rising|falling] [for <phase>]: unstable <value> [after|before <phase>]; stable <value> [after|before <phase>];]} | default [rising|falling] [for <phase>]: unstable <value> [after|before <phase>]; stable <value> [after|before <phase>]; END; |
The syntax is similar to the input connector stability specifications. However the phase specifications identify the phase for which the data is destined.
The times can be absolute or relative, as for the input specification. Here, however, since it is a destination phase which is specified, it can often be convenient to use the keyword 'before' to state that a time is 'relative to' and 'for' the specified phase.
Since this file must be provided by the user, an example is shown here for clarification.
name mycircuit; version 1.00; period 180000; setuptime 100; holdtime 200; CLOCK CONNECTORS BEGIN ck: up (90000:90100); down (10000:10100); END; CONDITIONED COMMAND STATES BEGIN com1: up; END; SPECIFY INPUT CONNECTORS BEGIN out1: unstable 1000 after ck rising; stable 3000 after ck rising; default: unstable 500 after ck rising; stable 4000 after ck rising; END; VERIFY OUTPUT CONNECTORS BEGIN out1: unstable 1000 after ck rising; stable 3000 after ck rising; default: unstable 500 after ck rising; stable 4000 after ck rising; END; |
During the aggression detection stage, it is possible to specify that only one signal can switch at the same time among a set of signals. Theses sets are specified in CROSSTALK MUTEX section :
CROSSTALK MUTEX BEGIN MUXUP {sig1, sig2}; MUXDN {sig3, sig4, sig5}; MUXUP {sig7, sig8, ..., sig12}; ...; END; |
In each MUXUP (MUXDN) section, only one signal in the list can rise (fall) at the same time. A signal can be listed at most in one MUXUP and in one MUXDN section. If two or more signals of a same mutex appear in the aggressor list of a signal, the one with the bigger coupling capacitance between the victim and this aggressor is considered to be switching at the same time.