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 toolBigPicture(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!

Post Author

Posted May 26th, 2016, by

Post Tags

, ,

Post Comments

1 Comment

About Verification Horizons BLOG

This blog will provide an online forum to provide weekly updates on concepts, values, standards, methodologies and examples to assist with the understanding of what advanced functional verification technologies can do and how to most effectively apply them. We're looking forward to your comments and suggestions on the posts to make this a useful tool. Verification Horizons BLOG

@dennisbrophy tweets

  • @sricvc @mentor_graphics Srini, as a valued Quest Vanguard Partner I'll get someone to call or email and connect with you on this question.
  • Why Hardware Engineers Have to Think Like Cybercriminals, and Why Engineers Are Easy to Fool https://t.co/ZRVP3GGM6N
  • IEEE Securing the Pharmaceutical Supply Chain with Blockchain Webinar Replay and Slides https://t.co/0jJSKNm5i6

Follow dennisbrophy

@dave_59 tweets

  • I missed #btwd, but my son made it https://t.co/Q1Fh6do6wQ
  • RT @CynthiaArmour: Unicyclists, tandems, Freewheelers, bike 🐕, e-bikes and long distance riders- great time at Fremont BART station! Thx fo…
  • @sricvc @TudorTimi Extending a semaphore class is easy - coming up with an algorithm to implement what you want is not.

Follow dave_59

@jhupcey tweets

Follow jhupcey


One comment on this post | ↓ Add Your Own

Commented on June 1, 2016 at 12:01 am
By Semiconductor Engineering .:. Blog Review: June 1

[…] have probably heard a lot about Portable Stimulus recently. Mentor’s Tom Fitzpatrick talks about one proposal that the standards group is considering and the overlap between it and the […]

Add Your Comment