Validating silicon in embedded designs
Chip vendors and their customers can employ simulation models to ensure designs meet or exceed performance objectives
By Brian Davis, PLX Technology -- Test & Measurement World, 8/1/2007 2:00:00 AM
Many semiconductor manufactures are providing board and system designers with a new generation of simulation models—either Verilog or VHDL—of their devices. Simulating designs with these models provides those designers with the ability to
debug and validate system functionality,
measure system performance, and
identify and work around errors that the semiconductor vendor may not be aware of.
Typically, these simulation models are compiled from the register transfer logic (RTL) Verilog or VHDL code and are cycle-based—that is, they behave just like RTL and do not contain timing delays. Models created properly are exact representations of the silicon device.
Not all chip vendors provide simulation models of their chips, and those who do may not have models for all of their chips. Additionally, some chip vendors may have a model of a particular chip but are willing to provide it only to their key customers.
Even when a Verilog or VHDL simulation model is available, you may have difficulty obtaining it. Searching a silicon vendor’s Web site may not turn up any reference to a model, much less information about ordering one. Diligence can pay off, though; respected vendors will generally provide the needed simulation model when asked.
RTLs and operating systems
EDA vendors such as Cadence, Mentor Graphics, and Synopsys provide software tools that compile a device’s RTL into an encrypted Verilog or VHDL simulation module. By encrypting the RTL code, the ASIC vendor can protect its intellectual property and still provide a way for system designers to simulate a design. When these “black box” encrypted modules (simulation models) are used with a compatible simulator, they behave exactly like the RTL.
Depending upon the tool used to compile the RTL, the model may or may not be platform-operating-system-specific (for example, Linux, Windows NT, or Solaris). In addition, the model may or may not be simulator-specific (for example, VSIM, VCS, or Verilog-XL).
For example, the model compilation tool we use at PLX Technology for our PCI switches and bridges compiles the RTL into an operating system (OS) executable file with an industry-standard SWIFT interface to achieve simulator independence. An installation program is provided with the files to install the model on the designer’s particular OS platform.
Due to the wide variety of simulators, OS C-shell configurations, and models used by designers, interoperability issues can occur. Models compiled with older versions of Linux, for example, may be incompatible with newer commercial versions of the OS. These issues can be overcome by working with the EDA and chip vendors’ technical support groups.
Once a Verilog or VHDL simulation test environment is functioning, you can measure the system’s performance and adjust it if necessary. Besides ensuring that the system performs as required, you may uncover “show stopper” errors and find ways to work around them.
Many ASIC chips have errors—such as not passing a PCI-SIG compliance test—that may impact a system. By obtaining the ASIC vendor’s most recent errata sheet, system designers can work around these problems. Simulations may also reveal some undocumented, yet critical, problems. Undocumented problems are rare when you work with a respected chip vendor, but if you do uncover some and find a way to work around them, you will give your product a competitive advantage.
PCI Express raises the bar
When you view a PCI bus simulation, it is relatively easy to interpret the activity and discern what’s occurring on the bus. The same cannot be said for a PCI Express link, which is serialized, supports lane polarity inversion and lane reversal, and may be composed of a variable amount of serial lanes (x1, x2, x4, x8, x12, x16, x24, or x32). PCI Express bytes are 10-bit-encoded, may be scrambled, and are byte-striped across the available lanes. Additionally, PCI Express transfers use encoded packets.
Because of these factors, waveforms cannot be depended on to communicate the chip’s state when an issue occurs over a PCI Express link. Even with simulation monitors and bus tracking code that logs the link activity, recreating a designer’s model simulation problem becomes an extremely difficult proposition.
The idea of capturing a stimulus at the pin level by monitoring the signals or pins and writing a file on a signal change is anything but new. The level of complexity of creating such a file increases significantly if a pin or bus is bidirectional; that is, the bus can be driven by more than one device or can go to a high-impedance state. Fortunately, from the point of view of writing code to create a PCI Express switch simulation capture module, a PCI Express link pin is always either an input or an output.
At PLX, we created a Verilog stimulus-capture module that can be installed in a Verilog simulation test environment (Figure 1). Since the capture module has the identical signaling I/O as the chip-simulation model, a designer can just copy, paste, and change the model instance name (for example, change pex8532 to pex8532_cap) inside the simulation-test environment. After adding the capture module file name (pex8532_cap.v) to the RTL run list, the designer is ready to capture the PCI Express switch simulation in the form of a stimulus file.
 |
| Figure 1. Engineers at PLX created a Verilog stimulus-capture module that can be installed in a Verilog simulation test environment. |
A captured-stimulus-simulation-test environment contains a single instance of the switch device under test (DUT) and the Verilog code to call and run the captured stimulus (Figure 2). Once the designer has verified the captured-stimulus simulation, he or she provides the simulation-stimulus file to the chip vendor for analysis. The vendor then runs the simulation stimulus using the RTL instead of the model so that the internal logic nodes can be observed and the simulation can be analyzed.
 |
| Figure 2. A captured-stimulus simulation-test environment contains a single instance of the switch device under test (DUT) and Verilog code to call and run the captured stimulus. |
In one case, a manufacturer implemented the capture module and was able to provide the captured stimulus—all in the time it took to run the simulation and transfer the files electronically. The stimulus files were then run with the RTL and the simulation was analyzed. As it turned out, an error was found and fixed in a subsequent revision of the chip.
Capture module and stimulus file
The key to the capture module and the stimulus it generates is the simulation time scale. If a time scale of 1 ps/ps is used in a simulation, then a #1 in Verilog code is 1 ps, a #1000 is 1 ns, and so on. For a time scale of 1 ps/ps, an internal clock (CAP_CLK) can be generated to run with a period of 2 ps. The capture module logic uses the fact that simulators evaluate and update signals based on the same time scale. A portion of the capture module logic uses the CAP_CLK to keep track of the time delay between the detection of signal changes. When a signal change does occur, it is detected on the rising edge of CAP_CLK. This signal change event triggers the capture module logic to write the stimulus file.
The stimulus file that the capture module writes contains an elementary sequence of Verilog signal force statements preceded with #DELAY statements. By using both clock edges of the CAP_CLK, the capture module logic is able to adjust the running time count delay between signal changes to match the actual time the signal changes before writing the #DELAY statement.
Initially, the capture module logic writes the stimulus file with a set of force statements for every input signal. After this initial phase, it will append additional #DELAY and force statements to the stimulus file in response to a signal change. Below is a snapshot of the Verilog code the capture module writes to the stimulus file after the initialization phase:
 |
In addition to capturing the input stimulus, the capture module also writes a file that tracks the outputs. Although not critical to recreating the designer’s problem, the captured-output file can be joined with the captured input stimulus. Then, by tracing the captured outputs alongside the outputs generated when the captured input stimulus is run with the RTL or the model, the designer and chip vendor can ensure the captured stimulus does indeed re-create the issue in question.
Simulator limitations and stimulus file sizes
Because the stimulus file size increases the longer the simulation is run, it is possible for the simulation to create a stimulus file that is too large for the simulator’s memory. The size of the stimulus file that the simulator can run depends on how much RTL is compiled with the stimulus, the number of signal transactions in the stimulus file, the simulator version and configuration, and the OS on which the simulator is running. If the size of the stimulus file reaches the memory limit, you will need to simplify or shorten the simulation.
Chip vendors and designers alike have benefited from using the types of simulation models I have described. They’ve used the models to debug and validate system functionality and ensure designs meet or exceed performance objectives.
Make way for PCI Express
10/01/2003PCI Express Analyzer Handles ASI
03/01/2005PCI Express: Beyond minimum compliance
07/31/2006
-
FLIR offers IR camera for under $3000
-
Don't let the economy compromise quality (Guest commentary)
-
Danaher speeds up restructuring, acquires life-sciences businesses
-
Agilent’s Cover-Extend technology eliminates need for physical test points for in-circuit test
-
So many combinations: Testing a switch-matrix board
View All Webcasts
