Get email delivery of the Cadence blog featured here
There isn’t a silver bullet when it comes to verification efficiency. But having a standard test and stimulus specification language that is reusable across target platforms like emulation and simulation can be a huge productivity boost. That was the main message of a Cadence-sponsored panel discussion on Wednesday, March 2, at DVCon in San Jose.
“Software-Driven Verification with Portable Stimulus: The Next Productivity Leap Enabling the Continuum of Verification Engines” drew several notables from the design and verification world:
Schirrmeister led the discussion, highlighting the many challenges in designing hardware and software systems: many IP blocks, many cores, lots of software. “At the end of the day, you have different types of applications you are dealing with….with different challenges to be dealt with. You have different complexities, differentiation that you try to achieve in hardware and software, specific analog/mixed-signal requirements,” he noted.
The goal of the Portable Stimulus Specification Working Group is to define a portable test and stimulus specification language that can be used to generate stimulus for multiple target implementations. Users would then be able to specify behaviors and intent once, and multiple implementations could be derived from this. Users would also ideally be able to select the best tool(s) from competing vendors to achieve the best results for their target platform.
Fitzpatrick emphasized that standardization provides a way to address the challenges designers are facing today. “All of you out there seem to have your own way of dealing with this problem,” he said. “The idea of standardization is, you cooperate on standards and you compete on tools.”
Starr pointed out that one of the key goals for software-driven verification is to be able to verify and debug earlier in the development process. Verification engineers want to be able to check production code, but this runs too late in the process. Portable stimulus can provide a way to get closer to metal and software and test all of the interactions earlier, he said.
Software-driven verification can mean different things to different people, said Fitzpatrick. “Ultimately, we need to verify these devices, and there’s a large software-driven component. Power control comes to mind—it’s a piece of software intimately involved in controlling the hardware. We need to use the resources we have to test all these things as we go from block level to system level. Portable stimulus provides a layered way to test these things.”
Often, Fitzpatrick noted, software engineers are concerned about having to rewrite their software. A portable specification would allow reuse. Gururaj added that portable stimulus provides another layer for users to model interactions in their final device. Rosenberg pointed out that what’s needed is to find the right level of abstraction, a commonality that is used across all of the elements that need to be verified.
The key, Fitzpatrick said, is to talk about software-driven verification as an evolution, not a revolution. There’s a need, he said, to educate software engineers on the value of using their knowledge for verification and layering in the knowledge from verification engineers on how to do verification.
AMD’s process illustrates how a software-driven verification approach can be applied. Starr explained that the team starts its work on virtual platforms, applying some level of abstraction to catch the bugs. The team then moves on to hybrid emulation before the whole SoC is ready, in order to get a jump start and perhaps derive some additional performance. Finally, the team performs full emulation with the full SoC.
“There’s no silver bullet,” said Rosenberg. “We’re all talking about odds here—we’re trying to define a process to follow that is systematic and predictable, to improve our chances to get away without bugs.”