Portable Stimulus Taking Center Stage at DAC

Living on the cutting edge, as I do, I’ve been focusing most of my attention recently on the problem of Portable Stimulus. As you may know, the Accellera Portable Stimulus Working Group (PSWG) has spent the last 14 months or so (starting in March, 2015) working on developing a standard to address this important aspect of functional verification. Although I’ve served as the Vice Chair of the PSWG since its inception, the views expressed here are my own and are not intended to represent the official position of the PSWG as a whole.

As we all know, functional verification testing takes many forms, depending on where you are in the process, and the testing is done by different people with different areas of focus along the way. The idea of Portable Stimulus is that we can have a single description of the scenario(s) to be exercised that can be reused by everyone from architects to RTL verification engineers to post-Silicon validation engineers and software teams on a variety of platforms from simulation and virtual platforms to FPGA prototypes, emulation and even post-Silicon. To describe it in its most simplistic form, we’re talking about a single representation of test intent that can be used to drive a UVM-based simulation for an IP block and can also be used to generate executable C code to run on an embedded processor to drive the same IP block inside an SoC in an emulator, FPGA prototype or even in the actual chip. No one on the committee that I’ve talked to is under the illusion that this is an easy problem to solve, but it’s an important one for us to take the next step in verification productivity.

The WG is actively considering two alternate proposals: a joint proposal from Mentor Graphics and Cadence and a one from Breker. While there is a considerable amount of common conceptual ground between the two proposals, there are some important conceptual (and practical) differences between the two. One point of agreement I see amongst the WG members is that to achieve the necessary level of abstraction and automation, the description of stimulus scenarios must be declarative. As shown in the picture below, the abstract model then gets processed by a tool(affectionately referred to as “secret sauce”) that produces the output for the desired target implementation of the test.

Both proposals rely on the idea of a graph to describe the scenarios. The Mentor-Cadence proposal uses a domain-specific language to specify the graph declaratively, as well as actions that represent the individual behaviors to be executed and resources, components and flow objects that describe the rules and constraints of the system under test that the “secret sauce” tool will use to generate the appropriate target implementation of the test. These concepts not only raise the level of abstraction of the test, but they also raise the level of randomization. Consider a system like:

Here we have a system that can receive data via either a USB port or a modem port. When data is received, it will be transferred to a video decoder which will decode the video. In an actual SoC, there would be a lot more going on, but we’ll keep it simple for now. Note that the only data transfer option from the USB port is a DMA transfer, which the Model port supports both DMA and mem copy. A simple graph specification in the Mentor-Cadence proposal would look something like this:

graph {

  select {

    { USB receive;

      DMA xfer; }

    { Modem receive;

      select {

        DMA xfer;

        mem copy;

      }

    }

  }

  Decode vid;

};

Each of the actions (the ovals in the diagram) represents a unit of behavior that will be implemented on the target platform. The implementations can be associated directly with the action as part of the model or imported from existing C/C++ code using a Direct Programming Interface (DPI). I’ll save a more detailed discussion for later, but there’s one other key point I’d like to make. The declarative specification is flexible enough to describe the actions and their relationships and data flow to allow the tool to infer whatever details are necessary to complete the scenario. For example, given that the system can only support a DMA transfer from the USB port, we could write a partial specification:

graph {

  USB receive;

  Decode vid;

};

In this scenario, the important behaviors we want to exercise are the USB receive action followed by the Decode vid action. By specifying these two actions, the other parts of the model tell the secret sauce tool that the only way to get data from the USB to the video decode is via a DMA Xfer action, so that action would be inferred. In fact, there could actually be multiple DMA transfers between the two actions, as long as that satisfied the rest of the system constraints specified in the model.

The flexibility of the partial specificaion made possible by the declarative language we’ve proposed makes it much easier to describe a set of possible scenarios and rely on the tool to choose the specific scenario and generate the output test for the target platform.

You’ll have many chances to learn more about Portable Stimulus at DAC this year. The PSWG is offering a tutorial on Monday: “How Portable Stimulus Addresses Key Verification, Test Reuse, and Portability Challenges.” You can register here. And I’ll be presenting “Get Ready for Portable Stimulus” in the Verification Academy Booth (#627) at 4pm on Tuesday. I’ll be going into much more detail about Portable Stimulus and will be happy to answer any questions you might have. Hope to see you there!