GLS

Gate-level Simulation (GLS): A Quick
Guide for Beginners

Product Version 15.2
April, 2016
Copyright Statement
© 2016 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property of their respective
holders.
Learn more at Cadence Online Support - http://support.cadence.com

© 2016 Cadence Design Systems, Inc. All rights reserved worldwide. Page 2
Gate-level Simulation (GLS): A Quick Guide for Beginners
Contents
Purpose ....................................................................................................................... 4
Audience ...................................................................................................................... 4
Overview ...................................................................................................................... 4
Why GLS is needed? ................................................................................................... 5
Types of GLS ............................................................................................................... 6
Types of Delay Models ................................................................................................ 9
Setting up a GLS Flow for the First Time: An Example.............................................. 11
Disabling Timing Information ..................................................................................... 16
Basic Switches for GLS ............................................................................................. 19
GLS: The Most Common Issues and Resolutions ..................................................... 20
Warnings to look out for: ............................................................................................ 28
Summary ................................................................................................................... 32
Support ...................................................................................................................... 32
Feedback ................................................................................................................... 32

Purpose
This Application Note explains the basics of Gate-level Simulations (GLS) including why
it is required, the basic switches associated with it, and how to set up the GLS flow. This
document also discusses a few issues commonly faced during GLS runs and identifies
resolutions to the issues using the Cadence Xcelium simulator.
Audience
This document is aimed at verification engineers who are running gate-level simulations
for the first time, and also for beginners, in order for them to understand GLS better.
Overview
Gate-level simulation (GLS) is the simulation of a netlist, with or without gate delays, and
takes place after the synthesis of the RTL code, or post-P&R (placement & routing). RTL
simulation, which is the simulation of RTL code, aims to check and verify the functionality
and the source, which can be described in one or more HDL languages.
Gate-level simulation is used to check and ensure that the desired functionality is not lost
in the translation from high-level RTL to low-level gate implementation, and also when
timing is enabled, to ensure timing delays do not break the intended functionality.
Static Timing Analysis (STA) and Equivalence Checking (EC) have reduced the need for
GLS to some extent. However, so far, these static tools are not able to cover all the
verification needs. So GLS remains a significant step in the verification cycle.
The following sections in this document discuss multiple reasons why GLS is important
to verification engineers and the design verification process.

Why GLS is needed?

GLS can identify issues that Static Timing Analysis (STA) or logical equivalence tools are
not able to report. The following are some of the reasons why GLS is important in the
verification flow:
1. Overcoming the limitations of STA, such as:
a. The inability of STA to identify asynchronous interfaces. It is a good way to

check the critical timing paths of asynchronous designs that are not checked
by STA.
b. Static timing constraint requirements, such as those for false and multi-cycle
paths.
2. Verifying system initialization and that the reset sequence is correct.
3. Verifying that the power-up and reset operation of all power domains match the
power intent, and also to check that the design does not have any unintentional
dependencies on the initial conditions.
4. Revealing glitches on edge-sensitive signals due to combinational logic using both

worst-case and best-case timing information.
5. Performing DFT verification because scan-chains are inserted after RTL synthesis.
6. Verifying that clock-tree synthesis meets requirements.
7. Capturing switching factors for power estimation.
8. Analyzing X state pessimism or an optimistic view, in RTL or GLS.
9. Checking final performance to ensure that the design works at the desired
frequency, with actual delays in place.
This includes structural elements not checked by STA or formal engines, and
buffers or other elements added during place and route.
GLS also plays a vital role in Low Power verification. For more information on best
practices for using GLS for low power verification you can view the following document
from this article attachment section: Optimizing GLS for LP Sanity Checks

Types of GLS
Gate-Level Simulation can be either of the following three:
1. Zero Delay Simulation
2. Unit Delay Simulation
3. SDF Simulation (Simulation Delay File specifies timing)
Using zero delay simulation we can verify that the system initialization and reset
sequence, DFT verification, and also power up and reset operation of all power domains
are working correctly.
Clock tree synthesis, desired frequency verification, STA tool limitations, and revealing
glitches using best-case and worst-case timing information can all be verified by SDF
simulations.
1. Zero Delay Simulation
Zero delay simulation means simulating the netlist without annotating any timing data. It
is mainly meant for checking and validating the functionality of the design once it is
translated into a gate-level netlist. In zero delay simulation mode, specify block delays
are ignored.
These kinds of simulations are much faster than simulations with timing, and can be
started earlier in the design cycle, when the netlist is not yet frozen, or you do not have
timing information available.
Zero delay mode can be enabled using the -NOSpecify switch or by adding –
delay_mode Zero in command line. This option works for Verilog designs only and
disables timing information described in the specify blocks, such as module paths, and
delays and timing checks.
2. Unit Delay Simulations
Unit delay simulation operates on the assumption that all the elements in a circuit possess
identical delay time. Hence, providing any random delay value is similar to adding a unit
delay (1 time unit). This has the advantage that it is easier to implement than SDF
simulation.
However, zero delay simulation can induce false race conditions and zero-delay loops.
But, you can run unit delay simulation to detect and resolve genuine race conditions and
timing-sensitive loops.

In unit delay mode, simulator ignores all module path delay information and timing checks,
and converts all non-zero structural and continuous assignment delay expressions to a
unit delay of one simulation time unit. There are two ways to specify the delay mode to
unit delay mode:
 Use compiler directives in the source file to set delay modes specific to particular
modules: `delay_mode_unit
 Use the command-line plus options at compile time to set a global delay mode for
the simulation run: +delay_mode_unit
3. SDF Simulation
SDF Simulation is the actual delay simulation where the delay specified in the SDF file is
annotated into the design and all the timing checks are carried out. This type of simulation
takes time, and is much slower than zero delay or unit delay simulation.
An SDF file is output from the synthesis tool (Genus), the place & route tool (Innovus), or
the static timing analysis tool (Tempus). When the SDF file is delivered to verification
teams, the simulations are run using it and a gate-level netlist. The verification tool uses
the SDF and tries to annotate the delays contained in the SDF to the corresponding
instances/arcs in the netlist. This is also known as back-annotation.
During GLS simulations with SDF, you may encounter many annotation warnings that
need to be analyzed, and either sorted out, or waived, based on the type of warnings and
errors. The most important warnings that needed to be looked into are the ones that are
due to non-existent paths (SDF has an arc but netlists do not). Also, there can be a
mismatch between the simulation model specify block and library (.lib) of the
particular IP.
A typical SDF file contains a header section followed by one or more cell entries. For each
cell entry, you can specify delays, timing checks, and other constraints using a wide
variety of keywords. A simple syntax of the SDF file is as follows:

Delays can be annotated in the design in two ways.
a. Using the $sdf_annotate system task
By default, SDF annotation is performed during elaboration. The elaborator

recognizes the $sdf_annotate system tasks in your design source files. If the
$sdf_annotate system tasks are scheduled to run at time 0, and if they meet
other requirements, annotation is performed automatically.
b. Using a SDF command file
An SDF command file can be used if the annotation is to take place during
elaboration. This is an alternative to annotating at time 0 by using a
$sdf_annotate call. A command file can also be used to force elaboration-
time annotation if the $sdf_annotate system tasks in the design do not meet
the requirements for elaboration-time annotation.
For more information on the two methods, refer to the latest SDF Annotation Guide in our
product manuals.

Types of Delay Models

Delay models are mainly of two types:
1. Transport Delay Models
2. Inertial Delay Models
Transport Delay
Transport delay models propagate all signals to an output after any input signals change.
Scheduled output value changes are queued for transport delay models.
In other words, transport delay is meaningful with respect to devices that are modeled as
ideal conductors. For example, they may be modeled as having no resistance. In that
case, the waveform at the output is delayed but otherwise matches the waveform at the
input.
Transport delay can also be useful when modeling behavioral elements where the delay
from input to output is of interest, but there is no visibility into the behavior of delays
internal to the device.
Inertial Delay
Inertial delay models only propagate signals to an output after the input signals have
remained unchanged (been stable) for a time period equal to or greater than the
propagation delay of the model. If the time between two input changes is shorter than a
procedural assignment delay, a continuous assignment delay, or gate delay, a previously
scheduled but unrealized output event is replaced with a newly scheduled output event.
In other words, inertial delay is a measure of the elapsed time during which a signal must
persist at an input of a device for a change to appear at an output. A pulse of the duration
less than the inertial delay does not contain enough energy to cause the device to switch.

Simulator default delay modes differ. Simulators can provide command-line options, or
simulator-specific compiler directives, to manipulate the delay mode. Usually, inertial
delays are used for component delays, while transport delay is for interconnect delays.
We can set the delay behavior at elaboration. The Xcelium simulator default is to simulate
interconnect delays and module path delays as transport delays.
The following table shows how to enable transport delay behavior with pulse control using
some of the xmelab options, or through SDF construct.

Setting up a GLS Flow for the First Time: An Example

A typical GLS flow looks like the following flowchart:
The basic inputs for a GLS run are:
a) A gate-level netlist
b) Library cell information
c) Delay information contained in an SDF timing file
d) Testbenches to exercise the netlist
Included with this App Note, is a testcase tarfile named counter_gls.tar.gz which is a
simple counter design. You can download the testcase from the article attachemnt
section: counter_gls.tar
The example contains the following:
a. RTL source code : counter.v

b. Testbench : counter_test.v
c. Netlist : counter_netlist.v
d. Library : slow_vdd1v0_basicCells.v
e. SDF file : delays.sdf
f. A few run files to help you run the flow

In this document the counter example will be used to run zero delay and SDF Simulations.
In Zero delay mode, the delay in specify blocks and the SDF file will be ignored, and
delays will not be annotated to the design. Zero delay mode can be activated by adding
the –nospecify switch to the elaboration command line.
In SDF simulations, the delay information in the SDF file and library will be annotated to
the design and the functionality will be an almost exact replica of what it will be in silicon.
1. Running Zero Delay Simulation
You have to add the –nospecify switch to enable zero delay simulation.
The xrun command looks like the following:
xrun -clean counter_netlist.v counter_test.v –mess –access +rwc –v

slow_vdd1v0_basicCells.v -timescale 1ns/10ps -nospecify
Running this command will give you the following messages:
file: counter_netlist.v
module worklib.counter:v
errors: 0, warnings: 0
file: counter_test.v
module worklib.counter_test:v
file: slow_vdd1v0_basicCells.v
module slow_vdd1v0_basicCells.INVX1:v
module slow_vdd1v0_basicCells.NAND2BX1:v
module slow_vdd1v0_basicCells.NAND2X1:v
module slow_vdd1v0_basicCells.SDFFRHQX1:v
module slow_vdd1v0_basicCells.XNOR2X1:v
module slow_vdd1v0_basicCells.XOR2XL:v
primitive slow_vdd1v0_basicCells.altos_dff_r_err:v
primitive slow_vdd1v0_basicCells.altos_dff_r:v
Caching library 'slow_vdd1v0_basicCells' ....... Done
Caching library 'worklib' ....... Done
Elaborating the design hierarchy:
Top level design units:
counter_test
xmelab: *W,SDFSKPA: Ignore $sdf_annotate on line 12 file
./counter_test.v because of -nospecify option.
Building instance overlay tables: .................... Done
Generating native compiled code:
slow_vdd1v0_basicCells.SDFFRHQX1:v <0x6d3ba451>
streams: 0, words: 0
worklib.counter:v <0x42f99fd5>
worklib.counter_test:v <0x6a10ebfe>
Building instance specific data structures.
Loading native compiled code: .................... Done
Design hierarchy summary:
Instances Unique
Modules: 24 8
UDPs: 16 2
Primitives: 79 5
Registers: 12 7
Scalar wires: 29 -
Always blocks: 1 1
Initial blocks: 2 2
Cont. assignments: 0 1
Pseudo assignments: 4 4
Timing checks: 144 -
Delayed tcheck signals: 32 -
Simulation timescale: 10ps
Writing initial simulation snapshot: worklib.counter_test:v
Loading snapshot worklib.counter_test:v .................... Done
xcelium> source
/home/manashr/tools/xcelium/16.11/latest/tools/inca/files/xmsimrc
xcelium> run
In the messages, the warning noted in bold indicates that, due to the usage of
–nospecify, the $sdf_annotate() system task is ignored, and delays are not
annotated to the design.
If, instead of using the $sdf_annotate() system task, you use the use –sdf_cmd_file
command-line option, running the following will run a zero-delay simulation.
Note that most of the messages are similar to the messages shown earlier, but the
warning message is:
xmelab: *W,SDFIGN: Ignore -sdf_cmd_file because of -nospecify option.

2. Running SDF Simulation
In SDF Simulation, delays are annotated to the design, and different types of timing
checks are performed. Delays can be annotated by the Verilog system function
$sdf_annotate(), or with the xrun command line option –sdf_cmd_file. All delay
annotation occurs at elaboration time. However, if it is required to annotate delays during
simulation time, you have to use the –sdf_sim_time switch.
To run SDF simulation, use the following command (comment line 12 in

counter_test.v):
xrun -v slow_vdd1v0_basicCells.v counter_netlist.v counter_test.v -

mess -access +rwc -timescale 1ns/10ps -sdf_cmd_file sdf_cmd_file
The command using the $sdf_annotate() system task is:
xrun -v slow_vdd1v0_basicCells.v counter_netlist.v counter_test.v -

mess -access +rwc -timescale 1ns/10ps
Running the command displays the following messages:

file: counter_netlist.v
module worklib.counter:v
file: counter_test.v
module worklib.counter_test:v
file: slow_vdd1v0_basicCells.v
module slow_vdd1v0_basicCells.INVX1:v
module slow_vdd1v0_basicCells.NAND2BX1:v
module slow_vdd1v0_basicCells.NAND2X1:v
module slow_vdd1v0_basicCells.SDFFRHQX1:v
module slow_vdd1v0_basicCells.XNOR2X1:v
module slow_vdd1v0_basicCells.XOR2XL:v
primitive slow_vdd1v0_basicCells.altos_dff_r_err:v
primitive slow_vdd1v0_basicCells.altos_dff_r:v
Caching library 'slow_vdd1v0_basicCells' ....... Done
Caching library 'worklib' ....... Done
Elaborating the design hierarchy:
Top level design units:
counter_test
Reading SDF file from location "delays.sdf"
Annotating SDF timing data:
Compiled SDF file: delays.sdf.X
Log file: sdf.log
Backannotation scope: counter_test.counter1
Configuration file:
MTM control: MAXIMUM
Scale factors:
Scale type:
Annotation completed successfully...
SDF statistics: No. of Pathdelays = 57 Annotated = 100.00% --
No. of Tchecks = 144 Annotated = 77.78%
Total Annotated Percentage
Path Delays 57 57 100.00
$hold 8 0 0.00
$removal 8 8 100.00
$width 24 0 0.00
$recovery 8 8 100.00
$setuphold 96 96 100.00
Building instance overlay tables: .................... Done
Generating native compiled code:
slow_vdd1v0_basicCells.SDFFRHQX1:v <0x185260d9>
slow_vdd1v0_basicCells.SDFFRHQX1:v <0x36516d05>
worklib.counter:v <0x7f5d92ed>
worklib.counter_test:v <0x40a8df8d>
Building instance specific data structures.
Loading native compiled code: .................... Done
Design hierarchy summary:
Instances Unique
Modules: 24 8
UDPs: 16 2
Primitives: 79 5
Timing outputs: 22 4
Registers: 12 7
Scalar wires: 51 -
Always blocks: 1 1
Initial blocks: 2 2
Cont. assignments: 0 1
Pseudo assignments: 4 4
Timing checks: 144 19
Interconnect: 67 -
Delayed tcheck signals: 32 18
Simulation timescale: 10ps
Writing initial simulation snapshot: worklib.counter_test:v

Here, the annotation is 100% complete, so the delay is annotated to the design properly
and the timing checks are done.
In some cases, you may see that the timing checks are not 100% complete. In this case,
you can go through the timing check information provided in the specify block of the
library, and the delays the (SDF) files and debug why some checks are not being carried
out. The next section of this document will discuss more about how to selectively disable
a few or all of the timing checks.
If you use both the –sdf_cmd_file switch and the $sdf_annotate() system task, the
switch has higher precedence, and $sdf_annotate() system task will be ignored.
If you need to debug timing check failures or annotation failures, add the following two
switches (marked in bold) to get more detailed information about where to start from, and
where to look for information to fix those errors:
xrun -v slow_vdd1v0_basicCells.v counter_netlist.v counter_test.v -mess

-access +rwc -timescale 1ns/10ps -sdf_cmd_file sdf_cmd_file –sdf_verbose
–sdfstats file.txt
For more details on how to fix timing checks, error see the section titled GLS: Most
Common Issues and Resolutions.
Disabling Timing Information

Sometimes, you may not be interested in a timing violation from a certain portion of the
design at the SOC level. So, to resolve, this Xcelium has the capability of providing a
flexibility way to turn off timing checks for selected portions of the design. This helps in
improving performance.
A number of solutions exist to turn off timing checks:

1. Disabling Timing Checks Globally at Elaboration time
The Xcelium default behavior is to follow the timing description of the models. To disable
some or all timing information globally, use the following switches:
2. Disabling Timing Checks Locally at Elaboration time
This can be achieved by using a timing file. You have to add the –tfile <file_name>
elaboration switch. A timing file is a text file that lets you turn off timing for particular
instances or portions of a design.
A timing file consists of a set of lines:
 Each line pertains to:

o Specific instance(s) in the design
o Hierarchical portions of the design
 Each line begins with a keyword and must be terminated by a carriage return.
 Keywords are case-insensitive.
The following table contains the list of keywords:

If the HDL contains a $setuphold statement, and you have specified in the timing file to
disable the $setup timing check in the tfile, then the $setup portion of $setuphold is
disabled. In this case, any potential timing violation for the setup portion will not be seen
in the simulation run.
However, the reverse is not true. If the HDL contains a $setup or a $hold statement,
and the tfile contains a statement to disable the $setuphold timing check, then none of
the individual timing checks for $setup or $hold will be disabled. The same rules apply
to $recrem with respect to $recovery and $removal.
For the RETAIN SDF keyword and data that is a part of IOPATH constructs, the annotator
tool that runs during elaboration will ignore the RETAIN data, and, it can be disabled by
passing the -sdf_ignore_retain switch to xrun or xmelab.
The following is an example of a simple tfile:

3. Disabling Timing Checks Locally at Simulation Time
You can use the tcheck command to disable timing checks locally at simulation time.
The tcheck command turns timing check messages and notifier updates on or off for a
specified Verilog instance. The specified Verilog instance can also be an instance of a
Verilog module instantiated in VHDL.
Syntax:
tcheck <instance_path> -off | -on
Please note that using tcheck will not help improve performance. If you want to
improve performance then Cadence recommends that you use the tfile approach
instead.
Basic Switches for GLS

-anno_simtime Enable delay annotation at simulation time
-delay_mode <mode> Delay mode {Zero,PUnit,Unit,Path,Distr,None}
+delay_mode_distributed Use distributed delay mode
+delay_mode_none Specify no commandline delay modes
+delay_mode_path Use path delay mode
+delay_mode_punit Use precision unit delay mode
+delay_mode_unit Use unit delay mode
+delay_mode_zero Use zero delay mode
-gateloopwarn Enable potential zero-delay gate loop warning
-maxdelays Select maximum delays for simulation
-mindelays Select minimum delays for simulation
-ntcnotchks Generate NTC delay while removing timing checks
-no_tchk_msg Turn off timing check warnings
-no_tchk_xgen Turn off X-generation in VITAL timing checks
-nonotifier Ignore notifiers in timing checks
-nospecify Suppress timing information from specify blocks
-notimingchecks Do not execute timing checks
-noautosdf Suppress automatic SDF annotation
-nosdfstats_log Disable SDF annotation statistics logging
-tfile <file> Specify a timing file
-tfverbose Enables verbose mode for timing file matching.
-transport_int_delays Make interconnect timing be multisource capable
-pulse_e <arg> Set percentage of delay for pulse error limit
-pulse_int_e <arg> Set percent delay for pulse error limit
-pulse_int_r <arg> Set percent delay for pulse reject limit
-pulse_r <arg> Set percentage of delay for pulse reject limit
-races Run zero-delay race condition checks
-seq_udp_delay <arg> Specify a constant delay for sequential UDPs
-sequdp_nba_delay Add nba delay to zero-delay sequential UDP's
-sdf_cmd_file <file> Specify file of SDF annotation commands
-sdf_file <arg> Specify the SDF annotation file
-sdf_no_warnings Do not report SDF warnings
-sdf_simtime Allow SDF annotation during simulation
-sdf_verbose Include detailed information in SDF log file
-sdfdir <dir> Specify directory to be used for SDF compile
-sdfstats <arg> Write SDF annotation statistics to the given file
GLS: The Most Common Issues and Resolutions

Issue 1: Debugging 0-delay Loop in GLS
As previously discussed, in zero-delay mode there is a high probability that you may
encounter gate loops, and the simulation may become unresponsive. Usually, the
simulator gives the the folllowing warning:
xmsim: *W,TRZDGOC: Possible zero-delay gate oscillation detected
Here is an example that shows such a loop and how to resolve it. The following code will
generate one of these loops as it obviously oscillates after i1 goes from a 1 to 0 value:
top.v
--------
module top;
reg i1;
wire o1, o2;
buf b1 (o2, o1);

nor b2 (o1, o2, i1);
initial begin
$monitor($stime,, i1, o1, o2);
i1 = 1;
#10 i1 = 0;
end
endmodule
Observe that the flip-flop output (modeled with a UDP) updates in the same clock cycle
as the input data signal. A clock-cycle delay is expected to be present between the two
signal changes.

Using the -gateloopwarn and -access +c switches during elaboration (xmelab
command or xrun) will let the simulator detect such loops during simulation. In this case,
the simulator will interrupt the simulation and issue the warning message. The message
indicates that you should execute the following TCL command:
drivers –active
Sample output:
xcelium> drivers -active

[./loop.v, 7, top] buf b1 (o2, o1)
You can then examine the circuit network that involves the identified drivers and
determine what steps to take. In this case, adding a delay to the nor gate will cause the
simulation to move forward as the timing of the loop is solved, that is, it is no longer a
zero-delay loop.
Methods of adding delays to the design vary based on the circuit involved. Adding a delay
construct like #0.1, using SDF, UDP switches (-add_seq_delay, -seq_udp_delay, or -
delay_trigger for always blocks, avoid -delay_mode zero, and so on) can have an
impact on the particular looping behavior. However, merely adding a delay will not stop
the general oscillation of this circuit when i1 = 0. Some coding changes will be needed
to correct the design error.
The race conditions present in UDP-modelled flip-flops can be addressed using one of
the switches: seq_udp_delay, -sequdp_nba_delay or add_seq_delay. The
seq_udp_delay switch is documented in the Verilog Simulation User Guide. You can get
more help on add_seq_delay using the xrun -help command as follows:
UNIX> xrun -helpargs -helpverbose -add_seq_delay
You can visit our product manuals to learn more about SDF annotation methods:
For more details on how to resolve zero-delay gate loops or infinite loops, you can look
at the related article section of this article: “Resolving Infinite Loops in Zero-Delay
Mode Gate-Level Simulation”
Issue 2: Debugging an xmelab: *E, CUVUNF Error
When you use xmhelp as follows: xmhelp xmelab CUVUNF, the help prints:
The indicated hierarchical name could not be resolved. The name was
resolvable up to, but not including, the last component of the name
prefix printed in the error message.

The explaination is as follows: During synthesis, the design is flattened and hierarchies
in the design do not exist any more, except for the hierarchies explicitly preserved during
synthesis. If the test environment is accessing some hierarchy that exists in RTL, but not
in the netlist, then simulator reports this error during gate simulations.
There are two ways to resolve this:
1. Replace the hierarchical path names of the RTL with the corresponding nets (net
names) of the netlist in the testbench environment before running gate
simulations. The synthesis team can provide this information.
2. Provide the synthesis team with the paths accessed within the testbench
environment so that the synthesis team can keep these paths and hierarchies
preserved, while flattening the complete design during the synthesis cycle, then
the corresponding paths can be accessed in GLS.
The constraint that needs to be passed in RC (the Cadence Synthesis tool) is:
rc:/set_attribute preserve true object
Issue 3: Debugging an xmelab: *E, FLFFNF Error
When you use xmhelp as follows: xmhelp xmelab FLFFNF, the help prints:
The compiled SDF file specified in the SDF annotation command file
does not exist. The annotation command will be ignored.
This indicates that when using –sdf_cmd_file, the file provided in the compiled SDF file
does not exist. If you use $sdf_annotate(), the tool internally compiles the SDF file and
generates a compiled SDF file with the extension .sdf.X. However, if the SDF has not
been previously compiled, or if it is compiled into a different directory such that the tool is
unable to find it, the tool gives the error FLFFNF.
To resolve this error:
1. if the SDF file is already compiled, then specify the absolute path for the compiled
SDF file, in the SDF command file.
2. Otherwise, compile the SDF file using the SDF compiler. The command is:
xmsdfc <filename.sdf>
This command will generate the compiled SDF file into the current working directory with
a name filename.sdf.X. You can use this name in the SDF command file to correct the
error.
Note: Xcelium will automatically compile the SDF file if it has not been previously
compiled. Also, a new keyword has been added to the SDF command file: SDF_FILE,
which specifies the uncompiled SDF file name. The SDF file provided in the example
supplied with this document will be compiled automatically and you will not encounter the
error. It is always recommanded that you use use latest tool version in order to have new
features and better performance.
Issue 4: Debugging an xmelab:*W SDFNEP & *W SDFNET Error
The SDF annotator handles timing checks in the same way that the Xcelium Simulator
do. However, the annotator follows strict rules when it matches Verilog timing checks to
the corresponding SDF checks. The following two warnings appear whenever the
corresponding checks are not done.
SDFNEP says, “This path, including the condition, if any, does not exist
in the instance being annotated. The requested annotation will not
occur. In order to perform the annotation the information in the SDF
file must be updated to correctly match what is in the HDL description.”
SDFNET says, “This timing check, including conditions, if any, does not
exist in the instance being annotated.”
The SDF timing check translation rules are as follows:
1. If you specify a module path delay or timing check that does not already exist in
the Verilog model, the simulator cannot annotate the timing information.
2. If there is an edge specifier in an IOPATH statement in an SDF file, there must be

an exact match of the same edge specifier in the HDL model.
3. If there is an edge specifier in a TIMINGCHECK statement in an SDF file, there must

be an exact match in the HDL code.
4. If there is no edge specifier in an IOPATH or TIMINGCHECK statement in an SDF

file, the simulator annotates data to any path (or timing check) in the HDL code
that has the same reference, and to data nets specified in the SDF IOPATH or
TIMINGCHECK statement. Therefore, the non-edge specified IOPATH and
TIMINGCHECK SDF statements overwrite the corresponding edge-specified paths
and checks in HDL.
5. SETUPHOLD statements in your SDF file do not annotate data to the corresponding
but separate $setup and $hold statements in your Verilog code do. However,
you can use the +sdf_splitvlog_suh command-line option to cause the
SETUPHOLD checks in an SDF file to be split into their component SETUP and HOLD
checks, provided there are no negative values in those checks.

For more details on how to handle these two issues, refer to the following article under
related articles sections of this article: SDFNET or SDFNEP messages, causes and
cures
Issue 5: Debugging Timing Failures
Whenever there is a timing violation, the simulator issues a warning indicating there is a
timing failure in the design. The warning will point you the necessary details to debug the
failure. The message printed by tool appears similar to the following:
Warning! Timing violation

$setuphold<setup>( posedge CK:25 NS, negedge D:15330 PS,
10.09 : 10090 PS, 0.00 : 0 FS );
File: ./slow_vdd1v0_basicCells.v, line = 9817
Scope: counter_test.counter1.\count_reg[0]
Time: 25 NS
You can check any elaboration time warninge or the SDF annotation summary as first
checks to identify the problem.
Usually, there are two possible reasons for this warning:
1. There is a potential design problem.
2. The annotation is not proper.
If it is a design issue, follow these guidelines to debug it:
o The warning indicates that there is a timing violation on setup timing for setuphold
timing check at 25ns in the slow_vdd1v0_basiccells.v file at line 9817.
Inspecting line 9817 in the file shows that it has the following timingcheck:
$setuphold (posedge CK, negedge D, 0, 0, notifier,,, delayed_CK,
delayed_D);
It is clear from the warning message that the posedege of the clock is at 25ns and
the negedge of D is at 15.33ns. Check for this instance and send the signals to
the SimVision waveform window.
o In the waveform window, check whether the delay mentioned in SDF is reflected
or not. If it is, then this is a potential design problem and the setup window is
missed. Take the necessary measures to resolve the issue.
If the delay in SDF is not reflected in the waveform, it is a annotation problem. The tool
could not track the value from SDF and has taken it from the Verilog model. To debug
this, search the elaboration log (xmelab.log) and see if there is any warning for the

reported path annotation. You can use the –sdf_verbose and –sdfstats switches to
get more detailed messages and search for warnings. Once you know that the path is not
annotated, take the necessary measures to solve it, and the timing violation will
disappear.
Issue 6: Debugging a Glitch Suppression Error
Whenever the tool fails to suppress a glitch it issues a warning indicating that the glitch
suppression is cancelled, as shown in the following warning message:
Warning!
Glitch suppression Scheduled event for delayed signal of net "DD"
at time 6FS was canceled!
In this case, a schedule is cancelled when a delay schedules a transition to occur before
a previously scheduled transition. The message can only be generated for the negative
timing check delayed signals that have different rise and fall delays calculated.
In this case, it is possible for the input events to cause a scheduled output event to be
cancelled. To better understand what is going on:
1. Add the -ntc_verbose option to the invocation. For the signals of interest,
compare the calculated delays.
2. Monitors can be placed on the primary inputs for the delayed signals to see what
these signals are doing and to look at the input events on how they compared the
calculated delays for them.
3. If you want to see a glitch that happens in n FS, you will need to do this by observing
a waveform that is dumped with the event enabled solution.
Use the -nontcglitch switch when you run xmsim (three-step mode) or the
+ncnontcglitch switch when using xrun.
Issue 7: Debugging an Pulse Flagged Error
The following warning message can be caused by the use of the +pulse_r/0 and
+pulse_e/100 options. These options control when to report messages. In this case,
using 0% and 100%, any pulse that is smaller than the delay from the input to the output
of any gate is detected, and will report a warning.
Warning! Pulse flagged as an error, value = StE File: …/….v, line = 35,
pos = 6 Node: ….Z Time: 18754652 PS + 0

To suppress the display of error messages for pulses smaller than error percent, use the
-epulse_no_msg option to xmsim when you invoke the simulator.
Change the percentages to let different amount of glitches pass through. However, you
should consult whoever is in charge of the library for the recommended amount of pulse
rejection to set.
For more details on pulse_e and pulse_r, and how to control pulses using global pulse
control option in Xcelium, refer to following article in the related article section:
“An example, showing how -pulse_e, -pulse_r and -pathpulse can control pulse
behavior in a simulation”
Issue 8: Debugging When SDF Delays Do Not Appear in the Simulation or the
Waveform Display
The SDF file back annotates interconnect and path delays to a netlist. In the example
included with this document, the delay.sdf file annotates the counter_netlist.v
netlist. Sometimes while annotating, an input to output delay of zero on an instance can
be observed in the netlist, even when the SDF has an actual delay of, say, x ns.
There can be several reasons for delays not appearing in a waveform display:
1. Warnings like SDFNET or SDFNEP are present in the log file. Check the log file to
see if the SDF annotator gave any warnings at the time of annotation. If warnings
like SDFNET or SDFNEP are present, it is possible that a particular delay was not
annotated.
2. A pulse on an input is less than its path delay. In this case, the pulse will get
rejected by the instance. You can set the rejection and error limits on a pulse
to control how wide a pulse must be to propagate through a module. For example:
xmelab -pulse_r 0 -pulse_e 0

xrun -pulse_r 0 -pulse_e 0
3. You can generate an SDF logfile to check if the delay is actually annotated. The
following system task generates a log file named sdf.log:
$sdf_annotate("test.sdf", , , "sdf.log");
Use the -sdf_verbose option with xmelab or xrun to log every annotation
performed into the log file. The following is an example of an SDF log file:
sdf.log
.......
Time units: 1ps
.......
Annotating to instance top.inst.inst1 of module SDFFHX1_1
ABSOLUTE (IOPATH D Q) = (6)
4. It is possible that the sdf.log file correctly shows the annotation, but no delay
shows up in the waveforms. The reason for this could be the timescale/precision
settings. The default timescale for the simulator is 1ns/1ns. In the example, if
default timescale is used, 6ps is 0.006ns. This is much less than the default
precision of 1ns. In this case, the value will be rounded down to zero, and therefore
no delay in the waveform will be seen. In such a case, you must use the
appropriate timescale/precision for the simulation. For example:
xrun -timescale 1ns/1ps
You can use the cmelab and xrun option -dumptiming <dump_file>. This will
generate a file named dump_file that contains the design hierarchy along
with all the timing information within each scope. This file can be used to check
what actually is annotated from the SDF files. All the scopes that are annotated
with 0 value shall be explicitly shown. For example:
<pdelay anno='y' delay="0"/>
5. It is possible that the time precision in module and the time precision specified at
the command line differ and annotation does not happen. For example, consider
the following:
o The SDF file has its time unit as 1ps.
o The command line uses the -timescale 1ps/1fs option.
o The module that had the instance definition had timescale as 1ns/10ps.
o With these settings, all the modules that do not have timescale defined are
simulated with 1ps/1fs.
o All the modules that have timescale defined are not affected and simulated at the
timescale defined at the top.
o Suppose the SDF interconnect delay is .572ps, which is less than module
precision of 10ps. In this case, the value is rounded to 0, and the annotated value
is 0.

In such cases, use the -override_precision option in addition to the -timescale
option. This will make the precision for modules change to 1fs precision and annotation
will happen successfully.
Warnings to look out for:
WARNING/ERROR SDF / SPECIFY COMMENTS

MNEMONIC BLOCK (SNIPPET)
*W, SDFNL2 $recrem(data ,posedge Sum of 2 timing limits in
*W, PSDNGL2 clk , -1, - $setuphold or $recrem should
*W, CUNGL2 2,,,,d_data,d_clk); be greater than or equal to zero.
(RECREM data (posedge
Negative timing limit is set to zero.
clk) (-6) (-4))
*W, SDFIND - An attempt was made to annotate
a negative delay value to a
primitive (UDP). The value is set
to zero.
NOTE – UDPs do not have

specify blocks to facilitate
annotation.
*W, SDFNGL - Negative values encountered in
timing checks are set to 0 as
–noneg_tchk option is used.
*W, NONTCTL $recrem(data Sum of the two limits is negative.
,posedge clk , 1, - Use -ntc_tolerance option by
2,,,,,); providing a positive tolerance
value.
*W, NTCTLER - A tolerance value must be zero or
a positive value.
*W, NGLIM2 $recrem(data ,posedge Both limits in $setuphold or
clk , -1, - $recovery are negative. One
2,,,,d_data,d_clk);
must be greater than or equal to
(RECREM data (posedge zero: the negative limit(s) is set to
clk) (-6) (-4)) 0.
*W, SDFNL2N - The sum of timing limits in a
*W, SDFNL2P $setuphold or $recrem timing
*W, SBNGL2N check must be less than or equal
*W, SBNGL2P
*W, SBNGL2
to the tolerance value given by
*W, SANGL2N the -ntc_tolerance option
*W, SANGL2P (default tolerance is 0).
*W, SANGL2

The negative limit is set to 0.
If -ntc_neglim or -
ntc_polsim is specified, the
negative/positive limit is adjusted
to match the positive/negative
limit respectively.
*W, NTCTLUT - Tolerance value should be a time
value with the following valid time
unit:
fs, ps, ns, us, ms, or s
*W, NTCTLOF - Tolerance value is too big to be
represented properly. The default
value zero is assumed.
*W, NTCAJL2 - Only one of the two options,
–ntc_neglim, -ntc_poslim, can
be specified. When both are
given, the simulator uses
-ntc_neglim, and ignores
-ntc_poslim.
*W, NTCWID - The delay on an NTC net has a
different rise and fall delay. The
difference between the rise and
fall delay is greater than the limit
of a $width check controlled by
this net.
*W, NTCNOT - -notimingcheck has been used
*W, NTCNTX on a design with NTC delays.
Cadence recommends that
-ntcnotchk be used
instead. This option removes the
timing checks from the simulation
after the NTC delays have been
generated.

*W, NTCNNC $recrem(negedge data During the calculation of the
,posedge clk , 1, signal delay values and the
1,,,,d_data,d_clk); adjustment of timing check limit
$setuphold(posedge clk,
values, convergence could not be
posedge data , 1,
1,,,,d_data,d_clk); achieved. Some negative limits
are set to zero and iteration is
(RECREM (negedge data) continued until a solution is found.
(posedge clk) (5) (-4)
)
(SETUPHOLD (posedge
data)(posedge clk)
(12)(-9))
*W, NTCDNG $setuphold(posedge Signals have negative values on
clk, posedge data , 1, both reference and data limits for
1,,,,d_data,d_clk); different edges and this will cause
non-convergence. The limits are
(SETUPHOLD (posedge
data)(posedge clk) set to zero by the NTC algorithm.
(12)(-9))
*E, NTCIDNT $setuphold( posedge CK, On the given timing check line,
posedge D, 2 , -2 , the identical signal is being used
Notifier,,,CK,d_D ); for the delayed output and the
primary input to the timing check.
*W, NTCRLX (SETUPHOLD (posedge Non-convergence is caused due
*W, NTCRLX2 enb) (posedge clkin) (- to signals with non-overlapping
10) (8)) two limit constraints for different
(SETUPHOLD (negedge
edges. The limits are relaxed to
enb) (posedge clkin)
(12) (-9)) make the constraints overlap by
at least two units of simulation
precision.
*W, NTCELX $setuphold The pair of signals had non-
(posedge CLK, overlapping two limit constraints
posedge D, -3, 8, , , , for different edges and this
dCLK, dD);
caused non-convergence. The
$setuphold (posedge limits were relaxed to make the
CLK, negedge D, -7, 13, constraints overlap by at least two
, , , dCLK, dD); units of simulation precision. This
caused the limits to change by
more than the permissible
percentage.

*W, NTCPAT (IOPATH clkin clkout Normally, the NTC delay is
(24) (24)) smaller than the enclosing path
delay, which lets the path delay
(SETUPHOLD (posedge en)
control when the output transition
(posedge clkin) (-178)
(203)) will occur. When the NTC delay
(SETUPHOLD (negedge en) is larger than parts of a path
(posedge clkin) (735) delay, the output transition is no
(-489)) longer exclusively determined by
the path delay. The NTC delay
may have a visible impact on the
timing of the output transition.
*W, SDFNEP This path, including the condition,
*W, SDFNET if any, does not exist in the
instance being annotated. The
requested annotation will not
occur. To perform the
annotation, the information in the
SDF file must be updated to
correctly match what is in the HDL
description. This timing check,
including conditions, if any, does
not exist in the instance being
annotated.
*W, SDFNCAP The source and destination for the
requested interconnect are not
hierarchically connected by a
wire. A unidirectional continuous
assign was detected as the
reason for the disconnection. The
port requested port annotation will
still be placed at the destination
location.
*W, SDFNSB The module is being annotated
with either path delay or timing
check information, but the module
has no specify block. This
warning is issued only once per
instance.
These warnings may not always be critical for the design. However, it is always a good
idea to cross-check the reasons for the warning and assess the potential issue which may
come up and take measures to remove these warnings.
Summary
This Application Note will help you in setting up the environment for the first time and help
you understand the GLS flow, if you are a beginner. This document may not be sufficient
to address all your needs because it does not cover many parts of GLS. Therefore, it is
advisable for you to visit the Cadence online support site at https://support.cadence.com
and search for more detailed information about GLS and related topics.
Support
Cadence Online Support at https://support.cadence.com provides access to support
resources, including an extensive knowledge base, access to software updates for
Cadence products, and the ability to interact with Cadence Customer Support.
Feedback
Email comments, questions, and suggestions to content_feedback@cadence.com.


GLS

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

GLS

Enviado por

Direitos autorais:

Formatos disponíveis

Gate-level Simulation (GLS): A Quick

Guide for Beginners

Learn more at Cadence Online Support - http://support.cadence.com

Learn more at Cadence Online Support - http://support.cadence.com

Learn more at Cadence Online Support - http://support.cadence.com

Why GLS is needed?

1. Overcoming the limitations of STA, such as:

a. The inability of STA to identify asynchronous interfaces. It is a good way to

2. Verifying system initialization and that the reset sequence is correct.

4. Revealing glitches on edge-sensitive signals due to combinational logic using both

6. Verifying that clock-tree synthesis meets requirements.

7. Capturing switching factors for power estimation.

8. Analyzing X state pessimism or an optimistic view, in RTL or GLS.

Learn more at Cadence Online Support - http://support.cadence.com

1. Zero Delay Simulation

2. Unit Delay Simulation

3. SDF Simulation (Simulation Delay File specifies timing)

1. Zero Delay Simulation

2. Unit Delay Simulations

Learn more at Cadence Online Support - http://support.cadence.com

Learn more at Cadence Online Support - http://support.cadence.com

Delays can be annotated in the design in two ways.

a. Using the $sdf_annotate system task

By default, SDF annotation is performed during elaboration. The elaborator

b. Using a SDF command file

Learn more at Cadence Online Support - http://support.cadence.com

Types of Delay Models

1. Transport Delay Models

2. Inertial Delay Models

Learn more at Cadence Online Support - http://support.cadence.com

Learn more at Cadence Online Support - http://support.cadence.com

Setting up a GLS Flow for the First Time: An Example

The basic inputs for a GLS run are:

b) Library cell information

c) Delay information contained in an SDF timing file

d) Testbenches to exercise the netlist

The example contains the following:

a. RTL source code : counter.v

Learn more at Cadence Online Support - http://support.cadence.com

1. Running Zero Delay Simulation

The xrun command looks like the following:

xrun -clean counter_netlist.v counter_test.v –mess –access +rwc –v

Running this command will give you the following messages:

xmelab: *W,SDFIGN: Ignore -sdf_cmd_file because of -nospecify option.

Learn more at Cadence Online Support - http://support.cadence.com

2. Running SDF Simulation

To run SDF simulation, use the following command (comment line 12 in

xrun -v slow_vdd1v0_basicCells.v counter_netlist.v counter_test.v -

The command using the $sdf_annotate() system task is:

xrun -v slow_vdd1v0_basicCells.v counter_netlist.v counter_test.v -

Running the command displays the following messages:

Learn more at Cadence Online Support - http://support.cadence.com

xrun -v slow_vdd1v0_basicCells.v counter_netlist.v counter_test.v -mess

Disabling Timing Information

A number of solutions exist to turn off timing checks:

Learn more at Cadence Online Support - http://support.cadence.com

1. Disabling Timing Checks Globally at Elaboration time

2. Disabling Timing Checks Locally at Elaboration time

A timing file consists of a set of lines:

 Each line pertains to:

The following table contains the list of keywords:

Learn more at Cadence Online Support - http://support.cadence.com

The following is an example of a simple tfile:

Learn more at Cadence Online Support - http://support.cadence.com

Issue 4: Debugging an xmelab:W SDFNEP & W SDFNET Error