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) |
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
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) |
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, 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 |
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> |
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
.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.
.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.
Yagle supports the structural subset of the Verilog Hardware Description Language. For more information see the IEEE P1364 standard
Yagle 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.
Yagle supports the Standard Prasitic Exchange Format Language, used for parasitic back-annotation putpose. For more information see the IEEE 1481-1999 standard.
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; |
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.
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.