Application-specific-integrated-circuit (ASIC) prototyping brings great promise to an embedded design-verification team: the ability to process billions of verification cycles in less than one hour. More importantly, it has the ability to be fast enough to start testing hardware/software integration way ahead of silicon availability. Yet ASIC prototyping tends to be an afterthought of the verification process. Often, it’s managed by an entirely separate team with different solutions to everything from executing tests to debugging and knowing if a test passes or fails. As a result, ASIC prototyping is more painful than it needs to be. It also limits the reuse between the simulation environment and the emulation setup. This article explores what it takes to make ASIC prototyping ubiquitous. Now that a small emulation card can be hidden inside a PC and design teams can start emulating designs at a speed of several megahertz, they might as well reap the full benefits of faster verification.

The main driver behind the emergence of lightweight emulation is the amazing density produced by field-programmable-gate-array (FPGA) firms year after year, as they follow and sometimes beat Moore’s Law. The race between Xilinx and Altera keeps producing bigger and bigger chips that are capable of mapping larger chunks of an ASIC. Trying to guess which company is ahead at any given time is pointless. After all, it seems to change with each new iteration. And it doesn’t matter because competition is good for ASIC prototyping. Some of those parts are too expensive to ever go into production aside for the most high-end products. But they’re perfectly suited for ASIC prototyping.

Of course, ASIC design size also is increasing. But with the move to systems-on-a-chip (SoCs), each individual block isn’t growing as fast. Rather, more and more blocks are being combined to form the next-generation SoC. This trend should continue because it takes less engineering effort to design a bigger FPGA (just put more lookup tables [LUTs] on the matrix) than it takes to design a functional SoC. This oversimplification may offend FPGA manufacturers, but there’s some truth to this perception.

Leave The Lab
FPGAs are now available to build great ASIC prototypes. Although they constitute the raw material, however, they’re not yet close to delivering on this need. The problem is that it also takes great software to build a ubiquitous prototype. The first thing that has to go is the laboratory environment. As long as ASIC prototyping is performed in the lab––in a separate environment from what designers know––it won’t become a mainstream tool. Over the years, thanks to the Verilog hardware-description-language (HDL) simulator, hardware designers and verification engineers have learned to work together. Now, most design teams don’t see a difference between design and verification because the same engineer can do both.

As of today, prototyping and the lab are still inexorably intertwined. This situation has real cost consequences for any ASIC project, as the issues found in the lab late in the design cycle are difficult to send back to the designers for a quick fix. It can take weeks to understand an issue found in the lab and determine if it’s even a real bug or just an artifact of the prototype setup. The core issue behind this failure in communication is the lack of commonality. The two teams use different tools and methodologies and don’t speak the same language. While there are plenty of good historical reasons why that is so, it doesn’t make it less wrong today.

The perception is that if a design isn’t hooked up to real hardware, the design team isn’t verifying the ASIC. In the networking industry, it seems that nothing can replace a good old SmartBits packet generator. But there’s one problem with that logic: Design teams forget that the prototype isn’t running at speed. Maybe its external interfaces are running at speed, but the core ASIC cannot run at several hundred megahertz over multiple FPGAs. The tests are biased. In addition, artificial tests generated by a well-designed testbench are likely to be invalid.

TLM For All
One reason to stay in the lab is the gap in speed between what FPGAs can do and what a Verilog testbench can generate. The typical goal of an FPGA prototype is to run in the range of 10 MHz or more, which represents 1000X compared to what a Verilog HDL simulator can deliver. Historically, it’s correct to say that it made sense to use a completely different approach.

Things have changed with the advent of transaction-level modeling (TLM). Whether a design manipulates video frames, Ethernet packets, or USB packets, its behavior can be described at a higher level of abstraction than bits and vectors (see Figure 1). The average design-verification engineer hasn’t noticed the potential impact of this transition on prototyping because the simulator is slowed down by the design’s register-transfer-level (RTL) code. The whole point of prototyping is to offload the RTL code to the emulator. Then, all that’s left is the testbench, which benefits from dealing with transactions instead of bits.

With the move to SystemVerilog as the testbench language of choice, the industry has made good progress. As the dust settles in the OVM/VMM debate, the clear winner will be transactors. A good transaction-oriented testbench is essential, as only transactors have the horsepower to generate enough traffic. Moving to a prototype eliminates the bottleneck of simulating the design under test (DUT). Transactors eliminate the second bottleneck of communicating with the DUT. Now, a third bottleneck starts appearing on code profiles because a testbench is only as fast as the random constraint solver generating the transactions. Paying special attention to their optimal use is critical.

Without going into the details of the technology, an engineer can’t understand how much progress has been made in that space if he or she doesn’t understand behavioral SystemVerilog synthesis technologies, such as ZEMI-3 or SCEMI-2. For the first time, an engineer can use the same behavioral checker or monitor for regular simulation and ASIC prototyping.

Push-Button Compiler
For FPGA-based prototypes, the big problem left to solve is compiling and building a model that used to take months. Without the help of specialized software, design teams would have to modify the clock tree to fit what FPGAs can do––that is to say, not much. When a design has thousands of derived clocks, it will be difficult to work with the handful of global clock nets that are provided by an FPGA. As soon as the FPGA prototype contains more than four FPGAs, proper floorplanning that’s optimal for both clock distribution and block partitioning becomes an engineering project in itself.

Design teams can measure the success of an FPGA-prototype project by the time it takes to map a new revision of the RTL code to the FPGA prototype. If it takes more than three days, the prototype won’t add value to the project. If there are any manual steps to compiling the ASIC for the FPGA prototype, the project loses.

The great thing about modern FPGAs is that they enable electronic-design-automation (EDA) companies to design push-button FPGA prototypes that look and feel like traditional emulators. The differences between emulation and prototyping have blurred, benefiting everyone.

How well the software is customized for a particular FPGA architecture is what defines the best product for the end user. For instance, multi-FPGA performance is based on some sort of multiplexing of FPGA pins. The software must know how far to push the frequency on each pin for ultimate performance and what kind of multiplexing will lead to the best results. A generic approach, which is designed to work with a wide range of differing boards, is guaranteed to either create random, untraceable failures or provide disappointing performance.

The Platform For Software Developers
The real drivers behind ubiquitous ASIC prototyping are software developers. They need a platform to write their software. In addition, they don’t want to change their code once the ASIC is out. Software developers don’t care what the platform looks like or how it’s built. But it needs to run their software fast enough. Booting Linux, which is step one to bring up a software environment of value, takes about one billion cycles.

The platform must therefore be fast, transparent, and cheap (see Figure 2). Typically, there are five times more software developers than there are hardware design and verification engineers for the same project. The semiconductor industry tolerates the high six-figure price tags for hardware-design tools because the cost of one single mistake more than justifies the price. Yet the software industry doesn’t have the same problem. It’s annoying to have to fix software bugs in the field or after tapeout. But it isn’t perceived to have the same intrinsic cost as a hardware bug. Price is important for a prototype to be ubiquitous.

A design-verification engineer can now purchase an ASIC prototype that fits onto a small PCIe card, plug it inside a regular PC, and forget that it’s even there. It runs the same TLM testbench that he or she likes and understands—except now it runs at prototype speed. The shocking part is that this isn’t a dream. It’s available today if the design-verification engineer knows to look for it.