1. Input Files

1. 1. Netlist

1. 1. 1. SPICE

The syntax of the SPICE subset supported by Yagle 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

Yagle 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, Yagle uses the HSPICE model. Otherwise, Yagle 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 Yagle 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 Yagle 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 Yagle 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>

Yagle 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 Yagle (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

Yagle 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

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

1. 1. 3. VHDL

Yagle 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

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

1. 3. INF - Design Specific Configuration

1. 3. 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. 3. 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. 3. 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. 3. 4. Behavioral Model Directives

SUPPRESS

The user can specify a list of signals which to be eliminated by Boolean simplification of the final behavioral description.

SUPPRESS
BEGIN
    sig1;
    sig2;
    sigs*;
    ...
END;

It is possible to use the wildcard '*' as for signal renaming.

SENSITIVE

This directive is useful in the case of functional abstraction with timing information. The user can specify a list of bussed signals for which the most precise timed behavioral model will be used. This is only required for certain critical signals.

SENSITIVE
BEGIN
    sig1;
    sig2;
    sigs*;
    ...
END;

It is possible to use the wildcard '*' as for signal renaming.

1. 3. 5. Correspondencies INF / Tcl