A new generation of faster debugging tools based on in-circuit emulation is increasing the number of design turns that can be accomplished in a given amount of time and speeding new products to market. New emulators with custom, field-programmable gate arrays (FPGAs) optimized for emulation can determine the current state of every signal in the entire design being tested.
With the use of custom FPGAs, it is possible to perform design experiments, such as forcing a storage element to 1 or 0 without recompiling. An integrated debug environment makes it possible to move from a high-level block diagram to a schematic, source code, state descriptions, or waveforms to quickly diagnose a problem.
The typical design change, which requires recompiling one or two FPGAs, can be completed in approximately 30 minutes. The net result is that two or three design turns can be accomplished per day, compared to the one turn that can be achieved with traditional emulators. Debugging can be accomplished at either the chip or system level, resulting in significant reductions in time to market and increased product quality.
During the debugging process, an interesting conceptual design with many bugs is made into a finely tuned product that works in every possible situation exactly as intended. The debug process generally consists of running experiments where the variables in the environment are modified in a controlled fashion such as changing a starting address or increasing the clock speed. Each such experiment results in some data being captured, often in the form of waveforms.
This snapshot of the circuit performance provides considerable insight into the operation of the logic. It is just as important to quickly create snapshots as it is to run new experiments. The technology of in-circuit emulation addresses many of these issues by allowing designers to quickly create a hardware model of a chip design using proprietary emulation software that maps the design onto reprogrammable circuitry.
The Problems With Commercial FPGAs
But, until recently, there have been some significant limitations on the debugging capabilities of in-circuit emulators. One reason is that they traditionally have used off-the-shelf commercial FPGAs as building blocks.
With this approach, implementing the debugging capabilities in conventional FPGA-based emulators requires the construction of scan chains built from flip-flops that clock the data out of the chip into the logic analyzer. The number of signals that can be probed is limited, and the emulator needs to be recompiled to change the signals that are probed, which is frequently required during debugging.
Just moving a single probe takes an average of 30 minutes because it requires recompiling the FPGA containing that probe. The most advanced emulators built on conventional FPGAs offer a mode that provides full internal visibility, probing every signal in the circuit. But that consumes a considerable amount of the logic capacity, typically 30%.
Also, the overhead created by providing 100% internal visibility reduces the speed at which signals can be sampled to around 500 kHz. This rules out its use in many applications.
The time involved in compiling a design for in-circuit emulators based on commercial FPGAs may be too long to meet fast-track design schedules. Traditional emulation requires register transfer level (RTL) to gate-level mapping using a silicon synthesis tool that converts the RTL to a net list of gates and flip-flops prior to each design turn. By itself, this process could easily take a day.
Next is emulation mapping, which breaks up the gate-level design into hundreds of FPGA-sized chunks.
The final step is compiling each segment of the design onto an individual FPGA. As an example, in a typical 1.1-million gate networking design, the overall compile time using five workstations and commercial synthesis tools takes 32 hours with this approach.
Advantages of Custom FPGAs
A generation of in-circuit emulators based on custom FPGAs optimized for emulation enables new architectures that can streamline the debugging process. The architecture of the FPGA can be designed around the needs of emulation rather than optimized for building a system-on-a-chip.
For example, the use of custom FPGAs also makes it possible to build an efficient hardware-based logic analyzer into the chip, a feature that consumed precious resources of off-the-shelf FPGAs. It consists of a matrix of switches that can record any signals in the circuit being emulated, including I/O.
Up to 64 signals can be multiplexed to each logic-analyzer pin on the chip, although the time sequencing required to accomplish this level of multiplexing takes a toll on logic-analyzer speed. You can manage this trade-off by selecting any number of signals, up to 64, to multiplex through each pin.
The event detectors that are used to trigger the logic analyzer also are built into the silicon, avoiding the need to route the signals outside the chip. At any point in time, emulators built with custom FPGAs can determine the current state of every signal in the entire design being tested. With the logic analyzer built into the FPGA, designers can move probes instantly, avoiding lengthy delays for compiling probes.
The use of custom FPGAs also makes it possible to build in the capability to support design experiments, that is, to set, force, and release any storage element such as a flip-flop or register without recompiling. For example, at run time, the flip-flop or register can be initialized to 1 or 0, locked at 1 or 0, or released to its natural state. While these capabilities can be implemented in emulators built with off-the-shelf FPGAs, it is necessary to recompile the FPGA that contains the storage element, which takes about 30 minutes.
The ability to perform these functions without this delay can significantly increase the speed of the debugging process. During debugging, designers frequently have a hunch of what is causing a problem and need a way to confirm it.
The best way usually is to force signal values to change in the same way the proposed fix would. This is much faster than actually changing the design to model a proposed solution to the problem. The fact that custom FPGA-based in-circuit emulators can perform this task in a few minutes rather than a half hour significantly increases the speed of the debugging process.
Custom FPGAs optimized for emulation are designed with a regular, consistent, crossbar-connected architecture. The net result is that compilation time can be reduced by an order of magnitude or more, substantially reducing the time required for each debug cycle.
In the example, the time required to compile a 1.1-million gate networking design is reduced to 1.1 h on three workstations, with the result that a farm of workstations or PCs is no longer required, nor are day-long delays for recompiles. As a general rule, million-gate designs can be compiled in less than an hour. Engineers compiling large designs on only one or two workstations usually can compile designs from five to 20 times faster than with emulators based on generic FPGAs.
When you perform emulation, you have to slow down the real world to the speed of the emulator. This normally is not a problem, but there is a limit beyond which anomalies begin to occur that make it impossible to accurately emulate a device.
The use of custom FPGAs makes it possible to increase the speed of the logic analyzer to 2 MHz while still supplying 100% visibility. This level of speed provides an accurate picture of virtually any device, eliminating a limitation of generic FPGAs and making it practical to provide 100% internal visibility on every emulation.
The inclusion of a complete logic analyzer with instant probe changes, event detectors, and pin multiplexing means that designers can move probes instantly, avoiding lengthy delays for recompiling probes. The usual limitations of providing 100% internal visibility in terms of sampling frequency, depth, and capacity are eliminated.
Off-line debugging allows teams to share an emulator more efficiently than before, increasing usage for large teams by a factor of three to 10. Taken together, these improvements make it possible to find and fix two to three bugs per day compared to one bug per day in traditional emulation systems (Figure 1).
Integrated Debugging Environment
An important aid to debugging productivity provided by the latest generation of emulators is an integrated debugging environment that incorporates all of the elements needed to understand and diagnose any design. It includes a waveform display that permits designers to see the signals of any node in the emulated design.
A schematic diagram lets engineers backtrack through the area of the design where the signal isn’t correct. A source-code window makes it possible to examine the code running on the device to obtain another view of the problem.
The typical debugging process proceeds much like it would using traditional manual methods. You trace a signal anomaly through the schematic, inspect the source code, and add new signals to the waveform display.
Signal tracking is simplified because the signal values automatically are annotated onto the schematic and source code. This process can be accomplished in a few seconds instead of the hours that previously would have been required to perform each of these steps with a separate instrument or software package and recompile the design to probe the new node.
In an example of the use of these methods, a Japanese company is building an MPEG 4 encoder/decoder chip with 700,000 ASIC gates. The design is a Verilog model. The behavioral Verilog test bench, which includes several memory models coded in behavioral code, runs at 10 Hz using native-compiled software simulation.
At the end, the designers want to view a video clip of the graphics produced by the chip—about 35 frames. Using software simulation, it only was possible to produce one video frame every seven days. Emulation ran at 13 kHz, 1,000 times faster, making it possible to generate 35 frames in a few hours.
When the designers viewed the frames, they could see sparkles, indicating that a number of pixels were not correct. The size of the sparkles was small enough that they could only be detected by the eye when they transitioned on and off out of sequence with the rest of the frame. The sparkles could not have been detected in simulation because it is too hard for the eye to see a single bad pixel. Once the sparkles were detected, the designers attached probes to the output stream.
The cone of logic that drives the D/A logic was traced back using the schematic viewer. Once likely signals were identified, they instantly were probed without recompiling, and the test was quickly rerun.
When bad data was found on internal signals, the process was repeated until the source of the problem was found. A timing problem was discovered where the address lines were glitching during the write cycle.
The cause of the glitching could be observed because the emulator’s logic-analyzer sampling rate was increased to 8 MHz without recompiling. The RTL code was modified to remove the glitch, the design was recompiled in a few hours, and the frames were rerun showing that the sparkles had been removed.
With traditional emulation, instant probing was not available, and if its full visibility feature were used, the logic analyzer would not have been running fast enough to show the glitches. With traditional emulation, the recompiles would have taken overnight instead of a few hours. This application is typical of the results that custom FPGA-based emulation can provide: first pass success while reducing debugging time.
About the Author
Ray Turner is the product line manager for Quickturn’s Mercury and CoBALT in-circuit emulation systems. Before joining Quickturn, he was the EDA marketing manager for PCAD products for seven years. Overall, Mr. Turner has 15 years experience in product management for EDA products and an additional 14 years experience in hardware, software, and IC design in the telecommunications, aerospace, ATE, and microprocessor industries. He received a B.S.E.E. from Loyola University of Los Angeles. Quickturn/A Cadence Company, 2670 Seely Ave., San Jose, CA 95134, 408-914-6000, e-mail: [email protected]
For More Information
Mercury Technical Data
www.rsleads.com/210ee-267
Quickturn Engines Information
www.rsleads.com/210ee-268
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2002 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
October 2002