Pipelined Monitor strategy

I’m experimenting with a pipelined interface. I found documentation on pipelined drivers in the UVM Cookbook and buried in the UVM source files (header of uvm_transaction), but nothing on pipelined monitors. I made my own pipelined monitor based on the pipelined driver.

I plan to add protocol checks. At first I was going to add my own member variables to record the begin/end times, then I noticed uvm_transaction has accept_tr/begin_tr/end_tr and get_* methods which have the desired behavior. I haven’t seen any monitor example use these methods. Is it save/recommended to use these methods in the monitor?

Is this the correct approach? Is there a better strategy?

task run();
    // this monitor supports a two-deep pipeline
    fork
      do_item();
      do_item();
    join
endtask

task do_item();
  forever begin
    mbus_item tr;
    lock.get();
    tr = mbus_item::type_id::create("tr");
    accept_tr(tr);
      // wait for qualification
    begin_tr(tr);
      // collect address phase

    ap.write(tr); // put here to prevent clobber

    // allows next transaction to begin address phase
    lock.put();
    if(tr.expectData()) begin
      data_lock.get();
        // wait for qualification
        // collect data phase
      data_lock.put();
    end
      // (may trigger custom "data_phase" event here)
    end_tr(tr);
  end
endtask: do_item

In reply to chr_sue:

Can you tell me how to get transaction-id in the monitor?
From the driver we can send transaction-id to the sequence by writing rsp.set_id_info(req); seq_item_port.put(rsp);.
In the body of the sequence we can use, get_response(rsp, req.get_transaction_id());
How do we get id information in the monitor?

In reply to sudhanshu:

Could you please explain what is the reason for your run_phase implementation in the monitor?

In reply to chr_sue:

I am trying to implement AHB master UVC. I could create pipelined driver, now I want to create AHB monitor. Please suggest me an efficient way to create monitor.
I have few doubts

  1. Should I use semaphore (same as driver) in the monitor as well?
  2. If I capture both address & data phase in one transaction packet in the monitor then by the time I get data phase of 1st transaction, address field of the packet is updated with the address phase of 2nd transaction. So I get wrong information. How to handle this?

[i]In reply to sudhanshu:[/

If you are using strict pipelining then it should not be a serious problem to create a monitor run_phase.
But I believe it is a better solution to handle the responses in the driver. The driver has all the mechanisms you need to do this.