Accellera and Portable Stimulus

I’ll start with a quick note on DVCon. This seems to be gaining momentum each year. In addition to the events in the US, Europe and India, a DVCon event is now planned for China, kicking off in Shanghai in 2017. At a time when we’re all bemoaning the future of EDA and EDA conferences, DVCon is booming internationally, no doubt reflecting the relentless growth of the verification challenge.

In standards development, Accellera is working in a number of areas; my focus for this blog is their work on the Portable Stimulus (PS) standard, in development under the Portable Stimulus Specification Working Group (or more simply PSWG). The purpose of the PSWG is to provide for sharing scenarios, results and coverage requirements across platforms (virtual, emulation, simulation, prototype and board) and teams (architect, hardware developer, software developer, analog developer, post-silicon debug, ..), all the way from block level to system level, in a non-proprietary standard. Which sounds quite a bit bigger than portable stimulus, but they were allowed only four letters for the group acronym.

Development is about halfway towards version 1 (expected early 2017) and most of the key semiconductor systems and EDA players are actively involved. They are starting with a baseline of a declarative specification (separating what should be tested from how it is tested and moving towards a solver-based philosophy). This should be able to integrate with non-PS code and, in the baseline proposal should fit with existing ecosystems. The preference for a declarative rather than more common procedural approaches is driven by ability, especially at the system level, to trace paths, potentially formally prove properties, define coverage and more.

The working group are now looking at next steps. A joint contribution from Cadence and Mentor suggests a new domain-specific declarative language, also providing for integration from legacy C/C++/SV code. The Breker contribution suggests a declarative C++ along with value constraints and path constraints. The Vayavya contribution is a complementary syntax to generate register sequences and firmware and driver routines from a canonical hardware/software interface description.

The value in portability between platforms and teams is an obviously good thing in many ways, but what I find gets lost in that general message of standardization goodness is standardization around an important shift in system-level testing and coverage. For me this starts a DVCon or two ago where there were fairly strident demands from the audience wanting to know why vendors weren’t providing tools to help improve system-level coverage as they had with constrained random (CR) for block-level coverage.

CR is too crude for system-level tests, but there seemed at that time to be no widely-accepted alternative to directed or software-driven test. Neither offers a systematic way to optimize hardware coverage. But graph-based/declarative approaches can give better guidance at the system-level both to the verification engineer and to solvers to construct/randomize sequences of actions and to determine a usable sense of coverage. For solvers, think of it as sequence-based constrained-random, where what is randomized is not just data but also paths through feasible sequences of system-level actions.

I have seen solutions along these lines emerging from several of the EDA vendors and I’m sure some of the motivation for PS has been to get the representation of this capability standardized before it becomes frozen into proprietary formats. And that is really important because this system level aspect of verification is going to be the heart of the problem and the heart of valuable solutions.

You can learn more about the Portable Stimulus Working Group HERE.

More articles by Bernard…