Ug900 Vivado Logic Simulation
Ug900 Vivado Logic Simulation
of this document
Logic Simulation
UG900 (v2024.1) May 30, 2024
Chapter 1
Overview
• Hardware, IP, and Platform Development: Creating the PL IP blocks for the hardware
platform, creating PL kernels, functional simulation, and evaluating the AMD Vivado™ timing,
resource use, and power closure. Also involves developing the hardware platform for system
integration. Topics in this document that apply to this design process include:
This chapter provides an overview of the simulation process, and the simulation options in the
AMD Vivado™ Design Suite.
• Creating test benches, setting up libraries, and specifying the simulation settings for
Simulation
• Generating a Netlist (if performing post-synthesis or post-implementation simulation)
• Running a Simulation using Vivado simulator or third party simulators. See Supported
Simulators for more information on supported simulators.
Supported Simulators
Following are the supported simulators in the Vivado Design Suite:
See the Vivado Design Suite User Guide: Release Notes, Installation, and Licensing (UG973) for the
supported versions of third-party simulators.
For more information about the Vivado IDE and the Vivado Design Suite flow, see:
• Vivado Design Suite User Guide: Using the Vivado IDE (UG893)
• Vivado Design Suite User Guide: Design Flows Overview (UG892)
Simulation Flow
Simulation can be applied at several points in the design flow. It is one of the first steps after
design entry and one of the last steps after implementation as part of verifying the end
functionality and performance of the design.
Simulation is an iterative process and is typically repeated until both the design functionality and
timing requirements are satisfied.
The following figure illustrates the simulation flow for a typical design:
RTL Design
Behavioral Simulation
(Verify Design Behaves as
Intended)
Synthesize
Post Implementation
Simulation
(Close to Emulating HW)
X23703-021320
• RTL Code
• Instantiated UNISIM library components
• Instantiated UNIMACRO components
• UNISIM gate-level model (for the Vivado logic analyzer)
• SECUREIP Library
RTL-level simulation lets you simulate and verify your design prior to any translation made by
synthesis or implementation tools. You can verify your designs as a module or an entity, a block,
a device, or a system.
RTL simulation is typically performed to verify code syntax, and to confirm that the code is
functioning as intended. In this step, the design is primarily described in RTL and consequently,
no timing information is required.
RTL simulation is not architecture-specific unless the design contains an instantiated device
library component. To support instantiation, AMD provides the UNISIM library.
When you verify your design at the behavioral RTL, you can fix design issues earlier and save
design cycles.
Keeping the initial design creation limited to behavioral code allows for:
Post-Synthesis Simulation
You can simulate a synthesized netlist to verify that the synthesized design meets the functional
requirements and behaves as expected. Although it is not typical, you can perform a timing
simulation with estimated timing numbers at this simulation point.
The functional simulation netlist is a hierarchical, folded netlist expanded to the primitive module
and entity level; the lowest level of the hierarchy consists of primitives and macro primitives.
These primitives are contained in the UNISIMS_VER library for Verilog, and the UNISIM library
for VHDL.
Related Information
UNISIM Library
Post-Implementation Simulation
You can perform functional or timing simulation after implementation. Timing simulation is the
closest emulation to actually downloading a design to a device. It allows you to ensure that the
implemented design meets functional and timing requirements and has the expected behavior in
the device.
IMPORTANT! Performing a thorough timing simulation ensures that the completed design is free of
defects that could otherwise be missed, such as:
Note: For Versal devices, post-synthesis, and post-implementation simulation are supported only for fabric
logic (PL) and not supported for designs with Hard Blocks (NoC/AIE/PS). Only behavioral simulation is
supported for designs utilizing Hard Blocks.
• VHDL, see IEEE Standard VHDL Language Reference Manual (IEEE-STD-1076-1993) and part
of VHDL-2008.
• Verilog, see IEEE Standard Verilog Hardware Description Language (IEEE-STD-1364-2001).
• SystemVerilog, see IEEE Standard for SystemVerilog--Unified Hardware Design, Specification,
and Verification Language (IEEE-STD-1800-2009).
• IEEE P1735 encryption, see Recommended Practice for Encryption and Management of
Electronic Design Intellectual Property (IP) (IEEE-STD-P1735).
Chapter 2
• Create a test bench that reflects the simulation actions you want to run.
• Set up an install location in Vivado IDE (if not using the Vivado simulator).
• Compile your libraries (if not using the Vivado simulator).
• Select and declare the libraries you need to use.
• Specify the simulation settings such as target simulator, the simulation top module name, top
module (design under test), display the simulation set, and define the compilation, elaboration,
simulation, netlist, and advanced options.
• Generate a Netlist (if performing post-synthesis or post-implementation simulation).
You can also set up the test bench to display the simulation output to a file, a waveform, or a
display screen. A test bench can be simple in structure and can sequentially apply a stimulus to
specific inputs.
• Subroutine calls
• Stimulus that is read in from external files
• Conditional stimulus
• Other more complex structures
The advantages of a test bench over interactive simulation are that it:
The following bullets are recommendations for creating an effective test bench.
• Always specify the `timescale in Verilog test bench files. For example:
`timescale 1ns/1ps
• Initialize all inputs to the design within the test bench at simulation time zero to properly
begin the simulation with known values.
• Apply stimulus data after 100 ns to account for the default Global Set/Reset (GSR) pulse used
in functional and timing-based simulation.
• Begin the clock source before the Global Set/Reset (GSR) is released.
For more information about test benches, see Writing Efficient Test Benches (XAPP199).
TIP: When you create a test bench, remember that the GSR pulse occurs automatically in the post-
synthesis and post-implementation timing simulation. This holds all registers in reset for the first 100 ns of
the simulation.
Related Information
The Vivado Design Suite provides simulation models as a set of files and libraries. Your simulation
tool must compile these files prior to design simulation. The simulation libraries contain the
device and IP behavioral and timing models. The compiled libraries can be used by multiple
design projects.
During the compilation process, Vivado creates a default initialization file that simulator uses to
reference the compiled libraries. The compile_simlib command creates the file in the library
output directory specified during library compilation. The default initialization file contains
control variables that specify reference library paths, optimization, compiler, and simulator
settings. If the correct initialization file is not found in the path, you cannot run simulation on
designs that include AMD primitives.
The name of the initialization file varies depending on the simulator you are using, as follows:
For more information on the simulator-specific compiled library file, see the third-party
simulation tool documentation.
IMPORTANT! Compilation of the libraries is typically a one-time operation, as long as you are using the
same version of tools. However, any change to the Vivado tools or the simulator versions requires that
libraries be recompiled.
You can compile libraries using the Vivado IDE or using Tcl commands, as described in the
following sections.
• Language: Compiles libraries for the specified language. If this option is not specified, then the
language is set to correspond with the selected simulator (above). For multi-language
simulators, both Verilog and VHDL libraries are compiled.
• Family: Compiles selected libraries to the specified device family. All device families are
generated by default.
• Compiled library location: Specifies the directory path for saving the compiled library results.
By default, the libraries are saved in the current working directory in Non-Project mode, and
the libraries are saved in the <project>/<project>.cache/compile_simlib directory
in Project mode. See the Vivado Design Suite User Guide: Design Flows Overview (UG892) for
more information on Project and Non-Project modes.
TIP: Because the Vivado simulator has pre-compiled libraries, it is not necessary to identify the library
location.
• Simulator executable path: Specifies the directory to locate the simulator executable. This
option is required if the target simulator is not specified in the $PATH or %PATH% environment
variable, or to override the path from the $PATH or %PATH% environment variable.
• GCC executable path: Specifies the directory to locate GCC installation. This option is
required if GCC path settings are not done as mentioned in GCC Path Settings. Ignore if you
are not using SystemC IP.
• Miscellaneous Options: Specify additional options for the compile_simlib Tcl command.
• Compile AMD IP: Enable or disable compiling simulation libraries for AMD IP.
• Verbose: Temporarily overrides any message limits and returns all messages from this
command.
• Command: Shows the Tcl command equivalent for the options you enter in the dialog box.
TIP: You can use the value of the Command field to generate a simulation library in Tcl/non-project
mode.
• Questa Advanced Simulator: Generating a simulation library for Questa for all languages and
for all libraries and all families in the current directory.
• ModelSim: Generating simulation library for ModelSim at /a/b/c, where the ModelSim
executable path is <simulator_installation_path>.
• VCS: Generating a simulation library for VCS for the Verilog language, for the UNISIM library
at /a/b/c.
• Xcelium: Generating a simulation library for Xcelium for the Verilog language, for the UNISIM
library at /a/b/c.
Tcl Command
Where:
For example, to change the option used to compile the UNISIM VHDL library, type:
IMPORTANT! The compile_simlib command compiles AMD primitives and Simulation models of
AMD Vivado IP. AMD Vivado IP cores are delivered as an output product when the IP is generated;
consequently, they are included in the pre-compiled libraries created using compile_simlib.
'/test/patched_ip_repo/data/ip/xilinx'
To compile the default installed IP repository and the repository that is pointed to by
XILINX_PATH in a new output directory, set the XILINX_PATH environment (env) variable to
point to this patched IP repository and run compile_simlib. compile_simlib processes the
IP library sources from the default installed repository and the one set by XILINX_PATH.
'/test/patched_ip_repo/data/ip/xilinx'
To compile the repository pointed to by XILINX_PATH in an existing output directory where the
library was already compiled for the default installed IP repository, set the XILINX_PATH env
variable to point to this patched IP repository and runcompile_simlib. compile_simlib
processes the IP library sources from the repository set by XILINX_PATH in the existing output
directory.
When you instantiate a component in your design, the simulator must reference a library that
describes the functionality of the component to ensure proper simulation. The AMD libraries are
divided into categories based on the function of the model.
Notes:
1. The SIMPRIMS_VER is the logical library name to which the Verilog SIMPRIM physical library is mapped.
2. XPM is supported as a pre-compiled IP. Hence, you need not add the source file to the project. For third party
simulators, the Vivado tools map to pre-compiled IP generated with compile_simlib.
IMPORTANT! You must specify different simulation libraries according to the simulation points. There are
different gate-level cells in pre- and post-implementation netlists.
The following table lists the required simulation libraries at each simulation point.
SIMPRIM
Simulation Point UNISIM UNIFAST UNIMACRO SECUREIP (Verilog SDF
Only)
1. Register Transfer Yes Yes Yes Yes N/A No
Level (RTL)
(Behavioral)
2. Post-Synthesis Yes Yes N/A Yes N/A N/A
Simulation (Functional)
3. Post-Synthesis N/A N/A N/A Yes Yes Yes
Simulation (Timing)
4. Post- Yes Yes N/A Yes N/A N/A
Implementation
Simulation (Functional)
5. Post- N/A N/A N/A Yes Yes Yes
Implementation
Simulation (Timing)
IMPORTANT! The Vivado simulator uses precompiled simulation device libraries. When updates to
libraries are installed, the precompiled libraries are automatically updated.
Note: Verilog SIMPRIMS_VER uses the same source as UNISIM with the addition of specify blocks for
timing annotation. SIMPRIMS_VER is the logical library name to which the Verilog physical SIMPRIM is
mapped.
VHDL <Vivado_Install_Dir>/data/vhdl/src/unisims
UNIFAST Verilog <Vivado_Install_Dir>/data/verilog/src/unifast
VHDL <Vivado_Install_Dir>/data/vhdl/src/unifast
UNIMACRO Verilog <Vivado_Install_Dir>/data/verilog/src/unimacro
VHDL <Vivado_Install_Dir>/data/vhdl/src/unimacro
SECUREIP Verilog <Vivado_Install_Dir>/data/secureip/
UNISIM Library
Functional simulation uses the UNISIM library and contains descriptions for device primitives or
lowest-level building blocks.
IMPORTANT! By default, the compile_simlib command compiles the static simulation files for all
the IPs in the IP Catalog.
The following table lists the UNISIM library component files that let you call precompiled,
encrypted library files when you include IP in a design. Include the path that you require in your
library search path.
IMPORTANT! Verilog module names and file names are uppercase. For example, module BUFG is
BUFG.v, and module IBUF is IBUF.v. Ensure that UNISIM primitive instantiations adhere to an
uppercase naming convention.
The VHDL UNISIM library is divided into the following files, which specify the primitives for the
AMD device families:
To use these primitives, place the following two lines at the beginning of each file:
library UNISIM;
use UNISIM.VCOMPONENTS.all;
IMPORTANT! You must also compile the library and map the library to the simulator. The method
depends on the simulator.
Note: For Vivado simulator, the library compilation and mapping is an integrated feature with no further
user compilation or mapping required.
Note: Starting in AMD Versal™ adaptive SoC, AMD is delivering Verilog/SystemVerilog models only for the
new primitives. This means that a mixed-language environment is needed for VHDL-only designs, like what
has been needed in the past for IPs and XPMs. For more information, see AR76496.
In Verilog, the individual library modules are specified in separate HDL files. This allows the -y
library specification switch to search the specified directory for all components and automatically
expand the library.
The Verilog UNISIM library cannot be specified in the HDL file prior to using the module. To use
the library module, specify the module name using all uppercase letters.
The following example shows the instantiated module name as well as the file name associated
with that module:
If you use precompiled libraries, use the correct simulator command-line switch to point to the
precompiled libraries. The following is an example for the Vivado simulator:
-L unisims_ver
Where:
UNIMACRO Library
The UNIMACRO library is used during the functional simulation and contains macro descriptions
for selected device primitives.
IMPORTANT! You must specify the UNIMACRO library anytime you include a device macro listed in the
Vivado Design Suite 7 Series FPGA and Zynq-7000 SoC Libraries Guide (UG953).
To use these primitives, place the following two lines at the beginning of each file:
library UNIMACRO;
use UNIMACRO.Vcomponents.all;
In Verilog, the individual library modules are specified in separate HDL files. This allows the -y
library specification switch to search the specified directory for all components and automatically
expand the library.
The Verilog UNIMACRO library does not need to be specified in the HDL file prior to using the
modules as is required in VHDL. To use the library module, specify the module name using all
uppercase letters. You must also compile and map the library; the method you use depends on
the simulator you choose.
IMPORTANT! Verilog module names and file names are uppercase. For example, module BUFG is
BUFG.v. Ensure that UNIMACRO primitive instantiations adhere to an uppercase naming convention.
SIMPRIM Library
Use the SIMPRIM library for simulating timing simulation netlists produced after synthesis or
implementation.
IMPORTANT! Timing simulation is supported only in Verilog; there is no VHDL version of the SIMPRIM
library.
TIP: If you are a VHDL user, you can run post synthesis and post implementation functional simulation (in
which case no standard delay format (SDF) annotation is required and the simulation netlist uses the
UNISIM library). You can create the netlist using the write_vhdl Tcl command. For usage information, refer
to the Vivado Design Suite Tcl Command Reference Guide (UG835).
-L SIMPRIMS_VER
Where:
Note: Secure IP Blocks are fully supported in the Vivado simulator without additional setup.
AMD leverages the encryption methodology as specified in the IEEE standard Recommended
Practice for Encryption and Management of Electronic Design Intellectual Property (IP) (IEEE-STD-
P1735). The library compilation process automatically handles encryption.
Note: See the simulator documentation for the command line switch to use with your simulator to specify
libraries.
The following table lists special considerations that must be arranged with your simulator vendor
for using these libraries.
IMPORTANT! See Vivado Design Suite User Guide: Release Notes, Installation, and Licensing (UG973) for
the supported version of third-party simulators.
The UNISIM library contains the wrappers for VHDL SECUREIP. Place the following two lines at
the beginning of each file so that the simulator can bind to the entity:
Library UNISIM;
UNISIM.VCOMPONENTS.all;
When running a simulation using Verilog code, you must reference the SECUREIP library for
most simulators.
If you use the precompiled libraries, use the correct directive to point to the precompiled
libraries. The following is an example for the Vivado simulator:
-L SECUREIP
IMPORTANT! You can use the Verilog SECUREIP library at compile time by using -f switch. The file list is
available in the following path: <Vivado_Install_Dir>/data/secureip/
secureip_cell.list.f.
UNIFAST Library
The UNIFAST library is an optional library that you can use during RTL behavioral simulation to
speed up simulation runtime.
IMPORTANT! The UNIFAST library is an optional library that you can use during functional simulation to
speed up simulation runtime. UNIFAST libraries are supported for 7 series devices only. AMD UltraScale™
and later device architectures do not support UNIFAST libraries, as all the optimizations are incorporated
in the UNISIM libraries by default. UNIFAST libraries cannot be used for sign-off simulations because the
library components do not have all the checks/features that are available in a full model.
RECOMMENDED: Use the UNIFAST library for initial verification of the design and then run a complete
verification using the UNISIM library.
The simulation runtime improvement is achieved by supporting a subset of the primitive features
in the simulation mode.
Note: The simulation models check for unsupported attribute values only.
MMCME2
To reduce the simulation runtimes, the fast MMCME2 simulation model has the following
changes from the full model:
1. The fast simulation model provides only basic clock generation functions. Other functions,
such as DRP, fine phase shifting, clock stopped, and clock cascade are not supported.
2. It assumes that the input clock is stable without frequency and phase change. The input clock
frequency sampling stops after the LOCKED signal is asserted HIGH.
3. The output clock frequency, phase, duty cycle, and other features are directly calculated from
the input clock frequency and parameter settings.
Note: The output clock frequency is not generated from input-to-VCO clock.
4. The standard and the fast MMCME2 simulation model LOCKED signal assertion times differ.
• Standard Model LOCKED assertion time depends on the M and D setting. For large M and
D values, the lock time is relatively long for a standard MMCME2 simulation model.
• In the fast simulation model, the LOCKED assertion time is shortened.
DSP48E1
To reduce the simulation runtimes, the fast DSP48E1 simulation model has the following features
removed from the full model.
• Pattern Detection
• OverFlow/UnderFlow
• DRP interface support
GTHE2_CHANNEL/GTHE2_COMMON
To reduce the simulation runtimes, the fast GTHE2 simulation model has the following feature
differences:
• GTH links must be synchronous with no Parts Per Million (PPM) rate differences between the
near and far-end link partners.
• Latency through the GTH is not cycle-accurate with the hardware operation.
• You cannot simulate the DRP production reset sequence. Bypass it when using the UNIFAST
model.
• GTX links must be of synchronous with no Parts Per Million (PPM) rate differences between
the near and far-end link partners.
• Latency through the GTX is not cycle-accurate with the hardware operation.
Method 1 is the recommended method whereby you simulate with all the UNIFAST models.
Use the following Tcl command in the Tcl console to enable UNIFAST support (fast simulation
models) in a Vivado project environment for the Vivado simulator, ModelSim or VCS:
See the UNISIM Library for more information regarding component files.
For more information, see the appropriate third-party simulation user guide.
Recommended for more advanced users who want to specify which modules to simulate with
the UNIFAST models.
To specify individual library components, Verilog configuration statements are used. Specify the
following in the config.v file:
• The name of the top-level module or configuration (For example, config cfg_xilinx;)
• The name to which the design configuration applies (For example, design test bench;)
• The library search order for cells or instances that are not explicitly called out (for example:
default liblist unisims_ver unifast_ver;)
• The map for a particular CELL or INSTANCE to a particular library (For example, instance
testbench.inst.O1 use unifast_ver.MMCME2;)
Note: For ModelSim (vsim) only -genblk is added to hierarchy name (For example, instance
testbench.genblk1.inst.genblk1.O1 use unifast_ver.MMCME2; - VSIM).
Example config.v
config cfg_xilinx;
design testbench;
default liblist unisims_ver unifast_ver;
//Use fast MMCM for all MMCM blocks in design
cell MMCME2 use unifast_ver.MMCME2;
//use fast dSO48E1for only this specific instance in the design
instance testbench.inst.O1 use unifast_ver.DSP48E1;
//If using ModelSim or Questa, add in the genblk to the name
(instance testbench.genblk1.inst.genblk1.O1 use unifast_ver.DSP48E1)
endconfig
library unisim;
library unifast;
configuration cfg_xilinx of testbench
is for xilinx
.. for inst:netlist
. . . use entity work.netlist(inst);
.......for inst
.........for all:MMCME2
..........use entity unifast.MMCME2;
.........end for;
.......for O1 inst:DSP48E1;
.........use entity unifast.DSP48E1;
.......end for;
...end for;
..end for;
end for;
end cfg_xilinx;
Note: If you want to use a VHDL UNIFAST model, use a configuration to bind the UNIFAST library during
elaboration.
• Target simulator: From the simulator drop-down menu, select a simulator. AMD Vivado™
simulator is the default simulator. However, many third-party simulators are also supported.
• Simulator language: Select the simulator language mode. The simulation model used for
various IPs in your design varies depending on what language the IP supports.
• Simulation set: Select the simulation set that the simulation commands use by default.
IMPORTANT! The compilation and simulation settings for a previously defined simulation set are not
applied to a newly-defined simulation set.
• Simulation top module name: Enter an alternate top module to use during simulation.
• Generate simulation scripts only: Generates scripts if selected. Simulation is not invoked.
• Configure script to run simulator in GUI mode: Launch simulator GUI in scripts-only mode if
selected.
• Compiled library location: This option is displayed when you select a third-party simulator.
This directory serves as the location from which the simulator accesses compiled libraries. To
facilitate this, you are required to explicitly define the path where libraries are compiled by
using the comb_simlib command.
• Compilation tab: This tab defines and manages compiler directives, which are stored as
properties on the simulation fileset and used by the xvlog and xvhdl utilities to compile Verilog
and VHDL source files for simulation.
Note: xvlog and xvhdl are Vivado simulator specific commands. The applicable utilities change based on
the target simulator.
• Elaboration tab: This tab defines and manages elaboration directives, which are stored as
properties on the simulation fileset and used by the xelab utility for elaborating and
generating a simulation snapshot. Select a property in the table to display a description of the
property and edit the value.
Note: xelab is a Vivado simulator specific command. The applicable utilities change based on the target
simulator.
• Simulation tab: This tab defines and manages simulation directives, which are stored as
properties on the simulation fileset and used by the xsim application for simulating the current
project. Select a property in the table to display a description of the property and edit the
value.
• Netlist tab: This tab provides access to netlist configuration options related to the SDF
annotation of the Verilog netlist and the process corner captured by SDF delays. These
options are stored as properties on the simulation fileset and are used while writing the netlist
for simulation.
• Include all design sources for simulation: By default, this option is enabled. Selecting this
option ensures that all the files from design sources along with the files from the current
simulation set is used for simulation. Even if you change the design sources, the same
changes are updated when you launch the behavioral simulation.
CAUTION! Changing the settings in the Advanced tab should be done only if necessary. The Include
all design sources for simulation check box is selected by default. Deselecting the box could produce
unexpected results. As long as the check box is selected, the simulation set includes Out-of-Context
(OOC) IP, IP Integrator files, and DCP.
Note: For detailed information on the properties in the Compilation, Elaboration, Simulation, Netlist,
and Advanced tabs, see Appendix A: Compilation, Elaboration, Simulation, Netlist, and Advanced
Options.
The Vivado Design Suite ensures the availability of a simulation model by using the available
synthesis files of an IP to generate a language-specific structural simulation model on demand.
For cases in which a behavioral model is missing or does not match the licensed simulation
language, the Vivado tools automatically generate a structural simulation model to enable
simulation. Otherwise, the existing behavioral simulation model for the IP is used. If no synthesis
or simulation files exist, simulation is not supported.
Note: The simulator_language property cannot deliver a language-specific simulation netlist file if the
generated Synthesized checkpoint (.dcp) is disabled.
The Generate Output Products dialog box (shown in the following figure) opens.
Notes:
1. Where available, behavioral simulation models always take precedence over structural simulation models. The Vivado
tools select behavioral or structural models automatically, based on model availability. It is not possible to override
the automated selection.
2. Use the target_language property when either language can be used for simulation Tcl: set_property
target_language VHDL [current_project]
3. Setting VHDL as a target language for AMD Versal™ devices is not yet supported. This results in an error in the
simulation.
IMPORTANT! Run simulations using a time resolution of 1 fs. Some AMD primitive components, such as
GT, require a 1 fs resolution to work properly in either functional or timing simulation.
See Simulation Options for detailed information on Simulation Options in Settings dialog box.
IMPORTANT! Picoseconds are used as the minimum resolution because testing equipment can measure
timing only to the nearest picosecond resolution.
1. Select File → Add Sources, or click Add Sources in the Flow Navigator.
The Add Sources wizard opens.
2. Select Add or Create Simulation Sources, and click Next.
The Add or Create Simulation Sources dialog box opens. The options are:
• Add Files: Invokes a file browser so you can select simulation source files to add to the
project.
• Add Directories: Invokes directory browser to add all simulation source files from the
selected directories. Files in the specified directory with valid source file extensions are
added to the project.
• Create File: Invokes the Create Source File dialog box where you can create new
simulation source files. See the Vivado Design Suite User Guide: System-Level Design Entry
(UG895) for more information about project source files.
• Buttons on the side of the dialog box let you do the following:
○ Remove : Removes the selected source files from the list of files to be added.
VIDEO: For a demonstration of this feature, see the Vivado Design Suite QuickTake Video: Logic
Simulation..
The simulation set lets you define different sources for different stages of the design. For
example, there can be one test bench source to provide a stimulus for behavioral simulation of
the elaborated design or a module of the design, and a different test bench to provide a stimulus
for timing simulation of the implemented design.
When adding simulation sources to the project, you can specify which simulation source set to
use.
1. In the Sources window popup menu, right-click Simulation Sources and click Edit Simulation
Sets, as shown in the following figure.
2. From the Add or Create Simulation Sources wizard, select Add Sources.
This adds the sources associated with the project to the newly created simulation set.
3. Add additional files as needed.
The selected simulation set is used for the active design run.
Generating a Netlist
To run a simulation of a synthesized or implemented design run, the netlist generation process.
The netlist generation Tcl commands can take a synthesized or implemented design database and
write out a single netlist for the entire design.
The Vivado Design Suite generates a netlist automatically when you launch the simulator using
the IDE or the launch_simulation command.
Netlist generation Tcl commands can write SDF and the design netlist. The Vivado Design Suite
provides the following Tcl commands:
TIP: The SDF values are only estimated during the early design process (for example, during synthesis). As
the design process progresses, the accuracy of the timing numbers also progresses as there is more
information available in the database.
The functional simulation netlist is a hierarchical, folded netlist that is expanded to the primitive
module or entity level; the lowest level of hierarchy consists of primitives and macro primitives.
In many cases, you can use the same test bench that you used for behavioral simulation to
perform a more accurate simulation.
The following Tcl commands generate Verilog and VHDL functional simulation netlist,
respectively:
In many cases, you can use the same test bench that you used for functional simulation to
perform a more accurate simulation.
Compare the results from the two simulations to verify that your design is performing as initially
specified.
TIP: If you are a VHDL user, you can run post-synthesis and post-implementation functional
simulation (in which case no standard delay format (SDF) annotation is required and the simulation
netlist uses the UNISIM library). You can create the netlist using the write_vhdl Tcl command. For
usage information, see the Vivado Design Suite Tcl Command Reference Guide (UG835).
The following is the Tcl syntax for generating a timing simulation netlist:
Chapter 3
The Vivado Design Suite User Guide: Using the Vivado IDE (UG893) describes the use of the Vivado
IDE.
Set the following environment variables before running simulation in Vivado IDE.
Questa
setenv MODEL_TECH <tool installation path> set MODEL_TECH=<tool
setenv LM_LICENSE_FILE <license file> installation path>
setenv PATH ${MODEL_TECH}/bin:$PATH set LM_LICENSE_FILE=<license
file>
set Path=%MODEL_TECH%
\win32;%Path%
Active-HDL NA
set ACTIVE_BIN=<tool
installation path>
set Path=%<Active_hdl install
dir>%\BIN;%Path%
set LM_LICENSE_FILE=<license
file>
Xcelium NA
setenv CDS_INST_DIR <xcelium_install_dir>
setenv LD_LIBRARY_PATH $CDS_INST_DIR/tools/
xcelium/lib:$LD_LIBRARY_PATH
setenv PATH $CDS_INST_DIR/tools/xcelium/
bin:$CDS_INST_DIR/tools/bin:$PATH
setenv CDS_LICENSE_DIR <tool_license>
VCS NA
setenv VCS_HOME <tool_install_path>
setenv LM_LICENSE_FILE <license_file_path>
setenv PATH ${VCS_HOME}/bin:${PATH}
Notes:
1. Tool installation path should be added to environment variable PATH (irrespective of OS). To simulate SystemC-based
designs for the supported simulator, provide the required g++ version installation path as mentioned in Appendix F:
SystemC Support in Vivado IDE. The LD_LIBRARY_PATH should also include the simulator library path.
For links to more information on your third-party simulator, see Links to Additional Information
on Third-Party Simulators.
IMPORTANT! Use only supported versions of third-party simulators. For more information on supported
Simulators and Operating Systems, see the Compatible Third-Party Tools table in the Vivado Design Suite
User Guide: Release Notes, Installation, and Licensing (UG973).
From the Vivado IDE, you can compile, elaborate, and simulate the design based on the
simulation settings and launch the simulator in a separate window.
When you run a simulation prior to synthesizing the design, the simulator runs a behavioral
simulation. Following each successful design step (synthesis and implementation), the option to
run a functional or timing simulation becomes available. You can initiate a simulation run from
the Flow Navigator or by typing in a Tcl command.
From the Flow Navigator, click Run Simulation, and select the type of simulation you want to run,
as shown in the following figure:
TIP: This command provides a -scripts_only option that can be used to write a DO or SH file,
depending on the target simulator. Use the DO or SH file to run simulations outside the IDE.
Note: If you are running the VCS simulator outside of Vivado, make sure to use -full64 switch.
Otherwise, the simulator does not run if the design contains an AMD IP.
IMPORTANT! Use the following command to run the 32-bit Simulator: set_property 32bit 1
[current_fileset -simset]
Note: AMD Verification IP (VIP) uses SystemVerilog construct. If you are using any IP that instantiates VIP,
make sure that your simulator supports SystemVerilog.
When you run Post-Synthesis and Post-Implementation timing simulation, the simulators include:
You define the overall design functionality in the beginning. When the design is implemented,
accurate timing information is available.
• Calls the netlist writer, write_verilog with the -mode timesim switch and write_sdf
(SDF annotator)
• Sends the generated netlist to the target simulator
You control these options using Simulation Settings as described in Using Simulation Settings.
IMPORTANT! Post-Synthesis and Post-Implementation timing simulations are supported for Verilog only.
There is no support for VHDL timing simulation. If you are a VHDL user, you can run post-synthesis and
post-implementation functional simulation (in which case no SDF annotation is required and the
simulation netlist uses the UNISIM library). You can create the netlist using the write_vhdl Tcl
command. For usage information, refer to the Vivado Design Suite Tcl Command Reference Guide
(UG835).
When synthesis runs successfully, the Run Simulation → Post-Synthesis Timing Simulation
option becomes available.
After you select a post-synthesis timing simulation, the timing netlist and the SDF file are
generated. The netlist files include $sdf_annotate command so that the generated SDF file is
picked up.
After you select a post-implementation timing simulation, the timing netlist and the SDF file are
generated. The netlist files include $sdf_annotate command so that the generated SDF file is
picked up.
When you specified simulation settings, you specified whether or not to create an SDF file and
whether the process corner would be set to fast or slow.
TIP: To find the SDF file options settings, in the Vivado IDE Flow Navigator, right-click Simulation and
select Simulation Settings. In the Settings dialog box, select Simulation category and click Netlist tab.
Based on the specified process corner, the SDF file contains different min and max numbers.
RECOMMENDED: To run a setup check, create an SDF file with -process_corner slow, and use the max
column from the SDF file.
To run a hold check, create an SDF file with the -process_corner fast, and use the min column
from the SDF file. The method for specifying which SDF delay field to use is dependent on the
simulation tool you are using. Refer to the specific simulation tool documentation for information
on how to set this option.
To get full coverage run all four timing simulations, specify as follows:
If you are running timing simulation from Vivado IDE, it adds the timing simulation-related
switches to the simulator. If you run a standalone timing simulation, make sure to pass the
following switch to simulators during elaboration:
For VCS:
IMPORTANT! The Vivado simulator models use interconnect delays; consequently, additional switches
are required for proper timing simulation, as follows: -transport_int_delays -pulse_r 0 -
pulse_int_r 0 . Table 15: xelab, xvhd, and xvlog Command Options provides descriptions for these
commands.
For more detailed usage or information about each commands, see the ModelSim
documentation.
Example DO File
2. Enable SAIF dumping. You can use the command line in the simulator workspace:
power -enable
For more detailed usage or information about each command, see the Synopsys VCS
documentation.
See Power Analysis Using Vivado Simulator for more information about Switching Activity
Interchange Format (SAIF).
Dumping VCD
You can use a Value Change Dump (VCD) file to capture simulation output. The Tcl commands
are based on Verilog system tasks related to dumping values.
For more detailed usage or information about each commands, see the ModelSim
documentation.
Example DO File:
vcs +vcs+dumpvars+test.vcd
Simulating IP
In the following example, the accum_0.xci file is the IP you generated from the AMD Vivado™
IP catalog. Use the following commands to simulate this IP in VCS:
In Modelsim
set_property -name {modelsim.simulate.tcl.post} -value
{<AbsolutePathOfFileLocation>}
-objects [get_filesets sim_1]
In VCS
set_property -name {vcs.simulate.tcl.post} -value
{<AbsolutePathOfFileLocation>} -objects
[get_filesets sim_1]
In Xcelium
set_property -name {xcelium.simulate.tcl.post} -value
{<AbsolutePathOfFileLocation>}
-objects [get_filesets sim_1]
• Native do file: This is a default do file format. In this format, the compile and elaborate shell
script calls source <tb>_compile/elaborate.do. For example:
The simulate script calls vsim -64 -c -do do {<tb>_simulate.do}. For example:
• Classic do file: Classic do file format is different from the native do file in compile and
elaborate shell scripts. There is no change in the simulate script. In compile and elaborate shell
scripts, it calls vsim -c -do do {<tb>_compile/elaborate.do}. For example,
This file format is useful for a shared project as the path for the Questa Advanced Simulator/
ModelSim utility is hard-coded inside the shell scripts.
Explanation
set_param simulator.modelsimNoQuitOnError 0
Make sure that you have the correct environment setup for the simulator before running the
scripts. See Using Simulation Settings for more information on configuring your simulator. See
the user guide of your specific simulator for the details of running batch or scripted mode.
Chapter 4
See the Vivado Design Suite Tutorial: Logic Simulation (UG937) for a step-by-step demonstration of
how to run Vivado simulation.
From the Flow Navigator, click Run Simulation and select a simulation type to invoke the Vivado
simulator workspace, as shown in the following figure.
Main Toolbar
The main toolbar provides one-click access to the most commonly used commands in the Vivado
IDE. When you hover over an option, a tool tip appears that provides more information.
Run Menu
The menus provide the same options as the Vivado IDE with the addition of a Run menu after
you have run a simulation.
• Restart: Lets you restart an existing simulation from time 0. Tcl Command: restart
• Run All: Lets you run an open simulation to completion. Tcl Command: run -all
• Run For: Lets you specify a time for the simulation to run. Tcl Command: run <time>
TIP: While you can always specify time units in the run command such as run 100 ns, you can also
omit the time unit. If you omit the time unit, the Vivado simulator assumes the time unit of the
TIME_UNIT Tcl property. To view the TIME_UNIT property, use the Tcl command get_property
time_unit [current_sim]. To change the TIME_UNIT property use the Tcl command
set_property time_unit <unit> [current_sim], where <unit> is one of the following:
fs, ps, ns, us, ms, and s.
Related Information
Simulation Toolbar
When you run the Vivado simulator, the simulation-specific toolbar (shown in the following
figure) opens to the right of the main toolbar.
These are the same buttons labeled in Run Menu above (without the Delete All Breakpoints
option), and they are provided for ease of use.
Related Information
Sources Window
The Sources window displays the simulation sources in a hierarchical tree, with views that show
Hierarchy, IP Sources, Libraries, and Compile Order, as shown in the following figure.
The Sources buttons are described by tooltips when you hover the mouse over them. The
buttons let you examine, expand, collapse, add to, open, filter, and scroll through files.
You can also open or add a source file by right-clicking on the source object and selecting the
Open File or Add Sources options.
Scope Window
A scope is a hierarchical partition of an HDL design. Whenever you instantiate a design unit or
define a process, block, package, or subprogram, you create a scope.
In the Scope window (shown in the following figure), you can see the design hierarchy. When you
select a scope in the Scope window, all HDL objects visible from that scope appear in the Objects
window. You can select HDL objects in the Objects window and add them to the waveform
viewer.
Filtering Scopes
• Click Settings option on the scopes sub-menu to toggle between showing or hiding (check or
uncheck) the corresponding scope type.
TIP: When you hide a scope using Setting option, all scopes inside that scope are also hidden regardless
of type. For example, in the preceding figure, clicking the Verilog Module button to hide all Verilog
module scopes hides not only the bft_tb scope but also uut (even though uut is a VHDL entity
scope).
• To limit the display to scopes containing a specified string, click the Search button and
type the string in the text box.
The objects displayed in the Objects window change (or are filtered) based on the current scope.
Select the current scope to change the objects in the Objects window.
When you right-click a scope, a menu (shown in the following figure) appears with the following
options:
• Add to Wave Window: Adds all viewable HDL objects of the selected scope to the waveform
configuration.
TIP: HDL objects of large bit width can slow down the display of the waveform viewer. You can filter
out such objects by setting a display limit on the wave configuration before issuing the Add to Wave
Window command. To set a display limit, use the Tcl command set_property DISPLAY_LIMIT
<maximum bit width> [current_wave_config].
The Add to Wave Window command might add a different set of HDL objects from the set
displayed in the Objects window. When you select a scope in the Scope window, the Objects
window might display HDL objects from enclosing scopes in addition to objects defined
directly in the selected scope. The Add to Wave Window command, on the other hand, adds
objects from the selected scope only.
Alternately, you can drag and drop items in the Objects window into the Name column of the
Wave window.
IMPORTANT! The Wave window displays the value changes of an object over time, starting from the
simulation time at which the object was added.
TIP: To display object values prior to the time of insertion, the simulation must be restarted. To avoid
restarting the simulation because of missing value changes, issue the log_wave -r / Tcl command
at the start of a simulation run to capture value changes for all display-able HDL objects in your design.
For more information, see Using the log_wave Tcl Command.
• Go To Instantiation Source Code: For Verilog modules and VHDL entity instances, opens the
source code at the point of instantiation for the selected instance.
• Set Current Scope to Active: Set the current scope to selected scope. The selected scope
becomes the active simulation scope (that is, get_property active_scope
[current_sim]). The active simulation scope is the HDL process scope, where the
simulation is currently paused. When used by disabling the follow active scope in setting,
Vivado simulator remembers the last current_scope selection even when simulation proceeds.
When a breakpoint is hit, current_scope still points to the last scope, which is set as active
scope.
• Log to Wave Database: You can log either of the following:
○ The objects of current scope.
○ The objects of the current scope and all scope below the current scope.
TIP: By default, the Vivado simulator suppresses the logging of large HDL objects. To change the size
limit of logged objects, use the set_property trace_limit <size> [current_sim] Tcl
command, where <size> is the number of scalar elements in the HDL object.
In the source code text editor, you can hover over an identifier in the code to get the value, as
shown in Scope Window.
IMPORTANT! For this feature to work, make sure that you have the scope associated with the source
code selected in the Scope window.
TIP: Because the top module is not instantiated, the Go to Instantiation Source Code right-click option
(shown in the preceding figure) is grayed out when the top module is selected.
TIP: Use log_wave to log the objects of current scope or below. Post simulation, you can add any
objects on the waveform and see the plot starting from time 0 till the current simulation.
In either the Scope or the Sources window, a search field displays when you select the Show
Search button .
As an equivalent to using the Scope and Objects windows, you can navigate the HDL design by
typing the following in the Tcl Console:
get_scopes
current_scope
report_scopes
report_values
TIP: To access source files for editing, you can open files from the Scope or Objects window by selecting Go
to Source Code, as shown in Scope Window.
TIP: After you have edited source code and saved the file, you can click the Relaunch button to
recompile and relaunch simulation without having to close and reopen the simulation.
Objects Window
The Objects window displays the HDL simulation objects associated with the scope selected in
the Scope window, as shown in the following figure.
Icons beside the HDL objects show the type or port mode of each object. This view lists the
Name, Value, and Data Type of the simulation objects.
You can obtain the current value of an object by typing the following in the Tcl Console.
get_value <hdl_object>
TIP: To limit the number of digits to display for vectors, use the set_property
array_display_limit <bits> [current_sim] command, where <bits> is the number of bits
to display.
The following are the options available at the top of the Objects window. Click Settings to view
the selected objects in the Objects window. Use this to filter or limit the contents of the Objects
window.
• Search: You can use the Search option to search for an object name.
• Settings: Settings option allows you to display or hide various HDL objects in the Objects
window.
When you right-click an object in the Objects window, a context menu (shown in Objects
Window) appears. The options in the context menu are described below.
• Add to Wave Window: Add the selected object to the waveform configuration. Alternately,
you can drag and drop the objects from the Objects window to the Name column of the wave
window.
• Log to Wave Database: Logs events of the selected object to the waveform database (WDB)
for later viewing in the wave window.
TIP: By default, the Vivado simulator suppresses the logging of large HDL objects. To change the size
limit of logged objects, use the set_property trace_limit <size> [current_sim] Tcl
command, where <size> is the number of scalar elements in the HDL object.
• Show in Wave Window: Highlights the selected object in the wave window.
• Default Radix: Set the default radix for all objects in the Objects window and text editor. The
default radix is Hexadecimal. You can change this option from the context menu.
Tcl command:
set_property radix <new radix> [current_sim]
• hex
• ascii
• oct
Note: If you need to change the radix of an individual signal, use the radix option from the context
menu.
• Radix: Select the numerical format to use when displaying the value of the selected object in
the Objects window and in the source code window.
You can change the radix of an individual object as follows:
1. Right-click an object in the Objects window.
2. From the context menu, select Radix and the format you want to use:
• Default
• Binary
• Hexadecimal
• Octal
• ASCII
• Unsigned Decimal
• Signed Decimal
• Signed Magnitude
TIP: If you change the radix in the Objects window, it is not be reflected in the wave window.
• Report Drivers: Display in the Tcl Console a report of the HDL processes that assign values to
the selected object.
• Go To Source Code: Open the source code at the definition of the selected object.
• Force Constant: Forces the selected object to a constant value.
• Force Clock: Forces the selected object to an oscillating value.
• Remove Force: Removes any force on the selected object.
TIP: If you observe that some HDL objects do not appear in the Waveform Viewer, it is because Vivado
simulator does not support waveform tracing of some HDL objects, such as named events in Verilog
and local variables.
Related Information
Wave Window
When you invoke the simulator it opens a wave window by default. The wave window displays a
new wave configuration consisting of the traceable HDL objects from the top module of the
simulation, as shown in Wave Window.
TIP: On closing and reopening a project, you must rerun the simulation to view the wave window. If,
however, you unintentionally close the default wave window while a simulation is active, you can restore it
by selecting Window → Waveform from the main menu.
To add an individual HDL object or set of objects to the wave window: in the Objects window,
right-click an object or objects and select the Add to Wave Window option from the context
menu (shown in Objects Window).
Using the add_wave command, you can specify full or relative paths to HDL objects.
For example, if the current scope is /bft_tb/uut, the full path to the reset register under uut
is /bft_tb/uut/reset: the relative path is reset.
TIP: The add_wave command accepts HDL scopes as well as HDL objects. Using add_wave with a
scope is equivalent to the Add To Wave Window command in the Scope window. HDL objects of large bit
width can slow down the display of the waveform viewer. You can filter out such objects by setting a
display limit on the wave configuration before issuing the Add to Wave Window command. To set a display
limit, use the Tcl command set_property DISPLAY_LIMIT <maximum bit width>
[current_wave_config].
Wave Objects
The Vivado IDE Wave window is common across a number of Vivado Design Suite tools. An
example of the wave objects in a waveform configuration is shown in the following figure.
The Wave window displays HDL objects, their values, and their waveforms, together with items
for organizing the HDL objects, such as groups, dividers, and virtual buses.
Collectively, the HDL objects and organizational items are called a wave configuration. The
waveform portion of the Wave window displays additional items for time measurement, which
include cursors, markers, and timescale rulers.
The Vivado IDE traces the value changes of the HDL object in the Wave window during
simulation, and you use the wave configuration to examine the simulation results.
The design hierarchy and the simulation waveforms are not part of the wave configuration, and
are stored in a separate wave database (WDB) file.
When you right-click an object in the Waveform window, a context menu (shown in the following
figure) appears. See Understanding HDL Objects in Waveform Configurations for more
information on HDL objects in Waveforms. The options in the context menu are described
below:
• Go To Source Code: Opens the source code at the definition of the selected design wave
object.
• Show in Object Window: Displays the HDL objects for a design wave object in the Objects
window.
• Report Drivers: Display in the Tcl Console a report of the HDL processes that assign values to
the selected wave object.
• Force Constant: Forces the selected object to a constant value.
• Force Clock: Forces the selected object to an oscillating value.
• Remove Force: Removes any force on the selected object.
• Find: Opens the Find Toolbar in the Waveform window to search for a wave object by name.
• Find Value: Opens the Find Toolbar in the Waveform window to search a waveform for a
value.
• Select All: Selects all the wave objects in the Waveform window.
• Expand: Shows the sub-objects of the selected wave object.
• Collapse: Hides the sub-objects of the selected wave object.
• Ungroup: Unpacks the selected group or virtual bus.
• Rename: Changes the displayed name of the selected wave object.
• Name: Changes the display of the name of the selected wave object to show the full
hierarchical name (long name), the simple signal or bus name (short name), or a custom name.
• Waveform Style: Changes the waveform of the selected design wave object to digital or
analog format.
• Signal Color: Sets the waveform color of the selected design wave object.
• Divider Color: Sets the bar color of the selected divider.
• Radix: Sets the radix in which to display values of the selected design wave objects.
• Show as Enumeration: Shows values of the selected SystemVerilog enumeration wave object
as enumerator labels in place of numbers, whenever possible.
• Reverse Bit Order: Reverses the bit order of values displayed for the selected array wave
object.
• New Group: Packs the selected wave objects into a folder-like group wave object.
• New Divider: Creates a horizontal separator in the list of the Waveform window's wave
objects.
• New Virtual Bus: Creates a new logic vector wave object consisting of the bits of the selected
design wave objects.
• Cut: Allows you to cut a signal in the Waveform window.
• Copy: Allows you to copy a signal in the Waveform window.
• Paste: Allows you to paste a signal in the Waveform window.
• Delete: Allows you to delete a signal in the Waveform window.
See Chapter 5: Analyzing Simulation Waveforms with Vivado Simulator for more information
about using the Wave window.
The new wave configuration is not saved to disk automatically. Select File → Simulation
Waveform → Save Configuration As and supply a file name to save a WCFG file.
To save a wave configuration to a WCFG file, type the Tcl command save_wave_config
<filename.wcfg>.
The specified command argument names and saves the WCFG file.
IMPORTANT! Zoom settings are not saved with the wave configuration.
Related Information
You can set a different Wave window to be the active window by clicking the title of the window.
Related Information
TIP: Availability of popup menu options is dependent on the design development stage. For example, if you
have run synthesis but have not yet run implementation, the implementation options in the popup menu
are grayed out.
You can view Run Simulation → Post-Synthesis Functional Simulation option (shown in the
previous figure) after completing a successful synthesis run.
After synthesis, the general logic design has been synthesized into device-specific primitives.
Performing a post-synthesis functional simulation ensures that any synthesis optimizations have
not affected the functionality of the design. After you select a post-synthesis functional
simulation, the functional netlist is generated, and the UNISIM libraries are used for simulation.
The Run Simulation → Post-Implementation Functional Simulation option (shown in the previous
figure) becomes available after completing implementation run.
After implementation, the design has been placed and routed in hardware. A functional
verification at this stage is useful in determining if any physical optimizations during
implementation have affected the functionality of your design.
After you select a post-implementation functional simulation, the functional netlist is generated
and the UNISIM libraries are used for simulation.
When you run Post-Synthesis and Post-Implementation timing simulation the simulator tools
include:
You defined the overall functionality of the design in the beginning. When the design is
implemented, accurate timing information is available.
• Calls the netlist writer, write_verilog with the -mode timesim switch and write_sdf
(SDF annotator)
• Sends the generated netlist to the target simulator
You control these options using Simulation Settings as described in Using Simulation Settings.
IMPORTANT! Post-Synthesis and Post-Implementation timing simulations are supported for Verilog only.
There is no support for VHDL timing simulation. If you are a VHDL user, you can run post synthesis and
post implementation functional simulation (in which case no SDF annotation is required and the simulation
netlist uses the UNISIM library). You can create the netlist using the write_vhdl Tcl command. For usage
information, refer to the Vivado Design Suite Tcl Command Reference Guide (UG835).
IMPORTANT! The Vivado simulator models use interconnect delays; consequently, additional switches
are required for proper timing simulation, as follows: -transport_int_delays -pulse_r 0 -
pulse_int_r 0
The Run Simulation → Post-Synthesis Timing Simulation option (shown in the previous figure)
becomes available after completing a successful synthesis run.
After synthesis, the general logic design has been synthesized into device-specific primitives, and
the estimated component delays are available. Performing a post-synthesis timing simulation
allows you to see potential timing-critical paths prior to investing in implementation. After you
select a post-synthesis timing simulation, the timing netlist and the estimated delays in the SDF
file are generated. The netlist files includes $sdf_annotate command so that the simulation
tool includes the generated SDF file.
The Run Simulation → Post-Implementation Timing Simulation option (shown in the previous
figure) becomes available after completing implementation run.
After implementation, the design has been implemented and routed in hardware. A timing
simulation at this stage helps determine whether or not the design functionally operates at the
specified speed using accurate timing delays. This simulation is useful for detecting
unconstrained paths, or asynchronous path timing errors, for example, on resets. After you select
a post-implementation timing simulation, the timing netlist and the SDF file are generated. The
netlist files include $sdf_annotate command so that the generated SDF file is picked up.
When you specified simulation settings, you specified whether or not to create an SDF file and
whether the process corner would be set to fast or slow.
TIP: To find the SDF file optional settings, in the Vivado IDE Flow Navigator, right-click Simulation and
select Simulation Settings. In the Settings dialog box, select Simulation category and click Netlist tab.
Based on the specified process corner, the SDF file contains different min and max numbers.
Run two separate simulations to check for setup and hold violations.
To run a setup check, create an SDF file with -process_corner slow, and use the max column from
the SDF file.
To run a hold check, create an SDF file with the -process_corner fast, and use the min column
from the SDF file. The method for specifying which SDF delay field to use is dependent on the
simulation tool you are using. Refer to the specific simulation tool documentation for information
on how to set this option.
To get full coverage run all four timing simulations, specify as follows:
If you add objects to the Wave window and run the simulation, the design hierarchy for the
complete design and the transitions for the added objects are automatically saved to the WDB
file. You can also add objects to the waveform database that are not displayed in the Wave
window using the log_wave command. For information about the log_wave command, see
Using the log_wave Tcl Command.
Closing a Simulation
To close a simulation, in the Vivado IDE:
Select File > Exit or click the X at the top-right corner of the project window.
CAUTION! When there are multiple simulations running, clicking the X on the blue title bar closes all
simulations. To close a single simulation, click the X on the small gray or white tab under the blue title bar.
close_sim
The Tcl command first checks for unsaved wave configurations. If it exists, the command issues
an error. Close or save unsaved wave configurations before issuing the close_sim command, or
add the -force option to the Tcl command.
Note: It is always recommended to use close_sim command to completely close the simulation before
using close_project command to close the current project.
1. Create a Tcl script with the simulation commands you want to add to the simulation source
files. For example, if you have a simulation that runs for 1,000 ns, and you want it to run
longer, create a file that includes:
run 5us
Or, if you want to monitor signals that are not at the top level (because, by default, only top-
level signals are added to the waveform), you can add them to the post.tcl script. For
example:
add_wave/top/I1/<signalName>
Option Description
[-step] Launch a simulation step. Values: all, compile, elaborate, simulate. Default: all (launch all
steps).
[-simset] Name of the simulation fileset.
[-mode] Simulation mode. Values: behavioral, post-synthesis, post-implementation Default: behavioral.
[-type] Netlist type. Values: functional, timing. This is only applicable when the mode is set to post-
synthesis or post-implementation.
[-scripts_only] Only generate scripts.
[-gui] Invoke simulator GUI (applicable for -scripts_only mode).
[-exec] Execute existing script for the step specified with the -step switch.
[-of_objects] Generate compile order file for this object (applicable with -scripts_only option only).
[-absolute_path] Make all file paths absolute with respect to the reference directory.
[-install_path] Custom installation directory path.
[-noclean_dir] Do not remove simulation run directory files.
[-quiet] Ignore command errors.
[-verbose] Suspend message limits during command execution.
[-gcc_install_path] Specify GNU compiler installation directory path for g++/gcc executable.
[-exec] Execute existing script for the step specified with the -step switch.
Examples
• Running behavioral simulation using Vivado simulator.
create_project project_1 project_1 -part xc7vx485tffg1157-1
add_files -norecurse tmp.v
add_files -fileset sim_1 -norecurse testbench.v
import_files -force -norecurse
update_compile_order -fileset sources_1
update_compile_order -fileset sim_1
launch_simulation
Note: The launch_simulation command is natively integrated into the Vivado IDE that can be used for
running a simulation or generating scripts in GUI or Tcl mode. You can also use export_simulation
command for generating scripts only. See Exporting Simulation Files and Scripts for more details.
By default, the launch_simulation command compiles the design files and binds the pre-
compiled IP/simulation models during elaboration. These pre-compiled IP/simulation models can
be compiled with the design as well in the local run directory in which case the relevant source
files of these IP/simulation models will added in the .do/prj/sh file for compilation. To run the
design in non-precompile mode, unselect Project Settings → IP → Precompiled IP simulation
libraries check-box or set the following property to false from the Tcl Console.
Note: When the design is run in a non-precompile mode, the pre-compiled version of the IP/simulation
models that were compiled using compile_simlib are not used.
Use the following steps to modify your design and re-run the simulation:
1. Use the Vivado code editor or other text editor to update and save any necessary source
code changes.
2. Use the Relaunch Simulation button on the Vivado IDE toolbar to re-compile and re-
launch the simulation, as shown in the following figure. You might alternatively use the
relaunch_sim Tcl command to re-compile and re-launch the simulation.
3. If the modified design fails to compile, an error box appears displaying the reason for failure.
The Vivado IDE continues to display the results of the previous run of the simulation in a
disabled state. Return to step 1 to correct the errors and re-launch the simulation again.
IMPORTANT! Relaunching might fail for reasons other than compilation errors, such as in the case of a
file system error. If the Run buttons on the Simulation toolbar is grayed out after a re-launch, indicating
that the simulation is disabled, check the contents of the Tcl Console for possible errors that have
prevented the re-launch from succeeding.
CAUTION! You might also re-launch the simulation using Run Simulation in the Flow Navigator or using
launch_simulation Tcl command. However, using these options might fully close the simulation,
discarding waveform changes and simulation settings such as radix customization.
Note: The Relaunch Simulation button is active only after one successful run of Vivado simulator using
launch_simulation. The Relaunch Simulation button would be grayed out if the simulation is run in a
Batch/Scripted mode.
• The state of the filter buttons and column widths of the Scopes and Objects windows.
• Tcl properties of the simulation, including array display limit, default radix, default time unit for
the run command, and trace limit.
• Radixes and the Show as Enumeration state that you set on HDL objects in the Objects
window.
After you shut down the simulation, the Vivado simulator restores your settings when you
reopen and run the Vivado simulator.
IMPORTANT! Turn off the Clean Up Simulation Files check box in Vivado's Simulation Settings to ensure
that the settings file does not get erased when you relaunch the simulation.
TIP: To revert the settings to their defaults, delete the settings file. You can find the settings file under the
Vivado project directory at <project>.sim/<simset>/<simtype>/xsim.dir/<snapshot>/
xsimSettings.ini . For example, the settings file for the default behavioral simulation run of the BFT
example design would reside at bft.sim/sim_1/behav/xsim.dir/bft_tb_behav/
xsimSettings.ini . Alternatively, turn on the Clean Up Simulation Files check box in the Simulation
Settings.
Default Settings
An AMD Vivado™ project Tcl object supports a few properties that allow you to supply default
settings for cleaned-up or newly created simulations. These simulations do not already have a
settings file. The following list shows the default settings properties of the project:
• XSIM.ARRAY_DISPLAY_LIMIT
• XSIM.RADIX
• XSIM.TIME_UNIT
• XSIM.TRACE_LIMIT
You can view the current values of the properties with the report_property
[current_project] Tcl command and set the values of the properties with the
set_property <property name> <property value> [current_project] Tcl
command. For example, to set the array display limit to 16, use the following command.
When you launch the new or cleaned-up simulation, the simulation Tcl object inherits your
project properties. You can verify it with the following Tcl command:
report_property [current_sim]
IMPORTANT! The project properties apply only to cleaned-up or newly created simulations. After you
have run a simulation of a particular run type and sim set such as sim_1/behav, that simulation retains
a separate copy of the settings for all subsequent launches. The changes to the project properties can no
longer take effect for that simulation. The project properties take effect again only if the simulation is
cleaned up or the settings file is deleted.
Chapter 5
Typically, simulation is set up in a test bench where you define the HDL objects you want to
simulate. For more information about test benches, see Writing Efficient Test Benches (XAPP199).
When you launch the Vivado simulator, a wave configuration displays with top-level HDL
objects. The Vivado simulator populates design data in other areas of the workspace, such as the
Scope and Objects windows. You can then add additional HDL objects, or run the simulation. See
Using Wave Configurations and Windows below.
A wave configuration can have a name or be untitled. The name shows on the title bar of the
wave configuration window. A wave configuration is untitled when it has never been saved to a
file.
See Chapter 4: Simulating with Vivado Simulator for more information about creating new
waveform configurations. Also see Creating and Using Multiple Waveform Configurations for
information on multiple waveforms.
A Wave window opens, displaying waveform data that the simulator finds for the listed wave
objects of the WCFG file.
Tcl command: open_wave_config <waveform_name>
Standalone mode
You can open the WDB file outside Vivado using the following command:
TIP: You can open a WCFG file together with the WDB file by adding -view <WCFG file> to the
xsim command.
Interactive Method
• If a Vivado Design Suite project is loaded, click Flow → Open Static Simulation and select the
WDB file containing the waveform from the previously run simulation.
TIP: A static simulation is a mode of the Vivado simulator in which the simulator displays data from a
WDB file in its windows in place of data from a running simulation.
Programmatic Method
current_fileset
open_wave_database <name>.wdb
IMPORTANT! Vivado simulator can open WDB files created on any supported operating system. It can
also open WDB files created in Vivado Design Suite versions 2014.3 and later. Vivado simulator cannot
open WDB files created in versions earlier than 2014.3 of the Vivado Design Suite.
When you run a simulation and display HDL objects in a Wave window, the running simulation
produces a waveform database (WDB) file containing the waveform activity of the displayed
HDL objects. The WDB file also stores information about all the HDL scopes and objects in the
simulated design. In this mode, you cannot use commands that control or monitor a simulation,
such as run commands, as there is no underlying 'live' simulation model to control.
However, you can view waveforms and the HDL design hierarchy in a static simulation.
You can create multiple wave objects from the same HDL object, and set the display properties
of each wave object separately.
For example, you can set one wave object for an HDL object named myBus to display values in
hexadecimal and another wave object for myBus to display values in decimal.
There are other kinds of wave objects available for display in a waveform configuration, such as
dividers, groups, and virtual buses.
Wave objects created from HDL objects are specifically called design wave objects. These objects
are displayed with a corresponding icon. For design wave objects, the icon indicates whether the
object is a scalar or a compound such as a Verilog vector or VHDL record.
TIP: To view the HDL object for a design wave object in the Objects window, right-click the name of the
design wave object and choose Show in Object Window.
The following figure shows an example of HDL objects in the waveform configuration window.
The design objects display Name and Value.
• Name: By default, shows the short name of the HDL object: the name alone, without the
hierarchical path of the object. You can change the Name to display a long name with a full
hierarchical path or assign it a custom name.
• Value: Displays the value of the object at the time indicated in the main cursor of the wave
window. You can change the formatting, or radix, of the value independent of the formatting
of other design wave objects linked to the same HDL object and independent of the
formatting of values displayed in the Objects window and source code window.
The Scope window provides the ability to add all viewable HDL objects for a selected scope to
the wave window. For information on using the Scope window, see Scope Window.
About Radixes
Understanding the type of data on your bus is important, and to use the digital and analog
waveform options effectively, you need to recognize the relationship between the radix setting
and the data type.
IMPORTANT! Make a change to the radix setting in the window in which you wish to see the change. A
change to the radix of an item in the Objects window does not apply to values in the Wave window or the
Tcl Console. For example, the item wbOutputData[31:0] can be set to Signed Decimal in the objects
window, but it remains set to Binary in the Wave window.
1. In the Waveform window, click the Settings button to open the Waveform Settings.
2. On the General page, click the Default Radix drop-down menu.
3. From the drop-down list, select a radix.
Note: For a description of the usage for Real and Real Settings, see Using Analog Waveforms.
3. From the Tcl Console, to change the numerical format of the displayed values, type the
following Tcl command:
set_property radix <radix> <hdl_object>
Where <radix> is one the following: bin, unsigned, hex, dec, ascii, or oct and where
<wave_object> is an object returned by the add_wave command.
TIP: If you change the radix in the Wave window, it is not reflected in the Objects window.
Bus values are interpreted as numeric values, which are determined by the radix setting on the
bus wave object, as follows:
• Binary, octal, hexadecimal, ASCII, and unsigned decimal radixes cause the bus values to be
interpreted as unsigned integers.
• If any bit in the bus is neither 0 nor 1, the entire bus value is interpreted as 0.
• The signed decimal and signed magnitude radixes cause the bus values to be interpreted as
signed integers.
• Real radixes cause bus values to be interpreted as fixed point or floating point real numbers,
based on settings of the Real Settings dialog box.
1. In the waveform configuration window, select an HDL object, and right-click to open the
popup menu.
2. Select Radix → Real Settings to open the Real Settings dialog box, shown in the following
figure.
You can set the radix of a wave to Real to display the values of the object as real numbers. Before
selecting this radix, you must choose settings to instruct the waveform viewer how to interpret
the bits of the values.
• Fixed Point: Specifies that the bits of the selected bus wave object(s) are interpreted as a fixed
point, signed, or unsigned real number.
• Binary Point: Specifies how many bits to interpret as being to the right of the binary point. If
the Binary Point is larger than the bit width of the wave object, wave object values cannot be
interpreted as fixed point, and when the wave object is shown in Digital waveform style, all
values show as <Bad Radix>. When shown as analog, all values are interpreted as zero.
• Floating Point: Specifies that the bits of the selected bus wave object(s) should be interpreted
as an IEEE floating point real number.
Note: Only single precision and double precision (and custom precision with values set to those of single
and double precision) are supported.
Other values result in <Bad Radix> values as in Fixed Point. Exponent Width and Fraction
Width must add up to the bit width of the wave object, or else <Bad Radix> values result.
TIP: If the row indices separator lines are not visible, you can turn them on in the Using the Waveform
Settings Dialog Box to make them visible.
IMPORTANT! When viewing an HDL bus object as an analog waveform—to produce the expected
waveform, select a radix that matches the nature of the data in the HDL object. For example:
• If the data encoded on the bus is a 2's-compliment signed integer, you must choose a signed
radix.
• If the data is floating point encoded in IEEE format, you must choose a real radix.
To customize the appearance of an analog waveform, right-click an HDL object in the Name
column of the waveform configuration window and select Waveform Style from the drop-down
menu. A popup menu appears, showing the following options:
The Wave window can display analog waveforms only for buses that are 64 bits wide or smaller.
• Row Height: Specifies how tall to make the select wave object(s), in pixels. Changing the row
height does not change how much of a waveform is exposed or hidden vertically, but rather
stretches or contracts the height of the waveform.
When switching between Analog and Digital waveform styles, the row height is set to an
appropriate default for the style (20 for digital, 100 for analog).
TIP: If the row indices separator lines are not visible, enable the checkbox in the Waveform Settings to
turn them on. Using the Waveform Settings Dialog Box for information on how to change the options
settings. You can also change the row height by dragging the row index separator line to the left and
below the waveform name.
• Y Range: Specifies the range of numeric values to be shown in the waveform area.
○ Auto: Specifies that the range should continually expand whenever values in the visible
time range of the window are discovered to lie outside the current range.
○ Fixed: Specifies that the time range is to remain at a constant interval.
○ Min: Specifies the value displayed at the bottom of the waveform area.
Both values can be specified as floating points; however, if the wave object radix is an integer,
the values are truncated to integers.
• Interpolation Style: Specifies how the line connecting data points is to be drawn.
○ Linear: Specifies a straight line between two data points.
○ Hold: Specifies that of two data points, a horizontal line is drawn from the left point to the
X-coordinate of the right point, then another line is drawn connecting that line to the right
data point, in an L shape.
• Off Scale: Specifies how to draw waveform values that lie outside the Y range of the
waveform area.
○ Hide: Specifies that outlying values are not shown, such that a waveform that reaches the
upper or lower bound of the waveform area disappears until values are again within the
range.
○ Clip: Specifies that outlying values be altered so that they are at the top or bottom of the
waveform area. So, a waveform that reaches the upper or lower bound of the waveform
area follows the bound as a horizontal line until values are once again within the range.
○ Overlap: Specifies that the waveform be drawn wherever its values are, even if they lie
outside the bounds of the waveform area and overlap other waveforms, up to the limits of
the Wave window itself.
• Horizontal Line: Specifies whether to draw a horizontal rule at the given value. If the
checkbox is on, a horizontal grid line is drawn at the vertical position of the specified Y value,
if that value is within the Y range of the waveform.
As with Min and Max, the Y value accepts a floating point number but truncates it to an
integer if the radix of the selected wave objects is an integer.
Renaming Objects
You can rename any wave object in the waveform configuration, such as design wave objects,
dividers, groups, and virtual buses.
1. Expand the Name column until you see the entire name.
2. In the Name column, use the scroll bar to view the name.
1. Select one or more signal or bus names. Use Shift+click or Ctrl+click to select many signal
names.
2. Right-click and select Name from the drop-down menu. A popup menu appears, showing the
following options:
• Long to display the full hierarchical name of the design object.
• Short to display only the name of the signal or bus.
• Custom to display the custom name given to the object when renamed. See Changing the
Object Display Name.
TIP: Renaming a wave object changes the name display mode to Custom. To restore the original name
display mode, change the display mode to Long or Short, as described above. Long and Short names
are meaningful only to design wave objects. Other wave objects (dividers, groups, and virtual buses)
display their Custom names by default and display an ID string for their Long and Short names.
1. Select a bus.
2. Right-click and select Reverse Bit Order.
The bus bit order reverses. The Reverse Bit Order command is marked to show that this is the
current behavior.
IMPORTANT! The Reverse Bit Order command operates only on the values displayed on the bus. The
command does not reverse the list of bus elements that appear below the bus when you expand the
bus wave object.
TIP: The index ranges displayed on the Long and Short names of buses indicate the bit order in bus
elements. For example, after applying Reverse Bit Order on a bus bus[0:7], the bus displays
bus[7:0].
1. Select an enumeration
2. Right-click and check Display As Enumeration
1. Select an enumeration
2. Right-click and uncheck Display As Enumeration
Note: Enumeration values for which there is no defined label always display numerically, regardless of
the Display As Enumeration setting. The Display As Enumeration option is enabled only for
SystemVerilog enumeration objects.
• Resizing handles between the Name, Value, and waveform columns of the wave window
• Scroll combinations with the mouse wheel
• Zoom feature buttons in the Wave window sidebar
• Zoom combinations with the mouse wheel
• Vivado IDE Y-Axis zoom gestures
• Vivado simulation X-Axis zoom gestures. See the Vivado Design Suite User Guide: Using the
Vivado IDE (UG893) for more information about using the mouse to pan and zoom.
Note: In contrast to other Vivado Design Suite graphic windows, zooming in a Wave window applies to
the X (time) axis independent of the Y axis. As a result, the Zoom Range X gesture, which specifies a
range of time to which to zoom the window, replaces the Zoom to Area gesture of other Vivado Design
Suite windows.
TIP: Saving a WCFG file records wave window settings in addition to wave objects and markers. Wave
window settings include the Name and Value column widths, zoom level, scroll position, expansion state
of groups and buses, and the position of the main cursor.
Note: You might need to widen the Value column first to widen the Name column if the Value column's
width is already at its minimum.
Reset Zoom
Zoom Out
Y Y
Zoom Zoom
Fit Out
X X
Zoom Zoom
In X
X Range
Zoom
Zoom Y
In
Range
Y
To invoke a zoom gesture, hold down the left mouse button and drag in the direction indicated in
the diagram, where the starting mouse position is the center of the diagram.
• Zoom Out Y: Zooms out in the Y dimension by a power of 2 determined by how far away the
mouse button is released from the starting point. The zoom is performed such that the Y value
of the starting mouse position remains stationary.
• Zoom Y Range: Draws a vertical curtain that specifies the Y range to display when the mouse
is released.
• Zoom In Y: Zooms in toward the Y dimension by a power of 2 determined by how far away
the mouse button is released from the starting point. The zoom is performed such that the Y
value of the starting mouse position remains stationary.
• Reset Zoom Y: Resets the Y range to that of the values currently displayed in the Wave
window and sets the Y Range mode to Auto.
All zoom gestures in the Y dimension set the Y Range analog settings. Reset Zoom Y sets the Y
Range to Auto, whereas the other gestures set the Y Range to Fixed.
From the General tab, you can configure the following Waveform Settings:
• Radix: Sets the numerical format to use for newly-created design wave objects.
• Elide Setting: Controls truncation of signal names that are too long for the Wave window.
○ Left truncates the left end of long names.
○ Middle preserves both the left and right ends, omitting the middle part of long names.
TIP: If the Floating Ruler option appears disabled (unchecked) in the Settings dialog box, use Shift+Click
on the Wave window to make the secondary cursor visible. This action results in enabling the Floating
Ruler option in the Settings dialog box.
• From the Colors tab, you can set colors of items within the waveform.
• Auto: The timescale chooses time units suitable for the wave window's zoom level.
• Default: Displays the time units corresponding to the precision of the simulation that was
determined when the HDL design was compiled.
• Samples: Displays the time in discrete sample numbers instead of fractions of a second (not
available for HDL simulation).
• User: User-defined time units (not available for HDL simulation).
• fs: Displays time units in femtoseconds.
• ps: Displays time units in picoseconds.
• ns: Displays time units in nanoseconds.
• us: Displays time units in microseconds.
• ms: Displays time units in milliseconds.
• s: Displays time units in seconds.
Organizing Waveforms
The following subsections describe the options that let you organize information within a
waveform.
To add a Group:
Note: A group can include dividers, virtual buses, and other groups.
A Group is represented with the Group button . You can move other HDL objects to the group
by dragging and dropping the signal or bus name.
The new Group and its nested wave objects are saved when you save the waveform
configuration file.
• Move Groups to another location in the Name column by dragging and dropping the group
name.
• Remove a Group by highlighting it, right-click, and select Ungroup from the popup menu.
Wave objects formerly in the Group are placed at the top-level hierarchy in the wave
configuration.
Groups can be renamed as well. See Changing the Object Display Name.
CAUTION! The Delete key removes a selected group and its nested wave objects from the wave
configuration.
Using Dividers
Dividers create a visual separator between HDL objects to make certain signals or objects easier
to see. You can add a divider to your wave configuration to create a visual separator of HDL
objects, as follows:
1. In a Name column of the Wave window, click a signal to add a divider below that signal.
2. Right-click and select New Divider.
The new divider is saved with the wave configuration file when you save the file.
Tcl command: add_wave_divider
• To move a Divider to another location in the waveform, drag and drop the divider name.
• To delete a Divider, highlight the divider, and click the Delete key, or right-click and select
Delete from the context menu.
Dividers can be renamed also; see Changing the Object Display Name.
The virtual bus displays a bus waveform, whose values are composed by taking the
corresponding values from the added scalars and arrays in the vertical order that they appear
under the virtual bus and flattening the values to a one-dimensional vector.
1. In a wave configuration, select one or more wave objects to add to a virtual bus.
2. Right-click and select New Virtual Bus from the popup menu.
You can move other logical scalars and arrays to the virtual bus by dragging and dropping the
signal or bus name.
The new virtual bus and its nested items save when you save the wave configuration file. You can
also move it to another location in the waveform by dragging and dropping the virtual bus name.
You can rename a virtual bus; see Changing the Object Display Name.
To remove a virtual bus, and ungroup its contents, highlight the virtual bus, right-click, and select
Ungroup from the popup menu.
CAUTION! The Delete key removes the virtual bus and nested HDL objects within the bus from the wave
configuration.
Analyzing Waveforms
The following subsections describe available features that help you analyze the data within the
waveform.
Using Cursors
Cursors are temporary time markers that can be moved frequently for measuring the time
between two waveform edges.
You can place the main cursor with a single left-click in the Wave window.
To place a secondary cursor, Ctrl+Click, hold the waveform, and drag either left or right. You can
see a flag that labels the location at the top of the cursor. Alternatively, you can hold the Shift
key and click a point in the waveform.
If the secondary cursor is not already on, this action sets the secondary cursor to the present
location of the main cursor and places the main cursor at the location of the mouse click.
Note: To preserve the location of the secondary cursor while positioning the main cursor, hold the Shift key
while clicking. When placing the secondary cursor by dragging, you must drag a minimum distance before
the secondary cursor appears.
Moving Cursors
To move a cursor, hover over the cursor until you see the grab symbol, and click and drag the
cursor to the new location.
As you drag the cursor in the Wave window, you see a hollow or filled-in circle if the Snap to
Transition waveform setting is selected, which is the default behavior.
• A hollow circle under the mouse indicates that you are between transitions in the waveform
of the selected signal.
• A filled-in circle under the mouse indicates that the cursor is locked in on a transition of
the waveform under the mouse or on a marker.
A secondary cursor can be hidden by clicking anywhere in the Wave window where there is no
cursor, marker, or floating ruler.
The Waveform window contains buttons for jumping the main cursor to the next or previous
transition of the selected waveform or from the current position of the cursor.
1. Ensure the wave object in the waveform is active by clicking the name.
This selects the wave object, and the waveform display of the object displays with a thicker
line than usual.
2. Click the Next Transition or Previous Transition buttons in the waveform toolbar (?),
or use the right or left keyboard arrow key to move to the next or previous transition,
respectively.
TIP: You can jump to the nearest transition of a set of waveforms by selecting multiple wave objects
together.
Using Markers
Use a marker when you want to mark a significant event within your waveform in a permanent
fashion. Markers let you measure times relevant to that marked event.
• You add markers to the wave configuration at the location of the main cursor.
1. Place the main cursor at the time where you want to add the marker by clicking in the
Wave window at the time or on the transition.
• You can move the marker to another location in the Wave window using the drag and drop
method. Click the marker label (at the top of the marker or marker line) and drag it to the
location.
○ As you drag the marker in the Wave window, you see a hollow or filled-in circle if the Snap
to Transition option is selected in the Waveform Settings window, which is the default
behavior.
○ A filled-in circle indicates that you are hovering over a transition of the waveform for
the selected signal or over another marker.
○ For markers, the filled-in circle is white.
○ A hollow circle indicates that the marker is locked in on a transition of the waveform
under the mouse or on another marker.
Release the mouse key to drop the marker to the new location.
• You can delete one or all markers with one command. Right-click over a marker, and do one of
the following:
○ Select Delete Marker from the popup menu to delete a single marker.
○ Select Delete All Markers from the popup menu to delete all markers.
You can also use the Delete key to delete a selected marker.
See the Vivado Design Suite help or the Vivado Design Suite Tcl Command Reference Guide
(UG835) for command usage.
You can display (or hide) the floating ruler and drag it to change the vertical position in the Wave
window. The time base (time 0) of the floating ruler is the secondary cursor, or, if there is no
secondary cursor, the selected marker.
The floating ruler is visible only when the secondary cursor or a marker is present.
IMPORTANT! This search feature supports only scalar and vector (1-D) wave objects of a logic type. Logic
types include 2-state and 4-state types of Verilog/SystemVerilog and bit and std_logic of VHDL.
1. In the Name column, select one or more design wave objects (wave objects that have
waveforms).
2. Right-click one of the selected wave objects in either the Name column or Value column and
choose the Find Value option to activate the Find toolbar.
3. On the Find toolbar, choose a radix for your search value from the Radix drop-down list. The
search feature supports the following radixes:
• Binary
• Hexadecimal
• Octal
• Unsigned Decimal
• Signed Decimal
4. In the blank text box on the Find toolbar, enter a value pattern consisting of a string of digits
valid for the radix you chose. Valid digits include numeric digits, VHDL MVL 9 literals (U, X, 0,
1, Z, W, L, H, -), and Verilog literals (0, 1, x, z).
Note: If you enter an invalid digit, the text box turns red, and an error message appears at the right side
of the toolbar. The set of valid numeric digits depends on the radix. For example, if you chose the
Octal radix, numeric digits are those between 0 and 7. Numeric digits for hexadecimal include 0
through 9 and A through F (or a through f). You might enter the special digit '.' to specify a match with
any digit value. For example, the Octal value pattern 12.4 matches occurrences of 1234, 1204, and
12X4 encountered in the waveform.
5. Choose a match style from the following options in the Match drop-down list:
• Exact: Waveform values must contain the same number of digits as in the value pattern to
be considered a match. For example, a value pattern of 1234 matches occurrences of
1234 encountered in the waveform but not 123 or 12345.
TIP: With the Exact match style you might omit leading zeros from the value pattern. For example,
to find the value 0023 in the waveform, you might specify a value pattern of 0023 or simply 23.
• Beginning: Any waveform value whose beginning digits match the value pattern is
considered a match. For example, a value pattern of 1234 matches occurrences of 1234
and 12345 encountered in the waveform but not 1235 or 123. This option is available
only for radixes Binary, Octal, and Hexadecimal.
• End: Any waveform value whose ending digits match the value pattern is considered a
match. For example, a value pattern of “1234” matches occurrences of 1234 and 91234
encountered in the waveform but not 1235 or 234. This option is available only for radixes
Binary, Octal, and Hexadecimal.
• Click the Next button or press the Enter key to move the main cursor forward to the
nearest match, or click the Previous button to move the main cursor backward to the
nearest match. With multiple wave objects selected, the cursor stops on the nearest
match of any of the selected wave objects.
TIP: If there are no matches in the requested direction, the cursor remains stationary and a Value
not found message appears on the right side of the toolbar.
To make it easier to view the transactions, the Vivado simulator provides a feature that analyzes
the signal activity and produces new signals that summarize the activity at the transaction level.
This process is called as protocol analysis. For each AXI interface the Vivado simulator creates a
new design object called a protocol instance that represents the AXI interface and the inputs and
outputs of protocol analysis. The protocol instance typically resides in the same scope as its input
signals.
CAUTION! Some AXI interfaces that are internal to an AXI interconnect might not display correctly in
the wave viewer depending on the configuration of the interconnect. It is recommended that you mark
interfaces only on the boundary of an interconnect.
1. In the Scope window, select the scope containing AXI interface signals.
Note: The scope hierarchy roughly matches your block design.
2. Locate the protocol instance for an AXI interface of a block in your block design. Select the
scope name that matches the instance name of your block.
Perform the following steps to find a protocol instance using the Objects window:
TIP: Protocol instances have a port mode of Internal Signal. To facilitate searching for protocol
instances in the Objects window, you can hide all objects except the Internal Signal object. Click the
gear icon, deselect the Select All check box, and select the Internal Signal check box. To restore the
Objects window, select the Select All check box.
Use the Following Command to Locate All Protocol Instances in the Design:
Use the Following Command to Locate All Protocol Instances in or under a Scope:
Note: To optimize computer resources, the protocol instance does not display its child objects until the
protocol instance is added to the wave window for the first time.
The protocol instances window contains the complete protocol instance list present in a given
design. It has an absolute path to the protocol instance to ensure that an instance with the
same name can be differentiated based on the path.
The protocol instance input signals shown with an orange icon are the aliases of the AXI
signals from the HDL design. Hover over input to see a tooltip giving full path of the alias as
well as the full path of the actual (aliased) signal. From a protocol instance input, you can also
jump the Scope and Objects window to the actual signal. Perform the following steps to go to
the actual signal of a protocol instance input:
1. To view all signal types in the Objects window, click the gear icon and select the Check All
check box.
2. Right click the protocol instance input.
3. Select Go To Actual.
TIP: If you like to save the protocol instance input signals in a wave configuration (WCFG) file, add the
actual signals of the input signals instead. Because the protocol instance inputs and outputs are created
only after a WCFG file is loaded, your saved inputs are missing from the wave configuration. The protocol
instance outputs cannot be saved in a WCFG file.
The protocol instance outputs are shown with a green O icon. These are special signals of the
protocol instance that have no counterparts in the HDL design. The output signals produce
events meaningful only to the wave viewer for displaying transactions.
CAUTION! The set of protocol instance output signals and their contents are subject to change from one
Vivado release to the next. It is recommended not to depend on the specific behavior of protocol instance
output signals when scripting using Tcl.
You can add any protocol instance present in the design to the wave window. Adding a protocol
instance to the wave window causes the Vivado simulator to run protocol analysis on the
protocol instance inputs starting from the simulation time 0 regardless of how much simulation
time has already elapsed. As protocol analysis uses the waveform database (WDB), inputs of all
protocol instances are always traced in the waveform database even if you have not requested
tracing of the inputs or added the protocol instance to the wave window.
In addition to marking an AXI interface in your IP integrator block design as described in Using
the IP Integrator to Mark an AXI Interface to View in the Vivado Simulator section, you can add a
protocol instance to the wave window using the Objects window or a Tcl command.
IMPORTANT! Protocol instances might use more computer resources, it is recommended that you add
just the protocol instances you currently need. You can always add additional protocol instances at a later
time during the simulation without missing the data.
Perform the following steps to add a protocol instance to the Wave window using the Objects
window:
1. To locate the protocol instance in the Objects window, see the steps described in the section
Finding Protocol Instances in the Objects Window.
2. Add the protocol instance to the Wave window in the following two ways:
a. Right click the protocol instance and choose Add to Wave.
b. Drag and drop the protocol instance to the Name column of the Wave window.
Perform the following steps to add a protocol instance to the Wave window using a Tcl
command:
1. To locate the protocol instance in the Objects window, see the steps described in the section
Finding Protocol Instances in the Vivado Simulator.
2. Copy the protocol instance path to the clipboard:
a. If you have located the protocol instance in the Objects window, left-click the protocol
instance to select it and copy the protocol instance path.
b. If you have located the protocol instance in the Tcl Console, use your mouse to select the
protocol instance path and copy it.
c. If you have located the protocol instance using the get_objects Tcl command, use your
mouse to select the text of the protocol instance path in the Tcl Console and copy it.
Alternatively, you can get objects together as described in the following section.
3. Type add_wave and paste the protocol instance name.
TIP: If your protocol instance path contains special characters, surround the path with double braces. For
example, add_wave {{path}}.
and use the list with the add_wave Tcl command to add all the protocol instances in the list:
add_wave $p
or a specific protocol instance from the list using the built-in lindex command as shown in the
following example that adds the first protocol instance of the list:
add_wave [lindex $p 0]
When you add a protocol instance to the wave window, the Vivado simulator creates a hierarchy
of wave objects to represent the protocol instance. You cannot change the structure of the
hierarchy. The type of AXI interface determines the hierarchy.
TIP: You might need to view the protocol instance input signals not included in the wave object hierarchy.
While you cannot add the signals to the hierarchy, you can add them before or after the hierarchy.
Transaction waveforms differ from other types of waveforms. A transaction waveform displays
periods of activity and inactivity of some aspect of the simulated design in contrast with
displaying value changes of a signal over time. The following figure shows an example of a
transaction waveform. A thin line indicates periods of inactivity, while the rectangles represent
periods of activity which are generally called transaction bars. The example in the figure shows
three transaction bars.
As shown in the following figure, the transaction waveform displays a gray bar with the text
Loading while protocol analysis is performed on the inputs of the protocol instance. As the
protocol analysis progresses, the gray bars shrink to reveal newly processed transaction data.
Place your cursor on a transaction bar and left-click to select the transaction bar, which is
highlighted with a double border as shown in the following figure:
If the selected transaction bar is a member of a group of related transaction bars, arrows appear
called associations connecting the related transaction bars. The rest of the objects in the wave
window appear dim to highlight the group of transaction bars. The following figure shows a
selected transaction bar and its related transaction bars connected with associations.
TIP: To reposition the main cursor within a transaction waveform, hold the Ctrl key and left click at the
desired cursor time.
When you click on one end of an association, the selection moves to the transaction bar at the
other end of the association, and the wave window scrolls so that the other end is in view.
Note: The wave window might not scroll if the other end is already in view.
Tool Tips
When you hover over a transaction bar or an association using your mouse, a tooltip displaying
extra information about the transaction bar or association might appear depending on the type
of protocol instance interface.
The top of the wave object hierarchy of an AXI4 protocol instance is the top summary row. This
transaction waveform shows the overall read and write activity of an AXI interface based on the
following rules:
• If one or more AXI read transactions are in progress, the top summary shows a Read
transaction bar in purple color.
• If one or more AXI write transactions are in progress, the top summary shows a Write
transaction bar in pink color.
• If one or more of AXI read and write transactions are in progress, the top summary shows
Read/Write transaction bar in teal color.
An AXI transaction is an abstract concept not to be confused with the graphical transaction bar.
It is a complete data exchange carried out using AXI signaling, including the Address, Data, and
optionally Response phases.
TIP: For performance reasons, the wave viewer does not display the transaction bars in different colors
when zoomed out. Instead, it displays all transaction bars in teal color. You need to zoom in to distinguish
between read and write transactions.
There are a group of outstanding AXI read transactions and a group of write transactions located
under the top of the wave object hierarchy of an AXI4 protocol instance. An AXI transaction is
known as outstanding if the interface master has raised A*VALID or WVALID but the last data
phase or optionally response phase has not yet completed. The outstanding reads row shows the
current count of outstanding AXI read transactions or is inactive (shown as a thin line) to indicate
zero outstanding AXI read transactions. Similarly, the outstanding writes row shows the current
count of outstanding AXI write transactions or is inactive to indicate zero outstanding AXI write
transactions.
There is a set of transaction summary rows under each outstanding read and write row labeled as
Row <n>, where <n> is an integer. A transaction summary is a transaction bar that depicts a
single AXI transaction starting at the first phase and ending at the last phase of an AXI
transaction. The assignment of a transaction summary to a specific numbered row conveys no
special meaning. Instead, it prevents the overlapping of multiple outstanding AXI transactions in
the same row.
TIP: The number of transaction summary rows can increase as simulation progresses. For performance
reasons, the wave window updates the rows only when protocol analysis is complete. To see the latest
state of the rows during simulation without waiting for the entire simulation to complete, you can pause
the simulation and allow the Loading bars to disappear.
Each transaction summary is labeled with a sequence number. The first AXI transaction has a
sequence number of 1, the second AXI transaction has a sequence number of 2, and so on. The
progression of sequence numbers for reads and writes are separate from each other and from the
AXI transactions of all other protocol instances. For example, a particular protocol instance can
have an AXI read transaction with the sequence number 16 and a separate AXI write transaction
with the sequence number 16.
The channels wave object group is collapsed by default. When you expand the group, you see
logic signals for the AXI interface clock and reset (if present) and one transaction row for each
AXI channel present in the interface.
Note: Not all five channels are necessarily present in an AXI interface. For read only interfaces, the write
channels are absent. For write only interfaces, the read channels are absent. Some AXI interfaces that
employ the write channels might omit the response channel if the AXI master has no use of the response
information.
Each channel row shows a transaction bar summarizing individual handshakes of that AXI
channel from VALID to READY, except that the multiple contiguous data beats of the same AXI
transaction appear as a single transaction bar. To visually tie all channel transaction bars of an
AXI transaction together, each channel transaction bar is tagged with the same sequence number
as the corresponding transaction summary. You can expand the channel row to show key AXI
signals for that channel.
TIP: You might need to view protocol instance input signals not included in the wave object hierarchy.
While you cannot add the signals to the hierarchy, you can add them before or after the hierarchy.
TIP: The channel transaction bars appear up to one clock cycle after the corresponding AXI signal event.
The AXI protocol analyzers consider AXI signal events that occur on or after a positive clock edge to take
effect at the following positive clock edge.
When you hover over any channel transaction bar, association, or transaction summary using
your mouse, a tooltip appears showing the values of the informational AXI address channel
signals from the address phase of the AXI transaction.
Note: Optional AXI address channel signals that are absent from the interface are omitted from the tooltip.
When you select a channel transaction bar, associations appear for all channel transaction bars
participating in the same AXI transaction as the selected transaction bar. You can click the tails of
the association arrows to follow the progress of the AXI transaction from address phase through
response phase. The chain of associations always begins with the address phase transaction even
if the data phase precedes the address phase.
Error Conditions
If there is a handshaking error on the interface, you might see a sequence number on a channel
transaction consisting of a string of all 9s. This sequence number indicates that the data and/or
response phases could not be matched with an address and/or data phase. Common causes are
mismatched read/write ID tags and the protocol analyzer being held in reset (ARESET or
ARESETn signal active) while the AXI phases are in progress.
CAUTION! Because certain configurations of an AXI interconnect are optimized for performance rather
than transaction debugging, AXI interfaces internal to an AXI interconnect might respect a different reset
signal than the one connected to the interface causing transaction errors in the wave viewer. If you observe
transaction errors on the interface, it is recommended that you monitor interfaces on the outside of the
interconnect instead.
The wave object hierarchy of an AXI-S interface contains only one transaction row, which is at
the top of the hierarchy. Each transaction bar in the row corresponds to one complete AXI
transaction. The text on the transaction consists of the stream identifier from AXI signal TID and
the coarse routing information from AXI signal TDEST.
The transaction bar contains color-coded stripes to indicate the status of an AXI transaction as
described in the following table.
Under the top transaction row, the wave object hierarchy contains some of the key AXI signals
plus stall and starve status signals to indicate stall and starve conditions. The status signals
provide the same information as the color stripes do in the transaction row.
TIP: The channel transaction bars appear up to one clock cycle after the corresponding AXI signal event.
The AXI protocol analyzers consider AXI signal events that occur on or after a positive clock edge to take
effect at the following positive clock edge.
Error Conditions
A handshaking error produces an error transaction with the text containing all Fs.
Chapter 6
This chapter describes debugging methods and includes Tcl commands that are valuable in the
debug process. There is also a flow description on debugging with third-party simulators.
• Step through the code line by line: For any design at any point in development, you can use
the step command to debug your HDL source code one line at a time to verify that the
design is working as expected. After each line of code, run the step command again to
continue the analysis. For more information, see Stepping Through a Simulation.
• Set breakpoints on the specific lines of HDL code, and run the simulation until a breakpoint is
reached: In larger designs, it can be cumbersome to stop after each line of HDL source code is
run. Breakpoints can be set at any predetermined points in your HDL source code, the
simulation is run (either from the beginning of the test bench or from where you currently are
in the design) and stops are made at each breakpoint. You can use the Step, Run All, or Run
For commands to advance the simulation after a stop. For more information, see the section,
Using Breakpoints, below.
• Set conditions. The tools evaluate each condition and execute Tcl commands when the
condition is true. Use the Tcl command:
add_condition <condition> <instruction>
The line of code is highlighted and an arrow points to the currently executing line of code.
You can also create breakpoints for additional stops while stepping through your simulation. For
more information on debugging strategies in the simulator, see the section, Using Breakpoints,
below.
• From the current running time, select Run > Step, or click the Step button .
The HDL associated with the top design unit opens as a new view in the Wave window.
• From the start (0 ns), restart the simulation. Use the Restart command to reset time to the
beginning of the test bench. See Chapter 4: Simulating with Vivado Simulator.
2. In the waveform configuration window, right-click the waveform or HDL tab and select Tile
Horizontally see the waveform and the HDL code simultaneously.
3. Repeat the Step action until debugging is complete.
As each line is executed, you can see the arrow moving down the code. If the simulator is
executing lines in another file, the new file opens, and the arrow steps through the code. It is
common in most simulations for multiple files to be opened when running the Step command.
The Tcl Console also indicates how far along the HDL code the step command has progressed.
Using Breakpoints
A breakpoint is a user-determined stopping point in the source code that you can use for
debugging the design.
TIP: Breakpoints are particularly helpful when debugging larger designs for which debugging with the Step
command (stopping the simulation for every line of code) might be too cumbersome and time consuming.
You can set breakpoints in executable lines in your HDL file so you can run your code
continuously until the simulator encounters the breakpoint.
Note: You can set breakpoints on lines with executable code only. If you place a breakpoint on a line of
code that is not executable, the breakpoint is not added.
1. Run a simulation.
2. Go to your source file and click the hollow circle to the left of the source line of interest.
A red dot confirms the breakpoint is set correctly.
After the procedure completes, a simulation breakpoint button opens next to the line of code.
Type the Tcl Command: add_bp <file_name> <line_number>
This command adds a breakpoint at <line_number> of <file_name>. See the Vivado
Design Suite help or the Vivado Design Suite Tcl Command Reference Guide (UG835) for
command usage.
Open the HDL source file.
3. Set breakpoints on executable lines in the HDL source file.
4. Repeat steps 1 and 2 until all breakpoints are set.
5. Run the simulation, using a Run option:
• To run from the beginning, use the Run > Restart command.
• Use the Run > Run All or Run > Run For command.
The simulation runs until a breakpoint is reached, then stops.
The HDL source file displays an arrow, indicating the breakpoint stopping point.
6. Repeat Step 4 to advance the simulation, breakpoint by breakpoint, until you are satisfied
with the results.
A controlled simulation runs, stopping at each breakpoint set in your HDL source files.
During design debugging, you can also run the Run > Step command to advance the
simulation line by line to debug the design at a more detailed level.
You can delete a single breakpoint or all breakpoints from your HDL source code.
To remove all breakpoints, either select Run> Delete All Breakpoints or click the Delete All
Breakpoints button .
Adding Conditions
To add breakpoints based on a condition and output a diagnostic message, use the following
commands:
Using the Vivado IDE BFT example design, to stop when the wbClk signal and the reset are
both active-High, issue the following command at start of simulation to print a diagnostic
message and pause simulation when reset goes to 1 and wbClk goes to 1:
In the BFT example, the added condition causes the simulation to pause at 5 ns when the
condition is met and "Reset went to high" is printed to the console. The simulator waits
for the next step or run command to resume the simulation.
-notrace Option
Normally, when you execute the add_condition command, the specified Tcl commands also
echo to the console, log file, and journal file. The -notrace switch causes those commands to
execute silently, suppressing the commands (but not their output) from appearing in those three
places.
puts 'Hello'
the normal behavior of the above command would be to emit the following output in the
console, log file, and journal file:
# puts ‘Hello’
Hello
When you execute -notrace switch, it produces only the following output:
Hello
Pausing a Simulation
While running a simulation for any length of time, you can pause a simulation using the Break
command, which leaves the simulation session open.
To pause a running simulation, select Simulation > Break or click the Break button .
The simulator stops at the next executable HDL line. The line at which the simulation stopped is
displayed in the text editor.
Note: This behavior applies to designs that are compiled with the -debug <kind> switch.
Resume the simulation any time using the Run All, Run, or Step commands. See Stepping
Through a Simulation for more information.
ltrace on
set_property line_tracing true [current_sim]
To turn off line tracing, use one of the following Tcl commands:
ltrace off
set_property line_tracing false [current_sim]
You can display a note on the Tcl console for every process that the simulation encounters while
running. This continuous display of encountered processes is called process tracing.
ptrace on
set_property process_tracing true [current_sim]
To turn off process tracing, use one of the following Tcl commands:
ptrace off
set_property process_tracing false [current_sim]
TIP: A 'force' is both an action (that is, the overriding of HDL-defined behavior on a signal) and also a Tcl
first-class object, something you can hold in a Tcl variable.
You can use force commands on an HDL signal to override the behavior for that signal as defined
in your HDL design. You might, for example, choose to override the behavior of a signal to:
• Supply a stimulus to a test bench signal that the HDL test bench itself is not driving
• Correct a bad value temporarily during debugging (allowing you to continue analyzing a
problem)
• Force Constant
• Force Clock
• Remove Force
The following figure illustrates how the add_force functionality is applied given the following
command:
tc
Current Time
tr
t1
t2
t3
t4
t5
You can get more detail on the command by typing the following in the Tcl Console:
add_force -help
Force Constant
The Force Constant option lets you fix a signal to a constant value, overriding the assignments
made within the HDL code or another previously applied constant or clock force.
Force Constant and Force Clock are options in the Objects or wave window right-click menu (as
shown in the following figure) or in the text editor (source code).
TIP: Double-click an item in the Objects, Sources, or Scope window to open it in the text editor. For
additional information about the text editor, see the Vivado Design Suite User Guide: Using the Vivado IDE
(UG893).
The Force options are disabled for the objects for which the Vivado simulator does not support
forcing. The type of object or limitations in the Vivado simulator's modeling for those objects
might be the cause for not supporting such objects.
TIP: To force a module or entity port whose Force options are disabled, try forcing its connected actual
signal one scope level up. Use the add_force Tcl command (for example, add_force myObj 0) to
view the reason why the options are disabled.
When you select the Force Constant option, the Force Constant dialog box opens so you can
enter the relevant values, as shown in the following figure.
• Signal name: Displays the default signal name, that is, the full path name of the selected
object.
• Value radix: Displays the current radix setting of the selected signal. You can choose one of
the supported radix types: Binary, Hexadecimal, Unsigned Decimal, Signed Decimal, Signed
Magnitude, Octal, and ASCII. The GUI then disallows entry of the values based on the Radix
setting. For example, if you choose Binary, no numerical values other than 0 and 1 are
allowed.
• Force value: Specifies a force constant value using the defined radix value. (For more
information about radixes, see Changing the Default Radix and Using Analog Waveforms.)
• Starting after time offset: Starts after the specified time. The default starting time is zero.
Time can be a string, such as 10 or 10 ns. When you enter a number without a unit, the
Vivado simulator uses the default (ns).
• Cancel after time offset: Cancels after the specified time. Time can be a string such as 10 or
10 ns. If you enter a number without a unit, the default simulation time unit is used.
Tcl command:
add_force /testbench/TENSOUT 1 200 -cancel_after 500
Force Clock
The Force Clock command lets you assign a signal a value that toggles at a specified rate
between two states, in the manner of a clock signal, for a specified length of time. When you
select the Force Clock option in the Objects window menu, the Force Clock dialog box opens, as
shown in the following figure.
The options in the Force Clock dialog box are shown below.
• Signal name: Displays the default signal name; the full path name of the item selected in the
Objects window or waveform.
TIP: The Force Clock command can be applied to any signal (not just clock signals) to define an
oscillating value.
• Value radix: Displays the current radix setting of the selected signal. Select one of the
displayed radix types from the drop-down menu: Binary, Hexadecimal, Unsigned Decimal,
Signed Decimal, Signed Magnitude, Octal, or ASCII.
• Leading edge value: Specifies the first edge of the clock pattern. The leading edge value uses
the radix defined in the Value radix field.
• Trailing edge value: Specifies the second edge of the clock pattern. The trailing edge value
uses the radix defined in the Value radix field.
• Starting after time offset: Starts the force command after the specified time from the current
simulation. The default starting time is 0. Time can be a string, such as 10 or 10 ns. If you
enter a number without a unit, the Vivado simulator uses the default user unit.
• Cancel after time offset: Cancels the force command after the specified time from the current
simulation time. Time can be a string, such as 10 or 10 ns. When you enter a number without
a unit, the Vivado simulator uses the default simulation time unit.
• Duty cycle (%): Specifies the percentage of time that the clock pulse is in an active state. The
acceptable value is a range from 0 to 100 (default is 50%).
• Period: Specifies the length of the clock pulse, defined as a time value. Time can be a string,
such as 10 or 10 ns.
Note: For more information about radixes, see Changing the Default Radix and Using Analog
Waveforms.
Remove Force
Remove Force
To remove any specified force from an object, use the following Tcl command:
You can invoke the following commands to observe the effect of add_force:
add_force /top/I1/sel 1
run 10
add_force /top/I1/sel 0
run all
You can use the add_force Tcl command to force a signal, wire, or register to a specified value:
For more info on this and other Tcl commands, see the Vivado Design Suite Tcl Command Reference
Guide (UG835).
The following is an example Verilog file, top.v, which instantiates a counter. You can use this file
in the following command example.
Command Example
2. Invoke the Vivado Design Suite in Tcl mode, and source the add_force.tcl file.
Observe that the value of out1 increments as well as decrements in the Wave window. You
can observe the waveforms in the Vivado IDE using the start_gui command.
Observe the value of updown signal in the Wave window.
4. In the Tcl Console, type:
remove_forces $force2
run 100
Observe that the value of out1 is not changing because the clk signal is not toggling.
Switching Activity Interchange Format (SAIF) dumping is optimized for AMD power tools and for
use by the report_power Tcl command. The Vivado simulator writes the following HDL types
to the SAIF file. Refer to Power in AMD Devices in the Vivado Design Suite User Guide: Power
Analysis and Optimization (UG907) for additional information.
• Verilog:
○ Input, Output, and Inout ports
• VHDL:
○ Input, Output, and Inout ports of type std_logic, std_ulogic, and bit (scalar, vector,
and arrays).
Note: A VHDL netlist is not generated in the Vivado Design Suite for timing simulations; consequently,
the VHDL sources are for RTL-level code only, and not for netlist simulation.
For RTL-level simulations, only block-level ports are generated and not the internal signals.
For information about power analysis using third-party simulation tools, see Dumping SAIF for
Power Analysis, and Dumping SAIF in VCS in Chapter 3: Simulating with Third-Party Simulators.
1. Compile your RTL code with the -debug typical option to enable SAIF dumping:
xvlog -sv <fileName>.sv
xelab -debug typical top -s mysim
xsim mysim
3. Add the scopes and signals to be generated by typing one of the following Tcl commands:
log_saif [get_objects]
• Only the internal signals of the scope /tb/UUT, use the command:
log_saif [get_objects -filter { type == signal } /tb/UUT/* ]
TIP: This filtering is applicable to all Tcl commands that require HDL objects.
report_drivers <hdl_object>
The command prints drivers (HDL statements doing the assignment) to the Tcl Console along
with current driving values on the right side of the assignment to a wire or signal-type HDL
object.
You can also call the report_drivers command from the Object or Wave window context
menu or text editor. To open the context menu (shown in the following figure), right-click any
signal and click Report Drivers. The result appears in the Tcl console.
For the VCD feature, the Tcl commands listed in the following table model the Verilog system
tasks.
See the Vivado Design Suite Tcl Command Reference Guide (UG835), or type the following in the Tcl
Console:
Note: These commands work for both RTL and SystemC designs.
<command> -help
Example:
open_vcd xsim_dump.vcd
log_vcd /tb/dut/*
log_vcd -include_systemc * /tb/dut/hier1/sc_object
log_vcd -ports * /tb/dut/HDL_signal
run all
close_vcd
quit
You can use the VCD data to validate the output of the simulator to debug simulation failures.
Related Information
TIP: To display object values prior to the time of insertion, the simulation must be restarted. To avoid
having to restart the simulation because of missing value changes: issue the log_wave -r / Tcl command at
the start of a simulation run to capture value changes for all display-able HDL objects in your design.
Syntax:
• Those objects having names that start with a and end in b and have digits in between:
log_wave [get_objects -regexp {^a[0-9]+b$}]
• All objects in the current scope and all child scopes, recursively:
log_wave -r *
• Temporarily overriding any message limits and return all messages from the following
command:
log_wave -v
• Only the internal signals of the scope /tb/UUT, use the command:
log_wave [get_objects -filter {type == signal} /tb/UUT/*]
The wave configuration settings, which include the signal order, name style, radix, and color are
saved to the wave configuration (WCFG) file upon demand. See Chapter 5: Analyzing Simulation
Waveforms with Vivado Simulator.
From the Objects window, you can check to see if a signal is present in the Wave window and
vice versa. Right-click the signal to open the context menu shown in the following figure. Click
Show in Wave Window or Add to Wave Window (if signal is not yet present in the Wave
window).
You can also cross probe a signal from the text editor. Right-click a signal to open the context
menu shown in the figure below. Select Add to Wave Window, Show in Waveform or Show in
Objects. The signal then appears highlighted in the Wave or Objects window.
$HOME/.Xilinx/xsim/xsim_init.tcl
It is useful if you want to set a property across multiple runs. In such a scenario, you can write
these inside a tcl file, and Vivado simulator sources this tcl file before time 0' during execution.
Currently, you can only access these variables if the subprogram is at the top of the call-stack.
Use the following options to support access to variables at any level of the call-stack.
Call Stacks window shows HDL scopes for all the VHDL/Verilog processes in a design that are
waiting inside a subprogram at the current simulation time. This is similar to get_stacks Tcl
command.
By default, the current process in which simulation is stopped (inside a subprogram) is selected in
the Call Stacks window. However, you can select any other processes waiting in a subprogram.
The effect of selecting a process on the Call Stack window is same as selecting a process scope
from the Scope window or using current_scope Tcl command. When you select a process on
the Call Stacks window, the updated process appears in the Scope window, Objects window,
Stack Frames window, and Locals tab. The process name with absolute path and the type of the
selected process is shown in the Call Stacks window.
Stack Frames window shows the current HDL process that is waiting inside a subprogram and
the subprograms in its call-stack. This is similar to report_frames and current_frame Tcl
commands. In the Stack Frames windows, the most recent subprogram in the current hierarchy is
shown at the top, followed by caller subprograms. The caller HDL process is shown at the
bottom. You can select other frames to be current and the effect is the same as the
current_frame –set <selected_frame_index> Tcl command. The Locals tab in the
Objects window follows the subprogram frame selection and shows the static and automatic
variables local to the selected subprogram frame. The frame number, subprogram/process name,
source file, and current line for the selected HDL process are shown in the Stack Frames window.
The Locals tab in Objects window shows the name, value, and type of static and automatic
variables local to the currently executing (or selected) subprogram. This is similar to
get_objects –local Tcl command. This window follows the frame selected in the Stack
Frames window. For every variable/argument, its name, value, and type would be shown in the
Locals tab.
In the SystemVerilog, there are dynamic types such as Class, Dynamic Array, Queue, and
Associative Array, and so on. These dynamic types are supported in the Vivado simulator. Vivado
allows you to probe the dynamic type variables. For example:
module top();
int dynamicArray[];
byte queue[$];
initial
begin
dynamicArray = new[3];
dynamicArray = '{10, 20, 30};
queue.push_back(8'hab);
queue.push_back(8'hff);
#10;
dynamicArray = new[5](dynamicArray);
$display(queue.pop_front());
end
endmodule
You can probe the dynamic type variables using the following windows as shown in the following
figure:
• Objects window
Note: Dynamic types are not supported for tracing waveform (add_wave) or for creating waveform
database (log_wave).
Chapter 7
Vivado supports an integrated simulation flow where the tool can launch Vivado simulator, or a
third party simulator from the IDE. However, many users also want to run simulation in batch or
scripted mode in their verification environment, which might include system-level simulation or
advanced verification such as UVM. The Vivado Design Suite supports batch or scripted
simulation in the Vivado simulator.
This chapter describes a process to gather the needed design files, generate simulation scripts for
your target simulator, and run the simulation in batch mode. The simulation scripts can be
generated for a top-level HDL design, for hierarchical modules, managed IP projects, or block
designs from Vivado IP integrator. Batch simulation is supported in both project and non-project
script-based flow.
The Vivado Design Suite provides an Export Simulation command to let you quickly gather the
design files required for simulation, and generate the simulation scripts for the top-level RTL
design, or a sub-design. The export_simulation command generates scripts for all of the
supported third-party simulators or for the target simulator of your choice.
From within the Vivado IDE, use the File → Export → Export Simulation command to open the
Export Simulation dialog box as shown in the following figure.
The Export Simulation command writes a simulation script file for all supported simulators or for
the specified Target simulator. The generated scripts contain simulator commands for compiling,
elaborating, and simulating the design.
The features of the Export Simulation dialog box include the following:
• Target simulator: Specifies all simulators, or a specific simulator to generate command line
scripts for. Target simulators include Vivado simulator as well as various supported third-party
simulators. Refer to Chapter 3: Simulating with Third-Party Simulators for more information.
Note: On the Windows operating system, scripts are only generated for those simulators that run on
Windows.
Note: In the command line mode, the equivalent option, -simulator, has a value called all that generates
the scripts for all supported simulators. This is supported for the command line only and not in the GUI.
• Compiled library location: To perform a simulation with the script generated by Export
Simulation, your simulation libraries must first be compiled with the compile_simlib Tcl
command. The generated scripts automatically include the setup files needed for the target
simulator from the compiled library directory. Refer to Compiling Simulation Libraries for more
information.
TIP: It is recommended to provide the path to the Compile library location whenever running Export
Simulation. This ensures that the scripts always point to the correct simulation libraries.
• Export directory: Specifies the output directory for the scripts written by Export Simulation.
By default, the simulation scripts are written to the local directory of the current project.
• Overwrite files: Overwrites the files of the same name that already exist in the export
directory.
• Use absolute paths: By default, source files and directory paths in the generated scripts are
relative to a reference directory that is defined in the scripts. Use this switch to make file
paths in the script absolute rather than relative.
• Copy source files to export directory: Copy design files to the output directory. This copies
the simulation source files as well as the generated scripts to make the entire simulation folder
more portable.
• Command: This field provides the Tcl command syntax for the export_simulation
command that are run as a result of the various options and settings that you have specified in
the Export Simulation dialog box.
• Help: For detailed information on various options in Export Simulation Files dialog box, click
the Help button.
The Export Simulation command supports both project and non-project designs. It does not read
properties from the current project to query for Verilog defines and includes directories. Instead,
the Export Simulation command gets directives from the dialog box or from
export_simulation command options. You must specify the appropriate options to get the
results you want. In addition, you must have output products generated for all IP and BD that are
used in the top-level design.
IMPORTANT! The export_simulation command does not generate output products for IP and BD
if they do not exist. Instead, it returns an error and exits.
When you click OK on the Export Simulation dialog box, the command gets the simulation
compile order of all design files required for simulating the specified design object: the top-level
design, a hierarchical module, IP core, a block design from Vivado IP integrator, or a Managed IP
project with multiple IP. The simulation compile order of the required design files is exported to a
shell script with compiler commands and options for the target simulator.
The simulation scripts are written to separate folders in the Export directory as specified in the
Export Simulation dialog box. A separate folder is created for each specified simulator, and
compile, elaborate, and simulate scripts are written for the simulator.
The scripts generated by the Export Simulation command uses a 3-step process, analyze/
compile, elaborate, and simulate, that is common to many simulators including the Vivado
simulator. However, for ModelSim and Riviera, the generated scripts use the two-step process of
compile and simulate that the tool requires.
TIP: To use the two-step process in the Questa simulator, you can start with the scripts generated for
ModelSim and modify them as needed.
The Export Simulation command also copies data files (if any) from the fileset, or from an IP, to
the specified export directory. If the design contains Verilog sources, then the generated script
also copies the glbl.v file from the Vivado software installation path to the output directory.
When you run the Export Simulation command from the dialog box, the Vivado IDE actually runs
a sequence of commands that defines the base directory (or location) for the exported scripts,
exports the IP user files, and then runs the export_simulation command.
The export_ip_user_files command is run automatically by the Vivado IDE to ensure that
all required files needed to support simulation for both core container and non-core container IP,
as well as block designs, are available. See this link in the Vivado Design Suite User Guide: Designing
with IP (UG896) for more information. While export_ip_user_files is run automatically
when working with the Export Simulation dialog box, you must be sure to run it manually before
running the export_simulation command.
TIP: The -no_script option is specified when export_ip_user_files is run automatically by the
Vivado IDE. This is to prevent the generation of simulation scripts for the individual IP and BDs that are
used in the top-level design because it can add significant run time to the command. However, you can
generate these simulation scripts for individual IP and BD by running export_ip_user_files on
specified objects (-of_objects), or without the -no_script option.
The export_ip_user_files command sets up the user file environment for IP and block
design needed for simulation and synthesis. The command creates a folder called
ip_user_files, which contains instantiation templates, stub files for use with third-party
synthesis tools, wrapper files, memory initialization files, and simulation scripts.
The export_ip_user_files command also consolidates static simulation files that are
shared across all IP and block designs in the project and copies them to an ipstatic folder.
Many of the IP files that are shared across multiple IP and BDs in a project do not change for
specific IP customizations. These static files are copied into the ipstatic directory. The scripts
created for simulation reference the shared files in this directory as needed. The dynamic
simulation files that are specific to an IP customization are copied to the IP folder. See
Understanding IP User Files in Vivado Design Suite User Guide: Designing with IP (UG896) for more
information.
IMPORTANT! The scripts and files generated by the export_simulation command point to the files
in the ip_user_files directory. You must run the export_ip_user_files command before you
run export_simulation or simulation errors might occur.
export_ip_user_files -no_script
export_simulation -of_objects [get_filesets sim_1] -directory C:/test_sim \
-simulator questa
Or, export the ip_user_files for all IP and BDs in the design:
You can also generate simulation scripts for block design objects:
IMPORTANT! You must have output products generated for all IP and BD that are used in the top-level
design. The export_simulation command does not generate output products for IP and BD if they
do not exist. Instead, it returns an error and exits.
The Managed IP Project shown above features four different customized IP: blk_mem_gen_0,
c_addsub_0, fifo_generator_0, xdma_0. For this project, the Vivado Design Suite creates
an ip_user_files folder as shown in the following figure.
The simulation scripts for your target simulator, or for all supported simulators, are located in
the ./sim_scripts folder as seen in Exporting a Manage IP Project. You can go to the folder
of your target simulator and incorporate the compile, elaborate, and simulate scripts into
your simulation flow.
The Vivado tool consolidates all the shared simulation files, used by multiple IP and BD in the
design, into a folder called ./ipstatic. The dynamic files that vary depending on the specifics
of an IP customization are located in the ./ip folder.
TIP: In addition to exporting all the IP in a Manage IP project, you can use the steps outlined in Exporting
IP from the AMD Catalog and Block Designs to generate scripts for individual IP in the project.
For timing simulation, there are additional steps and data required to complete the simulation, as
described in the following:
xvhdl
xvhdl Syntax
xvhdl
[-encryptdumps]
[-f [-file] <filename>]
[-h [-help]
[-initfile <init_filename>]
[-L [-lib] <library_name> [=<library_dir>]]
[-log <filename>]
[-nolog]
[-prj <filename>]
[-relax]
[-v [verbose] [0|1|2]]
[-version]
This command parses the VHDL source file(s) and stores the parsed dump into a HDL library on
disk.
xvhdl Examples
xvlog
The xvlog command is the Verilog parser. The xvlog command parses the Verilog source file(s)
and stores the parsed dump into an HDL library on disk.
xvlog Syntax
xvlog
[-d [define] <name>[=<val>]]
[-encryptdumps]
[-f [-file] <filename>]
[-h [-help]]
[-i [include] <directory_name>]
[-initfile <init_filename>]
[-L [-lib] <library_name> [=<library_dir>]]
[-log <filename>]
[-nolog]
[-noname_unamed_generate]
[-relax]
[-prj <filename>]
[-sourcelibdir <sourcelib_dirname>]
[-sourcelibext <file_extension>]
[-sourcelibfile <filename>]
[-sv]
[-v [verbose] [0|1|2]]
[-version]
[-work <library_name> [=<library_dir>]
[-incr]
[-nosignalhandlers]
[-uvm_version arg]
xvlog Examples
Note: xelab, xvlog, and xvhdl are not Tcl commands. The xvlog, xvhdl, xelab are Vivado-
independent compiler executables. Hence, there is no Tcl command for them.
The simulation launching is Vivado dependent and hence, is done through xsim Tcl command.
For usage of simulation outside Vivado, an executable by the same name as xsim is provided.
The xsim executable launches Vivado in project less mode and executes xsim Tcl command to
launch simulation. Hence, to get help on xvlog, xvhdl, xelab form within Vivado IDE, precede
the command with exec.
• In the first phase, the simulator compiler xelab, compiles your HDL model into a snapshot,
which is a representation of the model in a form that the simulator can execute.
• In the second phase, the simulator loads and executes (using the xsim command) the
snapshot to simulate the model. In Non-Project Mode, you can reuse the snapshot by skipping
the first phase and repeating the second.
When the simulator creates a snapshot, it assigns the snapshot a name based on the names of
the top modules in the model. However, you can override the default by specifying a snapshot
name as an option to the compiler. Snapshot names must be unique in a directory or SIMSET;
reusing a snapshot name, whether default or custom, results in overwriting a previously-built
snapshot with that name.
IMPORTANT! You cannot run two simulations with the same snapshot name in the same directory or
SIMSET.
xelab
The xelab command, for given top-level units, does the following:
• Loads children design units using language binding rules or the -L <library> command line
specified HDL libraries
• Performs a static elaboration of the design (sets parameters, generics, puts generate
statements into effect, and so forth)
• Generates executable code
• Links the generated executable code with the simulation kernel library to create an executable
simulation snapshot
Then use the produced executable simulation snapshot name as an option to the xsim command
along with other options to effect HDL simulation.
TIP: xelab can implicitly call the parsing commands, xvlog and xvhdl . You can incorporate the
parsing step by using the xelab -prj option. See Project File (.prj) Syntax for more information about
project files.
Note: xelab, xvlog, and xvhdl are not Tcl commands and are Vivado-independent compiler executables.
Hence, there is no Tcl command for them.
xelab
[-d [define] <name>[=<val>]
[-debug <kind>]
[-f [-file] <filename>]
[-generic_top <value>]
[-h [-help]
[-i [include] <directory_name>]
[-initfile <init_filename>]
[-log <filename>]
[-L [-lib] <library_name> [=<library_dir>]
[-maxdesigndepth arg]
[-mindelay]
[-typdelay]
[-maxarraysize arg]
[-maxdelay]
[-mt arg]
[-nolog]
[-noname_unnamed_generate]
[-notimingchecks]
[-nosdfinterconnectdelays]
[-nospecify]
[-O arg]
[-override_timeunit]
[-override_timeprecision]
[-prj <filename>]
[-pulse_e arg]
[-pulse_r arg]
[-pulse_int_e arg]
[-pulse_int_r arg]
[-pulse_e_style arg]
[-r [-run]]
[-R [-runall]]
[-rangecheck]
[-relax]
[-s [-snapshot] arg]
[-sdfnowarn]
[-sdfnoerror]
[-sdfroot <root_path>]
[-sdfmin arg]
[-sdftyp arg]
[-sdfmax arg]
[-sourcelibdir <sourcelib_dirname>]
[-sourcelibext <file_extension>]
[-sourcelibfile <filename>]
[-stats]
[-timescale]
[-timeprecision_vhdl arg]
[-transport_int_delays]
[-v [verbose] [0|1|2]]
[-version]
[-sv_root arg]
[-sv_lib arg]
[-sv_liblist arg]
[-dpiheader arg]
[-driver_display_limit arg]
[-dpi_absolute]
[-incr]
[-93_mode]
[-nosignalhandlers]
[-dpi_stacksize arg]
[-transform_timing_checkers]
[-a[ --standalone]
[-ignore_assertions]
[-ignore_coverage]
[-cov_db_dir arg]
[-cov_db_name arg]
[-uvm_version arg]
[-report_assertion_pass]
[-dup_entity_as_module]
[-cc_celldefines]
[-cc_libs]
[-cc_type arg]
[-cov_db_dir arg]
[-cov_db_name arg]
[-ignore_localparam_override]
[-sc_lib arg]
[-sc_root arg]
xelab Examples
xelab work.top1 work.top2 -s cpusim
xelab lib1.top1 lib2.top2 -s fftsim
xelab work.top1 work.top2 -prj files.prj -s pciesim
xelab lib1.top1 lib2.top2 -prj files.prj -s ethernetsim
1. A library specified by the 'uselib directive in the Verilog code. For example:
module
full_adder(c_in, c_out, a, b, sum)
input c_in,a,b;
output c_out,sum;
wire carry1,carry2,sum1;
`uselib lib = adder_lib
half_adder adder1(.a(a),.b(b),.c(carry1),.s(sum1));
half_adder adder1(.a(sum1),.b(c_in),.c(carry2),.s(sum));
c_out = carry1 | carry2;
endmodule
• If a VHDL unit is found, the xelab command binds it and the search stops.
• If xelab does not find a VHDL unit, it treats the case-preserved component name as a Verilog
module name and continues a case-sensitive search in the user-specified list and order of
unified logical libraries. The command selects the first matching the name, then stops the
search.
• If case sensitive search is not successful, xelab performs a case-insensitive search for a
Verilog module in the user-specified list and order of unified logical libraries. If a unique
binding is found for any one library, the search stops.
`uselib Syntax
The `uselib lib directive cannot be used with any of the Verilog-XL `uselib directives. For
example, the following code is illegal:
The order in which libraries are specified determines the search order. For example:
Specifies that the search for an instantiated module is made in mylib first, followed by
yourlib.
Like the directives, such as `uselib dir, `uselib file, and `uselib libext, the
`uselib lib directive is persistent across HDL files in a given invocation of parsing and
analyzing, just like an invocation of parsing is persistent. Unless another `uselib directive is
encountered, a `uselib (including any Verilog XL `uselib) directive in the HDL source
remains in effect. A `uselib without any argument removes the effect of any currently active
`uselib <lib|file|dir|libext>.
The following module search mechanism is used for resolving an instantiated module or UDP by
the Verific Verilog elaboration algorithm:
• First, search for the instantiated module in the ordered list of logical libraries of the currently
active `uselib lib (if any).
• If not found, search for the instantiated module in the ordered list of libraries provided as
search libraries in xelab command line.
• If not found, search for the instantiated module in the library of the parent module. For
example, if module A in library work instantiated module B of library mylib and B
instantiated module C, then search for module C in the /mylib, library, which is the library of
B (parent of C).
• If not found, search for the instantiated module in the work library, which is one of the
following:
`uselib Examples
File half_adder.v compiled into File full_adder.v compiled into Logical Library Named
Logical Library Named adder_lib Work
Used by
Command Option Description
Command
-d [define] <name>[=<val>] Define Verilog macros. Use -d|--define for each xelab
Verilog macro. The format of the macro is Parsing Design Files,
<name>[=<val>], where <name> is name of the macro xvhdl and xvlog
and <value> is an optional value of the macro.
-debug <kind> Compile with specified debugging ability turned on. xelab
The <kind> options are:
Used by
Command Option Description
Command
-encryptdumps Encrypt parsed dump of design units being compiled. Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-f [-file] <filename> Read additional options from the specified file. xelab
xsim Executable
Options
Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-generic_top <value> Override generic or parameter of a top-level design xelab
unit with specified value. For example, -generic_top
"P1=10"
-h [-help] Print this help message. xelab
xsim Executable
Options
Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-i [include] <directory_name> Specify directories to be searched for files included xelab
using Verilog `include. Use -i|--include for each Parsing Design Files,
specified search directory. xvhdl and xvlog
-initfile <init_filename> User-defined simulator initialization file to add to or xelab
override settings provided by the default xsim.ini Parsing Design Files,
file. xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-L [-lib] <library_name> Specify search libraries for the instantiated non-VHDL xelab
[=<library_dir>] design units. For example, a Verilog design unit. Parsing Design Files,
Use -L|--lib for each search library. The format of xvhdl and xvlog
the argument is <name>[=<dir>], where <name> is Parsing Design Files,
the logical name of the library and <library_dir> is xvhdl and xvlog
an optional physical directory of the library.
-log <filename> Specify the log file name. Default: <xvlog|xvhdl| xelab
xelab|xsim>.log. xsim Executable
Options
Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-maxarraysize <arg> Set maximum vhdl array size to be 2**n (Default: n = xelab
28, which is 2**28).
-maxdelay Compile Verilog design units with maximum delays. xelab
-maxdesigndepth <arg> Override maximum design hierarchy depth allowed by xelab
the elaborator (Default: 5000).
-maxlogsize <arg> Set the maximum size a log file can reach in MB. The xsim Executable
default setting is unlimited. Options
-mindelay Compile Verilog design units with minimum delays. xelab
Used by
Command Option Description
Command
-mt <arg> Specifies the number of sub-compilation jobs which xelab
can be run in parallel. Possible values are auto, off, or
an integer greater than 1.
If auto is specified, xelab selects the number of
parallel jobs based on the number of CPUs on the host
machine. (Default = auto.)
Advanced usage: to further control the -mt option, you
can set the Tcl property as follows:
• -O 0 = Disable optimizations
-override_timeunit Override timeunit for all Verilog modules, with the xelab
specified time unit in -timescale option.
-override_timeprecision Override time precision for all Verilog modules, with xelab
the specified time precision in -timescale option.
-pulse_e <arg> Path pulse error limit as percentage of path delay. xelab
Allowed values are 0 to 100 (Default is 100).
-pulse_r <arg> Path pulse reject limit as percentage of path delay. xelab
Allowed values are 0 to 100 (Default is 100).
Used by
Command Option Description
Command
-pulse_int_e arg Interconnect pulse reject limit as percentage of delay. xelab
Allowed values are 0 to 100 (Default is 100).
-pulse_int_r <arg> Interconnect pulse reject limit as percentage of delay. xelab
Allowed values are 0 to 100 (Default is 100).
-pulse_e_style <arg> Specify when error about pulse being shorter than xelab
module path delay should be handled. Choices are:
Default: onevent
-prj <filename> Specify the Vivado simulator project file containing one xelab
or more entries of vhdl|verilog <work lib> <HDL Parsing Design Files,
file name>. xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-r [-run] Run the generated executable snapshot in command- xelab
line interactive mode.
-rangecheck Enable runtime value range check for VHDL. xelab
-R [-runall] Run the generated executable snapshot until the end xelab
of simulation. xsim Executable
Syntax
-relax Relax strict language rules. xelab
Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-s [-snapshot] <arg> Specify the name of output simulation snapshot. xelab
Default is <worklib>.<unit>; for example:
work.top. Additional unit names are concatenated
using #; for example: work.t1#work.t2.
-sdfnowarn Do not emit SDF warnings. xelab
-sdfnoerror Treat errors found in SDF file as warning. xelab
-sdfmin <arg> <root>=<file> SDF annotate <file> at <root> with xelab
minimum delay.
-sdftyp <arg> <root>=<file> SDF annotate <file> at <root> with xelab
typical delay.
-sdfmax <arg> <root>=<file> SDF annotate <file> at <root> with xelab
maximum delay.
-sdfroot <root_path> Default design hierarchy at which SDF annotation is xelab
applied.
-sourcelibdir Directory for Verilog source files of uncompiled xelab
<sourcelib_dirname> modules. Parsing Design Files,
Use -sourcelibdir <sourcelib_dirname> for each xvhdl and xvlog
source directory.
Used by
Command Option Description
Command
-sourcelibext <file_extension> File extension for Verilog source files of uncompiled xelab
modules. Parsing Design Files,
Use -sourcelibext <file extension> for source xvhdl and xvlog
file extension.
-sourcelibfile <filename> File name of a Verilog source file with uncompiled xelab
modules. Parsing Design Files,
xvhdl and xvlog
-stat Print tool CPU and memory usages, and design xelab
statistics.
-sv Compile input files in SystemVerilog mode. Parsing Design Files,
xvhdl and xvlog
-timescale Specify default timescale for Verilog modules. Default: xelab
1ns/1ps.
-timeprecision_vhdl <arg> Specify time precision for vhdl designs. Default: 1ps. xelab
-transport_int_delays Use transport model for interconnect delays. xelab
-typdelay Compile Verilog design units with typical delays xelab
(Default).
-v [verbose] [0|1|2] Specify verbosity level for printing messages. Default = xelab
0. Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-version Print the compiler version to screen. xelab
xsim Executable
Options
Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
-work <library_name> Specify the work library. The format of the argument is Parsing Design Files,
[=<library_dir>] <name>[=<dir>] where: xvhdl and xvlog
Parsing Design Files,
• <name> is the logical name of the library. xvhdl and xvlog
-sv_root <arg> Root directory of which DPI libraries are to be found. xelab
Default: <current_directory/xsim.dir/xsc>
--sc_lib arg Shared library name for SystemC functions; (.dll/.so) xelab
without the file extension
--sc_root <arg> Root directory of which SystemC libraries are to be xelab
found. Default: <current_directory>/xsim.dir/
work/xsc
-sv_lib <arg> Shared library name for DPI imported functions xelab
(.dll/.so) without the file extension.
-sv_liblist <arg> Bootstrap file pointing to DPI shared libraries. xelab
-dpiheader <arg> Header filename for the exported and imported xelab
functions.
Used by
Command Option Description
Command
-driver_display_limit <arg> Enable driver debugging for signals with maximum size xelab
(Default: n = 65536).
-dpi_absolute Use absolute paths instead of LD_LIBRARY_PATH on xelab
Linux for DPI libraries that are formatted as
lib<libname>.so.
-incr Enable incremental analysis/elaboration in simulation. Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
xelab
-93_mode Compile VHDL in pure 93 mode. Parsing Design Files,
xvhdl and xvlog
xelab
-2008 Compile VHDL file in 2008 mode. Parsing Design Files,
xvhdl and xvlog
-nosignalhandlers Do not allow compiler to trap Antivirus, firewall signal. Parsing Design Files,
xvhdl and xvlog
Parsing Design Files,
xvhdl and xvlog
xelab
-dpi_stacksize <arg> User defined stack size for DPI task. xelab
-transform_timing_checkers Transform timing checker to Verilog process. xelab
-a Generate a standalone non-interactive simulation xelab
executable that performs run-all.
Always use with -R.
To run the simulation faster without any debug
capability, use -standalone with -R. It invokes the
Simulation standalone without invoking Vivado IDE.
This option saves the license loading time.
-ignore_assertions Ignore SystemVerilog concurrent assertions. xelab
-ignore_coverage Ignore SystemVerilog functional coverage. xelab
-cov_db_dir <arg> Functional coverage database dump directory. The xelab
coverage data is present under <arg>/xsim.covdb/
<cov_db_name> directory. Default is ./.
-cov_db_name <arg> Functional coverage database name. The coverage data xelab
is present under <cov_db_dir>/xsim.covdb/<arg>
directory. Default is a snapshot name.
-uvm_version <arg> Specify UVM version (default 1.2). Parsing Design Files,
xvhdl and xvlogxelab
-report_assertion_pass Report SystemVerilog Concurrent Assertions Pass, even xelab
if there is no pass action block.
-dup_entity_as_module Enable support for hierarchical references inside the xelab
Verilog hierarchy in mixed language designs.
Used by
Command Option Description
Command
-cc_celldefines Specify if code coverage information needs to be xelab
captured for libs/modules with cell define attribute set.
OFF by default.
-cc_libs Specify if code coverage information needs to be xelab
captured for all the libraries specified. OFF by default.
-cc_type arg Specify options for generating Code Coverage Statistics xelab
-bcesfxt. (s)Statement Coverage, (b)Branch Coverage,
(c)Condition Coverage Supported.
-ignore_localparam_override Ignore localparam override xelab
Where:
CAUTION! Use this option only if your security software prevents the simulator
from running successfully.
TIP: When running the xelab, xsc, xsim, xvhdl, xcrg, or xvlog commands in batch files or scripts,
it might also be necessary to define the XILINX_VIVADO environment variable to point to the installation
hierarchy of the Vivado Design Suite. To set the XILINX_VIVADO variable, add one of the following to your
script or batch file:
Note: Currently, Vivado simulator only supports these features for SystemVerilog and Verilog code. VHDL
is not supported yet.
xcrg Examples
# Functional Coverage with one DUT and one TB generating html and text
reports
xelab -svlog DUT1.v -svlog TB1.v -cov_db_dir ./fRun1 -cov_db_name DB1 -R
xcrg -dir ./fRun1/ -db_name DB1 -report_dir ./fReport1 -report_format html
firefox ./fReport1/dashboard.html &
xcrg -dir ./fRun1/ -db_name DB1 -report_dir ./fReport1 -report_format text
gvim ./fReport1/xcrg_report.txt
# Merging Functional Coverage runs of one DUT and 2 TBs generating merged
html report (using TB from previous example)
xelab -svlog DUT1.v -svlog TB2.v -cov_db_dir ./fRun2 -cov_db_name DB2 -R
xcrg -dir ./fRun1 -db_name DB1 -dir ./fRun2 -db_name DB2 -merge_dir ./
fMerge1 -merge_db_name mDB1 -report_dir ./mfReport1
firefox ./mfReport1/dashboard.html &
# Other examples
xcrg -h
xcrg -file /path/to/file
xcrg -file /path/to/file -db_name work.top
xcrg -dir /path/to/abc
xcrg -dir ./abc -report_dir def -report_format html
xcrg -dir ./abc -db_name work.top -report_dir def -report_format html
xcrg -dir /path/to/abc -db_name work.top -report_dir def -report_format text
xcrg -merge_dir m
xcrg -merge_db_name xyz -report_dir def
xcrg -report_format html -nolog
xcrg -report_format html -log xcrgOutput.log
xcrg -cov_db_name a1 -cov_db_dir ./
xcrg -report_dir abc -cov_db_name work.testbench -cov_db_dir ./xsim.codeCov/
Table 18: File Types and Associated Commands for Design File Analysis
IMPORTANT! You can provide multiple top-level design unit names with xelab . To use the Vivado
simulator workspace for purposes similar to those used during launch_simulation, you must set
debug level to typical.
You can provide multiple wcfg files using multiple -view flags. For example:
To parse design files using a project file, create a text file called <proj_name>.prj, and use the
syntax shown below inside the project file.
Where:
<work_library>: Is the library into which the HDL files on the given line are to be compiled.
<file_names>: Are Verilog source files. You can specify multiple Verilog files per line.
<file_name>: Is a VHDL source file; specify only one VHDL file per line.
1. For Verilog or SystemVerilog: [-d <macro>] provides the option to define one or more
macros.
2. For Verilog or SystemVerilog: [-i <include_path>] provides the option to define one or
more <include_path> directories.
Predefined Macros
XILINX_SIMULATOR is a Verilog predefined-macro. The value of this macro is 1. Predefined
macros perform tool-specific functions, or identify which tool to use in a design flow. The
following is an example of usage:
`ifdef VCS
// VCS specific code
`endif
`ifdef INCA
// NCSIM specific code
`endif
`ifdef MODEL_TECH
// MODELSIM specific code
`endif
`ifdef XILINX_ISIM
// ISE Simulator (ISim) specific code
`endif
`ifdef XILINX_SIMULATOR
The compilers attempt to read xsim.ini from these locations in the following order:
<logical_library1> = <physical_dir_path1>
<logical_library2> = <physical_dir_path2>
std=<Vivado_Install_Area>/xsim/vhdl/std
ieee=<Vivado_Install_Area>/xsim/vhdl/ieee
vl=<Vivado_Install_Area>/xsim/vhdl/vl
ieee_proposed=$RDI_DATADIR/xsim/vhdl/ieee_proposed
synopsys=<Vivado_Install_Area>/xsim/vhdl/synopsys
uvm=<Vivado_Install_Area>/xsim/system_verilog/uvm
unisim=<Vivado_Install_Area>/xsim/vhdl/unisim
unimacro=<Vivado_Install_Area>/xsim/vhdl/unimacro
unifast=<Vivado_Install_Area>/xsim/vhdl/unifast
simprims_ver=<Vivado_Install_Area>/xsim/verilog/simprims_ver
unisims_ver=<Vivado_Install_Area>/xsim/verilog/unisims_ver
unimacro_ver=<Vivado_Install_Area>/xsim/verilog/unimacro_ver
unifast_ver=<Vivado_Install_Area>/xsim/verilog/unifast_ver
secureip=<Vivado_Install_Area>/xsim/verilog/secureip
work=./work
• There must be no more than one library path per line inside the xsim.ini file.
• If the directory corresponding to the physical path does not exist, xvhd or xvlog creates it
when the compiler first tries to write to that path.
• You can describe the physical path in terms of environment variables. The environment
variable must start with the $ character.
Behavioral Simulation
The following figure illustrates the behavioral simulation process:
Gather Files
Execute Using
XSIM <snapshot>
Debug on Waveform
X23705-021420
To run behavioral simulation from within the Vivado Design Suite, use the Tcl command:
launch_simulation -mode behavioral.
Create Netlist
write_verilog or write_vhdl
Gather Files
(Create Project File )
Simulation Using
xsim <snapshot>
Debug in Waveform
Or Self-checking Test Bench
X12985
The following is an example of running a post-synthesis functional simulation from the command
line:
TIP: When you run a post-synthesis or post-implementation timing simulation, you must run the
write_sdf command after the write_verilog command, and the appropriate annotate command
is needed for elaboration and simulation.
Use the -tclbatch option to contain commands within a file and execute those commands as
simulation starts. For example, you can have a file named run.tcl that contains the following:
run 20ns
current_time
quit
You can set a variable to represent a simulation command to quickly run frequently used
simulation commands.
export_simulation
Export a simulation script file for the target simulator. The generated script contains simulator
commands for compiling, elaborating and simulating the design.
This command retrieves the simulation compile order of specified objects, and export this
information in a shell script with the compiler commands and default options for the target
simulator. The specified object can be either a simulation fileset or an IP. If you want to run
simulation outside Vivado IDE, export_simulation can be used in place of
launch_simulation -scripts_only to generate scripts file.
Usage
Name Description
[-simulator] Simulator for which the simulation script will be created. Allowed values are all,
xsim, modelsim, questa, vcs, xcelium, riviera, and activehdl.
Default: all
[-of_objects] Export simulation script for the specified object.
Default: None
[-step] Name of the step for which the simulation script needs to be generated.
Default: None
[-ip_user_files_dir] Directory path to exported IP/BD user files (for static, dynamic and data files). For a
managed-IP project, the default path is ip_user_files.
Default: Empty
[-ipstatic_source_dir] Directory path to the exported IP/BD static files.
Default: Empty
[-lib_map_path] Precompiled simulation library directory path. If not specified, follow the
instructions in the generated script header to manually provide the simulation
library mapping information.
Default: Empty
[-gcc_install_path] GNU compiler installation directory path for the g++/gcc executables. If not
specified, the tool attempts to find based on simulator install path settings.
Default: Empty
[-script_name] Output shell script filename. If not specified, then file with a default name is
created.
Default: top_module.sh
Name Description
[-directory] Directory where the simulation script will be generated.
Default: export_sim
[-runtime] Simulation run time.
Default: full simulation run or until a logical break or finish condition
[-define] Read Verilog defines from the list specified with this switch.
Default: Empty
[-generic] Read VHDL generics from the list specified with this switch.
Default: Empty
[-include] Read include directory paths from the list specified with this switch.
Default: Empty
[-more_options] Pass specified options to the simulator tool.
Default: Empty
-single_step Writes out a single-step script. This is supported for Xcelium only.
[-use_ip_compiled_libs] Reference pre-compiled IP static library during compilation. This switch also works
with -ip_user_files_dir and -ipstatic_source_dir switches also for
generating scripts using pre-compiled IP library.
[-absolute_path] Make all file paths absolute with respect to the reference directory.
[-export_source_files] Copy IP/BD design files to output directory.
[-generate_hier_access] Extract path for hierarchical access simulation.
-exec Executes the generated script.
[-force] Overwrite previous files.
[-quiet] Ignore command errors.
[-verbose] Suspend message limits during command execution.
Description
Export a simulation script file for the target simulator (see the list of supported simulators below).
The generated script contains simulator commands for compiling, elaborating, and simulating the
design.
The command retrieves the simulation compile order of specified objects, and export this
information in a shell script with the compiler commands and default options for the target
simulator. The specified object can be either a simulation fileset, IP, or a BD (block design).
If the object is not specified, then this command generates the script for the active simulation
top. Any Verilog including directories or file paths for the files containing Verilog define
statements are added to the compiler command line.
By default, the design source file and include directory paths in the compiler command line are
set relative to the ref_dir variable that is set in the generated script. To make these paths
absolute, specify the -absolute_path switch.
The command also copies data files (if any) from the fileset, or from an IP to the output directory.
If the design contains Verilog sources, then the generated script also copies the glbl.v file from
the software installation path to the output directory.
A default .do file that is used in the compiler commands in the simulation script for the target
simulator, is written to the output directory.
Note: To perform simulation with the generated script, the simulation libraries must be compiled first using
the compile_simlib Tcl command. The compiled library directory path must be specified when
generating this script. The generated script automatically includes the setup files for the target simulator
from the compiled library directory.
Supported Simulators
Arguments
• -of_objects: (Optional) Specify the target object for which the simulation script file needs
to be generated. The target object can be either a simulation fileset (simset) or an IP. If this
option is not specified then this command generates file for the current simulation fileset.
• -step: (Optional) Specify the name of the step for which the simulation script needs to be
generated. The valid step values are : compile, elaborate, and simulate. If this is not specified,
the script executes all the steps applicable.
• -ip_user_files_dir: (Optional) Specify the directory path to the extracted design files
for the generated IP/BD source. For a managed IP project, the default path is ip_user_files. If
this is not specified, the extracted design files are picked from the default directory path that
is set by the IP.USER_FILES_DIR project property.
• -lib_map_path: (Optional) Specify path to the AMD pre-compiled simulation library for the
selected simulator. The simulation library is compiled using compile_simlib. See the
header section in the generated script for more information. If this switch is not specified,
then the generated script will not reference the pre-compiled simulation library and the static
IP files will be locally compiled.
• -gcc_install_path: (Optional) Specify the directory path to the GNU executable for the
target simulator. This option is required for designs that contain SystemC, C++ or C source. If
this option is not specified, the tool attempts to calculate the path to the GNU executagble
based on the simulator install path settings.
• -absolute_path: (Optional) Specify this option to make source and include directory paths
absolute. By default, all paths are set relative to the output directory specified with the -
directory switch.
• -force: (Optional) Overwrite an existing script file of the same name. If the script file already
exists, the tool returns an error unless the -force argument is specified.
• -directory: (Required) Specify the directory path where the script file is exported.
• -simulator: (Required) Specify the target simulator name for the simulation script. The valid
simulators names are xsim, modelsim, questa, vcs (or vcs_mx), xcelium, riviera, and
activehdl.
• -quiet: (Optional) Execute the command quietly, ignoring any command line errors and
returning no messages. The command also returns TCL_OK regardless of any errors
encountered during execution.
• -verbose: (Optional) Temporarily override any message limits and return all messages from
this command.
• -runtime: (Optional) Specify simulation runtime. If not specified, then simulation will run
until finding a logic break or finish declaration. Alternatively, the runtime can be specified
using the "<simulator>.simulate.runtime" fileset property
• -define: (Optional) Specify the list of Verilog defines used in the design. Alternatively,
defines can be specified using the "verilog_defines" fileset property.
• -generic: (Optional) Specify the list of VHDL generics used in the design. Alternatively, can
be specified using the "vhdl_generic" fileset property.
• -include: (Optional) Specify the list of include directory paths for verilog include files in the
design. Alternativiely, can be specified using the include_dirs fileset property.
• -export_source_files: (Optional) Specify this option to copy the IP design files to the
generated script directory in a sub-directory named srcs. The generated script references the
design files from this srcs directory.
export_ip_user_files
Generate and export IP/IP integrator user files from a project. This can be scoped to work on one
or more IPs.
Syntax
Usage
Name Description
[-of_objects] IP, IP integrator or a fileset.
Default: None
[-ip_user_files_dir] Directory path to simulation base directory (for static, dynamic, wrapper, netlist,
script, and MEM files).
Default: None
[-ipstatic_source_dir] Directory path to the static IP files.
Default: None
[-lib_map_path] Compiled simulation library directory path.
Default: Empty
[-no_script] Do not export simulation scripts.
Default: 1
[-sync] Delete IP/IP integrator dynamic and simulation script files.
[-reset] Delete all IP/IP integrator static, dynamic and simulation script files.
[-force] Overwrite files.
[-quiet] Ignore command errors.
[-verbose] Suspend message limits during command execution.
Description
Export IP user files repository with static, dynamic, netlist, Verilog/VHDL stubs, and memory
initialization files.
Arguments
• -of_objects: (Optional) Specify the target object for which the IP static and dynamic files
need to be exported.
• -ip_user_files_dir: (Optional) Directory path to IP user files base directory (for dynamic
and other IP non-static files). By default, if this switch is not specified, this command uses the
path specified with the IP.USER_FILES_DIR project property value.
Note: If the -ip_user_files_dir switch is specified, by default, the IP static files are exported
under the sub-directory with the name ipstatic. If this switch is specified with -
ipstatic_source_dir, the IP static files are exported in the path specified with the -
ipstatic_source_dir switch.
Examples
Appendix A
Compilation, Elaboration,
Simulation, Netlist, and Advanced
Options
From the Vivado IDE Flow Navigator, you can right-click Simulation, and select Simulation
Settings to open the simulation settings in the Settings dialog box. From the Simulation settings,
you can set various compilation, elaboration, simulation, netlist, and advanced options.
Compilation Options
The Compilation tab defines and manages compiler directives, which are stored as properties on
the simulation fileset and used by the xvlog and xvhdl utilities to compile Verilog and VHDL
source files for simulation.
Option Description
Verilog options Browse to set Verilog include path and to define macro
Generics/Parameters options Specify or browse to set the generic/parameter value
xsim.compile.tcl.pre Tcl file containing set of commands that should be invoked before the launch of
compilation
xsim.compile.xvlog.nosort Do not sort Verilog file during compilation
xsim.compile.xvhdl.nosort Do not sort VHDL file during compilation
xsim.compile.xvlog.relax Relax strict Verilog and SystemVerilog language checking rules
xsim.compile.xvhdl.relax Relax strict VHDL language checking rules
xsim.compile.xsc.mt_level Specify the number of sub-compilation jobs to run in parallel
xsim.compile.xvlog.more_options More XVLOG compilation options
xsim.compile.xvhdl.more_options More XVHDL compilation options
xsim.compile.xsc.more_options More XSC compilation options
Option Description
Verilog options Browse to set Verilog include path and to define macro
Generics/Parameters options Specify or browse to set the generic/parameter value
questasim.compile.tcl.pre Tcl file containing set of commands that should be invoked before the
launch of compilation
questasim.compile.vhdl_syntax Specify VHDL syntax
questasim.compile.use_explicit_decl Log all signals
questasim.compile.load_glbl Load GLBL module
questasim.compile.vlog.more_options More VLOG compilation options
questasim.compile.vcom.more_options More VCOM compilation options
questasim.compile.sccom.cores Specify the number of process cores to run in parallel
questasim.compile.sccom.more_options More SCCOM compilation options
Option Description
Verilog options Browse to set Verilog include path and to define macro
Generics/Parameters options Specify or browse to set the generic/parameter value
modelsim.compile.tcl.pre Tcl file containing a set of commands that should be invoked before the
launch of compilation
modelsim.compile.vhdl_syntax Specify VHDL syntax
modelsim.compile.use_explicit_decl Log all signals
modelsim.compile.load_glbl Load GLBL module
modelsim.compile.vlog.more_options More VLOG compilation options
modelsim.compile.vcom.more_options More VCOM compilation options
Option Description
Verilog options Browse to set the Verilog include path and to define macro
Generics/Parameters options Specify or browse to set the generic/parameter values
vcs.compile.tcl.pre a Tcl file containing set of commands that should be invoked before the launch
of compilation
vcs.compile.load_glbl Load GLBL module
vcs.compile.vhdlan.more_options More VHDLAN compilation options
Option Description
vcs.compile.vlogan.more_options Extra VLOGAN compilation options
vcs.compile.syscan.more_options More SYSCAN compilation options
vcs.compile.g++.more_options More G++ compilation options
vcs.compile.gcc.more_options More GCC compilation options
Options Description
Verilog Options Browse to set Verilog include path and to define macro
Generics/Parameters options Specify or browse to set the generic/parameter value
xcelium.compile.tcl.pre Tcl file containing a set of commands that should be invoked before the
launch of a compilation
xcelium.compile.v93 Enable VHDL-93 features
xcelium.compile.relax Enable relaxed VHDL interpretation
xcelium.compile.load_glbl Load GLBL module
xcelium.compile.xmvhdl.more_options More XMVHDL compilation options
xcelium.compile.xmvlog.more_options More XMVLOG compilation options
xcelium.compile.xmsc.more_options More XMSC compilation options
xcelium.compile.g++.more_options More G++ compilation options
xcelium.compile.gcc.more_options More GCC compilation options
Elaboration Options
The Elaboration tab defines and manages elaboration directives, which are stored as properties
on the simulation fileset and used by the xelab utility for elaborating and generating a simulation
snapshot. Select a property in the table to display a description of the property and edit the
value.
Option Description
xsim.elaborate.snapshot Specifies the simulation snapshot name
xsim.elaborate.debug_level Choose simulation debug visibility level. By default, it is typical
Option Description
xsim.elaborate.relax Relax strict HDL Language checking rules
xsim.elaborate.mt_level Specify the number of sub-compilation jobs to run in parallel
xsim.elaborate.load_glbl Load GLBL module
xsim.elaborate.rangecheck Enables runtime value range check for VHDL
xsim.elaborate.sdf_delay Specifies sdf timing delay type to be read for use in timing simulation
xsim.elaborate.xelab.more_options More XELAB elaboration options
xsim.elaborate.xsc.more_options More options for XSC during elaboration
xsim.elaborate.coverage.name Specify coverage database name
xsim.elaborate.coverage.dir Specify coverage database directory name
xsim.elaborate.coverage.type Specify coverage type(s) (line branch condition or all)
xsim.elaborate.coverage.library Track std/unisims/retarget libraries
xsim.elaborate.coverage.celldefine Track modules with celldefine attributes
xsim.elaborate.link.sysc Specify SystemC library to bind
xsim.elaborate.link.c Specify C/C++ library to bind
Option Description
questasim.elaborate.acc Enables access to simulation objects that might be optimized by
default (default: npr)
questasim.elaborate.vopt.more_options More VOPT elaboration options
questasim.elaborate.sccom.more_options More options for sccom during elaboration
questasim.elaborate.link.sysc Specify SystemC library to bind
questasim.elaborate.link.c Specify C/C++ library to bind
Option Description
modelsim.elaborate.acc Enables access to simulation objects that might be optimized by default
modelsim.elaborate.vopt.more_options More VOPT elaboration options
Option Description
vcs.elaborate.debug_pp Enable post-process debug access
vcs.elaborate.vcs.more_options More VCS elaboration options
vcs.elaborate.link.sysc Specify SystemC library to bind
vcs.elaborate.link.c Specify C/C++ library to bind
Option Description
xcelium.elaborate.update Checks if unit is up-to-date before writing
xcelium.elaborate.xmelab.more_options More xmelab elaboration options
Simulation Options
The Simulation tab defines and manages simulation directives, which are stored as properties on
the simulation fileset and used by the xsim application for simulating the current project. Select a
property in the table to display a description of the property and edit the value.
Option Description
xsim.simulate.runtime Specifies simulation run time for the Vivado simulator. Enter blank to load just
the simulation snapshot and wait for user input.
xsim.simulate.tcl.post Tcl file containing set of commands that you want to invoke at end of simulation.
xsim.simulate.log_all_signals Logs all object signals
xsim.simulate.wdb Specifies simulation waveform database file
xsim.simulate.saif Specifies SAIF file name
xsim.simulate.saif_scope Specifies design hierarchy instance name for which power estimation is desired.
xsim.simulate.saif_all_signals Logs all object signals for the design under test for SAIF file generation
xsim.simulate.xsim.more_options More Vivado simulator simulation options
Option Description
xsim.simulate.custom_tcl Specify the name of a custom tcl file which will be the source during simulation in
place of a regular Tcl file generated by Vivado
xsim.simulate.add_positional Add positional parameter to XSIM for passing command line argument
xsim.simulate.no_quit Do not quit simulation
Option Description
questasim.simulate.runtime Specify simulation runtime
questasim.simulate.tcl.post Tcl file containing a set of commands that you want to invoke at the end of
the simulation.
questasim.simulate.log_all_signals Log all signals
questasim.simulate.custom_do Specify the name of custom do file
questasim.simulate.saif_scope Specify design hierarchy instance name for which power estimation is
desired
questasim.simulate.sc_async_update Enables asynchronous request updates for SystemC
questasim.simulate.vsim.more_options More VSIM simulation options
questa.simulate.custom_wave_do Name of the custom wave.do file, which is used in place of a regular Vivado
generated wave.do file
Option Description
modelsim.simulate.runtime Specify simulation runtime.
modelsim.simulate.tcl.post Tcl file containing a set of commands that you want to invoke at the end of
the simulation.
modelsim.simulate.log_all_signals Log all signals.
modelsim.simulate.custom_do Specify the name of custom do file.
Option Description
modelsim.simulate.saif_scope Specify design hierarchy instance name for which power estimation is
desired.
modelsim.simulate.vsim.more_options More VSIM simulation options.
modelsim.simulate.custom_wave_do Name of the custom wave.do file, which is used in place of a regular Vivado
generated wave.do file.
Option Description
vcs.simulate.runtime Specify simulation runtime
vcs.simulate.tcl.post Tcl file containing a set of commands that you want to invoke at the end of the
simulation.
vcs.simulate.log_all_signals Log all signals
vcs.simulate.saif SAIF file name
vcs.simulate.saif_scope Specify design hierarchy instance name for which power estimation is desired
vcs.simulate.vcs.more_options More VCS simulation options
Option Description
xcelium.simulate.tcl.post Tcl file containing set of commands that you want to invoke at the end of
the simulation
xcelium.simulate.runtime Specify simulation runtime
xcelium.simulate.log_all_signals Log all signals
xcelium.simulate.update Check if unit is up-to-date before writing
xcelium.simulate.ieee_warnings Suppress IEEE warnings
xcelium.simulate.saif_scope SAIF file name
xcelium.simulate.saif Specify design hierarchy instance name for which power estimation is
desired
xcelium.simulate.xmsim.more_options More XMSIM simulation options
Netlist Options
The Netlist tab provides access to netlist configuration options related to the SDF annotation of
the Verilog netlist and the process corner captured by SDF delays. These options are stored as
properties on the simulation fileset and are used while writing the netlist for simulation.
Option Description
-sdf_anno A check box is available to select the -sdf_anno option. This option is enabled by default
-process_corner You can specify the -process_corner as fast or slow
Note: The Netlist Options of all the third-party simulators (Questa Advanced Simulator, ModelSim
Simulator, VCS and Xcelium Simulators) are similar to the options of Vivado simulator Netlist Options.
• Enable incremental compilation option: This option enables the incremental compilation and
preserves the simulation files during the successive run.
• Include all design sources for simulation option: By default, this option is enabled. Selecting
this option ensures that all the files from design sources along with the files from the current
simulation set are used for simulation. Even if you change the design sources, the same
changes are updated when you launch the behavioral simulation.
IMPORTANT! This is an advanced user feature. Unchecking the box could produce unexpected results.
The Include all design sources for simulation check box is selected by default. As long as the check box
is selected, the simulation set includes Out-of-Context (OOC) IP, IP Integrator files, and DCP.
Unchecking the box gives you the flexibility to include only the files you want to simulate, but, as
stated above, you might experience unexpected results.
Note: The Advanced Simulation Options are the same for all simulators.
Appendix B
1. Right-click the file and select Set file type as shown in the following figure.
2. In the Set Type dialog box, shown in the following figure, change the file type from Verilog to
SystemVerilog and click OK.
Alternatively, you can use the following command in the Tcl Console:
A new -sv flag has been introduced to xvlog, so if you want to read any SystemVerilog file, you
can use the following command:
prj Mode
If you want to run the Vivado simulator in the prj-based flow, use sv as the file type, as you use
verilog or vhdl.
Note: Sensitivity on dynamic types such as Queue, Dynamic Array, Associative Array, and Class are not
supported. Therefore, block waiting on dynamic type update might not work correctly. For example:
module top();
int c[$];
event e1;
initial
begin
c[0] = 10;
for(int i = 0; i <= 10; i++)
begin
c = {i, c};
-> e1;
#5;
end
end
always@(*) $display($time, " trying to read sensitivity on dynamic type :
%d", c[0]);
// this won't work as sensitivity on dynamic type is not supported
always @(e1) $display($time, " coming from event sensitivity : %d",
c[0]); // this we
can do as WA
always_comb if(c.size() > 0) $display($time, " Coming from size
sensitivity : %d",
c[0]); // sensitivity on size works
Appendix C
By default, Vivado simulator supports UVM version 1.2. If you want to use the UVM version 1.1,
you need to pass -uvm_version 1.1 to xvlog and xelab command. Set the following
properties if you use it through the Vivado integrated design environment:
You can also set these properties from Vivado Integrated Design Environment (IDE) using
Compilation and Elaboration tab in simulation settings. For more information, see Using
Simulation Settings.
Appendix D
Introduction
The AMD Vivado™ simulator supports the subset of VHDL 2008 (IEEE 1076-2008). The
complete list is given in Supported features of VHDL 2008 (IEEE1076-2008).
For example, to compile a design called top.vhdl in VHDL-2008, the following command line can
be used:
The Vivado simulator executable xelab is used to elaborate a design and produce an executable
image for simulation.
No switch is needed to elaborate on parser dumps produced by xvhdl. You can pass -vhdl2008
to xelab to directly use vhdl source files.
Example 1:
Example 2:
Instead of specifying VHDL files in the command line for xvhdl and xelab, a .prj file can be
used. If you have two files for a design called top.vhdl (2008 mode) and bot.vhdl (93 mode),
you can create a project file named example.prj as follows:
In the project file, each line starts with the language type of the file, followed by the library name
such as xil_defaultlib and one or more file names with a space separator. For VHDL 93, use
vhdl as the language type. For VHDL 2008, use vhdl2008 instead.
Alternatively, to mix VHDL 93 and VHDL 2008 design units, compile the files separately with a
proper language mode specified to xvhdl. Then, elaborate on top(s) of the design. For example,
if you have a VHDL 93 module called bot in file bot.vhdl, and a VHDL-2008 module called top
in file top.vhdl, you can compile them as shown in the example below:
xvhdl bot.vhdl
xvhdl -2008 top.vhdl
xelab -debug typical top -s mysim
Once the executable is produced by xelab, you can run the simulation as usual.
Example 1:
Example 2:
xsim mysim -R
For example, if you are using the following syntax for the fixed package in Vivado synthesis:
library ieee;
use ieee.fixed_pkg.all;
Change this to the following syntax in VHDL-2008 for use in the Vivado simulator:
library ieee_proposed;
use ieee_proposed.fixed_pkg.all;
See Fixed point Support in the Vivado Design Suite User Guide: Synthesis (UG901) for more
information about fixed and floating packages in Vivado Synthesis.
Supported Features
Following are the supported features of VHDL 2008 (IEEE1076-2008):
Note: For detailed information about features, see Supported VHDL-2008 Features section in Vivado
Design Suite User Guide: Synthesis (UG901).
Appendix E
Introduction
You can use the SystemVerilog Direct Programming Interface (DPI) to bind C code to
SystemVerilog code. Using DPI, SystemVerilog code can call a C function, which in turn can call
back a SystemVerilog task or function. AMD Vivado™ simulator supports all the constructs as
DPI task/function, as described below.
Compiling C Code
A new compiler executable, xsc, is provided to convert C code into an object code file and to
link multiple object code files into a shared library (.a on Windows and .so on Linux). The xsc
compiler is available in the <Vivado installation>/bin directory. You can use -sv_lib to
pass the shared library containing your C code to the Vivado simulator/elaborator executable.
The xsc compiler works in the same way as a C compiler, such as gcc. The xsc compiler:
• Calls the LLVM clang compiler to convert C code into object code
• Calls the GNU linker to create a shared library (.a on Windows and .so on Linux) from one or
more object files corresponding to the C files
The shared library generated by the xsc compiler is linked with the Vivado simulator kernel using
one or more newly added switches in xelab, as described below. The simulation snapshot created
by xelab thus has the ability to connect the compiled C code with compiled SystemVerilog code
and effect communication between C and SystemVerilog.
xsc Compiler
The xsc compiler helps you create a shared library (.a on Windows or .so on Linux) from one or
more C files. Use xelab to bind the shared library generated by xsc into the rest of your design.
You can create a shared library using the following processes:
• One-step process: Pass all C files to xsc without using the -compile or -shared/
shared_systemc/static switch.
• Two-step process:
Usage
Switches
You can use a double dash (--) or a single dash (-) for switches.
Switch Description
-compile [c] Generate the object files only from the source C files. The link stage is not
run.
-f [ -file ] <arg> Read additional options from the specified file.
-h [ -help ] Print this help message.
-i [ -input_file ] <arg> List of input files (one file per switch) for compiling or linking.
-mt <arg> (=auto) Specifies the number of sub-compilation jobs that can be run in parallel.
Choices are:
• auto: automatic
Default: auto
-o [ -output ] <arg> Specify the name of output shared library. Works with --shared, --
shared_systemc, --exe options only. The default for shared library is
<current_directory>/xsim.dir/work/xsc/dpi.so.
-work <arg> Specify the work directory in which to place the outputs (object files).
Default: <current_directory>/xsim.dir/xsc
-v [ -verbose ] <arg> Specify verbosity level for printing messages.
Allowed values are: 0, 1
Default: 0
Switch Description
-gcc_compile_options <arg> Supply an additional option to the compiler. You can use multiple -
gcc_compile_options switches.
-gcc_link_options <arg> Supply an additional option to the linker. You can use multiple -
gcc_link_options switches.
-shared Run only the linking stage to generate the shared library (.so) from the
object files.
-gcc_path Print path of the C compiler used internally.
-lib <arg> Specify the logical library directories that are read. Default is
<current_directory>/xsim.dir/xs.
-cppversion <arg> Set the CPP version. Currently, CPP 11 and 14 are supported. The default is
11.
--shared_systemc Run only the linking stage to generate the shared library (.dll) for SystemC
from the object files.
--static Run only the linking stage to generate a static library (.a) for SystemC from
the object files.
--exe Create executable for standalone SystemC.
--version Print version of the Vivado Simulator xsc being used.
--debug Debug SystemC modules. This option is relevant only when used together
with -exe option, otherwise is ignored.
--print_gcc_version Print version of the C compiler used internally.
Examples
Note: By default, Linux uses the LD_LIBRARY_PATH for searching the DPI libraries. Hence, provide -
dpi_absolute flag to xelab on Linux if the library name starts with lib*.
Note: You can use -additional_option to the compiler to pass an extra switch.
• Example:
Switch Description
-sv_root arg Root directory relative to which a DPI shared library should be searched. (Default:
<current_directory>/xsim.dir/xsc)
-sv_lib arg Name of the DPI shared library without the file extension defining C function imported in
SystemVerilog.
-sv_liblist arg Bootstrap file pointing to DPI shared libraries.
-dpiheader arg Generate a DPI C header file containing C declaration of imported and exported functions.
-dpi_absolute Use absolute paths instead of LD_LIBRARY_PATH on Linux for DPI libraries that are formatted as
lib<libname>.so.
For more information on r-sv_liblist arg, refer to the IEEE Standard for SystemVerilog—
Unified Hardware Design, Specification, and Verification Language, Appendix J.4.1, page 1228.
Unpacked arrays of bit, logic Passed as array Yes C can call SystemVerilog
To generate a C header file that provides details on how SystemVerilog data types are mapped to
C data types, pass the parameter -dpiheader <file name> to xelab. Additional details on
data type mapping are available in the IEEE Standard for SystemVerilog.
Examples
• SystemVerilog types::
• C types:
svLogicVecVal e[SV_PACKED_DATA_NELEMS(4)];
svLogicVecVal e1[2][SV_PACKED_DATA_NELEMS(4)];
svBit e3;
svBit e4[3];
TIP: The C argument types depend on the base type of the enum and the direction.
Packed Struct/Union
When using a packed struct or union type, an equivalent SystemVerilog type, svLogicVecVal
or svBitVecVal, is created on the DPI C side.
Examples
• SystemVerilog type:
• C type:
svLogicVecVal c_obj[SV_PACKED_DATA_NELEMS(172)];
svLogicVecVal c_obj1[5][SV_PACKED_DATA_NELEMS(344)];
Unpacked Struct
An equivalent unpacked type is created on the C side, in which all the members are converted to
the equivalent C representation.
Examples
• SystemVerilog type:
typedef struct {
int i;
bit b;
reg r[3:0];
logic [2:0] l[4:8][9:1];
} sType;
• C type:
typedef struct {
int i;
svBit b;
svLogic r[4];
svLogicVecVal l[5][9][SV_PACKED_DATA_NELEMS(3)];
} sType;
Declaration
Open arrays might only appear in import function/task declaration in SystemVerilog code. By
leaving the dimension(s) open, you must specify an open array and the size of the blank
dimension will be determined with respect to the actual argument.
Examples
At C side, the open array(s) might only be accessed by the handle and provided APIs:
svdpi.h Support
module m();
import "DPI-C" function void myFunction1(input int v[]);
int arr[4];
int dynArr[];
initial begin
arr = '{4, 5, 6, 7};
myFunction1(arr);
dynArr = new[6];
dynArr = '{8, 9, 10, 11, 12, 13};
myFunction1(dynArr);
end
endmodule
C code:
#include "svdpi.h"
void myFunction1(const svOpenArrayHandle v)
{
int l1 = svLow(v, 1);
int h1 = svHigh(v, 1);
for(int i = l1; i<= h1; i++) {
printf("\t%d", *((char*)svGetArrElemPtr1(v, i)));
}
printf("\n");
}
Examples
Note: All the examples below print PASSED for a successful run.
Examples include:
• Import Example Using -sv_lib, -sv_liblist, and -sv_root: A function import example that
illustrates different ways to use the -sv_lib, -sv_liblist and -sv_root options.
• Function with Output: A function that has output arguments.
• Simple Import-Export Flow (Illustrates xelab -dpiheader Flow): Shows a simple import>export
flow (illustrates xelab -dpiheader <filename> flow).
○ function2.c
○ file.sv
function1.c
#include "svdpi.h"
DPI_DLLESPEC
int myFunction1()
{
return 5;
}
function2.c
#include <svdpi.h>
DPI_DLLESPEC
int myFunction2()
{
return 10;
}
file.sv
module m();
import "DPI-C" pure function int myFunction1 ();
import "DPI-C" pure function int myFunction2 ();
integer i, j;
initial
begin
#1;
i = myFunction1();
j = myFunction2();
$display(i, j);
if( i == 5 && j == 10)
$display("PASSED");
else
$display("FAILED");
end
endmodule
Usage
Methods for compiling and linking the C files into the Vivado simulator are described below.
Flow description:
The xsc compiler compiles and links the C code to create the shared library xsim.dir/xsc/
dpi.so, and xelab references the shared library through the switch -sv_lib.
Two-step flow
Flow description:
• Compile the two C files into corresponding object code in the work directory abc.
• Link these two files together to create the shared library dpi.so.
• Make sure that this library is picked up from the work library abc via the -sv_root switch.
TIP: -sv_root specifies where to look for the shared library specified through the switch -sv_lib .
On Linux, if -sv_root is not specified and the DPI library is named with the prefix lib and the
suffix .so, then use the LD_LIBRARY_PATH environment variable for the location of shared library.
Flow description:
If you want to do your compilation and linking, you can use the -verbose switch to see the
path and the options with which the compiler was invoked. You can then tailor those to suit your
needs. In the example above, a distinct shared library final is created. This example also
demonstrates how spaces in the file path work.
file.sv
/*- - - -*/
package pack1;
import "DPI-C" function int myFunction1(input int v, output int o);
import "DPI-C" function void myFunction2 (input int v1, input int v2,
output int o);
endpackage
/*-- ---*/
module m();
int i, j;
int o1 ,o2, o3;
initial
begin
#1;
j = 10;
function.c
#include "svdpi.h"
DPI_DLLESPEC
int myFunction1(int j, int* o)
{
*o = j /2;
return 0;
}
DPI_DLLESPEC
void myFunction2(int i, int j, int* o)
{
*o = i+j;
return;
}
run.ksh
xsc function.c
xelab -vlog file.sv -sv -sv_lib dpi -R
1. Run xelab with the -dpiheader switch to create the header file, file.h.
2. Your code in file.c then includes the xelab-generated header file (file.h), which is listed
at the end.
3. Compile the code in file.c and test.sv as before to generate the simulation executable.
file.c
#include "file.h"
/* NOTE: This file is generated by xelab -dpiheader <filename> flow */
int cfunc (int a, int b) {
//Call the function exported from SV.
return c_exported_func (a,b);
}
test.sv
module m();
export "DPI-C" c_exported_func = function func;
import "DPI-C" pure function int cfunc (input int a ,b);
/*This function can be called from both SV or C side. */
function int func(input int x, y);
begin
func = x + y;
end
endfunction
int z;
initial
begin
#5;
z = cfunc(2, 3);
if(z == 5)
$display("PASSED");
else
$display("FAILED");
end
endmodule
run.ksh
TIP: When the return value of a function is computed solely on the value of its inputs, it is called a pure
function.
Appendix F
For SystemC simulation verification, simulation models are provided in C/C++/SystemC. Vivado
Design Suite provides two sets of simulation models:
• Protected models
• Unprotected models
Note: With Vivado simulator, there is no need to compile the simulation libraries. Libraries must generally
be compiled or recompiled with a new software release to update simulation models and to support a new
version of the simulator and GCC.
• SELECTED_SIM_MODEL: This is an IP level setting that allows you to select and set one of
the simulation models from the ALLOWED_SIM_MODELS.
• PREFFERED_SIM_MODEL: This is a project-level setting that allows you to set the default
simulation model for the project. This is common across all IPs present in your project.
1. In the Flow Navigator, click Open Block Design to open a block design.
2. Select the desired IP from the block design.
4. Change the SELECTED_SIM_MODEL option from Block Properties window of your IP. For
example, from rtl to tlm.
Note: Setting PREFFERED_SIM_MODEL to tlm sets all IPs SELECTED_SIM_MODEL to tlm except IPs that
do not support tlm.
Protected Models
The protected models are pre-compiled and released in the form of a shared library that is built
for the respective simulator. This shared library is packaged as part of the AMD Vivado™ install
and based on the design configuration these models are bonded during elaboration. The
following two protected models are delivered as part of Vivado install:
• AI Engine
• Network on chip (NoC)
These models are in the form of shared library present in the following installation path:
<Vivado-install-path>/data/simmodels/<simulator>/<simulator_version>/
<os_type>/<gcc_version>/systemc/protected
• Riviera: <Vivado-install-path>/data/simmodels/riviera/2023.04/
lnx64/9.3.0/systemc/protected/
Note: Versal models such as the AI Engine and NoC are not supported for post-synthesis simulation.
Unprotected Models
The unprotected models are released as a source code in the installation. You need to compile
the model for the target simulator using the compile_simlib utility. For AMD Vivado™
simulator, these unprotected models are precompiled in the standard <Vivado-install-
path>/data/xsim folder where other libraries are compiled. For third-party simulators, these
models must be compiled using compile_simlib. The following un-protected models are
delivered as part of Vivado installation:
• aie_xtlm
• axi_tg_sc
• axis_dwidth_converter_sc
• axis_switch_sc
• common_cpp
• common_rpc
• debug_tcp_server
• emu_perf_common
• noc_sc
• pl_fileio
• remote_port_c
• remote_port_sc
• rwd_tlmmodel
• sim_ddr
• sim_qdma_cpp
• sim_qdma_sc
• sim_xdma_cpp
• sim_xdma_sc
• tlm_ext
• xtlm
• xtlm_ap_ctrl
• xtlm_ipc
• xtlm_simple_interconnect
• xtlm_trace_model
These simulation model sources are present in the following installation path:
<Vivado-install-path>/data/systemc/
c/c++/SystemC sources can be compiled using GCC. Each simulator supports different versions
of GCC. If a design contains AMD provided SystemC models, the GCC version used should be the
supported version. The design needs to be re-compiled if the GCC version changes.
Compatible GCC
Simulator Version SystemC Compiler
Version
AMD Vivado™ simulator 2024.1 9.3.0 XSC
Siemens EDA Questa Advanced 2023.3 7.4.0 SCCOM
simulator
Cadence Xcelium Parallel simulator 23.09.001 9.3.0 XMSC
VCS U-2023.03-SP2 9.2.0 SYSCAN
Riviera 2023.04 9.3.0 CCOMP
Simulator Linux
Questa setenv MODEL_TECH <tool installation path>
setenv LM_LICENSE_FILE <license file>
setenv PATH ${MODEL_TECH}/bin:$PATH
Note: By default, the GCC path is auto-determined from the tool installation location for Questa and
Xcelium.
Command Settings
compile_simlib • Specify the GCC compiler install path using -gcc_exec_path switch.
• If not, set the environment variable GCC_SIM_EXE_PATH <gcc_install_dir>.
launch_simulation • Specify the GCC compiler install path using -gcc_install_path switch.
• If not, set the property using set_property
simulator.<name>_gcc_install_dir <gcc_path> [current_project].
• If not, set the environment variable GCC_SIM_EXE_PATH <gcc_install_dir>.
Note: If these recommended settings are not found, Vivado picks install path from PATH env variable. Also,
it is always recommended to use tool native SystemC compilers.
Appendix G
generate_vcd_ports
The generate_vcd_port command opens a VCD file handle for writing port activity of the
given instance. This VCD file is read by create_testbench Tcl command to read port activity
for writing the stimuli source. The instance can be selected from the scope window in the Vivado
simulator IDE or by specifying the hierarchical path to the instance when executing this
command from Tcl console. The command creates dummports.vcd file that gets populated
when running simulation for the selected instance scope.
Note: The Vivado simulator must be active to generate this file for the selected instance.
If running this command from Vivado IDE, then the dumpports.vcd file is created in the
simulation run directory. If running this command from Vivado simulator standalone GUI, then
the dumpports.vcd file is created in vcd2tb sub-directory of the current directory. Following
are the generate_vcd_port options:
• -quiet (optional): Execute the command quietly, returning no messages from the command.
The command also returns TCL_OK regardless of any errors encountered during execution.
Note: Any errors encountered on the command-line while launching the command are returned. Only
errors occurring inside the command are trapped.
• -verbose (optional): Temporarily override any message limits and return all messages from this
command.
Following example command creates a VCD file for /top/DUT/fifo/buf_1 instance of type
buf module, record waveform activity for 2000ns, and close the VCD file handle:
generate_vcd_ports {/top/DUT/fifo/buf_1}
run 2000ns
close_vcd -ports
create_testbench
Create a test bench for a design unit instance. This command creates a functional system Verilog-
based test bench for the scoped hierarchical instance. The test bench contains port/signal
specification, parameter declaration, stimuli vector include file and module instantiation of the
selected instance as a design under test (DUT). This command allows you to add the test bench
to an existing or a new simulation fileset from which the simulation can be launched.
Option Description
-name <arg> Specify the name of the test bench module name. The default name is test bench.
-add_to_simset <arg> Specify simulation fileset name to which the test bench needs to be added. If this
switch is not specified, then the command adds a test bench to the current active
simulation fileset.
-set_as_top Set the generated test bench module at the top in the simulation fileset where the
test bench is added.
-mode <arg> Specifies simulation mode. Allowed values are behavioral, post-synthesis, or post-
implementation. The default is behavioral.
-type <arg> Specifies simulation type. Allowed values are functional or timing (not applicable
for behavioral mode).
-force Overwrite existing test bench file.
-quiet Execute the command quietly, returning no messages from the command. The
command also returns TCL_OK regardless of any errors encountered during
execution.
Note: Any errors encountered on the command line while launching the command
are returned. Only errors occurring inside the command are trapped.
-verbose Temporarily override any message limits and return all messages from this
command.
Notes:
1. All the arguments are optional as the default value is set as explained for each flag.
The following example command creates a test bench for the fifo module and adds it to the
sub_design_fifo simulation fileset:
The following example command generates a VCD file for /top/DUT/fifo/buf_1 instance of
type buf module, record the waveform activity in the VCD file for 2000 ns, create a test bench
with module named tb, add the test bench to the test_buffer simulation fileset and set tb as
top module in this fileset:
generate_vcd_ports {/top/DUT/fifo/buf_1}
run 2000ns
close_vcd -ports
create_testbench -name tb -add_to_simset test_buffer -set_as_top
3. Select the desired scope for which you want to generate test bench as shown in the following
figure:
5. Delete all existing signals on the waveform and select Add to Wave Window for the selected
scope.
Note: Step 5 is used to demonstrate that the generated test bench is driving the design unit correctly.
6. Use restart, run 2000 ns and close_vcd -ports commands on Tcl console to dump
the signal activity. This logs the signal from time 0 to 2000 ns on the waveform as shown in
the following figure:
8. Use launch_simulation command to run the simulation with the newly generated test
bench.
9. Compare the input/output of the waveform with the waveform of your original design; the
input/output is the same.
This is how you can create a test bench for your sub-design and use the generated test bench
independently with any standard simulator.
Appendix H
Although you can access the GSR net after configuration, avoid the use of the GSR circuitry in
place of a manual reset. This is because the FPGA devices offer high-speed backbone routing for
high fanout signals such as a system reset. This backbone route is faster than the dedicated GSR
circuitry and is easier to analyze than the dedicated global routing that transports the GSR signal.
A GSR pulse can optionally be supplied in pre-synthesis functional simulations, but is not
necessary if the design has a local reset that resets all registers.
TIP: When you create a test bench, remember that the GSR pulse occurs automatically in the post-
synthesis and post-implementation simulation. This holds all registers in reset for the first 100 ns of the
simulation.
Note: If a design uses ICAP primitive, GSR lasts for 1.281 us at that time.
In simulation, the GTS signal is usually not driven. The circuitry for driving GTS is available in the
post-synthesis and post-implementation simulations and can be optionally added for the pre-
synthesis functional simulation, but the GTS pulse width is set to zero by default.
Global Tri-State D Q
(GTS)
Initialization CE
User Tri-State Controller
Enable C
CLR
GSR
GTS
User
Programmable
I/O User Output Logic
Pad User
Resources
Output Buffer Async.
Reset Global
User Input Set/Reset
(GSR)
Input Buffer
General Purpose X8352
In most cases, GSR and GTS need not be defined in the test bench.
The glbl.v file declares the global GSR and GTS signals and automatically pulses GSR for 100
ns.
To use the GLBL_VHD component you must instantiate it into the test bench.
The GLBL_VHD component declares the global GSR and GTS signals and automatically pulses
GSR for 100 ns.
The following code snippet shows an example of instantiating the GLBL_VHD component in the
test bench and changing the assertion pulse width of the Reset on Configuration (ROC) to 90 ns:
Simulation time is advanced only when there are no more transactions to process for the current
simulation time. For this reason, simulators can give unexpected results, depending on when the
events are scheduled within a time step. The following VHDL coding example shows how an
unexpected result can occur.
• clk_prcs
• clk_b_prcs
The simulator performs the clk_b <= clk assignment before advancing the simulation time.
As a result, events that should occur in two clock edges occur in one clock edge instead, causing
a race condition.
• Do not change clock and data at the same time. Insert a delay at every output.
• Use the same clock.
• Force a delta delay by using a temporary signal, as shown in the following example:
clk_b <= clk;
clk_prcs : process (clk)
begin
if (clk'event and clk='1') then
result <= data;
end if;
end process;
result_temp <= result;
clk_b_prcs : process (clk_b)
begin
if (clk_b'event and clk_b='1') then
result1 <= result_temp;
end if;
end process;
Most event-based simulators can display delta cycles. Use this to your advantage when
debugging simulation issues.
The ASYNC_REG constraint can be attached to a register in the front-end design by using either:
The registers to which ASYNC_REG are attached retain the previous value during timing
simulation and do not output an X to simulation. Use care; a new value might have been clocked
in as well.
The ASYNC_REG constraint is applicable to CLB and Input Output Block (IOB) registers and
latches only. For more information, see ASYNC_REG constraint in the Vivado Design Suite
Properties Reference Guide (UG912).
If you cannot avoid clocking in asynchronous data, do so for IOB or CLB registers only. Clocking
in asynchronous signals to RAM, Shift Register LUT (SRL), or other synchronous elements has less
deterministic results; therefore, should be avoided. AMD highly recommends that you first
properly synchronize any asynchronous signal in a register, latch, or FIFO before writing to a
RAM, Shift Register LUT (SRL), or any other synchronous element. For more information, see the
Vivado Design Suite User Guide: Using Constraints (UG903).
Because this value cannot be determined, and accurate simulation results cannot be guaranteed,
the element outputs an X to represent an unknown value. The X output remains until the next
clock cycle in which the next clocked value updates the output if another violation does not
occur.
The presence of an X output can significantly affect simulation. For example, an X generated by
one register can be propagated to others on subsequent clock cycles. This can cause large
portions of the design under test to become unknown.
To correct X-generation:
• On a synchronous path, analyze the path and fix any timing problems associated with this or
other paths to ensure a properly operating circuit.
• On an asynchronous path, if you cannot otherwise avoid timing violations, disable the X
propagation on synchronous elements during timing violations by using the ASYNC_REG
property.
When X propagation is disabled, the previous value is retained at the output of the register. In
the actual silicon, the register might have changed to the 'new' value. Disabling X propagation
might yield simulation results that do not match the silicon behavior.
CAUTION! Exercise care when using this option. Use it only if you cannot otherwise avoid timing
violations.
• JTAG simulation
• SelectMAP simulation
JTAG Simulation
The simulation supports the interaction of the JTAG ports and some of the JTAG operation
commands. The JTAG interface, including an interface to the scan chain, is not fully supported. To
simulate this interface:
This becomes:
• The interface to the external JTAG signals (such as TDI, TDO, and TCK)
• The communication channel to the BSCAN component
The communication between the components takes place in the VPKG VHDL package file or the
glbl Verilog global module. Accordingly, no implicit connections are necessary between the
specific JTAG_SIME2 component and the design, or the specific BSCANE2 symbol.
Stimulus can be driven and viewed from the specific JTAG_SIME2 component within the test
bench to understand the operation of the JTAG/BSCAN function. Instantiation templates for
both of these components are available in both the AMD Vivado™ Design Suite templates and
the specific-device libraries guides.
SelectMAP Simulation
The configuration simulation models (SIM_CONFIGE2 and SIM_CONFIGE3) with an
instantiation template allow supported configuration interfaces to be simulated to ultimately
show the DONE pin going HIGH. This is a model of how the supported devices react to stimulus
on the supported configuration interface.
The models handle control signal activity as well as bit file downloading. Internal register settings
such as the CRC, IDCODE, and status registers are included. You can monitor the Sync Word as it
enters the device and the start-up sequence as it progresses. The following figure illustrates how
the system should map from the hardware to the simulation environment.
The configuration process is specifically outlined in the configuration user guides for each device.
These guides contain information on the configuration sequence and the configuration
interfaces.
Memory
Controller IDCODE Parameter
X10194
1 1 0
The configuration models allow the configuration interface control logic to be tested before the
hardware is available. It simulates the entire device and is used at a system level for:
• Applications using a processor to control the configuration logic to ensure proper wiring,
control signal handling, and data input alignment.
• Applications that control the data loading process with the CS (SelectMAP Chip Select) or CLK
signal to ensure proper data alignment.
• Systems that need to perform a SelectMAP ABORT or Readback.
The config_test_bench.zip file has sample test benches that simulate a processor running
the SelectMAP logic. These test benches have control logic to emulate a processor controlling
the SelectMAP interface and include features such as a full configuration, ABORT, and Readback
of the IDCODE and status registers.
For the ZIP files associated with this model, see AMD Answer Record 53632.
The simulated host system must have a method for file delivery as well as control signal
management. These control systems should be designed as set forth in the device configuration
user guides.
The configuration models also demonstrate what is occurring inside the device during the
configuration procedure when a BIT file is loaded into the device.
During the BIT file download, the model processes each command and changes registers settings
that mirror the hardware changes.
You can monitor the CRC register as it actively accumulates a CRC value. The model also shows
the Status Register bits being set as the device progresses through the different states of
configuration.
Each configuration model provides an example of a correct configuration. You can leverage this
example to assist in the debug procedure if you encounter device programming issues.
You can read the Status Register through JTAG using the Vivado Device Programmer tool. This
register contains information relating to the current status of the device and is a useful
debugging resource. If you encounter issues on the board, reading the Status Register in Vivado
Device Programmer is one of the first debugging steps to take.
After the status register is read, you can map it to the simulation to pinpoint the configuration
stage of the device.
For example, the GHIGH bit is set HIGH after the data load process completes successfully; if this
bit is not set, then the data loading operation did not complete. You can also monitor the GTS,
GWE, and DONE signals set in BitGen that are released in the start-up sequence.
The configuration models also allow for error injection. The active CRC logic detects any issue if
the data load is paused and starts again with any problems. It also detects bit flips manually
inserted in the BIT file and handles them just as the device would handle this error.
Feature Support
Each device-specific configuration user guide outlines the supported methods of interacting with
each configuration interface. The following table shows which features discussed in the
configuration user guides are supported.
SelectMAP reconfiguration No
SelectMAP data ordering Yes
Reconfiguration and MultiBoot No
Configuration CRC—CRC checking during configuration Yes
Configuration CRC—post-configuration CRC No
In the hardware, the value that is read might be the old data, the new data, or a combination of
the old data and the new data.
In simulation, this is modeled by outputting X because the value read is unknown. For more
information on block RAM collisions, see the user guide for the device.
In certain applications, this situation cannot be avoided or designed around. In these cases, the
block RAM can be configured not to look for these violations. This is controlled by the generic
(VHDL) or parameter (Verilog) SIM_COLLISION_CHECK string in block RAM primitives.
The following table shows the string options you can use with SIM_COLLISION_CHECK to
control simulation behavior in the event of a collision.
Write Collision
String Write Xs on the Output
Messages
ALL Yes Yes
WARNING_ONLY Yes No. Applies only at the time of collision. Subsequent reads of
the same address space could produce Xs on the output.
Write Collision
String Write Xs on the Output
Messages
GENERATE_X_ONLY No Yes
None No No. Applies only at the time of collision. Subsequent reads of
the same address space could produce Xs on the output.
Apply the SIM_COLLISION_CHECK at an instance level so you can change the setting for each
block RAM instance.
Note: Any change to design files after the last compilation is not reflected in the simulation when you set
this property.
Skipping Simulation
To perform a semantic check on the design HDL files, by elaborating and compiling the
simulation snapshot without running simulation, you can set the SKIP_SIMULATION property on
the simulation fileset:
IMPORTANT! If you elect to use one of the properties above, disable the Clean up simulation files check
box in the simulations settings, or if you are running in batch/Tcl mode, call launch_simulation with
-noclean_dir.
Appendix I
• For HDL objects of type logic, the value is a one-dimensional array of the logic type or
the value is a string of digits of the specified radix.
○ If the string specifies fewer bits than the type expects, the string is implicitly zero-extended
(not sign-extended) to match the length of the type.
○ If the string specifies more bits than the type expects, the extra bits on the MSB side must
be zero; otherwise, the command generates a size mismatch error.
For example, the value 3F specifies eight bits (4 per hex digit) with radix hex and a 6-bit
logic array, equivalent to binary 0011 1111. But because the upper two bits of 3 are zero,
the value can be assigned to the HDL object. In contrast, the value 7F would generate an
error, because the upper two bits are not zero.
○ A scalar (not array or record) logic HDL object has an implicit length of one bit.
• A Verilog object is considered to be of logic type if it is of the implicit Verilog bit type, which
includes wire and reg objects, integer, and time.
• A VHDL object is considered to be of logic type if the objects type is bit, std_logic, or
any enumeration type whose enumerators are a subset of those of std_logic and include at
least 0 and 1, or type of the object is a one-dimensional array of such a type.
• For HDL objects, which are of VHDL enumeration type, the value can be one of the
enumerator literals, without single quotes if the enumerator is a character literal. Radix is
ignored.
• For VHDL objects, of integral type, the value can be a signed decimal integer in the range of
the type. Radix is ignored.
• For VHDL and Verilog floating point types the value can be a floating point value. Radix is
ignored.
• For all other types of HDL objects, the Tcl command set does not support setting values.
Appendix J
This appendix lists the application of Mixed Language in the Vivado simulator, and the exceptions
to Verilog, SystemVerilog, and VHDL support.
IMPORTANT! Connecting the whole VHDL record object to a Verilog object is unsupported; however,
VHDL record elements of a supported type can be connected to a compatible Verilog port.
• A Verilog/SV hierarchical reference cannot refer to a VHDL unit nor can a VHDL expanded or
selected name refer to a Verilog/SV unit.
• First searches for a unit of the same language as that of the instantiating design unit.
• If a unit of the same language is not found, xelab searches for a cross-language design unit in
the libraries specified by the -L option.
The search order is the same as the order of appearance of libraries on the xelab command line.
Note: When using the Vivado IDE, the library search order is specified automatically. No user intervention
is necessary or possible.
Related Information
To ensure that you are correctly matching port types, review the Port Mapping and Supported
Port Types.
1. Declare a VHDL component with the same name and in the same case as the Verilog module
that you want to instantiate. For example:
COMPONENT MY_VHDL_UNIT PORT (
Q : out STD_ULOGIC;
D : in STD_ULOGIC;
C : in STD_ULOGIC );
END COMPONENT;
2. Use named or positional association to instantiate the Verilog module. For example:
UUT : MY_VHDL_UNIT PORT MAP(
Q => O,
D => I,
C => CLK);
To instantiate a VHDL component in a Verilog/SV design unit, instantiate the VHDL component
as if it were a Verilog/SV module.
For example:
module testbench ;
wire in, clk;
wire out;
FD FD1(
.Q(Q_OUT),
.C(CLK);
.D(A);
);
VHDL1 Verilog/SV 2
IN INPUT
OUT OUTPUT
INOUT INOUT
Notes:
1. Buffer and linkage ports of VHDL are not supported.
2. Connection to bi-directional pass switches in Verilog are not supported. Unnamed Verilog ports are not allowed on
mixed design boundary.
The following table shows the supported VHDL and Verilog data types for ports on the mixed
language design boundary.
Note: Verilog output port of type reg is supported on the mixed language boundary. On the boundary, an
output reg port is treated as if it were an output net (wire) port. Any other type found on mixed language
boundary is considered an error.
Note: The Vivado simulator supports the record element as an actual in the port map of a Verilog module
that is instantiated in the mixed domain. All those types that are supported as VHDL port (listed in Table
49: Supported VHDL and Verilog Data Types) are also supported as a record element.
byte
bit_vector
std_logic_Vector
std_ulogic_vector
signed
unsigned
shortint
bit_vector
std_logic_Vector
std_ulogic_vector
signed
unsigned
longint
bit_vector
std_logic_Vector
std_ulogic_vector
signed
unsigned
integer
bit_vector
vector of bit(1D)
bit_vector
std_logic_Vector
std_ulogic_vector
signed
unsigned
vector of logic(1D)
bit_vector
std_logic_Vector
std_ulogic_vector
signed
unsigned
vector of reg(1D)
bit_vector
std_logic_Vector
std_ulogic_vector
signed
unsigned
logic/bit
bit
std_logic
std_ulogic
bit_vector
std_logic_Vector
std_ulogic_vector
signed
unsigned
Note: VHDL entity instantiating Verilog Module having a real port is supported.
• integer
• real
• string
• boolean
Note: Any other generic type found on mixed language boundary is considered an error.
The following table lists the VHDL type bit mapping to Verilog states.
bit Verilog
0 0
1 1
The folowing table lists the VHDL type std_logic mappings to Verilog states.
std_logic Verilog
U X
X X
0 0
1 1
Z Z
W X
L 0
H 1
- X
Because Verilog is case sensitive, named associations and the local port names that you use in
the component declaration must match the case of the corresponding Verilog port names.
• Alias of an alias
generate_item_or_null ::=
generate_conditonal_statement |
generate_case_statement |
generate_loop_statement |
generate_block |
module_or_generate_item
generate_item_or_null ::=
generate_conditional_statement|
generate_case_statement |
generate_loop_statement |
generate_blockgenerate_condition
generate_block ::=
begin
[ : generate_block_identifier ]
{ generate_item }
end
generate_block ::=
begin:
generate_block_identifier {
generate_item }
end
Appendix K
verilog <libraryName>
<VerilogDesignFileName>
vhdl <libraryName> <VHDLDesignFileName>
sv <libraryName>
<SystemVerilogDesignFileName>
xelab top1 top2 -s top Elaborates a design that has two top design units: top1 and top2.
In this example, the design units are compiled in the work library.
After compilation, xelab generates an executable snapshot with
the name top. Without the -s top switch, xelab creates the
snapshot by concatenating the unit names.
Command Line xelab -help
Help and xelab Table 15: xelab, xvhd, and xvlog Command Options
Options
Running Simulation
After parsing, elaboration and compilation stages are successful; xsim loads an executable snapshot to run simulation.
Usage xsim top -R Simulates the design to through completion.
xsim top -gui Opens the Vivado simulator workspace (GUI).
xsim top Opens the Vivado Design Suite command prompt in Tcl mode.
From there, you can invoke such options as:
run -all
run 100 ns
Important Shortcuts
You can invoke the parsing, elaboration, and executable generation and simulation in one, two, or three stages.
Three Stage xvlog bot.v
xvhdl top.vhd
xelab work.top -s top
xsim top -R
Note: If your design contain UVM construct then you need to pass -L uvm to xvlog and xelab command
current_scope Report or set the current, working HDL scope. See Scope Window
for more information.
get_objects Get a list of HDL objects in one or more HDL scopes, per the
specified pattern. For example command usage refer to: Example
SAIF Tcl Commands.
get_scopes Get a list of child HDL scopes. See Scope Window for more
information.
get_value Get the current value of the selected HDL object (variable, signal,
wire, register). Type get_value -help in Tcl Console for more
information.
launch_simulation Launch simulation using the Vivado simulator.
remove_bps Remove breakpoints from a simulation.
report_drivers Print drivers along with current driving values for an HDL wire or
signal object. Reference for more information: Using the
report_drivers Tcl Command.
report_values Print current simulated value of given HDL objects (variables,
signals, wires, or registers).
restart Rewind simulation to post loading state (as though the design was
reloaded); time is set to 0.
set_value Set the HDL object (variable, signal, wire, or register) to a specified
value. Reference for more information: Appendix I: Value Rules in
Vivado Simulator Tcl Commands.
step Step simulation to the next statement. See Stepping Through a
Simulation.
Appendix L
• Setting the values of the top-level input ports of the HDL design
• Instructing the Vivado simulator to run the simulation for a certain amount of simulation time
Additionally, the C/C++ program can read the values of the top-level output ports of the HDL
design.
To call a function through dynamic linking requires your program to perform the following steps:
Steps 1, 2, and 4 require the use of OS-specific library calls, as shown in the following table. See
your operating system documentation for details about these functions.
XSI requires you to call functions from two shared libraries: the kernel shared library and your
design shared library. The kernel shared library ships with the Vivado simulator and is called
librdi_simulator_kernel.so (Linux) or librdi_simulator_kernel.dll (Windows).
It resides in the following directory:
where <platform> is lnx64.o or win64.o. Make sure to include this directory in your library
path while running your program. On Linux, include the directory in the environment variable
LD_LIBRARY_PATH, and on Windows, in the environment variable PATH.
Your design shared library, which the Vivado simulator creates in the course of compiling your
HDL design, as described in Preparing the Design Shared Library, is called xsimk.so (Linux) or
xsimk.dll (Windows) and typically resides at the following location:
where <HDL design directory> is the directory from which your design shared library was
created, and <snapshot name> is the name of the snapshot that you specify during the
creation of the library.
Your C/C++ program calls the XSI function xsi_open() residing in your design shared library
and all other XSI functions from the kernel shared library.
The XSI code examples that ship with the Vivado simulator consolidate the XSI functions into a C
++ class called Xsi::Loader. The class accepts the names of the two shared libraries, internally
executes the necessary dynamic linking steps, and exposes all the XSI functions as member
functions of the class. Wrapping the XSI functions in this manner eliminates the necessity of
calling the dynamic linking OS functions directly. You can find the source code for the class that
can be copied into your own program at the following location under your Vivado installation:
To use Xsi::Loader, simply instantiate it by passing the names of the two shared libraries as
shown in the following example:
#include "xsi_loader.h"
...
Xsi::Loader loader("xsim.dir/mySnapshot/xsimk.so",
"librdi_simulator_kernel.so");
The following table lists the XSI functions and their Xsi::Loader member function equivalents
to use for each step. You can find the usage details for each XSI function in the XSI Function
Reference.
You can find the example C++ programs that use XSI in your Vivado simulator installation at the
following location:
1. The compilation lines specify (via -I) the inclusion of the directory containing the xsi.h
include file.
2. There is no mention of the design shared library or kernel shared library during the
compilation of a C++ program.
CAUTION! If you intend to rebuild the design shared library for your C/C++ program while your program
continues to run, be sure to close the design in your program before executing this step.
Create your design shared library by invoking xelab on the HDL design and including the -dll
switch to instruct xelab to produce a shared library instead of the usual snapshot for use with the
Vivado simulator's user interface.
For example:
Type the following in the Linux command line to create a design shared library at ./xsim.dir/
design/xsimk.so:
where work.top1 and work.top2 are the top module names and design is the snapshot
name.
See xelab, xvhdl, and xvlog xsim Command Options for more details on compiling an HDL design.
xsi_close
void xsi_close(xsiHandle design_handle);
void Xsi::Loader::close();
This function closes an HDL design, freeing the memory associated with the design. Call this
function to end the simulation.
xsi_get_error_info
const char* xsi_get_error_info(xsiHandle design_handle);
const char* Xsi::Loader::get_error_info();
xsi_get_port_number
XSI_INT32 xsi_get_port_number(xsiHandle design_handle, const char*
port_name);
int Xsi::Loader::get_port_number(const char* port_name);
This function returns an integer ID for the requested top-level port of the HDL design. You might
subsequently use the ID to specify the port in xsi_get_value and xsi_put_value calls.
port_name is the name of the port and is case sensitive for Verilog and case insensitive for
VHDL. The function returns -1 if no port of the specified name exists.
Example code:
#include "xsi.h"
#include "xsi_loader.h"
...
Xsi::Loader loader("xsim.dir/mySnapshot/
xsimk.so","librdi_simulator_kernel.so");
...
int count = loader.get_port_number("count");
xsi_get_status
XSI_INT32 xsi_get_status(xsiHandle design_handle);
int Xsi::Loader::get_status();
This function returns the status of the simulation. The status mighr be equal to one of the
following identifiers:
Example code:
#include "xsi.h"
#include "xsi_loader.h"
...
Xsi::Loader loader("xsim.dir/mySnapshot/
xsimk.so","librdi_simulator_kernel.so");
...
if (loader.get_status() == xsiError)
printf("HDL run-time error encountered.\n");
xsi_get_value
void xsi_get_value(xsiHandle design_handle, XSI_INT32 port_number, void*
value);
int Xsi::Loader::get_value(int port_number, void* value);
This function fetches the value of the port indicated by port ID port_number. The value is
placed in the memory buffer to which value points. See xsi_get_port_number for information on
obtaining an ID for a port.
IMPORTANT! Your program must allocate sufficient memory for the buffer before calling the function.
See Vivado Simulator VHDL Data Format and Vivado Simulator Verilog Data Format to determine the
necessary size of the buffer.
Example code:
#include "xsi.h"
#include "xsi_loader.h"
...
// Buffer for value of port "count"
s_xsi_vlog_logicval count_val = {0X00000000, 0X00000000};
Xsi::Loader loader("xsim.dir/mySnapshot/
xsimk.so","librdi_simulator_kernel.so");
...
int count = loader.get_port_number("count");
loader.get_value(count, &count_val);
xsi_open
typedef struct t_xsi_setup_info {
char* logFileName;
char* wdbFileName;
} s_xsi_setup_info, *p_xsi_setup_info;
xsiHandle xsi_open(p_xsi_setup_info setup_info);
void Xsi::Loader::open(p_xsi_setup_info setup_info);
bool Xsi::Loader::isopen() const;
This function opens an HDL design for simulation. To use this function, you must first initialize an
s_xsi_setup_info struct to pass to the function. Use logFileName for the name of the
simulation log file, or NULL to disable logging. If waveform tracing is on (see xsi_trace_all),
wdbFileName is the name of the output WDB (waveform database) file. Use NULL for the
default name of xsim.wdb. If the waveform tracing is off, the Vivado simulator ignores the
wdbFileName field.
TIP: To protect your program from future changes to the XSI API, AMD recommends that you zero out the
s_xsi_setup_info struct before filling in the fields, as shown in the xsi_open.
The plain (non-loader) form of the function returns an xsiHandle, a C object containing process
state information about the design, to be used with all other plain-form XSI functions. The loader
form of the function has no return value. However, you might check whether the loader has
opened a design by querying the isopen member function, which returns true if the open
member function had been invoked.
Example
#include "xsi.h"
#include "xsi_loader.h"
...
Xsi::Loader loader("xsim.dir/mySnapshot/
xsimk.so","librdi_simulator_kernel.so");
s_xsi_setup_info info;
memset(&info, 0, sizeof(info));
info.logFileName = NULL;
char wdbName[] = "test.wdb"; // make a buffer for holding the string
"test.wdb"
info.wdbFileName = wdbName;
loader.open(&info);
xsi_put_value
void xsi_put_value(xsiHandle design_handle, XSI_INT32 port_number, void*
value);
void Xsi::Loader::put_value(int port_number, const void* value);
This function deposits the value stored in value onto the port specified by port ID
port_number. See xsi_get_port_number for information on obtaining an ID for a port. value is
a pointer to a memory buffer that your program must allocate and fill. See the Vivado Simulator
VHDL Data Format and Vivado Simulator Verilog Data Format for information on the proper
format of value.
CAUTION! For maximum performance, the Vivado simulator performs no checking on the size or type of
the value you pass to xsi_put_value. Passing a value to xsi_put_value, which does not match the
size and type of the port might result in unpredictable behavior of your program and the Vivado simulator.
Example code:
#include "xsi.h"
#include "xsi_loader.h"
...
// Hard-coded Buffer for a 1-bit "1" Verilog 4-state value
const s_xsi_vlog_logicval one_val = {0X00000001, 0X00000000};
Xsi::Loader loader("xsim.dir/mySnapshot/
xsimk.so","librdi_simulator_kernel.so");
...
int clk = loader.get_port_number("clk");
loader.put_value(clk, &one_val); // set clk to 1
xsi_restart
void xsi_restart(xsiHandle design_handle);
void Xsi::Loader:: restart();
xsi_run
void xsi_run(xsiHandle design_handle, XSI_UINT64 time_ticks);
void Xsi::Loader::run(XSI_INT64 step);
This function runs the simulation for the given amount of time specified in kernel precision units.
A kernel precision unit is the smallest unit of time precision specified among all HDL source files
of the design. For example, if a design has two source files, one of which specifies a precision of 1
ns and the other specifies a precision of 1 ps, the kernel precision unit becomes 1 ps, as that time
unit is the smaller of the two.
A Verilog source file might specify the time precision using the `timescale directive.
Example:
`timescale 1ns/1ps
In this example, the time unit after the / (1 ps) is the time precision. VHDL has no equivalent of
`timescale.
You might additionally adjust the kernel precision unit through the use of the xelab command-
line options --timescale, --override_timeprecision, and --timeprecision_vhdl.
See xelab, xvhdl, and xvlog xsim Command Options for information on the use of these
command-line options.
Note: xsi_run blocks until the specified simulation runtime has elapsed. Your program and the Vivado
simulator share a single thread of execution.
xsi_trace_all
void xsi_trace_all(xsiHandle design_handle);
void Xsi::Loader:: trace_all();
Call this function after xsi_open to turn on waveform tracing for all signals of the HDL design.
Running the simulation with waveform tracing causes the Vivado simulator to produce a
waveform database (WDB) file containing all events for every signal in the design. The default
name of the WDB file is xsim.wdb. To specify a different WDB file name, set the
wdbFileName field of the s_xsi_setup_info struct when calling xsi_open, as shown in
the example code.
Example code:
#include "xsi.h"
#include "xsi_loader.h"
...
Xsi::Loader loader("xsim.dir/mySnapshot/
xsimk.so","librdi_simulator_kernel.so");
s_xsi_setup_info info;
memset(&info, 0, sizeof(info));
char wdbName[] = "test.wdb"; // make a buffer for holding the string
"test.wdb"
info.wdbFileName = wdbName;
loader.open(&info);
loader.trace_all();
After the simulation completes, you can open the WDB file in Vivado to examine the waveforms
of the signals. See Opening a Previously Saved Simulation Run for more information on how to
view WDB files in Vivado.
IMPORTANT! When compiling the HDL design, you must specify -debug all or -debug typical
on the xelab command line. The Vivado simulator does not record the waveform data without the -
debug command line option.
Example code:
Example code:
Example code:
Example code:
Example code:
VHDL arrays are organized in C/C++ with the left index of the VHDL array mapped to C/C++
array element 0 and the right index mapped to C/C++ element <array size> - 1.
Example code:
Each four-state bit of Verilog value occupies one bit position in aVal and the corresponding bit
position in bVal.
For two-state SystemVerilog bit values, an aVal bit holds the bit value, and the corresponding
bVal bit is unused. AMD recommends that you zero out bVal when composing two-state
values for xsi_put_value.
Verilog vectors are organized in C/C++ with the right index of the Verilog vector mapped to
aVal/bVal bit position 0 and the left index mapped to aVal/bVal bit position <vector size> -
1.
aVal/bVal Bit Position <vector size> to <vector size> - <vector size> - 2 ... 1 0
31 1
Index of unused left left - 1 ... right + 1 right
wire [left:right] vec
(where left > right)
Index of unused left left + 1 ... right - 1 right
wire [left:right] vec
(where left < right)
For example, the following table shows the Verilog and C/C++ equivalents of the following
Verilog vector.
The C/C++ representation of a Verilog vector with more than 32 elements is an array of
s_xsi_vlog_logicval, for which the right-most 32 bits of the Verilog vector maps to
element 0 of the C/C++ array. The next 32 bits of the Verilog vector maps to element 1 of the
C/C++ array, and so forth. For example, the following table shows the mapping of Verilog vector
s_xsi_vlog_logicval val[3];
Hence, vec[2] maps to val[3] bit position 3, and vec[69] maps to val[0] bit position 0.
Appendix M
The AMD Technical Information Portal is an online tool that provides robust search and
navigation for documentation using your web browser. To access the Technical Information
Portal, go to https://docs.amd.com.
Documentation Navigator
Documentation Navigator (DocNav) is an installed tool that provides access to AMD Adaptive
Computing documents, videos, and support resources, which you can filter and search to find
information. To open DocNav:
• From the AMD Vivado™ IDE, select Help → Documentation and Tutorials.
• On Windows, click the Start button and select Xilinx Design Tools → DocNav.
• At the Linux command prompt, enter docnav.
Note: For more information on DocNav, refer to the Documentation Navigator User Guide (UG968).
Design Hubs
AMD Design Hubs provide links to documentation organized by design tasks and other topics,
which you can use to learn key concepts and address frequently asked questions. To access the
Design Hubs:
Support Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see Support.
References
These documents provide supplemental material useful with this guide:
1. Vivado Design Suite User Guide: Release Notes, Installation, and Licensing (UG973)
2. Vivado Design Suite User Guide: System-Level Design Entry (UG895)
3. Vivado Design Suite User Guide: Designing with IP (UG896)
4. Vivado Design Suite User Guide: Using the Vivado IDE (UG893)
5. Vivado Design Suite User Guide: Using Tcl Scripting (UG894)
6. Vivado Design Suite 7 Series FPGA and Zynq-7000 SoC Libraries Guide (UG953)
7. Vivado Design Suite Tcl Command Reference Guide (UG835)
8. Vivado Design Suite User Guide: Power Analysis and Optimization (UG907)
9. Vivado Design Suite User Guide: Using Constraints (UG903)
10. Vivado Design Suite Tutorial: Logic Simulation (UG937)
11. Vivado Design Suite User Guide: Design Flows Overview (UG892)
12. Vivado Design Suite Properties Reference Guide (UG912)
13. Vivado Design Suite User Guide: Synthesis (UG901)
14. Writing Efficient Test Benches (XAPP199)
15. IEEE Standard VHDL Language Reference Manual (IEEE-STD-1076-1993)
16. IEEE Standard Verilog Hardware Description Language(IEEE-STD-1364-2001)
17. IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification
Language (IEEE-STD-1800-2009)
18. Standard Delay Format Specification (SDF) (IEEE-STD-1497-2004)
19. Recommended Practice for Encryption and Management of Electronic Design Intellectual
Property (IP) (IEEE-STD-P1735)
Training Resources
AMD provides a variety of training courses and QuickTake videos to help you learn more about
the concepts presented in this document. Use these links to explore related training resources:
Revision History
The following table shows the revision history for this document.
Copyright
© Copyright 2012-2024 Advanced Micro Devices, Inc. AMD, the AMD Arrow logo, Artix, Kintex,
UltraScale, UltraScale+, Versal, Virtex, Vivado, Zynq, and combinations thereof are trademarks of
Advanced Micro Devices, Inc.AMBA, AMBA Designer, Arm, ARM1176JZ-S, CoreSight, Cortex,
PrimeCell, Mali, and MPCore are trademarks of Arm Limited in the US and/or elsewhere.PCI,
PCIe, and PCI Express are trademarks of PCI-SIG and used under license. Other product names
used in this publication are for identification purposes only and may be trademarks of their
respective companies.