Do you remember 1964? That’s when Motown Records’ The Velvelettes, backup singers for Martha Reeves and the Vandellas, cheekily sang,“‘cause finding a good man, girls, is like finding a needle in a haystack.”
The song offers refreshingly sound advice 48 years later as the singers intone, “You’d better get yourselves on the right track.” It seems that these days finding a bug in a system-on-a-chip (SoC) design has become significantly tougher than searching for a good man was in 1964.
With engineering teams combining hardware with embedded software, they are forced to simultaneously sort out hardware and software issues, instead of just one or the other in a serial fashion. So that makes two haystacks, not one.
While hardware design has always been difficult, the advent of SoCs has sent everyone on the engineering team clambering into the two haystacks to look for that needle. Well, too often we’ve heard the software team point its collective finger at the hardware team and say, “It’s a hardware bug!” The hardware team screams back at the software team, “It’s a software bug!”
“You’d better look before you leap,” cautioned The Velvelettes. Until a thorough investigation is conducted, at face value, they both seem to be right.
Rather unique to the verification field, here is where a state-of-the-art emulation system can come to the rescue to sort out and find that elusive needle in those two haystacks. Emulation can be invaluable for debugging hardware and for testing the integration of hardware and software within SoCs well ahead of first silicon.
When two disparate parts of the engineering team––hardware designers and software developers––use emulation, they’re able to share the same system and design representations. Thanks to combined software and hardware views of the SoC design, they are able to work together to debug hardware and software interactions.
This is possible for three reasons. First, best-in-class emulation systems are fast and can execute billions of verification cycles as required in embedded designs, in a short period of time. Second, they provide a full view of the design guts necessary to debug the hardware. Third, they support transaction-level verification necessary for hardware debugging at a high-level of abstraction via monitors, checkers, and assertions. Emulation allows engineering teams to plan more strategically and implement a debugging approach based on multiple abstraction levels, and not just delve into those two haystacks independently from one another (Fig. 1). Teams can track a design problem across the boundary between the embedded software and the underlying hardware to determine whether the problem lies in the software or in the hardware.
Multi-level debugging gives the engineering team a way to systematically move between different levels of abstraction, starting with embedded software at the highest level. Typical questions addressed at this level include:
- “Has the operating system booted yet?”
- “Is the processor stuck in an interrupt handler?
- “Why is the device driver not handling the data properly?”
Starting from a database comprising multi-billion clock cycles, a software debugger can localize a problem to within a few million clock cycles (Fig. 2). At this level, either the software team quickly identifies the source of troubles in the software code or they work with the hardware team using a software-aware hardware debugging approach to zoom-in to a lower level of abstraction.
The second level is executed via monitors, checkers and assertions implemented through hardware transactors, which avoid speed degradation, to help narrow down the problem to a few thousand cycles. Once the collected data at those two levels has been reviewed, emulation allows them to move down to the signal level. They can analyze the information via the RTL waveforms of the identified period of time and trace its likely origin. At this stage, either a hardware bug is unearthed or the hardware is absolved from failure. In the latter case, it forces a decision to move back to the software environment.
Navigating between different abstraction levels––from software through hardware and backward––avoids long simulation runs and massive amounts of detailed data.
This approach would be impossible with software simulators because they are too slow to effectively execute embedded software, taking weeks, if not months, to process billions of cycles. Likewise, this methodology would not be practical with FPGA prototypes because they lack the design visibility and the interaction with the embedded software necessary for tracing a hardware bug driven by the embedded software.
“Well, now, I say, I’m tellin’ you the natural facts,” the song goes. Just as emulation is antiquating simulation, new emulation systems are obliterating older versions of emulators because they’re smaller, less costly, easier to use and, most importantly, they run faster. And, while the needle in the haystack analogy has been doubled to two haystacks when it comes to describing how SoC designs are debugged, the debugging capabilities to be found in emulation are quickly rendering this analogy obsolete. This is a welcome event. Or, as The Velvelettes sing: “You’d better get yourselves on the right track, ‘cuz finding a good man (or SoC, in this case), is like finding a needle in a haystack.”
Eve Team
www.eve-team.com