Inside Portable Stimulus: Filling in the Blanks

A Portable Stimulus tool can do much of the work and allow many tests to be created based on the defined verification objectives.

For those who want all the answers now, Accellera recorded this DVCon training session that goes over the basics of the language and how tools work. I use many of the same examples for continuity purposes, but I will present the material in a different manner.

The Accellera tutorial starts off by defining the syntax of the language. I will concentrate on the abstract notions first and then get into syntax later. You will also read new or unfamiliar terms being thrown around such as declarative, partial specification, inference. I will get to all of that in due course; just don’t worry about the terms to start off with.

Portable Stimulus enables you to quickly and easily specify scenarios that should be tested. Today, the only way to do this is to carefully craft directed tests. This probably involves writing software to run on the processors within the design coupled with something to coordinate activities on the external ports of the design. This all becomes simpler with Portable Stimulus because:

• It does a lot of the grunt work for you.
• It allows you to specify the important aspects of the scenario that you want to run and have the tool fill in the blanks.
• It allows you to re-target that test to one of many execution platforms.

In this blog, I will look at how a tool fills in the blanks.

Let’s assume that you want to run a test that executes action “b” followed by either action “c” or action “f.” Examples of actions could be to input a packet from a port, to perform an operation within a direct memory access (DMA), or to execute an encode or decode function. Basically, an action is a fundamental capability within a design. The tool will look at the complete Portable Stimulus model to find out how to make that happen. For this example, a bunch of primitive tasks are defined along with the data that they produce and consume. These are shown in Figure 1.

As we see, action “a” has no inputs and produces data in a buffer. A buffer implies a sequential operation. The action produces a buffer full of data and something consumes it. Action “b” takes in data from a buffer and outputs data to a buffer. Action “c” has a data stream as its input and produces no output. A stream means that something has to produce the data at the same time that it is being consumed and, thus, implies a concurrent operation. You get the idea.

Earlier, I stated that I wanted a test that had “b” followed by “c” or “f,” and you can see from Figure 1 that “b” requires input data from a buffer. Actions “a,” “b,” “e,” “g,” and “p” are capable of producing this data, and a tool could randomly select one of these to produce the data for “b.” If the tool chose “a,” “g,” or “p,” it satisfied the ability to make “b” happen, and these would be executed before “b” is executed. If it chose action “b” to produce the data for “b,” then it iterates again until it satisfied the need. It could have chosen “e,” which produces a buffer of data out and requires a stream to feed it. That stream could come from actions “d” or “j.” If “e” was selected, then it would select either “d” or “j” to run concurrently with “e.”

Once a tool has chosen what happens before “b.” it then needs to randomly decide if it will execute “c” or “f,” and each of those need to be resolved. Action “c” takes no input and it would mean that the buffer produced by “b” would be thrown away. This may be OK, or there could be constraints that stop this from happening. While “b” produces a buffer that could be consumed by “f,” it does not mean that other tasks cannot be run in between.

The tool may adjust its decisions based on other factors, such as how long a test is required, if one action is more important than others, and whether some actions have already been well-represented by other tests. Another thing that may limit the choices that a tool can make is resource conflicts. I did not define them at this level, but it is possible for each action to request a shared resource. If that resource is being consumed, then some of the other actions may be prohibited from being selected.

At the end of the process, the tool has produced a scenario that fits the initial intent. I could ask it to produce 20 or 30 variants, or I could provide another partial requirement for the scenario. It is also possible that I haven’t yet finished writing the model and — in the future — more possible actions will become available. It is not necessary for the entire verification model to be constructed ahead of time. As long as the tool can find one way to satisfy the scenario request, I can start testing.

Hopefully, this blog made clear what a partial specification means and how a Portable Stimulus tool can do much of the work and allow many tests to be created based on the defined verification objectives. From a simple request made to a tool, multiple scenarios can be created.

You may think that this sounds a lot like data/control flow diagrams, and you would be right. Within Breker’s tools, we allow you to create models using graphical input to specify both the dataflow and control aspects of tests. A simple example is shown in Figure 3.

In future columns, I will discuss how each of these actions are defined, how the dataflow is defined, how constraints can be placed on them, how resources are used, and more. In the meantime, I welcome your comments, and please feel free to ask questions if anything that I’ve said is not clear.

Note: Breker CEO Adnan Hamid previously wrote about the newly released Portable Stimulus Standard from Accellera and discussed what it is and the types of verification methodology that it will support. Learning how to use Portable Stimulus and what it is capable of doing will take a few more blogs, and that responsibility has been transferred to Leigh Brady, Breker’s verification architect. Leigh was part of the team that created Verilog-XL, worked to put Verilog into the public domain, and participated in several subcommittees responsible for extending the language. Later, she worked on SuperLog, which transformed into SystemVerilog, and she is now an active participant on the Portable Stimulus committee.