A Portable Stimulus Standard Will Take Time, but the Technology is Here Today

Last week, we used an update on the Accellera Portable Stimulus Working Group (PSWG) presented at the Design and Verification Conference and Exhibition (DVCon) as a jumping-off point to discuss the status of this standardization effort and some key aspects of the three proposals currently under consideration. We were not the only blog to cover portable stimulus topics from DVCon; Brian Bailey of SemiconductorEngineering and Bernard Murphy from SemiWiki also posted their observations.

Earlier this week, EDACafe blogger colleague Peggy Aycinena posted a thought-provoking look at PSWG and the portable stimulus challenge. In regards to the scope of the proposed standard, she noted “a distinct wow factor in all of this, it’s so comprehensive” and said “this whole effort seems massive to me.” Today we’d like to respond to Peggy’s comments and questions, noting both the challenges of a portable stimulus standard and the availability of a working solution today.

First of all, let be honest: Peggy is correct about the broad scope of the standard and the effort it will take to complete the work undertaken in PSWG. She included in her post the same Accellera diagram that we referenced in our own post last week:

Indeed, this diagram and its implications are “massive” because the proposed standard applies to many types of users, platforms, and levels of integration during system-on-chip (SoC) development. We wouldn’t go as far as Peggy’s statement that the standard would be inclusive of “everything and everyone involved in chip design and verification” since it’s really about verification and validation. Designers might help develop the portable stimulus models but otherwise this diagram is not a design flow.

But there’s plenty of scope to cover just within verification and validation; the needs of a verification engineer working on a single IP block are very different from a those of a bring-up team validating fresh silicon in the lab. The whole point of the portable stimulus concept is that EDA vendor tools will be able to generate appropriate test cases (stimulus, results checking, and coverage) for any target from the same abstract model. As we’ll discuss in a moment, this approach is not just a vision.

Peggy also sagely described the non-technical aspects of standards development as “the politics of corporate posturing/positioning” with “each party involved hoping to craft a document that most closely matches their internal technology road maps.” That’s a bit harsh; people involved in standards bodies inevitably end up spending a good chunk of their own time because they believe in the value for the industry. At the same time, they do represent their employers and so politics just as inevitably play a role.

As we discussed last week regarding the DVCon presentation, the next step for PSWG is choosing the baseline for the standard. Breker has proposed a solution using C++11, with a class library and an API, but no extensions or non-standard constructs. Cadence and Mentor are championing a proposal for a new domain-specific language for the portable stimulus models. There are technical, practical, and political arguments in favor of both proposals.

So Peggy is right about the broad scope of the proposed standard, the challenges to developing it, and the aggressive nature of PSWG’s goal for first release in January 2017. It is interesting that she does not seem to be as concerned about whether it will actually be possible to build EDA tools that serve the full scope of the diagram above once a standard is available. Perhaps that’s because she knows that a working portable stimulus solution is available today.

Our Trek family of products reads C++ graph-based scenario models and automatically generates self-checking test cases for all of the targets shown in the diagram. We have customers using graphs to verify individual IP blocks and then combining these graphs for subsystem and system verification. We generate UVM transactions for testbenches as well as C code to compile and run in embedded processors. We run on “bare metal” so that we have full control of all system resources.

Further, we fine-tune the generated code for every platform. We have customers moving seamlessly from virtual platforms to simulation to emulation to silicon, and from silicon back to simulation and emulation for debug purposes. We collect system-level coverage information, even from silicon. Finally, our solution scales. We have customers with system-level graphs of more than a million nodes, and customers running our test cases on as many as 144 processors in parallel in a multi-SoC configuration.

Once of the reasons that we continue to invest a great deal of effort into PSWG despite the challenges is that we know we will have a solution ready as soon as the standard is defined. The portable stimulus standard will take some to complete for all the reasons we’ve discussed but the technology to implement it exists today. Please come join the ranks of Breker customers now, and we’ll migrate you to the standard when it’s available. For more information, please contact us. As always, thanks for reading!

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Accellera, Breker, bring-up lab, C/C++, cache coherency, Cadence, constraints, EDACafe, emulation, ESL, FPGA, functional verification, graph, graph-based, mentor, multi-SoC, Peggy Aycinena, portable stimulus, prototyping, PSWG, scenario model, SemiconductorEngineering, SemiWIki, simulation, SoC validation, SoC verification, system-on-chip, SystemVerilog, test case generator, test cases

This entry was posted on Thursday, March 24th, 2016 at 12:58 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.