I N V E Unive ni vers rsa al Ve Verific ri fica ation ti on Methodo tho dolo logy gy N (UVM) Workshop T I V E
November 2012 – UVM1.1
© 2008-2012Cadence Design Systems, Inc. All rights reserved worldwide.
Printed in the United States of America. Cadence Design Systems, Inc., 2655 Seely Avenue, San Jose, CA 95134, USA Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence's trademarks, contact the corporate legal department at the address shown above or call 800.862.4522. Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are used with permission. All other trademarks are the property of their t heir respective holders. Restrict Restrict ed Permissio Permissio n: This publication is protected by copyright law and international treaties and contains trade secrets and proprietary information owned owned by Cadence. Unauthorized reproduction or distribution of this publication, or any portion of it, it , may result in civil and criminal penalties. Except as specified in this permission statement, this publication may not be copied, reproduced, modified, published, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to print one (1) hard copy of this publication subject to the following conditions: The publication may be used only in accordance with a written agreement between Cadence and its customer; The publication may not be modified in any way; Any authorized copy of the publication or portion thereof t hereof must include all original copyright, trademark, and other proprietary notices and this permission statement; The information contained in this document cannot be used in t he development development of like li ke products or software, whether for internal or external use, and shall not be used for the benefit of any other party, whether or not for consideration Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence's customer in accordance with, a written agreement between between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result f rom use of such information. Restrict Restrict ed Right Right s: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 DFAR252.227-7013 et seq. or its successor.
© 2008-2012Cadence Design Systems, Inc. All rights reserved worldwide.
Printed in the United States of America. Cadence Design Systems, Inc., 2655 Seely Avenue, San Jose, CA 95134, USA Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence's trademarks, contact the corporate legal department at the address shown above or call 800.862.4522. Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are used with permission. All other trademarks are the property of their t heir respective holders. Restrict Restrict ed Permissio Permissio n: This publication is protected by copyright law and international treaties and contains trade secrets and proprietary information owned owned by Cadence. Unauthorized reproduction or distribution of this publication, or any portion of it, it , may result in civil and criminal penalties. Except as specified in this permission statement, this publication may not be copied, reproduced, modified, published, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to print one (1) hard copy of this publication subject to the following conditions: The publication may be used only in accordance with a written agreement between Cadence and its customer; The publication may not be modified in any way; Any authorized copy of the publication or portion thereof t hereof must include all original copyright, trademark, and other proprietary notices and this permission statement; The information contained in this document cannot be used in t he development development of like li ke products or software, whether for internal or external use, and shall not be used for the benefit of any other party, whether or not for consideration Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence's customer in accordance with, a written agreement between between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result f rom use of such information. Restrict Restrict ed Right Right s: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 DFAR252.227-7013 et seq. or its successor.
Setting tt ing Your Expectations
• Start Start buil buildin ding g knowl knowledg edge e on the the Univ Univers ersal al Verif Verific icati ation on Methodology (UVM) – – – –
We will cover many many of the basic UVM concepts You will test some some UVM features with simple labs See how UVM is supported by Cadence verification platform platform Understand how Coverage Driven Methodology Methodology (CDV) works with UVM
• The The wo work rksh shop op will will no nott co cove verr – SystemVerilog language language syntax
UVM Workshop Agenda
Introduction to UVM and Coverage Driven Verification UVM Class-based Workshop: • The UVM Library • Stimulus Generation • Building Reusable Verification Components • Testbench Creation Using Reusable Components • Coverage Analysis and Regression UVM Multi-Language and UVM Acceleration Migration to UVM Summary Labs
Labs and DUT Introduction • This workshop includes hands-on labs – We follow the process of creating a verification environment for a simple UART DUT that is part of a larger SoC system – The labs allow further understanding of the lectures and provide a simple UVM example for hands-on exploration UART block: Converts parallel data from the APB bus into serial CPU data and vice versa
DMA
Memory
AHB Parallel APB bus
Bridge APB
UART
UART
Serial UART protocol
UART Serial
APB Core
USB
Ethernet
UART DUT and Verification Environment Module Verification Component
UVM Testbench
Scoreboard
Imitates external device by generating frames
Interface & wh ite-box coverage
Programs the UART and transfers traffic
UART DUT (Verilog RTL) APB Verification Component
APB
Tx FIFO
txd
Transmitter
APB Interface
Mode Switch Rx FIFO
Receiver
Control/Status Registers
rxd
Test 1
Test 2
UART Verification Component
Control/Interrupt Logic
Multi-channel c ontroller
Controls APB and UART components
UART Serial
Test 3
Tests indicate which stimulus sequences to execute
UVM Workshop Agenda
Introduction to UVM and Coverage Driven Verification UVM Class-based Workshop: • The UVM Library • Stimulus Generation • Building Reusable Verification Components • Testbench Creation Using Reusable Components • Coverage Analysis and Regression UVM Multi-Language and UVM Acceleration Migration to UVM Summary Labs
What is UVM? UVM is the Universal Verification Methodology – A methodology and a library that codifies the best practices for efficient and exhaustive verification. • A complete, proven solution – Proven solution, with a success record and large community of users with methodology knowledge and commitment – Well-thought-out solution for a wide variety of verification challenges
• Open – A key motivation for moving to SystemVerilog – An Accellera standard, supported by Cadence, Mentor and Synopsys
• Enables reuse of verification environments – Verification IP can dramatically speed-up delivery and improve quality – A common methodology that also works for other languages (SystemVerilog, e, SystemC)
8
© 2011 Cadence Design Systems, Inc. All rights reserved.
UVM is Production Ready Cadence Verification Methodolo gy Leadership from the Beginning…
2000 eRM
Jan 2006URM 2008 OVM
Feb 2011 UVM
eVC
OVC
UVC
Configuration
DUT I/F
Configuration
DUT I/F
Configuration
DUT I/F
Passive Agent
Active Agent
Passive Agent
Active Agent
Passive Agent
Active Agent
Monitor
Sequence_driver
Monitor
BFM
• Architecture • Sequences • Messaging/logging • Reset/clocking • Common test interface • Packaging & code structure
Added: • Module to system reuse • Register package (vr_ad) • HW/SW co-verification © 2011 Cadence Design Systems, Inc. All rights reserved.
Coverage
Sequencer Seqs.
Checks
Included:
9
Monitor
Seqs.
Seqs. Checks Coverage
Sequencer
Checks Coverage
Driver
Added: • SystemVerilog support • Architecture • Sequences • Factory • Configuration mechanism • Field automation • Message macros • Register pkg (contribution) • Integration of AVM base classes •TLM Communication Channel • Multi-language interoperability
O V M 2 .1 .1
Driver
Added: • SV callback enhancements • Report catching callback • SV end of test enhancements • Closer to eRM capability • Register support • Enhanced phasing • Partial TLM2 support • Improved configuration and command line support • Script for “o” to “u” migration for OVM users
UVM and Coverage Driven Verification
• Coverage-driven verification(CDV) combines the following aspects to significantly reduce the time spent verifying a design: – Automatic stimulus generation – Self-checking testbenches – Coverage metrics
• Why CDV? – Eliminate the effort and time to write hundreds of tests – Ensure thorough verification using upfront goal setting
• UVM provides the framework to achieve CDV
Coverage Driven Verification • Components of a coverage driven verification environment – Automated Stimulus Generation – Independent Checking – Coverage Collection
Coverage
seed 23098432 38748932 23432239 17821961 10932893 20395483 18902904 23843298 23432432 24324322 55252255 09273822 13814791 4098e092 23432424 24242355 25262622 26452454 24524522
Coverage
Scoreboard Data Checking
Monitor
Monitor
Random Generation Tests Tests
Random Stimulus Sequence Generator Generator
Driver
DUT UART
APB
Coverage Driven Verification Flow Verification Plan vPlan
• Create a verification plan Verification Environment Verification Arch it ect ur e
Adju st and Add Constraints and Stimulus Sequences
Asser tio ns , Constraints & Coverage
Simulation, Accel erati on, Emulation
Refine Coverage Model Review Coverage
– Based on specification requirements – Decide what to test and how
• Create smart testbench that: – Generates random legal stimulus – Includes assertions and coverage to measure progress against the goals – Checks for undesired behavior (BUGS!)
• Implement coverage model based on the verification plan, in place early on • Iteratively run simulations and analyze coverage • Adjust constraints and add new scenarios targeting coverage holes • Refine and enhance the coverage model
Coverage Driven Verification – Example • This table represents the attributes we want to verify: – – – –
Goals Functional requirements Checks Block-level coverage
• Multiple coverage metrics should be used: – – – –
A1 A2 A3 A4 s e r u t a e F
B1 B2 B3 B4 C1 C2 C3 C4 D1 D2 D3 D4
Specification Blocks Functional coverage Assertions (Static Formal Verification and Simulation) Directed tests Code coverage
• For some attributes, multiple metrics are required to determine coverage • For others, a single metric is sufficient
Integrating Coverage Techniques Initial Coverage Results
Direct ed Tests : 19%
Asser tio ns : 31%
Functional Coverage: 62%
Code Cover age: 43%
We recommend: • Start with explicit coverage to represent verification goals: Static and dynamic assertions and functional coverage
Coverage full partial
• Balance with implicit, implementation coverage to ensure thoroughness: code, FSM and assertion coverage
none Total Coverage: 68%
Coverage Driven Verification - Summary
• Combination of automated random test creation and functional coverage – Coverage is your executable test plan
• Advantages: – Saves test writing efforts – Reliable metrics to check your progress throughout the verification cycle – Ensures efficient verification – Eventually determines completeness
UVM Methodology Implements the CDV Concepts
Agenda
Introduction to UVM and Coverage Driven Verification UVM Class-based Workshop: • The UVM Library • Stimulus Generation • Building Reusable Verification Components • Testbench Creation Using Reusable Components • Coverage Analysis and Regression UVM Multi-Language and UVM Acceleration Migration to UVM Summary Labs
The UVM Library Using inheritance and encapsulation i n class libraries
• Three layers of elements TLM
Existing TLM standard for class communication
Structural Elements Methodology
Classes common to most methodologies: components, messages, simulation phases, etc.
The main user interface that enables reuse including classes that capture the high-level methodology and wrap the low-level classes
UVM Class Hierarchy (UVM 1.1) uvm_object
Base class for all UVM data and hierarchical components
name copy(), clone() … print()
uvm_transaction uvm_sequence_item uvm_sequence
uvm_report_object
body()
uvm_report_*()
uvm_port_base #(IF)
uvm_report_handler uvm_component
uvm_subscriber uvm_env
uvm_*_export
parent children get/set_config_*(), create () build_phase(), connect_phase(), end_of_elaboration_phase(); start_of_simulation_phase(); run_phase(), ……
uvm_tlm_fifo uvm_tlm_analysis_fifo
uvm_test uvm_driver
uvm_monitor
uvm_agent
uvm_scoreboard
uvm_*_port
TLM uvm_*_imp
uvm_tlm_req_rsp_channel uvm_tlm_transport_channel
uvm_sequencer
Using the UVM Class Library Deriving an environment from the class library allows: • Exploiting built-in automation – – – – –
Sequences … standard & powerful test writer interface Built-in factory for rapid reuse Transaction manipulation (packing, deep copying etc) Flexible automatic test phase interface Messaging utilities
• Adhering to a proven methodology – – – –
Modular topology (monitors, drivers, agents) Out-of-the box or partial reuse TLM communication for language independent modularity A powerful component configuration scheme
Where Do I Get UVM?
Option 1
Option 2
Download the UVM library from www.uvmworld.org You will be redirected to http://www.accellera.org/activities/vip Included in Incisive Release – Located at: `ncroot`/tools/uvm – Will contain bug fixes not on UVM world – Contains Cadence additions to UVM • Tcl commands • Transaction recording • Register generator • Templates for verification component generation
What the release looks like? uvm/ UVM_Reference.html uvm_release-notes.txt uvm/bin/ ovm2uvm.pl uvm/doc/ uvm/src/ base/ comps/ dpi, reg/ macros/ seq/ tlm1, tlm2/ uvm_pkg.sv uvm.sv uvm_macros.svh
UVM Reference Manual UVM Release information OVM to UVM migration script User Guide and Reference UVM source files low-level library components methodology layer (agent, env) register package and reg dpi macro definitions sequence-related code TLM layer components `include file required for UVM
What the release looks like? (cont.) Cadence-specific additions (only found in the IUS version of UVM) Directories of examples that run on multiple simulators Includes: basic_examples, callbacks, configuration, factory, phases, etc more complex UVM examples UVM equivalent of the xbus To run on IES: irun –f compile_ius.f
uvm/sv/cdns_additions uvm/examples/ simple/ …… integ/ xbus/ examples/ sv/
codec/ apb/
Agenda
Introduction to UVM and Coverage Driven Verification UVM Class-based Workshop: • The UVM Library • Stimulus Generation – Modeling Data Items – Reusable Sequences
• Building Reusable Verification Components • Testbench Creation Using Reusable Components • Coverage Analysis and Regression UVM Multi-Language and UVM Acceleration Migration to UVM Summary
Modeling Data Items
• Data items – Represent the main transaction input to the DUT – Adhering to a protocol, consistent values are generated and sent – Examples include packets, transactions, instructions, and so on
• Test environment randomizes data items (transactions) – A default distribution should be generated – Tests further steer generation by layering constraints or selecting from pre-defined scenarios – This makes test short, readable, easier to write and maintain Test 3 Test 2 Test 1
UVM Smart Testbench
SystemVerilog Data Item: A UART Frame class uart_frame; rand int delay; rand bit start_bit; rand bit [7:0] payload; rand bit [1:0] stop_bits; rand bit [3:0] error_bits; bit parity;
Fields to be randomized How will the test-writer request a bad parity frame?
// utility functions parity is calculated using a function extern function bit calc_parity( ); extern function void print( ); extern function bit compare(uart_frame rhs); … endclass: uart_frame
Design for Test-writing using Knobs typedef enum bit {BAD_PARITY, GOOD_PARITY} parity_e; class uart_frame; Define an find enumeration make it Can you another to possible rand int delay; easy to describe parity type control field in the frame? rand bit start_bit; rand bit [7:0] payload; Can have zero, short, medium rand bit [1:0] stop_bits; and long delays rand bit [3:0] error_bits; bit parity; Knobs are control fields that allow easy user interface // control fields rand parity_e parity_type; // utility functions extern function bit calc_parity( ); … endclass: uart_frame
Test writers can specify the distribution of GOOD vs. BAD parity Extra logic can set the parity based on the generated parity_type
Recommendation: Think of the desired scenarios and make sure you have the needed control knobs to achieve them
Setting Default Distribution typedef enum bit {BAD_PARITY, GOOD_PARITY} parity_e; class uart_frame; rand int delay; By default we don’t want rand bit start_bit; a huge delay rand bit [7:0] payload; rand bit [1:0] stop_bits; Can you think of another rand bit [3:0] error_bits; possible default constraint? bit parity; // control fields In typical traffic, most rand parity_e parity_type;
frames are legal
constraint default_delay { delay >= 0; delay < 20; } constraint default_parity_type {parity_type dist { GOOD_PARITY:=90, BAD_PARITY:=10};} // utility functions … endclass: uart_frame
Layering Constraints for Testing • In a specific test, a user may want to: – Adjust the randomness – Disable existing constraints – Further change the generation using new constraints
• This is achieved using class inheritance • Create a new class that inherits from the parent class frame
class uart_frame; … endclass
short_delay_frame class short_delay_frame extends uart_frame; // additions here …
New class members
endclass
Example: Layering Constraints You can redefine the default_delay // original frame declaration code constraint block or change its constraint mode to zero class uart_frame; rand int delay; // This is a default constraint that could be overriden constraint default_delay {delay > = 0; delay < 20;} endclass: uart_frame
How can you get a delay of 25?
Use of inheritance
These constraint blocks will be resolved together
// Test code class short_delay_frame extends uart_frame; // This constraint further constrains the delay values constraint test1_delay {delay < 10;} endclass: short_delay_frame
What is the legal range in a short_delay_frame?
How Are Data Items Generated? A Simple Generator Generator Produces data (transactions) i/f
i/f
Bus Driver Gets data and sends to DUT
interface
DUT
Randomize in a loop a transaction or create an array of transactions to send one-by-one
class simple_generator; rand int count; uart_frame frame; task gen_and_push(); frame = new(); for (int i=0; i
class driver; virtual interface dut_if if; task send_tx_frame (input uart_frame frame); . . . // implements protocol-specific code if.txd = frame.start_bit; …. endtask endclass Gets a frame and drives it
following the timing protocol
Data Item Example class uart_frame; rand int delay; rand bit start_bit; rand bit [7:0] payload; bit parity; rand bit [1:0] stop_bits; rand bit [3:0] error_bits;
User defined function
// Utility functions extern function bit calc_parity( ); extern function void print(); extern function bit compare(uart_frame rhs); … endclass: uart_frame
Required for most transactions!
Where SV Language Stops and UVM Begins Example: Data Items class uart_frame; uart_frame; bitrand bitstart_bit; start_bit; bitrand [7:0]bitpayload; [7:0] payload; bitrand bit parity; parity; rand parity_e parity_e parity_type; parity_type; intrand inttransmit_delay; delay; endclass : uart_frame
Does language alone support all the necessary customization operations? • Randomization • Printing • Cloning • Comparing • Copying • Packing • Transaction Recording
No! Only randomization is defined in the SystemVerilog LRM
UVM provides the rest!
Enabling Data Item Automation class uart_frame extends uvm_sequence_item; rand bit start_bit; UVM data items are derived rand bit [7:0] payload; from uvm_sequence_item bit parity; rand parity_e parity_type; Enables all automation for rand int delay; uart_frame fields // *optional* field declarations and automation flags `uvm_object_utils_begin(uart_frame) `uvm_field_int ( start_bit, UVM_ALL_ON ) `uvm_field_int ( payload, UVM_ALL_ON ) `uvm_field_int ( parity, UVM_ALL_ON ) `uvm_field_enum ( parity_e, parity_type, UVM _ ALL_ON + UVM_NOCOMPARE ) `uvm_field_int ( delay, UVM_ALL_ON + UVM_DEC + UVM_NOCOMPARE ) `uvm_object_utils_end endclass: uart_frame Specify field level flags: UVM_NOCOMPARE, UVM_NOPRINT, etc.
UVM Macros: `uvm_object_utils and `uvm_field_* • UVM provides macros to reduce coding and enable automation of common verification functions
`uvm_object_utils_begin (name) `uvm_field_int (name, FLAGS) `uvm_field_enum (etype, name, FLAGS) `uvm_field_array_int (name, FLAGS) `uvm_object_utils_end
• The `uvm_object_utils macro implements a set of utility functions for UVM objects. – get_type_name() and create() methods are implemented – The object is also configured for built-in automation • print(), compare(), copy(), clone(), pack(), unpack(), etc
• `uvm_field_* macros specify the automation requirements for each field of the data item – Flags indicate whether the field is to be included in printing, copying, etc • UVM_ALL_ON enables everything
Note: These macros are optional – but highly recommended!
Example xampl e: Data Data Type Type Auto Au tomatio mation n
uart_frame frame1, frame2; initial begin frame1 = new(“my_frame”); new(“my_frame”); assert(frame1.randomize()); frame1.print (); $cast(frame2, frame1.clone()); frame2.set_name(“my_frame2”) frame2.print (tree_printer); end
Three Thre e buil t-in printers prin ters can be used
-------------------------------------- Name Type Size Value -------------------------------------- my_frame uart_frame @607 start_bit integral 1 ’h1 payload integral 8 ’hfc parity integral 1 ’h0 parity_type parity_e 32 BAD_PARITY delay integral 32 ’d382 ---------------------------------------
Create a new uart_frame and copy frame1 to frame2 my_frame2: (uart_frame@788) { start_bit: ’h1 payload: ’hfc parity: ’h0 parity_type: BAD_PARITY delay: ’d382 }
Transactio ransact ion n Re Record co rdin ing g in IES IES // inside driver or monitor code uart_frame frame1; int handle; ... handle = begin_tr(frame1) begin_tr(frame1);; // start recording … // body including timing end_tr(frame1)); end_tr(frame1) ); // end recording
SimVision: Automatic transaction recording. Au A u t o m at atii c rec r eco o r d i n g met m eth h o d s b u i l t i n t o UVM it i t em ems s
Flag Argum Ar gume ent Definiti fin itions ons Table (part (partial ial list li st)) FLAG FL AG
DESCRIPTION
DEFAULT DEFAULT
UVM_ALL_ON / UVM_DEFAULT
Turns on the COPY, COPY, COMPARE, COMPARE, PRINT, PRINT, RECORD, CLONE, PACK , UNPACK UNPACK and DEEP flags
UVM_DEFAULT
UVM_COPY / UVM_NOCOPY
setting COPY includes the field in copy(), clone() operations. NOCOPY excludes the field
UVM_COPY
UVM_COMPARE/ UVM_NOCOMPARE
setting COMPARE includes the field in compare operations. NOCOMPARE – excludes the field
UVM_COMPARE
UVM_PRINT / UVM_NOPRINT
PRINT includes the field in print(), sprint() operations
UVM_PRINT
UVM_PACK/ UVM_NOPACK
PACK includes the field in pack and unpack operations
UVM_PACK
UVM_PHYSICAL / UVM_ABSTRACT
Treat as a PHYSICAL fields. Treat as an abstract field.
UVM_READONLY
Do not allow setting of this field from the set_*_local methods.
Radix (for printing) ADD UVM_ to each radix listed
Provide a specific radix to use when printing integral fields (or arrays of integral fields). Available radix values are: BIN, DEC, UNSIGNED, OCT, OCT, HEX, STRING, TIME
UVM_HEX
Messages for Debug & Error Reporting
• Messages – – – –
While developing or using environments, users need to print messages $display does not allow non-intrusive filtering and control User may want to get trace messages from a suspect component Critical to large environment with many verification components
• Error reporting – The testbench must produce clear and descriptive error messages to communicate a checker mismatch – Should affect simulation based on severity
• Error – stop • Warning – record and proceed • Allow customization of above
Message Requirements
• Simplicity of – Writing messages – Turning messages on and off
• Uniformity of – Output format – Turning on and off
• User control over formatting of output
UVM Messaging Facility Messages print trace information with advantages over $display: • •
Aware of its hierarchy/scope in testbench Allows filtering based on hierarchy , verbosity , and time uvm_report_info("PKT", "Packet Sent");
Output
id
time
message body
UVM_INFO @10 uvm_test_top.test.generator [PKT]: Packet Sent
severity
scope
• Simple Messaging: – uvm_report_*(string id, string message);
• Where * (severity) is one of fatal, error, warning, info • Tips: – Use get_type_name() to give an id of the class type – Use $sformatf() to create message string using $display syntax
Messages and Verbosity uvm_report_info(get_type_name(), $sformatf("addr %h",addr), UVM_LOW);
• Additional argument to uvm_report* defines verbosity UVM_NONE, UVM_LOW, UVM_MEDIUM, UVM_HIGH, UVM_FULL
• By changing the verbosity maximum, messages can be filtered – For example, if the verbosity is set to UVM_LOW, all messages coded with UVM_MEDIUM and higher will not print
Ways to change verbosity without recompiling! 1. Command-line:
% irun …. +UVM_VERBOSITY=UVM_NONE 2. Procedural (test): set_report_verbosity_level_hier(UVM_MEDIUM);
Enhancing the Messaging Methods
The uvm_report* built-in methods raise a few issues: • The string manipulations are executed whether the message is printed or not. – String manipulation is costly and gets worse when data items are large or complex.
• A single mechanism is used to control trace messages and error messages: (+UVM_VERBOSITY) • Errors and warnings are also sensitive to verbosity. – The default verbosity for warnings is MEDIUM and for fatal/error is LOW. – When UVM_NONE verbosity setting is specified on the command line, errors and warnings will not be printed (or executed).
Enhancing the Messaging Methods • We suggest using macros to address these issues: – Allows checking the verbosity before string manipulation – Enables printing line number and file name – Hard-codes errors to use severity UVM_NONE
• Macros are the ONLY reasonable way to address the first two items • Syntax `uvm_info(string id, string message, int verbosity) `uvm_warning(string id, string message) `uvm_error (string id, string message `uvm_fatal(string id, string message)
• Note: warning/error/fatal have hard-coded verbosity of UVM_NONE
Using the UVM Library with Incisive Simulators • irun allows users to run the simulator by specifying all input files and command-line options on a single command line. – Each file is compiled using the appropriate compiler based on the file extension used. • Verilog, SystemVerilog, VHDL, e, C and C++ – Command-line options are also recognized and passed to the compiler, the elaborator and the simulator % irun -access +r -gui test.sv
verify.e
top.v
sub.vhd
• irun supports UVM-specific options: -uvm -uvmhome $UVM_HOME +UVM_TESTNAME +UVM_VERBOSITY
Searches /tools/uvm/src and sets command-line options to compile the lib Optionally specifies a different directory for the UVM installation Passes the default test name for run_test() Sets the verbosity level for UVM messages
It’s Lab Time! – Lab 1
Data Item Modeling: • UART serial data interface – frames
Objectives: • Transaction generation and constraint layering • UVM automation • Use UVM message facility
UVM Testbench
Scoreboard coverage
APB UVC
UART DUT
Multi-channel controller
Labs 1-3 focus on the UART UVM Verification Component
UART UVC
Lab1: Data Item Modeling Discussion
• What did we do? – Generated constrained-random UART frames in a loop – Explored the UVM built-in automation and messaging – Altered the distribution of generated items using constraint layering
• Questions – What advantages do you see in using `uvm_info() over $display? – When we introduced a test1_frame, we had to modify the frame_generator to create test1_frames Can you think of a scenario in which this would be problematic? – Can you send a stream of transactions with incrementing payload values using constraint layering?
Constraint Layering Using the Factory • In lab 1 – you had to modify the generator in order to use the test1_frame derived class – This is problematic for large SOC designs because you will have to modify many files
• UVM includes a mechanism (called a “factory”) for allowing users to override the default behavior – The factory is automatically built into the library – Powerful tool for test-writing & reuse
• Let’s revisit the previous lab example to understand how the factory works
Constraint Layering Using the Factory typedef enum {SHORT, MEDIUM, LONG} delay_t; // extended class uses control knob for delay class delay_frame extends uart_frame; Add control knob to rand delay_t delay_knob; constrain delay constraint delay_type_c { delay > 0; delay_knob == SHORT -> delay < 10; delay_knob == MEDIUM -> delay < 40 delay_knob == LONG -> delay > 100; } `uvm_object_utils_begin (delay_frame) `uvm_field_enum (delay_t, delay_knob, UVM_ALL_ON|UVM_NOCOMPARE ) `uvm_object_utils_end
function new (string name=“delay_frame”); … endclass: delay_frame
Registers delay_frame with the factory
// In the generator class: uart_frame frame; // data item declaration ... create frame (“frame”)); frame == uart_frame::type_id:: new(“frame”); // create a new data item
Replace frame=new(); with create (…)
What is the UVM Factory?
• Central location to create class instances on demand – Each type is registered with the factory – Instances created via factory call • Not via class constructor del ay_f r ame
?
– Apply override instructions to factory
• Make all uar t _f r ame instances del ay_f r ame instead
from
to
uar t _f r ame ...
del ay_f r ame ...
Factory
Class Hierarchy uar t _f r ame
?
Cr eat e uar t _ f r ame Factory allocates instance of required type
type and instance override list
+cr eat e
registered types uar t _f r ame
del ay_f r ame
del ay_f r ame
+cr eat e
Register type with factory
Factory Overrides • Type override replaces ALL instances: – For a specific test, replace all uar t _f r ame packets with del ay_f r ame packets
A uart_frame
drv_c
B delay_frame
drv1_c
set _t ype_over r i de_by_t ype( uar t _f r ame: : get _t ype( ) , del ay_f r ame: : get _t ype( ) )env1 ;
• Instance override replaces specific instances: – Replace uar t _f r ame in agent[0] sequencer – Replace agent [ 1] driver dr v_c with dvr 1_c
agent[0]
agent[1]
seqr
seqr A B
A B
driver monitor A B
A B
env1 set _i nst _over r i de_by_t ype( "env1. agent [ 0] . seqr ", agent[0] uar t _f r ame: : get _t ype( ) , del ay_f r ame: : get _t ype( ) ) ;
driver monitor
agent[1] seqr
seqr
A B
set _i nst _over r i de_by_t ype( " env1. agent [ 1] " , dr v_c: : get _t ype( ) , dr v1_c: : get _t ype( ) ) ;
A
driver monitor A
B A
A B
A
driver monitor A A
A
Using Factory for Object Substitution from Test
uart_frame new_frame
Replace ALL instances Syntax: object::type_id::set_type_override (derived_obj::get_type())
Example: uart_frame::type_id::set_type_override
A
C
B
(delay_frame::get_type());
Replace specific instances Syntax: object::type_id::set_inst_override
A
(derived_obj::get_type(), “hierarchical path”);
Example: uart_frame::type_id::set_inst_override
(delay_frame::get_type(), “A.B”);
B
C
Using Factory for test1_frame from Lab1 class test1_frame extends uart_frame; macro registers the constraint default payload { payload <= 8’h3f; } object with the factory `uvm_object_utils (test1_frame) function new(string name=“test1_frame”); super.new(name); class frame_generator; endfunction : new uart_frame frame; endclass : test1_frame … task gen_and_push(); // replace frame = new(); with the following: module lab1_top; frame = uart_frame::type_id::create(“frame”); … … frame_generator generator; endclass : frame_generator … initial begin uart_frame::type_id::set_type_override (test1_frame::get_type());
generator = new(); … endmodule : lab1_top
Agenda
Introduction to UVM and Coverage Driven Verification UVM Class-based Workshop: • The UVM Library • Stimulus Generation – Modeling Data Items – Reusable Sequences
• Building Reusable Verification Components • Testbench Creation Using Reusable Components • Coverage Analysis and Regression UVM Multi-Language and UVM Acceleration Migration to UVM Summary
Reminder: Simple, Non-UVM Generator
Generator Produces data i/f
i/f
Bus Driver Consumes and send to DUT
class generator; Randomize in a loop a rand int count; transaction or create an uart_frame frame; array of transactions virtual task gen_and_push(); for (int i=0; i
Many critical randomization concepts are up to
Key Randomization Concepts • Everyt Everythin hing g shou should ld be ran random dom within within spec spec (inf (infini inity ty minus) minus) • Re Reac acti tive ve ge gene nera rati tion on an and d pre pre-ru -run n gen gener erat atio ion n • Stan Standa dard rd so solu luti tion on for for va vari riou ouss scena scenari rios os – Interrupt modeling, modeling, looking at previously generated generated data, protocol layering, modeling timing
• Maxi Maximu mum m flex flexib ibililit ityy for for test test crea creati tion on – You can never predict predict all test requirements requirements
• Stimul Stimulus us is repr reprodu oducib cible le with with smal smalll chan changes ges in the design design – Random Stability
• Syst System em-l -lev evel el sce scena nari rios os an and d cont contro roll – Some scenarios scenarios will be reused at the system system level
Ideal methodology should address the requirements above out-of-the-box, even for non-expert users!
Scenari cenario o Crea Creation ti on Requirements qui rements
• Achie Achievi ving ng full full cove coverag rage e using using const constrai raint nt laye layeri ring ng is highl highlyy recommended – The technology evenly selects items from legal ranges – Efficient in capturing unanticipated unanticipate d bugs
• Many Many time times, s, singl single e items items canno cannott captur capture e high-l high-lev evel el inten intenti tion on – Ordered streams of transactions are required – Examples: configuration of a device, de vice, program generation
• A sequence sequence is is a set of transactions that accomplish a defined task • Sequen Sequences ces ar are e prov provide ided d as par partt of a reus reusabl able e comp compone onent nt – Capture important scenarios that should shoul d be exercised
• UVM UVM prov provide idess an adv advanc anced ed seque sequence nce gen gener erati ation on mech mechani anism sm
UVM Sequencer – an an Adv A dvanced anced Generato Generatorr
Sequencer Generator
Produces data i/f
UVM sequencer • By de defa faul ultt wor works ks exa exact ctly ly like like a gene genera rato torr – Generates random transactions on request We replace the generator • Addres Addresses ses all all ran random domiz izati ation on re requi quire reme ments nts:: with a sequencer – random by-default, by-default, reactive generation, generation, system-level ready, modeling timing, etc
• sequences i/f
Bus Driver Consumes and send to DUT
User-defined sequences sequences of of transactions are created and executed – For example, a user creates a sequence that interleaves legal and illegal frames
• Test Test wr writ iter er set setss the the sequ sequen ence cerr to to exec execut ute ea specific sequence • Prov Provid ides es bu buililtt-in in ra rand ndom om stab stabililit ityy – Random sequence sequence immune to changes in other parts of TB/design
Sequences Example: UART Retry Sequence // Send one BAD_PARITY frame followed by a GOOD_PARITY extend from uvm_sequence // frame with the same payload class retry_seq extends uvm_sequence #(uart_frame); // uart_frame req; // built-in data item field Data item `uvm_object_utils (retry_seq) Registers the retry_seq with the factory rand bit [7:0] pload; // randomizable sequence parameter ... virtual task body ( ); // sequence behavior `uvm_do_with (req, {payload == pload; parity == BAD_PARITY;} ) `uvm_do_with (req, {payload == pload; parity==GOOD_PARITY;} ) endtask : body body() can also include time consuming endclass statements, fork…join, function calls, etc
The ‘uvm_do’ Operation … virtual task body (); // sequence behavior `uvm_do_with(req, {payload == pload; parity == BAD_PARITY;} ) endtask Reactive generation
• Translates into: – – – – –
• Combines procedural and declarative (constraint layering) directives • Factory support out-of-the-box
Wait till item is requested Create items using a factory Randomize (with constraints or not) Return the item to the requester Block code execution till item_done()
Inline constraints for additional control
• Allows modeling timing • built-in TLM to allow reuse • e.g. scenario that calls for and support multi-language a frame, wait for FIFO full communication New and expert users deploy all key randomization concepts! and do illegal frame
Sequences Example: Manual Approach ... virtual task body ( ); // sequence behavior //`uvm_do_with (req, {payload == pload; parity == BAD_PARITY;} ) req = uart_frame::type_id::create(“req”); start_item(req); if (!req.randomize() with {payload == pload; parity == BAD_PARITY;} ) begin `uvm_fatal(get_type_name(), "Randomization failed") end finish_item(req); … endtask : body endclass
Nesting Sequences // call retry sequence wrapped with random frames class rand_retry_seq extends uvm_sequence #(uart_frame); `uvm_object_utils (rand_retry_seq) retry_seq retry_sequence;
Using a previously defined sequence
virtual task body (); // executable sequence behavior `uvm_do (req) `uvm_do_with (retry_sequence , {pload inside {[0:31]};}) `uvm_do (req) Create and randomize a endtask retry_seq sequence and endclass call it’s body
Sequence Execution Sequencer // Sequence: rand_retry_seq class rand_retry_seq extends … //uart_frame req; //built into seq retry_seq retry; virtual task body (); `uvm_do(req) `uvm_do_with(retry, {pload inside {[0:31]};)) `uvm_do(req) endtask endclass
// Sequence: retry_seq class retry_seq extends uvm_sequence #(…); // uart_frame req; // built into base seq rand bit[7:0] pload; virtual task body (); `uvm_do_with(req, {payload ==pload; parity==BAD_PARITY;}) `uvm_do_with(req,{payload==pload; parity==GOOD_PARITY;}) endtask endclass get_next_item() get_next_item() item_done()
Driver
Controlling Sequencer Behavior • How do we control which sequences run on a UVC sequencer and when? 1.
r un_ phas e( ) (and every run sub-phase) has a def aul t _sequence property. • Set def aul t _s equence to a sequence to execute in that phase.
// Test: Set uart_tx_sequencer to use retry_seq as the default sequence uvm_config_db#(uvm_config_wrapper)::set(this,"uart_tx_sequencer.run_phase ", "default_sequence", retry_seq::type_id::get()); 2.
Execute a sequence directly on a UVC sequencer from a test class, by calling the sequence’s start method
3.
Group sequences into a sequence library; Set def aul t _sequence to execute the sequence library
The UVM Driver Pulls transactions from the sequencer and drives the DUT interface Sequencer
class uart_tx_driver extends uvm_driver #(uart_frame); // uart_frame req; // built-in field
Derived from uvm_driver
Produces data
`uvm_component_utils(uart_tx_driver)
i/f
virtual task get_and_drive(); forever begin seq_item_port.get_next_item(req); send_tx_frame(req); seq_item_port.item_done (); end endtask
i/f
Driver Consumes and send to DUT
Main control loop
Interface to the sequencer via TLM
virtual task send_tx_frame(input uart_frame cur_tx_frame); ... endtask endclass Drive interface signals following the protocol
Summary - UVM Sequences • • • • • •
Easy to use; no need to learn complex mechanism Combines declarative and procedural constraints Can be generated on-the-fly or at time zero Can nest sequences Can use events or time to delay transactions Ability to create a system-level sequence – Control multiple interfaces from a single consistent sequences – E.g. Configure the registers via the bus, then start external stimuli
• Provide built-in random stability Sequences are at the heart of testbench automation and reuse!
Other Sequence Applications
• Sequences are a standard mechanism to create, control and drive complex hierarchical inputs into the DUT • Provide proven solution for block and system level solutions – – – – – –
Multi-channel sequences Pre-run sequences (zero-time-generation) Reactive sequences Interrupt sequences Protocol layering And more …
SimVision - Advanced UVM Analysis and Debug
•
UVM-aware dynamic object debug – Debug testbench configuration and hierarchy – Set breakpoints • Step in, step through classes
– Flexible TCL to manipulate testbench at run-time
•
UVM transaction analysis – UVM transaction recording – Stripe chart
•
Debug constraint conflicts – Identify over-constrained issues – Interactively reduce constraints and randomize on the fly
67
Design Browser
Icon fo r UVM data members Click on icon will “ route” to Design Browser
Methods Tab
Method s Tab of the displayed UVM Component
Interactiv Interact ive e Sequ Seque ence nc e Debug Callstack Viewing • When When stopp stoppin ing g a break breakpoi point, nt, you you can can use use the the “cal “calls lstac tack” k” sidebar to see where your method was called from and to traverse the callstack. callstack.
Transactio ransact ion n Visua Visu aliz li zation ti on - Se Sequences class concurrent_u2a_a2u_rand_trans_vseq extends uvm_sequence; … // APB sequences program_dut_csr_seq config_dut config_dut;; apb_to_uart_wr raw_seq raw_seq;; // UART sequences uart_transmit_seq uart_seq uart_seq;; intrpt_seq rd_rx_fifo rd_rx_fifo;; virtual task body(); … endtask endclass
class do_something_seq extends uvm_sequence; concurrent_u2a_a2u_rand_trans_vseq my_vseq my_vseq;; `uvm_sequence_utils(do_something_seq,apb_uart_virtual_sequencer ) task body(); uvm_report_info("do_someth uvm_report_info("do_something_seq","Doin ing_seq","Doing g Nothing First", UVM_NONE); #2000 uvm_report_info("do_someth uvm_report_info("do_something_seq", ing_seq", "Doing concurrent_u2a_a2u_rand_t concurrent_u2a_a2u_rand_trans rans sequence NOW", UVM_NONE); `uvm_do(my_vseq); endtask endclass
Transactio Transact ion n Stripe Stri pe Chart (TS (TSC)
Constraint Debugger
When there is a constr aint solver failu re, a new constraint debugger window is c reated for showing r andom variables and constraints associated w ith t he class instance.
Constraint Debug
At th e to p of th e wi ndow is a to ol bar which has buttons that allow the user to create or delete a new constraint.
This portion lists the variables and their values. All variables are listed in th e object since state variables can be used in a constraint.
Source view region will show the selected rand variables and constraints i n co ntext.
This portion lists the constraints for the object. This displays the constraint name and the first line of the constraint from the source file.
Constraint Debug – Dynamic Analysis Show All const raints
Click to add new constraints
Click to disable constraint Do a “ run –rand_solve” for this instance With refined constraints, constraint solver success now.
It’s Lab Time! – Lab 2 UVM Testbench
coverage
UVM Sequences: Objectives: • Explore the driver and sequencer interaction • Review the sequencer default behavior • Execute a specific sequence • Write a new sequence
Scoreboard
APB UVC
UART DUT
UART UVC
Multi-channel controller
uart_tx sequencer sequence seq_item_export
seq_item_port
uart_tx driver
Sequencer: • Creates and executes “sequences” of transactions • Sends UART frames to the Driver Sequence : • Creates randomized UART frames Driver : • Gets UART frames from the Sequencer • Converts to signal-level details ( it just prints the frame in this lab) • Indicates it’s ready for another frame
Recap: Sequence – Sequencer – Driver – DUT Interaction Sequencer: 2. Executes the “default_sequence” - Creates, randomizes, and calls the sequence
body() task
4. Sends frame to the driver via TLM port 5. Waits for item_done() from driver
before generating next frame Sequence: 3. Generates a sequence item (aka data
items, transactions, etc) Driver: 1. Requests a frame from the sequencer 6. Gets a frame via TLM port 7. Sends frame to the DUT via SV
interface 8. Indicates item_done() to sequencer
sequences
sequencer Default_sequence
seq_item_export
uart frames seq_item_port
driver virtual i/f
uart signals interface
UART DUT
simple_tx_seq transmit_seq repeat_seq incr_payload bad_parity
sequence_items BAD_PARITY GOOD_PARITY uart_frames
Lab2: Creating Sequences Discussion
• What did we do: – – – –
Explore the driver and sequencer interaction Review the sequencer default behavior Execute a specific sequence Write a new sequence
• Questions – What benefits do sequences provide? – What is the sequence body() task? – How to control a sequencer execution?
• How can Sequences enable reuse?
Agenda
Introduction to UVM and Coverage Driven Verification UVM Class-based Workshop: • The UVM Library • Stimulus Generation • Building Reusable Verification Components – Concepts for reuse – Reusable environment topology
• Testbench Creation Using Reusable Components • Coverage Analysis and Regression UVM Multi-Language and UVM Acceleration Migration to UVM Summary
Reusable Environments
• CDV and UVM shorten the verification process – Avoid the need to create hundreds of tests – UVM provides base classes and automation to quickly build the testbench environment – Allows fine control over the created scenarios
• One of the core values of the UVM methodology is the ability to reuse these components – As you move from block to system-level (vertical reuse) – From one project to the next (horizontal reuse)
Creating a Reusable Verification Environment UVM Testbench
BUS UVC Mon Mon
Module VC
•
– Apply stimulus on each external interface – Coordinate stimulus across multiple ports for system-level scenarios – Emulate the CPU by reading and writing device registers
BFM BFM
SEQR
Scoreboard Mon
coverage
DRV
VC3
•
Project1 DUT M u l t i C h a n n e l S e q u e n c e G e n e r a t o r
CPU
Periph
Mon Mon Mon
BFM BFM DRV
SEQR
Protocol1 VC3 UVC
Mem
Periph
Mon Mon Mon
BFM BFM DRV
SEQR
Protocol2 VC3 UVC
Tasks to be done:
Issues: – How do we model complex environments? Generation? Checking? Coverage? – How do we facilitate reuse?
•
Solution: “divide and conquer” – Create a reusable verification component per interface – Following the protocol, each component: • Stimulates the interface • Checks for protocol correctness • Collects coverage – Add a mechanism for multi-channel traffic generation – Create end-to-end checker and coverage collector
Packaging UVM Components for Reuse • UVM methodology combines all components for a single interface into a reusable package
Coverage
Scoreboard Data Checking
Coverage
Monitor
Monitor
seed 23098432 38748932 23432239 17821961 10932893 20395483 18902904 23843298 23432432 24324322 55252255 09273822
Tests Tests
Sequencer
Driver
Packaged for reuse
DUT UART
APB
Reuse at the System Level • Configure APB UVC as passive: – Monitor still collects coverage
Coverage
• New blocks are added as they are developed • Reuse of scoreboard for checking
Scoreboard Checking Coverage
Passive
Coverage
Tests Tests
Random AHB to APB Sequence Bridge Generator
Monitor
Driver
Reusable Compon ent
Monitor
DUT APB
UART
Reusable Environments: Main Players
• Contributors have different skill sets and responsibilities • Who are they? – Reusable component developers • Experts in protocol knowledge and verification – Environment integrators • Build test environments using reusable components • Less protocol knowledge, more target system knowledge – Test-writers • May have little verification expertise
• UVM allows each contributor to focus on his responsibilities and be productive quickly Note: At times the same person is doing two or all the roles above
Facilitating Reuse Testbench
Mon BFM Mon BFM Mon DRV
SEQR
VC3 VC2 M u l t i C h a n n e l S e q u e n c e G e n e r a t o r
Project2 DUT Periph
• Create a components repository • Reuse existing components for next project – Can use various languages based on needs and preferences
• New components are added as needed • Over time, components repository grows and matures – Proven on multiple projects – Becomes a major company strength!
Periph
VC Repository Mon BFM Mon BFM Mon DRV
Module VC
Mon BFM Mon BFM Mon DRV
Scoreboard SEQR
coverage
VC3
Mon BFM Mon BFM Mon BFM
Mon BFM Mon BFM Mon DRV
BUS VC Mon BFM Mon
BFM
SEQR SEQR
SEQR
SEQR Mon DRV
VC3
VC3 eVC
VC3 VC2
VC3
Component Repository…Sounds Trivial?
• Verification methodologies have existed for many years – Many components have been created – Limited success on sharing components between teams and across companies
• Proven UVM concepts have delivered success! – – – –
Well-defined, easy-to-learn architecture Verification component encapsulation at the interface level Configuration scheme for reuse Capable scenario generation for multiple protocols and unanticipated needs
Let’s see how to do it right!
Coverage and Checking
Sequencer
Produces data i/f
• From where should we collect coverage? • Neither the sequencer nor the driver are the ideal option – What if we want to monitor an interface that we do not drive?
i/f
Driver Consumes and send to DUT
• For this we need a third component called a “Monitor”
The Monitor
• Monitor – A passive component that collects information on a monitored interface – Builds abstract transactions – Contains events, status, checkers and coverage
• Protocol specific • Passive entity – Never drives signals!
• Monitor is independent of the driver! – May need to monitor information driven by the testbench
Monitor Checking and coverage
The UVM Monitor – Coverage Implementation class uart_monitor extends uvm_monitor ; `uvm_component_utils(uart_monitor) uart_frame frame; // data item to be collected
Derived from uvm_monitor and registered with the factory
covergroup uart_trans_frame_cg; NUM_STOP_BITS : coverpoint frame.nbstop { bins ONE = {0}; Implement coverage bins TWO = {1}; model based on your } verification plan DATA_LENGTH : coverpoint frame.char_length { …} PARITY_MODE : coverpoint frame.parity_mode { … } endgroup function new (string name = "", uvm_component parent = null); super .new(name, parent); new() covergroup in the constructor uart_trans_frame_cg = new(); endfunction: new Task to collect data items task collect_frame ( ); // Collect uart data from interface from the DUT interface uart_trans_frame_cg.sample(); endtask: collect_frame Sample coverage when endclass: uart_monitor frame is collected
Creating Assertion/Formal-Ready Interface Components • Assertions are useful for dynamic simulation – Can identify overlooked issues • DUT and reference model can be wrong • May capture performance concerns – Can significantly reduce debug time vs. end-to-end checkers
• Can be leveraged in formal verification – Another efficient, complementary path to discover bugs – Can be exploited before a dynamic environment exists
• Interface UVCs are protocol specific – Ideal place to capture protocol assertions inside
• UVM introduces a unified flow for dynamic and formal verification
UVM Assertions Methodology The methodology was designed to: • Combine upfront planning and assertions development into your flow • Instantiate and control assertions • Reuse assertions • Between projects • Across teams (designers, verification engineers, etc) • Using multiple technologies • Measure thoroughness using assertions
Immediate assertion
Env (UVC)
Agent checks in the monitor Agent Agent Config: active_passive
sequences tlm i/f
tlm i/f
Monitor
tlm i/f
Coverage Checking
Driver
vif
vif
Concurrent assertions reside in the SV interface Ask us for inform ation or T=training on UVM and Assertion s
Sequencer
I/F
DUT
Agenda
Introduction to UVM and Coverage Driven Verification UVM Class-based Workshop: • The UVM Library • Stimulus Generation • Building Reusable Verification Components – Concepts for reuse – Reusable environment topology
• Testbench Creation Using Reusable Components • Coverage Analysis and Regression UVM Multi-Language and UVM Acceleration Migration to UVM Summary
How to Facilitate Reuse? Reuse of low-level components • Integrator places drivers, sequencers and monitors within his project testbench environment • Integrator needs to learn: – Class names and their roles – How these components communicate with each other – How to configure components separately or create and communicate with a central configuration facility – How to set the right signals or learn to use a central signal map
• Lots of manual work and understanding is required • No single consistent guidelines – Different per reusable component
Consider This: Your Next Verification Challenge! Trace Port Analys er
SDRAM Bank 0
SDRAM Bank 2
SDRAM Bank 1
SDRAM Bank 3
SRAM
ROM
Flash
LCD Display
PC Cards MOVE
Static Memory Interface
SDRAM Controller
M ARM926 T CPU E
Vectored Interrupt Control
Color LCD
DMA M
M
S
PCMCIA Host
ARM I AHB ARM D AHB LCD AHB
SRAM Buffer
DMA 1 AHB (Periph) DMA 2 AHB (Memory) EXPANSION AHB
DMA APB
Core APB WATCHDOG
AHB/ APB
TIMERS
AHB/ APB
MPEG-4 Engine
Colour Convert
SSP Camera Interface Camera
GPIO (x4) GPIO x4
SYSTEM CONTROL
RTC
Clk/Reset Generator 32 GPIO lines
32KHz CLK Xtal Osc
UART
SIM Card
USB Interface Transceiver
PLL Xtal Osc
USB Connection to PC
Scalability is a must! Class level reuse is not enough!
Camera Control
Our new system specs are in the mail
The Solution: Agents uvm_agent uvm_ sequencer
Config :
sequences seq_item_export
uvm_monitor events, status, data
• Agents provide all the verification logic for a device in the system • Instantiation and connection logic is done by the developer in a standard manner – Integrator does not need to worry about this
• A standard agent has: seq_item_port
uvm_driver
vif
vif
interface
DUT
– Sequencer for generating traffic – Driver to drive the DUT – Monitor
• Note: that the monitor is independent of the driving logic to allow a passive operation mode • Agent has standard configuration parameters for the integrator to use
Agent Standard Configuration • A standard agent is configured using an enumeration field: is_active
uvm_agent uvm_ sequencer
Config :
is_active: UVM_PASSIVE UVM_ACTIVE
sequences
min_addr: 16’h0100
seq_item_export
passive uvm_monitor events, status, data
seq_item_port
uvm_driver
vi
UVM_ACTIVE: • Actively drive an interface or device • Driver, Sequencer and Monitor are allocated UVM_PASSIVE: • Only the Monitor is allocated • Still able to do checking and collect coverage
vi
interface
DUT
• Other user-defined configuration parameters can also be added Example: address configuration for slave devices
Creating the Agent
Derived from uvm_agent
Configuration field class master_agent extends uvm_agent; uvm_active_passive_enum is_active = UVM_ACTIVE; UVM field declaration for library automation `uvm_component_utils_begin(master_agent) `uvm_field_enum(uvm_active_passive_enum, is_active, UVM_ALL_ON) `uvm_component_utils_end // agent sub component instances Using the constructor to allocate the master_driver driver; sub-instances is problematic master_sequencer sequencer; because new() is not polymorphic master_monitor monitor; function new( input string name, input uvm_component parent); agent super.new( name, parent); sequencer // create the sequencer, driver and monitor Config : Is_active sequences monitor = new (“monitor”,this); if (is_active == UVM_ACTIVE) begin driver = new(“driver”,this); monitor events, sequencer = new(“sequencer”, this); status, driver end data Allocation using new() forces a vi vi endfunction re-write when modifications are endclass required
Creating the Agent Using build_phase() Method class master_agent extends uvm_agent; active_passive_enum is_active = UVM_ACTIVE; `uvm_component_utils_begin(master_agent) `uvm_field_enum(active_passive_enum, is_active, ALL_ON) `uvm_component_utils_end // agent sub component instances master_driver driver; Constructor is still required master_sequencer sequencer; master_monitor monitor; function new(input string name, input uvm_component parent); super.new(name, parent); Use the build_phase() method to allocate components and address endfunction virtual function void build_phase(uvm_phase phase); the polymorphism requirement // Allocate sequencer, driver and monitor here endfunction virtual function void connect_phase(uvm_phase phase); // Make TLM connections here Use the connect_phase() method endfunction to make TLM connections between the sub-components endclass
The Agent build_phase() and connect_phase() class master_agent extends uvm_agent; class v2_mdriver extends master_driver; ... // add attributes + override virtual methods // agent sub component instances endclass master_driver driver; // syntax for introducing the new driver – in test master_sequencer sequencer; master_driver::type_id::set_type_override ( master_monitor monitor; v2_mdriver::get_type()); ... virtual function void build_phase (uvm_phase phase); Use the factory to override super.build_phase(uvm_phase phase); the driver for a specific test // create sequencer, driver and monitor Call super.build_phase(…) monitor = master_monitor::type_id::create ( “monitor”, this); if (is_active == UVM_ACTIVE) begin driver = master_driver::type_id:: create(“driver”, this); sequencer = master_sequencer::type_id::create (“sequencer”, this); end Use create() for factory allocation endfunction virtual function void connect_phase(uvm_phase phase); driver.seq_item_port. connect( sequencer.seq_item_export); endfunction Standard TLM mechanism for connecting endclass the driver and sequencer
Verification Environments • Many protocols have a variable number of devices – Example: AHB has multiple masters and slaves
• These are represented as agents in UVM – Agents share a common configuration or common signals • Example: Bus speed
– Agents communicate with each other directly or via a central component • Example: A single bus monitor can serve multiple agents
• Environment classes (envs) are introduced to encapsulate and configure multiple agents – Contain all the reusable logic for an interface – Also referred to as UVM Verification Components (UVCs) – Usually have two or more agents
