The rise of hardware-assisted verification

Chris Tice is corporate vice president and general manager of hardware system verification at Cadence Design Systems

Verification of hardware, and the software it enables, continues to be a key bottleneck for chip design. As part of system development, design teams have the option to use different engines and techniques, starting from simulation using approaches based on transaction-level models (TLM) to various ways to execute the register-transfer level (RTL), in simulation and using hardware-assisted verification to enable software development.

The latter is increasingly taking a central role for verification and it is doing so for three reasons. First, there is a secular shift in verification requirements as designs have shifted to advanced nodes, with an explosion in chip complexity – traditional techniques are becoming too slow. Second, there is a shift towards the integration of more complex IP, and hardware-assisted verification is the platform of choice for integration, for reasons of speed and capacity. Third, IP comes with software, and it needs platforms to run on and in addition, more often than not, software executing on the various processors in systems on chip (SoCs) needs to be brought-up as a requirement for tape-out of the hardware. Again, hardware-assisted verification is the preferred platform, although it takes a number of different forms.

Design-cycle choices

Typically acceleration has been used early in the design cycle when you have a testbench-driven verification environment. What’s important here is the reactivity of the verification solution. That means that the solution can be reliably compiled and turned around fast enough to keep up with the design team and design changes.

As the design matures, you shift from a verification-centric type approach to a system-centric approach. That’s where emulation starts to become the dominant use case. In this case you are integrating the entire SoC or subsystem into the emulation environment, and running it effectively against the software stack. Perhaps the verification is software-driven. Another use model is in-circuit emulation [ICE], which occurs when the emulator is connected to the outside environment. Test streams may come from the real environment itself.

The key to making use of this technology is the overall productivity of your platform. It’s a function of the ability to bring a model up reliably inside the platform, and to use that platform to effectively debug and perform complex verification. Productivity is about predictability – you can predict when the platform is going to be up, and you can turn your model reliably. It’s also about versatility – you need a platform that can be used early in the design process when you’re in acceleration mode, all the way through to the end of the process for system integration.

Verification hub

To aid that process, we have built a solution around the notion that the Palladium acceleration technology acts as the verification hub. It has a variety of solutions and methodologies that ride around it. We have virtualized ICE, which we call in-circuit acceleration. Beyond that we have the hybrid use model, where you have a soft model running on a processor and a hard model inside the device under test (DUT).

In traditional ICE, the entire design is inside the emulation box. This includes the CPU and applications processor or GPU. These all tend to run in lockstep around 1 MHz or so. That does give you a high-fidelity, accurate model, but it may take hours or tens of hours to boot an OS when you’re running at 1 MHz.

The hybrid model takes an instruction-accurate model of the processor and connects it to the rest of the circuit through a transaction-based interface. So now when you’re running CPU-based traffic, you’re running it on a virtual model. Instead of running at 1 MHz you may be running at tens of MIPS, and sometimes up to 100 or 200 MIPS, perhaps 100X faster than the emulator. If you’re running a CPU boot operation, you can run anywhere from 50-60X faster.

When you run things that are applications-centric, you’re still running the actual RTL at emulation speeds, and you get full accuracy. The processor is running as a virtual model, and the details are running in RTL. That combination tends to result in a 10X-15X performance increase. The net is a big productivity gain for the software development and hardware/software co-verification teams. A side benefit is that you gain 30 per cent to 40 per cent capacity, as the virtual model is running on a workstation.

Hybrid model

Bringing the hybrid model approach into the solution you have a process by which you can move from early software implementation through to RTL acceleration as the project nears completion. First, you have a standalone virtual platform based on the Virtual System Platform (VSP), you have a connection between VSP and the Incisive simulation environment, and you can get hybrid simulation models. Then you can port the RTL into Palladium and get acceleration on top of that.

FPGA prototyping forms another strand of verification acceleration. In its current context, FPGA prototyping uses multiple FPGAs that are connected together. It takes time to build that model, and to properly match the RTL is quite difficult, so it tends to be used at the tail end of the design cycle.

At Cadence, we view FPGA prototyping as a complement to our mainstream verification solutions around Palladium and Incisive. One way we approach this is by enabling customers to build faster replicated models of Palladium. These can be used for regression tests or for software development.

As the experience has shown so far, there is no single solution. Our strategy with the System Development Suite is to develop a suite of interconnected platforms from the Virtual System Platform to Incisive and Palladium and the Rapid Prototyping Platform, all connected through common flows.