Hardware/software co-debugging is the best way to break out of a very tedious cycle.
“I have a dream…that one day…all SoCs will be free…of bugs and verifying them will be a walk in the park. I have a dream…that one day…all software engineers will be able to validate their software on pre-silicon hardware at the speed of light, delivering fully functional embedded software “before-on-time” for tape-out.
I have a dream today…Well, if not today, how about first thing in the morning…on my desk? Or put another way, how do we make our dreams of tomorrow come true today?
That is not that simple, is it? Every day embedded software code is getting more and more complex, lines of codes are growing longer, and pre- and post-silicon software validation is becoming both more challenging and more critical in the functional verification of SoC environments. Software is the fastest growing component of SoC development costs, and all this software requires a lot of verification.
Figure 1: Impact of Design Technology on SOC Consumer Portable Implementation Cost (Source: 2007 ITRS Roadmap)
On top of that, functional verification itself is becoming a major concern for electronics designers due to increasing design complexity and functionality, along with the convergence of applications such as GPU and CPU infrastructures. Also, the growth of application convergence and software development are creating new challenges in hardware and software integration.
Figure 2: SoC Consumer Portable Design Complexity Trends (Source: 2007 ITRS Roadmap)
In order to stay ahead of the competition and boost verification productivity, engineering teams have to find new methodologies and solutions to achieve first time silicon success “in the blink of an eye.” Traditional simulation simply lacks the required performance for full, system-level verification of such things as multi-core, multi-media, and video designs.
So what can EDA tools do to make the dream a reality today? Fortunately, two hardware/software co-debugger technologies have emerged that herald the dawning of a new day — virtual probe and CPU virtualization.
Today, embedded software development entails writing the original code, building the design, testing and debugging it, modifying the code based on debug results, and then repeating the entire cycle. What do software engineers want to break free of this lengthy and tedious cycle? They want a fast and fully integrated development environment with a built-in context-aware editor, built-in compilation tools, and source-level debugging engines—all linked to a source control system. And they want to be able to run their software on a fast RTL accurate model that behaves “as close as final” to real silicon hardware.
They have strong preferences for their tool flow, so EDA vendors need to understand their flow in order to propose solutions that solve the problems they do really care about. That is the whole philosophy behind virtual probe solutions.
Software debug with a virtual JTAG probe is a creative and effective solution. It is very useful for OS boot code bring-up, hardware configuration coding, and low-level driver development work, offering a nice control and visibility mechanism. Bottom line is: software engineers can debug their code at the speed of emulation. This kind of speed is like night and day compared to digital simulation.
Figure 3: Software-Driven Hardware Verification with Virtual Probe
Yet, it’s not nearly as fast as another emerging technique: CPU virtualization. Hardware emulation technology itself is not enough if it’s not well used and is not part of an advanced ecosystem to ease emulation platform building, mapping, and usage. Accelerating RTL is one thing, but taking advantage of OS booting at the CPU host speed, outside the SoC mapped into hardware, is even more powerful. This helps get closer to the speed of light verification environment that software engineers really want by combining fast software execution with RTL accuracy.
How does this work exactly? Well, the idea here is to connect a transaction-level functional model of the CPU (in SystemVerilog or SystemC) to an accelerated-synthesizable RTL SoC within an emulator. By moving the CPU and memory subsystem of the SoC outside the emulator, the software engineers can work directly on the CPU using their favorite software debugger, with the hardware seen as a black box.
Figure 4: CPU Virtualization Platform
This works especially well when few hardware accesses but big software activity is required. It delivers the fastest platform before silicon availability and a nice environment for driver development to ensure OS boot in seconds.
This technology provides not only state of the art methodologies and tools to facilitate hardware/software co-debug and the integration of complex system platforms by mixing heterogeneous environments but also makes it easier to use hardware emulation platforms through a smart software cockpit. A bonus of such a technique is that verification engineers can reuse their verification environment when going to validation.
With these advanced techniques, the ability to perform pre-silicon OS boot is now a reality and when silicon samples come back from the fab, designers are able to bring up and test their SoCs in a matter of days thanks to the resulting high quality of the design. Total verification cycles will remain difficult to cut down though. However a few days to validate a silicon sample out of the fab is a pretty good achievement.
The advances in emulation technology that enable these techniques are found in Mentor Graphics Veloce OS3, making our dreams for tomorrow come true today.
I say to you today, my friends, so even though we face the difficulties of today and tomorrow, I still have a dream.
This is a great solution for checking all (or most, or many) components of a large SoC, as we move downstream in implementation. Earlier upstream, one could have worked with another MGC technology called Seamless CVE in RTL, just simulation (disclaimer: I am a former user, also later worked for that unit briefly at MGC).
Even further upstream, before RTL implementation, we may be doing system level design in ESL with SystemC (C/C++) and at startup Space Codesign, we have single engine, non-stop hardware/software co-debugging capability – i.e., you don’t have to restart any hardware-side simulation when you modify the hardware. Please check that out on our YouTube channel! 🙂