Emulation 103--Accelerating Transaction-based Verification

Transaction-Based Verification is a technique for verifying modern SoC designs with interfaces such as PCI express, using test benches at the transaction level of abstraction. Transaction-based verification complements directed and constrained random tests, and is an emerging methodology for verifying complex SoCs that have multiple on-chip standard bus and peripheral interfaces. Typically in a transaction-based verification environment, the test bench is developed in C/C++, System C or System Verilog, and is used to drive data to the RTL design blocks of an IC’s design. The principal advantage of transaction-based tests is that they can be developed much more quickly than directed tests without needing in-depth knowledge of the protocol or the SoC, and can be re-used whenever the target standard is applied.

Most SoC development teams employ a variety of test development methods. Regardless of whether tests are directed, constrained random, or traffic generator oriented, as chip designs grow, the complexity of tests, and their run times grow exponentially.

In the old days (I date myself), even before emulation became available, simulation acceleration systems were used to overcome the long simulation run times. But these systems were targeted at what would be seen today as very small designs.

Early emulation systems did not have the high speed host interfaces or the efficient simulator APIs like SystemVerilog DPIs available today. The early emulation systems were largely used for system integration and test, post-RTL development. Often the use of emulation was limited by the time it took to map designs correctly, and it was in a race to show productivity before the first silicon was delivered. Today’s FPGA prototyping performs pretty much the same function, and often faces the same issue. As a consequence, to accommodate the ever increasing verification problem with large chip designs, the ‘farm” of simulation servers emerged the preferred RTL verification environment in the late 90’s and persists in most design environments today.

Over the last several years, simulation farms have run into limitations due to the overall complexity of the verification challenge and the finite ability to parallelize tests and a farm’s attendant power and cooling requirements. For the past several years, as new emulation technology emerged, the use of emulation systems for accelerating simulations has become its primary differentiation from FPGA-based prototyping systems. The principal value of such acceleration is to shorten the time to tapeout as many more verification cycles can be achieved in a much shorter period of time. Plus, the days and weeks of block and full chip simulation runs are typically reduced to minutes and hours, allowing bugs to be discovered faster and fixes verified in less time. The result is that much of the time savings can be applied to directly shorten schedules, and/or to remove some of the risk of slippage.

With the emergence of (1) transaction-based verification for critical portions of SoC design, (2) standards for communicating between host and DUT in emulation systems enabling interoperability with simulators, and (3) the widespread adoption of SystemVerilog for test benches, it is now possible to synthesize timed portions of transaction-based verification environment into emulators along with DUT to accelerate a large portion of the test bench with the DUT in an accelerated simulation using emulation systems. Critical to this type of operation is the availability of synthesis tools for the most crucial high-level System Verilog constructs. With all the old bottlenecks of co-simulation in the early emulation systems eliminated, in such an environment, accelerated transaction-based verification can be run at nearly full in-circuit emulation speeds.

As a result, what we see in the emulation space is that the traditional driver of getting a high speed platform for early software debug and system integration is now being displaced by the huge advantage of moving many of the simulation runs to an accelerated environment. And, with the increased ease of developing re-usable transaction-based test benches, transaction-based verification acceleration is quickly becoming a mainstream requirement for SoC development teams.

More Blog Posts

Comments (↓ Add Your Own)

3 Comments on this Post

Commented on 2:00 AM, Mar 28, 2010
By Rahul Singhal

Hi Mr. Zak, I wanted to know if any quantitative results, of reduction in regression runtime, have been published by someone for the Multicore processor verification. Thank you, Rahul Singhal

Commented on 2:03 AM, Mar 28, 2010
By Rahul Singhal

PS: I meant regression runtime - comparing simulation vs. emulation

Commented on 8:22 PM, Mar 29, 2010
By Ralph Zak

Hello Rahul, The question is a good one. We have quite a bit of data on the relative runtimes of emulation vs. simulation. Much of the data is on multi-core designs, but I do not know if I have a specific breakout on those types of designs. To the extent that they are larger than most, the relative runtime improvement is better, mostly because simulation gets slower with larger designs. While the emulation system typically runs at 1 MHz, and RTL simulators run up to 100Hz (we do see sub-1 Hz on really big customer designs, I am thinking of one large multi-core design in particular), you don't necessarily see a throughput gain of 10,000x. There are three key factors involved. One is the relative speed of the emulation system vs. that of the simulator, another is the extent of acceleration of the testbench itself in the emulator, and the third is the communication mechanism between the emulator and host machine. I cannot speak for competitive systems, but in our systems we have collected a lot of data from customer projects and competitive benchmarks. What we typically see with vector-based test benches driven by the simulator, is acceleration of 10-50X over simulation. With OVM transaction-based testbenches, where we have the ability to synthesize most behavioral constructs in the SV test bench to be able to accelerate those, and with our optimized host communications we typically see acceleration of 200-1000x over simulation. So a week long test is reduced to typically less than an hour. If the test bench is fully synthesizable, and can be run in the emulator, then seeing full 10,000X differential is possible because everything is at emulation speed. I hope this helps. Ralph

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)