mentorgraphics

by Matthew Ballance, Mentor, a Siemens Business

In our previous article, The Nuts and Bolts of Verification: Recasting SystemVerilog for Portable Stimulus, we described how verification teams can jumpstart portable stimulus test description creation using existing SystemVerilog constructs and principles. Now, switching from analogy to idiom, we’ll dive into the “nuts and bolts” of how to restructure SystemVerilog for reuse.

Specifically, we will share basic practical concepts and coding guidelines that make SystemVerilog classes, constraints, and covergroups more amenable to automated reuse in a Portable Stimulus Specification (PSS) description. Because so much content has already been created in SystemVerilog, leveraging portions of SystemVerilog-based descriptions you already have in-house will accelerate creation of PSS descriptions, delivering immediate productivity benefits.

The guidelines for structuring SystemVerilog for reuse presented in this article reflect a preference for a fully-automated flow to reuse information captured and reflect best practices that evolved from the experience of users of the Questa inFact Portable Test tool from Mentor Graphics.

Focus on the constructs

SystemVerilog is a fully-featured language for register-transfer level (RTL) design and verification. As such, it includes constructs inherited from the Verilog language for describing hardware constructs. It also includes object-oriented programming constructs, and constructs for automated stimulus generation and functional coverage collection, that are used for verification of a hardware description.

The PSS language is predominantly a declarative language, with a few procedural constructs. In contrast, SystemVerilog is predominantly a procedural language with a few declarative constructs.

As a consequence of the declarative nature of PSS, the declarative constructs in a SystemVerilog description are easiest to reuse as part of a PSS description: specifically, data structures and constraints on the fields of those data structures, as well as covergroups, used to model functional coverage goals. In general, design patterns that negatively impact reuse of SystemVerilog descriptions are ones that blend procedural and declarative description, or impact encapsulation of a declarative description.

In most cases, the best practices that enable reuse are also simply good SystemVerilog coding practices that result in well-encapsulated code. Of course, there are cases where it is pragmatic or necessary to use constructs and patterns that limit reuse. Even with these cases, a little foresight can maintain a sensible balance between reusable constructs and pragmatic design patterns.

The goal in structuring SystemVerilog for reuse is to create self-contained elements that can be extracted from the SystemVerilog description and added to the PSS description. We will now take a detailed look at some of these elements individually to see how this can be done.

Inline randomization constraints

SystemVerilog allows inline constraints to be specified when an object is randomized. This can be a handy way to customize random transactions to create directed-random test sequences. Figure 1 shows a directed-random test that leverages an existing transaction class and inline constraints to perform a series of reads and writes.

While the use of this design pattern in a SystemVerilog testbench can be very useful, it does limit reuse. The in-line constraints are introduced in a procedural block and often will include references to variables within that procedural block. Consequently, reusing these inline constraints is difficult if not impossible.

Inline constraints can also be abused, of course. The author has worked with testbench environments where up to a hundred lines of inline constraints were specified simply to ensure valid relationships between class fields. Worse, these large blocks of inline constraints were copied across multiple tests resulting in a maintenance headache when these base constraints needed to be adjusted.

You can increase code maintainability and reuse by factoring common constraints out of inline constraint blocks. Figure 2 shows how the read/write inline constraint is factored out by creating a read transaction and a write transaction class. This increases test readability and maintainability, and provides more specific elements that can be reused in a PSS description.

Dynamic enabling/disabling of constraint blocks

Another interaction between SystemVerilog procedural code and declarative constraints is support for dynamically enabling and disabling constraint blocks. Under ideal circumstances, dynamically disabling constraints is used in very limited cases to do things such as enabling generation of illegal transactions. A highly-problematic use of dynamic constraint-block control is where at least one block must be disabled in order for randomization to complete successfully. Figure 3 shows an operation sequence-item class that specifies two conflicting constraints – one that sets “normal” operating modes, and another that sets “extended” operating modes. The user of this class must know to disable at least one of the normal_mode_c or ext_mode_c constraints prior to randomizing the object.

From a reuse perspective, the use of dynamically-controlled constraints presents two challenges. The current PSS language doesn’t provide facilities for dynamically controlling constraints. So, at a minimum, additional changes will be required in the PSS description to adapt the description imported from SystemVerilog. In addition, the use of conflicting constraints presents a usability challenge in both SystemVerilog and PSS descriptions. Valid combinations of enabled/disabled constraint blocks must be documented somewhere. At best, the valid enabled/disabled constraint blocks will be captured as a comment which will likely not propagate to the PSS description. At worst, the valid combinations of enabled/disabled constraint blocks are “tribal knowledge” captured in working test sequences.

Using class hierarchy and constraint overloading instead of dynamic constraint enable/disable results in SystemVerilog sequence items that are easier to use, and a SystemVerilog description that is easy to reuse as part of a PSS. There are two equivalent approaches to structuring a class hierarchy to handle cases often implemented using dynamic constraint enable/disable. The first approach, additive constraint refactoring, is shown in Figure 4. Using this approach, derived classes add in just the constraints needed to achieve their intended purpose. So, the normal_op_item class adds constraints to ensure that only “normal” modes are produced, while the ext_op_item class adds constraints to ensure that only “extended” modes are produced. This approach is a good general approach.

The second approach, subtractive constraint refactoring, is more often used to create exceptional use cases, such as error injection. Taking the example used thus far, let’s assume that “normal” modes are the ones used the majority of the time.

Figure 5 shows the definition of the normal_op_item class with constraints that enforce ‘normal’ operation. In order to create the ‘exceptional’ condition that could be created by disabling the ‘normal_mode_c’ constraint, the ext_op_item class overrides the normal_mode_c constraint with an empty constraint – effectively disabling this constraint in a declarative way.

Using class hierarchy and constraint refactoring results in more-reusable classes in SystemVerilog environments. It also results in SystemVerilog descriptions that are reusable in a PSS description by moving controls from procedural description into the declarative portion of the description.

References to global data

Referring to global data items outside the class presents a challenge for reuse – both in SystemVerilog and in a PSS description. Figure 6 shows such a case, where the coefficient field in the transform_item class is bounded by a global min and max field in the global_data_pkg package.

This has its convenient aspects, of course, in allowing the coefficient bounds to be set once per testbench environment. The downside is that this makes reuse more challenging. Perhaps the coefficient bounds were global in the original testbench environment, but this may not always be the case. Perhaps in the next testbench environment there will be two UVM agents that use the transform_item class. Each of these agents may need to use different bounds for the coefficient.

Figure 7 shows an approach to removing global data references by creating fields inside the class. The procedural SystemVerilog code that randomizes the refactored transform_item class will need to set the coeff_min and coeff_max prior to randomizing the class. However, the refactored code results in a class that is self-contained and easier to reuse. A self-contained class is also much more reusable within a PSS, since there are no references to external entities.

Reusable functional coverage

SystemVerilog covergroups provide an exceptionally flexible construct for monitoring and aggregating testbench data. However, the exceptional flexibility of the construct impacts its reusability.

Figure 8 shows a SystemVerilog covergroup structured in a way that is ideal for reuse in a PSS description. All the coverpoints and cross-coverpoints reference the config_item class field item that specified as a parameter to the covergroup. This ensures that the covergroup is self-contained. In addition, the class monitored by the covergroup is the same class used for generating stimulus. This allows configurations to be generated that efficiently satisfy the coverage goals without the user providing additional directives to relate the stimulus-generation class to the class used to capture coverage data.

Conclusion

The PSS standard allows a single representation of test stimulus, expected results, and coverage goals to be captured in a description that can be reused across test environments from UVM to software-driven test environments.

Using the best practices for modularity and reuse described above helps enable reuse across SystemVerilog environments and PSS descriptions. To summarize, these best practices are:

1. Avoid use of inline constraints.
2. Avoid enabling and disabling constraints from procedural code.
3. Avoid referencing class-external variables from constraints
4. Structure functional coverage descriptions to explicitly reference a single class, ideally a stimulus-generation class

Reusing the wealth of existing SystemVerilog descriptions, such as transactions and device configuration classes, allows users to more-quickly take advantage of the benefits of Portable Stimulus tools such as efficient closure on test goals and automated creation of C tests.

Many users of the Questa inFact portable stimulus tool have already taken advantage of this reuse path by using the tool’s SystemVerilog import capability to import existing configuration classes and jump-start creation of portable stimulus models.

This concludes our four-part series on how to use existing UVM and SystemVerilog descriptions to accelerate the creation of portable stimulus models. If you haven’t already, see the previous EE World articles to learn more about how you can catapult your verification effort into a higher level of productivity and reuse.

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.

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.