Design Verification

This section introduces design verification, which is the process of testing the functionality and performance of your design. The Xilinx Development System supports three complementary methods for design verification: simulation, static timing analysis, and in-circuit verification.

Overview

Design verification procedures should occur throughout your design process, as illustrated in the following figure.

Figure 2.9 Three Verification Methods of the Design Flow (FPGAs)

Figure 2.10 Three Verification Methods of the Design Flow (CPLDs)

You can verify Xilinx designs in three different ways.

• Simulation
  
  
• Static timing
  
  
• In-circuit verification
  
  

Each verification type uses different design tools; see the following figure for a description.

Figure 2.11 Verification Tools

Pre-Simulation Translation

Before simulation occurs, the physical design information must be translated and distributed back to the logical design. For FPGAs, this back-annotation process is done with a program called NGDAnno. For CPLDs, back-annotation is performed with the TSIM Timing Simulator. These programs create a database for the netlist writers, which translate the back-annotated information into a netlist format that can be used for simulation. The back-annotation flows are shown in the following figures.

Figure 2.12 Back-Annotation (FPGAs Only)

Figure 2.13 Back-Annotation (CPLDs Only)

Note: The NGD2XNF program (and the XNF output file format) are not supported in the 2.1i software.

NGDAnno (FPGA's Only)

NGDAnno is a program that distributes delays, setup and hold time, and pulse widths found in the physical NCD design file back to the logical NGD file.

NGDAnno merges mapping information from the NGM file with placement, routing, and timing information from the NCD file. This data is combined into a generic annotated (NGA) file. The NGA file is input to the appropriate netlist writer (NGD2EDIF, NGD2VER, or NGD2VHDL) which then converts the binary Xilinx database format back to an ASCII netlist.

Note: Use caution when making changes to the functional behavior of your design. For example, if you make logical changes to an NCD design from within the FPGA Editor, the graphical design editor, NGDAnno will be unable to correlate the changed objects in the physical design with the objects in the logical design.
It will then recreate the entire NGA design from the NCD and issue a warning indicating that the NCD is out of sync with the NGM.

An NCD file is input to the NGDAnno program. The NCD file can be a mapped-only design, or a partial or fully placed and routed design. An NGM file which is created by the mapper is an optional source of input.

The output of NGDAnno is an NGA file, which is a back-annotated NGD file. For details on NGDAnno refer to the “NGDAnno” chapter.

CPLD command

The CPLD command automatically generates the NGA file unless the command is run with the notsim option. For a description of the CPLD command and its options, refer to the “Fitter Command and Option Summary” appendix in the CPLD Synthesis Design Guide.

Netlist Writers

Netlist writers take the output of NGDAnno or the CPLD command and create a simulation netlist in the specified format. An NGD or NGA file is input to each of the netlist writers. The NGD file is a logical design file containing primitive components, while the NGA file is a back-annotated logical design file. Following is a list of the supported netlist writers with descriptions of their input and output files.

• NGD2EDIF - takes an NGD or NGA file and translates it into an EDIF netlist.
  
  Output from the NGD2EDIF program is an EDN file, a netlist in EDIF format. The default EDN file produced by NGD2EDIF is generic. If you want to produce EDIF targeted to Mentor Graphics or Viewlogic, you must include the -v (vendor) option.
  
  
• NGD2VER - translates an NGD or NGA file into a Verilog netlist (V) file. If the input is an NGA file, NGD2VER will also generate an SDF (Standard Delay Format) file.
  
  The resulting V and SDF files will have the same root name as the NGD or NGA file unless you specify otherwise.
  
  
  
  The SDF file contains timing information intended solely for use with the Verilog file which was generated from the same NGA file. Do not attempt to use the SDF file in conjunction with the original Verilog netlist design or the product of another netlist writer.
  
  
• NGD2VHDL - translates an NGD or NGA file into a VHDL netlist (VHD). If the input file is an NGA file, NGD2VHDL will also generate an SDF (Standard Delay Format) file. The VHD and SDF files will have a tim_sim root name by default. To change the root name of your files, go to the Simulation Data Options dialog box and select the VHDL/Verilog tab.
  
  For more information on the Netlist Writers or NGDAnno, refer to later chapters in this manual.
  
  

Invoking Netlist Writer Programs

You can invoke any of the supported netlist writer programs (for example, NGD2VER, NGD2EDIF) from the UNIX or DOS command line. Most of the programs can be invoked from the Design Manager for Alliance or the Project Manager for Foundation.

Select the NGD2 and netlist writer commands as follows.

1. If you are an Alliance user, proceed as follows:
   
   
   1. Open the Xilinx Design Manager.
      
      
   2. Select Design Implement.
      
      
   3. Select a part and then click the Options button.
      
      
   4. Proceed to Step 3.
      
      
2. If you are a Foundation User, proceed as follows:
   
   
   1. Open the Project Manager.
      
      
   2. Click Implementation Implementation Options.
      
      
   3. Proceed to Step 3.
      
      
3. Select a netlist writer program from the Simulation drop-down list box.
   
   

Additional Translation Options

In addition to back-annotating a fully routed design, you can also back-annotate a translated but unmapped design and a mapped but unrouted design for FPGAs. You can also create an output netlist to allow simulation of the design at the different stages of development in the Xilinx environment.

For example, if you want to verify that the circuit logic is correct before you implement the design, you can use the data in a non-implemented NGD design as input to the netlist writers NGD2EDIF, NGD2VER, or NGD2VHDL. You then run a simulation program on the resulting netlist.

To simulate a design that contains only IOB and CLB block delays, you can take the NCD file produced by MAP and then run NGDAnno. Afterwards, run the appropriate netlist writer to generate a simulatable netlist.

Block delays are generally 50% of your path delay. Simulating with block delays is an imprecise method of determining whether your timing will be met before you actually place and route. (However, this simulation type is less time consuming than performing a full timing simulation.) The simulation process is shown in the “Back-Annotation (FPGAs Only)” figure.

Schematic-Based Simulation

Design simulation involves testing your design using software models. It is most effective when testing the functionality of your design and its performance under worst-case conditions. You can easily probe internal nodes to check your circuit's behavior, and then use these results to make changes in your schematic.

Simulation is performed using third-party tools that are linked to the Xilinx Development System. Use the various CAE-specific interface user guides, which cover the commands and features of the Xilinx-supported simulators, as your primary reference.

The software models provided for your simulation tools are designed to perform detailed characterization of your design. You can perform functional or timing simulation, as described in the following sections.

Functional Simulation

Functional simulation determines if the logic in your design is correct before you implement it in a device.

Functional simulation can take place at the earliest stages of the design flow. Since timing information for the implemented design is not available at this stage, the simulator tests the logic in the design using unit delays.

Note: It is usually faster and easier to correct design errors if you perform functional simulation early in the design flow.

The verification methods figures show the design flows for integrated and non-integrated simulation tools. Integrated tools such as Mentor or Viewlogic contain a built-in interface which links the simulator and a schematic editor, allowing the tools to use the same netlist. You can move directly from entry to simulation when using a set of integrated tools.

Functional simulation in schematic-based tools is usually performed immediately after Design Entry in the capture environment. The schematic capture tool requires a Xilinx Unified Library and the simulator requires a library if the tools are not integrated. Most of the schematic-based tools will require translation from their native database to XNF or EDIF for implementation. The return path from implementation is usually XNF or EDIF with certain exceptions where a schematic tool is tied to an HDL simulator.

Timing Simulation

Timing simulation verifies that your design runs at the desired speed for your device under worst-case conditions. This process is performed after your design is mapped, and placed and routed for FPGAs or fitted for CPLDs. At this time, all design delays are known.

Timing simulation is valuable because it can verify timing relationships and determine the critical paths for the design under worst-case conditions. It can also determine whether or not the design contains set-up or hold violations.

To input timing information into your design, you must convert the routed NCD file into an NGA file. The resulting NGA file can then be translated by NGD2EDIF, NGD2VER, or XNF2NGD. These netlist writers create suitable formats for various simulators.

Note: Naming the nets during your design entry is very important for both functional and timing simulation. This allows you to find the nets in the simulations more easily than looking for a machine-generated name.

HDL-Based Simulation

Xilinx supports functional and timing simulation of HDL designs at the following three points in the HDL design flow as shown in the following figure.

Figure 2.14 Three Simulation Points for HDL Designs

• Register Transfer Level (RTL simulation which may include the following
  
  
  • Instantiated UNISIM library components
    
    
  • LogiBLOX modules
    
    
  • LogiCORE models
    
    
• Post-synthesis functional simulation with one of the following.
  
  
  • Gate-level UNISIM library components
    
    
  • Gate-level pre-route SIMPRIM library components
    
    
• Post-implementation back-annotated timing simulation with the following.
  
  
  • SIMPRIM library components
    
    
  • Standard Delay Format (SDF) file
    
    

The three primary simulation points can be expanded to allow for two additional post-synthesis simulations, as shown in the following table. These two additional points can be used when the synthesis tool either cannot write VHDL or Verilog, or if the netlist is not in terms of UNISIM components.

Table 2_3 Five Simulation Points in HDL Design Flow

These simulation points are described in various sections of the “Simulating Your Design” chapter of the Synthesis and Simulation Design Guide. These sections include the following:

• “Functional Simulation”
  
  
• “Timing Simulation”
  
  

The libraries required to support the simulation flows are described in detail in the “Using VHDL/Verilog Libraries and Models” section. The new flows and libraries now support closer functional equivalence of initialization behavior between functional and timing simulations. This is due to the addition of new methodologies and library cells to simulate GSR/GTS behavior.

It is important to address the built-in reset circuitry behavior in your designs starting with the first simulation to ensure that the simulations agree at the three primary points.

If you do not simulate GSR (Global Set/Reset) behavior prior to synthesis and place and route, your RTL and possibly post-synthesis simulations will not initialize to the same state as your post-route timing simulation. As a result, your various design descriptions are not functionally equivalent and your simulation results will not match. In addition to the behavioral representation for GSR, you need to add a Xilinx implementation directive. This directive is used to specify to the place and route tools to use the special purpose GSR net that is pre-routed on the chip, and not to use the local asynchronous set/reset pins. Some synthesis tools can identify, from the behavioral description, the GSR net, and will place the STARTUP module on the net to direct the implementation tools to use the global network. However, other synthesis tools interpret behavioral descriptions literally, and will introduce additional logic into your design to implement a function. Without specific instructions to use device global networks, the Xilinx implementation tools will use general purpose logic and interconnect resources to redundantly build functions already provided by the silicon.

Even if GSR behavior is not described, the actual chip initializes during configuration, and the post-route netlist will have this net that must be driven during simulation. The “Simulating Global Signals” section of the Synthesis and Simulation Design Guide includes the methodology to describe this behavior, as well as the GTS (Global Tristate) behavior for output buffers.

For a complete discussion of GSR and GTS, refer the following sections in the “Simulating Your Design” chapter of the Synthesis and Simulation Design Guide.

• “Adapting Schematic Global Signal Methodology for VHDL”
  
  
• “Setting VHDL Global Set/Reset Emulation in Functional Simulation”
  
  
• “Setting Verilog Global Set/Reset”
  
  
• “Setting Verilog Global Tristate (XC4000, Spartan, and XC5200 Outputs Only)”
  
  

Xilinx VHDL simulation supports the VITAL standard. This standard allows you to simulate with any VITAL-compliant simulator, including MTI/Mentor^® ModelSim, Synopsys VSS, and Active-VHDL.

Built-in Verilog support allows you to simulate with the Cadence Verilog-XL and other compatible simulators. Xilinx HDL simulation supports all current Xilinx FPGA and CPLD devices. Refer to the “Using VHDL/Verilog Libraries and Models” section for the list of supported VHDL and Verilog standards.

For information about CPLD HDL simulation refer to the “Simulating Your Design” chapter of the CPLD Synthesis Design Guide.

Static Timing Analysis With TRACE (FPGAs Only)

Static timing analysis is best for quick timing checks of a design after placement and routing is complete.

TRACE (Timing Reporter and Circuit Evaluator) is a Xilinx application program designed to provide static timing analysis and can be used to evaluate how well the place and route tools have met any input timing constraints.

By using TRACE, you can quickly check for timing problems in your FPGA design. You can also use TRACE to determine path delays in your design.

TRACE performs two major functions.

• Timing verification - the process of verifying that the design meets your timing constraints.
  
  
• Reporting - the process of enumerating input constraint violations and placing them into an accessible file. TRACE can be run on partially or completely placed and routed designs. The timing information reported issued by TRACE depends on the completeness of the placement and routing of the input design.
  
  

Within the Design Manager, TRACE is run using the Timing Analyzer. See the Timing Analyzer Guide for details.

In-Circuit Verification

As a final test, you can verify how your design performs in the target application. In-circuit verification tests the circuit under typical operating conditions. Because you can program your Xilinx devices repeatedly, you can easily load different iterations of your design into your device and test it in-circuit. To verify your design in-circuit, download your design bitstream into a device with the Xilinx XChecker Cable, Parallel Cable III, or MultiLINX cable.

Note: For information about Xilinx cables and hardware, see the Hardware User Guide.

Design Rule Checker (FPGAs Only)

Before generating the final bitstream, it is important to use the DRC option in BitGen to evaluate the NCD file for problems that could prevent the design from functioning properly. DRC will be invoked automatically unless you use the -d option.

Xilinx Design Download Cables

Xilinx provides the Parallel Cable III, XChecker cable, or MultiLINX cable, depending on which development system you are using. To download your design, you must create a configuration bitstream.

For FPGAs, you can use the XChecker or MultiLINX cable to read back and verify configuration data. Detailed cable connection and daisy-chain information is provided in the Hardware Debugger Guide.

Note: The Xilinx Parallel Cable III can be used for FPGA and CPLD design download and readback, but it does not have a design verification function.

With the XChecker cable, you can use the Hardware Debugger Pick function to take snapshots of the circuit at specific clock cycles. You can obtain these snapshots by performing serial readback of the nodes during in-circuit operation. With the Hardware Debugger software, you can speed up your analysis by limiting the readback bitstream to only those nodes and clock cycles in which you have interest.

You can also use the XChecker cable to probe your design after you download it. Probing internal nodes allows you to pinpoint the location of any design problems.

Use the XChecker cable when you do not want to specify additional IOBs and routing resources on your Xilinx FPGA for probing. This allows you to decide how you want to probe after you have downloaded your design.

The MultiLINX Cable is compatible in supporting Readback & Verify for all the FPGAs supported by the XChecker cable. In addition to the supporting legacy devices, the MultiLINX Cable supports the devices that were not supported by the XChecker cable. Supported devices include those devices in the 4000E, 4000XL, and Spartan families whose bit file size is more than 256K bits. The MultiLINX Cable also supports readback & verify for the new Virtex family.

Note: Debug is not available with the MultiLINX Cable in 2.1i.