Verification Cookbook Glossary

This page is an index to the glossary of various terms defined and used in the UVM Cookbook.

A

Advanced Verification Methodology (AVM)

A verification methodology and base class library written in SystemVerilog and created by Siemens EDA in 2006, the AVM was the precursor to OVM and UVM. It provided a framework for component hierarchy and TLM communication to provide a standardized use model for SystemVerilog verification environments. AVM is not recommended for new projects, refer instead to Universal Verification Methodology (UVM).

Agent

An Agent is a verification component for a specific logical interface. The logical interface can be implemented as a SystemVerilog interface - as a collection of wires. An agent's job is to drive activity on the interface, or monitor activity on the interface, or both. It normally contains driver, monitor, sequencer, coverage and configuration functionality. Methodology base class libraries typically provide a base class for an agent as part of a component framework, although they are normally vacuous.

Analysis

Functionality in a Verification Environment which involves taking input from one or more DUT interface monitors in the form of abstracted transactions and analyses of the contents, for correctness or in order to record coverage statistics.

Analysis Port

In UVM, an API for reporting abstract transactions to interested parties in the verification environment. The API is used to connect a producer component (e.g. a monitor) to one or more consumer components, also called subscribers (these are typically analysis components, e.g. scoreboards or coverage objects). Connection is a simple one-time activity. Transactions are then written to the port and the API automatically calls each subscriber's write() API in turn, with that transaction handle. The process takes zero simulation time and has lowest possible overhead.

Aspect Oriented Programming (AOP)

A software programming methodology which provides a framework and syntax for separation of concerns, across a hierarchy of objects. Unlike traditional Object Oriented Programming (OOP), Aspect Oriented Programming is not restricted to separation of concerns using hierarchy alone. It allows orthogonal slices of functionality to be defined separately and then stitched together with core functionality and other aspects and compile/elaboration time.

Individual methods of a class can be augmented (prepended or appended) or replaced by a contribution from an aspect. It is often used to add a layer of debug functionality, or to specify test variants in a concise manner. As a powerful language feature, it comes with a challenge, to avoid overuse or avoid adding complexity that is hard to debug or maintain at a later date. Various proponents and opponents can be found. Notable languages incorporating some degree of AOP functionality are 'e' and 'vera'. SystemVerilog has no AOP features.

Assertion

A software language construct which evaluates a condition and causes a fail or error message if the condition is false. A concise way to perform a check, often a check which is a prerequisite to subsequent processing, e.g. a check for null pointer before the pointer is used. In high-level Design/Verification Language terms, an assertion is often used to refer to a property/assertion construct which checks for a condition (the property) using a concise language which allows interrogation of signal states, transitions, in some order or within some time constraints.

The properties referred to in assertion statements can be built up from sequences and can become considerably complex; they can also be used with some formal tools for static evaluation. SystemVerilog Assertions (SVA) is a part of the SystemVerilog design/verification language and contains a powerful set of syntax to make these condition checks. Other assertion languages include PSL (property specification language).

Assertion Coverage

A kind of Functional Coverage which measures which assertions have been triggered. SystemVerilog contains syntax to add coverage to individual properties specified using SVA. Such coverage is useful to know whether the assertion is coded correctly, and whether the test suite is capable of causing the condition that is being checked to occur.

B

Black Box

A style of design verification where the design under test is considered opaque. The design can only be stimulated and observed using the available port connections, with no internal activity or signaling available for analysis.

Bus Functional Model (BFM)

A model which represents the behavior of a protocol (e.g. an addressable bus) at the signal function level. It is capable of providing the required signal activity to implement the features of the bus, under control of some API or higher-level abstraction.

C

Class

In Object-Oriented Programming (OOP), a software (or HVL) language construct which encapsulates data and the methods which operate on that data together in one software definition. The definition can typically inherit base functionality from a parent class and optionally augment or override that functionality to create a more specific definition. Classes can be instantiated and constructed one or more times to create objects.

Clock-Domain Crossing

A clock-domain crossing is when a signal moves from the output of a flip-flop clocked by one clock (and therefore part of that clock-domain) to the input of a flip-flop clocked by a different clock (a second clock domain). At the boundary (crossing) between these domains, some synchronization is normally required, the nature of that depending on the relationship between the two clocks. Verification techniques, methodology and tools exist to perform sanity checks on this particular area of DUT functionality.

Code Coverage

The capability for a simulator to record statistics on execution of each line of HDL code in a DUT, as a rough approximation for the quality of the verification. Several variants exist which track more detailed coverage, e.g. of multiple logical paths through a design depending on conditionals. Common variants include branch, statement, toggle, expression, condition and FSM coverage.

Component

A software entity which performs some functionality and can be connected to other components. In a class-based verification environment such as UVM, a component is a pseudo-static object, created in a preset way using the UVM API, is part of the testbench hierarchy, and exists for the lifetime of the simulation.

Configuration Object

An abstraction of one or more configuration values of various types, used within a verification environment to make shared persistent data available to one or more components, for the purposes of configuring those components to perform their function in a particular way, or to equip them with some higher level pseudo-static state of the DUT. More dynamic data is expressed in transaction objects - configuration objects are for less-frequently-changing or constant state.

Configuration Space

A set of state values that can be explored during verification, representing the set of possible configuration values for a DUT. Configuration can refer to soft configuration (e.g. programmed configuration register values or initialization pins) or hard parameterization. It is most often used to refer to soft config.

Constrained Random

A verification methodology where test stimulus is randomized in the HVL before being applied, rather than specified in a directed manner. The randomization is tailored (constrained) to a sensible subset of all possible values, to narrow the set of all possible stimulus down to a subset of legal, useful, interesting stimulus. Constrained random can also be applied to other aspects of the test including DUT configuration selection and testbench topology. SystemVerilog has constructs built into the language to support constrained random testing.

Constraint

In Constrained Random Stimulus, an item which restricts a particular aspect of a stimulus transaction (normally one transaction class member) to be a preset value, or bound within a specified range of values, or having a particular relationship to the value of another member of the randomized class. A set of constraints can be built up to narrow the random space for a stimulus transaction down to a legal, useful or interesting subset. During randomization, constraints are evaluated until a value random result is created that satisfies all constraints, or an error is produced if this is not possible.

Consumer

In software, an entity that receives data from a producer. The job of the consumer is to consume data or information. That information was created by a producer. In HVL, the data is normally an abstract transaction object. The abstract transaction object represents information - for example a READ transaction might contain an address and a data. That transaction is produced by the producer, and delivered to the consumer.

This kind of transaction communication is referred to as transaction level communication. In UVM, there is an API to provide TLM (transaction level modeling) communication and Analysis Ports. The TLM standard and analysis ports facilitate consistent producer/consumer connectivity.

Coverage

A statistical measurement of verification progress made by observing language features, including Code Coverage and Functional Coverage.

Coverage Class

In Functional Coverage methodology, a class (e.g. written in SystemVerilog) which contains coverage constructs to measure a particular reported entity (e.g. a transaction from a monitor, or a completed check from a scoreboard). Contained within a class in order to keep the coverage definition separate from the machinery of the test environment / interface monitors.

Coverage Closure

The process in verification of successive refinement of the stimulus that is given to the DUT and the checks that are performed, following the Verification Plan, until a sufficient measurement of coverage is reached w.r.t. the set of coverage goals implied by the Verification Plan. When coverage closure is reached, the DUT is considered verified (according to the criteria of the plan as executed).

D

Device Under Test (DUT)

The piece of code (RTL, gate level, System C models, etc.) which is being exercised by a testbench.

Driver

A verification component responsible for taking transactions written at a particular level of abstraction and converting them to a lower level of abstraction, according to the protocol being verified. Most drivers have as their 'lower level abstraction' the bus functional model which causes individual signal wires on the interface to be updated and reacted to. A typical driver would accept a transaction and convert it to signal changes.

Dual Top

An architectural arrangement where the testbench is contained within one top-level Verilog model, and the DUT is contained within another. Often associated with the requirements of Emulation, where portions of the test environment are required to be synthesizable.

E

E Reuse Methodology (eRM)

A methodology for use of the Verisity 'e' language and the 'specman' tool to create verification components and test environments following a consistent architecture. Some of its features, such as sequences, are reused in the SystemVerilog OVM and UVM methodologies.

Emulation

The acceleration of verification from what is possible in simulator software to a hardware platform where the simulation is synthesized into a netlist of logic running on real hardware (e.g. an FPGA implementation of logic cells and programmable interconnect). Trades off a more complex compilation step for vastly faster runtime cycle-per-second performance. Emulation also can constrain the ability to perform debug on the running test environment. Good emulation solutions workaround those tradeoffs to provide a full-featured verification environment for productive verification of large designs or complete state spaces, or system-level evaluation of real firmware running on emulated hardware.

F

Fork-join

A Verilog construct which splits a thread of activity into one or more new sub threads, each executing independently on the simulator, and subsequently 'joined' together in a predefined way. SystemVerilog enhances the syntax available for specification of how to join threads, so that the coder can choose to wait for all threads to complete (the default) [fork/join], or for the first one to complete [fork/join_any], or just to move on leaving them running independently [fork/join_none].

Functional Coverage

A kind of coverage supported in language syntax and measured in verification tools to reflect the desire expressed in a Verification Plan to apply particular test stimulus and checks to a DUT in order to fully verify it. Items in a Verification Plan can map to named/grouped functional coverage points which are defined in the language. SystemVerilog code can trigger those measurements by evaluating a specified triggering condition and can report a data value which is recorded in a preset manner, for subsequent reporting.

Functional Coverage is a key part of today's constrained random methodology, where the test intent is specified in the set of functional coverage points defined and measured in the context of random stimulus application, not in a set of manually directed tests with their own stimulus and checks.

G

Golden Model

A model which represents some existing known good behavior of a function, normally created outside the scope of the verification activity. When one exists, it is useful in a verification environment to form part of a scoreboard / predictor or other checker arrangement to enable self-checking.

Graph Based Verification

One of a number of 'intelligent testbench automation' features which optimizes the constrained random stimulus space using a graph representing interesting paths through the detailed possibilities of the protocol, in order to provide faster coverage closure compared to normal randomization of stimulus.

H

Hierarchy

An arrangement of entities which by their definition may contain zero or more sub-entities, each of which are also hierarchical. In the design/verification activity, can be used in relation to design modules (Verilog modules can contain instances of other modules) and of testbench component hierarchy (SystemVerilog UVM component objects can instantiate child component objects) or of sequence stimulus hierarchy (sequences can invoke sub-sequences).

I

Interface

In SystemVerilog, a construct representing a bundle of defined wires, normally used to represent the signals which comprise a single instance of a protocol interface between a DUT and a testbench. A useful abstraction used during testbench definition and hookup, avoiding the need to replicate declarations for each member signal along the way. Can be provided to a class-based testbench via a virtual interface.

Interrupt

In CPU hardware/software, a system event which is conveyed by hardware to the CPU where it causes normal software execution to be suspended and a designated subroutine to be executed in order to service the interrupt, clear it, and return to the normal execution thread. Hierarchy and priority normally exist, allowing interrupts to be interrupted in turn, if required.

For Verification, it is desirable to emulate this behavior by allowing a sequence of stimulus to be interrupted by some waited-upon event and a special sequence substituted and executed on the driver representing the interrupt service routine and the set of reads and writes that are required there, before returning to the existing running sequence. UVM sequencer/driver architecture allows this kind of override, priority, hierarchy with various APIs for locking / grabbing / setting arbitration priority.

M

Matlab

A language and programming tool / simulation environment for modeling algorithms and datapaths at a higher level of abstraction. It also provides graphical visualization of these higher-level mathematical functions.

Metrics

Measurable statistics, in the case of a verification environment, representing progress, performance and completeness of the verification activity. Notable metrics are code coverage, functional coverage, bug rates, source code complexity, project-to-project reuse statistics, and project management measurements.

Model

An abstracted software representation of a hardware or software function, containing some approximation of the set of external connections and some approximation of the internal behavior. The intent of a model could be to document the specification of a function to be implemented/measured, or to serve as part of a checking environment for a design which implements the function, to be compared with the model's execution of any given stimulus, or to deliver an alternate level of detail of the function for some optimized usage.

Module

A named, instantiable design unit in Verilog - a static collection of behavioral or RTL or gate-level functionality with a predefined set of inputs and outputs, which can be formed into a hierarchy or can enclose submodules - instances of other modules in a hierarchy. Unlike Classes, Modules are static - they are created at elaboration time and therefore exist at time 0 before the simulation starts and remain in a fixed structure for the entire simulation.

Monitor

A component responsible for watching pins wiggle on a bus and converting those pin wiggles back into transactions. The transactions are then sent out through an analysis_port. The analysis_port may be connected to a scoreboard, a predictor, a coverage class, etc. The monitor doesn't do checking directly.

O

Open Verification Methodology (OVM)

A base class library written in SystemVerilog language, implementing verification environment and stimulus features such as component hierarchy, abstract transaction connections (TLM), sequences of stimulus transactions, message reporting, testbench construction phasing, and incorporating OOP techniques such as configuration patterns and factory pattern substitution. First Released in 2008 and developed as a joint effort between Siemens EDA and Cadence Design Systems, building on Siemens EDA's existing SystemVerilog AVM architecture and incorporating patterns and use models from Cadence's 'e' reuse methodology (eRM). OVM formed the basis for the Universal Verification Methodology (UVM) in 2010. OVM is portable code known to run on all SystemVerilog-compliant simulators and is in widespread use today.

P

Package

In SystemVerilog, a software entity which provides an encapsulation of a set of software artifacts (types, variables, class definitions) within a single namespace. This serves to protect symbols from collision with those in other package namespaces, and also to provide a mechanism for import of a set of functionality into another software entity for reuse.

Parameterized Class

As discussed in Parameters a class may have elaboration-time parameters which allow variation of its runtime representation, those parameters containing values - integral or string or class handle, or types, e.g. class types. The feature is similar to the templates in C++ language. Once parameters are added to a class, it is no longer possible to instantiate the class without specifying those parameters (although defaults can be provided), and any hierarchy above the object of that class type needs to pass down the required parameter values which are ultimately set to concrete values at a high level of the hierarchy.

In verification methodology such as UVM, parameterized classes are heavily used to implement TLM connections, factory patterns and other methodology features. They are advisable only for verification component hierarchy usage, in situations where the DUT and its interfaces are parameterized, and the test environment has to be capable of testing more than one variant of those. However, they are not recommended for use on data/transaction/sequence or analysis component classes, where more abstract forms of representation at runtime can replace them.

Parameterized Tests

The application of Parameters and Parameterized Classes to the problem of providing a library of tests with variations in applicability, perhaps selectable at runtime, or perhaps aligned with the parameters required for the DUT instance to be tested. The test class typically instantiates the environment(s) which in turn instantiate Agent(s) containing driver(s) or monitor(s). For methodologies which pass a virtual interface to drivers and monitors to connect to the actual DUT, any parameterization in the DUT (and its interfaces) needs passed down to the drivers/monitors, via the Agents, Environments, and ultimately the tests.

Parameters

In Verilog and SystemVerilog, the ability to specify pseudo-constants on module or class declarations, which are resolved to actual values during the elaboration phase of compilation, for the purpose of making those entities more reusable and flexible to more than one situation. Different instances of a module or objects of a class type can have different parameter values. parameter values can be passed down hierarchy to sub-modules or instances of types within a class. Parameterized modules and classes introduce an aspect to software construction that provides flexibility but adds a complexity and maintenance burden, ideally this powerful feature is used sparingly. Often soft run-time configuration variables can suffice.

Phasing

Phasing is a stepwise approach to the construction of a verification environment at runtime and the execution of required stimulus and the completion of the test when stimulus is done. UVM has an API which enables components to participate in this step-by-step process in a predetermined and familiar manner. The construction of a structured test environment with TLM connections is done in a predetermined manner to enable smart hierarchy and connectivity management, and at runtime there are phases which can map to different kinds of stimulus or can be user-defined as required for the application. Most verification environments use the simplest possible subset of the available phases: build, connect, run.

Pipelined

An attribute of a hardware design of a logic function or connectivity protocol. Pipelining is the storage of intermediate representations of progress within the execution of a logic function or protocol transfer in an overlapping form, allowing a transform which takes more than one clock cycle to complete and overlap with others, in order to improve overall throughput (but not normally to affect or impact end to end latency).

The depth of the pipeline is the amount of overlap that is possible in a particular design, depending on the nature and amount of the intermediate storage elements, and constrained by the protocol itself, in particular any feedback loops or possible stalls in execution. Verification of pipelined logic or protocols requires stimulus to match that complexity - simple back-to-back stimulus is insufficient. Techniques can be used in Drivers and Monitors to support pipelining.

Power Architecture Coverage

A kind of Functional Coverage which is specific to the verification of low-power domain architectures, often referring to a standard convention such as Unified Power Format (UPF) which breaks down the possible states and features in a predictable manner. Functional verification of normal DUT traffic and features must coexist with verification of power architecture and the various state transitions that can occur, and their interactions with normal stimulus.

Predictor

A verification component which acts alongside or within a scoreboard or checker, comparing two or more observed behaviors on the design under test for correctness. The predictor may transform an observed behavior into another form which can be more directly compared for consistency. That transformation may involve reference to a Golden Model which may implement functional transformation, aggregation or disaggregation, or more complex topologies of input versus output.

Producer

In software, an entity that delivers data to a Consumer. The job of the producer is to produce data or information. That information will be passed to a consumer. In HVL, the data is normally an abstract transaction object. The abstract transaction object represents information - for example a READ transaction might contain an address and a data. That transaction is produced by the producer and delivered to the consumer.

This kind of transaction communication is referred to as transaction level communication. In UVM, there is an API to provide TLM (transaction level modeling) communication and Analysis Ports. The TLM standard and analysis ports facilitate consistent producer/consumer connectivity.

Program Block

Program blocks in SystemVerilog exist in order to mimic the scheduling semantics that a PLI application has interacting with a Verilog simulator. As such they are not normally required in an OVM/UVM testbench in SystemVerilog where there is direct access to the DUT pins from the language with no PLI requirement. Siemens EDA does not recommend their use.

R

Register Model

A kind of Model which represents the behavior of a set of named addressable registers, grouped into hierarchies as required, divided into named fields with attributes and specified behaviors, all representing the normal kind of behavior of a bus-addressable configuration/control/status/data interface.

The structures occur so frequently in typical designs and conform to a small set of common feature patterns, so are ideal for usage of a common modeling solution. One such model solution is found in the UVM. It enables abstract reads/writes to named registers or fields, via a collaborating bus driver, and modeling of current or expected values which can be predicted and checked, in collaboration with a bus monitor. It can be used as a configuration object elsewhere in the testbench where decisions have to be made about stimulus delivery, reassembly, or checking, based on known soft configuration values stored in register fields. It can be used to inform coverage objects which seek to measure design coverage related to different register settings.

Regression

The running of a suite of tests repeatedly in some cycle, in order to determine forward progress of a design/verification activity and catch any unexpected backwards progress (regression) so that debug may determine whether a design bug or a verification bug exists, and what needs to be done to move that test to a passing state and continue with forward progress.

A regression suite has various attributes - it may require one or more verification environments / testbenches, it may use parameters to alter design or testbench configuration, there may be test stimulus which is directed, or constrained random, or graph-based, and there may be different knobs controlling checks to be performed, amount of debug data to collect, and extent of simulation. Underlying machinery is used to distribute the compilation and running of the various tests on simulators and other tools, often requiring parallel run distribution across multiple compute environments.

Underlying machinery can control the intent of the regression (what stimulus to run) and capture the results of that run and/or cumulative runs on order to present data to the verification resources to aid their productivity or their ability to achieve Coverage Closure.

Resource

In UVM, a configuration variable or object, held within a Resource Database, for global access by both components who subscribe to configuration of that type, and those who are responsible for specifying the configured value.

Responder

A verification component which, similar to a driver, interacts with a lower level of abstraction such as the individual signals on a protocol interface, in order to participate in a protocol. Unlike a driver, responders do not initiate stimulus traffic from a sequence, they respond (slave-like) to traffic observed on the interface in order to maintain legal protocol. Their execution may be controlled by configuration (specifying how they are to respond in general) including some constrained randomization possible within the allowed configuration space, or by sequences of configuration changes (altering the way they respond in a controlled way), or by maintaining some state, e.g. a memory model or register model, which reflects persistent data values deposited by earlier traffic and subsequently retrieved accurately by the responder.

S

Scoreboard

A component responsible for checking actual and expected values. The actual and expected values will be delivered via analysis_port/export connections to the scoreboard from monitors and/or predictors. The scoreboard may also record statistical information and report that information back at the end of a simulation.

Sequence

A class-based representation of one or more stimulus items which are executed on a driver. Can collaborate in a hierarchy for successive abstraction of stimulus and can participate in constrained random setup to enable highly variable sets of stimulus above the randomization possible in an individual transaction. Sequences can represent temporal succession of stimulus, or parallel tracks of competing or independent stimulus on more than one interface. They can be built up into comprehensive stress test stimulus or real-world stimulus particular to the needs of the protocol.

UVM has comprehensive support the automated definition and application of sequences. In its simplest form, a sequence is a function call (a functor), which may request permission to communicate with a driver using a sequence item. This complicated sounding interaction is not so complicated. A sequence asks for permission to send a transaction (sequence item) to the driver. Once it has been granted permission by the sequencer, then the transaction is passed to the driver.

Sequence Item

A class-based abstract transaction representing the lowest level of stimulus passed from a sequence to a driver. Also known as a Transaction.

Sequencer

A component responsible for coordinating the execution of stimulus in the form of sequences and sequence items from a parent sequence, ultimately feeding a driver component with transactions. UVM/OVM provide a standard sequencer component with preset arbitration and locking methods for complex sequence stimulus. At its simplest, a sequencer can be thought of as a fancy arbiter. It arbitrates who gets access to the driver, which represents who gets access to the interface.

Shmoo

A Test/Verification technique where test stimulus is deliberately applied with a time offset from other test stimulus in order to force a rendezvous inside the design under test of stimulus arrival or state change, combined with a sweep of relative timing offset to explore simultaneous arrival in addition to a plus-or-minus offset between two or more stimulus events.

The sweep distance should equal or exceed the known pipeline depth of the logic under test in order to flush out pipeline definition bugs. Unlikely to be achieved by normal randomization alone, more usually an orchestrated or semi-directed test sequence calling sub-sequences in a time-controlled manner.

Subscriber

In a verification environment, a component which is a consumer of transaction data via an analysis port and associated connection made during verification environment construction. A UVM base class is supplied for the simplest case of subscriber, and other classes and macros are available to build more complex subscribers which feed from more than one analysis port traffic. Most analysis components are subscribers in this way.

T

Test

A class-based representation of a verification scenario. A test consists of a verification environment constructed in a particular way, some particular stimulus run upon it in a particular way, checks, coverage, and debug capabilities enabled or configured according to intent of the engineer or regression environment. The top-level of a component hierarchy in UVM.

Test Plan

Part of a Verification Plan, a document or documents which capture the detailed intent of the verification team for completing coverage closure on the design under test. The Test Plan is typically in spreadsheet or other structured form and contains detailed testbench requirements and links to functional coverage, assertions or specific tests. The Test Plan is sometimes referred to as 'verification plan' or 'requirements spreadsheet' or 'trace matrix' or 'coverage spreadsheet'.

Transaction

An abstraction of design activity on a signal interface into a class-based environment, to allow higher-order verification intent to be expressed more concisely. The unit of data that is passed along TLM connections in UVM. When the stimulus strategy involves UVM sequences, the transaction is also known as a Sequence Item.

A transaction is a collection of information that is passed from point A to point B and may have a beginning time and an ending time. A transaction may have relationships with other transactions - like transaction X is the parent of transaction Y (and transaction Y is the child of transaction X).

Transactor

A generic term for any verification component that actively interacts with the DUT interfaces (e.g. a driver or responder).

Two Kingdoms

This is one way of describing a class-based technique that allows transactors to talk to a DUT. The technique relies on an concrete implementation of an abstract interface in an interface and a handle to the abstract class in the transactor. It used to workaround some of the complexities associated with virtual interfaces.

U

UVM Verification Component (UVC)

A set of software and related artifacts providing a self-contained, plug-n-play verification solution for a particular protocol interface or logic function, compatible with the UVM. A UVC consists of one or more configurable Agents with a set of familiar APIs and ports, defining the underlying signal Interface and TLM Sequence Item, a Sequence Library of example stimulus and protocol compliance test stimulus, a comprehensive Protocol Coverage Model, some example Analysis components and tests, and documentation including a reference protocol Verification Plan.

The resulting set of collateral provides a coherent, complete solution for protocol or function compliance testing. The term 'Verification Component' is sometimes used interchangeably with 'Verification IP (VIP)'.

Unified Coverage Database (UCDB)

A database developed by Siemens EDA for capture of code coverage, functional coverage, and other metrics together in one place for post-regression analysis and reporting. Forms the basis of the UCIS industry standard in development in Accellera.

Unified Power Format (UPF)

A format for specifying the design intent for power control features in a design such as power domains, power isolation, power state transitions and register/memory retention regions. Verification of the power design intent can be made using formal and simulation tools, based on the content of a UPF description. The UPF format is defined by IEEE 1801-2009.

Universal Verification Methodology (UVM)

A standard API and reference base class library implementation in SystemVerilog describing a standardized methodology for verification environment architecture, to facilitate rapid, standardized verification environment creation and stimulus application/coverage closure on a design under test. Can be viewed as an extension to the SystemVerilog language to avoid the necessity to reinvent the wheel on common architectural traits such as component hierarchy build-out, transaction level modeling connections, higher-order stimulus application, common configuration and substitutions, register modeling, and reporting.

Derived from the Open Verification Methodology (OVM), and created in 2010 by Siemens EDA, Cadence and Synopsys working in the context of the Accellera committee. Other Accellera participants have since contributed to the implementation and its maintenance.

V

Veloce

Siemens EDA's emulation platform for high-performance simulation acceleration and in-circuit emulation of complex integrated circuits.

Verification

The process of evaluating a programmatic representation of a hardware design for correctness according to its specifications, including the use of techniques such as simulation, mathematical and formal evaluation, hardware emulation, application of directed tests or random stimulus in the context of a programmatic verification environment.

Verification Architecture Document (VAD)

A high-level verification planning document that records all of the verification planning, strategy and decisions. This is a 'parent' document and all other verification documents are typically derived from it. It may contain coverage information, or that may be split out into a separate Verification Implementation Document (VID).

Verification Implementation Document (VID)

A verification document containing more detailed implementation planning for example a coverage plan, highlighting all the locations where coverage is measured, and associated conventions for coverage naming and configuration. Often part of or a sub-document of a Verification Architecture Document (VAD).

Verification IP

The verification components in the Siemens EDA Verification IP library fit any verification environment. By facilitating and enhancing the application of transaction-level modeling (TLM), advanced SystemVerilog testbench features (such as constrained random testing), modern verification methodologies (such as OVM and UVM), and seamlessly integrating with other Siemens EDA tools (such as Questa Verification Management, Questa Simulation, Questa VIQ and Veloce), Siemens EDA Verification IP increases productivity even further.

Verification IP delivers a common interface across the library of protocols. This results in a scalable verification solution for popular protocols and standard interfaces, including stimulus generation, reference checking, and coverage measurements that can be used for RTL, TLM, and system-level verification.

Verification with Siemens EDA Verification IP is straight forward: simply instantiate it as a component in your testbench. The built-in capabilities of Verification IP automatically provide the entries for the coverage database, so you have the metrics in place to track whether all necessary scenarios are covered.

Siemens EDA Verification IP is also integrated with the Questa debug environment and makes use of the transaction viewing capability in Questa so that you can get both signal-level and transaction-level debugging capabilities.

Verification Methodology Manual (VMM)

A standard API and reference base class library implementation in SystemVerilog describing a standardized methodology for verification environment architectures. It was created by Synopsys and was derived from the Vera RVM (Reference Verification Methodology). Still supported by Synopsys although superseded by the Universal Verification Methodology (UVM).

Verification Plan

A document or documents which capture the intent of the verification team for completing coverage closure on the design under test. It is good practice to split the document into separate verification architecture and optional implementation documents, and a separate Test Plan in spreadsheet or other structured form for detailed requirements and links to functional coverage.

Virtual Interface

In SystemVerilog, a virtual interface is a handle variable that contains a reference to a static interface instance. Virtual interfaces allow the class-based portion of a verification environment to connect to physical interfaces containing signal definitions in the static module hierarchy.

Virtual Sequence

A sequence which controls stimulus generation across more than one sequencer, coordinate the stimulus across different interfaces and the interactions between them. Usually the top level of the sequence hierarchy. AKA 'master sequence' or 'coordinator sequence'. Virtual sequences do not need their own sequencer, as they do not link directly to drivers. When they have one it is called a virtual sequencer.

Virtual Sequencer

A virtual sequencer is a sequencer that is not connected to a driver itself but contains handles for sequencers in the testbench hierarchy. It is an optional component for running of virtual sequences - optional because they need no driver hookup, instead calling other sequences which run on real sequencers.

W

White Box

A style of design verification where the design under test is considered semi-transparent. In addition to stimulating and observing the Black Box ports on its periphery, its internal signals or elements of interest such as state machines or FIFOs can also be stimulated and observed by the testbench.

Worker Sequence

A sequence which calls lower-level API sequences to build up compound activities such as DUT configuration, loading a memory, initializing a feature. Usually a worker sequence would only be sending eventual sequence items to a single sequencer (as opposed to a virtual sequence which sends to multiple sequencers) A worker sequence is a fancy name for a sequence that does work by calling other sequences. Collections of worker sequences can be built up, one upon the other. In the software world this might be called chains of function calls. Each function calling lower level functions in turn. Worker sequences call (or start, or send) lower level sequences. A worker sequence may hide details of sequences - like calling start.