UVM Connect

Part 1 – Introduction

Adam Erickson
Verification Technologist

[email protected]
www.verificationacademy.com
 UVM Connect Presentation Series
• Part 1 – UVMC Introduction
• Learn what UVMC is and why you need it
• Review the principles behind the TLM1 and TLM2 standards
• Review basic port/export/interface connections in both SC and SV

• Part 2 – UVMC Connections

• Learn how to establish connections between
TLM-based components in SC and SV

• Part 3 – UVMC Converters

• Learn how to write the converters that are needed to transfer
transaction data across the language boundary

• Part 4 – UVMC Command API

• Learn how to access and control key aspects
of UVM simulation from SystemC
 What is UVM Connect?

• Connect SC & SV SC
TLM1
SV
Models Using TLM1

• Connect SC & SV SC
TLM2
SV
Models Using TLM2

• UVM Query and Control UVM

SC Command
SV
via Command API C / C++
 What is UVM Connect for?
• Abstraction Refinement
T1 SC Ref
Score
• Reuse SC models Model
as reference models in SV T1 T2

• Integrate SV RTL models Seq

T
Agent1 DUT Agent2
in SC

• Expand VIP Inventory VIP Library

• Integrate more off-the-shelf VIP

• Leverage lang strengths

Seq Seq
• Drive SC models with Seqs
T SC T
Seqs
Seq Models Seq
random stimulus from SV
 What is UVM Connect for?
• Encapsulation
• Minimize modifications when substituting components
• Wrap foreign IP in native skin
- integrate as ordinary native component
• Hide cross-language connection details

DMA
SV
uP RTL
Ctrl

T1 SC Ref Periph
Score Predict Mem Bus
Model A
T1 T2

T Periph
Seq Agent1 DUT Agent2 B
 Interoperability Using Standard Interfaces
• To be reusable & easy to use, components must be
• Independent of their context, not expose implementation

• To interoperate, components must agree on

• Information to exchange (i.e. the data type)
• Means of exchanging that information (i.e. the interface)

• Analogy : Media Server and TV

• They don’t know about each other; designed independently
• They agree on common data (video) & interface (HDMI)
• Both can be connected to many other devices

Media Server TV
HDMI
 Interoperability Using Standard Interfaces
• Interfaces
• An interface is a group of methods with well-defined semantics
• Hide implementation
- Implementation can change without affecting code that uses it
- Also known as “encapsulation” or “decoupling”
• Make integration easier—connect the ports, like modules
• Enhance reuse—can reuse components in may different contexts

• Transaction-Level Interfaces
• The interface conveys transaction objects
• “Initiator” components call these methods to send or request new
transactions
• “Target” components implement these methods to execute
transactions or fulfill requests
• TLM ports, exports, and sockets isolate interface callers from
interface implementors
 TLM Standard Interfaces
• TLM 1.0 - 2005
• Defines simple intput, get, peek, analysis, fifo
• Semantics only loosely defined
• pass by value

• TLM 2.0 - 2009

• Much stronger standard with well-defined semantics
• 190-page LRM, now part of IEEE 1666 (SystemC) LRM
• optimized for high-speed, memory-mapped bus interfaces
• b_transport, nb_transport_fw|bw, sockets
• tlm_generic_payload (canonical trans type) and protocol
• pass by reference

• Implementations in SC and SV UVM

• TLM library in SC is fully compliant, complete
• TLM library in UVM is an approximation
- constrained by limitations in SV, “80%” complete
 Ports, Exports, and Interfaces
• TLM port connections are like Verilog module port
connections, except we’re connecting interfaces, not wires.
- Initiatorsinitiate requests, Targets satisfy requests (control flow)
- Producersproduce data, Consumersexecute data (data flow)

initiator target = thread

producer consumer
= port

target initiator = export/imp

producer consumer
= socket

initiator initiator = data flow

producer FIFO consumer

initiator target
producer consumer
 Hierarchical TLM Connections
• Ports can connect/bind to • Interfaces (SC)
• Parent ports • Pure virtual classes inherited by
• Sibling exports target. No explicit binding.
• Sibling interfaces/imps • Imps (SV)
• Exports can connect/bind to • Are implicitly bound to target
• Child exports when allocated in target’s c’tor
• Child interfaces/imps • in = new(“in”, this);

initiator port port export export imp

port port export export imp target

parent1 parent2
parent1
initiator
target

void put( t ) {
port.put( t ); …
}
 Hierarchical TLM Connections
• Resolving port connections
• occurs just before end of elaboration
• all ports requiring connections connected?
- SC and SV do this checking independently
• if all OK, port-export-interface/imp network collapsed such
that calls incur at most 2 hops
- SC: initiator call  port  target method
- SV: initiator call  port  imp  target method

initiator port port export export imp

imp port export export imp target

parent1 parent2
parent1
initiator
target

void put( t ) {
port->put( t ); …
}
 TLM Ports
producer
• Ports are used to out
some
target
call interface
out->put( t );
methods implemented
elsewhere SC

• The “starting point” for

communication by class producer : public sc_module
{
initiators
sc_port<tlm_blocking_put_if<packet> > out;

• Integrator connects producer(sc_module_name nm) : out(“out”){

port externally SC_THREAD(run);
}
void run() {
• Depicted as square packet t;
in diagrams ...initialize/randomize packet...
out->put( t );
}
};
 TLM Ports
producer
• Ports are used to out
some
target
call interface
out.put( t );
methods implemented
elsewhere SV

• The “starting point” for class producer extends uvm_component {

communication by tlm_blocking_put_port #(packet) out;
initiators
function new (string name, uvm_component parent=null);
super.new(name,parent);
• Integrator connects out = new(“out", this);
port externally endfunction

virtual task run_phase (uvm_phase phase);

• Depicted as square packet t;
in diagrams ...initialize/randomize packet...
out.put(t);
endtask
};
 TLM Interfaces and Imps
some
• Are the “end point” consumer
initiator
in a network of port or
port-export- export void put (const packet &t) {
interface/imp …
connections }
SC

• In SC, the target

component inherits the
interface & implements class consumer : public sc_module,
its methods. Target can tlm_blocking_put_if<packet>
inherit (and implement) {
multiple interfaces. public:
consumer(sc_module_name nm) {
}

virtual void put(const packet &t) {

cout << “Got packet: “ << t << endl;
wait(10,SC_NS);
}
};
 TLM Interfaces and Imps
some
• Are the “end point” initiator consumer
in a network of port or in
port-export- export task put (packet t );
interface/imp …
connections endtask SV

• In SC, the target class consumer extends uvm_component;

component inherits the uvm_blocking_put_imp #(packet,consumer) in;
interface & implements `uvm_component_utils(consumer)
its methods. Target can
function new(string name,
inherit (and implement) uvm_component parent=null);
multiple interfaces. super.new(name,parent);
in = new("in", this);
• In SV, no multiple endfunction
inheritance. Uses imps
as workround. Imps virtual task put (packet t);
delegate external calls `uvm_info("CONSUMER/PKT/RECV",
to the component that t.sprint(),UVM_MEDIUM)
implements them. #10ns;
Depicted in diagrams as endtask
circle endclass
 TLM Exports
parent
• Promotes an interface some consumer
implementation from a in in
initiator
child to parent export export
put
SC
• Internally bound to child SC
export or imp/interface
in constructor
class consumer : public sc_module,
tlm_blocking_put_if<packet>
• Externally connected to {
port or parent export, public:
but not required. (If no sc_export<tlm_blocking_put_if<packet> > in;
connection, no activity)
consumer(sc_module_name nm) : in("in") {
in(*this); // promote own intf impl
• Depicted as circle }
in diagrams
virtual void put(const packet &t) {
cout << “Got packet: “ << t << endl;
wait(10,SC_NS);
}
};
 TLM Exports
parent
• Promotes an interface some consumer
implementation from a in in
initiator
child to parent export imp
put
SV
• Internally bound to child SV
export or imp/interface
in constructor class parent extends uvm_component;
uvm_blocking_put_export #(packet) in;
• Externally connected to
consumer cons;
`uvm_component_utils(consumer)
port or parent export, function new(string name,
but not required. (If no uvm_component parent=null);
connection, no activity) super.new(name,parent);
in = new("in", this);
• Depicted as circle
endfunction
function void build_phase(uvm_phase phase);
in diagrams cons=consumer::type_id::create(“const”,this);
endfunction
function void connect_phase(uvm_phase phase);
in.connect(consumer.in);
endfunction
endclass
 TLM Analysis Ports
monitor
• Ports that broadcast any # of
to all connected ap
targets
targets
ap->write( t );
(publisher/subscriber)
SC
• Read-only. Targets must
not modify. For debug,
scoreboards, etc. class monitor: public sc_module
{
• Usually does not sc_port<tlm_analysis_if<packet>,
require connection 0,SC_ZERO_OR_MORE_BOUND> > ap;
(SC_ZERO_OR_MORE_BOUND) monitor(sc_module_name nm) : ap(“ap”){
SC_THREAD(run);
• Depicted as diamond }
in diagrams void run() {
packet t;
...capture packet off bus...
ap->write( t );
}
};
 TLM Analysis Imps
class scoreboard extends uvm_component;
• Receives streams uvm_analysis_imp #(packet,scoreboard) actual_in;
of transactions from `uvm_component_utils(scoreboard)
connected publisher function new(string name,
(e.g. monitor) uvm_component parent=null);
super.new(name,parent);
• Read-only. actual_in = new("actual_in", this);
For debug, ...
scoreboards, etc. endfunction
virtual function void write(packet t);
• Like all exports/imps, packet exp;
does not require `uvm_info("SB/PKT/RECV",t.sprint(),UVM_MEDIUM)
a connection if (!expect_fifo.try_get(exp)) ...error
if (!t.compare(exp)) ...error
• Depicted as endfunction
circle in diagrams endclass
scoreboard
initiator ap
(publisher)
function void write (packet t);
…
endfunction SV
 TLM Initiator Socket
• Can do blocking or struct producer: public sc_module,
non-blocking transport public tlm_bw_transport_if< >
(Usually one or the {
other) tlm::tlm_initiator_socket< > out; // tlm_gp
producer (sc_module_name nm) : out(“out") {
out(*this); // bind bw intf to self
• Default type parameters SC_THREAD(fw_proc);
 tlm_generic_payload }
and base protocol // FORWARD PATH
void fw_proc() {
• Initiator must implement // prepare tlm gp trans...
all of bw interface out->b_transport(t,del); *or*
• unless simple initiator out->nb_transport_fw(t,ph,del);
socket used (utility layer) }
// BACKWARD PATH
virtual tlm_sync_enum nb_transport_bw(...) {
• If driving SV target, ...coordinate with fw path, per protocol
mem and debug }
methods can be stubbed virtual void invalidate_direct_mem_ptr(...) {
out; they won’t be called // Dummy implementation
}
• Depicted as square }; producer some
with outward facing target
arrow out->b_transport ( t, del ); socket
SC
 TLM Target Socket
• Can impl blocking or struct consumer: public sc_module,
non-blocking transport public tlm_fw_transport_if< > {
(Usually one or the tlm::tlm_target_socket< > in;
other) consumer(sc_module_name nm) : in(“in") {
in.bind(*this);
SC_THREAD(bw_proc);
• Default type parameters }
 tlm_generic_payload // FORWARD PATH
and base protocol void b_transport( packet& trans,sc_time& t ) {
// fully execute request, modify args, return }
• Target must implement tlm_sync_enum nb_transport_fw(...) {
all of fw interface // per protocol, update args as allowed,return}
• unless simple target socket bool get_direct_mem_ptr(…) { return FALSE; }
used (from utility layer) uint transport_dbg(…) { return 0; }

// BACKWARD PATH
• If driving SV target, void bw_proc() {
mem and debug ...coordinate with fw transport per protocol
methods can be stubbed in->nb_transport_bw(trans,ph,delay);
out. }
};
• Depicted as square some consumer
with inward facing arrow initiator
socket void b_transport (packet&, sc_time&)
SC
 TLM Sockets – Blocking Transport
• Blocking Transport

• Initiator indirectly calls b_transport in Target

• Initiator must not modify transaction; transaction contents invalid

until b_transport returns

• When b_transport returns, transaction is complete with

status/results

• Transaction can be reused in next b_transport call

initiator target

out->b_transport( t ); void b_transport( t ) {

check status… execute…
get results… set status…
}
 TLM Sockets – Non-blocking Transport
• Non-blocking Transport using Base Protocol
• Initiator starts request by calling nb_transport_fw in Target
- Target returns with updated arguments
• Target can call nb_transport_bw in Initiator at phase transitions
- To provide Initiator updates; Initiator may respond via fw interface
• Transaction contents, phase, & delay can change
- Only certain fields in certain phases, according to base protocol rules
• Transport calls continue back and forth until
either returns transaction complete status
- Same transaction handle used throughout its execution, for efficiency
- concurrent transactions possible—using different transaction object

initiator target

void run() {
tlm_status nb_transport_fw
stat = skt->nb_transport_fw
( t&, phase&, delay& ) {
( t, phase, delay );
process fw request…
} coordinate }
coordinate
tlm_status nb_transport_bw void run() {
( t&, phase&, delay& ) { stat= skt->nb_transport_bw
process bw response… ( t, phase, delay );
} }
 TLM Generic Payload
• TLM 2.0 defines Field Description
• a base transaction type:
tlm_generic_payload (TLM GP) command READ, WRITE, or
IGNORE
• a base protocol with initiator/target
sockets address Base address

data Data buffer, array of

• When used together, bytes.
interoperability is maximized data_length Number of valid
bytes in data buffer
response_ OK, INCOMPLETE,
• The TLM GP definitions and status GENERIC_ERROR,
converters are built-in ADDRESS_ERROR,
BURST_ERROR,etc.
• models that use the TLM GP
are the easiest to integrate byte_enable Byte-enable data
• connect and go! byte_enable_ Number of valid byte-
length enables
 Summary
• UVMC provides TLM1 and TLM2 connectivity SCSV
• See Part 2: UVMC Connections
• See Part 3: UVMC Converters

• UVMC provides a UVM Command API

• For accessing and controlling UVM simulation from SC
• See Part 4: UVMC Command API

• TLM helps isolate component implementations from the

outside world
• Integration easier—connect the ports, like modules
• Reuse enhanced—can reuse components in may different contexts

• TLM interoperability requires that components agree on

• data to exchange
• method of exchange (interface)
• direction of exchange (initiator or target)
 UVM Connect Presentation Series
• Part 1 – UVMC Introduction
• Learn what UVMC is and why you need it
• Review the principles behind the TLM1 and TLM2 standards
• Review basic port/export/interface connections in both SC and SV

• Part 2 – UVMC Connections

• Learn how to establish connections between
TLM-based components in SC and SV

• Part 3 – UVMC Converters

• Learn how to write the converters that are needed to transfer
transaction data across the language boundary

• Part 4 – UVMC Command API

• Learn how to access and control key aspects
of UVM simulation from SystemC
UVM Connect
Part 1 – Introduction

Adam Erickson
Verification Technologist

[email protected]
www.verificationacademy.com