Types of Ports in UVM TLM

In UVM (Universal Verification Methodology), TLM (Transaction Level Modeling) is used to transfer data between components using transactions instead of signals.
To enable this communication, UVM defines three fundamental TLM connection types

Three Types of TLM Connection Objects in UVM:

UVM TLM communication is built using:

  1. Port
  2. Export
  3. Implementation (Imp)

These are not SystemVerilog ports — they are UVM class-based communication objects

TLM Port

A TLM port is used by a component to initiate a transaction.

  • Acts as a caller
  • Does not implement the method
  • Connected during the connect_phase
uvm_blocking_put_port #(my_txn) put_port;           //unidirectional
uvm_analysis_port      #(my_txn) analysis_port;

uvm_transport_port #(REQ, RSP) trans_port;           //bidirectional

Constructor Method:

trans_port = new(string name, uvm_component parent);

Typical Usage

  • Sequencer → Driver
  • Monitor → Scoreboard

TLM Export

A TLM export acts as a forwarding interface.

  • Forwards method calls
  • Does not contain implementation logic
  • Used when a component is an intermediate connection point
uvm_blocking_put_export #(my_txn) put_export;     //unidirectional

uvm_transport_export #(REQ, RSP) trans_export;     //bidirectional

Constructor Method:

trans_export = new(string name, uvm_component parent);

Typical Usage

  • Environment forwarding transactions to sub-components
  • Hierarchical connections

TLM Implementation (Imp)

A TLM imp provides the actual implementation of TLM methods.

  • Implements put(), get(), write(), etc.
  • Final transaction consumer
  • Must define method behavior
uvm_blocking_put_imp #(my_txn, my_comp) put_imp;      //unidirectional

uvm_transport_imp #(REQ, RSP, IMP) trans_imp;               //bidirectional

REQ → request type

RSP → response type

IMP → component class implementing the method

Constructor Method:

trans_imp = new("trans_imp", this);

Picture Representation:

Valid TLM Connections in UVM

UVM enforces strict connection rules to maintain architectural correctness.

From – ToValid
Port → Export✅ Yes
Port → Imp✅ Yes
Export → Export✅ Yes
Export → Imp✅ Yes
Port → Port✅ Yes (hierarchical forwarding case)

Invalid Connections:

From – ToValid
Imp → Port❌ No
Imp → Export❌ No
Imp → Imp❌ No

Rule: Calls always flow towards the implementation, never away from it.

Port-to-Port Connection:

This is most commonly seen when connecting a sub-component port to a parent component port, such as driver → agent → environment.

🔹 Method calls must ultimately terminate at an imp.
🔹 Ports may be chained hierarchically to forward calls upward.

Child port → parent port → export/imp → Allowed

Let’s understand it through an example.

Driver (child)

uvm_blocking_put_port #(my_txn) drv_put_port;

Agent (parent)

uvm_blocking_put_port #(my_txn) agent_put_port;

Valid Port-to-Port Connection

// Inside agent.connect_phase()
driver.drv_put_port.connect(agent_put_port);

Later, the agent’s port must connect to an export or imp:

agent.agent_put_port.connect(scoreboard.put_export);

If the chain never reaches an imp, UVM will throw a runtime error.

Think of ports as pipes, not endpoints.

Port → Port → Port → Export → Imp

As long as:

  • Direction is consistent
  • Interface types match
  • The chain ends at an imp

…it is valid UVM TLM.

Previous
Next