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 our paper, Verification Patterns—Taking Reuse to the Next Level.

Environment Patterns:

Stimulus Patterns:

Analysis Patterns:

Environment Patterns

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.

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.

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.

Languages & Standards

Methodologies

Techniques & Tools

Universal Verification Methodology (UVM)

Featured Courses

Additional Courses

Formal-Based Techniques

Analog/Mixed Signal

UVM Forum

SystemVerilog Forum

Coverage Forum

Additional Forums

Specification Patterns

Pattern Resources

UVM Cookbook

Coding Guidelines & Deployment

Coverage Cookbook

Featured & On-Demand

On-Demand Library

Recording Archive

Conferences & WRG

Siemens EDA Learning Center

Blog & News

Verification Horizons Publication

About Us

Training

Portfolio

Explore

Siemens

Contact