E

---

Verilog Value Change Dump Stimuli

---

This chapter introduces the Verilog^® value change dump (VCD) and extended VCD (EVCD) file formats, as used in the Spectre^® circuit simulator, and provides illustrations to explain the signal information file.

The VCD file (ASCII format) contains information about value changes for selected variables in the circuit design. Spectre supports two types of VCD files:

• Four-state – represents variable changes in 0, 1, x (unknown or “not needed”) and z (tri-state) without providing strength information and port direction
• Extended – represents variable changes in all states and provides strength information and port direction
  For more information about EVCD file format, refer to “Enhanced VCD Commands”.

Processing the Value Change Dump File

To process VCD or EVCD files in Spectre, the following statements need to be specified in the netlist file:

Spectre Syntax

vcd_include “vcd_filename” “signal_info_filename” [autostop=yes|no]
[insensitive=yes|no]

SPICE Syntax

.vcd “vcd_filename” “signal_info_filename” [autostop=yes|no]
[insensitive=yes|no]

or

Spectre Syntax

evcd_include “evcd_filename” “signal_info_filename” [autostop=yes|no]
[insensitive=yes|no]

SPICE Syntax

.evcd “evcd_filename” “signal_info_filename” [autostop=yes|no]
[insensitive=yes|no]

Spectre replaces the end time in the .tran or tran statement with the time specified in the .vcd/.evcd file when autostop=yes (default is no). If no is specified, the simulation time specified in the .tran or tran statement remains unchanged. For more information on autostop, refer to the Transient Analysis (tran) section in the Spectre Circuit Simulator Reference manual.

Each vcd or evcd statement can only specify one VCD or EVCD file. If a netlist file needs to include multiple VCD or EVCD files, multiple vcd or evcd statements must be used. For example, if a netlist file contains three VCD files, it needs three vcd statements (use the same netlist file format for EVCD files).

Spectre Syntax:

Statement 1: vcd_include “file1.vcd” “file1.signal”

Statement 2: vcd_include “file2.vcd” “file2.signal”

Statement 3: vcd_include “file3.vcd” “file3.signal”

SPICE Syntax:

Statement 1: .vcd “file1.vcd” “file1.signal”

Statement 2: .vcd “file2.vcd” “file2.signal”

Statement 3: .vcd “file3.vcd” “file3.signal”

VCD and EVCD formats are widely used in digital circuit design and contain different kinds of information for transistor level simulation. You need to provide signal information, such as timing characteristics, voltage threshold, and driving ability of input signals for each VCD or EVCD file. Since VCD and EVCD formats are compatible, Spectre can share the same signal information file.

By default, Spectre handles the VCD and EVCD file content as case insensitive (insensitive=yes). Case sensitivity can be set using the insensitive=no option.

VCD Commands

• VCD File Format
• Definition Commands
• Data Commands

VCD File Format

Continuous Line

The continuous line symbol is the back slash (\) sign and is rarely used in the VCD file. The beginning of a card is indicated by the $command keyword (for example, .$var), and ends with the $end keyword. If an identifier is longer than 1024 characters, and does not fit into a single line, the \ sign must be used to continue the line.

$comment

$comment
 comments
 $end

Description

Comments need to be enclosed within the $comment and $end commands.

Example

$comment

This is a test line.

$end

Definition Commands

In the definition section, the VCD command keywords used to indicate the start of a card begin with a dollar ($) sign. VCD definition commands include: $comment, $date, $enddefinitions, $scope, $timescale, $upscope, $var, and $version. The end of a card is marked with an $end keyword. Multiple lines can be placed between the $command and $end commands.

Spectre supports the following VCD definition section commands:

• $date
• $enddefinitions
• $scope
• $timescale
• $upscope
• $var
• $version

$date

$date
 
date
 
$end

Description

The $date command is used to specify the date of the VCD file created. Spectre accepts this command card, but does not process it.

Example

$date May 7, 2001 $end

$enddefinitions

$enddefinitions $end

Description

The $enddefinitions command indicates where the definition section of the VCD file ends. This command card tells Spectre to treat the rest of the VCD file as the data section. If this command card is missing, Spectre parses the data section incorrectly and issues an error message.

Example

$enddefinitions $end

$scope

$scope
 
[scope_type] [scope_name]
 
$end

Description

The $scope command card switches from the current circuit level to a lower circuit level in the design hierarchy.

Example

$scope module module1 $end

It is important to note:

• Spectre ignores scope_type, but the command must still be specified to maintain consistency with standard VCD format.
• A matching $upscope card must be specified in the VCD file definition section to switch the scope back to the current scope.

$timescale

$timescale [number] [time_unit_prefix] $end

Description

The $timescale command is used to specify the time scale. This time scale applies to all time values in the VCD file, and to its signal information file. The default time is 1 ns.

Arguments

number	A positive double number
time_unit_prefix	The unit prefix. The following unit prefix symbols can be applied to any numerical quantities: a = A = 1.0e-18 F = f = 1.0e-15 G = g = 1.0e9 K = k = 1.0e3 M = m = 1.0e-3 N = n = 1.0e-9 P = p = 1.0e-12 T = t = 1.0e12 U = u = 1.0e-6 X = x = MEG = meg = 1.0e6 Y = y = 1.0e-24 Z = z = 1.0e-21

Example

$timescale 1 ns $end

or

$timescale 1ns $end

produces the same result, telling Spectre to set the time scale to 1 ns.

$upscope

$upscope $end

Description

The $upscope command card switches from the current circuit level to an upper circuit level in the design hierarchy.

Example

$upscope $end

$var

$var
 
[var_type] [size] [identifier] [reference]
 
$end

or

$var [var_type] [size] [identifier] [reference] [index_range] $end

Description

The $var command defines the bus to be dumped into the data section.

Arguments

var_type	The bus type (Spectre ignores this information)
size	Number of bits in this bus specified as a decimal number
identifier	The identifier used in the data section; it can be a or a combination of printable ASCII characters
reference	The name of the bus
index_range	The index range of the bus in the following formats: [MSI:LSI] [LSI:MSI] [index] if the size is 1 MSI, LSI, and index must be an integer

The name of the bit is a combination of the reference and the index.

Examples

In the following example

$var reg 4 % regA [0:3] $end

the names of the four bits in bus regA are regA[0], regA[1], regA[2], and regA[3]. The netlist file referencing these VCD sources must match these names.

In the next example

$var reg 1 & b [0] $end

the name of the bit is b[0]. The card defined a bit, not a bus, as a size of 1.

In the next example

$var reg 1 & c $end

the name of the bit is c.

In the next example

$var reg 4 % regA $end

the names of the four bits in bus regA are regA[3], regA[2], regA[1], and regA[0]. The netlist file referencing these VCD sources must match the names.

$version

$version version $end

Description

The $version command is used to specify the version of the VCD file created. Spectre accepts this command card, but does not process it.

Example

$version spectre B2001.2.10 $end

Data Commands

In the VCD data section, a time point that starts with a number (#) sign (for example, #100) indicates the beginning of a new card. This card continues until it reads the line before the next card (cards can have multiple lines). It can also contain data values and a command block. A command block begins with one of the following command keywords, $comment or $time_value, and ends with $end.

data

Description

Data is divided into two types that each have their own format:

• Bus data
• Bit data

The bus data is for buses defined by $var, with a size greater than one. The bit data applies to the bus defined by $var, with a size equal to one. The bus data format is Bvalue bus_identifier whereas the bit data format is value bus_identifier.

Examples

In the following example

b0101 %

the bus with identifier % (defined by $var) has a binary value of 0101.

In the next example

1&

the one bit bus with identifier & (defined by $var) has a binary value of 1.

The valid characters for specifying the value are: 0, 1, x, X, z, and Z. Of these characters, x and X are treated as 0 for the input signal, and do not need a vector check for the output signal. The z and Z characters are treated as floating to high-impedance for the input signal, and do not need a vector check for the output signal.

time_value

#time_value

Description

Each time value (point) is the beginning of a card in the data section.

Example

#100

Time value is equal to 100 time units (time unit is defined by $timescale).

Signal Information File

The signal directions are specified in the signal information file. To input signals, Spectre applies stimuli to the simulation. The values of the output signals are used to perform a vector check against the simulation results, and vector errors are generated if mismatches occur. The enable signals are required to control the bi-directional signal behavior as input or output signals. All other signals in the VCD or EVCD file, not specified in the signal information file, are ignored by the simulator (warning messages are issued for these signals, based on the scopes specified in the signal information file).

The time scale of the time related cards in the signal information file are controlled by the $timescale card in the VCD file. For example, if $timescale is set to 1 ns and .tdelay to 2, a delay of (2 * 1ns) occurs.

The signal name in the signal information file can be specified by using the bus name or a wildcard. The signal name specified in the VCD file is in bus/bit format. Table E-1 provides examples.

Table E-1 Signal Name in VCD File Corresponds to Signal Information File

VCD File	Signal Information File
P[0] ... P[15]	P[0:15]
P[0] ... P[15]	P[*]
Q[63:32] Q[31:0]	Q[63:0]

The example in Table E-2 shows an incorrect naming format.

Table E-2 Incorrect Naming Format in Signal Information File

VCD File	Signal Information File
A[0:15]	A[0:7] A[8:15]

Signal Information File Format

Comment Line

A comment line begins with asterisk (*) or dollar ($) signs.

Continuous Line

A continuous line is indicated by a plus (+) sign.

The maximum length of a line is 1024 characters. If a card is longer than 1024 characters, you need to use the continuous line for the card.

To process VCD and EVCD formats, the following signal characteristics need to be defined in the signal information file:

• Signal Matches
• Signal Timing
• Voltage Threshold
• Driving Ability

Signal Matches

In this section, the following statements define the signal matches between the VCD and analog netlist files, signal directions, and output vector check.

• .alias
• .scope
• .in
• .out
• .bi
• .chk_ignore
• .chkwindow

.alias

.alias
 
target_busname alias_name

Description

The .alias statement is used to modify the name of the signal bus in the VCD/EVCD file to match the signal name in the netlist file.

By default, Spectre maps the bus delimiter from "*[*]" in VCD file to "*<*>" in the analog netlist. For example, the default setting is as follows:

.alias *[*] *<*>

You can use the following alias statement to alias the VCD signal top.hier1.hier2.*[*] to SPICE top level *<*>:

.alias top.hier1.hier2.*[*] *<*>

Examples

The following example

.alias *[*] *[*]

tells Spectre to keep square brackets as the bus limiter in an analog netlist. This .alias statement is required because *[*] is mapped to *<*> by default (see Table E-3).

Table E-3 .alias *[*] [*] Names

Bus Name	Signal Name
a[0:3]	a[0], a[1], a[2], a[3]
vec[3:0]	vec[3], vec[2], vec[1], vec[0]

In the next example

.alias sig_*[*] vec_*<*>

tells the simulator to change the square brackets to angular brackets (see Table E-4).

Table E-4 .alias sig_*[*] vec_*<*> Names

Bus Name	Signal Name
sig_1[0:3]	vec_1<0>, vec_1<1>, vec_1<2>, vec_1<3>
sig_bus1[3:0]	vec_bus1<3>, vec_bus1<2>, ve_bus1c<1>, vec_bus1<0>

In the next example

.alias sig_* vec_*

tells the simulator to change the prefix of the signal names from sig_ to vec_ (see Table E-5).

Table E-5 .alias sig_* vec_ * Names

Bus Name	Signal Name
sig_1	vec_1
sig_2	vec_2

.scope

.scope
 
scope_name1 [scope_name2 ... scope_nameN]

Description

The .scope statement specifies the target scope located in the definition section of the VCD file. Only the signals defined in the specified scope are processed. Multiple .scope statements in a signal information file are supported.

Arguments

scope_name

The name of the scope specified in the VCD file by the $scope card.

Example

.scope module1 module2

tells Spectre to process the signal located in scope module1 and module2.

.in

.in
 
signal_name1 signal_name2 ... signal_nameN

Description

The .in statement defines the specified bus as the input bus.

Arguments

name	The name of the bus specified in the VCD file

Example

VCD file:

$var reg 4 % b [0:3] $end

$var reg 1 * a $end

$var reg 1 & c [4] $end

$var reg 4 % d [0:3] $end

Signal information file:

.in b[0:3] a c[4] d[*]

Defines b[0:3], a, c[4], and d[0:3] as the input signals.

.out

.out signal_name1 signal_name2 ... signal_nameN

Description

The .out statement defines the specified bus as the output bus.

Arguments

name	The name of the bus specified in the VCD file

Example

In the VCD File:

$var reg 4 % b [0:3] $end

$var reg 1 * a $end

$var reg 1 & c [4] $end

$var reg 4 % d [0:3] $end

In the signal information file

.out b[0:3] a c[4] d[*]

Defines b[0:3], a, c[4], and d[0:3] as the output signal.

.bi

.bi ‘enable_signal_expr’ signal_name1 signal_name2 ... signal_nameN

Description

The .bi statement defines the specified bus as the bidirectional bus.

The enable signal can be from a VCD/EVCD or an analog netlist file. When an enable signal is from an analog netlist file, it can also be defined as an output signal for a vector check or only used as an enable signal. If a VCD signal is used as an enable signal, it must be declared an input using the .in statement and located in the VCD file. Different from enable statements in the vector file, the logic voltage threshold of an analog enable signal is defined by the .voh and .vol statements.

The .alias statement can be used to perform name mapping for the enable signal. In hierarchical signal name mapping (.hier 1), a hierarchical structure for the analog netlist file is supported for the enable signal. A period (.) can be used as the hierarchical delimiter to specify the hierarchical signal, and the hierarchical delimiter can be mapped to other delimiters by the .alias statement.

Bit-wise logic operators are supported in an enable signal expression: & (AND), | (OR), ^ (XOR), and ~ (NOT). Additional operators can be created using a combination of the supported operators. The order of processing for the logic operators is NOT > AND > OR, XOR (OR and XOR are processed at the same time). You can use parentheses () around the operators to change the processing order.

Arguments

‘enable_signal_expr’	The expression for the enable signals. The bidirectional bus switches to output mode only when its value is high. You need to use single quotation marks ‘’ for enable signal expressions.
signal_name	The name of the bus specified in the VCD/EVCD file.

Examples

The following example

VCD file:

$var reg 4 % b [0:3] $end

$var reg 1 & en $end

Signal information file:

.bi en b[0:3] 

defines b[0:3] as the bidirectional signal, which is controlled by the en signal. When en is high, b[0:3] becomes the output signal.

In the next example

VCD file:

$var reg 4 * myBi [0:3] $end

$var reg 1 # en $end

Signal information file:

bi ~en myBi[0:3] 

defines myBi[0:3] as the bidirectional signal, which is controlled by the en signal. The enable signal is appended with a tilde (~) sign, so unlike the first example, the en is now high, myBi[0:3] becomes the input signal, and vice versa.

In the next example

VCD file:

$var reg 4 * myBi_1 [0:3] $end

$var reg 1 # en $end

Signal information file:

.hier 1

.bi ‘en & (ana_en1 ^ X1.ana_en2)’ myBi_1[0:3]

.voh 1.5 ana_en* X1.ana_en* 

.vol 0.8 ana_en* X1.ana_en*

defines myBi_1[0:3] as the bidirectional signal, which is controlled by the expression ‘en & (ana_en1 ^ X1.ana_en2)’. When the value of the expression is high, myBi_1[0:3] becomes the input signal, and vice versa. The .voh and .vol statements define the logic voltage threshold of the two analog enable signals.

.chk_ignore

.chk_ignore start_time end_time [signal_name1 ... signal_nameN]

Description

The .chk_ignore statement specifies a window used to ignore output vector checks for a VCD file. You can provide the signal names in order to apply this statement locally. In addition to hierarchical mapping, the hierarchical structure is also given in the signal names. The start_time and end_time arguments must be specified. To define multiple time windows for ignoring output vector checks, use multiple chk_ignore statements.

Arguments

start_time	Defines the start time for the window used to ignore the output vector checks (use the $timescale card in the VCD file to set the time scale).
end_time	Defines the end time for the window used to ignore the output vector checks. You can use end_time=-1 to ignore the entire transient time (use the $timescale card in the VCD file to set the time scale).

Example

VCD file:

$timescale 1ns $end

Signal information file:

.hier 1

.chk_ignore 0 100 X1.out1 Top.digital.pout[*]

.chk_ignore 300 500 X1.out1 Top.digital.pout[*]

.chk_ignore 0 -1 out[*]

tells Spectre to ignore the output vector check for signals X1.out1 and Top.digital.pout[*] in the time windows 0 ns to 100 ns and 300 ns to 500 ns, and to ignore the entire transient time for the signal out[*].

.chkwindow

.chkwindow start_time end_time steady [period=const [first=const] ] [ signal_name1 ... signal_nameN ]

Description

The .chkwindow statement specifies a window for output vector checking. Spectre only checks the signal states within this window. The signal states outside the window are ignored. The checks occur at every time point specified in the VCD/EVCD file or as defined by the period and first arguments.

Setting the period argument activates periodic window checking. If period is not defined, the first argument is ignored by the simulator.

Arguments

start_time	Defines the window start time at which the window starts at time vec_time-start_time. If the period argument is defined, vec_time is the first time point defined by the first argument, and the vector checks are repeated according to the value of period. If the period argument is not defined, vec_time is the time point defined in the VCD/EVCD file.
end_time	Defines the window end time at which the window ends at time vec_time+end_time.
steady = 0 | 1	If set to 0, then the vector check passes as long as the signal has reached the desired state once. If set to 1, then the signal remains in the desired state for the entire window period to pass the vector check.
period	Activates periodic window checking and defines its time period.
first	Defines the first check point for periodic window checking (only valid when the period argument is also defined).

Examples

In the following example

VCD file:

$timescale 1ns $end

Signal information file:

.chkwindow 5 5 0

The .chkwindow statement is set to 0, so the waveform passes the vector check (see Figure E-1).

Figure E-1 Vector Check with .chkwindow Set to 0

In the next example

VCD file:

$timescale 1ns $end

Signal information file:

.chkwindow 5 5 1

The .chkwindow is statement set to 1 and the signal remains at that state for the entire window period, in order to pass the vector check (see Figure E-2). If the signal matches Figure E-1, the vector check fails.

Figure E-2 Vector Check with .chkwindow Set to 1

In the next example

VCD file:

$timescale 100ps $end

Signal information file:

.chkwindow 5 5 1 period=100 first=20 p[*] out_* 

tells the simulator to activate periodic window checking for signals p[*] and out_*. The vector check points start at 2 ns and repeats every 10 ns.

In the next example

.hier 1

.chkwindow 5 5 1 first=20 X1.Xana.p[*] X1.Xdigital.Xcore.out_*

tells the simulator to ignore the first argument because a valid period argument has not been specified. The other arguments are used in the simulation.

Signal Timing

The signal timing characteristics (delay, rise and fall time) are defined in this section.

• .idelay
• .odelay
• .tdelay
• .tfall
• .trise

.idelay

.idelay time_value [signal_name1 ... signal_nameN]

Description

The .idelay statement specifies the delay time for the corresponding input signals. If a bidirectional signal is specified, this only applies to the input stage of the bidirectional signal. The default value is 0.0, if .idelay and .tdelay are not set.

Example

In the following example

VCD file:

$timescale 1ns $end

Signal information file:

.idelay 5

All input signals have a time delay of 5 ns.

In the next example

VCD file:

$timescale 100 ps $end

Signal information file:

.hier 1

.scope Xtop.XI1

.in a[0:3] b

.tdelay 0.1 Xtop.XI1.a* Xtop.XI1.b

The Xtop.XI1.a[0:3] and Xtop.XI1.b input signals have a delay time of 10 ps.

.odelay

.odelay time_value [signal_name1 ... signal_nameN]

Description

The .odelay statement specifies the delay time for the corresponding output signals. If a bidirectional signal is specified, this only applies to the output stage of the bidirectional signal. The default value is 0.0, if .odelay and .tdelay are not set.

Example

VCD file:

$timescale 1ns $end

Signal information file:

.odelay 5

All output signals have a time delay of 5 ns.

.tdelay

.tdelay time_value [signal_name1 ... signal_nameN]

Description

The .tdelay statement specifies the delay time for the corresponding input, output, and bidirectional signals. The default value is 0.0, if .tdelay, .idelay, and .odelay are not specified.

Example

VCD file:

$timescale 1ns $end

Signal information file:

.tdelay 5

All signals have a time delay of 5 ns.

.tfall

.tfall time_value [signal_name1 ... signal_nameN ]

Description

The .tfall statement specifies the fall time of the input signal. If .tfall is not specified, the default value is 0.1 n.

Examples

In the following example

VCD file:

$timescale 1 ns $end

Signal information file:

.tfall 0.1 

all input signals have a fall time of 0.1 ns.

In the next example

VCD file:

$timescale 1 ns $end

Signal information file:

.in a[0:3] b

.tfall 0.1 a[0:3] b 

input signals a[0:3] and b have a fall time of 0.1 ns.

.trise

.trise time_value [signal_name1 ... signal_nameN]

Description

The .trise statement specifies the rise time of the input signal. If .trise is not specified, the default value is 0.1 n.

Examples

In the following example

VCD file:

$timescale 1 ns $end

Signal information file:

.trise 0.1 

all input signals have a rise time of 0.1 ns.

In the next example

VCD file:

$timescale 1 ns $end

Signal information file:

.in a[0:3] b

.trise 0.1 a[0:3] b 

input signals a[0:3] and b have a rise time of 0.1 ns.

Voltage Threshold

As digital vector format, the voltage threshold for logic low and high can be specified using the following statements to convert the input vectors to stimuli or to perform an output vector check.

• .vih
• .vil
• .voh
• .vol

.vih

.vih voltage_value [signal_name1 ... signal_nameN]

Description

The .vih statement specifies the logic high voltage of the input signal. If .vih is not specified, the default voltage is 3.3.

You can also use a parameter name to specify the voltage. For example:

.vih pwr_vdd

The .vih statement also supports global and local specifications as well as expressions, as shown below.

.vih pwr_vdd

.vih pwr_vdd_cpu_sram r*cpu_sram[*]

.vih pwr_vdd *.08

Examples

In the following example

.vih 5.0

tells Spectre all input signals have a logic high voltage of 5.0.

In the next example

.in a[0:3] b

.vih 5.0 a[*] b

tells the simulator input signals a[0:3] and b have a logic high voltage of 5.0.

.vil

.vil voltage_value [signal_name1 ... signal_nameN]

Description

The .vil statement specifies the logic low voltage of the input signal. If .vil is not specified, the default voltage is 0.0.

Like .vih, .vil also support parameters, global and local specifications, and expressions.

Examples

In the following example

.vil 1.0

tells Spectre all input signals have a logic low voltage of 1.0.

In the next example

.in a[0:3] b

.vil 1.0 a[0:3] b

tells the simulator input signals a[0:3] and b have a logic low voltage of 1.0.

.voh

.voh voltage_value [ signal_name1 ... signal_nameN ]

Description

The .voh statement specifies the logic high voltage of signals defined as outputs and signals from the analog netlist file that are used in the signal information file. If .voh is not specified, the default voltage is 3.3.

Like .vih, .voh also support parameters, global and local specifications, and expressions.

Examples

In the following example

.voh 5.0

tells Spectre that all output signals have a logic high voltage of 5.0.

In the next example

.out out[0:3] outA

.voh 5.0 out[*] outA

tells the simulator output signals out[0:3] and outA have a logic high voltage of 5.0.

.vol

.vol voltage_value [signal_name1 ... signal_nameN]

Description

The .vol statement specifies the logic low voltage of signals defined as outputs and signals from the analog netlist file that are used in the signal information file. If .vol is not specified, the default voltage is 0.0.

Like .vih, .vol also support parameters, global and local specifications, and expressions.

Examples

In the following example

.vol 1.0

tells Spectre that all output signals have a logic low voltage of 1.0.

In the next example

.out out[0:3] outA

.vol 1.0 out[0:3] outA

tells the simulator output signals out[*] and outA have a logic low voltage of 1.0.

Driving Ability

For input stimuli, the output resistance of VCD/EVCD sources can affect Spectre results. To specify the driving ability of VCD/EVCD sources, use the following statements:

.outz

.outz 
resistance [signal_name1 ... signal_nameN]

Description

The .outz statement specifies the output resistance for corresponding input signals. If .outz is not specified, the default value is 0.01.

Example

.outz 1meg

All input signals have an output resistance of 1 Megaohm.

.triz

.triz
 resistance [signal_name1 ... signal_nameN]

Description

The .triz statement specifies the output impedance when the corresponding input signals are in tri-state. If .triz is not specified, the default value is 1,000 Meg.

Example

.triz 500meg

All input signals have an output impedance of 500 Megaohms.

Hierarchical Signal Name Mapping

Hierarchical signal name mapping can be used to precisely match signals between the VCD and analog netlist files, and is defined by Spectre hier statement:

.hier 0 | 1

Description

The .hier statement is used to specify hierarchical names in both the VCD and analog netlist files.

Arguments

hier

If hier=0, Spectre creates flat mapping between the VCD and analog netlist files (default). To maintain backward compatibility, the hierarchical delimiter is regarded as part of the signal name. If hier=1, the simulator applies the hierarchical names to the VCD and analog netlist files. The VCD file stimuli are no longer limited to the top level of the analog netlist file. In the VCD info file, the complete hierarchical structure needs to be added to the .scope statement (the hierarchical signals in the analog netlist file are mapped according to the information provided by the .alias statement).

The key differences between flat and hierarchical mapping include:

• To match hierarchical signals in the VCD file, the complete hierarchical structure needs to be specified in the .scope, .alias, and .chkwindow statements, as well as in the signal characteristic statements. For flat mapping, only the signal names are needed.
• For hierarchical signal name mapping, the statements to define the port direction of the signal are related to the .scope statement, which includes the .in, .out, and .bi statements. When using flat mapping, the multiple scopes defined by the .scope statement are regarded as set. Spectre searches all of the scopes to perform a signal match and outputs an error message when the same signal name is defined in more than one VCD scope.
• The hierarchical structure of the analog netlist file is specified by the .alias statement when performing hierarchical mapping.

Enhanced Statements

.scope and .in/.out/.bi

When using Spectre to apply hierarchical names to the VCD/EVCD and analog netlist files (.hier 1), the hierarchical structure in the VCD/EVCD file must be clearly defined with the .scope statement. The .in, .out, and .bi statements are used to define the signal name in the specified .scope statement and cannot contain the hierarchical structure. For the .bi statement, the enable signal needs to contain the hierarchical path because the signal may belong to a different scope.

The VCD/EVCD signal info file supports multiple .scope statements. The effective scope of each .scope statement is affected by the other statements, requiring the .in, .out, and .bi statements to be in the correct location.

Examples

In the VCD file:

$scope module top $end

$scope module digital $end

$var reg       1 !    din_1  $end

$var reg       1 "    en  $end

$scope module drv $end

$var reg       1 !    mid[1]  $end

$var reg       1 "    inout  $end

$upscope $end

$upscope $end

$upscope $end

In the VCD info file:

.hier 1

.scope top.digital

* The effective scope is top.digital

.in din_1 en

* The scope top.digital is ended by the next .scope statement

.scope top.digital.drv

* The effective scope is changed to top.digital.drv

.out mid[*]

.bi top.digital.en inout

.alias

.alias targ_signame alias_signame

The hierarchical structures that are defined in the .scope statement are used only for the VCD/EVCD file, so the .alias statement is needed to map the signals to the lower circuit levels of the analog netlist file.

Arguments

targ_signame	Specifies the hierarchical signal names (VCD/EVCD format) that are already defined in the .scope statement and .in/.out/.bi statements. The hierarchical delimiter is represented by a period (.).
alias_signame	Specifies the hierarchical signal names of the analog netlist file. The hier_delimiter option defines the hierarchical delimiter.

Examples

In the following example

.alias TOP.module1.in1 X1.in1

.scope Top.module1

.in in1

tells Spectre to map the TOP.module1.in1 defined in the .scope and .in/.out/.bi statements to the signal in1 of instance X1 in the analog netlist file.

In the next example

.alias *[*] *<*>

.alias Top.module1.sig_*[*] X1.vec_*<*>

.scope Top.module1

.out sig_[0:15]

.scope digital_block

.in datain[*]

tells the simulator for the Top.module1.sig_[0:15] signals, the second .alias statement overwrites the first .alias statement and maps the signals to X1.vec_<0>, ... X1.vec_<15>. Since only the first .alias statement matches the digital_block.datain[*] signals, they are mapped to digital_block.datain<*> of the analog netlist file.

In the next example

• Analog netlist file:
  

  Opt options hier_delimiter = %

• VCD/EVCD info file:
  

  .alias TOP.module1.sig_[*] X1%Xdrv%vec_<*>

  .scope Top.module1

  .out sig_*

Hierarchical Signal Names

For hierarchical mapping, the signal names in the .alias and .chkwindow statements, as well as in the signal characteristic statements, must have the hierarchical structure in the VCD file.

Examples

.hier 1

.chkwindow -1 5 1 Top.X1.out*

.vih 1.2 X1.in[*]

.vol 0.2 X1.dout1 Xdig.X2.dout1

.tfall 0.2 Xana.X1.in* Xdig.din*

.outz 100 X1.in[*]

Enhanced VCD Commands

Since the EVCD and VCD formats are similar, only the key EVCD format differences will be discussed in this section:

• Signal Strength Levels
• Value Change Data Syntax
• Port Direction and Value Mapping

Signal Strength Levels

Verilog HDL allows scalar net signal values to have a full range of unknown values, and different levels of strength or combinations of levels of strength. For logic operation, multiple-level logic strength modeling resolves combinations of signals into known or unknown values, allowing the behavior of hardware to be represented with improved accuracy.

EVCD signal strength can be defined by eight values, ranging from 0 (weakest) to 7 (strongest). The most commonly used values are 0 and 6. For example, for logic value 0

<0_strength_component> =6 , <1_strength_component> =0

and for logic value 1

<0_strength_component> =0 , <1_strength_component> =6

Spectre ignores the strength information (minimal impact on most CMOS circuit designs). If you want to preserve driver strength during simulation, specify .outz in the signal information file for specific signals with different output resistances.

For more information about logic strength modeling, refer to IEEE Std 1364-2001.

Value Change Data Syntax

The EVCD data command is different from the one used with VCD because the EVCD version can provide strength information and additional signal states.

data

p[port_value] [0_strength_component] [1_strength_component] [identifier_code]

Description

The value change section shows the actual value changes at each simulation time increment. Only variables that change value during a time increment are listed. In the EVCD file, strength information and a larger number of value states with port direction are presented in the value change section. The arguments for the EVCD data command are listed below.

Arguments

p	Key character that indicates a port. There is no space between p and port_value.
port_value	State character which contains information about driving direction and the value of the port. The state characters are described in “Port Direction and Value Mapping” (see tables).
0_strength_component	One of the eight Verilog strength values indicating the strength0 component of the value (Spectre ignores this value).
1_strength_component	One of the eight Verilog strength values indicating the strength1 component of the value (Spectre ignores this value).
identifier_code	The identifier code for the port, which is defined in the $var construct for the port.

Examples

The following example

pU 0 7 <0

tells Spectre that one bit bus with identifier <0 (defined by $var) has a binary value of U, and the strength of 0 component is 0 and the strength of 1 component is 7.

In the next example

pCCC 667 667 !

tells the simulator the bus with identifier ! (defined by $var) has a binary value of CCC, and the strength of 0 component is 667 and the strength of 1 component is 667. There is more than one driver on this port and the resolved value is CCC.

Port Direction and Value Mapping

The port value in the EVCD file contains port direction information, which helps Spectre distinguish some of the x states, apply stimuli for input signals, or perform a vector check for output signals.

input Direction

Given an DUT and a test fixture, the driving direction is input if the text fixture drivers are driving a non-tristate value and the drivers inside the DUT are tri-state. The resolved value is mapped in Table E-6.

When reading the mapping information in the following tables, it is important to note:

• Declared in and declared out indicates the signal is defined as input and output in the signal information file. The term active implies the drivers are in a non-tristate condition.
• Because the conflicting states of the signal value are converted to x in the VCD file, they are regarded as “not needed” and Spectre does not perform a vector check when the signals are specified as output.
• Combining the port direction for the signal value in the EVCD file and the specified direction in the signal information file, Spectre can distinguish the input and output values of a signal and perform a vector check when it is specified as output in the signal information file.
  

  Table E-6 input Value Mapping

  Port Value	Declared in	Declared out	Declared bi Enable = 0	Declared bi Enable = 1	Mapped VCD Value
  D	0 input	No check	0 input	No check	Low – only one active driver to the port
  d	0 input	No check	0 input	No check	Low – two or more active drivers to the port (may be conflicts, yet resolved value is low)
  U	1 input	No check	1 input	No check	High – only one active driver to the port
  u	1 input	No check	1 input	No check	High – two or more active drivers to the port (may be conflicts, yet resolved value is high)
  N	x input	No check	x input	No check	Unknown (not needed)
  n	x input	No check	x input	No check	Unknown (not needed)
  Z	z input	No check	z input	No check	Tri-state

output Direction

The driving direction is output if the driving value from drivers inside the DUT is non-tristate, but the value driven by the drivers in the test fixture is tri-state. The resolved value is mapped in Table E-7.

Table E-7 output Value Mapping

Port Value	Declared in	Declared out	Declared bi Enable = 0	Declared bi Enable = 1	Mapped VCD Value
L	z input	Check 0	z input	Check 0	Low – only one active driver to the port
l	z input	Check 0	z input	Check 0	Low – two or more active drivers to the port (may be conflicts, yet resolved value is low)
H	z input	Check 1	z input	Check 1	High – only one active driver to the port
h	z input	Check 1	z input	Check 1	High – two or more active drivers to the port (may be conflicts, yet resolved value is high)
X	z input	No check	z input	No check	Unknown (not needed)
T	z input	No check	z input	No check	Tri-state

unknown Direction

The driving direction is unknown if both the drivers in the test fixture and DUT are driving a non-tristate value. The resolved value is mapped in Table E-8.

Table E-8 unknown Value Mapping

Port Value	Declared in	Declared out	Declared bi Enable = 0	Declared bi Enable = 1	Mapped VCD Value
0	0 input	Check 0	0 input	Check 0	Low (input=0 and output=0)
1	1 input	Check 1	1 input	Check1	High (input=1 and output=1)
?	x input	No check	x input	No check	x (input=x and output=x)
A	0 input	Check 1	0 input	Check 1	x (input=0 and output=1)
a	0 input	No check	0 input	No check	x (input=0 and output=x)
B	1 input	Check 0	1 input	Check 0	x (input=1 and output=0)
b	1 input	No check	1 input	No check	x (input=1 and output=x)
C	x input	Check 0	x input	Check 0	x (input=x and output=0)
c	x input	Check 1	x input	Check 1	x (input=x and output=1)
F, f	z input	No check	z input	No check	Tri-state (input=z and output=z)

Enhanced VCD Format Example

The following is an example of EVCD file format.

$date

Jul 11, 2004 15:42:26

$end

$version

TOOL: ncsim 05.00-p001

$end

$timescale

1 ns

$end

$scope module board $end

$scope module counter $end

$var port [3:0] ! value $end

$var port 1  clock $end

$var port 1 # fifteen $end

$var port 1 $ altFifteen $end

$upscope $end

$upscope $end

$enddefinitions $end

#0

$dumpports

pXXXX 6666 6666 !

pN 6 6 "

pX 6 6 #

pX 6 6 $

$end

#5

pU 0 6 "

#10

pLLLL 6666 0000 !

pL 6 0 #

pL 6 0 $

#50

pD 6 0 "

...

Frequently Asked Questions

• Is it necessary to modify the VCD/EVCD file to match the signals?
• How can I verify the input stimuli?
• How do I verify the output vector check?
• Why should I use hierarchical signal name mapping?
• What is the difference between CPU and user time?

Is it necessary to modify the VCD/EVCD file to match the signals?

You can adjust the signal information file to match signals in the VCD/EVCD file with those in the netlist file, and leave the VCD/EVCD file unchanged. Spectre only needs the scopes specified in the .scope statement and ignores the other scopes (the simulator also ignores the parent or child scope of the specified scope). The .alias statement can be used to map the signal names between the VCD/EVCD and circuit netlist files.

How can I verify the input stimuli?

As digital vector format, first probe the signals in the top-level using .probe tran v(*) depth=1 and check the waveform outputs with the Virtuoso Visualization and Analysis or SimVision viewers.

Review the log file to check if the signals defined in the digital vector file match those defined in the analog netlist file.

• If the signal is in the specified scope of VCD/EVCD, but not in the VCD info file, a warning message appears.
• If the signal is in the specified scope of VCD/EVCD and in the VCD info file, but not in the analog netlist file, a warning message appears.
• If the signal is in the analog netlist file, but does not match the one in VCD/EVCD, check the list of dangling nodes or no DC path to the ground.

How do I verify the output vector check?

A <netlistName>_<tranName>.veclog file is generated at the location specified by Spectre option-raw statement if there are any vector checks. A <netlistName>_<tranName>.vecerr file is also generated when errors occur during the vector check. Refer to these two files for detailed information about the vector check. Here, <netlistName> refers to the name of the netlist and <tranName> refers to the name of the transient analysis.

When the signal is defined in both the VCD/EVCD files and the VCD info file, but not in the analog netlist file, the simulator issues a warning message.

Why should I use hierarchical signal name mapping?

Flat signal name mapping works for most situations, but suffers from the following limitations:

• Only the signals in the top level can be mapped to the VCD file (analog netlist file).
• When multiple .scope statements are used in a digital VCD file, Spectre treats them as a single set and searches for signals (as defined in the .in, .out, and .bi statements) in all of the .scope statements. An error occurs when a signal with the same name appears in more than one .scope statement.

Hierarchical signal name mapping is able to overcome these limitations, allowing you to map signals to the lower levels of the analog netlist file and to use multiple .scope statements (see “Enhanced Statements” for more information about .scope statements).

What is the difference between CPU and user time?

Description

• CPU time is the time the central processing unit (CPU) spends running the user program
• User time is the user and system times combined (that is, the total time needed to provide system service to the user program)

When running a simulation, Spectre stores the elapsed CPU and user time information in the STDOUT (standard output) or log file. The estimated completion time is based on linear interpolation of the user time from the start of the simulation. To view such information in STDOUT, set annotated=estimated in the tran statement.

Example

tran: time = 3.303 us    (82.6 %), step = 9.036 ps     (226 u%) 
cpu = 957402.0 s, elapsed = 190995.8 s, steps = 144244, mem = 45959.8 MB
estimated completion time:  10:12:07

Return to top