![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2017\/04\/PSSecretSauce.png\")
<\/a>the Standard defines the syntax, concepts and semantics to define an abstract Portable Stimulus model, which represents your verification intent. That\u2019s it. As we\u2019ve discussed<\/a>, 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.<\/p>\nAs 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. \u201cportable\u201d) 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<\/em> 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.<\/p>\n The other issue I\u2019d 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<\/em> 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<\/em> C++ code to describe your verification intent. A standard C++ compiler won\u2019t know what to do with it since a standard C++ compiler doesn\u2019t understand the semantics of Portable Stimulus.<\/p>\n 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<\/em> itself part of the Standard \u2013 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 \u201clanguage,\u201d 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\u2019s familiarity with a given language, but also including the general requirements of a company\u2019s verification & tool flow, and the ecosystem with which they are familiar.<\/p>\n 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 \u201ctest.\u201d 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\u2019t believe it.<\/p>\nThe Choice of Input Language<\/h1>\n
Conclusion<\/h1>\n