You don't need a graphic like this one 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 your ARM Cortex™-A Series processor, and execute the programs. Seems straightforward, but now try it for multiple embedded core clusters 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 is well between the HW and the SW at the system level.
But here comes the fire hose. By this time, you have 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 is 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 are easier to debug?
There is 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 for your embedded ARM Cortex A-Series processors 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 from Mentor 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.
Guest Partner Blogger:Mark Olen is currently a Functional Verification Technologist at Mentor Graphics Corp. He has spent thirty years in semiconductor design verification and manufacturing test, and has authored papers in the areas of intelligent testbench automation, design for test technology, and semiconductor manufacturing test automation. He wrote his first testbench in 1981 at Raytheon, and went on to spend ten years working at Teradyne in the ATE and DFT industries. He became Vice President of Cascade Microtech's thin film wafer probe division, before co-founding Lighthouse Design Automation where graph-based Intelligent Testbench Automation was first successfully applied to semiconductor design verification. Mark graduated from MIT with a BS in EE&CS.