Portable Stimulus Layer 1: Test Abstraction

From the number of blog views, it’s clear that the topic of “portable stimulus” is of considerable interest to our readers. As a reminder, Accellera’s Portable Stimulus Working Group (PSWG) is developing a standard in this area and Breker is helping to lead this effort. In our last two posts on this topic, we have outlined our guiding principles for any proposed standard, based on our own experience over the years with our most advanced customers. We also split the goal of the portable stimulus effort into three parts: 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.

For this post, we’re going to explore the first level in more detail. We made the statement in our last post that the test abstraction level can be standardized using a simple application programming interface (API) to specify the abstract steps of the test. The API defines the access to a base-class library providing the primitive operations used to create portable tests. First of all, let’s be clear that this is not a theoretical proposal. We have provided a library with a defined API for several years and this is a key building block of our own portable stimulus and test solution. We know that this approach works from our own customers and believe that it would be an excellent foundation for a standard.

This proposal should not be alarming to anyone involved in verification. A library with an API is easy to learn, requiring no new language or language constructs of any kind. In fact, the entire Accellera Universal Verification Methodology (UVM) is built on a similar idea. The UVM added no new constructs to SystemVerilog, but instead provided a rich base-class library for creating verification IP (VIP) models and constrained-random testbenches. In fact, some of the more advanced features of UVM such as the Register Layer help pave the way for a portable stimulus base-class library. Of course we are now operating at a higher level of abstraction, so that tests written using the proposed API are portable from IP to system and from simulator to silicon.

What sort of elements should this library contain? Clearly it must include abstract primitive operations to read and write registers and memories, and to send data to and from chip I/O ports. Defining the registers can be done very much as in the UVM. We’ll want to be able to print messages, set message verbosity, and keep count of errors. We’ll need to delineate the start and end of tests and define tasks within a test. For users who don’t have their own interrupt handler, we can provide a default library element. In short, the base-class library defined by the API will look quite familiar to anyone who develops testbenches, writes tests, and verifies chips for a living.

A verification engineer must be able to hand-write a directed test using the library elements. Because of the higher abstraction level than the UVM, such a test can be ported by an EDA vendor’s tools to UVM transactions for IP and subsystem level and to C/C++ tests for a system-on-chip (SoC) running in simulation, emulation, or in actual silicon. If the engineer takes advantage of the higher levels of the portable stimulus standard (test scheduling and test randomization) then the generated test from the EDA tools can use many of the same library elements to build the portable test.

There are several advantages of our proposed approach to the Accellera portable stimulus standard. The layering clearly defines what’s needed for each automated verification task. The library approach is familiar to users of the UVM and other Accellera standards. There’s no new language to learn, so engineers can get up and running quickly. Finally, as we’ll discuss in our next blog post, adding on layers 2 and 3 of the standard enables an enormously powerful environment with realistic use cases, randomized control flows, and enough intelligence to verify cache coherency and other famously difficult problems. Catch you next week!

Tom A.

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

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

This entry was posted on Thursday, May 14th, 2015 at 12:04 am. 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.