DVCon Europe 2015 T01 Presentation

Advanced
UVM Tutorial
Taking Reuse to the Next Level
Mark Li6erick
Jason Spro6
Jonathan Bromley
Verilab & Accellera 1

Agenda
VerAcal & Horizontal Reuse of UVM Environments

Self-Tuning FuncAonal Coverage
- Strategy & ImplementaAon
AdapAve Protocol Checks

- ConguraAon Aware AsserAons
ConguraAon Object EncapsulaAon &

Appropriate cong_db Usage
Parameterized Classes, Interfaces & Registers

Ver3cal & Horizontal Reuse
of UVM Environments
Mark Li6erick


What is VericaAon Reuse?
Code reuse, is the use of exis3ng soAware,
or soAware knowledge, to build new soAware Wikipedia
VericaAon Reuse:
achieving verica3on goals through eec$ve code reuse
Specically:
reuse vericaAon components between environments
reuse vericaAon components between hierarchies
reuse vericaAon environments between projects
also reuse of base-classes, pa6erns & methodology
Several dierent paradigms:
referred to as horizontal and ver$cal reuse
Horizontal Reuse
Reusing vericaAon code without changing role
similar responsibiliAes, structure & use-case
Reuse s3mulus, checks, coverage & messages
same sAmulus API presented to user or test writer
Horizontal reuse usually means predictable use-case
typically achieved by conguraAon, adapAon and exibility
code is designed for more than one known use-case

Horizontal Reuse examples
Reuse verica3on component in mulAple envs
BLOCK A BLOCK B
C env C env
SB SB
S D M S D D S
M M M
SAME ROLE, DIFFERENT ENVIRONMENT DIFFERENT DUT
Reuse verica3on environment in mulAple projects

PROJECT X PROJECT Y
C env C env
SB SB
S D D S S D D S
M M M M
SAME ROLE & ENV, DIFFERENT CONFIG DERIVATIVE DUT

VerAcal Reuse
Reusing vericaAon code with a dierent role
dierent responsibiliAes, structure & use-case
Reuse s3mulus, checks, coverage & messages, but
sAmulus nested or layered inside high-level scenario
(with dierent user API)
or sAmulus not reused at all
(but checks, coverage & messages are)
Ver3cal reuse usually means unknown use-cases
typically achieved by encapsulaAon and extensibility
code is designed to allow the user to do other things

VerAcal Reuse Examples
Reuse passive block-level in top-level environment
PASSIVE
C BLK
SB
ACTIVE
C BLK
SB
M M
S D D S
M M
DIFFERENT STRUCTURE, NO STIMULUS

(STIMULUS COMES FROM ANOTHER UVC)
Reuse ac3ve component in top-level context

BLOCK A
C env
SB
S D
S D M
M
M
DIFFERENT ROLE, STIMULUS IS PART OF

HIGH-LEVEL SCENARIO (NOT SO RANDOM)
Reuse in UVM
UVM enables reuse, but does not guarantee it
SystemVerilog object-oriented program paradigm (OOP)
UVM provides reusable base-classes & methodology
UVM reuses standard soAware paKerns for uAliAes:
factory, conguraAon database, event pools, phases, ...
Reuse aects all aspects of environments, including:
architecture checks
conguraAon coverage
sAmulus modeling


Tutorial Content
DVCon EU 2014
DVCon EU 2015
Configuration Object
Encapsulation & Appropriate
config_db Usage STIMULUS Effective Stimulus
& Sequence Hierarchies
Demystifying the UVM CONFIG CHECKS

Configuration Database
Vertical & Horizontal Reuse

of UVM Environments UVM Adaptive Protocol Checks
- Config Aware Assertions
ARCHITECT
-URE COVERAGE
Parameterized Classes, Self-Tuning
Interfaces & Registers Functional Coverage -
Strategy & Implementation
MODELING
Behind the Scenes Advanced UVM Register

of the UVM Factory Modeling & Performance

AddiAonal UVM Concerns For
VERTICAL REUSE

Top-Level VericaAon Requirements
Top-Level has dierent concerns to block-level
funcAonal correctness & performance of full applica3on
interac3on of modules, sub-systems & shared resources
operaAon with all clock, power & test domains
connec3vity of all blocks & sub-systems
Cannot achieve closure on all these by looking only
at external pins in a complex top-level SoC
require checks, coverage & debug messages at all levels
NOT ENOUGH TO PROVE OPERATION OF THE PERFECT CHIP

(ALSO NEED TO ISOLATE & DEBUG FAILURES EFFECTIVELY)

VerAcal Reuse
Three observaAons:
verAcal reuse is hard to prepare for due to
change of role and unknown use-cases EFFORT: HOW MUCH?
top-level environment o_en must be developed
in parallel with block-level TIME: SCHEDULE IMPACT?
verAcal reuse is eort for implementer and
only adds value for the re-user COST: WHO PAYS?
Reality check:
dont try to second guess everything the user might need
get structure right, validate operaAon & allow for adapAon
REUSE GUIDELINES RETROFITTING REUSE
AcAve/Passive OperaAon
Ac3ve components provide or aect the s3mulus
driven to the DUT, inuencing the sAmulus ow
Passive components do not provide or aect the
s3mulus in any way, they just observe
Ac3ve/Passive mode aects:
run-Ame architecture
funcAonal capability
error tolerance
debug capability

AcAve Block-Level
ACTIVE
LIB BLOCK
C S SB
ENV
MASTER SLAVE
C ENV C ENV
SVA
SVA
S D D S
VIF
VIF
DUT
INTERFACE
INTERFACE
REQ M M RESP
VIF
VIF
AGENT AGENT
S3mulus is provided by sequencers and drivers

proac3ve master generates request sAmulus
reac3ve slave generates response sAmulus
Checks performed by interfaces, monitors & scoreboards
Coverage is collected by monitors & scoreboards
Messages are generated by all components
Passive Block-Level
PASSIVE
SB BLOCK
C ENV
MASTER SLAVE
C ENV C ENV
SVA
SVA
DUT
INTERFACE
INTERFACE
REQ M M RESP
VIF
VIF
AGENT AGENT
No s3mulus is performed by passive components

sequencers and drivers are not even present
Checks are sAll performed by interfaces, monitors &
scoreboards
Coverage is sAll collected by the monitors & scoreboards
Messages are generated by the remaining components

Passive Reuse in Top-Level
ACTIVE
S LIB BLOCK-A TOP-LEVEL
C env
SB ENV
C
M M
if if
SB
BUS
env
S D
interface
A
BUS M
C agent OUT
env
ALL CHECKS, COVERAGE & MESSAGES REUSED M

TO
agentENSURE:
OUT
if
C
EFFECTIVE
TXRX
env
VALIDATION OF BLOCK IN TOP-LEVEL CONTEXT
COMPREHENSIVE
S D
TOP-LEVEL OPERATION AND DEBUG
interface
S RESP
TX M env
D S
interface
agent
SB M RESP
agent C
S D
interface
RX M
C agent
DUT TOP

AcAve/Passive Misuse
low-level UVC OK but env ignores ac3ve/passive
drivers post sequence items to scoreboard
drivers doing funcAonal 3meout checks
coverage dened in ac3ve components
congura3on updates from sequence or driver
important messages from drivers
error injec3on trac reported as a warning
passive components control end-of-test schedule
uncontrollable end-of-test scoreboard checks
...
AcAve/Passive Guidelines
(OBVIOUSLY) ACTIVE COMPONENT (NOT SO OBVIOUSLY) ACTIVE
IS NOT PRESENT IN PASSIVE MODE STIMULUS IS ALSO NOT PRESENT
complete env must consider ac3ve/passive
do not connect scoreboards to ac3ve components
perform funcAonal checks in passive comps
collect funcAonal coverage in passive comps CONFIG:
UPDATE PSEUDO-STATIC
NOT SEQUENCE, BUT MONITOR
generate important messages in p assive
NOT comps
REG WRITE, BUT PREDICT
update congura3on only from passive comps

promote warnings to errors in passive mode
do not control end-of-test from passive comps
allow disable for scoreboard end-of-test check
... BUS MAY STILL BE ACTIVE TOP-LEVEL SCENARIO DECIDES
INTERNAL
WHEN TOP SCENARIO COMPLETES WHEN TO END THE TEST
Problems of Scale
Top-level environment is already complex
IntegraAng many block-level environments
introduces addiAonal requirements:
build and integraAon encapsula3on
congura3on containment and consistency
namespace isolaAon and cohabita3on
BLOCK-LEVEL SUPPLIERS NEED TO MAKE THINGS

AS EASY AS POSSIBLE TO INTEGRATE AND REUSE

Problems of Scale
environment pulled together only in base-test

mul3ple dispersed cong objects and elds
mul3ple agent interfaces required for top-level
macro deni3ons have global scope
enumera3on literals and types without prex
inexible inappropriate low-level coverage
incorrect message verbosity resulAng in cluKer
...

Scale Guidelines
TEST IS NOT REUSED USER ONLY SETS TOP-CONFIG
BUT ENVIRONMENT IS WHICH PROPAGATES DOWN
encapsulate all sub-components in env not test

use hierarchical congura3on objects for env
combine mulAple I/Fs into hierarchical interfaces
avoid namespace collisions by using scope prex
encapsulate coverage in separate class for overload
apply more rigorous message verbosity rules
...
MESSAGE CLUTTER UNACCEPTABLE USER ONLY HAS ONE INTERFACE TO
WITH A LOT OF REUSED BLOCK ENVS INSTANTIATE & ADD TO CONFIG_DB

Un-Encapsulated Reuse
MANY COMPONENTS TO
LIB BLOCK-A BLOCK-B
INSTANTIATE
BLOCK-X
& CONNECT
ACTIVE
S
C C C
TOP-LEVEL
env env env ENV
SB M SB
if
C M M
if
M
if
if
M M M
if if M M
if
M
if
if if
SB
BUS
env
S D
A B
interface
MANY INCONSISTENT
C
BUS CONFIG
agent
M
X OUT
OBJECTS & FIELDS TO MAINTAIN env
MANY SMALL
M
agent INTERFACES
OUT
TO
if
C
TXRX INSTANTIATE & SET IN CONFIG_DB
env
S D
interface
S RESP
TX M env
D S
interface
agent
SB M RESP
agent C
S D
interface
RX M
C agent
UN-ENCAPSULATED REUSE
DUT TOP IS ERROR-PRONE,
HARD TO MAINTAIN & TOO MUCH EFFORT

Encapsulated Reuse
ACTIVE
S LIB BLOCK-A BLOCK-B BLOCK-X TOP-LEVEL
C env C env C env
SB SB ENV
M
C M M M
M M M
M M M
SB interface interface interface
BUS
env
BLOCK-LEVEL ENV
S D
A B ENCAPSULATION
interface
HIERARCHICAL
C
CONFIG
BUS
agent
M
X OUT
(TOP CONTROLS BLOCKS, env
BLOCKS CONTROL UVCS) HIERARCHICAL

M OUT
INTERFACE
if
agent C
TXRX (1 INST & 1 SET IN CONFIG_DB)
env
S D
interface
S RESP
TX M env
D S
interface
agent
SB M RESP
agent C
S D
interface
RX M
C agent
PROPER ENCAPSULATION MAKES VERTICAL REUSE
DUT TOP
OF MANY BLOCK-LEVEL ENVS A FEASIBLE PROPOSITION

What is the Cost of Reuse?
AddiAonal eort in verica3on components
architectural concepts are provided by methodology
shortcuts & quick xes save Ame in iniAal project...
...but in the long term all bad coding style costs money
eort here benets both supplier and reuser
AddiAonal eort in verica3on environments
packaging environment, cong, interfaces all costs eort
eort here only really benets reuser
Total cost is relaAvely low but not zero
REUSE DOES NOT COME FOR FREE YOU MUST DO SOMETHING !

Reality Check
ObservaAon: since reuse does not come for free...
... it will not be correctly implemented in rst instance!
Specically:
rst project implemenAng block-level has other priori3es
top-level project needs to start in parallel with block-level
second project using the block should factor in the costs
trade-o reuse costs verses design from scratch
trade-o reuse costs verses quality & debug improvements
architectural xes for reuse should be retro;ed to source
(since working regression provides the best cross-check)

What is Retrofng?
RetroZng refers to the addi3on of new technology
or features to older systems Wikipedia
Retrofng Reuse:
adding reuse capability to an exisAng component or
environment that does not yet support reuse
Specically:
xing a vericaAon component to comply with guidelines
re-architec3ng a block-level environment for verAcal reuse
...aKemp3ng reuse of an environment for the rst Ame!


Strategy for Retrofng
First, determine what you have
probably supplied documentaAon will not be good enough
print & review the topology, cong and factory sefngs
Next, determine scope of rework
acAve/passive build control or major scoreboard reconnect?
Implement changes in block-level environment
run passing block-level regressions throughout
validate passive operaAon at block-level with shadow instance
Use in the top-level environment
ensure top-level conAnues to run with no bad side-eects
ensure block-level checks, coverage and messages work
VALIDATE PASSIVE MODE USING BLOCK-LEVEL REGRESSIONS

Passive Shadow
TWO INSTANCES OF THE SAME ENVIRONMENT SHADOW PASSIVE
ONE IN ACTIVE MODE, ONE IN PASSIVE MODE ENVIRONMENT
BLOCK-LEVEL
PASSIVE BASE TEST
BLOCK
C ENV
SB
NORMAL ACTIVE
M
if
M
if
ENVIRONMENT
ACTIVE
LIB BLOCK
C S SB
ENV
MASTER SLAVE
C ENV C ENV
SVA
SVA
S D D S
VIF
VIF
DUT
INTERFACE
INTERFACE
REQ M M RESP
VIF
VIF
AGENT AGENT
PROVE FUNCTIONALITY USING A PASSIVE SHADOW ENV

FOR UP-FRONT OR RETROFITTED PASSIVE OPERATION

References and Further Reading
Advanced UVM Tutorial
Verilab, DVCon Europe 2014, www.verilab.com/resources
Advanced UVM Register Modeling
Theres More Than One Way To Skin A Reg
M.Li6erick & M.Harnisch, DVCon 2014,
www.verilab.com/resources
Pragma$c Verica$on Reuse in a Ver$cal World
M.Li6erick, DVCon 2013, www.verilab.com/resources

QuesAons
Accellera Systems Initiative 31

Self-Tuning Coverage
Jonathan Bromley

Overview
Coverage
Coverage reuse
reuse needs
needs SELF TUNING in response to
configuration, parameters etc
exibility,
exibility, congurability
congurability
Coverage can mislead! See Verilab papers DVCon-US 2015

Coverage can mislead! and suggestions in this tutorial
SV covergroups are not

SV covergroups are not More detail and recommendations
easy to congure later in this tutorial
easy to congure
SV covergroups are not More detail and recommendations
SV covergroups
easy to recongure are not later in this tutorial
easy to recongure

COVERAGE GUIDELINES

Coverage EncapsulaAon
Coverage should be encapsulated for maintenance
isolate coverage code specic purpose, o4en verbose
separate class for coverage
each coverage class should be in its onot
wn e le
xtensible, no factory
minimize SV asserAon-based coverage
but architecture of coverage classes needs care

more details in later secAons

ImplementaAon OpAons in SV
Coverage in a subscriber class
Extend a component to add coverage groups
InstanAate a coverage class in some
component

MASTER ENV
environment structure
Extend a component to add coverage Cfg groups
Sqr Driver
InstanAate a coverage class in some
class ... extends uvm_subscriber#(dvcon_txn);
AGENT
Monitor
component
dvcon_txn cov_txn; no n eed f or d eep c opy
covergroup cg;
...
Coverage
coverpoint cov_txn.size {...}
... subscriber
endgroup
function void write(dvcon_txn t);

cov_txn = t;
cg.sample();
endfunction

inheritance
class dvcon_cov_monitor extends dvcon_monitor;
InstanAate a coverage class in some component
ùvm_component_utils(dvcon_cov_monitor)
MASTER ENV
Cfg
Sqr Driver
covergroup cg;
... AGENT
Monitor
endgroup can be sampled at any point in the code
... has access to all class members Cover
code
uvm_factory f = uvm_factory::get();
f.set_type_override_by_type (
dvcon_monitor::get_type(),
dvcon_cov_monitor::get_type()
);
no override, no coverage!

composi;on
InstanAate a coverage class in some component
MASTER ENV
Cfg
class dvcon_cov extends uvm_component; or uvm_object Sqr Driver
ùvm_component_utils(dvcon_cov)
AGENT
dvcon_monitor p_monitor; Monitor
covergroup cg;
coverpoint p_monitor.value {...} Cov
... object
function new(string name, uvm_component parent);
back
super.new(name, parent); pointer
$cast(p_monitor, parent);
cg = new();
endfunction No instance, no coverage!

ImplementaAon OpAons - review
Coverage in a subscriber class environment structure
restricted to contents of a single object (transacAon,

transacAon-set)
but otherwise provides good isolaAon inheritance
extend monitor class to add cannot

coverage groups
factory-replace
exible, but limits TB structure coverage alone
instanAate correct monitor type, composi;on
else coverage missed!
instanAate coverage class in another component
coverage class has handle to component, sees all contents
Best choice depends on application!
allows all coverage implementaAon including control/
Aming Verilab & Accellera 40
most exible soluAon
Coverage Is Distributed
Coverage of individual transacAons: easy but insucient
cover each txn from monitor protocol coverage
DUT behaviour coverage is also important, but sampling
and data gathering likely to be distributed across...
parts of verif env
acAvity on other interfaces
register state and changes
end-to-end matching
Ame
what else happened during the life of this txn/instrucAon/...?
DUT state at start, end, other key points in txn lifeAme?

Coverage from many places contributes to verif plan
assertion Coverage of end-to-end cross with system-wide concerns
coverage behaviours and checks (reset, congestion, mode changes...)
LIB ENVIRONMENT
C S SB
configuration
coverage MASTER SLAVE
C ENV C ENV
SVA
SVA
S D D S
VIF
VIF
DUT
INTERFACE
INTERFACE
REQ M M RESP
VIF
VIF
AGENT AGENT
protocol DUT internals and protocol

coverage register coverage coverage

Coverage from many places contributes to verif plan
Encapsulate! cross with system-wide concerns
(reset, congestion, mode changes...)
Many connecAons
may be required
System Monitor
with Coverage
LIB ENVIRONMENT
C S SB
MASTER SLAVE
C ENV C ENV
SVA
SVA
S D D S
VIF
VIF
DUT
INTERFACE
INTERFACE
REQ M M RESP
VIF
VIF
AGENT AGENT

Coverage Tuning
Modify the coverage model to suit our requirements
for example exhausAve block-level coverage not
appropriate for top-level vericaAon requirements, so
reduce scope
Reuse the same mechanism for sampling coverage
this is built into the component implementaAon
fully idenAes what cover points are sampled and when
Redene the coverage groups and coverpoints
modify the number of coverpoints in exisAng cover group
modify range and condiAons of exisAng coverpoint bins
e uses AOP to redene exisAng coverpoints
SystemVerilog uses OOP f44
Verilab & Accellera actory to replace exisAng class
IMPLEMENTING FLEXIBLE
COVERAGE

Making Coverage Flexible
TradiAonal approaches to congurable points/bins
sample()
enum {normal,wrapper
fizz, m ap sampled
buzz, fizzbuzz} data
fb;to coverage-
friendly
covergroup
bit value
this_bit;
cg;
coverpoint fb;
sample()
int bit_num;
... enum
typedef
covergroup
wrapper
{normal,
cg;
mulAple
fizz, buzz, sample()
fizzbuzz} can bfb_e;
e useful
endgroup
int x;
coverpoint
coverpoint
function
covergroup ecg;
xpression
this_bit; is the result of a funcAon
sample(int x);
coverpoint bit_num;
if (x%15 ==to_fb(x);0) fb = fizzbuzz;
covergroup
coverpoint
cross
else c onstructor
this_bit, bit_num;
...if (x%3==0) fb = fizz;
args used to shape bins
endgroup
module
else if
endgroup
function
else
p arameters
(x%5==0) fb
sample (bit u sed
= buzz;
[31:0]
fb = normal;
to x);
shape bins
function to_fb(int x);
for (bit_num = 0; bit_num < 32; bit_num++) begin
SV gotchas:
cg.sample();
ifthis_bit
(x%15 ===0)
endfunction
else
x[bit_num];fizzbuzz;
return
if (x%3==0) return fizz;
cg.sample();
"i"
else
end doesn't remove
if (x%5==0) a bin, buzz;
return just suppresses a sample
else return normal;
endfunction
Eects
endfunctionof illegal, ignore, default o_en misunderstood

Recent Language Enhancements
Available SV-2012 opAons:
bin with() funcAon (value lter)
bin set expression (value list specicaAon)
cross bin with()/matches (tuple lter, match
threshold)
cross bin set expression (queue of value tuples)
Many scope visibility gotchas
good examples are hard to nd
meanwhile, read LRM carefully and try small test examples
Patchy tool support
with() funcAons are widely supported
set expressions in some tools
Bin SpecicaAon Improvements
Illegal cross bins example taken from a real-world
problem: N bits
active 1 0 1 0
Illegal if active==0 or iillegal
f active==ready
example ready 0 1 1 0
Illegal if active has any bits set
that are not set in ready
covergroup cg_active_ready(int Nbits); Easy in SV-2012!
...
binsof expressions: messy, inexible
active_X_ready: cross active, ready {
function CrossQueueType all_illegals(int n);
for (int R=0; R<(1<<n); R++)
for (int A=0; A<(1<<n); A++)
if ( A==0 || A==R || (A & ~R)!=0 )
all_illegals.push_back( '{A,R} );
endfunction
illegal_bins bad_active = all_illegals(Nbits);
}
self-tuning for Nbits
endgroup
RECONFIGURABLE COVERAGE

Congurable Coverage
Any good reusable VC or env has a congura3on
object
Can we use this cong object to tune coverage?
YES, but there are challenges:
covergroup must be created in a class's constructor
this is too early in a UVM component; cong is not yet
known
Following slides oer two soluAons
1. wrap covergroup in uvm_object, get cong from UVM
cong DB
straightorward
2. embedded class constructed
Verilab & Accellera 50 much later, a_er cong is
known
Making It Congurable
Covergroup in a component can't be congured:
class dvcon_monitor extends uvm_monitor;
covergroup dvcon_cg(int max); ...; endgroup
function new(string name, uvm_component parent = null);
super.new(name, parent); configuration not yet available
dvcon_cg = new(...);
Cong informaAon is available much later

function void build_phase(uvm_phase phase);
get automa;c cong
super.build_phase(phase);
dvcon_cg = new(...);
illegal! must be in constructor
...
We need a workaround...

Congurable Coverage Roadblock
Key problem:
CG must be created in enclosing class's new()
but...
UVM classes have fixed constructor arguments
SoluAon 1: constructor gets info from cong_db before CG new

OK for uvm_object, supports factory
Parent object must prepare cong_db entries before creaAon
Unhelpful for uvm_component cong info may not be available
SoluAon 2: Encapsulate CG in a non-UVM class
pass cong in constructor arguments good for dedicated
factory cannot replace a non-UVM class coverage components

Workaround 1: Coverage Object
class my_component...
component needs
...
configurable coverage
dvcon_cov cov_wrap;
string cov_name = "cov_wrapper";
function void start_of_simulation_phase(...);
dvcon_cov_cfg cfg = new("cov_cfg");
... populate cfg object coverage object can be
uvm_config_db#(dvcon_cov_cfg)::set( factory-overridden
null, cov_name, "cfg", cfg);
cov_wrap = dvcon_cov::type_id::create(cov_name);
endfunction class dvcon_cov extends uvm_object;
... ùvm_object_utils(dvcon_cov)
late config covergroup dvcon_cg(int max); ... endgroup
and creation dvcon_cov_cfg cfg;
function new(string name = "");
super.new(name);
uvm_config_db#(dvcon_cov_cfg)::get(
null, name, "cfg", cfg);
dvcon_cg = new(cfg.max);
endfunction
endclass coverage wrapper class
Workaround 2: Coverage Wrapper
For easy factory replacement, component is
coverage
class o
dvcon_txn_cvg nly! extends uvm_subscriber #(dvcon_txn);
ùvm_component_utils(dvcon_txn_cvg) register with
class
class cov_wrapper;
cov_wrapper; factory
function
function new(string
new(string name,
name, dvcon_config
dvcon_config cfg);
cfg); ......
...
...
nested (local) class definition
endclass
endclass
dvcon_config cfg;
cfg set from above in build_phase or later
cov_wrapper cov;
virtual function void create_coverage();
do not call until
cov = new({get_full_name(), ".cov"}, cfg); cfg is ready
endfunction
virtual function void write(dvcon_txn txn);
cov.sample(txn);
endfunction
...

Coverage Wrapper Details
Delegate sampling to virtual methods for easy
extension
class
cov_wrapper; arbitrary covergroup arguments
used to configure bin shapes
dvcon_txn txn;
covergroup dvcon_cg(int max);
cp_len: coverpoint txn.length {
bins tiny[] = {[0 :3 ]};
bins mid = {[4 :max-4]};
bins limit[] = {[max-3:max ]};
}
endgroup
function new(...); ...; endfunction
virtual function void sample(dvcon_txn t);
txn = t; no need for object copy
dvcon_cg.sample(); txn is used only during sample()
endfunction
endclass

Congurable Coverage Component
SUMMARY
nested (wrapper) class contains covergroup(s)

not a uvm_object arbitrary constructor signature
OK
nested-class object can be constructed any Ame
postpone unAl cong is fully known
component encapsulates responsibility for:
understanding and preparing conguraAon
construcAng nested-class object
data collecAon and sampling
prepare for extension, factory applicability
Reference
Guidance on coverage design:
avoid lies
maximise eecAveness

Adap3ve Protocol Checks
ConguraAon Aware AsserAons
Mark Li6erick


IntroducAon
Mo3va3on
inconsistent SVA setup across clients & projects
many protocols where adapAve SVA required
SVA encapsula3on in UVM
why, what & where?
Techniques for making SVA congura3on-aware
why & how?
Techniques for making SVA phase-aware
automaAcally self-conguring SVA checks
iniAal build and dynamic run-Ame conguraAon

Distributed UVC Checks
Types of UVC checks:
signal protocol and Aming
transac3on content and funcAonal correctness
transac3on comparison and relaAonships
Each is handled by dierent component
ENV
All checks belong to UVC
UVC
C S D SVA
VIF
DUT Concurrent assertions are

I/F
M
VIF
SB AGENT not allowed

in SystemVerilog classes
TRANSACTION TRANSACTION SIGNAL

COMPARISONS CONTENT PROTOCOL

Check ConguraAon & Control
All checks can be aected by: class my_monitor ...
if (checks_enable)
control knobs (e.g. checks_enable) trans.check_crc();
cong elds (e.g. cfg.mode)
class my_monitor ...
ConguraAon object elds can be: trans.check_parity(
cfg.odd_even
constant a_er build-phase );
dynamic during run-phase

class my_test ...
uvm_config_db#(my_config)::set
class my_monitor ...
(this,"*","cfg",cfg);
if (condition)
// update config uvm_config_db#(bit)::set
cfg.speed_mode = FAST; (this,"*","checks_enable",0);

SVA ConguraAon & Control
sequence s_fast_transfer;
REQ ##1 !REQ[*1:4] ##0 ACK;
range operators
endsequence
must be constants
sequence s_slow_transfer;
REQ ##1 !REQ[*3:10] ##0 ACK;
endsequence
CONTROL no class variables in
property p_transfer; KNOB
@(posedge CLK) concurrent assertions
disable iff (!checks_enable)
REQ |->
if (cfg_speed_mode == FAST)
s_fast_transfer; cfg.speed_mode is not allowed
else CONFIG
s_slow_transfer; FIELD
endproperty local variables used for SVA
a_transfer:
assert property (p_transfer) cfg copied to local variables
else $error(illegal transfer);

SVA Interface
config db
VIF
config_db::get config_db::set
ENV TESTBENCH
UVC MODULE this interface is required
AGENT I/F for UVC-DUT signals
M VIF D VIF +SVA
... but what about SVA?
DUT
OTHER AGENTS
OTHER
I/F
OTHER UVCS

SVA EncapsulaAon
interface my_interface;
Lines of Code
// local signal definitions
// modport declarations
// clocking blocks
Signal
// bus-functional methods ConnecAons
SVA Checks
// support code for SVA
// property definitions
// assertion statements
SVA checks create clutter
endinterface
in interface construct
SVA code is verbose, complex & not related to signal communication
=> isolate and encapsulate SVA

Interface in Interface
interface my_interface; I/F interface my_sva_checker(
// local signals SVA // signal ports
logic CLK; input logic CLK,
logic REQ; input logic REQ,
logic ACK; input logic ACK,
logic [7:0] DATA; input logic [7:0] DATA
logic OTHER; );
... // support code
// modports, etc. // properties
... implicit instantiation // assertions
// protocol checker endinterface
my_sva_checker
sva_checker(.*);
ports have same name as interface signals
endinterface (but can be a subset)
required signal subset well encapsulated
module not allowed inside interface => use interface

SVA ConguraAon
UVC TESTBENCH MODULE
AGENT
C INTERFACE
MON VIF
C SVA C
C DUT
interface my_sva_checker(...);
CONTROL
// control knobs KNOBS
bit checks_enable = 1; No class variables inside
// config object CONFIG concurrent assertions
my_config cfg; FIELDS
// local variables for SVA
class variables are
my_speed_enum cfg_speed_mode;
int unsigned cfg_max_value;
allowed in support code
bit cfg_data_en;
// properties and assertions... Interface is not a
// update local vars from cfg... phased component
endinterface
when is config class built?
Method API
TESTBENCH MODULE
UVC INTERFACE
AGENT
C SVA C
MON VIF
C DUT
C
push CFG from class environment to SVA interface
manual operation and only partially encapsulated by interfaces

Interface Methods
interface my_sva_checker(...); INTERFACE
...
MON
function void set_config VIF
SVA C
(my_config cfg);
cfg_speed_mode = cfg.speed_mode; C
cfg_max_value = cfg.max_value;
cfg_data_en = cfg.data_en;
endfunction required fields well encapsulated
function void set_checks_enable internal SVA details well hidden

(bit en);
checks_enable = en; interface my_interface;
...
endfunction function void set_config(my_config cfg);
...
endinterface sva_checker.set_config(cfg);
endfunction
user API via VIF methods function void set_checks_enable(bit en);

sva_checker.set_checks_enable(en);
endfunction
...
endinterface
API IniAal ConguraAon
call set_* methods
could be done in agent or monitor via virtual interface
after build and connect
class my_monitor extends uvm_monitor;

...
function void end_of_elaboration_phase(...);
...
// set interface config after build
vif.set_config(cfg);
vif.set_checks_enable(checks_enable);
endfunction
...
endclass
must be after VIF assigned

API Dynamic ConguraAon
call set_config
via virtual interface
must be PASSIVE component when update required
class my_monitor extends uvm_monitor;

...
task run_phase(...);
forever begin
...
if (cfg updated) vif.set_config(cfg);
end
endtask
endclass additional work for monitor
hard to debug if done wrong

Phase-Aware Interface
TESTBENCH MODULE
UVC INTERFACE
AGENT
C SVA C
MON VIF
C DUT
C
reference CFG from class environment inside SVA interface
automatic and fully encapsulated in interface

Class Inside SVA Interface
class is UVM phased component UVC INTERFACE
SVA C CLASS
locally declared class can see
all local variables in interface
// declare local variables (cfg, checks_enabled, etc.)
...
class checker_phaser extends uvm_component;
// use local variables (cfg, checks_enabled, etc.)
// use UVM phases (build, connect, run, etc.)
endclass no component_utils if multiple instances required
(cant
// construct register
unique same type
instance multiple class
of phaser times with factory)
// (at the top-level under uvm_top)
checker_phaser m_phase = new($psprintf("%m.m_phase"));
endinterface
unique name required for multiple instances
unique name provides better debug messages

Parallel Phases
SVA interface class in parallel with main env under uvm_top
UVM_TOP
UVM phases run in parallel
ENV SVA UVM phase
CLASS CLASS
build both build phases complete before

either connect phase starts
connect
... but order of build phase
elaboration completion cannot be predicted!
run potential race scenario

SVA Class IniAal ConguraAon
use end_of_elaboration_phase to avoid race condition
class checker_phaser extends uvm_component;

...
function void end_of_elaboration_phase(...);
...
if (!uvm_config_db#(my_config)::get(this,","cfg,cfg))
ùvm_fatal(CFGERR,no my_config cfg in db)
void'(uvm_config_db#(bit)::get cfg must be

(this,","checks_enable,checks_enable)); provided by db
cfg_speed_mode = cfg.speed_mode; checks_enable may

cfg_max_value = cfg.max_value; be overloaded by db
endfunction
endclass
copy required cfg fields to
local variables for use in SVA
required cfg fully encapsulated no demands on monitor class
Class Dynamic ConguraAon
...
detect change
always @(cfg.speed_mode or cfg.data_en) begin
cfg_speed_mode = cfg.speed_mode; in cfg object
end
always@ and always_comb in do not work
endinterface since cfg is null at start of simulation
class checker_phaser ...; use run_phase to check for

...
dynamic cfg changes
task run_phase(...);
...
forever begin only required dynamic cfg fields
@(cfg.speed_mode or cfg.data_en) begin
cfg_speed_mode = cfg.speed_mode;
end
forever @* and @(*) do not work
ùvm_info(CFG,cfg updated,UVM_LOW)
end (cfg object does not change
endtask only fields inside the object)
endclass
Conclusion
PracAcal suggesAons for SVA encapsula3on
basic encapsulaAon inside interface
Demonstrated congura3on-aware SVA
method API with demands on UVC class
phase-aware SVA checker with embedded class
Successfully used in many UVM projects
Validated with mul3ple tools in dierent clients

References and further reading
SVA Encapsula$on in UVM Enabling Phase and
Congura$on Aware Asser$ons

QuesAons

ConguraAon Object EncapsulaAon
& uvm_cong_db Usage
Jason Spro6

Agenda
Basic syntax refresher
EncapsulaAon of conguraAon data
AutomaAc conguraAon revisited
Accessing conguraAon entries (more examples)
Care with conguraAon objects
Conclusion & References


BASIC SYNTAX AND USAGE
REFRESHER

Basic Syntax
typedef uvm_config_db#(uvm_bitstream_t) uvm_config_int;
typedef uvm_config_db#(string) uvm_config_string;
typedef uvm_config_db#(uvm_object) uvm_config_object;
typedef uvm_config_db#(uvm_object_wrapper) uvm_config_wrapper;
class uvm_config_db#(type T=int) extends uvm_resource_db#(T)
uvm_config_db#(T)::set(...) set() only modifies database

uvm_config_db#(T)::get(...) get() modifies target variables
uvm_config_db#(T)::exists(...)
uvm_config_db#(T)::wait_modified(...)
automatic configuration is done by uvm_component::build_phase() not the database

ENCAPSULATION OF
CONFIGURATION DATA

UVC/Environment ConguraAon
ENV
seq lib
UVC_BUS C Easy to congure from a test or other
VS

REG
P

S C part of environment (e.g. callbacks)
MODEL A D M SCOREBOARD
Manage diverse conguraAons
UVC_STXRX
UVC_PRX Manage funcAonal/structural changes
RX D S C
C S D
TX
1-4
RX
M Manage cross cufng conguraAons
M
VS
MY
RX TX DUT TX UVC_PTX
S D
1-4 D S C
M
M
Focused on UVC funcAonality not register elds

Usability: amount of work to congure, synchronize and manage
Extensibility: make it easy to add new funcAonality
Maintainability: modify without breaking user code

A Poor Cong API Example
class prx_cfg extends ... In ENV config we'd probably wrap it
// encapsulate UVC vars Hide the gazillions of set() calls
// partition nicely Limit exposure to implementation vars
// maybe add some methods And make a more useful API
...
enclass
Nice if someone had done
seq lib
ENV that here in the first place
UVC_BUS
VS P
C
REG S C
MODEL

A D M
'uvm_component_utils_begin(top_env)
SCOREBOARD
'uvm_field_int(m_active_ch,)
'uvm_field_int(m_max_ch,)
UVC_PRX
UVC_STXRX 'uvm_field_int(m_twait_min,)
TX RX RX D S C
C S D
1-4 M
'uvm_field_int(m_trespto_max,)
M
VS
MY // and 50 others like that
DUT TX
S D
RX TX UVC_PTX
'uvm_component_utils_end
1-4 D S C
M
M
PLEASE NO !

A Be6er Cong API Example
REG MODEL callback uses config API
R1
MEM if(field.write(val))
R2 rx = extracted_from(val);
... cfg.set_active_rx_chans(rx);
MAP RN
Takes care of lower level details and limits
ENV
seq lib exposure to implementation (config variables)
UVC_BUS
VS P
C
REG S C
MODEL

A D M
// do some checking
SCOREBOARD
if (rx > this.max_chans)
ùvm_fatal(...)
UVC_STXRX
UVC_PRX
Check using
RX D S C
C S D
TX RX
M
// distrubite the data DUT param
1-4
M
MY prx_cfg.set_active_chans(rx);
VS
DUT TX
S D
RX TX UVC_PTX
stxrx_cfg.set_active_rx_chans(rx);
1-4 D S C
M
M
// Optional: notify change

Organizing ConguraAon
Structural Modal Shared
DUT params protocol event pools

TB features control memory models
Devices attached UVC specific registers
operational constants system-wide
max_chans if (rx_chans >

max_chans)
addr_width 2**AW-1
Configuration objects at the same level often have common configuration data
e.g. DUT parameter derived values

Events and Pool Example
uvm_event and uvm_event_pool can
Test
be shared via uvm_config_db
Top ENV
uvm_event_pool m_env2_ev_pool
Env 1 Env2
May be appropriate for upper level to
extract entries from pool for lower levels
Agent1 Agent2
Mon cfg.m_hard_reset_ev; // events set by

cfg.m_soft_reset_ev; // Env2 from event
Drv
cfg.m_frame_end_ev; // event pool
Chk
m_global_ev_pool.get("env2_hrst")
Using the event pool on lower levels (e.g. in the

agent) may expose context sensitive names

Using Discrete (Non-object) Entries
Rules of Thumb
When there is an exisAng standard
e.g. UVC is_acAve (acAve/passive) ag
Simple standalone funcAonal mode or feature
e.g. UVC's physical interface or protocol type
e.g. UVC performance mode (fast with no frills)
Aects other dependent conguraAons
Quick wildcard setup required
Not as easy with objects, as entries part of a collecAon
When run-Ame modicaAon unlikely
Avoid need for run-Ame ::get() uvm_cong_db calls

AUTOMATIC CONFIGURATION
OBJECTS AND ENUMS REVISITED

Some Important Cong DB Points
Look-ups come down to a string match
Entries disAnguished strictly by the type used in set()
For auto cong base types must be used in set()

some "hacked" excepAons, e.g. is_acAve
Build phase treated dierently

priority to highest set() in hierarchy

Sefng and Gefng Objects
set() using base type
required for auto-config set() using base type
::set() ::get() auto explicit both auto and get() work
type type cong ::get()
$cast to concrete type

uvm_object uvm_object required for explicit get()
uvm_object CONCRETE Only auto-cong works
CONCRETE CONCRETE
Only get() works
set() using derived type
CONCRETE uvm_object get() must use derived
Wrong
Recommend using uvm_config_object typedef

Use Objects Like This
my_config m_cfg;
...
uvm_config_object::set(..., "m_config", m_cfg);
set() and get() use uvm_object type
In the target component

'uvm_field_object(m_config, UVM_DEFAULT)
uvm_object tmp;
uvm_config_object::get(..., "m_config", tmp);
$cast(m_config, tmp); // back to original type
Explicit get() needs a cast to concrete type

Parameterized Classes Work Too
my_config#(XYZ) m_cfg;
...
uvm_config_object::set(..., "m_config", m_cfg);
set() and get() use uvm_object type

my_config#(XYZ) m_config;
'uvm_field_object(m_config, UVM_DEFAULT)
uvm_object tmp;
uvm_config_object::get(..., "m_config", tmp);
$cast(m_config, tmp); // back to original type
Explicit get() needs a cast to concrete type

Wildcard Matching By Name+Type
cfg_a m_cfg_a; Config entries with the same name but different types
cfg_b m_cfg_b;
uvm_config_db#(cfg_a)::set(null, "*", "m_cfg", m_cfg_a);
uvm_config_db#(cfg_b)::set(null, "*", "m_cfg", m_cfg_b);
Test Wildcard matching

name+type
Concrete types Env 1 Env2
cfg_a m_cfg cfg_b m_cfg
Agent1 Agent2
uvm_config_db#(cfg_a)::get(this, "", "m_cfg", m_cfg);
uvm_config_db#(cfg_a)::get(this, "", "m_cfg", m_cfg);
Possible but not recommended: breaks auto-config and a bit risky

Sefng and Gefng Enums
typedef uvm_config_db#(uvm_bitstream_t) uvm_config_int
::set() ::get() auto explicit
type type cong ::get() set() using integral type
both auto and get() work
Cast to USER enum type
cong_int cong_int required for explicit get()
cong_int USER Only auto-cong works
USER USER
Only get() works
USER cong_int Wrong
Recommend using uvm_config_int typedef

Use Enums Like This
uvm_config_int::set(..., "m_bus_sz", SZ16);
set() and get() use integral type

'uvm_field_enum(my_enum_t, m_bus_sz, UVM_DEFAULT)
uvm_bitstream_t tmp;
uvm_config_int::get(..., "m_bus_sz", tmp);
m_bus_sz = my_enum_t'(tmp); // back to original type
Explicit get() needs a cast to enum type
using convenience types is typically less hassle

ACCESSING CONFIG ENTRIES
(MORE EXAMPLES)

Link Visibility to a Component
We can link visibility to a sequencer (e.g. from a test)
uvm_config_db#(T)::set(this,"env.agent1.seqr", "err_cfg", m_err_cfg)
test1
We can use a sequencer as the
env context for uvm_config_db lookup
agent1
seq1 A sequence can lookup entry using
seq1
seqr seq handle to the sequencer
Sequencer itself doesn't need

to have the target variable
uvm_config_db#(T)::get(p_sequencer,"","err_cfg", m_err_cfg)

Globally Visible Tag
uvm_config_db#(T)::set(null,"ERRINJ::","err_cfg",m_err_cfg)
Auto config not possible Creates a pseudo namespace anyone in

hierarchy can use for lookup
agentTX seqTX1 agentRX seqRX1 Scoreboard
SEQR seqTX2 SEQR seqRX2
seqTXERR seqRXERR
Lookup using this tag
uvm_config_db#(T)::get(null,"ERRINJ::","err_cfg", tmp)
$cast(m_err_config, tmp); // back to original type
Limited wildcard options due to uvm_config_db issues

Link Visibility to Self
Dynamically created instance no parent available
test1 Build full path from enclosing component, plus instance
name yes the get() will be fragile
env
obj1 = my_class::type_id::create(
agent1
{this.get_full_name(),".obj1"}, this);
obj1
Fetch value inside the instance
uvm_config_db#(T)::get(null,this.get_name(),"m_val", m_val)
Example: setting the value from the test using the full path
uvm_config_int::set(this,"env.agent1.obj1", "m_val", m_someval)
Fragile due to path/instance names if set outside enclosing component

Cong Changes: Run-Ame & Reset
build_phase aAer build_phase
Highest in hierarchy wins Last wriKen wins
Auto conguraAon This applies in run_phase()
Done once Run-Ame phases may repeat
Cong changes possible
User must police changes
Using objects is easier
e.g. A repeated phase get() could fetch a value out of sync with
a register state OR race with a register callback
Nothing reset specific in uvm_config_db

CARE WITH CONFIG OBJECTS
REFERENCES AND CONTENTS

Care with Handles Local Copies
First set() in build_phase()
env_cfg1
uvm_config_db
@ref @ref
m_cfg
m_env_cfg
env_cfg2
Later set() in run_phase()
m_cfg points to env_cfg1 after first get() in build_phase()
m_copy_of_var = m_cfg.var1 m_cfg members

variables used
my_callback = new("...", m_cfg.agent1_cfg)
m_cfg pointing to env_cfg2 after later get() is not enough!

Users of original content may be out of date

Care with Handles MulAple Users
Test // originally set up multiple agents

set(this,"agent*","m_cfg", m_agent_cfg)
Top Env
? We can replace m_agent_cfg
Env 2 Env1 reference for Agent2 but where?
?
Agent1 Agent2
Mon
Multiple people may be using the same
Drv reference. It could be important to stay in sync.
Chk

CONCLUSION AND REFERENCES

Conclusions
The uvm_cong_db is quite simple, but can be used
many dierent ways consistency is advisable
Thought required to organize and encapsulate your
conguraAon data
There are advantages to using objects vs discrete entries
AutomaAc conguraAon can simplify things so try to
keep it working
There's nothing reset specic in uvm_cong_db
Some funky things are possible, but no always advisable


AddiAonal Reading & References
Gefng Started with UVM: A Beginners Guide, Vanessa Cooper, Verilab Publishing 2013
Accellera
h6p://www.accellera.org
DVCON2014: Advanced UVM Register Modelling:
h6p://www.verilab.com/les/li6erick_register_nal_1.pdf
DVCON Europe 2014: Advanced UVM Tutorial
h6p://www.verilab.com/les/verilab_dvcon_tutorial_a.pdf
Hierarchical Testbench ConguraAon Using uvm_cong_db:
h6p://www.synopsys.com/Services/Documents/hierarchical-testbench-conguraAon-using-uvm.pdf
ConguraAon in UVM: The Missing Manual (DVCON India 2014), Mark Glasser
h6p://dvcon-india.org/wp-content/uploads/2014/proceedings/1130-1300/D2M2-2-3-
DV_ConguraAon_in_UVM_Paper.pdf
VericaAon Academy:
h6ps://vericaAonacademy.com/forums/uvm/uvmcongdb-usage-big-confusion
h6ps://vericaAonacademy.com/cookbook/testbench/build#Sub-Component_ConguraAon_Objects


Parameterized Classes,
Interfaces & Registers
Mark Li6erick


IntroducAon to Parameters
In SystemVerilog parameters enable exibility
compile-3me specializa3on of code-base
e.g. RTL module with variable FIFO depth, bus width, etc.
e.g. vericaAon component with variable channels, etc.
ParameterizaAon enables horizontal reuse
e.g. same DUT RTL code in dierent project derivaAve
e.g. same vericaAon code adapAng to dierent projects
Parameterized code trades exibility with complexity
in RTL parameters are usually easy to deal with and simple
in vericaAon code the benets are less clear...
PARAMETERIZED PARAMETERIZED PARAMETERIZED
CLASSES INTERFACES REGISTERS
PARAMETERIZED CLASSES

Parameterized Classes
Parameterized classes are a good t for many cases:
extensive horizontal reuse for a set of derivaAves
UVM base classes (e.g. TLM, sequencer, driver, monitor,...)
But parameterizaAon is intrusive...
creates verbose code base (harder to read and maintain)
parameter prolifera3on is ubiquitous (all over the code)
all les need parameters just to idenAfy specialized types
When is it worth the eort?
parameterizaAon is a lot of eort for the developers
... but can be very good for the user of the code!

Non-Parameterized Setup DERIVATIVE-SPECIFIC ENV
DERIVATIVE-SPECIFIC DERIVATIVE-SPECIFIC
MY_ENV
REGISTER SEQUENCES seq lib REGISTER MODEL
(CLONE & MODIFY) C
VS MY
REG
REG
MODEL SHARED ENVIRONMENT
SHARED SEQUENCES
HAVE NO ACCESS TO seq lib
NOP_ENV
REGISTER FIELDS UVC_BUS

C
VS P
(SINCE FIELDS ONLY
BASE
S C
ACTIVE CHANNELS
MODEL A D M
IN DERIVED CLASS) SCOREBOARD HELD IN CONFIG
UVC_PRX
UVC_STXRX
TX RX RX D S C
C S D
1-4 M
M
VS
MY
RX TX DUT TX UVC_PTX
S D
1-4 D S C
M
M
SERIAL PARALLEL
CONFIG-AWARE MAX-FOOTPRINT
AGENTS & SEQUENCES INTERFACES
Parameterized Environment
REGISTER MODEL
OF PARAMETER TYPE SHARED ENVIRONMENT
SHARED SEQUENCES
HAVE ACCESS TO seq lib
P_ENV#(REG,T,R)
REGISTER FIELDS UVC_BUS

C
VS REG
P S C
(PARAMETERIZED) REG
MODEL
PARAMETERS
A D M SCOREBOARD
(REGISTER TYPE,
NUM CHANNELS)
UVC_PRX#(T)
UVC_STXRX#(T,R)
TX RX RX D S C
C S D
1-4 M
M
VS
MY
RX TX DUT TX UVC_PTX#(R)
S D
1-4 D S C
M
M
PARAMETERIZED PARAMETERIZED
AGENTS & SEQUENCES INTERFACES
Reuse of Parameterized Env
A FEW DERIVATIVE-SPECIFIC DERIVATIVE-SPECIFIC ENVS e.g. B12_ENV SETS:
REG TYPE = REG_B,
REGISTER SEQUENCES (SPECIALIZE PARAMETERS) NUM SERIAL TX = 1
NUM SERIAL RX = 2
A21_ENV B12_ENV
seq lib seq lib
P_ENV#(REG_A,2,1) P_ENV#(REG_B,1,2)
seq lib seq lib
UVC_BUS UVC_BUS
VS P
C VS P
C
REG_A S C REG_B S C
REG REG
MODEL MODEL
A D M SCOREBOARD A D M SCOREBOARD
UVC_PRX#(2) UVC_PRX#(1)
UVC_STXRX#(2,1) UVC_STXRX#(1,2)
TX RX RX D S C TX RX RX D S C
C S D C S D
M M
M M
VS
A21 B12
VS
DUT TX TX
S D
RX TX UVC_PTX#(1)
S D
RX TX DUT UVC_PTX#(2)
D S C D S C
M M
M M
MASSIVE REUSE &

SHARED ENVIRONMENTS
AUTOMATIC TUNING:
(IDENTICAL CODE BASE)
WHATS NOT TO LIKE?
Generic p_env Environment
PARAMETER DECLARATION
class p_env #(type REG=uvm_reg_block, int T=1, int R=1)
extends uvm_env;
PARAMETER PROPAGATION
REG
my_reg reg_model; // register block base
p_env_sequencer #(REG) sequencer; // virtual sequencer
stxrx_env #(T,R) stxrx; // serial UVC
...
ùvm_component_utils_begin(p_env)
ùvm_component_param_utils_begin(p_env#(REG,T,R))
...
MUST USE *_PARAM_UTILS
function void build_phase(...); MUST USE PARAMETERIZED TYPES IN
... UTILS (OR YOU GET THE WRONG TYPE)
reg_model = REG::type_id::create(...);
my_reg::type_id::create(...);
sequencer = p_env_sequencer#(REG)::type_id::create(...);
p_env_sequencer::type_id::create(...);
stxrx = stxrx_env#(T,R)::type_id::create(...);
stxrx_env::type_id::create(...);
...
reg_model.build(); MUST USE PARAMETERIZED TYPES IN
... CREATE (OR YOU GET THE WRONG TYPE)
uvm_config_object::set(this, "*", "reg_model", reg_model);
...

uvc_stxrx Env/Agent/Comps
class stxrx_env #(int
extends
NT=1,
uvm_env;
int NR=1) extends uvm_env;
stx_agent #(NT)
tx_agent;
tx_agent;
srx_agent #(NR)
rx_agent;
rx_agent; PROPAGATE PARAMETERS
... THROUGHOUT HIERARCHY
class stx_agent #(int

extends
N=1)
uvm_agent;
extends uvm_agent;
stx_driver #(N)
driver;driver; INTRODUCE NEW PARAMETERS
s_monitor #(TX,N)
monitor;
monitor; AS REQUIRED (e.g. SHARED
virtual s_interface #(N)
vif; vif; MONITOR FOR TX AND RX)
...
class s_monitor #(s_dir_enum

extends uvm_monitor;
D=RX, int N=1) extends uvm_monitor;
...
s_transaction m_trans[N];
m_trans[4]; USE PARAMETERS AT LOW LEVELS
... (e.g. ARRAY SIZE, MESSAGES, ETC.)
if (D==TX)
ùvm_warning(...,error injected in Tx traffic to DUT)
else
ùvm_error(...,error observed
in DUT traffic)
in Rx traffic from DUT)
...

p_env Virtual Sequencer
PARAMETERIZE SEQUENCER TO GIVE SEQUENCES
ACCESS TO REG_MODEL OF CORRECT TYPE
class p_env_sequencer #(type REG=uvm_reg_block)

extends uvm_sequencer;
my_reg
REG reg_model;
reg_model;
// //
handle
handle
to to
register
register
model
model
ùvm_component_param_utils_begin(p_env_sequencer #(REG))
ùvm_component_utils_begin(p_env_sequencer)
ùvm_field_object(reg_model, UVM_ALL_ON | UVM_NOPRINT)
...
function void build_phase(...);
super.build_phase(...); DONT FORGET
if (reg_model == null)
ùvm_fatal("NOREG", null handle for reg_model")
...

p_env Sequences
P_SEQUENCER MUST BE CORRECT TYPE
OR YOU GET RUN-TIME CAST FAIL ERROR
...SEQ CANNOT RUN ON SEQUENCER TYPE...
class p_env_base_seq #(type REG=uvm_reg_block)
extends uvm_sequence;
ùvm_declare_p_sequencer(p_env_sequencer #(REG))
ùvm_declare_p_sequencer(p_env_sequencer)
ùvm_object_param_utils(p_env_base_seq)#(REG))
ùvm_object_param_utils(p_env_base_seq
...
SEQUENCES MUST EXTEND CORRECT BASE TYPE
=> SEQUENCES MUST BE PARAMETERIZED
class p_env_init_seq #(type REG=uvm_reg_block)
extends p_env_base_seq
p_env_base_seq;#(REG);
p_env_reset_seq #(REG)
reset_seq;
reset_seq;
// drive
//reset
drive reset
p_env_wait_cfg_seq #(REG)
cfg_seq;
cfg_seq;
// wait//cfg
wait
ackcfg ack
p_env_wait_ready_seq #(REG)
ready_seq;
ready_seq;
// wait//ready
wait ready
ùvm_object_param_utils_begin(p_env_init_seq #(REG))
ùvm_object_param_utils_begin(p_env_init_seq)
...
DONT EVER FORGET

DUT-Specic Environment
SPECIALIZE P_ENV ENVIRONMENT BY
SETTING ACTUAL PARAMETER VALUES
class a21_env extends uvm_env;

p_env env; // specific
p_env#(reg_a,2,1) env; //
environment
generic environment
ùvm_component_utils_begin(a21_env)
...
env = p_env#(reg_a,2,1)::type_id::create("env",
p_env::type_id::create("env", this); this);
...
DONT FORGET THIS EITHER ... OR REPLACE ALL OF THAT WITH

CONVENIENCE TYPE DEFINITION
typedef p_env#(reg_a,2,1) a21_env;

DUT-Specic Sequences
MUST EXTEND CORRECT TYPE
class a21_example_seq extends p_env_base_seq #(reg_a,2,1);

ùvm_object_utils(a21_example_seq)
... DEFINE CONVENIENCE TYPE
typedef p_env_base_seq #(reg_a,2,1) a21_base_seq;
class a21_example_seq extends a21_base_seq;

ùvm_object_utils(a21_example_seq)
USE CONVENIENCE TYPE
...
p_sequencer.reg_model.TX2_FIELD.write(status, 1'b0);
...
typedef p_env_init_seq #(reg_a,2,1) a21_init_seq;

typedef p_env_config_seq #(reg_a,2,1) a21_config_seq;
...
SHARED SEQUENCES MUST ALSO BE SPECIALIZED
TO RUN ON SPECIALIZED ENVIRONMENT SEQUENCER
=> DEFINE AND USE CONVENIENCE TYPES

DUT-Specic Tests
class test_example_seq extends a21_base_seq;
a21_init_seq init_seq; // init sequence
a21_config_seq cfg_seq; // cfg handshake
...
task seq_body(); SEQUENCES ARE ALREADY
ùvm_do(init_seq) SPECIALIZED BY TYPEDEFS
ùvm_do_with(cfg_seq, {...})
p_sequencer.reg_model.TX2_CFG_STAT.read(status, m_val);
...
NON-PARAMETERIZED SEQUENCES ALL RUN ON
OBJECTS & COMPONENTS ENVIRONMENT SEQUENCER
AT THE TOP-LEVEL
class test_example extends a21_base_test;
test_example_seq example_seq = new();
virtual task run_phase(...);
example_seq.start(tb.env.sequencer);
tb.env.reg_model.RX1_OFFSET_FIELD.write(status, 0);
...

ParameterizaAon Tips
Dont do it!
avoid parameterizaAon if possible
...but someAme it is an ideal t for horizontal reuse
It is hard to implement rst Ame round
but relaAvely easy to retrot
errors are all related to types specializaAon
bugs are all caused by bad parameter proliferaAon
so get the iniAal version working, then parameterize
Prac3ce makes perfect...
clone a working environment right now...
...and retrot parameterizaAon just for fun!

PARAMETERIZED INTERFACES

Normal Interfaces
class my_comp extends uvm_component;
config database virtual my_intf vif;
CIF
uvm_config_db#(virtual my_intf)
config_db::get config_db::set
::get(this,"","cif",vif);
BASE-TEST
ENV module testbench;

C S my_intf mif;
TESTBENCH MODULE
UVC my_dut dut(.ADDR(mif.addr),...);

C
initial begin
SVA
INTERFACE (MIF)
S D
VIF
DUT ::set(null,"*","cif",mif);
M
VIF
AGENT run_test();
end
Other AGENTs
interface my_intf();
Other OVCs
logic [31:0] addr;
...

Parameterized Interfaces
RTL Parameters o_en aect module ports
e.g. signal width (e.g. input logic [WIDTH-1:0] ADDR)
(but not the presence or absence of signal ports)
TempAng to parameterize the interface to match RTL ...
interface my_intf #(int
(); WIDTH=1)(); SIMPLE CHANGE TO
logic [WIDTH-1:0]
[31:0] addr;addr; ADD PARAMETER
... TO INTERFACE
module testbench; SIMPLE CHANGES TO

my_intf mif; mif;
my_intf#(32) SPECIALIZE INTERFACE
my_dut dut(.ADDR(mif.addr),...); AND SEND TO CONFIG_DB
initial begin
uvm_config_db#(virtual my_intf#(32))
my_intf)
NOTE THE INTERFACE
::set(null,"*","cif",mif);
TYPE IS SPECIALIZED
run_test();
IT IS NOT JUST my_intf
end

Using Parameterized Interfaces
Parameterized interfaces create a lot of superuous code
in structural components (monitor, driver, agent, env, ...), and in
func3onal objects (transacAon, sequences, scoreboard, predictor,...)
PARAMETERIZED
class monitor#(int W=1) extends INTERFACE
uvm_monitor;
ùvm_component_param_utils(monitor#(W)) PARAMETER
uvm_analysis_port #(trans#(W)) aport; PROLIFERATION
class trans#(int W=1) extends
virtual my_intf#(W) vif; uvm_sequence_item;
rand bit[W-1:0] addr;
class agent#(int W=1) extends uvm_agent;
ùvm_object_param_utils(trans#(W))
ùvm_component_param_utils(agent#(W))
monitor#(W) mon; class seq#(int W=1)extends
uvm_sequence#(trans#(W))
class env#(int W=1) extends uvm_env;
ùvm_object_param_utils(seq#(W))
ùvm_component_param_utils(env#(W))
agent#(W) agt;
e.g. ADD ONE PARAMETER
class test_env extends uvm_env; TO INTERFACE CHANGED
ùvm_component_utils(test_env) 43 LINES IN 11 FILES
env#(32) env;
PARAMETER SPECIALIZATION
Accessor Class
Alterna3ve for parameterized interfaces...
Uses object handle instead of virtual interface
classes support inheritance, interfaces do not!
HANDLES OF CAN REFERENCE OBJECT REGARDLESS OF INTERFACE
BASE TYPE OF ANY DERIVED TYPE PARAMETERIZATION
UVC TESTBENCH MODULE

C
INTERFACE
S D
BASE CLASS DEFINES embedded
DUT
accessor
ACCESSOR API: AGENT
M
object
set/get signal values
get parameter values
wait for N clocks CONCRETE CLASS IMPLEMENTS API:
... scoped within the interface instance
direct access to interface signals

Accessor Class Code
`define MAX_WIDTH 256 MAX-FOOTPRINT PARAMETER
...
typedef bit [MAX_WIDTH-1:0] t_uvc_data; ABSTRACT BASE CLASS
DEFINES ACCESSOR API
virtual class my_uvc_accessor extends uvm_object;DEFINES FULL API,

pure virtual function int get_data_width(); IS A LOT OF CODE,
pure virtual task wait_cycles(int N=1); RESTRICTED TO API
pure virtual function t_uvc_data get_data();
... GET HANDLE FROM CONFIG_DB
(LIKE VIF BUT A CLASS HANDLE)
class monitor extends uvm_monitor#(my_uvc_txn);
my_uvc_accessor accessor;
MONITOR & DRIVER USE VARIABLE
task get_data();
OF THE ABSTRACT TYPE TO DO
accessor.wait_cycles();
LOW-LEVEL ACCESSES
if (accessor.get_strobe()) begin
t_uvc_data data = accessor.get_data();
...

Accessor Class Interface
interface my_uvc_intf #(int DATA_WIDTH=32);
import my_uvc_pkg::*; PARAMETERIZED INTERFACE
bit [DATA_WIDTH-1:0] data;
clocking cb @(posedge clock); CONTAINS ACCESSOR CLASS
input #1step data;
... EXTEND ABSTRACT
endclocking BASE-CLASS &
class accessor extends my_uvc_accessor; IMPLEMENT METHODS
function t_uvc_data get_data(); return cb.data; endfunction
function int get_data_width(); return DATA_WIDTH; endfunction
...
endclass DIRECT ACCESS TO INTERFACE
function accessor get_acc(string name); VARIABLES & PARAMETERS
get_acc = new(name);
uvm_config_db#(uvm_object)::set(null, name, "accessor", get_acc);
endfunction
accessor acc = get_acc($sformatf("%m"));
endinterface
CREATE (WITH UNIQUE NAME) AT INITIALIZATION
TO AVOID RACE WITH UVM TEST START
Accessor Class Comments
Advantages:
supports polymorphic extensions to signal interacAon
highlights the limita3ons of virtual interfaces!
Disadvantages:
restricts how driver & monitor can access signals (API)
lot of code setup, duplicaAon & maintenance
not the standard UVM approach
Suitability?
some protocols that have to support mul3ple diverse I/Fs
wrapper methodology for legacy HDL transactors
... but not appropriate for most UVM environments

Maximum Footprint
Avoid parameterizaAon using maximum sized interface
o_en referred to as maximum footprint interface
INTERFACE NOT PARAMETERIZED
class my_config extends uvm_object;
interface my_intf(); rand int width;
logic [31:0] addr, data; constraint wc {soft width == 32;}
...
INTERFACE SUPPORTS MAX WIDTH class test_env extends uvm_env;
module testbench; cfg.randomize() with {width == 16;}
my_intf mif;
my_dut16 dut( UVC USES CONFIG TO
.ADDR(mif.addr[15:0]), CONSTRAIN OUTPUT VALUES
.DATA(mif.data[15:0]),...); & CHECK INPUT VALUES
initial begin (CAN BE UGLY BIT-SLICE CODE)
::set(null,"*","cif",mif); DUT IGNORES UNUSED INPUT BITS
run_test(); & UNUSED OUTPUT BITS ARE Z
end
DUT CONNECTS TO REQUIRED SLICE
Interface Wrapper
Maximum footprint can be enhanced with wrapper
parameterized interface wrapper for testbench module
contains a maximum footprint interface for class world
interface my_intf_wrapper PARAMETERIZED WRAPPER INTERFACE
#(int WIDTH=8, string INST=*, string FIELD=cif)();
import uvm_pkg::*; NON-PARAMETERIZED MAXIMUM
logic [WIDTH-1:0] addr, data; FOOTPRINT INTERFACE FOR UVC
my_intf mif();
assign mif.data[WIDTH-1:0] = data; // from DUT to UVC
ENCAPSULATE PARTIAL
assign addr = mif.addr[WIDTH-1:0]; // from UVC to DUT
SIGNAL ASSIGNMENTS
initial
uvm_config_db#(virtual my_intf)::set(null,INST,FIELD,mif);
ENCAPSULATE CONFIG
module testbench; FOR VIRTUAL INTERFACE
my_intf_wrapper#(16) ifw;
my_dut16 dut(.ADDR(ifw.addr),.DATA(ifw.data),...);
initial
EASY WRAPPER USE IN
run_test();
TESTBENCH MODULE
Interface Tips
Parameterized interfaces look good in theory,
but implementa3on is complex
If interface adapAon is only reason for parameters...
recommend you do not use parameterized interfaces
use the maximum footprint approach with wrapper
(or in some cases consider the accessor class soluAon)
If classes are parameterized for other reasons...
then use parameterized interfaces as well!

PARAMETERIZED REGISTERS

Generic Registers
Two approaches for register generaAon:
generate DUT-specic register model on-demand
(separate model for each derivaAve) MOST COMMON
registers are specialized in all representaAons APPROACH
(RTL, documentaAon, UVM register model)
code is simpler, but needs to be generated for each derivaAve
generate generic register model once for all DUTs
(one model that adapts to each derivaAve)
APPROPRIATE FOR
registers are generic in all representaAons RTL IP & UVC
(RTL, documentaAon, UVM register model) COMBO PACKAGES
code is more complex, harder to read, but is only generated once
PARAMETERIZED CONFIGURABLE
REGISTERS REGISTERS

Normal Registers
Fields, registers & blocks are generated on-demand
they are specialized for DUT-specic requirements
class my_reg extends uvm_reg;
ùvm_object_utils(my_reg) CREATE & CONFIGURE
virtual function void build(); EACH FIELD
my_field = uvm_reg_field::type_id::create(my_field");
my_field.configure(this, 32, 0, "W1R,1,'h0,1,1,1);
FIELD WIDTH USES A
class my_reg_block extends uvm_reg_block; GENERATED NUMBER
ùvm_object_utils(my_reg_block)
...
rand my_reg my_reg;
... CREATE, CONFIGURE
function void build(); & BUILD EACH REG
my_reg = my_reg::type_id::create(my_reg");
my_reg.configure(this, null, my_reg");
my_reg.build();
Verilab & Accellera 137 ALL GENERATED CODE

Parameterized Registers
Fields, registers and blocks are classes
they can be parameterized (e.g. width, default, etc.):
class my_reg #(int WIDTH=1) extends uvm_reg;
ùvm_object_param_utils(my_reg#(WIDTH)) FIELD WIDTH USES
virtual function void build(); PARAMETER
my_field = uvm_reg_field::type_id::create(my_field");
my_field.configure(this, WIDTH, 0, "W1R,1,'h0,1,1,1);
class my_reg_block #(int WIDTH=1) extends uvm_reg_block;

ùvm_object_param_utils(my_reg_block#(WIDTH))
...
PARAMETER
rand my_reg#(WIDTH) my_reg;
PROLIFERATION
...
(REG, BLOCK,...)
function void build();
my_reg = my_reg#(WIDTH)::type_id::create(my_reg");
my_reg.configure(this, null, my_reg");
my_reg.build();
Verilab & Accellera 138 ALL GENERATED CODE

e.g. ADD
Using Parameterized Registers ONE FIELD

PARAMETER
CHANGED
30 LINES
ParameterizaAon is invasive & ubiquitous IN 6 FILES
all classes referencing model become parameterized
or specialize the required type by xing the parameter
PARAMETER
class reg_sequencer#(int W=1) extends uvm_sequencer;
my_reg_block#(W) reg_model; PROLIFERATION
IN MIDDLE LAYERS
ùvm_component_param_utils(reg_sequencer#(W))
(SEQ,SEQR,AGT,ENV,...)
class reg_base_seq#(int W=1) extends uvm_sequence;
ùvm_object_param_utils (reg_base_seq#(W));
ùvm_declare_p_sequencer(reg_sequencer#(W))
class top_vsequencer extends uvm_sequencer;

reg_sequencer#(32) reg_sequencer; PARAMETER
ùvm_component_utils(top_vsequencer) SPECIALIZATION
IN UPPER LAYER
class my_reg_seq extends reg_base_seq#(32); (SEQ,SEQR,ENV...)
ùvm_object_utils (my_reg_seq);
Verilab & Accellera 139 ALL USER CODE

ConguraAon-Aware Registers
AlternaAve generic register model
build & congure based on conguraAon object elds
no parameters or compile-Ame denes
Problem:
uvm_reg_block is a uvm_object not a uvm_component
so it does not follow UVM phasing for safe conguraAon
SoluAon:
implement uvm_component wrapper around model
extract conguraAon during build phase & use in model

Normal Register Build

class my_env extends uvm_env;
my_reg_block reg_model;
NOTE : REG_MODEL IS
CONSTRUCTED BUT EMPTY
AFTER CREATE
reg_model = my_reg_block::type_id::create("reg_model", this);
reg_model.configure(null, "reg_model");
CREATE THE
reg_model.build();
REG_BLOCK
reg_model.lock_model();
BUILD THE
class my_reg_block extends uvm_reg_block; REG_BLOCK
function new (...); super.new(); ...
virtual function void build(); CREATE & BUILD
reg_a = my_reg_a::type_id::create(reg_a"); EACH REGISTER
reg_a.configure(this, null, reg_a);
reg_a.build();
CREATE & CONFIGURE
EACH FIELD
class my_reg_a extends uvm_reg;
function new (...); super.new(); ...
virtual function void build(); FIELD WIDTH USES A
GENERATED NUMBER
field_x = uvm_reg_field::type_id::create(field_x");
field_x.configure(this, 32, 0, RW", 1, 'h0, 1, 1, 1);

Congurable Register Build

class my_reg_wrapper extends uvm_component;
my_reg_block reg_model;
USE CONFIG TO SET
NOTE : REG_MODEL IS
CONSTRUCTED AND NOT
my_config cfg; EMPTY AFTER CREATE
KNOBS IN FIELDvoid
function CLASSbuild_phase(...);
reg_model = my_reg_block::type_id::create("reg_model", this);
CREATE REG_BLOCK,
reg_model.reg_a.field_x.set_width(cfg.width); REGISTERS & FIELDS
reg_model.configure(null, "reg_model");
reg_model.build();
CREATE MOVED
reg_model.lock_model();
BUILD TO NEW BUILD THE
class my_reg_block extends uvm_reg_block; REG_BLOCK
function new (...);
reg_a = my_reg_a::type_id::create(reg_a");... BUILD EACH
virtual function void build(); REGISTER
reg_a.configure(this, null, reg_a);
reg_a.build(); CONFIGURE
EACH FIELD
class my_reg_a extends uvm_reg;
function new (...);
FIELD WIDTH COMES
field_x = my_reg_field::type_id::create(field_x");...
virtual function void build(); FROM CONFIG KNOB
field_x.configure(this, field_x.width, 0, RW", 1, 'h0,...);

Using Register Wrapper
All funcAonality is contained inside wrapper class
just instanAate and congure like a normal component
CONFIGURATION-AWARE REGISTERS
class my_env extends uvm_env; USING WRAPPER COMPONENT
... IS MORE AD-HOC AND LIMITED
my_reg_wrapper reg_wrapper; BUT BETTER ENCAPSULATED
my_config cfg;
...
ùvm_component_utils_begin(my_env) INSTANTIATE WRAPPER
ùvm_field_object(cfg, UVM_ALL_ON)
...
CREATE WRAPPER
reg_wrapper = my_reg_wrapper::type_id::create(...);
uvm_config_object::set(this, "*", cfg", cfg);
...
PASS DOWN CONFIG

Register Tips
Generate deriva3ve-specic registers on-demand
if possible, since it makes life easy for everyone!
...but it is not always appropriate
(e.g. many DUT parameters in registers, bundled IP&VIP)
If class environment is already parameterized
then generate and use parameterized registers
If class environment is not parameterized
then do not use parameterized registers
use congura3on-aware registers and encapsulate
in a wrapper component

References and further reading
Abstract BFMs Outshine Virtual Interfaces for
Advanced SystemVerilog Testbenches
D.Rich, J.Bromley, DVCon 2008, www.doulos.com/downloads
Parameterized Interfaces and Reusable VIP
A.Pra6, Blog, h6ps://blogs.synopsys.com/vip-central
On SystemVerilog Interface Polymorphism and
Extendability
T.Timi, Blog, h6p://blog.vericaAongentleman.com
Pragma$c Verica$on Reuse in a Ver$cal World

QuesAons

DVCon Europe 2015 T01 Presentation

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

DVCon Europe 2015 T01 Presentation

Încărcat de

Drepturi de autor:

Formate disponibile

Advanced

Verilab & Accellera 1

AdapAve Protocol Checks

ConguraAon Object EncapsulaAon &

Parameterized Classes, Interfaces & Registers

Verilab & Accellera 2

Verilab & Accellera 3

Verilab & Accellera 5

SAME ROLE, DIFFERENT ENVIRONMENT DIFFERENT DUT

Reuse verica3on environment in mulAple projects

SAME ROLE & ENV, DIFFERENT CONFIG DERIVATIVE DUT

Verilab & Accellera 6

Verilab & Accellera 7

DIFFERENT STRUCTURE, NO STIMULUS

Reuse ac3ve component in top-level context

DIFFERENT ROLE, STIMULUS IS PART OF

Verilab & Accellera 9

Demystifying the UVM CONFIG CHECKS

Vertical & Horizontal Reuse

Behind the Scenes Advanced UVM Register

Verilab & Accellera 10

Verilab & Accellera 11

NOT ENOUGH TO PROVE OPERATION OF THE PERFECT CHIP

Verilab & Accellera 12

Verilab & Accellera 14

S3mulus is provided by sequencers and drivers

No s3mulus is performed by passive components

Verilab & Accellera 16

ALL CHECKS, COVERAGE & MESSAGES REUSED M

Verilab & Accellera 17

update congura3on only from passive comps

BLOCK-LEVEL SUPPLIERS NEED TO MAKE THINGS

Verilab & Accellera 20

environment pulled together only in base-test

Verilab & Accellera 21

encapsulate all sub-components in env not test

Verilab & Accellera 22

Verilab & Accellera 23

BLOCKS CONTROL UVCS) HIERARCHICAL

Verilab & Accellera 24

Verilab & Accellera 25

Verilab & Accellera 26

Verilab & Accellera 27

Verilab & Accellera 28

PROVE FUNCTIONALITY USING A PASSIVE SHADOW ENV

Verilab & Accellera 29

Verilab & Accellera 30

Accellera Systems Initiative 31

Verilab & Accellera 32

Coverage can mislead! See Verilab papers DVCon-US 2015

SV covergroups are not

Verilab & Accellera 33

Verilab & Accellera 34

but architecture of coverage classes needs care

Verilab & Accellera 35

Verilab & Accellera 36

function void write(dvcon_txn t);

Verilab & Accellera 37

Verilab & Accellera 38

Verilab & Accellera 39

restricted to contents of a single object (transacAon,

extend monitor class to add cannot

Verilab & Accellera 41

protocol DUT internals and protocol