Test Intent, Test Realization, and Separation of Concerns

Separation of concerns is a key computer-science design principle to ensure creation of modular programs. Quoting from Wikipedia, “A concern is a set of information that affects the code of a computer program… Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface”.

We’ve developed methodology in UVM that encourages separation of concerns when creating tests and verification environments as well. For example, good UVM methodology encourages separating description of the stimulus space (classes with constraints) from the code that implements the stimulus. This makes for a testbench environment that is modular and easy to control and customize.

Accellera’s emerging Portable Stimulus specification (PSS) seeks to raise the abstraction level for specifying test intent above what is currently possible in UVM, thereby making test creation far more productive. A key goal of the standard is to allow the same test intent to be retargeted to simulation, emulation, and prototype environments. Another is to enable users to work in terms of intent – what tests should be created – instead of focusing on the mechanics of how tests are implemented. These are ambitious goals and, to achieve them, Accellera’s PSS enforces a clear separation of concerns between test intent and test realization.

Describing Test Intent Declaratively

Accellera PSS uses a declarative specification for capturing test intent. In a declarative specification, relationships are bi-directional. If you’ve ever written SystemVerilog constraints, you’ve used a declarative specification. Accellera PSS extends this idea by allowing declarative descriptions of sequential and repetitive operations. Accellera PSS specifies both a domain-specific language (DSL) input format and a C++ class library input format. The domain-specific language provides language features tightly focused on capturing the semantics of the standard, while the C++ class library enables constructing a declarative description by creating C++ objects. Regardless of the input format, the standard defines a single set of declarative semantics.

Declarative descriptions are incredibly powerful when the criteria of interesting scenarios need to be concisely described, but have very different requirements than the requirements for general-purpose programming languages. For example, when requesting directions between two points on a map, you declaratively specify your origin and destination points. The available roads, traffic conditions, tolls and other options effectively serve as constraints to define the possible routes, but the specification of your intent is amazingly simple. Conversely, only someone looking for a significant intellectual challenge would attempt to write a general-purpose application, like a spreadsheet editor, using just a declarative description.

When it comes to specifying verification intent, declarative specifications make it easy to specify test spaces encompassing thousands or millions of possibilities. Because the relationships in a declarative description are bi-directional, it’s very easy to request a set of specific tests based on a specific pattern. For example: produce 20 tests where medium-sized chunks of data are transferred from either the Crypto engine or the PCIe endpoint to DDR. Because of this ability to ‘query’ a declarative description of test intent, I often think of a portable stimulus description as a test database.

Describing Test Realization Imperatively

Existing programming languages use an imperative style of description. Choices are made uni-directionally as the description executes sequentially, and there is no way to “reason backwards” from effect back to cause. These limitations don’t pose any problem, however, for code that manages interactions with the IPs being verified. If anything, using an imperative description to code up behavior that reads and writes IP registers and in-memory descriptors is far easier than trying to leverage a declarative description to do the same.

Connecting Declarative Test Intent to Imperative Test Realization

Because Accellera’s PSS focuses on improving the development of test intent, the majority of the description is declarative in nature. PSS provides specific regions of the description that are imperative, with well-defined semantics (an interface) for how they interact with the declarative portion of the description. In addition, PSS makes it very easy to leverage existing imperative descriptions written in existing programming languages, such as C/C++, SystemVerilog, etc. This separation of concerns is designed to maximize the productivity of capturing test intent, and maximize reuse of existing descriptions.

A Request for Help

Accellera released the Early Adopter draft of the Portable Test and Stimulus specification just before DAC this year, and opened a period of public review. Recently, Accellera extended the review period to the end of October to provide more time for users to review and provide input. So, please take advantage of this additional time to download the spec, review it with your test-intent needs in mind, and provide feedback. If you’d simply like to discuss your test-intent needs, and how they are addressed by Accellera PSS, with one of Mentor’s portable stimulus experts, please contact us at portable_stimulus@verificationacademy.com.