Although we had a very successful Portable Stimulus tutorial at DVCon US, there were still a couple of points of confusion that I’d like to take a moment to clear up.

Difference Between Standard and Tools

The first issue is apparently where we draw the line between what the Standard defines and what a tool is expected to do. As illustrated in this picture,

the Standard defines the syntax, concepts and semantics to define an abstract Portable Stimulus model, which represents your verification intent. That’s it. As we’ve discussed, the model can actually be a partial specification of your critical verification intent, and the semantics of the model define the solution space for scenario-level randomization to be applied to generate the myriad legal scenarios that conform to your specified intent given the available behaviors and operational constraints of the target platform.

As with most standards, Portable Stimulus is being created to allow you to write your verification intent model once, and allow it to be reused (i.e. “portable”) in many different , including across tools from multiple vendors. The reuse comes from the tools that will be used to process the model and create executable tests that implement the specified verification intent on a variety of platforms, including UVM simulations, architectural exploration, embedded processors (both simulation/emulation models and actual silicon) and any other environment that might be required. But it is important to understand that the standard does not require a particular tool to create a particular output. Just as with constraint solving in SystemVerilog, different tools are not required to come up with the same solution to a set of constraints, but they are required to come up with a legal solution. As with SystemVerilog tools, how well a given tool solves the set of constraints to achieve coverage or other goals will be a source of competition and innovation among tools.

The Choice of Input Language

The other issue I’d like to address is the choice of input language defined by the standard. The primary purpose of the Portable Stimulus Standard is to define a domain-specific language (DSL) that is declarative in nature to specify the verification intent. This requires a new way of thinking about the problem of stimulus and intent specification that truly does not fit in any existing language. In addition to the DSL, the Standard will also define a C++ input format that models the same semantics. Note that this does not mean that you can just arbitrary procedural C++ code to describe your verification intent. A standard C++ compiler won’t know what to do with it since a standard C++ compiler doesn’t understand the semantics of Portable Stimulus.

Rather, the C++ input format is a C++ library that defines a set of classes and related methods to mimic the constructs and semantics of the DSL. When the C++ Portable Stimulus model is compiled, it is linked against a library implementation (which is not itself part of the Standard – only the header files) that, when executed, will create the same data structures that the Portable Stimulus tool will use to generate the target implementation. The only advantage to a C++ user in using the C++ input format for Portable Stimulus is that the general syntax will be familiar. However, the C++ user will still need to learn what each of the classes and methods does, and how to use them. In effect, the C++ user will need to learn the new Portable Stimulus “language,” whether it is the DSL or the C++ library. The choice of which format to use will be determined by a variety of factors, including the user’s familiarity with a given language, but also including the general requirements of a company’s verification & tool flow, and the ecosystem with which they are familiar.

Conclusion

As with all standards, the key in developing the Portable Stimulus Standard will be in standardizing only as much as is required to allow users to describe portable verification intent models, and leave it to the tool developers to take it from there. By defining the precise semantics of a portable stimulus model, it will be possible for a single model to be written according to the standard that can be processed by a variety of Portable Stimulus tools, each of which will be able to generate a consistent and coherent implementation of the verification intent, whether for a UVM simulation environment, as C code to be compiled for a processor (or processor model), or any other desired target implementation. If there are multiple legal scenarios that conform to the specified constraints, each scenario can be generated individually as a separate “test.” Because the semantics of a portable stimulus model are declarative rather than procedural, users will have to think about the specification in a new way. Whether they will find the new DSL a better vehicle for expressing this intent or will prefer using the C++ class library input format will be left up to users. Just remember: If someone tells you that you can do Portable Stimulus just by knowing C++, don’t believe it.

For more details on the new Portable Stimulus standard, please check out our new Portable Stimulus Basics course on Verification Academy.