The Xilinx VHDL and Verilog simulation solution allows you to manage design changes more quickly and efficiently when using any combination of FPGA and CPLD devices. The VHDL simulation solution supports the VITAL standard, which enables you to simulate with any VITAL-compliant simulator, including Mentor QuickHDL, Synopsys VSS, and Cadence Leapfrog. Built-in Verilog support allows you to simulate with the Cadence Verilog-XL and other compatible simulators. The Xilinx HDL solution supports the XC3100A, XC4000E, XC4000X, XC5200, XC9500, Spartan, SpartanXL, and Virtex families.
The following three sections detail the processes of VHDL and Verilog simulation. The “VHDL and Verilog Libraries” section discusses the UNISIM and LogiBLOX Libraries, and how Xilinx supports them with additional components. The “VHDL Global Set/Reset Emulation” section describes the cells needed for this process, and the “VHDL and Verilog Simulation Flow” section describes the five phases in the design flow where HDL simulation can occur.
A typical single chip VHDL or Verilog design flow consists of generating a VHDL RTL (Register Transfer Level) description, a VHDL RTL simulation, synthesis implementation, optional unit delay gate-level functional simulation, and timing simulation. See the “HDL Simulation Design Cycle” figure for more information.
RTL simulation is primarily a behavioral description of your design's behavior at the register transfer level. RTL simulation is not FPGA or CPLD architecture specific (for simulation purposes) unless it contains instantiated unified Library components of instantiated LogiBLOX components.
Xilinx provides two libraries to support these instantiations: a functional UNISIM Library and a behavioral LogiBLOX library.
The following sections describe various aspects of these libraries.
There are two related areas in which Xilinx has furthered support for customers using the libraries of different vendors. Descriptions of VITAL and Verilog library support follow.
The following figure shows the HDL design cycle process.
Figure 4.5 HDL Simulation Design Cycle |  |
The UNISIM Library is for functional simulation only and contains default unit delays. Due to variations in language features and methodologies, the VHDL and Verilog versions of the UNISIM Library are different. Post-synthesis, gate-level simulation will also use the UNISIM library as discussed in the “VHDL and Verilog Simulation Flow” section. Post-NGDBuild and post-map partial timing simulations will use the SIMPRIM library, as will the full timing, back-annotated simulation.
There is only one VHDL library for all Xilinx technologies, as the implementation differences between architectures are not important for unit delay functional simulation. Functional differences in libraries are important to note, but they rarely occur. (Synopsys FPGA users can use a VHDL DesignWare library. For details, refer to the Synopsys (XSI) Interface Tutorial Guide.)
For example, in some instances, configuration statements are used to choose between architectures for the components. Using one source library makes it easier to switch between technologies. You are responsible for using technology-appropriate cells with your chosen synthesis tool. Since Verilog does not have a configuration statement, separate libraries are provided for each technology.
The UNISIM Library contains all of the Xilinx Unified Library components known to be inferred by major vendors' synthesis tools. In addition, the UNISIM Library contains components most commonly instantiated, like I/Os and memory cells. The synthesis tool's module generators, or LogiBLOX, should be used to generate higher order functions, such as adders, counters, and larger RAM's. You can also use the new Xilinx CORE Generator for this purpose.
Schematic macros are not provided, since major schematic vendors are expected to provide the lower-level netlist when the design is imported into a synthesis tool. This lower-level netlist for a schematic macro is required for implementation as well. The VHDL models for Synopsys DesignWare components can be found in the Xilinx Synopsys Interface at $XILINX/synopsys/libraries/sim/src/xdw. Verilog versions of the DesignWare components are not currently available.
The VHDL version of the UNISIM Library is VITAL compliant, and therefore may be accelerated, but it is not expected to be back-annotated with an SDF file. The library needs to be compiled for each HDL simulator. Xilinx provides the source files for this purpose. The files are located at $XILINX/vhdl/src/unisims. The source file should be compiled into a library named UNISIM.
The Verilog version may or may not have to be compiled, depending on the Verilog tool. Since there are a few cells with functional differences between Xilinx technologies, a separate library is provided for each supported technology. The prime example is that decoders have pull-ups in some technologies and not in others. The libraries are in uppercase only. Lowercase libraries can be found in the Xilinx Cadence Interface if needed. The libraries are found at $XILINX/verilog/src/<technology>, where <technology> can be UNI3000, UNI4000E, UNI4000X, UNI5000, or UNI9000. Virtex libraries are found at $XILINX/verilog/src/UNIVIRTEX.
There are small differences in uppercase libraries. Lowercase Verilog has already reserved the words buf, pullup, and pulldown so the Xilinx versions are changed to buff, pullup1, nd pullup2, then remapped to the proper cell during implementation.
The UNISIM VHDL library (or Verilog if required) may be compiled to any physical location the user or their system administrator desires. The VHDL source files are found in $XILINX/vhdl/src/unisims and are listed below in the order in which they must be compiled.
The uppercase Verilog components are found in individual component files in the following directories.
Components from the UNISIM Library may be instantiated in your design and simulated during the RTL simulation. The VHDL code must refer to the UNISIM library compiled by the user or the system administrator. Then, the VHDL simulation tool maps the logical library to the physical location of the compiled library. Verilog must also map to the UNISIM Verilog library. VHDL component declarations are already provided in the library and need not be repeated in your code.
LogiBLOX is a module generator which is primarily used for schematic-based design entry of modules such as adders, counters and large memory blocks. In an HDL flow, it can be used for generating large blocks of memory for instantiation. Refer to the LogiBLOX User Guide for more information.
The LogiBLOX VHDL library (or Verilog if required) may be compiled to any physical location that you desire. The VHDL source files are found in $XILINX/vhdl/src/logiblox. The following list shows the order in which the files must be compiled.
The verilog source files are found in the following directory:
$XILINX/verilog/src/logiblox
LogiBLOX components are simulated with behavioral code. They are not intended to be synthesized, but they can be simulated. The synthesizer must not be given the architecture or modules, but should treat the component as a black box. Implementation will pick up the NGO fie created by LogiBLOX. The source libraries for LogiBLOX packages are found at $XILINX/vhdl/src/logiblox and $XILINX/verilog/src/logiblox. The actual models are an output of the LogiBLOX tool. The package files need to be compiled into a library called LOGIBLOX. The component model from the LogiBLOX GUI should be compiled into your working directory with the rest of your design.
VHDL requires ports for all signals to be controlled by a testbench. There are VHDL-specific components that can be instantiated in the RTL and post-synthesis VHDL description in order to enable the simulation of the global signals for Global Set/Reset and Global Tri-state. NGD2VHDL creates a port on the back-annotated design entity for stimulating the global set/reset or tri-state enable signals. This port does not actually exist on the configured part.
You do not need to use the -gp switch to create an external port if you instantiated a StartUp block in the implemented design. In that case, the port is already identified and connected to the global set/reset or tri-state enable signal.
If you do not use the -gp option or a Startup block, you will need to use a special cell.
The VHDL only STARTUP Block was traditionally instantiated to identify the GR, PRLD, or GSR signals for implementation. However, the only time simulation was enabled in the traditional usage was when the net attached to the GSR or GTS also went off-chip. This happens because the STARTUP block does not have a simulation model. The new cells below can be used to simulate global set/reset or tri-state nets in all cases, whether or not the signal goes off chip.
There are several types of emulation cells, as the following list shows. Click a cell title for more information about a specific cell type.
The Virtex device series also includes two cells, the STARTUP_VIRTEX and STARTBUF_VIRTEX. For more information on these cells, refer to the Development System Reference Guide.
For information about Verilog only Set/Reset Emulation, Tri-State Emulation, and Oscillators, refer to the Cadence Interface/Tutorial Guide.
Detailed information about specific emulation cells and their uses follow.
The STARTBUF cell passes a reset or tri-state signal in the same way that a buffer would allow simulation to proceed. The cell also instantiates the STARTUP block for implementation. STARTBUF is a more simulation-friendly version of a typical STARTUP block. Though the same version works for all technologies, the XC5200 and XC4000 STARTUP blocks have different pin names. Implementation with the correct STARTUP block is handled automatically. An instantiation example for the STARTBUF cell follows.
U1: STARTBUF port map (GSRIN => DEV_GSR_PORT, GTSIN =>
DEV_GTS_PORT, CLKIN => `0', GSROUT => GSR_NET, GTSOUT
=> GTS_NET, Q2OUT => open, Q3OUT => open, Q1Q4OUT =>
open, DONEINOUT => open):One or both of the input ports GSRIN and GTSIN of the STARTBUF component and the associated output ports GSROUT and GTSOUT can be used. The other pins that are left “open” can be used to pass configuration instructions down to implementation, just as on a traditional STARTUP block. You can do this by connecting the appropriate signal to the port instead of leaving it in an “open” condition.
This cell is created during back-annotation if you do not use the -gp option or StartUp block options. It can therefore be instantiated in the front end to match for functionality with GSR, GR, or PRLD. (This is done in both functional and timing simulation.) During back-annotation, the entity and architecture for the ROC cell is placed in the design's output VHDL file. In the front end, the entity and architecture are in the UNISIM Library, requiring only a component instantiation. The ROC cell generates a one-time initial pulse to drive the GR, GSR, or PRLD net starting at time `0' for a user-defined pulse width. The pulse width can be set with a generic in a configuration statement. The default value of “width” is 0 ns, which disables the ROC cell and results in the global set/reset being held low. (Active low resets are handled within the netlist itself and require you to invert this signal before using it.)
The ROC cell enables you to simulate with the same testbench as in the RTL simulation, and also allows you to control the width of the global set/reset signal in the implemented design.
The ROC components require a value for the generic WIDTH, usually specified with a configuration statement. Otherwise, a generic map is required as part of the component instantiation.
You may set the generic with any generic mapping method you choose. Set the “width” generic after consulting the Xilinx Programmable Logic Data Book for the particular part and mode you have implemented.
For example, a XC4000E part can vary from 10 ms to 130 ms. The value to look for is the TPOR (Power-ON Reset) parameter found in the Configuration Switching Characteristics tables for Master, Slave, and Peripheral modes.
One of the easiest methods for mapping the generic is a configuration for the user's testbench. An example testbench configuration for setting the generic is shown below.
CONFIGURATION cfg_my_timing_testbench OF my_testbench IS
FOR my_testbench_architecture
FOR ALL:my_design USE ENTITY work.my_design(structure);
FOR structure
FOR ALL:roc ENTITY work.roc (structure);
Generic MAP (width => 100 ms)
END FOR;
END FOR;
END FOR;
END FOR;
END cfg_my_timing_testbench;The following is an instantiation example for the ROC cell.
U1: ROC port map (0 =>GSR_NET);THe ROCBUF allows the user to provide stimulus for the Reset on Configuration signal through a testbench but the port connected to it will not be implemented as a chip pin. The port can be brought back in the timing simulation with the -gp switch on NGD2VHDL. An example of instantiation of the ROCBUF cell follows.
U1: ROCBUF port map (I => SIM_GSR_PORT, O +> GSR_NET);This cell is created if you do not use the -tp or StartUp block options. The entity and architecture for the TOC cell is placed in the design's output VHDL file. The TOC cell generates a one-time initial pulse to drive the GR, GSR, or PRLD net starting at time `0'. The user-defined pulse width can be set with a generic. The default value of “width” is 0 ns, which disables the TOC cell and results in the tri-state enable being held low. (Active low tri-state enables are handled within the netlist itself and require you to invert this signal before using it.)
The TOC cell enables you to simulate with the same testbench as in the RTL simulation, and also allows you to control the width of the tri-state enable signal in the implemented design.
The TOC components require a value for the generic WIDTH, usually specified with a configuration statement. Otherwise, a generic map is required as part of the component instantiation.
You may set the generic with any generic mapping method you choose. Set the “width” generic after consulting the Xilinx Programmable Logic Data Book for the particular part and mode you have implemented.
For example, an XC4000E part can vary from 10 ms to 130 ms. The value to look for is the TPOR (Power-On Reset) parameter found in the Configuration Switching Characteristics tables for Master, Slave, and Peripheral modes.
One of the easiest methods for mapping the generic is a configuration for the user's testbench. An example testbench configuration for setting the generic is shown below.
CONFIGURATION cfg_my_timing_testbench OF my_testbench IS
FOR my_testbench_architecture
FOR ALL:my_design USE ENTITY work.my_design(structrue);
FOR structure
FOR ALL:toc ENTITY work.toc (structure);
Generic MAP (width => 100 ms)
END FOR;
END FOR;
END FOR;
END FOR;
END cfg_my_timing_testbench;An instantiation example of the TOC cell follows.
U2: TOC port map (O => GTS_NET);The TOCBUF allows the user to provide stimulus for the global tri-state signal (GTS) through a testbench. However, the port connected to TOCBUF will not be implemented as a chip pin. The port can be brought back in the timing simulation with the -tp switch on NGD2VHDL. An example of the instantiation of the TOCBUF cell follows.
U2: TOCBUF port map (I =>SIM_GTS_PORT, O =>GTS_NET);Oscillators are output as a parametizable cell. The cell does not exist in the SIMPRIM library, since only in VHDL are you unable to drive global signals. Schematic simulators can define and drive global nets so the cell is not required. Verilog has the ability to drive nets within a lower level module as well. Therefore, the oscillator cells are only required in VHDL. After back-annotation, their entity and architectures are contained in the design's VHDL output. For functional simulation, they may be instantiated and simulated with the UNISIM Library.
The period of the base frequency must be set in order for the simulation to proceed, since the default period of 0 ns disables the oscillator. The oscillator's frequency can vary significantly with process and temperature.
Before you set the base period parameter, consult the Xilinx Programmable Logic Data Book for the particular part you are using.
For example, the section in the databook for the XC4000 Series On-Chip Oscillator states that the base frequency can be anything from 4MHz to 10 MHz, though it is nominally 8 MHz. This means the base period generic “period_8m” in the XC4000E's OSC4 VHDL model can range from 250 ns down to 100ns. An example of this follows.
CONFIGURATION cfg_my_functional_testbench OF my_testbench IS
FOR my_testbench_architecture
FOR ALL: my_design USE ENTITY work.my_design (my_design_rtl);
FOR my_design_rtl
FOR ALL:my_submodule USE ENTITY work.my_submodule
(my_submoduel_rtl);
FOR my_submodule_rtl
FOR all: osc4 USE ENTITY work.osc4 (structure)
GENERIC MAP (period_8m => 125 nS);
END FOR;
END FOR;
END FOR;
END FOR;
END FOR;
END FOR;
END cfg_my_testbench_functional;HDL simulation can occur at five different phases in the design flow (see the “VHDL and Verilog Simulation Flow” figure).
Figure 4.6 VHDL and Verilog Simulation Flow | |
RTL level simulation allows you to verify or simulate a description at the system or chip level. At this level, designers generally describe the system or chip by using high-level RTL language constructs. VHDL and Verilog simulators are used to exercise the design in order to check its functionality before it is implemented in gates. A testbench is created to model the environment of the system or chip. At this level the UNISIM Library can be used to instantiate cells from the Unified Library. LogiBLOX components may also be instantiated if the user does not want to rely upon the synthesis tool's module generation capabilities.
Post-synthesis gate-level simulation in the Xilinx design flow includes any simulation performed after any of the synthesis, map, or place and route stages.
The system or chip is synthesized to gates, then the testbench is re-used to simulate the synthesized result and check its consistency with the original design description. This form of simulation is known as post-synthesis, gate-level functional simulation.
A post-synthesis, pre-NGDBUILD gate-level functional simulation allows you to directly verify the design after it has been generated by the synthesis tool. If there are differences between the behavior of the original RTL description and the synthesized design, this may indicate a problem using the synthesis tool. The ability to simulate post-synthesis is synthesis vendor dependent. The synthesis tool needs to be able to write VHDL or Verilog output, and it needs to write it in terms of the UNISIM Library. LogiBLOX will still be behavioral models, and their modules will be expanded and represented as gates. Check with your synthesis vendor. The library usage guidelines laid out for RTL simulation would then also apply to post-synthesis gate-level functional simulation.
This type of functional simulation is performed when it is not possible to simulate the direct output of the synthesis tool. This occurs when the tool cannot write UNISIM-compatible VHDL or Verilog netlists. In this case, generic SIMPRIM library models are used. Like the post-synthesis, pre-NGDBUILD type of simulation, this type of gate level simulation allows you to verify that a design has been synthesized correctly. Post-Map Partial Timing (CLB and IOB Block Delays)
In the Xilinx design flow, you can perform a partial timing simulation after the design has been mapped (see the “VHDL and Verilog Simulation Flow” figure).
The resulting NCD file contains timing numbers for the CLB and IOB mapped blocks. At this point the design is not routed and does not contain net delays, with the exception of pre-laid out macros such as cores.
Once your design is routed using PAR, it can be simulated with the actual block and net timing delays, using the same testbench as in the earlier behavioral simulation.
The back-annotation process (NGDAnno) produces a netlist of Simprims annotated with the appropriate block and net delay data that arise from the place and route process.
Different simulation libraries are needed to support simulation before and after NGDBuild has been applied to a design. Prior to NGDBuild, designs are expressed as netlists containing Unified Library components. After NGDBuild, designs are expressed as netlists containing SIMPRIMS. While the impact of these library changes are largely transparent to the user, there are two noticeable effects. These are: the need to specify different simulation libraries for pre- and post-implementation simulation, and the appearance of different gate-level cells in pre- and post-implementation netlists.
