Introducing The Universal Verification Methodology (Uvm) in Systemc and Systemc-Ams

North American SystemC User's Group June 2, 2014
Introducing the Universal Verification Methodology

(UVM) in SystemC and SystemC-AMS
Karsten Einwich Fraunhofer IIS/EAS

Martin Barnasconi NXP Semiconductors
Thilo Vörtler Fraunhofer IIS/EAS
Thomas Klotz Fraunhofer IIS/EAS
NASCUG 2014
© Fraunhofer IIS/EAS
Outline
n  Introduction and Motivation

n  Universal Verification Methodology (UVM) … what is it?
n  Why UVM in SystemC/C++/SystemC-AMS?
n  UVM-SystemC overview
n  UVM foundation elements
n  UVM test bench and test creation
n  Randomization and coverage
n  Contribution to Accellera
n  Applications and use cases of UVM-SystemC
n  Summary and outlook
NASCUG 2014
© Fraunhofer IIS/EAS Karsten Einwich
1
Presented during DAC 51 in San Francisco, CA Page 1 of 24
Outline

NASCUG 2014
Introduction: UVM - what is it?
n  Universal Verification Methodology facilitates the creation of modular,

scalable, configurable and reusable test benches
n  Based on verification components with standardized interfaces
n  Class library which provides a set of built-in features dedicated to simulation-
based verification
n  Utilities for phasing, component overriding (factory), configuration,
comparing, scoreboarding, reporting, etc.
n  Environment supporting migration from directed testing towards Coverage

Driven Verification (CDV)
n  Introducing automated stimulus generation, independent result checking
and coverage collection
NASCUG 2014
4
2
Motivation
n  No structured nor unified verification Verification & Validation

methodology available for ESL design
Methodology
n  UVM (in SystemVerilog) primarily targeting
block/IP level (RTL) verification, not system- UVM-‐SystemC* -‐AMS
level
n  Porting UVM to SystemC/C++ enables -‐AMS
TLM SCV
n  creation of more advanced system-level SystemC-‐AMS
test benches
n  reuse of verification components between SystemC
system-level and block-level verification
C++
n  Target to make UVM truly universal, and not
tied to a particular language
*UVM-SystemC = UVM implemented in
SystemC/C++
NASCUG 2014
5
Why UVM in SystemC/C++ and SystemC-AMS?
n Strong need for a system-level verification methodology for embedded

systems which include HW/SW and AMS functions
n SystemC is the recognized standard for system-level design, and needs to
be extended with advanced verification concepts
n SystemC AMS available to cover the AMS verification needs
n Reuse tests and test benches across verification (simulation) and validation
(HW-prototyping) platforms
n This requires a portable language like C++ to run tests on
HW prototypes and even measurement equipment
n Enabling Hardware-in-the-Loop simulation or Rapid Control Prototyping
n Benefit from proven standards and reference implementations
n Leverage from existing methodology standards and reference
implementations, aligned with best practices in verification
NASCUG 2014
6
3
Outline

NASCUG 2014
UVM-SystemC overview
UVM-‐SystemC functionality Status

Test bench creation with component classes: þ
agent, sequencer, driver, monitor, scoreboard, etc.
Test creation with test, (virtual) sequences, etc. þ
Configuration and factory mechanism þ
Phasing and objections þ
Policies to print, compare, pack, unpack, etc. þ
Messaging and reporting þ
Register abstraction layer and callbacks development
Coverage groups development
Constrained randomization SCV or CRAVE
NASCUG 2014
8
4
UVM layered architecture
Spec
Test Test
Test ccases
ases
Verification environment (test bench)

Scenario
Functional coverage
Sequences
Verification component
Functional Sequencer Scoreboard
Command Driver Monitor Monitor
Signal Device
under test
NASCUG 2014
9
UVM-SystemC phasing
UVM common phases

Pre-run phases Runtime phases Post-run phases
build connect    run » extract  check report  final 
before_end_of_elaboration* end_of_simulation*
end_of_elaboration
UVM runtime phases  »
Legend
start_of_simulation
configure main shutdown » = SystemC process(es)
pre-‐reset post-‐reset  = top-‐down execution
 = bottom-‐up execution
reset = SystemC-‐only callback
*
n UVM phases are mapped on the SystemC phases

n UVM-SystemC supports the 9 common phases and the (optional) refined
runtime phases
n Completion of a runtime phase happens as soon as there are no
objections (anymore) to proceed to the next phase
NASCUG 2014
10
5
UVM agent
seq
agent
trans
config
n  Component responsible for driving and sequencer
monitoring the DUT seq_item_export analysis
n  Typically contains three components
n  Sequencer seq_item_port item_collected_port
driver monitor
n  Driver
vif vif
n  Monitor
n  Can contain analysis functionality for
basic coverage and checking
n  Possible configurations
n  Active agent: sequencer and driver are enabled
n  Passive agent: only monitors signals
(sequencer and driver are disabled)
n  C++ base class: uvm_agent
NASCUG 2014
11
UVM-SystemC agent (1)

seq
class vip_agent : public uvm_agent Dedicated base class to agent
{ distinguish agents from trans
public:
vip_sequencer<vip_trans>* sequencer;
other component types config
vip_driver<vip_trans>* driver; sequencer
vip_monitor* monitor; seq_item_export analysis
Registers the object
UVM_COMPONENT_UTILS(vip_agent) in the factory

vip_agent( uvm_name name ) seq_item_port item_collected_port
: uvm_agent( name ), sequencer(0), driver(0), monitor(0) {}
Children are driver monitor
virtual void build_phase( uvm_phase& phase ) instantiated in
{ the build phase vif vif
uvm_agent::build_phase(phase);
Essential call to base class to
if ( get_is_active() == UVM_ACTIVE ) access properties of the agent
{
sequencer = vip_sequencer<vip_trans>::type_id::create("sequencer", this);
assert(sequencer);
driver = vip_driver<vip_trans>::type_id::create("driver", this);
assert(driver);
}
Call to the factory which creates and

instantiates this component dynamically
monitor = vip_monitor::type_id::create("monitor", this);
assert(monitor);
}
NASCUG 2014 NOTE: UVM-SystemC API under review – subject to change
12
6
UVM-SystemC agent (2)

seq
agent
trans
config
...

sequencer
virtual void connect_phase( uvm_phase& phase ) seq_item_export analysis
{

if ( get_is_active() == UVM_ACTIVE ) seq_item_port item_collected_port
{
// connect sequencer to driver driver monitor
driver-‐>seq_item_port.connect(sequencer-‐>seq_item_export);
} vif vif

}
};
Only the connection between sequencer
and driver is made here. Connection of
driver and monitor to the DUT is done
via the configuration mechanism
13
UVM verification component
n  A UVM verification component (UVC) UVM verification component (env)

is an environment which consists of config
one or more cooperating agents seq
agent
trans
n  UVCs or agents may set or get
config
configuration parameters
sequencer
n  An independent test sequence is seq_item_export analysis
processed by the driver via a sequencer
n  Each verification component is seq_item_port item_collected_port
connected to the DUT using a dedicated driver monitor

interface
vif vif
n  C++ base class: uvm_env
NASCUG 2014
14
7
UVM-SystemC verification component
class vip_uvc : public uvm_env

{ UVM verification component (env)
public: A UVC is considered as a
vip_agent* agent;
config
sub-environment in large seq

system-level environments agent
UVM_COMPONENT_UTILS(vip_uvc);
trans

vip_uvc( uvm_name name ) config
: uvm_env( name ), agent(0) {}

sequencer
virtual void build_phase( uvm_phase& phase ) seq_item_export analysis
{
uvm_env::build_phase(phase);
seq_item_port item_collected_port
agent = vip_agent::type_id::create("agent", this);
assert(agent); driver monitor
}
vif vif
};
n  In this example, the UVM verification component (UVC) contains only one
agent. In practice, more agents are likely to be instantiated
15
UVC with AMS driver and monitor using SystemC-AMS
n  Regular UVM-SystemC drivers and UVM verification component (env)

monitors are used in which SystemC-AMS
config
Timed Data Flow (TDF) modules are seq
instantiated agent
trans
n  Factory overrides enable configuration of config
the UVC’s driver or monitor for specific sequencer
AMS use cases seq_item_export analysis
n  For the SystemC-AMS modules, TDF ports
are necessary to allow read / write seq_item_port item_collected_port
AMS AMS
operations to the analog interface driver
driver monitor
monitor
n  The parent driver and monitor establish the vif vif
connection from the TDF ports to the
interface via the configuration mechanism
NASCUG 2014
16
8
UVM sequences sequence
transaction
n  Sequences are part of the test scenario and define

transaction
streams of transactions
n  The properties (or attributes) of a transaction are transaction
captured in a sequence item
n  Sequences are not part of the test bench hierarchy,
but are mapped onto one or more sequencers
seq1
n  Sequences can be layered, hierarchical or virtual,
and may contain multiple sequences or sequence trans
items seq
trans
n  Sequences and transactions can be configured via seq1
the factory seq2 seq2
trans
trans
NASCUG 2014
17
UVM-SystemC sequence item
class vip_trans : public uvm_sequence_item seq

{ agent
Transaction trans
public: defined as
sequence item
config
int addr;
int data;
User-defined data items sequencer
(randomization can be done
bus_op_t op;
using SCV or CRAVE) seq_item_export analysis

UVM_OBJECT_UTILS(vip_trans); seq_item_port item_collected_port

driver monitor
vip_trans( const std::string& name = "vip_trans" )
: addr(0x0), data(0x0), op(BUS_READ) {} vif vif

virtual void do_print( uvm_printer& printer ) const { ... }
virtual void do_pack( uvm_packer& packer ) const { ... } A sequence item should implement all
elementary member functions to print,
virtual void do_unpack( uvm_packer& packer ) { ... } pack, unpack, copy and compare the
virtual void do_copy( const uvm_object* rhs ) { ... } data items
virtual bool do_compare( const uvm_object* rhs ) const { ... } (there are no field macros in
}; UVM-SystemC )
18
9
UVM-SystemC sequence
template <typename REQ = uvm_sequence_item, typename RSP = REQ>
class sequence : public uvm_sequence<REQ,RSP>
{ seq
public: agent
sequence( const std::string& name ) Factory registration trans
: uvm_sequence<REQ,RSP>( name ) {} supports template classes config

UVM_OBJECT_PARAM_UTILS(sequence<REQ,RSP>); sequencer

Raise objection if there is seq_item_export analysis
virtual void pre_body() {
no parent sequence
if ( starting_phase != NULL )
starting_phase-‐>raise_objection(this);
} seq_item_port item_collected_port

virtual void body() {
A sequence contains a request driver monitor
and (optional) response, both
REQ* req; defined as sequence item
RSP* rsp;
vif vif
...
start_item(req); Compatibility layer to SCV or
// req-‐>randomize(); CRAVE not yet available
finish_item(req);
get_response(rsp); Optional: get response
}

virtual void post_body() {
if ( starting_phase != NULL ) starting_phase-‐>drop_objection(this);
}
};
19
UVM environment (test bench)
n  A test bench is the environment Testbench (env) config
which instantiates and configures scoreboard

virtual
the UVCs, scoreboard, and Subscr
eval
Subscr
sequencer 1 2
(optional) virtual sequencer
n  The test bench connects UVC1 (env) UVC2 (env)
agent agent
n  Agent sequencer(s) in each UVC with …..
the virtual sequencer (if defined) Sqr conf Sqr conf
Drv Mon Drv Mon

n  Monitor analysis port(s) in each UVC
with the scoreboard subscriber(s)
n  Note: The driver and monitor in each
agent connect to the DUT using the interface
stored in the configuration database
n  C++ base class: uvm_env
NASCUG 2014
20
10
UVM-SystemC test bench (1)

class testbench : public uvm_env
{
public: All components in the
vip_uvc* uvc1; test bench will be
vip_uvc* uvc2; dynamically instan- Testbench (env) config
virt_sequencer* virtual_sequencer; tiated so they can be
scoreboard* scoreboard1; overidden by the test if scoreboard
needed virtual Subscr Subscr
eval
UVM_COMPONENT_UTILS(testbench); sequencer 1 2

testbench( uvm_name name )
: uvm_env( name ), uvc1(0), uvc2(0), UVC1 (env) UVC2 (env)
virtual_sequencer(0), scoreboard1(0) {}
agent agent
…..
virtual void build_phase( uvm_phase& phase ) Sqr conf Sqr conf
{
uvm_env::build_phase(phase); Drv Mon Drv Mon

uvc1 = vip_uvc::type_id::create("uvc1", this);
assert(uvc1);
uvc2 = vip_uvc::type_id::create("uvc2", this);
assert(uvc2);

set_config_int("uvc1.*", "is_active", UVM_ACTIVE); Definition of active or
set_config_int("uvc2.*", "is_active", UVM_PASSIVE); passive UVCs

...
21
UVM-SystemC test bench (2)

...
virtual_sequencer = virt_sequencer::type_id::create( Testbench (env) config
"virtual_sequencer", this);
assert(virtual_sequencer); scoreboard
virtual Subscr Subscr
scoreboard1 = eval
sequencer 1 2
scoreboard::type_id::create("scoreboard1", this);
assert(scoreboard1);
} Virtual sequencer points to UVC1 (env) UVC2 (env)
UVC sequencer
agent agent
virtual void connect_phase( uvm_phase& phase )
…..
Sqr conf Sqr conf
{
virtual_sequencer-‐>vip_seqr = uvc1-‐>agent-‐>sequencer;
Drv Mon Drv Mon

uvc1-‐>agent-‐>monitor-‐>item_collected_port.connect(
scoreboard1-‐>xmt_listener_imp);

uvc2-‐>agent-‐>monitor-‐>item_collected_port.connect(
scoreboard1-‐>rcv_listener_imp);
}
Analysis ports of the

monitors are connected to
};
the scoreboard
subscribers (listeners)
22
11
UVM test
default
Test sequence
config
n  Each UVM test is defined as a dedicated C+
+ test class, which instantiates the test Testbench (env) config
bench and defines the test sequence(s) scoreboard
virtual Subscr ref Subscr
sequencer 1 model 2
n  Reuse of tests and topologies is possible by
deriving tests from a test base class UVC1 (env) UVC2 (env)
agent agent
…..
Sqr conf Sqr conf
n  The UVM configuration and factory concept
Drv Mon Drv Mon
can be used to configure or override UVM
components, sequences or sequence items
n  C++ base class: uvm_test
NASCUG 2014
23
UVM-SystemC test (1)

default
Test sequence
config
class test : public uvm_test
Specific class to identify the
{
public:
test objects for execution in the Testbench (env) config
sc_main program
testbench* tb; scoreboard
bool test_pass; virtual Subscr ref Subscr

test( uvm_name name ) : uvm_test( name ),
sequencer 1 model 2
tb(0), test_pass(true) {}
The test instantiates the UVC1 (env) UVC2 (env)
UVM_COMPONENT_UTILS(test); required test bench
agent agent
virtual void build_phase( uvm_phase& phase ) …..
{ Sqr conf Sqr conf
uvm_test::build_phase(phase);
tb = testbench::type_id::create("tb", this); Drv Mon Drv Mon
assert(tb);

uvm_config_db<uvm_object_wrapper*>::set( this,
tb.uvc1.agent.sequencer.run_phase", "default_sequence", Configuration of the default sequence,
vip_sequence<vip_trans>::type_id::get()); } which will be executed on the sequencer
of the agent in UVC1

set_type_override_by_type( vip_driver<vip_trans>::get_type(),
new_driver<vip_trans>::get_type() );
Factory method to override the
... original driver with a new driver
24
12
UVM-SystemC test (2)

default
Test sequence
config
Testbench (env) config
... scoreboard
virtual void run_phase( uvm_phase& phase ) sequencer 1 model 2
{
UVM_INFO( get_name(),
"** UVM TEST STARTED **", UVM_NONE ); UVC1 (env) UVC2 (env)
}
agent agent
…..
virtual void extract_phase( uvm_phase& phase ) Sqr conf Sqr conf
{
Get result of the scoreboard
if ( tb-‐>scoreboard1.error ) Drv Mon Drv Mon
in the extract phase
test_pass = false;
}

virtual void report_phase( uvm_phase& phase )
{
if ( test_pass )
UVM_INFO( get_name(), "** UVM TEST PASSED **", UVM_NONE );
else
UVM_ERROR( get_name(), "** UVM TEST FAILED **" ); Report results in
} the report phase
};
25
The main program (top-level)

top (sc_main)
default
Test sequence
config
n  The top-level (e.g. sc_main) contains the

test(s) and the DUT
scoreboard
sequencer 1 model 2
n  The interface to which the DUT is
connected is stored in the configuration UVC1 (env) UVC2 (env)
database, so it can be used by the UVCs agent agent
to connect to the DUT …..
Sqr conf Sqr conf
Drv Mon Drv Mon

n  The test to be executed is either defined
by the test class instantiation or by the
argument of the member function
run_test DUT
NASCUG 2014
26
13
UVM-SystemC main program

top (sc_main)
int sc_main(int, char*[]) Instantiate the
{ default

DUT and
interfaces
Test sequence
config
dut* my_dut = new dut("my_dut");
vip_if* vif_uvc1 = new vip_if;
vip_if* vif_uvc2 = new vip_if; scoreboard
register interface
using the configuration
sequencer 1 model 2
database

uvm_config_db<vip_if*>::set(0, "*.uvc1.*",
"vif", vif_uvc1); UVC1 (env) UVC2 (env)
uvm_config_db<vip_if*>::set(0, "*.uvc2.*",
agent agent
"vif", vif_uvc2);

…..
Sqr conf Sqr conf

my_dut-‐>in(vif_uvc1-‐>sig_a); Connect DUT to Drv Mon Drv Mon
my_dut-‐>out(vif_uvc2-‐>sig_a); the interface

run_test("test");

sc_start(); Register the test to be
executed. This function
return 0; also dynamically DUT
} instantiates the test if
given as argument
27
Constrained randomization in UVM-SystemC
n  Available constrained randomization libraries for SystemC

n  SystemC Verification Library (SCV)
n  Constrained Random Verification Environment (CRAVE)
n  Both APIs differ from the SystemVerilog constrained randomization API
n  Preference to have aligned API across these different languages
n  UVM-SystemC therefore introduces a “compatibility layer” for constrained

randomization with UVM/SystemVerilog “Look & Feel”
n  Introduction of dedicated randomization variables and constraint objects,
randomize() method, etc.
n  To be proposed as SCV language and library extension to Accellera
n  Proof-of-concept implemented using CRAVE library
NASCUG 2014
28
14
Example: Constrained randomization in UVM-SystemC
class simplesum : public scvx_rand_object int sc_main(int, char*[])

{ Randomization {
public: object bool result;

scvx_rand< int > x, y, z; Define variable(s) to simplesum s("simplesum");
scvx_constraint c1; be randomized and
the constraint(s) result = s.randomize(); Randomize
simplesum( scvx_name name ) variables
: x("x"), Optional: Assign if (result)
y("y"), user-defined s.print_result();
z("z"), names to variables else
c1("c1") and constraints cout << "No solution found." << endl;
{
c1( z() == x() + y() ); Implementation result = s.randomize_with(
} of constraint s.y() > 10 && s.x() == 8 );

void print_result() const if (result) Inline
{ s.print_result(); constraints
cout << name() << ": " else
<< z << " == " << x cout << "No solution found." << endl;
<< " + " << y << endl; }
}

}; // class simplesum

29
Functional coverage in UVM-SystemC
n  No standardized functional coverage API in SystemC available

n  Proprietary/commercial SystemC coverage APIs available, but not offered
(yet) for standardization
n  Introduction of a functional coverage API for UVM-SystemC with UVM/
SystemVerilog “Look & Feel”
n  To be proposed as SCV language and library extension to Accellera
n  Proof-of-concept implementation offers:
n  Coverage of variables (supports data types sc_bv, integer, and bool)
n  Automatic as well as user-defined coverage bins
n  Associate bins with sets of values (called multi-value bins)
n  Specialized bins (e.g. to ignore values, illegal values, etc)
n  Optional directives to control coverage collection and reporting
NASCUG 2014
30
15
Example: Functional coverage in UVM-SystemC (1)
class cg : public scvx_covergroup int sc_main(int, char*[])

{ {
public: int m; Variables to
Covergroup
scvx_coverpoint cp_m; int n; be covered
contains two
scvx_coverpoint cp_n; coverpoints
int stimuli_m[] = { 3, 5, 6, 5, 3, 6, 5,
cg( scvx_name name, int& m, int& n ) 5, 3, 3 };
: cp_m( "cp_m", m ), int stimuli_n[] = { 13, 1, 6, 3, 16, 12,
cp_n( "cp_n", n ) Ability to set 8, 3, 13, 3 };
{ maximum for
option.auto_bin_max = 16; automatic bins cg cg_inst("cg_inst", m, n); Instantiate
covergroup
cp_m.bins("bin_a") = list_of(4, 0, 1, 2, 3 ); for (int i = 0; i < 10; i++)
cp_m.bins("bin_b") = list_of(4, 4, 5, 6, 7 ); {
m = stimuli_m[i];
Creation of n = stimuli_n[i];
single-value bins Triggers the
cg_inst.sample(); coverage sampling
cp_m.ignore_bins("ignore_bins_m") = 6; }
cp_n.ignore_bins("ignore_bins_n") = 13;
} cg_inst.report(); Report coverage
Specialized bins to results
}; ignore values return 0;
}
31
Example: Functional coverage in UVM-SystemC (2)

$ ./test.exe
Covergroup: cg_inst coverpoint: cp_n
---------------------------------------- ---------------------------
VARIABLE Expected Covered Percent Name Percent Hitrate
---------------------------------------- ---------------------------
cp_m 7 2 28.57 auto[0] 100 0
cp_n 15 5 33.33 auto[1] 100 1
---------------------------------------- auto[2] 0 0
TOTAL: 22 7 31.82 auto[3] 100 3
---------------------------------------- auto[4] 0 0
auto[5] 0 0
coverpoint: cp_m auto[6] 100 1
--------------------------- auto[7] 0 0
Name Percent Hitrate auto[8] 100 1
--------------------------- auto[9] 0 0
bin_a[0] 0 0 auto[10] 0 0
bin_a[1] 0 0 auto[11] 0 0
bin_a[2] 0 0 auto[12] 100 1 Value 13 will
bin_a[3] 100 4 auto[14] 0 0 be ignored
bin_b[4] 0 0 auto[15] 0 0
bin_b[5] 100 4 Value 6 will ---------------------------
bin_b[7] 0 0 be ignored
---------------------------
NASCUG 2014
32
16
Outline

NASCUG 2014
Contribution to Accellera
n  Objective: seek further industry support and

standardization of UVM-SystemC
n  UVM-SystemC contribution to Accellera
Verification WG
n  UVM-SystemC Language Reference
Manual (LRM)
n  UVM-SystemC Proof-of-Concept
implementation, released under Apache
2.0 license
n  Align with SCV and Multi-Language
requirements and future developments
NASCUG 2014
34
17
Outline

NASCUG 2014
Applications and use cases of UVM-SystemC
n  Enables new use cases
n  New re-use scenarios
n  IP protected, language and simulator independent verification IP
n  Enables System-level UVM based verification
n  Simplifies development of UVM based verification methods for AMS systems
NASCUG 2014
36
18
Re-use across Languages, Simulators, Abstraction Levels
default
Test sequence
config
Testbench (env) config
scoreboard
sequencer 1 model 2
UVC1 (env) UVC2 (env)

agent agent
…..
Sqr conf Sqr conf
Drv Mon Drv Mon
DUT -‐ VHDL DUT -‐ Verilog

…
out out out DUT -‐ SystemC out DUT -‐ Matlab
in in in in
AMS DIG SW AMS DIG SW AMS DIG SW AMS DIG SW
NASCUG 2014
37
Re-use for emulation and lab validation
download
integrate
monitor
Zynq Board (FPGA + ARM)

Source: ZedBoard.org Source: ZedBoard.org
SimulaIon -‐ SystemC Real Time Hardware Real Time Hardware

default
Test sequence
config
Test
default config
Test
default config
sequence sequence
Testbench (env) config
Testbench (env) config Testbench (env) config
virtual scoreboard scoreboard scoreboard
virtual virtual
sequence Subscr ref Subscr ref Subscr ref Subscr
1 model 2 sequence Subscr
sequence Subscr
r 1 model 2 1 model 2
r r
UVC1 (env) UVC2 (env) UVC1 (env) UVC2 (env) UVC1 (env) UVC2 (env)
agent agent agent agent agent agent
Driver Monitor Driver Monitor Driver Monitor
SystemC SystemC EmulaIon EmulaIon Lab equip Lab equip
vif vif vif vif vif vif
DUT DUT DUT

SystemC -‐ Behavioral FPGA -‐ EmulaIon ASIC – 1st Silicon
NASCUG 2014
38
19
UVM-SystemC Codegeneration
class vip_agent : public uvm_agent

{
public:
vip_sequencer<vip_trans>* sequencer;
vip_driver<vip_trans>* driver;
vip_monitor* monitor;

UVM_COMPONENT_UTILS(vip_agent)

vip_agent( uvm_name name )
: uvm_agent( name ), sequencer(0), driver(0), monitor(0) {}

virtual void build_phase( uvm_phase& phase )
{
uvm_agent::build_phase(phase);

if ( get_is_active() == UVM_ACTIVE )
{
sequencer = vip_sequencer<vip_trans>::type_id::create("sequencer",this);
assert(sequencer);
driver = vip_driver<vip_trans>::type_id::create("driver", this);
assert(driver);
}

monitor = vip_monitor::type_id::create("monitor", this);
NASCUG 2014 assert(monitor);
}
39
UVM-SystemC-AMS
n  The UVM-SystemC infrastructure can also

handle AMS verification
n  Transactions will program analog driver and
monitors
n  Drivers generate analog signals, Monitors
analyze analog signals and extracting properties
like amplitude, spectrum, … and transfer them
via transactions
n  AMS verification requires a tighter binding/

synchronization to the time
n  Non-causalities due continuous signal behavior
n  AMS verification requires continuous distribution
function (and not PWC only)
n  Randomization of DUT parameters is essential
NASCUG 2014
40
20
UVM-SystemC-AMS extensions
n  UVM AMS extensions will not break the existing UVM
n  Time annotation to transaction
n  Decoupled sequence time
n  Data dependent synchronization
n  Introducing of a pre-build phase

n  Is executed before the DUT is instantiated
n  Permits the setting of parameter, which influence the DUT creation
n  Constraint randomization with continuous distribution function can be hardly
realized
n  Constraints for AMS are usually much simpler
NASCUG 2014
41
UVM for System-level / Functional verification
Vision
n  Translating specifications (documents, standards) to readable – also for non
verification experts - test scenarios, this should also include ranges and
uncertainties
n  No separation between analog/digital, hard- and software
n  “real” system-level verification
Main question:
n  Will the system work for the purposes for which it will be built
NASCUG 2014
42
21
Challenges for UVM System-level
n  No executable reference model available
n  Complex stimulation and expected sequences
n  Coverage measure is different to implementation level
n  How much of the possible application scenarios, input stimuli, operating
conditions, specification items are verified?
à UVM methodology/best practices have to be extended for system level!
à UVM framework is generic enough to realize the required extensions!

NASCUG 2014
43
Outline

NASCUG 2014
22
Summary and outlook
Universal Verification Methodology created in SystemC/C++

n  Fully compliant with UVM standard
n  Target is to make all essential features of UVM available in SystemC/C++
n  UVM-SystemC language definition and proof-of-concept implementation
contributed to Accellera Systems Initiative
n  SystemC-AMS is used for AMS system-level verification use cases
Ongoing developments
n  Extend UVM-SystemC with constrained randomization capabilities using
SystemC Verification Library (SCV) or CRAVE
n  Introduction of assertions and functional coverage features
n  Add register abstraction layer and callback mechanism
n  Develop UVM based AMS and system-level verification methods
NASCUG 2014
45
Acknowledgements
The development of the UVM-SystemC methodology and library has been

supported by the European Commission as part of the Seventh Framework
Programme (FP7) for Research and Technological Development in the project
'VERIFICATION FOR HETEROGENOUS RELIABLE DESIGN AND
INTEGRATION' (VERDI).
The research leading to these results has received funding from the European
Commission under grand agreement No 287562.
NASCUG 2014
46
23
Resources
n  SystemC, SystemC-AMS, UVM Standards:

n  www.accellera.org
n  SystemC proof-of-concept
n  www.accellera.org/downloads/standards/systemc
n  SystemC-AMS proof-of-concept
n  www.coside.de/open_source.html
n  Verdi project site (e.g. publications, tutorials for UVM SystemC)
n  www.verdi-fp7.eu
n  Crave randomization library
n  www.systemc-verification.org/
NASCUG 2014
47
24

Introducing The Universal Verification Methodology (Uvm) in Systemc and Systemc-Ams

Uploaded by

Copyright:

Available Formats

Introducing The Universal Verification Methodology (Uvm) in Systemc and Systemc-Ams

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introducing The Universal Verification Methodology (Uvm) in Systemc and Systemc-Ams

Uploaded by

Copyright:

Available Formats

North American SystemC User's Group June 2, 2014

Introducing the Universal Verification Methodology

Karsten Einwich Fraunhofer IIS/EAS

n Introduction and Motivation

© Fraunhofer IIS/EAS Karsten Einwich

n Introduction and Motivation

© Fraunhofer IIS/EAS Karsten Einwich

Introduction: UVM - what is it?

n Universal Verification Methodology facilitates the creation of modular,

n Environment supporting migration from directed testing towards Coverage

n No structured nor unified verification Verification & Validation

Why UVM in SystemC/C++ and SystemC-AMS?

n Strong need for a system-level verification methodology for embedded

n Introduction and Motivation

© Fraunhofer IIS/EAS Karsten Einwich

UVM-­‐SystemC functionality Status

UVM layered architecture

Verification environment (test bench)

Command Driver Monitor Monitor

UVM common phases

n UVM phases are mapped on the SystemC phases

UVM-SystemC agent (1)

NASCUG 2014 NOTE: UVM-SystemC API under review – subject to change

UVM-SystemC agent (2)

NASCUG 2014 NOTE: UVM-SystemC API under review – subject to change

UVM verification component

n A UVM verification component (UVC) UVM verification component (env)

connected to the DUT using a dedicated driver monitor

UVM-SystemC verification component

class vip_uvc : public uvm_env

UVC with AMS driver and monitor using SystemC-AMS

n Regular UVM-SystemC drivers and UVM verification component (env)

UVM sequences sequence

n Sequences are part of the test scenario and define

UVM-SystemC sequence item

class vip_trans : public uvm_sequence_item seq

NASCUG 2014 NOTE: UVM-SystemC API under review – subject to change

UVM environment (test bench)

n A test bench is the environment Testbench (env) config

which instantiates and configures scoreboard

Drv Mon Drv Mon

UVM-SystemC test bench (1)

UVM-SystemC test bench (2)

n C++ base class: uvm_test

UVM-SystemC test (1)

NASCUG 2014 NOTE: UVM-SystemC API under review – subject to change

UVM-SystemC test (2)

Testbench (env) config

NASCUG 2014 NOTE: UVM-SystemC API under review – subject to change

The main program (top-level)

n The top-level (e.g. sc_main) contains the

Drv Mon Drv Mon

UVM-SystemC main program

NASCUG 2014 NOTE: UVM-SystemC API under review – subject to change

Constrained randomization in UVM-SystemC

n Available constrained randomization libraries for SystemC

n UVM-SystemC therefore introduces a “compatibility layer” for constrained

Example: Constrained randomization in UVM-SystemC

class simplesum : public scvx_rand_object int sc_main(int, char*[])

n  Introduction and Motivation

n  Introduction and Motivation

n  Universal Verification Methodology facilitates the creation of modular,

n  Environment supporting migration from directed testing towards Coverage

n  No structured nor unified verification Verification & Validation

n Strong need for a system-level verification methodology for embedded

n  Introduction and Motivation

UVM-‐SystemC functionality Status

n UVM phases are mapped on the SystemC phases

n  A UVM verification component (UVC) UVM verification component (env)

n  Regular UVM-SystemC drivers and UVM verification component (env)

n  Sequences are part of the test scenario and define

n  A test bench is the environment Testbench (env) config

n  C++ base class: uvm_test

n  The top-level (e.g. sc_main) contains the

n  Available constrained randomization libraries for SystemC

n  UVM-SystemC therefore introduces a “compatibility layer” for constrained

n  No standardized functional coverage API in SystemC available

n  Introduction and Motivation

n  Objective: seek further industry support and

n  Introduction and Motivation

n  Enables new use cases

n  New re-use scenarios

n  IP protected, language and simulator independent verification IP

n  Enables System-level UVM based verification

DUT -‐ VHDL DUT -‐ Verilog

SimulaIon -‐ SystemC Real Time Hardware Real Time Hardware

n  The UVM-SystemC infrastructure can also

n  AMS verification requires a tighter binding/

n  Introducing of a pre-build phase

n  No executable reference model available

n  Complex stimulation and expected sequences

n  Coverage measure is different to implementation level

n  Introduction and Motivation

n  SystemC, SystemC-AMS, UVM Standards: