For Software Developers, Hardware Emulation Rules!

Note: @Extension Media, (2016). This is the author’s version of the work. It is posted here by permission Extension Media for your personal use. Not for redistribution. The definitive version was published February 1, 2106 in Embedded Systems Design http://www.extensionmedia.com

Booting an OS such as Linux gets the designer to the starting line, but how does the real work commence for complex multicore designs destined for gaming, digital signage, and more?

When software developers hear the word emulation, they often think software emulators and not hardware emulation. That’s changing, though, as the versatile hardware emulator gains a more widespread reputation for being able to ensure that the embedded system software works correctly with the underlying hardware. It’s happening as it becomes a shared resource between hardware and software teams to accelerate hardware/software integration ahead of first silicon. As it should, especially when the ratio of software developers is greater than hardware engineers on a chip project.

Through the years, hardware emulation has been used for hardware verification of ASIC and SoC designs, and its use model is growing. Hardware emulation’s speed of execution can be up to six orders of magnitude faster than a hardware-description-language (HDL) simulator, reducing the design debug process without constraining design sizes. Among the largest SoC designs are processor and graphics chips, and Ethernet switch and router chips. All of them approach or even surpass the half-billion ASIC-equivalent gate mark. These are designs that would thwart an HDL simulator.

[Photo courtesy Official Navy Page from United States of America Candice Villarreal/U.S. Navy; public domain, via Wikimedia Commons.]

Figure 1: Winning the debug process race: Boasting an execution speed up to six orders of magnitude faster than a hardware description language (HDL) simulator, hardware emulation can shorten the design debug process without constraining design sizes.

Executing Embedded Software

Never has hardware/software co-verification been more important as embedded software becomes a large component of an already complex system-on-chip (SoC) design. For designs using an operating system, such as Linux, booting it is a bare minimum. But Linux already exists and it’s not code that designers have to write. Although it does have to be customized to the system, with memory maps and drivers that take a simple system call and cause it to do real work on real hardware.Booting an OS typically gets the designer to the starting line. The real software that does the real work can only start when the OS has been successfully loaded. Attempting to verify such applications would simply stretch the runtime way beyond the OS boot time.

In addition, the designer has to test multi-threaded programs. For some systems, the multiple “threads” are actually turned into multiple processes running independently on different cores, with or without an OS. Packet processing is probably the best example of this: It typically consists of a pipeline of processors, each of which performs a specific piece of the packet processing functionality in turn. All of the threads or processes have to work together seamlessly, passing data around as necessary and seamlessly swapping contexts.

Simulation farms, a popular and well-used resource, are not adequate to execute embedded software. Embedded software needs to be processed in parallel and cannot be split in subsets, all of which takes several billion sequential cycles. Hardware emulation easily can handle a sequential process and is undeterred by design sizes. At speeds of several hundreds of kilohertz or megahertz, it can boot Linux in less than one hour.

Integrating newly designed hardware with newly coded software should be done as early as possible to resolve bugs –– not a problem for hardware emulation. It ensures software and hardware are verified concurrently to confirm they interact correctly. It can be used as soon as the design register transfer level (RTL) code is stable to uncover difficult to find hardware bugs that require many millions of verification cycles. It can trace a software bug into the hardware or a hardware bug in the software’s behavior with the necessary speed, performance, and capacity to handle complicated debugging scenarios, something no other verification tool can do.

The Shortcut Designers Can’t Afford

Virtual platforms are becoming increasingly popular as a way of testing software ahead of actual hardware. For general-purpose applications, those not requiring intricate interaction with the hardware, virtual platforms are an effective way of testing application software way before silicon or even RTL availability.

However, the strength of a virtual processor is also its weakness: It can execute software quickly because it abstracts out much of the execution detail. Such abstraction is acceptable for higher-level code or applications. For code that touches the hardware, such as drivers, designers can’t afford to take that shortcut.

Virtual platforms are utterly inadequate for proving that the chip is working because they eliminate the chip’s details.To verify the interaction of embedded software with the underlying hardware, a cycle-accurate representation of the design is needed to be able to trace a bug anywhere in the SoC. A hardware emulator offers an accurate functional representation of the design before the silicon is ready for testing because the emulated design is based on an actual silicon implementation, even though it’s not timing accurate.

Functional verification and system validation are hardware emulation strengths. It is used to verify the hardware and software work as intended and validate that the system meets or exceeds the specification. Software programmers are using it to validate embedded software –– applications, diagnostics, drivers, operating systems and software-driven tests, all with a need to process hundreds of millions, even billions of cycles –– extending its use across the entire SoC development cycle.

Hardware emulation gives software developers full, 100 percent visibility into the hardware design, necessary to quickly trace bugs anywhere in the design.

Not to Be Confused

Verifying the combination of hardware and embedded software is estimated to consume about 70 percent of the project cycle.

And this verification task is also the most challenging one to perform, so it’s no wonder hardware emulation rules. This co-verification process can improve product quality and shave months off a project development schedule.

The makeup of an SoC project team has changed through the years and now is comprised of both software developers and hardware engineers. Combining the two disciplines offers a way to differentiate the product and give it a technological edge.

The backdrop hasn’t changed much, though. It’s still a heavy mix of time-to-market delivery schedules, while balancing cost with design size and low-power considerations, revenue and profitability. Comparatively, debug’s a cinch with hardware emulation, as both software developers and hardware engineers benefit. Both groups have come to value hardware emulation’s ability to verify hardware and software at the same time. No one will confuse software emulation and hardware emulators again.

This entry was posted on Monday, February 29th, 2016 at 8:00 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.