Articles

RSS

System level verification allows simultaneous validation of PCBs, pre-silicon designs, and software, reducing time-to-market and increasing product quality. The traditional approach is to wait until integrated circuit prototypes, normally a two to three month process, before beginning system level verification of the PCB and software. A new approach involves mapping the silicon design onto reprogrammable circuitry, then plugging it into the PCB, then applying real world stimulus in order to debug the pre-silicon design, PCB and software simultaneously. Besides making it possible to begin system-level verification much earlier, debugging can typically proceed much faster than with real silicon because in-circuit emulation provides an integrated logic debug environment. The recent introduction of behavioral emulators that incorporate embedded RISC processors and can execute behavioral code, such as IP-blocks, memory models, testbenches, instruction set simulators, etc., has allowed dramatic gains in the run-time speeds of the verification environment.

Contents
•Problems with existing system-level verification methods
•Quickly creating a hardware model
•Types of emulation systems
•Behavioral emulation systems
•System level verification of Gigabit Ethernet switch
•Another system level verification example

The challenges of system-level designs include increased design complexity, verifying integrated circuits with larger numbers of gates, more complex software, and the need for the entire system to work together. For example, deep submicron process technology means more gates on the chip. Systems-on-a-chip use intellectual property from multiple sources, along with memory and software. Shrinking time-to-market, customer expectations of high product quality, and the cost pressures of today's highly competitive market increase this challenge. Product cycles have never been shorter and market window opportunities are continuously shrinking. The need to "get it right the first time" places ever-increasing burdens on the design verification process. When a new design goes to the fab, designers must be certain that all of the bugs have been discovered and fixed and that the chip will deliver the desired functionality, performance and profit margin in the final integrated system.

Problems with existing system-level verification methods
These trends place greater and greater performance demands on traditional system-level verification methods. One approach uses software simulation for functional logic verification at the module and chip level. System-on-a-chip methodologies, with microprocessors and other designs in excess of a million gates, push the time required for an event-driven simulation out to weeks or even months, even for non-exhaustive testing. Simulation also fails to model the interactions between the chip and other system components and software.

Cycle-based simulation is the next logical step for verification of complex designs. While this approach increases verification speed, cycle-based algorithms impose restrictions that rule out their use for many of today's more advanced designs.

Regardless of the method used to verify the pre-silicon design, the critical last stage of the design cycle is verification of the final gate-level design at the system level. The chip design must be connected to PCBs and exposed to real world stimuli. Until recently, real silicon was nearly always used for system-level verification. This approach provides real time performance, but real silicon is costly to manufacture, often requiring several spins for verification purposes, and takes many weeks to deliver. Real silicon does not provide access to internal nodes, making it difficult to debug the problem.

Back to top

Quickly creating a hardware model
In-circuit emulation addresses many of these issues by allowing designers to create a hardware model of a chip design using proprietary emulation software that maps the design onto reprogrammable circuitry. This approach offers significant speed improvements over traditional software simulation. Emulation speeds are typically on the order of ten thousand to a million times faster than event-driven simulation, verifying the functionality of designs with up to 20 million gates overnight. Just as important, emulation produces a time-correct, functional equivalent of the actual silicon that can be plugged into the PCB being designed and run real software. This approach delivers two to three orders of magnitude faster performance than does hardware-software co-verification running on a workstation using behavioral simulation or instruction-set simulators. In-circuit emulation allows designers to spot bugs and correct them immediately, view the chip design running in its target environment, and start integrating the system before the IC is even built. With the increasing software content in electronic products, starting software verification sooner in the development cycle means getting products to market sooner with higher quality.

Back to top

Types of emulation systems
There are two basic emulation architectures. The first, a processor-based emulation system, uses a compiled code approach: the design is converted and executed on a massive array of concurrent Boolean processors. Relative to FPGA-based emulators, processor-based emulators typically have a very fast model build or compile – on the order of a few minutes to a few hours. They are ideally suited for use in the early stages of a verification when the design changes frequently, even daily. Since processor-based emulators are typically based on a highly parallel, cycle simulation algorithm paradigm, they inherit the disadvantages of cycle-based simulation such as the elimination of logic feedback loops in the user design source and problems with asynchronous domain interaction. Processor-based emulators (and cycle-based simulators) are ideally suited for synchronous, single-clock designs.

FPGA-based in-circuit emulation systems replicate the operation of a complex integrated circuit by partitioning the circuit into blocks and compiling the blocks onto hundreds of field programmable gate arrays (FPGAs) that are linked together to emulate its operation. These emulators usually have a relatively long model build or compile time because they have to partition the design into individual FPGA's in addition to running place and route software for each FPGA in the emulation system. On the other hand, FPGA-based systems typically provide in-circuit speeds on the order of 5X higher than a processor-based system. FPGA-based emulators offer a true interconnection of gates. They can provide relative event-timing accuracy by determining the response of the circuit in between clock cycles, making them well suited for asynchronous designs.

An even newer generation of emulators incorporates custom FPGAs optimized for emulation. These systems are having a dramatic impact on the verification of integrated circuit (IC) designs due to their increased verification speed, accuracy and ease of debugging. Custom FPGAs enable new highly scalable architectures for increased capacity, incorporate special debugging logic, and provide for higher emulation and compilation speed than do off-the-shelf FPGA-based emulators. The regular, hierarchical structure that can be created in a custom FPGA lets designers compile their designs on a single workstation, with performance which is 5 to 20 times faster than emulators using traditional or commercial FPGAs. These new emulators also run faster.

One additional advantage of in-circuit emulators is their built-in debugging capabilities. This latest generation of emulators include a hardware-based logic analyzer. It consists of a matrix of switches, which make it possible to record any signals in the circuit being emulated, including I/Os. In one recent implementation of this technology, up to 64 signals were 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, the designer can manage this trade-off by selecting any number of signals (up to 64) to multiplex through each pin. The event detectors used to trigger the logic analyzer are built into the silicon, avoiding the need to route the signals outside the chip. With the built-in logic analyzer, designers can move probes instantly, avoiding lengthy delays for re-compiling the probes. The switch matrix can reassign signals to pins at run time, eliminating what is usually the most time-consuming step of the debugging process. These improvements can more than double debugging productivity, making it possible to find and fix 2 or 3 bugs per day compared to 1 per day with conventional systems.

Back to top

Behavioral emulation methods
An important recent innovation for in-circuit emulation is the development of behavioral emulation methods that connect emulation and simulation acceleration engines on a high speed bus, eliminating the delays inherent in a networked solution. This exceptional performance is achieved by creating an event-accurate, IEEE 1364-compliant (Verilog) simulation model of the design in reconfigurable logic (FPGAs). The behavioral emulator automatically partitions mixed level designs between the simulation and the emulation engines. Performance gains of 100X to 10,000X have been realized. At the one million gate level, for example, where typical gate level simulators perform under 10 Hz and behavioral simulators at less than 100 Hz, the new behavioral emulators deliver better than 10 KHz verification performance. On even more challenging 10 million gate designs, gate level simulators bog down to under 0.1 Hz and behavioral simulators operate at under 10 Hz, while behavioral emulators can still deliver 10 KHz, an increase of 10,000 times in performance.

Prior to behavioral emulation, the state of the art for running a behavioral-level testbench with an RTL-level design was to compile the design to run in the emulator. The testbench ran on a workstation interfaced to the emulator through a networking connection. This approach works well, but is not fast enough because of the bottleneck introduced by the networking protocol between the workstation and the emulation system. These new behavioral emulators make it possible to run the entire verification process on the dual-engine emulator with the testbench running on embedded processors. This approach is much faster and delivers lower levels of latency since the communications between the testbench and emulator take place on a high-speed bus. Support for PLI routines makes it easy to fit emulation usage into existing verification methodologies.

Unlike simulation, behavioral emulation can run in-circuit, which provides a higher level of verification and typically runs much faster. For example, consider a mixed level system-on-a-chip, where most of the design is available in the form of a gate level description. On the other hand, two of the required models, a CAM (Content-Addressable Memory) and a PCI bus model are not synthesizable. By using a behavioral emulator, the entire design can be mapped onto one single integrated system, with the gate level description on FPGAs and the behavioral code on the processors. The emulator itself can then be plugged into the PCB socket. The test stimulus comes from the PCB and its external connections, providing four or five orders of magnitude speed improvement over event-level simulation.

Back to top

System level verification of Gigabit Ethernet switch
A major supplier of networking equipment used these methods to verify a Gigabit Ethernet switch with ‘quality of service' features. The chip design features four million ASIC gates and the verification plan called for modeling and simulating real networking traffic to accurately stress test the chip. This company considered using simulation, but the estimated performance would have been too slow to simulate enough random events and timeouts for a realistic stress test. Event simulation could not provide the accuracy required because it could not model real external traffic. Moreover, the budget for their project would not allow for the purchase of an emulation system.

The solution was a remote-access, time-based verification environment. The host PC, running the target operating system, was linked to an in-circuit emulation system, which in turn was linked to a network traffic generator. The company was able to use real Peripheral Component Interconnect (PCI) traffic for software and test platform development, hardware/software co-verification, and software debugging on the hardware without purchasing the emulation hardware.

The design team used these time-based verification services to emulate an ASIC switch at a rate 780 times faster than the performance of an event simulator. Emulation, performed at 500-packets per second throughput, required just one and a half hours from RTL to emulation for four million ASIC gates. The team applied real network traffic to the emulated design using realistic data packets to simulate random events, along with stimulus response and analysis and full debugging.

The remote verification process was successful, finding six "silicon killer bugs." Two were discovered using real traffic and four more would not have been found if they had used simulation alone. The team developed the chip in 12 months with hardware and software integration accomplished four months prior to tapeout. The overall design project was a success as well, achieving first-pass silicon, software and a product that was first to market.

Back to top

Another system level verification example
Another system level verification example involved the emulation of an entire system, consisting of seven ASICs with a total of 2.4 million ASIC gates on five different PCBs. Each of the ASICs has over 500,000 gates. The ASICs were mapped onto FPGAs in an in-circuit emulation system that was then plugged into the PCBs and exposed to real world stimulus. 47 bugs were found in the ASICs and PCBs, of which 4 would have caused complete system failure, 28 would have required a respin and 15 were minor. The design team said that 23% of the bugs would have had a low probability of being found with simulation. At least one respin was saved on all three large ASICs, while one of the ASICs would have likely required three or four respins due to multi-layered bugs. Plugging their IC design into the system and running real software dramatically expedited software development. Two person-years went into developing 80,000 lines of firmware before first silicon was produced. The firmware was fully operational one day after first silicon, saving months of effort that would have been required for software debugging.

As chips grow in size and complexity, design teams need high performance tools to verify new design logic in the context of the overall system. Emulation provides a physical model of the silicon in development and a comprehensive, integrated logic debug environment to identify design flaws. Most important of all, emulation lets users plug the emulated silicon into a real PCB and debug the hardware and software in a system environment with real external stimulus early in the design cycle. True system level verification can dramatically reduce time-to-market and increase quality by making it possible to verify PCB, silicon and software long before first silicon is received.

Back to top

About the author
Ray Turner is the Product Line Manager for Quickturn's in-circuit emulation systems, Mercury and CoBALT . Before joining Quickturn, he was the EDA Marketing Manager for PCAD products for seven years. Overall, Ray has 15 years experience in product management for EDA products. Ray also has 14 years experience in hardware, software, and IC design in the telecommunications, aerospace, ATE, and microprocessor industries. Ray received his BSEE from Loyola University of Los Angeles. He holds patents for early work in digital signal processing and has authored two books on engineering.

For more information, contact Quickturn, A Cadence Company, 55 West Trimble Rd., San Jose, CA 95131-1013. Ph: 408-914-6000, Fax: 408-914-6001.