Blocking, non-blocking, FIFOs and channels

What blocking means in time

U3.3 named the flavours; here is what they mean in time against a FIFO. A blocking method is a task: the caller's thread may wait inside it, for any amount of simulated time. A non-blocking method is a function: it returns in the same time step, with 1 when it did the work and 0 when it could not.

The flavour decides where you may call it. A function cannot call a task, so code inside a write function or another function can use only the non-blocking forms.

function void send(pkt t);
  put_port.put(t);      // put is a task
endfunction
// %Error-FUNCTIMECTL: Functions cannot
//   invoke tasks

function bit send(pkt t);
  if (put_port.try_put(t)) return 1;
  dropped++;            // decide what a full FIFO means
  return 0;
endfunction

A try_put that returns 0 does nothing at all. In the example the test calls try_put(#99) on the full FIFO at 1 ns; it returns 0 and #99 never appears. Count or report those returns, or the loss is silent.

A FIFO between two initiators

uvm_tlm_fifo #(T) is a component with a storage queue and imps on both sides. Its put_export is a uvm_put_imp and its get_peek_export is a uvm_get_peek_imp. The producer pushes in through a port, the consumer pulls out through a port, and neither knows the other exists.

The third constructor argument is the size: new("fifo", this, 2) holds two packets, the default is 1, and 0 means unbounded. The trace below follows the example.

1. producer: put(#3) at 0 ns

   The FIFO already holds #1 and #2, so the producer's thread waits inside fifo.put.

2. consumer: get -> #1 at 10 ns

   The consumer's get removes #1. used() reads 1 at that moment.

3. producer: put(#3) returned at 10 ns

   Space exists, so #3 is stored and the producer moves on to put(#4), which waits again.

4. producer: put(#5) returned at 30 ns

   The producer finishes. The consumer drains #4 and #5 at 40 and 50 ns.

Size is a design decision. A size of 1 makes the producer wait for nearly every packet; size 0 never blocks but lets a runaway producer fill memory. Pick the depth the real hardware would have, or the depth you want to stress.

Looking inside and clearing out

The FIFO answers questions without changing anything: size() is its capacity, used() the packets held, and is_empty() and is_full() the two extremes. At 1 ns the example prints size=2 used=2 is_full=1 can_put=0.

peek and try_peek return the oldest packet without removing it. Two peeks give the same handle: the example prints 1 for a == b. An output argument of a class type copies the handle, never the object; a separate object would need clone(). Change a field through a peeked handle and the consumer's later get sees the change.

flush() discards what the FIFO holds. In a variant that flushes at 1 ns, #1 and #2 are never seen, and the producer waiting in put(#3) refills the FIFO at once: put(#3) returns at 1 ns. So flush alone is not a reset. A reset must also stop or restart the producer and the consumer, and count the discarded packets itself.

Two more limits apply. flush refuses, with the error flush failed, when packets are stored while a get is still pending. And the FIFO's two analysis ports, put_ap and get_ap, publish each successful put and get; packets removed by flush, and packets only peeked at, are never published.

Requests and responses through a channel

Some exchanges need an answer. uvm_tlm_req_rsp_channel #(REQ, RSP) is two FIFOs, one for requests and one for responses, each of size 1 by default. Both sides are initiators again, with two ports each.

A related component, uvm_tlm_transport_channel, adds a transport_export: one transport(req, rsp) call puts the request and then waits for the response from the same two FIFOs.

Try it

Lines 1 to 18 are the FIFO: two puts return at once, the third waits until the first get at 10 ns, and the producer finishes at 30 ns. Lines 19 to 26 are the channel: each request waits 5 ns for its response.

Try it: change the size to 0 (unbounded) and all five puts return at 0 ns. Change it to 1 and the producer finishes at 40 ns.

Check yourself

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

class producer extends uvm_component;
  `uvm_component_utils(producer)
  uvm_blocking_put_port #(int) put_port;
  function new(string name, uvm_component parent); super.new(name, parent); put_port = new("put_port", this); endfunction
  task run_phase(uvm_phase phase);
    phase.raise_objection(this);
    for (int i = 1; i <= 5; i++) put_port.put(i);
    $display("producer finished at %0d ns", $time);
    phase.drop_objection(this);
  endtask
endclass

class consumer extends uvm_component;
  `uvm_component_utils(consumer)
  uvm_blocking_get_port #(int) get_port;
  function new(string name, uvm_component parent); super.new(name, parent); get_port = new("get_port", this); endfunction
  task run_phase(uvm_phase phase);
    int v;
    forever begin
      #10;
      get_port.get(v);
    end
  endtask
endclass

class depth_test extends uvm_test;
  `uvm_component_utils(depth_test)
  producer prod;
  consumer cons;
  uvm_tlm_fifo #(int) fifo;
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  function void build_phase(uvm_phase phase);
    prod = producer::type_id::create("prod", this);
    cons = consumer::type_id::create("cons", this);
    fifo = new("fifo", this, 3);
  endfunction
  function void connect_phase(uvm_phase phase);
    prod.put_port.connect(fifo.put_export);
    cons.get_port.connect(fifo.get_export);
  endfunction
endclass

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

port.peek(t);

while (!port.try_get(t)) #1;

port.get(t);

port.peek(t);
      port.get(t);

Practice

• The trace window that never drops quietly Implement · Medium