Showing results for 
Show  only  | Search instead for 
Did you mean: 

The World of Hardware Simulation

11 0 3,075

Hello and welcome to the Hardware simulation blog series. In this series we will review and explore the various Signal Integrity (SI) issues that affect today’s High-Speed Printed Circuit Board (PCB) designs, and how to avoid them using simulation.

If you are one of the novice engineers who took the plunge into the world of High-Speed design and are overwhelmed by the term “Signal Integrity Simulations”, don't fret.  Over the course of this blog journey, we will first review the basics and then move onto cover some more advanced topics.

We no longer live in the digital realm of “0’s” and “1’s” for signals, so we now need to account for the analog effects on the signal during its journey from Transmitter to Receiver.

With increasing clock speeds and faster rise/fall times, the PCB trace is no longer an ideal wire and is not transparent to the signals it carries. With the general rule of thumb that any trace longer than “3 times (in cm) the rise time (in ns) or 1.18 times (in inches) the rise time (in ns)” should be treated as a transmission line, and with rise/falls times in the nanosecond (ns)/picosecond (ps) range for today's high-speed signals, you get a sense of how even short traces will end up as transmission lines.

The package traces, leads, PCB traces, connectors, and cables all begin to influence these high-speed signals. If the impedance of these interfaces is not properly designed and matched, it can lead to signal integrity issues that will affect the performance and reliability of the system.

fig 1.jpg

Figure 1:   Ideal Digital Signal

fig 2.jpg

 Figure 2:  Real World Signals

The analog nature of the signal is apparent in the example above. If its effects are not properly accounted for, the signal can end up having overshoots, undershoots, and glitches which degrade the signal quality and affect the device operation.

Overshoots can reduce device reliability and in extreme cases, cause irreversible damage to the device. Undershoots can cause the same, as well as reverse biasing the substrate which causes the device to operate in ways in which it was never intended to be operated.

With the advancement of PCB technology, and high-speed PCB designs which can have micro vias, buried vias, and blind vias, it is no longer always feasible to probe the signals of interest and debug them. Combined with the shorter design cycles and faster time to market requirements of a product, Hardware simulation (a.k.a Signal Integrity simulation) is no longer optional. It has become mandatory in order to get the product right the first time and to save huge amounts of cost and time debugging faulty PCB designs in the lab. 

Over the course of this series, we will cover topics related to various aspects of High Speed PCB design that designers must deal with, and see how Hardware simulations can help eliminate the guesswork during the design phase. The goal is to help designers catch and solve problems early in the design cycle. This is less expensive and more efficient than debugging the prototypes in a lab, going through multiple layout cycles, and spending valuable time, money, and effort.

Mentor Graphics® Hyperlynx® v9.4.2 is the SI simulation tool that will be used during this series as a mechanism to help describe the various concepts. Hyperlynx®  is just one SI tool on the market and there are many other tools available from other vendors. The concepts covered in this series remain the same whichever tool is used. Xilinx has no recommendation on any particular third-party SI tool, Hyperlynx®  just happens to be the tool used in this series to elaborate on the concepts covered.

Models for SI simulation

First let's look at the various models available for SI simulation, the differences between them, and which are preferrable when running an SI simulation.

SPICE Models:

SPICE stands for Simulation Program with Integrated Circuit Emphasis. As the names suggests, the models are very detailed right down to the transistor level and process parameters. These are very accurate and highly complex. However due to the circuit being described at the transistor level (which is proprietary information), not all device vendors will have these models available for SI simulation. There is also the limitation that not all SPICE simulators are fully compatible.

Xilinx provides encrypted HSPICE models (except for the UltraScale+ family) which need to be run with the HSPICE simulation tool from Synopsys®.These models can be download here.

IBIS Models:

IBIS stands for I/O Buffer Information Specification and is a standard for describing the analog behavior of buffers of digital device using plain ASCII text formatted data. These are behavioral level models that represent the I/V characteristics and dV/dt for the typical, minimum, and maximum case corners for inputs and outputs. Because they are behavioral models with no propriety data revealed, these models are the most popular type released by vendors to simulate the Input/Output (IO). They also have the advantages of being supported by all SI tools, and their ease of use.

A quick look at the important sections in an IBIS Model:

  • Header: Contains the general information of the model such as the File name, version, source, notes etc.
  • Component: Organizes all of the different models in the device to the pins
  • Model: Describes the characteristics of the driver and receiver of the various buffers
  • Define Package Model: Describes the package model of the device and provides the RLC matrix of the device pins.

IBIS Specification v6.1 (the latest as of today) contains detailed descriptions of the various syntax and header descriptions of the IBIS file and is the recommended document to understand the IBIS Model. It can be downloaded from 

The figure below compares the two models:

fig 3.JPG

 Figure 3:  Comparison of IBIS and SPICE Models

Xilinx IBIS Models are available for all devices and can be download from here. These models are generic in nature and do not map specific package pins to any I/O standard model. Unlike an ASIC, an FPGA is user programmable and the pinout is user specific except for a few dedicated pins.

The recommended method to get the IBIS Model is from Vivado Design Suite, which allows you to generate IBIS models. Vivado uses the netlist and implementation details from the design, and combines that information with the available per-pin parasitic package information to create a custom IBIS model for the design.

Remember, a simulation result is only as good as the quality of the model provided. Generating from Vivado gives you an IBIS Model that is mapped to your design I/O ports, and the best chance of it being error-free.   

Below are the steps to generate the IBIS model from Vivado for the following use-cases:

  1. With an RTL Design
  2. With no RTL Design
  3. For Zynq® MPSoC or Zynq®-7000 based designs

1. With an RTL Design:

If you have an RTL design, follow the steps below:

  1. Open an elaborated, synthesized, or implemented design
  2. Either a) select File  -> Export -> Export IBIS Models

            fig 4.jpg

           (Refer to the “Generating IBIS Model” section in (UG899) for details on the above options.)

       Or b) in the Tcl console run the "write_ibis" command with the below syntax.

       pic 6.jpg

         (Refer to the “write_ibis” section of (UG835) for details on the description of the various arguments.)

2. No RTL Design:

If you do not have an RTL design and have the pinout planned, follow the steps below. See (UG899) for details on I/O Planning if you are not familiar with it.

  1. Open the Vivado I/O Planning Project
  2. Select the Part
  3. Import the pinout file through a CSV or XDC file. If no pinout is available, select the "No I/O Ports at this time" option.
    This option will give a generic IBIS model with the package data included
  4. Finish creating the project and it will open the package view
  5. Review the I/O Ports tab to make sure that the pinout has been imported correctly. Run DRC if needed. 
  6. Either a) select File  -> Export -> Export IBIS Models

         fig 4.jpg

           (Refer to the “Generating IBIS Model” section of (UG899) for details on the above options.)

       Or b) in the Tcl console run the "write_ibis" command with the below syntax:

           pic 6.jpg

         (Refer to the “write_ibis” section of (UG835) for details on the description of the various arguments.)

3. Zynq MPSoC or Zynq-7000 based designs:

If IBIS Models are required for the PS section of the Zynq device only, you can follow the steps below:

  1. Launch a new RTL Project in Vivado and select the target Zynq device and package.
  2. When the new project is ready, create a block design in the IP Integrator
  3. Click on the “+” button to add IP in the IP selector window, and select “Zynq UltraScale+ MPSoC” or “Zynq7 Processing System” based on the family of device chosen.
  4. The respective Zynq based block will be added in the diagram window.
  5. Double click on the Zynq block to open the Re-customize IP window. Within the Re-customize IP window, select the options to be set in the Page Navigator and set the necessary parameters such as I/O Configuration, Clock configuration, DDR configuration etc.
  6. Click OK, and the IP will be updated. Right click on the Zynq IP block, and select “Make External.” Vivado will automatically add external signals
  7. To avoid receiving a warning about an un-assigned address, click on the “Address Editor” tab and select “Auto Assign Address”
  8. In the Hierarchy window, click on the “Sources” tab. Right click on the design and select “Create HDL Wrapper”
  9. Select “Let Vivado manage wrapper and auto-update,” and click OK.
  10. When the wrapper is complete, select “Open Elaborated Design” in the Flow Navigator. A dialog box will open with details about the Elaborated design. Click Ok and Open the Elaborated design. 
  11. Either a) select File  -> Export -> Export IBIS Models

         fig 4.jpg

           (Refer to the “Generating IBIS Model” section in (UG899) for details on the above options.)

       Or b) in the Tcl console run the "write_ibis" command with the below syntax:

       pic 6.jpg

        (Refer to the “write_ibis” section in (UG835) for details on the description of the various arguments.)

S-Parameter Models:

In the past, S-Parameters (short for Scattering Parameters) were most widely used in the frequency domain. However, with today's high-speed digital signals reaching >1 GHz speeds, S-parameters are used in SI simulations as behavioral models for passive interconnects such as resistors, capacitors, PCB traces, backplanes, connectors, cables and so on.

Most connector and cable vendors provide the S-parameters of their products which can be used to model them in SI simulations, especially when simulating multi-board interface. Most SI tools support combining S-parameter models with IBIS models to simulate the interface end to end.

The list of models needed to run an SI simulation is consolidated in the below figure

fig 7.JPG

 Figure 4:  Consolidated list of Models used for various elements

With that, I will sign off for now and let you digest the information we have covered.

In future entries in this series, we will delve into how to use the SI tools to simulate and debug various Signal Integrity issues.