Debugging SoCs Can Be Complicated
There’s nothing worse than thinking you’re close to the finish line of your system-on-a-chip (SOC) design then, just as you complete coding and verifying your register transfer level (RTL) code, you find the embedded code isn’t working. After doing all of that work, instead of grabbing something to eat and relaxing, now you have to re-trace your steps to detect just what went wrong and locate exactly where the issue is. Is it in hardware or software? Or both? But hey, there is good news!
This white paper right here is your ultimate debugging resource. It demonstrates two contrasting techniques for debugging Arm®-based SoCs at the RTL. You will also learn how adding a software-enabled verification environment to an existing hardware verification environment (sorry for the word salad, but you’re an engineer so you get it) is wildly advantageous to designers working on Arm-based designs, as compared to manually traversing static log files generated during simulation.
Adding a software-enabled verification environment to an existing hardware verification environment yields many benefits to designers working on Arm-based designs. Tools such as Veloce Codelink provide the functionality described. Veloce Codelink does not require changes to the software or hardware design and allows for logging and replaying your simulation. This multi-faceted tool supports multi-core, multi-CPU environments and offers the ability to step forward and backward, as well as up and down the call stack to be able to see what the software and hardware are each doing when a bug is encountered.
Indeed, adding the software debugger to the hardware verification environment and linking it to the processor model yields many benefits, not the least of which is that it allows for a higher level of abstraction when writing software. This helps to avoid the tendency to oversimplify the software because of a lack of visibility. Even though C or C++ allows for a higher level of abstraction, programs written in these languages are often very simple because they are very hard to debug. In extreme cases, such programs work almost at the assembly level, performing basic hardware writes and reads just so they can configure ASIC registers. Due to added visibility in Codelink, software can be extended to perform a results checkup and run various algorithms. Additionally, more complex boot-up software and Linux execution can be brought to run on the CPU to fully verify the design.
So read the white paper to learn more.