What Does “Portable Stimulus” Really Mean?

We’ve discussed at some length in past blog posts the recent effort by Accellera to standardize “portable stimulus” in its Portable Stimulus Working Group (PSWG). As a reminder, this group has been chartered by Accellera to “develop the electronic industry’s first standard for portable test and stimulus. When completed and adopted, this standard will enable a single specification that will be portable from IP to full system and across multiple target implementations.” At trade shows and customer meetings, we’re often asked to explain more about what the concept of portable stimulus means and how it relates to our products. We’ve also been asked for details on the workings of the PSWG and what is likely to happen in terms of a possible standard.

Let us be clear that neither this post nor future posts will reveal the inner workings of the PSWG or share non-public information. We believe strongly that standards bodies must do their jobs with a minimum of distraction. Members must be able to propose and discuss ideas that might seem crazy to those not actually doing the work and without the proper context. There are also IP rights and patent implications to some portions of the standardization process. So this won’t be a “kiss and tell” opportunity. If you want to know what’s happening on the standard right now, we invite your company to join Accellera and contribute a member of two to the PSWG. But for this post, we will take this opportunity to provide some background on the portable stimulus arena and share what we think is important.

For a start, let us remind you of our two basic precepts and add a third. The first is that portable stimulus is not enough. All tests must be self-checking, and coverage is needed to assess effectiveness. Thus, any attempt to make tests portable must encompass stimulus, results, and coverage. The “portable test and stimulus” name proposed for the Accellera standard is a direct reflection of the arguments that we and others made. Our second fundamental requirement is that portability must encompass both vertical reuse from IP to SoC and horizontal reuse across all verification platforms. Although it seems that there is industry consensus on this point, some parties seem more interested in a UVM-like extension for transactional testbenches and others in software-driven verification across platforms.

The third point, which may be less obvious, is that we do not believe that the tests themselves can be made portable. The same bits that run on simulation, leveraging UVM testbench models and backdoor memory access, cannot possibly run on actual silicon. What can be portable, and standardized, is some sort of abstract specification or model for the verification space and the test desired. We believe that this should be the focus of the Accellera PSWG, and indeed it is. There is a wide range of industry opinion on what format such a specification or model should take. Breker and the two other vendors that claim to have some form of a portable stimulus solution have each chosen a different input format and a different approach. We’d like to explain our thinking.

As we view the problem, the goal of the portable stimulus effort can be split into three parts. The first part involves defining the abstraction or model as we have discussed so far. We believe that this part of the standard can be defined using a simple application programming interface (API) to specify the abstract steps of the test. For example, a user might write a value to a particular memory location, using the same syntax for any target platform. The test generator then has the task of mapping this operation as appropriate for the target. For an IP block or a “headless” subsystem, the write would be generated using UVM transactions. For full-SoC platforms, C code would be generated.

The API alone would suffice for directed tests, and likely even for tests with randomized data and addresses. But full-SoC verification requires randomization of the control flow. The test generator must be able to string together multiple IP blocks into realistic use-case scenarios. Tests must be scheduled across multiple threads and multiple processors in order to stress all aspects of the system design. System-level scenarios such as power and security must be overlaid on top of regular operations. We do not believe that this level of specification is possible with a simple API. In our next post we will review some of the options we’ve considered at Breker for the two other parts. Some of these options are also likely to be considered within the PSWG. In the meantime, please give some thought to the types of portable system-level scenarios that you would need to define in order to thoroughly verify your most complex SoC.

Tom A.

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

Tags: Accellera, API, Breker, EDA, functional verification, graph, graph-based, horizontal reuse, IBM, portable stimulus, PSWG, scenario model, simulation, SoC verification, test generator, Universal Verification Methodology, uvm, vertical reuse, VIP

This entry was posted on Wednesday, April 29th, 2015 at 7:25 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.