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.
- Initiatorsinitiate requests, Targets satisfy requests (control flow)
- Producersproduce data, Consumersexecute 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 SCSV
• 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
