Walking in the Desert or Drinking from a Fire Hose?
You don’t need a graphic like the one below to know that multi-core SoC designs are here to stay. This one happens to be based on ARM’s AMBA 4 ACE architecture which is particularly effective for mobile design applications, offering an optimized mix of high performance processing and low power consumption. But with software’s increasing role in overall design functionality, verification engineers are now tasked with verifying not just proper HW functionality, but proper HW functionality under control of application SW. So how do you verify HW/SW interactions during system level verification?
For most verification teams, the current alternatives are like choosing between a walk through the desert or drinking from a fire hose. In the desert, you can manually write test programs in C, compile them and load them into system memory, and then initialize the embedded processors and execute the programs. Seems straightforward, but now try it for multiple embedded cores and make sure you confirm your power up sequence and optimal low power management (remember, we’re testing a mobile market design), correct memory mapping, peripheral connectivity, mode selection, and basically anything that your design is intended to do before its battery runs out. You can get lost pretty quickly. Eventually you remember that you weren’t hired to write multi-threaded software programs, but that there’s an entire staff of software developers down the hall who were. So you boot your design’s operating system, load the SW drivers, and run the design’s target application programs, and fully verify that all’s well between the HW and the SW at the system level.
But here comes the fire hose. By this time, you’ve moved from your RTL simulator to an emulator, because just simulating Linux booting up takes weeks to months. But what happens when your emulator runs into a system level failure after billions of clock cycles and several days of emulation? There’s no way to avoid full HW/SW verification at the system level, but wouldn’t it be nice to find most of the HW/SW interaction bugs earlier in the process, when they’re easier to debug?
There’s an easier way to bridge the gap between the desert and the fire hose. It’s called “intelligent Software Driven Verification”. iSDV automates the generation of embedded C test programs, for multi-core processor execution. These tests generate thousands of high-value processor instructions that verify HW/SW interactions. Bugs discovered take much less time to debug, and the embedded C test programs can run in both simulation and emulation environments, easing the transition from one to the other.Check out the on-line web seminar at the link below to learn about using intelligent Software Driven Verification” as a way to uncover the majority of your system-level design bugs after RTL level simulation, but before full system level emulation.
Comments