Design and verification project groups have a new tool in the arsenal that will enable better hardware emulation results, greater efficiency, and increased productivity
More than once, I have heard design and verification project groups complain about the lack of a unified and consistent SoC (system-on-chip) verification process. Almost all of them were juggling the wide range of verification technologies in their environments, including simulation, simulation acceleration, emulation, prototyping, and silicon validation — and they certainly were not juggling efficiently. This has gone on for years and is only getting more complicated.
Late last year, I read that one EDA company was introducing software to eliminate the need to hand-craft different tests for different verification platforms. I knew I needed to learn more. Testbench automation or — in this particular parlance — SoC verification seems like a viable solution. Especially when it can automatically generate multi-threaded, multi-processor, self-verifying C test cases that run on the SoC’s embedded processors on in-circuit emulation (ICE) platforms, FPGA prototypes, and production silicon. (For anyone unfamiliar with ICE, the design-under-test, or DUT, is mapped inside the hardware emulator connected to the target system where the taped-out chip would reside.) There’s no need to hand-write hardware validation tests for various platforms.
SoC verification and hardware emulation are a great match.
This is especially welcome news for hardware emulation users who are getting better and better tools and models to support their efforts. Even so, who would envy a verification engineer trying to debug the integration of hardware and software with sub-optimal techbenches? While not the easiest of responsibilities, they have been able to deploy speed adapters or verification IP (VIP) and now SoC verification.
SoC verification software is able to generate test cases and eliminate the need to hand-write hardware validation tests for a hardware emulation platform. Also, it can stress all aspects of the chip before a verification engineer tries to boot the operating system and applications.
What’s more, these tools can automatically generate self-verifying C test cases for system-level interactions, with a focus on verifying concurrent, coherent, and multi-threaded capabilities for any hardware platform. Obviously, automated test cases are more efficient than hand-written tests that normally verify that each IP block is instantiated properly in the SoC.
Because the tools use graphs on the GUI, test cases can be generated and modified for each platform. Longer test cases can be run in hardware rather than in software.
At this point, you may be wondering why I don’t mention the availability of testbenches from the Universal Verification Methodology (UVM) standard, which is a fairly standard way of debugging. Yes, this can be effective for IP blocks and small subsystems, but UVM doesn’t work well with embedded processors. The more desirable approach is one that’s automated and able to verify shared and concurrent SoC resources, system and power management, and application use cases.
I’m pleased to learn that design and verification project groups have a new tool in the arsenal that will enable better hardware emulation results, greater efficiency, and increased productivity. SoC verification and hardware emulation are a great match.