How TLM Works

Contents are extracted from the Advanced UVM sessions by Verification Academy.

TLM

TLM is all about communication through method calls

• A TLM port specifies the “API” to be used
• A TLM export supplies the implementation of the methods

Connections are between ports/exports, not components

Transaction are objects

Ports & exports are parameterized with the type of the transaction being communicated

Factory can be used to change the component’s type, as long as it is similar type and have the same set of interfaces

Hierarchical connections

Port-to-Export

port.connect(export);

Port-to-Port

child.port.connect(parent_port);

Export-to-Export

parent_export.connect(child.export);

Last export is actually an ‘imp’

The source use the interface

The target supply the implementation of the interface

The implementation contains the transaction type and type of the component contains the implementation

The transaction flow from C1 → C2 and C2 will do something with it

⇒ Factory override is also possible, C2X having different implementation on the put task

Analysis Communication

Analysis ports support 1:n connections

• All write() functions called in zero time

Used by coverage collectors and scoreboards

• uvm_subscriber has built-in analysis_export

Every components connect to the analysis_port will have an implementation of the write() method

When one subscriber made one change on the transaction, all other subscribers will know the changes

Recommended to make a copy of the transaction handle when implementing the write() method

Analysis of multiple streams

The uvm_subscriber only support single connection to analysis_port

Choice 1: Use imp suffixes defined via macro

• Declare macros outside of component
• Instantiate suffixed imps
• Implement write_SUFFIX methods

Write methods are functions

• Can’t synchronize between streams

Choice 2: Use embedded FIFOs (recommended)

• Declare analysis exports
• Connect exports to FIFOs

run_phase can now actively pull from FIFOs

TLM2 in UVM

TLM2: SystemC’s feature

TLM2 based on a generic_payload transaction base class

• TLM2 uses sockets, which contain both a port and an export
• Pass-by-reference (pass-by-value in TLM1)
• The generic payload can be extended to model any kind of transaction

Connections are between sockets, just like ports/exports

• Initiator socket connects to target socket

Blocking transport

Completes the entire transaction within a single method call

• Uses the b_transport() task

Nonblocking transport

Bidirectional communication

• Uses the nb_transport_fw() and nb_transport_bw() functions
• Initiator implements the nb_transport_bw()
• Target implements the nb_transport_fw()

uvm_tlm_sync_e: Indicates the status of the transaction

Pass through sockets

Generic Payload

All elements are rand and protected

Must use predefined virtual accessor methods

Defined to be either READ, WRITE or IGNORE command

Summary

Every port must eventually connect to an implementation (imp)

Mostly only use 2 port/export connections:

All TLM connections go from ‘origin’ to ‘destination’

• port.connect(export);
• child_port.connect(parent_port);
• parent_export.connect(child_export);