Delay between driver driving the interface signals and monitor sampling the same

UVM
1

I have been trying to figure out why there’s a delay of 1 clk cycle in the timestamp between when the driver sends the transaction on the interface and when the monitor samples it. Can someone help me with this?

Driver -


task run_phase (uvm_phase phase);
  forever begin
    seq_item_port.get_next_item(trans);
    drive_trans(trans);
    seq_item_port.item_done();
  end
endtask

task drive_trans (my_seq_item trans);
  vif.drv.drv_cb.data <= trans.data;
  @(vif.drv.drv_cb);
endtask

Monitor -


task run_phase (uvm_phase phase);
  forever begin
    @(vif.mon.mon_cb);
    trans.data = vif.mon.mon_cb.data;

    monitor_analysis_port.write(trans);
  end
endtask

Interface -


interface intf (input clk, input rstn);

  logic [31:0] data;

  clocking drv_cb @(posedge clk);
    output data;
  endclocking

  clocking mon_cb @(posedge clk);
    input data;
  endclocking

  modport drv (clocking drv_cb, input clk, rstn);
  modport mon (clocking mon_cb, input clk, rstn);
endinterface
2

In reply to tpan:

When you sample the data at posedge of clock then you get the value it had. you won’t get the new value which you are driving at that clock edge.

//SystemVerilog Scheduling :
Evaluate the Right-Hand-Side (RHS) of all nonblocking assignments happen in active region and udates to the Left-Hand-Side (LHS) variables happen in NBA region.


  //driver side
  always @(posedge clk)begin
    b <= a;    // vif.drv.drv_cb.data <= trans.data;
  end
  

  //monitor side 
  always @(posedge clk)begin
    c <= b;    // trans.data = vif.mon.mon_cb.data;
  end
3

In reply to Rahulkumar:

Thanks. I will read up more on the different regions for better understanding. So is this what all testbenches see, that is driving of data happens at clk_cycle T and this data is shown as being sampled by the monitor at clk_cycle T+1.

4

In reply to tpan:

In reply to Rahulkumar:
So is this what all testbenches see, that is driving of data happens at clk_cycle T and this data is shown as being sampled by the monitor at clk_cycle T+1.

No, it’s depend on your requirement.

  1. You can drive on posedge and sample on negedge. so absolute delay of half clock cycle.
  2. You can drive on posedge and sample on posedge. so absolute delay of 1 clock cycle.
    etc.
5

In reply to Rahulkumar:

I get your point. But I remember seeing simulations where the timestamps at the point the data is sampled by monitor matches the timestamp when the data is driven (while looking at the waveform). How do you think this gets done if the driving part and monitoring part are done at different points within a simulation cycle?

6

In reply to tpan:

In reply to Rahulkumar:
I get your point. But I remember seeing simulations where the timestamps at the point the data is sampled by monitor matches the timestamp when the data is driven (while looking at the waveform). How do you think this gets done if the driving part and monitoring part are done at different points within a simulation cycle?


//driving
@(posedge clk)
vif.data <= tr.data;

//monitor
@(posedge clk)
#1ns; //delta delay
tr.data = vif.data;

i don’t recommend this approach.