SoC design teams are tasked with completing full system-level verification before the creation of expensive production masks. To accomplish this task requires the teams to thoroughly vet all hardware blocks, all interactions between those blocks, and the purpose-built software created for the end application before the chip is even built. While hardware emulators and desktop FPGA prototype boards are two well-known participants in this verification, enterprise FPGA prototype platforms are now taking their place alongside them as the third participant.

While simulation dominates in the early stages of a design, its use is limited to circuit blocks due to inadequate performance. Once full-chip verification begins, greater speed is needed both to handle the enormous number of tests required to achieve full hardware coverage and to integrate the software with hardware. Emulation has taken on the bulk of this burden. In parallel, when RTL code reaches stability, validation of software application may begin. In virtue of their superior speed of execution, desktop prototyping boards excel in this realm.

Within the last ten years, a new tool fills the gap between the powerful analysis/debug capabilities of the emulator and the raw performance of the prototyping board. Called “enterprise FPGA prototyping,” it blends emulation characteristics and desktop prototyping to address new use cases that offload emulators. This allows a verification team to bulk up their high-speed hardware-based verification resources while optimizing the total cost of ownership. Together, emulation, enterprise prototyping, and desktop prototyping can bring an SoC to market more quickly and with greater confidence in the correctness of the silicon.

Related:What is the Difference Between Test and Verification?

Emulation Tasks – New and Old

Emulators have become the workhorses of SoC hardware verification. Able to execute orders of magnitude faster than simulation, they have been key to vetting the incredible amount of hardware placed on a single chip.

Emulator design reflects a balance between performance, the infrastructure required to implement the wide range of possible designs, and, most important, the extensive instrumentation that allows thorough debug if something is amiss. As a result, even if they don’t run as fast as a final application, they run fast enough to boot operating systems while exploring low-level software like drivers and bare-metal programs.

In-circuit emulation, or ICE, is another emulator task that used to be more prevalent. By connecting the emulator to physical networks or other hardware to deliver realistic data traffic, it is possible to thoroughly exercise the design under test (DUT) with real-world workloads and unearth deeply seated bugs. However, because ICE connections required rate adapters to slow down the real-world data rates to match the emulator speed, verification teams have moved to virtualized traffic generators instead of ICE.

Related:Create Once and Test Everywhere: The Promise of Portable Stimulus

Virtual traffic generators can be connected over the network without requiring speed rate adapters to match the speed of the emulator, facilitating the unmanned deployment of emulators in data centers, accessible from anywhere in the world 24/7. Virtualized traffic generators can create realistic workloads for a wide range of applications. See figure 1.

The Role of Desktop Prototype Boards

While emulators can test out low-level software, they’re not always the best tool for verifying higher-level application software. Such software must first be debugged at the software level, where fast speed of execution is paramount and hardware debug is unnecessary. Running it on an emulator is overkill and inefficient. Not to mention that there are more software developers than could be served by the number of emulators available.

Desktop prototype boards have been the answer to this need. They are configured once the hardware design has stabilized, with few silicon design changes coming during the remaining verification cycle. The re-configurable FPGA network allows performance to be optimized as the DUT is implemented. They can run as much as an order of magnitude faster than the emulator.

These boards are distributed to software developers who plug them into their desktop servers. When it comes time to run software tests, they can get results based on the actual hardware design much more quickly.

Because of their speed, it has been easier to connect these boards directly to real-world data sources without resorting to speed rate adapters, favoring the move of ICE off of emulators and onto desktop prototype boards.

The remarkable speed of execution achieved by manually optimizing the interconnection of a few FPGAs on the boards stands in contrast to the limited design capacity compared with emulation. Fewer components also mean lower cost that facilitates the proliferation among software developers.

The high performance and portability of the FPGA prototype boards make them unique vehicles as demo platforms for OEM providers of IP blocks.

The full-SoC verification environment has until recently featured these two hardware-assisted verification engines: the emulator housed in a data center with resources that can be accessed over the network; and the desktop prototype board located in the offices of software developers for easy access.

Emulators Need Offloading

The emulator has a central SoC-verification role. In addition to hardware debug and hardware/software integration, it can be used effectively for running long regression suites consisting of a large number of tests. As an example, tests that have already passed must be rerun each time the circuit changes to guarantee the integrity of the DUT. Executing these regression suites as quickly as possible is critical to avoid exceeding the time window allocated for the verification task. The emulator can meet the challenge, but its extensive debug capabilities remain unused. Only when a regression test fails do those powerful debug capabilities come into play to trace the bug and determine the root cause of the failure. Obviously, tying up such a precious resource for a task that is only using the performance but not the debugging means is inefficient.

A desktop prototype could be a way to run hardware regressions even faster than emulation, but they’re generally in the hands of software developers where they run software regressions. To get them into the hands of hardware teams would mean shipping boards to an even larger number of developers. If a prototype could be instantiated in the data center in the same way that an emulator is, then it could be accessed from anywhere for hardware regression use.

Enterprise Prototyping Fills the Gap

This is the role of the enterprise prototyping platform. It is rack-mounted and remotely accessible in the same way that the emulator is. It performs at speed closer to that of a desktop prototype than to an emulator, favoring its deployment for running regression suites and off-loading the emulator. If a regression test fails, then debug resources available on the emulator can be called into action by moving that test easily back into the emulation environment for root-cause debug.

Right out of the box, an enterprise prototype performs five times faster than an emulator. With some additional FPGA network optimization work, that gain can be increased up to 10 times. The evident benefit is that regression suites will run faster, helping to shoulder the nightly burden without bogging down the emulators.

In addition to providing faster execution speed, the enterprise prototype platform accommodates larger design sizes than the desktop prototype board and is less costly than the emulator, helping to multiply its adoption to larger teams of verification/validation engineers.

Just like their desktop counterparts, enterprise prototypes can be used for ICE, leveraging direct, unvirtualized data-source connections. While physical data sources used for emulation suffer extra transaction latency due to the network connection, a direct data connection delivers that data closer to real-time.

By taking on regressions, software verification with real-world workloads, and virtual and ICE tests, the enterprise prototype can lighten the emulation workload while providing the benefits of prototype features, speed, and cost.

Emulators may host any number of designs on any given day. They’re even big enough to host multiple projects at the same time. Their ease of configuration over the network helps to maximize their utilization. For this reason, a given set of tests might run on one emulator one day and another the next.

Configuration, including the connection of ICE data sources, happens at the beginning of the project, and those prototypes are then available as needed until the project is completed. At that point, they can be repurposed for another project without shipping them around the world.

The Full SoC Verification Connection

Combining emulators, desktop FPGA prototyping boards, and enterprise FPGA prototyping platforms, and working on the same SoC design where one is for all and all are for one, a verification team can assemble a perfectly matched hardware-assisted verification triad. This ensures thorough and exhaustive verification and validation of hardware and software of a modern, complex SoC.

Table I encapsulates the main differences among the three hardware-assisted verification engines. (Table Source: Lauro Rizzatti)

In summary:

The enterprise prototype system provides higher capacity than the desktop prototype board and offers higher speed and lower cost per gate and megahertz than an emulator. That helps verification teams reduce the overall cost of ownership of their hardware verification resources as it helps to accelerate the verification cycle.

Dr. Lauro Rizzatti is a verification consultant and industry expert on hardware emulation. Previously, Dr. Rizzatti held positions in management, product marketing, technical marketing, and engineering.