Portable Stimulus Layer 3: Test Randomization

Over the lifetime of this blog, we’ve covered a lot of diverse topics regarding Breker’s products and technology, trends in SoC verification, and the EDA industry in general. For the last month, we’ve offered our longest series of posts ever on a single topic: portable stimulus. There’s a very good reason for this: Accellera’s Portable Stimulus Working Group (PSWG) is making good progress on defining a standard in this area. As one of the group’s leaders, Breker has been leveraging our many years of experience in SoC verification to develop the best possible industry solution. We’ve been using The Breker Trekker blog to share our thoughts and to encourage your feedback.

We begin the fifth, and perhaps most important, post in our series by reminding you that we split portable stimulus into three layers: defining the tests using abstract primitive operations, scheduling the tests across multiple threads and multiple processors, and randomizing the control flow to verify the full range of realistic use-case scenarios. We have shown over the last two posts that both the first and second layers can be defined easily by a simple application programming interface (API) providing access to a base-class library. This library includes the basic building blocks needed for a directed or automated test as well as scheduling control for processors, threads, and resources. It is natural to wonder whether the randomization layer can be handled in a similar way.

Before we began covering the three layers in detail, we discussed various approaches to defining portable stimulus, which must include the capabilities of graphs to support randomization of the control flow. We noted our reservations about using the Unified Modeling Language (UML) alone and our reluctance to invent yet another new verification language just to define portable stimulus. We described how we have provided the industry’s leading portable test case solution by adding only a few small extensions to the standard C/C++ language. We handle these extensions with a pre-processor so that no other tool needs to understand them. We concluded by asking whether the test randomization step, which involves making constrained choices at select (branch) nodes in the graph, can also be handled with an API.

We’ll skip any drama and give you the answer; yes! All aspects of portable stimulus layer 3 can be handled by API calls with no new language or language extensions. This is a big step for Breker, our customers, and the verification industry. You can specify randomized selection points and control or bias the randomization process with nothing more than C/C++ API calls. As an example, a call to “pss_select” could set up the choices for randomization. The following code snippet would define the graph shown below it.

Each pass by an automatic test generator through this code would produces a random choice among the arguments and thus a random path through the graph.This randomization is critical for effective SoC verification. All combinations of processors and memories must be exercised for cache coherency verification. All legal producer-consumer scenarios between pairs of IP blocks must be verified. Of course, you may not want the selection of an argument to be purely random. The API and base-class library include additional functions to bias, force, or prohibit specific paths. These become graph constraints that control which paths are included in generated test cases. For example, if the functionality represented by node b2 is not yet implemented in the design, you could add an API call to prohibit paths through b2. When that functionality is ready to test, you simply remove the constraint.

We want to stress that this is a native language solution to both graph specification and portable stimulus generation. There is no new language to learn, no new constructs, no extensions to existing languages, or anything of the sort. The API can easily be offered in multiple languages; C/C++ and SystemVerilog are two obvious choices. Verification engineers use API-enabled libraries all the time, so adding one for portable stimulus is a very natural approach. You can use the first layer to set up your testbenches, configure your registers and memory, run your tests, check your results, and port the tests to hardware platforms. You can use layer 2 of the API to control scheduling and resource sharing. The third layer gives you the ability to specify graphs to define your verification space and generate very powerful test cases automatically across all platforms. We strongly believe that the API/base-class library approach would be ideal as the basis for an Accellera portable stimulus standard.

Tom A.

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

Tags: Accellera, API, Breker, C/C++, EDA, Esperanto, functional verification, graph, graph-based, horizontal reuse, IBM, portable stimulus, PSWG, randomization, scenario model, scheduling, simulation, SoC verification, subsystem, SystemVerilog, test, test generator, UML, Universal Verification Methodology, uvm, vertical reuse, VIP

This entry was posted on Thursday, May 28th, 2015 at 4:30 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.