Donald Cramb, EVE-USA
ETimes (5/30/2012 12:39 AM EDT)
Today’s system-on-chip (SoC) designs aren’t just hardware anymore. In the past, the creation of hardware chips was separate from the creation of the software to be executed on those chips, but today an SoC isn’t complete until you’ve proven that the intended software works – and works well – on the platform. In other words, today the SoC itself is a full-fledged embedded system.
This comes with a benefit. In the past, if there was a hardware problem the software programmer had to figure out how to code around it because the hardware was already done. By validating the software before declaring an SoC to be complete, you get an opportunity to fix hardware issues before they’re cast into silicon. But that benefit comes with a challenge: debugging efforts may lead to a hardware or a software cause. You can’t assume either one is correct.
Hardware debug before tape-out is traditionally done using simulation. Various other hardware validation strategies involving things like formal verification have augmented simulation to increase basic coverage and ensure that corner cases aren’t missed, but for debugging, simulation maintains its central role.
Software debug is traditionally done using debug engines, one per core. They take advantage of hardware features that provide some level of visibility into and control over the goings-on inside a processor. While there are a basic set of expected debug capabilities, your ability to diagnose issues is limited by the kind of access that the processor provides.
Click here to read more ...