The TLM-1 family: interfaces, flavours and masks

Eight interfaces, three flavours

A TLM-1 class name has three parts: uvm_ + flavour + interface + role. The interface names the methods, the flavour says blocking, non-blocking or both, and the role is port, export or imp from U3.2.

Read a name left to right. uvm_nonblocking_get_port is a caller that may use try_get and can_get only. uvm_put_imp is a target that must implement put, try_put and can_put. uvm_slave_imp is a target that hands out requests and takes responses.

How a port knows which methods it may call

Each class sets a bit mask, m_if_mask, from constants such as UVM_TLM_BLOCKING_PUT_MASK (bit 0) and UVM_TLM_NONBLOCKING_PUT_MASK (bit 4). A combined class ORs them. The example prints them at end of elaboration: blocking put port 001, non-blocking put port 010, combined put imp 011.

connect checks one rule: the provider's mask ANDed with the caller's mask must equal the caller's mask. A provider may offer more than the caller uses, never less. Exports are checked the same way, so a uvm_put_export in front of a uvm_put_imp serves both kinds of caller.

The mask only advertises; it does not create methods. Each class body expands the macros for its interface, so a uvm_blocking_put_port gets a put task and nothing else. Its try_put is still callable, because every class extends uvm_tlm_if_base, but that base body only reports a UVM_ERROR, UVM TLM interface function not implemented, and returns 0. Choose the flavour you will call, and let connect check the rest.

Master and slave: requests and responses as separate calls

A master port bundles two directions for an initiator: it puts requests and gets responses. A slave port is the mirror for the component that serves them: it gets requests and puts responses. Both are initiators, so they meet through a component that implements both sides, usually uvm_tlm_req_rsp_channel with its master_export and slave_export.

A master that puts a batch before collecting anything can stop for good. With the default sizes of 1, the channel accepts three requests without a single get. One waits in the request FIFO, one is with the slave, and one has become a response in the response FIFO. A fourth put waits for space, the slave waits to return its second response, and neither can move.

The remedy is to collect while sending. Run the put loop and the get loop as two forked threads, or cap the requests in flight at what the channel can hold, as the spot question shows. Three requests, as in the predict question, happen to fit; that does not make a larger batch safe.

nb_transport(req, rsp) is the non-blocking transport of TLM-1: a function that returns 1 with the response filled in when the target can answer now, and 0 otherwise. Use it for zero-time models called from a function, such as a lookup inside write. It is unrelated to TLM-2.0's nb_transport_fw and nb_transport_bw, which carry phases through sockets (U9.4).

Try it

The two mask lines show the bits behind each name: put is bit 0 and its non-blocking form bit 4, get and peek add bits 1, 2, 5 and 6, and bits 9 and 10 mark master and slave. Lines 3 to 7 are two callers of different flavours sharing one combined imp; lines 8 to 17 are the master and slave exchange.

Try it: change put_model's imp to uvm_blocking_put_imp #(pkt, put_model) and rebuild. The non-blocking connection fails with the interface error, while the blocking one stays legal.

Check yourself

`timescale 1ns/1ns
`include "uvm_macros.svh"
import uvm_pkg::*;

class pkt extends uvm_sequence_item;
  `uvm_object_utils(pkt)
  int id;
  function new(string name = "pkt"); super.new(name); endfunction
endclass

class master extends uvm_component;
  `uvm_component_utils(master)
  uvm_blocking_master_port #(pkt, pkt) port;
  function new(string name, uvm_component parent); super.new(name, parent); port = new("port", this); endfunction
  task run_phase(uvm_phase phase);
    pkt q, r;
    phase.raise_objection(this);
    for (int i = 1; i <= 3; i++) begin
      q = new;
      q.id = i;
      port.put(q);
    end
    repeat (3) port.get(r);
    $display("%0d ns: last response #%0d", $time, r.id);
    phase.drop_objection(this);
  endtask
endclass

class slave extends uvm_component;
  `uvm_component_utils(slave)
  uvm_blocking_slave_port #(pkt, pkt) port;
  function new(string name, uvm_component parent); super.new(name, parent); port = new("port", this); endfunction
  task run_phase(uvm_phase phase);
    pkt q, r;
    forever begin
      port.get(q);
      #5;
      r = new;
      r.id = q.id + 100;
      port.put(r);
    end
  endtask
endclass

class ms_test extends uvm_test;
  `uvm_component_utils(ms_test)
  master ma;
  slave  sl;
  uvm_tlm_req_rsp_channel #(pkt) chan;
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  function void build_phase(uvm_phase phase);
    ma   = master::type_id::create("ma", this);
    sl   = slave::type_id::create("sl", this);
    chan = new("chan", this);                 // default FIFO sizes: 1 and 1
  endfunction
  function void connect_phase(uvm_phase phase);
    ma.port.connect(chan.master_export);
    sl.port.connect(chan.slave_export);
  endfunction
endclass

module tb;
  initial run_test("ms_test");
endmodule

s.put_port.connect(k.put_imp);

s.put_port.connect(f.put_export);

s.put_port.connect(m.put_imp);

s.put_port.connect(w.put_export);

for (int i = 1; i <= 4; i++) begin
      q = new; q.id = i; port.put(q); sent++;
      if (sent - got == 3) begin port.get(r); got++; end
    end
    while (got < 4) begin port.get(r); got++; end

for (int i = 1; i <= 4; i++) begin q = new; q.id = i; port.put(q); sent++; end
    repeat (4) begin port.get(r); got++; end

fork
      for (int i = 1; i <= 4; i++) begin q = new; q.id = i; port.put(q); sent++; end
      repeat (4) begin port.get(r); got++; end
    join

for (int i = 1; i <= 4; i++) begin q = new; q.id = i; port.put(q); sent++; port.get(r); got++; end