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 IQ
      • Verification IP
      • Static-Based Techniques
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • 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)

      • Introduction to UVM
      • UVM Basics
      • Advanced 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.
    • Featured & On-Demand

      • Continuous Integration - March 28th
      • SystemVerilog Assertions
      • SoC Design & Functional Safety Flow
      • 2022 Functional Verification Study
      • Design Solutions as a Sleep Aid
      • CDC and RDC Assist
      • Formal and the Next Normal
      • Protocol and Memory Interface Verification
      • Webinar Calendar
    • On-Demand Library

      • Practical Flows for Continuous Integration
      • Lint vs Formal AutoCheck
      • The Three Pillars of Intent-Focused Insight
      • Formal Verification Made Easy
      • Fix FPGA Failures Faster
      • HPC Protocols & Memories
      • FPGA Design Challenges
      • High Defect Coverage
      • The Dog ate my RTL
      • Questa Lint & CDC
      • Complex Safety Architectures
      • Data Independence and Non-Determinism
      • Hierarchical CDC+RDC
      • All On-Demand Recordings
    • Recording Archive

      • Aerospace & Defense Tech Day
      • Exhaustive Scoreboarding
      • Improving Initial RTL Quality
      • CDC Philosophy
      • Hardware Emulation Productivity
      • Visualizer Debug Environment
      • Preparing for PCIe 6.0: Parts I & II
      • Automotive Functional Safety Forum
      • Siemens EDA Functional Verification
      • Improving Your SystemVerilog & UVM Skills
      • All Webinar Topics
    • Conferences & WRG

      • Industry Data & Surveys
      • DVCon 2023
      • DVCon 2022
      • DVCon 2021
      • Osmosis 2022
      • All Conferences
    • Siemens EDA Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • EDA Xcelerator Academy(Learning Services) Verification Training, Badging and Certification
      • 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 IQ
      • Verification Horizons Blog
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - March 2023
      • Verification Horizons - December 2022
      • Verification Horizons - July 2022
      • Issue Archive
    • About Us

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

      • Learning @OneGlance (PDF)
      • SystemVerilog & UVM Classes
      • Siemens EDA Classes
  • Home
  • Patterns Library
  • Implementation Patterns

Implementation Patterns

Implementation Patterns provide solutions to the construction problem for various verification infrastructures. Since the construction of contemporary testbenches are essentially large software projects, which utilize object-oriented features found in SystemVerilog and UVM, a lot of the prior work in software patterns is applicable to verification Implementation Patterns.

The Implementation Patterns in our library are organized into the following three subcategories, as illustrated in the previous figure: Environment, Stimulus, and Analysis. The Environment patterns are those that are used in testbench architecture, construction, configuration, and communication/synchronization. These patterns are the ones that capture the structural and behavior aspects of the core verification environment model. Stimulus patterns capture the behavior, strategy, and types of stimulus. Similarly, Analysis patterns are used to capture the behavior, strategy, and types of response checking and coverage. For reuse, analysis and stimulus have no interaction or interdependency. The environment (testbench) includes infrastructure, interconnect, resource sharing, synchronization, and so on. As such, it touches both analysis and stimulus. It is the structure in which both analysis and stimulus reside and operate.

To learn more about the details of the Verification Academy Patterns Library and Implementation Patterns, View | Download Verification Patterns—Taking Reuse to the Next Level our paper, Verification Patterns—Taking Reuse to the Next Level.

Environment Patterns:

  • BFM-Proxy Pair Pattern
  • Component Configuration Pattern
  • Dual Domain Hierarchy Pattern
  • Environment Layering Pattern
  • Façade Pattern
  • Parameterized UVM Tests Pattern
  • Resource Sharing Pattern
  • SW-HW Pipe Pattern
  • Utility Pattern

Stimulus Patterns:

  • Layering Sequence Pattern
  • Strategy Pattern

Analysis Patterns:

  • BFM Notification Pattern
  • Walking Pattern

 

Environment Patterns

  • Parameterized UVM Tests Pattern
  • BFM-Proxy Pair Pattern
  • Dual Domain Hierarchy Pattern
  • Façade Pattern
  • Utility Pattern
  • Component Configuration Pattern
  • Environment Layering Pattern
  • Resource Sharing Pattern
  • SW-HW Pipe Pattern

Parameterized UVM Tests Pattern

Intent:

Parameters used in a design in most cases must also be used in a testbench to ensure proper connections and communication can be performed. Parameterized UVM tests (which are not available by default) provide an easy mechanism for sharing of parameters.

Motivation:

Engineers create parameterized design IP so it can be verified once and then reused in multiple contexts. The parameters used in this IP can control design elements such as bus widths, generate statements to control if specific logic is available or not, etc. To verify the parameterized IP, the testbench must also have access to the parameters and knowledge of the values assigned to those parameters. With UVM being a hierarchical collection of objects with the test being the top level, why not just pass the same parameters to both the design and the UVM testbench. This will simplify the exploration of multiple parameter configurations and allow for verification of the full parameter state space.

Applicability:

This pattern is useful in cases where a design is parameterized and the full or at least multiple values of the parameter state space must be verified.

To view the entire Parameterized UVM Tests Pattern , please login with your Verification Academy Full Access account.

BFM-Proxy Pair Pattern

Intent:

The BFM-Proxy Pair Pattern is an Environment Pattern to facilitate the design of transactors like drivers and monitors for dual domain partitioned testbenches that can be used for both simulation and emulation, and across verification engines (or platforms) in general.

Motivation:

In order to enable and promote a verification process that is abstracted from underlying verification engines, particularly a software simulator and a hardware emulator, modern testbenches should exhibit (from conception) a dual domain architecture with partitioned HVL and HDL module hierarchies targeted for the simulator and emulator, respectively, and linked together to run in unison. Fundamental to this architecture is the employment of BFM-proxy pairs to devise so-called split transactors, where components in the HVL domain typically implemented as classes act as proxies to BFMs implemented as interfaces or modules in the (synthesizable) HDL domain. An HVL proxy provides a surrogate or placeholder for the associated cross-domain HDL BFM to control access to it via a transaction-based HVL-HDL communication model using remote function and task calls. Effectively, the proxy embodies the transactor API to upper testbench layers, abstracting the cross-domain communication and the implementation details of the BFM’s bus cycle state machines.

Applicability:

The BFM-Proxy Pair Pattern is applicable in any situation demanding a common dual domain partitioned testbench architecture (i.e., separated HVL and HDL module hierarchies) for both simulation and emulation, and across verification engines
in general.

To view the entire BFM-Proxy Pair Pattern , please login with your Verification Academy Full Access account.

Dual Domain Hierarchy Pattern

Intent:

The Dual Domain Hierarchy Pattern is an Environment Pattern to facilitate the design of testbenches that can be used for simulation as well as emulation, and across verification engines (or platforms) in general.

Motivation:

In order to enable and promote a verification process that is abstracted from underlying verification engines, particularly a software simulator and a hardware emulator, modern testbenches should be partitioned into two separated modeling domains, with different requirements, linked together to run in unison via transaction-level cross-domain data exchange. This is achieved by a dual domain testbench architecture with partitioned HVL and HDL module hierarchies, communicating through cross-domain function and task calls. The HDL domain is a synthesizable model to be compiled and run on the emulator (or other platform). It contains essentially everything that interacts directly with the RTL DUT or otherwise operates at the signal- level, namely the RTL DUT, clock and reset generators, and the various bus cycle state machines for driving and sampling DUT interface signals. The HVL domain is generally an untimed model with no explicit time advance references. It consists of non-synthesizable behavioral and object-oriented testbench code, including typically the various transaction-level stimulus and analysis components. Only transaction-based message passing can be performed between the two domains using “remote procedure invocations” in the form of function and task calls (i.e. cross-domain variable and signal references are not permitted).

Applicability:

The Dual Domain Hierarchy Pattern is applicable in any situation demanding a testbench with a common architecture for both simulation and emulation, and across verification engines in general.

To view the entire Dual Domain Hierarchy Pattern , please login with your Verification Academy Full Access account.

Façade Pattern

Intent:

A façade pattern provides a simple interface to a complex system, making it easier for the client or external world to use.

Motivation:

In UVM world, if we have to send sequences across different agents in a coordinated manner the top level sequence would need to refer to multiple agents.

Applicability:

Façade Pattern which is a Gang of Four’s structural pattern helps solve the problem of providing a simple interface to a complex system. It can provide an entry point to multiple environments from the top level.

To view the entire Façade Pattern , please login with your Verification Academy Full Access account.

Utility Pattern

Intent:

Encapsulate small, useful functionality in a portable, easy-to-use object.

Motivation:

In many cases a full verification component such as a UVM agent has more code and functionality than is required to perform a task. A small portable object derived from uvm_object or a standalone SystemVerilog package is sufficient in many cases.

Applicability:

The utility pattern is useful for encapsulating small, focused functionality.

To view the entire Utility Pattern , please login with your Verification Academy Full Access account.

Component Configuration Pattern

Intent:

The Component Configuration Pattern is used to create a coherent configuration structure for the component hierarchy from top to bottom. It promotes self-containment and data-hiding techniques in the configuration and creation of component hierarchy.

Motivation:

When building hierarchical simulation environments lower level components need to be configured in a way that is consistent with upper level configurations and randomizations. For example, interface agents need to be configured to be consistent with DUT operating mode selected in an encapsulating block, subsystem or chip level environment. The Component Configuration Pattern provides information about the encapsulating component without requiring knowledge of the encapsulated components structure.

Applicability:

The Component Configuration Pattern can be used when performing vertical reuse of components within other components.

To view the entire Component Configuration Pattern , please login with your Verification Academy Full Access account.

Environment Layering Pattern

Intent:

The Environment Layering Pattern is used to provide consistent configuration and structure for vertical reuse of environments.

Motivation:

Block level environments are used to test specific scenarios and close coverage. Subsystem and chip level environments are used to test integration and traffic patterns. Reusing block environments within subsystem environment and subsystem environments within chip environments leverages existing bug identification, analysis and coverage in upper level simulations. The Environment Layering Pattern can be used to provide consistent component encapsulation.

Applicability:

The Environment Layering Pattern can be used when performing vertical reuse of components within other components.

To view the entire Environment Layering Pattern , please login with your Verification Academy Full Access account.

Resource Sharing Pattern

Intent:

The Resource Sharing Pattern is used to share resources between objects without requiring detailed knowledge of the resource. Related resources share common access attributes thereby creating simple associations.

Motivation:

A hierarchical simulation environment contains resources required by other components as well as test writers. A consistent mechanism for sharing resources promotes horizontal and vertical reuse. A simple mechanism that requires no knowledge of the simulation environment hierarchy eases the task of test and stimulus creation.

Applicability:

The Resource Sharing Pattern can be used when reusing verification components. It can also be used to reduce the overhead of adding test writers to a project.

To view the entire Resource Sharing Pattern , please login with your Verification Academy Full Access account.

SW-HW Pipe Pattern

Intent:

The SW-HW Pipe Pattern is an implementation pattern that provides a buffered one-way communication channel between separated HVL and HDL module hierarchies in a dual-domain partitioned testbench. Writing to and reading from the pipe can be done at any rate. Writes block if the pipe is full. Data written to an empty pipe is available for reading on the next clock cycle. Reading from an empty pipe has a well-defined behavior.

Motivation:

Implementing an efficient driver in a dual-domain testbench with partitioned HVL and HDL module hierarchies targeted for the simulator and emulator can be problematic as the nature of a driver in a reactive testbench dictates that the UVM driver is not always able to provide data in advance, or provide any data at all. At the same time, the testbench should be able to react to events in the DUT with little delay. In order to facilitate optimization of the HVL-HDL (or inbound) cross-domain communication channel, it should be implemented using one-way, non-blocking function calls. However, the generally unpredictable rates of writing to, and reading from, the channel requires a return path for the implicit state (i.e. the buffer fill level) of the channel. A return HDL-HVL (or outbound) call must be decoupled from its corresponding forward HVL-HDL call to enable optimization of the latter in environments that support it. The frequency of return path calls is reduced in proportion to the size of the buffer.

Applicability:

The SW-HW Pipe Pattern is applicable in any situation that requires reactive one-way transfer of data between separated HVL and HDL domains in a common dual-domain testbench context. The pattern is pertinent especially if the transfer is part of a reactive loop of the testbench.

To view the entire SW-HW Pipe Pattern , please login with your Verification Academy Full Access account.

Stimulus Patterns

  • Layering Sequence Pattern
  • Strategy Pattern

Layering Sequence Pattern

Intent:

To be able to select and execute one of several sequences at will.

Motivation:

Often it is convenient to generate data using one virtual or abstract representation that needs to go through a transformation process before it can be applied to a concrete interface. In other stimulus generation scenarios it may be necessary to map or combine several virtual data streams into a single data stream.

Applicability:

The layering sequence pattern is applicable to any situation where sequences are available that use one sequence_item but must transformed to another sequence_item to be executed on a target sequencer. An example of this would be converting a uvm_tlm_generic_payload item to a bus specific sequence_item.

To view the entire Layering Sequence Pattern , please login with your Verification Academy Full Access account.

Strategy Pattern

Intent:

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Motivation:

When multiple behaviors are needed in a class, we typically use multiple conditional statements in its operations. Instead of many conditionals, move relates conditional behaviors into their own Strategy class.

Applicability:

This pattern helps implement one of the basic principles of Object Oriented programming, i.e. Open Close Principle. This principle states classes should be open for extension but closed for modification. It implies “change” what the modules do without changing them.

To view the entire Strategy Pattern , please login with your Verification Academy Full Access account.

Analysis Patterns

  • BFM Notification Pattern
  • Walking Pattern

BFM Notification Pattern

Intent:

The BFM Notification Pattern is an Analysis Pattern to facilitate the design of transactors for dual domain partitioned testbenches that provide effective and efficient notifications of protocol transaction occurrences, and any other interesting protocol and design events and conditions, for testbench control and analysis.

Motivation:

In accordance with the established analysis connection topology of a modern testbench, and for optimal performance in a dual domain testbench with partitioned HVL and HDL module hierarchies, HDL BFM interfaces or modules should autonomously observe protocol transactions, and any signal-level protocol and design events and conditions, and push out corresponding notifications (interrupt occurred, reset asserted, transaction completed, etc.) to their respective HVL class proxies where these notifications can be further broadcasted to the upper testbench layers, for instance using standard TLM-based communication semantics. This is in contrast with the upper testbench layers initiating such monitoring activity, through the proxies, by polling for transactions, or signal or state changes, which is unnatural and generally inefficient.

Applicability:

The BFM Notification Pattern is applicable in any situation demanding a common dual domain partitioned testbench architecture (i.e., separated HVL and HDL module hierarchies) for both simulation and emulation, and across verification engines in general.

To view the entire BFM Notification Pattern , please login with your Verification Academy Full Access account.

Walking Pattern

Intent:

To effectively verify connectivity between various modules such as Address and Data bus.

Motivation:

We typically keen on looking at toggle coverage of address and data bus connection at SoC level, as the key effort in Verification at SoC level is focused on integration. We would also be interested in collecting one-hot or one-cold encoding coverage.

Applicability:

This pattern will be applicable for anyone focused on integration verification. These are very commonly patterns used in stimulus and verification of RAM address and bus connectivity. This pattern can be used as Stimulus Pattern and an Analysis Pattern.

To view the entire Walking Pattern , please login with your Verification Academy Full Access account.

Siemens Digital Industries Software

Siemens Digital Industries Software

#TodayMeetsTomorrow

Portfolio

  • Cloud
  • Mendix
  • Electronic Design Automation
  • MindSphere
  • Design, Manufacturing and PLM Software
  • View all Portfolio

Explore

  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Customer Stories
  • Partners
  • Trust Center

Contact

  • VA - Contact Us
  • PLM - Contact Us
  • EDA - Contact Us
  • Worldwide Offices
  • Support Center
  • Give us Feedback
© Siemens 2023
Terms of Use Privacy Statement Cookie Statement DMCA