1. Input Files

1. 1. Technology File and Netlist

1. 1. 1. SPICE

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)

Expressions and Values

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

User-defined Functions

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) 

MOSFET

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

MOSFET Models

.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

JFET

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.

Junction Diode

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

Resistance

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

Capacitance

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

Subcircuit Instance

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

Independant Voltage Source

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.

Supported Voltage Sources: Scenario 1

.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

Supported Voltage Sources: Scenario 2

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

Supported Voltage Sources: Scenario 3

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

Supported Voltage Sources: Scenario 4

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

Supported Voltage Sources: Scenario 5

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

Supported Voltage Sources: Scenario 6

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

File Inclusion

.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

Subcircuit

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

Parameters

.PARAM {<param>=<val>|<expr>}

Temperature

.TEMP <val>|<expr>
.OPTION TEMP <val>|<expr>

Scale Factor

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

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

1. 1. 2. VERILOG

HITAS supports the structural subset of the Verilog Hardware Description Language. For more information see the IEEE P1364 standard

1. 1. 3. VHDL

HITAS supports the structural subset of the VHDL Hardware Description Language. For more information see the IEEE P1076 standard.

1. 2. Parasitics

1. 2. 1. DSPF Used for Connectivity

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

1. 2. 2. DSPF Used for Back-Annotation

If there is no BUSBIT construct, only identifiers containing [] or < > are considered as vectors.

1. 2. 3. SPEF

HITAS supports the Standard Prasitic Exchange Format Language, used for parasitic back-annotation putpose. For more information see the IEEE 1481-1999 standard.

1. 3. Timing Characterizations

1. 3. 1. Liberty

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.

1. 3. 2. TLF

HITAS supports the Cadence Timing Library Format versions 3 and 4, for integrating external timing characterization.

Supported TLF statements are:

1. 4. INF Design Specific Configuration

1. 4. 1. Description

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:

SDC input file

The SDC command will be translated in the appropriate information file sections.

User-defined INF file

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.

1. 4. 2. General

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;

1. 4. 3. Disassembly Directives

IGNORE

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.

CONSTRAINT

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;

MUTEX

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;

INPUTS

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;

STOP

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.

DIROUT

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.

DLATCH

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.

CKLATCH

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.

PRECHARGE

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

NOTLATCH

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

MARKSIG

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;

MARKTRANS

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;

1. 4. 4. Timing Directives

BREAK

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.

BYPASS

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.

FALSEPATH

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;

INTER

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;

PINSLOPE

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;

PATH DELAY MARGIN

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.

NOFALLING - NORISING

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;

CONNECTOR DIRECTIONS

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;

RC - NORC

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

NOCHECK
BEGIN
    sig;
    sig ALL;
    sig SETUP;
    sig HOLD;
    ...
END;
 

DONOTCROSS

Disables any path crossing specified latch or command.

DONOTCROSS
BEGIN
    sig1;
    sig2;
    ...
END;

1. 4. 5. Timing Abstraction Directives

Parameterization of Lookup Tables

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);

SLOPEIN

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;

CAPAOUT

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;

CLOCK CONNECTORS

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;

1. 4. 6. STA Directives

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.

General Header

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.

CLOCK CONNECTORS

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;

ASYNCHRONOUS CLOCK GROUPS

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.

EQUIVALENT CLOCK GROUPS

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.

MULTIPLE CLOCK PRIORITY

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.

SPECIFY INPUT CONNECTORS

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

VERIFY OUTPUT CONNECTORS

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.

Example of Stability Specification File

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;

1. 4. 7. Crosstalk Directives

CROSSTALK MUTEX

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.

1. 4. 8. Correspondencies INF / Tcl