The nuts and bolts of verification: Recasting SystemVerilog for Portable Stimulus

by Matthew Ballance, Mentor, a Siemens Business

Nuts and bolts. So prosaic, yet so fundamental and essential. They can be reused, mixed-and-matched in endless ways. All those old jars and tins full of leftover nuts, bolts, and screws have saved many trips to the hardware store.

Yet, if not for standardized gauge, thread count, and head type, reusing these basic fasteners wouldn’t be so convenient or even possible. Happily, standardization means we can reuse what we have on hand to quickly make “something” come together.

In these ways, the Accellera Portable Stimulus Specification (PSS) standard could be said to provide the nuts and bolts of functional verification.

As you already know if you’ve read the first two articles in this series, Retargeting existing tests in an integrated SoC verification flow and How to create and run reusable register-test models, the Portable Stimulus Specification is all about reusing commonly-used test atoms to create new scenarios more quickly. It saves us from wasting precious time recreating the same test information to verify the same functions throughout a single or multiple projects. And because the specification was developed to align with SystemVerilog constructs and principles, we can even extract data structures and constraints from our existing SystemVerilog environments to quickly build our stockpile of reusable test atoms.

Identifying existing formats and information within your organization that can be leveraged to create portable stimulus models flattens the adoption curve and boosts test-creation productivity. Universal Verification Methodology (UVM) register model descriptions and SystemVerilog classes and constraints are two sources of verification information you already have in-house.

In our first two articles, we showed you how to utilize UVM register models to jump-start the creation of portable stimulus models. In the final two articles, we will see which SystemVerilog constructs are most easily reused in a Portable Stimulus Specification, and we will provide coding guidelines to make reuse simple and reliable.

But first, let’s quickly review the nature and goals of the Portable Stimulus Specification.

Making tests more reusable

Reuse is a pretty broad term that covers a wide variety of workflows. Reuse of a description can be as simple (and low-tech) as hand re-implementation of an algorithm, originally implemented in one language, in a different language. Clearly, there is value in leveraging the original author’s thought process, but this is hardly an automatable process.

Design and verification have historically been driven by domain-specific languages, and reuse in verification has been a goal as long as verification has existed as a unique discipline. Reuse of a test description within the same language or methodology has long benefited from well-established guidelines. However, these guidelines do not exist for reusing a description across languages. The Accellera standardization effort around the Portable Stimulus Specification standard and the existence in the industry of portable stimulus tools that can re-target an abstract test specification to multiple environments provide a driver for the creation of such guidelines.

The Portable Stimulus Specification is fundamentally a declarative language that includes data structures, constraints, coverage-specification features, and graphs — a formally-analyzable specification of the test procedure. The larger purpose of the Portable Stimulus Specification standard, as summarized by Figure 1, is to enable multiple users and projects to use and reuse the same specification of test stimulus, expected results, and coverage goals across a variety of platforms, including simulation, emulation, and prototype.

Languages, such as SystemVerilog, and methodologies, such as the UVM, have greatly helped automation and reuse in transaction-oriented simulation and accelerated-simulation verification environments. Bringing test-creation automation and reuse to an even broader set of environments and execution platforms is a goal of the Portable Stimulus Specification standard.

SystemVerilog to PSS reuse flow

When it comes to reuse of SystemVerilog content in a Portable Stimulus Specification description, a high degree of automation is key. The source SystemVerilog description is fluid and will change over the lifetime of the project. Requiring a human to identify modifications to the relevant SystemVerilog source and update the Portable Stimulus Specification representation is labor-intensive, as well as being error-prone.

A typical SystemVerilog-to-Portable Stimulus Specification reuse diagram looks something like Figure 2. The primary source for shared data structures and constraints on those data structures is maintained in SystemVerilog. PSS representations of those data structures and constraints are derived directly and automatically from the SystemVerilog representation. This generated Portable Stimulus Specification description is then leveraged in user-created Portable Stimulus Specification descriptions.

Of course, an alternative reuse flow would be to declare all shared data structures and constraints on those data structures in the Portable Stimulus Specification language and automatically derive SystemVerilog representations, as shown in Figure 3. As the emerging Portable Stimulus Specification standard achieves greater industry acceptance and adoption, this flow should become more typical. However, at the moment and for the foreseeable future, there is much more content written in SystemVerilog that can usefully be leveraged as part of a Portable Stimulus Specification description.

Given that the bulk of verification today is done using SystemVerilog, it makes sense to find what elements of your existing SystemVerilog descriptions can be easily and reliably reused in a Portable Stimulus Specification description. With its nuts and bolts approach, the Portable Stimulus Specification promises to be the next great leap forward in verification productivity for increasingly complex SoCs.

In our next EE World article, we will provide lots of coding examples to walk you through how to restructure SystemVerilog for reuse.

 

Resources:

New School Stimulus Generation Techniques

Verification Academy Portable Test and Stimulus page

Matthew Ballance is a Product Engineer and Portable Stimulus Technologist at Mentor Graphics, working with the Questa inFact Portable Stimulus product. Over the past 20 years in the EDA industry, he has worked in product development, marketing, and management roles in the areas of HW/SW co-verification, transaction-level modeling, and IP encapsulation and reuse. Matthew is a graduate of Oregon State University.