Hardware Emulation Refuses to Stay in One Lane

One day recently, I was considering the varied use models for hardware emulation. It brought back a long-forgotten memory of an evening bowling in New England, where I lived for several years in the ‘80s.

New England has a quaint, little-known (outside of the region) type of bowling called Candlepin. While the play is the same as the more popular form of bowling, the pins are long and narrow, and look a bit like candles. The 10 candlepins are set up in an inverted triangle –– one ball in the first row, two in the second, three in the third, four in the fourth –– and look vaguely as if they’re in “lanes.” This could be a diagram for the verification tool space with most of the available verification tools and techniques in separate and distinct lanes, each with its own function.

Not so with hardware emulation because it’s able to fan cross lanes or boundaries and is multi-functioned. The best example is hardware/software co-verification. Emulation can track hardware bugs from a hardware glitch or software failure or detect software bugs caused by software breakdowns or hardware problems. Its final step is verifying that the hardware has been properly designed to run the software.

In another lane, verification engineers can work at the system level where some design blocks or sub-systems are described at the register transfer level (RTL). Hardware emulation has the processing power to manage software development and run software workloads, something simulation can’t offer from its lane.

Emulation design datacenters have begun cropping up everywhere, creating yet another lane, and are similar to remote centralized simulation server farms. They feature large capacity, multi-user capabilities and can remotely support verification engineers, hardware developers and software designers. They are ideal for parallel jobs (or lanes), including regression test suites that can run to several million cycles or booting operating systems needing billions of cycles.

Performance characterization is another of the many lanes supported by hardware emulation. Post-silicon verification and software validation are a necessary part of the final testing as the project team prepares for silicon. Once silicon is back, it’s tested. If it doesn’t pass, it’s obviously the silicon and not the validation environment because it’s been verified with hardware emulation.

Of course, emulation is well-known for debugging chip designs and viewed as the most effective verification tool because it provides an accurate representation of the design before silicon availability. As a result, it’s a perfect tool for project teams who want to avoid risk.

In the past, emulation was implemented in In-circuit emulation (ICE) mode with the design mapped inside the emulator in ICE mode and connected to the target system in place of a chip or processor for debug. While still employed, more verification engineers are switching lanes to transaction-based emulation or acceleration mode, which moves verification up a level of abstraction from RTL to improve performance and debug productivity. A virtual target system uses a hardware verification language (HVL) such as SystemVerilog, SystemC or C++, eliminating speed adapters that run between a slow emulator and a faster target system. This is the way hardware emulation is employed remotely.

Other applications include system-level prototyping and simulation testbench acceleration. Hardware emulation linked with a hardware verification language (HVL)-based testbench creates a hardware acceleration platform with the simulation speed essential to validate and debug a design. And, while hardware emulation can’t measure analog behavior since it requires a digital representation of the design, verification can be achieved by moving the power abstraction level higher up.

In Candlepin Bowling, the objective is to knock down as many pins as possible, a difficult proposition because the candlepins are smaller than the regular-size bowling balls –– 4.5 inches in diameter –– and lighter weight. The bowler gets three balls to make a strike. With emulation, there are no gutter balls. It refuses to stay in one lane and has the ability to take out all 10 candlepins in one strike.

See you at the bowling alley!

This entry was posted on Thursday, December 17th, 2015 at 11:29 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.