Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Advanced UVM
      • Basic UVM
      • Introduction to UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • Low Power Verification - 4/29
      • Fault Campaign for Mixed-Signal - 5/4
      • User2User - 5/26
      • Webinar Calendar
    • On-Demand Webinars

      • CDC+RDC Analysis
      • Basic Abstraction Techniques
      • Safety Analysis Techniques
      • QVIP Workflow and Debug for PCIe
      • Writing a Proxy-driven Testbench
      • Achieving High Defect Coverage
      • Visualizer Features
      • All On-Demand Webinars
    • Recording Archive

      • Siemens EDA 2021 Functional Verification Webinar Series
      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • Industry Data & Surveys
      • All Recordings
    • Conferences

      • DVCon 2021
      • DVCon 2020
      • DAC 2019
      • All Conferences
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - March 2021
      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa Basic
      • Questa Advanced
      • Mastering Questa
  • Home
  • Verification Horizons
  • March 2018
  • Make Your Constraints More Dynamic with Portable Stimulus

Make Your Constraints More Dynamic with Portable Stimulus

Verification Horizons - Tom Fitzpatrick, Editor

Make Your Constraints More Dynamic with Portable Stimulus Matthew Ballance - Mentor, A Siemens Business

INTRODUCTION

If you work in functional verification, you’ve likely become quite familiar with random constraints from functional verification languages such as SystemVerilog. Using a constraint solver to automate stimulus generation is key to quickly generating lots of stimulus that hits cases that weren’t envisioned by the test writer. When using constrained-random generation, constraints are the mechanism by which we customize what is legal and interesting in the stimulus space.

Accellera’s Portable Stimulus Standard (PSS) introduces some new constraint capabilities, in addition to supporting the capabilities that we’ve become familiar with in SystemVerilog. This article provides a guided tour of one of these new constraint features, along with examples that highlight their benefits.

CONSTRAINT FUNDAMENTALS

If you’ve used SystemVerilog, you’re likely very familiar with the constraint construct; random constraints declared within a class along with random fields. When an instance of the class is randomized, the constraints limit the available range of values.

Let’s say we are generating IPV4 traffic, and have a data structure that represents an IPV4 header. Figure 1 shows a SystemVerilog class and the corresponding PSS struct that we might use to represent this collection of random data.

Figure 1: IPV4 Header in SystemVerilog and PSS


Note that we also have a very basic constraint on the length field, since the total length of all packets must be at least 20 bytes. Also note just how similar the SystemVerilog and the PSS description of this IPV4 header is. So, if you can write SystemVerilog data structures and constraints, you can just as easily write PSS descriptions of data structures and constraints.

CUSTOMIZING RANDOMIZATION

In both SystemVerilog and PSS, we can customize pure-data randomization in a couple of ways. The simplest way, of course, is to add more constraints. We can add more constraints by declaring a new data structure that inherits from the base data structure and adds more constraints, as shown in Figure 2.

Figure 2: Small IPV4 Header Data Structure


Here again, both the constructs and syntax are remarkably similar between SystemVerilog and Accellera PSS.

Constraints can also be added ‘in-line’ when an instance of a data structure is randomized. When using a methodology such as UVM in SystemVerilog, randomization is likely to occur in a UVM sequence with the data structure instance subsequently being sent to the rest of the testbench. In a PSS model, actions roughly play the same role as a sequence, both selecting values for data structure fields and specifying what behavior in the environment should be performed.

In both cases, additional constraints can be added in-line with the call to randomize values of the data structure fields. Figure 3 shows a UVM sequence and a PSS action that create a series of small IPV4 headers by adding an in-line constraint.

Figure 3: Adding In-Line constraints


While in-line constraints are very handy, the fact that we’ve hard-coded values and relationships directly within the constraint blocks makes our SystemVerilog and PSS descriptions more brittle. What if my definition of a small header changes one day? I’ll need to find any place in my testbench where I’ve added a constraint like this and update it. What if I want to constrain another field temporarily any time a small packet is being created? Here again, I would need to make updates across my entire test description.

WHAT ARE DYNAMIC CONSTRAINTS?

PSS adds a new construct called a dynamic constraint that is remarkably helpful in addressing the limitations of hard-coded inline constraints. The data structure-level constraints that we’ve looked at thus far in both SystemVerilog and PSS are considered static. Specifically, once a constraint is declared in a class or struct it is applied every time an instance of the class is randomized. Accellera PSS supports static constraints inside struct and action types, but also introduces a new type of constraint: a dynamic constraint. A dynamic constraint is almost exactly the mirror image of a static constraint. While a static constraint always applies, a dynamic constraint only applies once the user activates it. Initially, this might seem like a fairly useless construct. It’s anything but!

In PSS, I might declare my IPV4 header struct anticipating that I would want to create some specific specializations of the struct. Figure 4 shows two dynamic constraints I might apply to enable creation of small headers and large headers.

Figure 4: PSS IPV4 Header Struct with Dynamic Constraints


Note that these two constraints conflict. However, because dynamic constraints don’t apply until the user activates them, that doesn’t create any problems.

We can use a dynamic constraint like any other constraint expression, including inside an inline constraint. Figure 5 shows an updated version of my create_small_ipv4_headers action that uses the new dynamic constraint.

Figure 5: Inline Randomization with a Dynamic Constraint


Simply by replacing a literal constraint (length <= 128) with a symbolic one (small_header_c) the code already conveys more of the author’s intent. This description is also less brittle. If we decide that a small header needs to be defined differently, we can simply update the original dynamic constraint definition, and all uses of that constraint will automatically use the new definition.

As you can start to see, dynamic constraints allow a constraint API to be developed such that test writers can symbolically constrain objects instead of directly referring to fields and constant values.

COMPOSING DYNAMIC CONSTRAINTS

Dynamic constraints provide value beyond just making code easier to understand and easier to update. Dynamic constraints are boolean constraints, which means we can use them in a conditional constraint. The value of a dynamic constraint is ‘true’ if it is applied and ‘false’ if not. This property of dynamic constraints allows us to compose more-interesting relationships.

What if we wanted to generate a series of headers that were either large or small? Using the knowledge that dynamic constraints are boolean constraints, we can state our intent quite simply, as shown in Figure 6.

Figure 6: Composing Inline Constraints with Dynamic Constraints


The use of dynamic constraints isn’t limited to inline constraint blocks. We also can use them inside the data structures along static constraints to encapsulate common constraints and make our constraints more modular and easier to understand.

Figure 7 shows an example of using dynamic constraints inside static constraints. For the purposes of this example, we have decided that, for our application, packets with immediate priority (DSCP level of CS1) must be less-equal to 256 bytes in size. Using dynamic constraints to associate a meaningful name with the constraint expression makes our code easier to read and maintain, just as it did in the case of inline constraints.

Figure 7: Using Dynamic Constraints Inside Static Constraints


USING VIRTUAL DYNAMIC CONSTRAINTS

Dynamic constraints, just like static constraints, are virtual. This means that we can change the meaning of a dynamic constraint (and, thus, the generated stimulus) using inheritance and factory-style type overrides.

What if we wanted to run a set of tests in which the definition of a small header is different from the default definition? Clearly it’s undesirable to actually modify the test scenarios themselves. Using dynamic constraints, and the fact that they are virtual, allows us to define a new struct where the definition of a small header is different, as shown in Figure 8.

Figure 8: Overriding a Dynamic Constraint


We create a new header struct that inherits from the existing ipv4_header struct and create a new definition of the small_header_c constraint. Just as with a static constraint, this version of the constraint will be used for all instances of the ipv4_header_larger_small_headers struct. But, how do we cause this struct to be used instead of the ipv4_header struct that is used in our test scenario (Figure 9).

Figure 9: Small Headers Scenario


Accellera PSS provides us with a very useful notion of ‘override’, which is effectively a UVM Factory built into the language. Just like the UVM Factory, the PSS override construct provides a way to replace instances of a given type with another derived type. The PSS type extension construct provides an easy way to inject these overrides without modifying the original scenario.

Figure 10 shows how type extension and the override construct are combined to cause the ipv4_header_larger_small_headers to be used by our create_small_ipv4_headers scenarios. This will cause our scenario to use the new definition of a small header without us needing to modify any code.

Figure 10: Injecting an Override Statement


USING DYNAMIC CONSTRAINTS WITH ACTIVITIES

Thus far, we’ve focused on applications for dynamic constraints that are fairly data-centric and restricted to a single data structure. These capabilities of dynamic constraints only increase when applied in the context of a PSS activity. If you’ve attended or watched one of the Accellera PSS tutorials, you’ve learned a bit about Activities. An activity is a declaratively-defined behavior that can be statically analyzed. An activity is closer to a set of random variables and constraints than it is to imperative code in SystemVerilog. Dynamic constraints effectively enable functional programming within an activity.

In SystemVerilog, we can only pass values between calls to randomize. For example, without a UVM sequence we could select a header size to be small, medium, or large, then constrain the packet size to this pre-selected size. However, the only way to pass forward the notion that a future header should be ‘small’ independent of a specific value is to add more variables to encode that intent. Dynamic constraints provide exactly this capability in Accellera PSS.

Figure 11 shows the use of dynamic constraints in an activity. In this case, the select statement chooses between sending four small-header packets and sending four large-header packets. Then, two normally-constrained headers are sent. We use dynamic constraints to easily control these two final headers based on the select branch taken. If we select the branch that sends the four small headers, we cause h1 to be sent with priority CS1 and cause h2 to be sent with priority CS2.

Figure 11: Using Dynamic Constraints in an Activity


CONCLUSION

As you’ve hopefully seen from the preceding article, dynamic constraints provide significant new capabilities above and beyond those provided by the constraints that we’ve become familiar with. Dynamic constraints are present in all versions of the Accellera Portable Stimulus Standard, and are supported by Mentor’s Questa® inFact portable stimulus tool.

Dynamic constraints are yet another example of how Accellera’s Portable Stimulus Standard is enabling greater abstraction and productivity in capturing test intent, in addition to enabling that test intent to easily be made portable across a variety of target platforms. If you’re interested in contributing to the evolution of features for productively capturing test intent, I’d encourage you to get involved with the Accellera Portable Stimulus Working Group!

Back to Top

Table of Contents

Verification Horizons Articles:

  • Achieving Your Team Goals Is Similar to Winning a Super Bowl Championship

  • Make Your Constraints More Dynamic with Portable Stimulus

  • Configuring Memory Read Completions Sent by PCIe® QVIP

  • SATA Specification 3.3 Gaps Filled by SATA QVIP

  • Part I: Power Aware Static Verification - From Power Intent to Microarchitectural Checks of Low-Power Designs

  • SVA Alternative for Complex Assertions

  • A Hierarchical and Configurable Strategy to Verify RISC-V based SoCs

Siemens Digital Industries Software

Siemens Digital Industries Software

##TodayMeetsTomorrow

Solutions

  • Cloud
  • Mendix
  • Siemens EDA
  • MindSphere
  • Siemens PLM
  • View all portfolio

Explore

  • Digital Journeys
  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Newsletter
  • Customer Stories

Contact Us

USA:

phone-office +1 800 547 3000

See our Worldwide Directory

  • Contact Us
  • Support Center
  • Give us Feedback
©2021 Siemens Digital Industries Software. All Rights Reserved.
Terms of Use Privacy Cookie Policy