I recently got an invitation to attend a session of the DV Club (yes, you guessed right, DV stands for Design Verification) in Milpitas. The 2 guest speakers for that event are supposed to talk about “leveraging low-cost FPGAs prototyping”, right on topic and of course I accepted the invitation.

Being German, I also did my homework and first checked out the DV Club website … so far so good:

• The tagline reads “Sharing knowledge among the verification community”
• A nice, organized website
• A blog
• And you can sign up for a newsletter

I promptly got a confirmation with further details about the upcoming event … so far so good!

You can imagine that I was very surprised then to receive an email, 2 days before the event that I have been uninvited:
“Hello Juergen,
My sponsors read over my RSVP list for the DV Club luncheon this week and have unfortunately asked me to remove you from the guest list.  I apologize for this – Cadence is our main sponsor and has the right of refusal to competitors. Once again my apologies – if you were a consultant rather than work for Synopsys I could invite you…”

So here is an organization who finally is trying to address one of the biggest challenges, and cost factors, in today’s ASIC and SoC design, a wonderful idea and what users as well as EDA tool providers need and should support. But then, when the rubber hits the road, turns out to be nothing more than another marketing venue for its so-called sponsors. VERY DISAPPOINTING INDEED!

Today’s verification challenges are so big and so diverse that a multitude of tools and solutions are needed to truly help the design and verification engineers. And these tools will most likely come from multiple vendors. Besides, competition is good, it encourages everybody to improve, advance and innovate, to the benefit of the user.

It is sad to see that a great idea, like the DV Club, is limiting itself to becoming their corporate sponsor’s spokesperson.

When it comes to hardware-assisted verification there are many terms floating around and used interchangeably. Here are the most common terms and my attempt to clarify them.

Rapid Prototyping
The use of one or multiple FPGAs to implement a pre-silicon, functional representation of an ASIC/ASSP/SoC design

(big box) Emulation
The use of a dedicated, usually custom chip based, hardware system to “emulate” an ASIC/ASSP/SoC design

Co-Simulation, aka Simulation-Acceleration
Connecting a cycle-accurate (RTL) test bench (TB) running on a simulator like VCS, to the design under test (DUT) running on a rapid prototype or emulator. The test bench is the master and is advancing the clock, thus data is send over the link between TB and DUT at every clock cycle.
Amdahl’s law applies, therefore the ratio between TB activity and DUT activity will determine the achievable acceleration. Typical acceleration factors are between 1x and 10x.

Transaction-based Verification, aka Co-Modeling, aka Co-Emulation
Connecting a high-level test bench or model running on a workstation, to the design under test (DUT) running on a rapid prototype or emulator. An Accellera standard has been created to define interfaces, protocols and infrastructure. This standard is referred to as SCE-MI (Standard Co-Emulation Modeling Interface). Both sides advance the clock independently and the communication happens through “transactions”. This requires transactor pairs, usually a C-API on the workstation and a corresponding synthesizable transactor on the rapid prototype or the emulator.
The achievable acceleration is determined by multiple factors, for one the ratio between a transaction and the # of clock cycles it creates on the hardware side, secondly on the latency of the physical link between the workstation and the hardware, and third the raw hardware performance. Typical performance ranges from 100kHz to 500kHz for emulators and up to 5MHz for rapid prototypes.

In Circuit Emulation (ICE)
Connecting the design under test (DUT) running on a rapid prototype or emulator to actual hardware interfaces to stimulate the DUT and/or to drive the system with the DUT outputs. The clocks on the rapid prototype or emulator are free running. Emulators usually require “speed bridges” to connect to the faster external interfaces, while rapid prototypes usually can run the interfaces directly and in real-time.
This is the highest performance use mode for a hardware-assisted verification system. The typical performance is ~1MHz for emulators and 10MHz … 50MHz for rapid prototyping systems.

“FahrvergnĂĽgen” describes the thrill, excitement and fun of driving a performance car, preferably at high-speed. But what does that have to do with chip verification and more specifically with hardware-assisted verification? Well, like driving a car, verification is a journey and how much fun, excitement and success you have along the way depends a lot on what vehicle you are using. And how fast you get to your destination also depends a lot on the vehicle you are using.

Hardware-assisted verification has been around for over 2 decades now, starting with gate-level simulation-acceleration, over hardware-emulation to, more recently, FPGA-based rapid prototyping. All of these hardware-assisted verification methodologies offer superior performance over most traditional, software-based methodologies, but there are also challenges involved. They range from implementing a chip design into the verification platform, over ease-of-use and debug capabilities, to mechanical footprint, power consumption and cooling.

Let me be very clear though, hardware-assisted verification is NOT replacing simulation. Just the opposite, it is very complementary to other verification tools and solutions, thereby enhancing the overall verification flow and improving productivity and results.

With this blog I hope to stimulate discussion, the exchange of ideas and dialog around all aspects of hardware-assisted verification. And let’s not forget to have some “FahrvergnĂĽgen” along the way!