Our ICs provide the core technology for digital set-top boxes, digital TVs, and DTV-PCs. Our flagship product, the TL850, includes an all-format decoder, video scalers, a transport demultiplexor, and a graphics engine for digital TV products on a single piece of silicon. The resulting one-million-plus-gate design presented a significant verification challenge.

We dedicate the majority of our testing to verifying the correct functionality of the decoder algorithms, particularly those covering the demanding MPEG-2 protocol. The goal of this testing ensures that the decoder presents all of the information in each frame without truncating or dropping information. Some examples of format decoding algorithm errors can result in a variety of unpleasant outcomes: the display of a partial image, dropped or repeated frames, jerky motion, or misaligned blocks.

To verify compliance with all 18 Advanced Television Systems Committee (ATSC) formats, we had to simulate gigabytes of data. To illustrate the magnitude of this amount of data, consider simulating the required data 18 ten-second video clips of each of the ATSC formats, totaling 32.7 Gbits just once, let alone the iterations often required. Assuming one verification run at 10 to 50 Hz the performance of traditional simulation tools the results wouldn't be available for an entire month, plus or minus a week. For this project, at least, a several-week debug cycle simply proved unacceptable. We needed a new verification environment that would provide at least two orders of magnitude improvement over our software solution.

Verifying the verification environment

In working to develop our new verification environment, we set several critical benchmarks. We wanted to achieve a 100X throughput improvement over HDL simulation using C test bench cosimulation, which in turn would shorten each design iteration from weeks to days by reducing regression time. We also wanted to run larger real-world tests to verify conformance and presilicon software and to ensure high quality. We also needed the ease of working within common, uniform C test benches as a single front end. Finally, we wanted to test the final gate-level netlist and reduce the workload on our workstations.

After careful research and analysis of the verification market, we evaluated a variety of options to solve our verification challenge: our current method of event- driven simulation (EDS); the distribution of the test bench onto a farm of workstations running EDS; hardware acceleration; cycle-based simulation (CBS); traditional emulation; and C test bench cosimulation (a varied form of emulation).

We evaluated each option against the current EDS approach, using criteria that included cost, performance, engineering effort, C test bench support, seamless environment, and degree of confidence.

Performance consistently served as the driving criterion.

We eliminated the workstation-farm approach because it didn't guarantee our performance needs and would have required us to purchase many workstations and simulation licenses. In addition, the tests must be split a difficult and frequently impossible task. In many multimedia applications the test suites depend upon a certain starting point and so resist partitioning and distribution.

Hardware acceleration could have provided a speed-up of 10X over our current EDS approach and could have supported the C test benches. We dismissed this approach, however, because it offered limited performance gains with a special hardware investment that can serve only to accelerate simulation.

The cycle-based simulation approach showed promise because it could provide a speed increase of 5ý10X, could support the C test benches, and offered the cheapest solution to implement. Nonetheless, a 5ý10X increase in performance didn't warrant the change in design methodology.

Traditional emulation offered the most exciting performance gains, with results of 1,000 to 100,000X. However, this kind of performance demanded a test stimulus supplied by a synthesizable test bench or by the design's target hardware environment. While we saw the in-circuit approach as a tantalizing option, we lacked the time to build the in-circuit environment.

C the bench

Having exhausted the traditional, advanced verification approaches, we turned to a new verification capability from Quickturn, referred to as Cobalt (Concurrent Broadcast Array Logic Technology) test bench cosimulation. Cobalt's modular emulation architecture, compiled code features, and fast interface to the workstation made it well suited for cosimulation. The dedicated, low-level connection DAS (Direct Attached Stimulus) interface offers speeds orders of magnitude faster than the usual bottleneck interface between workstation and hardware.

The verification engine achieved a 100X performance gain and provided stimuli to our accelerated design from C test benches running on a workstation. All regular C constructs including access to all of the workstation's peripherals and its large address space were avail- able. We built a bridge between the test bench running on a workstation and the design in the emulator/accelerator. The C test benches, Verilog, and Cobalt run together seamlessly, and appear to the design engineer like a single verification environment.

Figure 1 - Test Software Structure

The modularity of the test benches allows the verification team to shift smoothly between emulation and simulation.

We selected a configuration consisting of the Cobalt CE1000 model with a nominal capacity of 1-million gates and 24 Mbytes of memory. We obtained an IBM RS6000 dual-processor 333-MHz workstation, which provided dedicated processing to compile the design and execute the C test benches.

We engaged Quickturn's time-to-market engineering group (TTME) to design and develop the cosimulation platform using our existing and new C test benches and the Cobalt emulator. The previous verification environment connected our C test benches to the Verilog simulator through the Verilog-PLI interface. We wanted to maintain this interface and to add similar monitor, waveform, and VCD file capabilities to the new verification environment.

For the most part, both the Verilog-PLI and Cobalt environments used the identical C code (see Figure 1). To support what differences did exist between the two environments, the TTME group wrote a small amount of accelerator/simulator-specific code and placed it into separate files. When compiling the test bench, we selected the verification engine Verilog or Cobalt and compiled the appropriate files into the test bench. The original user interface remains constant for either the simulator or accelerator and the engine-specific files are transparent during run time.

Our system-on-a-chip (SOC) design interfaces to a number of system components such as memory, video, and other processors, each with an independent and asynchronous clock. The interface developed by the TTME group includes a small simulation kernel that generates each of the clocks. Using these clocks, it then schedules the execution of each test bench and performs the transfer of input and output data between the test bench and the emulated design. This removes any signal scheduling constraints on the C test bench. In essence, the kernel duplicates the scheduling function of the Verilog simulator.

Installation bring-up and customization were accomplished with help from the TTME group. Within 3 months, we had the system up-and-running, integrated with- in our verification environment, and converted to an entirely C-based test bench with higher performance and easier maintainability.

Go with the flow

The basic use flow for compiling and running the C test bench cosimulation consists of synthesis, compilations, and testing (see Figure 2).

Figure 2 - Flowing through verification

The automated cosimulation flow receives RTL code at one end and passes test results out the other, identify errors along the way.

We intended the cosimulation environment for use during regression testing and the testing of massive amounts of data. We used the emulator extensively and interchangeably with Verilog, and also discovered that it provided effective debugging for our design post-silicon. The following specific examples show how we used the cosimulation.

Our regression test suite included many over a thousand short test cases. While it would have been reasonable to run an individual test case using Verilog, we needed the speed of the emulator to run all of the tests. Out of a thousand short tests, we might find a bug in a few. In these cases we would duplicate the test in Verilog and debug within the purely software environment. The uniform front end made switching back and forth between the Verilog and Cobalt environments an easy process.

Our components for the digital TV market must conform to many standards, such as ATSC and MPEG. Often, the algorithms for these standards contain many data-dependency functions that are invoked only after frames of data have been exercised. We found that pseudo- random testing wasn't good enough. We needed the ability to run massive amounts of data in days not weeks or months. On the TL850 we discovered a critical bug in one of our algorithms that occurred after seconds of video. A Verilog-only solution wouldn't have allowed us to attempt this test.

We were able to trace system software bugs found after silicon, and reproduce and debug errors in the high-speed environment. Post-silicon hardware bugs typically took seconds or even minutes to manifest themselves. Reproducing these bugs in simulation could be accomplished only with a high-speed environment, suggesting (if not demanding) emulation.

Moving on up

When we finally reached the module integration phase, we began to use the Cobalt cosimulation environment. While we see value in using the environment earlier in the design cycle when writing HDL especially on next generation designs that reuse major components of the chip a few road blocks remain. First, since it takes time to develop the environment, the cosimulation environment isn't available until later in the design cycle. Second, Cobalt still offers only a primitive debugging interface. And third, the HDL-ICE product didn't meet our needs and we had to rely on using our chip synthesis tool to compile to gates, a slow process limited by bandwidth.

In the end, we were very pleased with our partnership and the verification environment we created together. The TL850 project completed on time with working silicon. Cobalt reduced our regression time by one to three months and allowed for more accurate software development prior to silicon. We caught some bugs by running large simulations before silicon and used the environment post-silicon for the verification of system problems. With the Cobalt cosimulation environment we reached our benchmark simulation runtime goal of about 5 KHz.

When we began to design the TL850 IC, we faced tremendous challenges. The chip represents our largest design to date with the most comprehensive test suite. After careful analysis of our options we chose a turnkey solution that met our performance goals. The resulting system fully integrated with our new and existing C test benches and the Verilog simulation environment and proved capable of high-performance cosimulation. The seamless environment enabled our engineers to continue working in the familiar test environment with only minimal changes. We achieved a substantial return on our investment when we saved at least a month in initial verification and found bugs that would have meant costly and time-consuming respins of the chip.