Sampling logic in UVM monitor : on all the clocks

I am a relatively newbie to UVM coding. I am aware of overall flow. I have a question here.
I am writing UVM testbench for BRAM :
RTL is:

    // Write logic
    always @(posedge clk)
        if(wr_en)
            mem[wr_addr] <= wr_data;
//Read logic
    always @(posedge clk)
      rd_data = mem[rd_addr];    

i.e rd_data is available in next clock cycle for the given read_addr continuously.

But when i try to sample this rd_data in monitor, I may lose data on some clocks.

Here is my seq_item and UVM monitor code:

class ram_seq_item extends uvm_sequence_item;
  //data and control fields
  rand bit            wr_en;
  rand bit [ADDR-1:0] wr_addr;
  rand bit [DATA-1:0]  wr_data;
  rand bit [ADDR-1:0] rd_addr;
       bit [DATA-1:0] rd_data;
     :
     :
     :
endclass

class ram_monitor extends uvm_monitor;
  uvm_analysis_port #(ram_seq_item) sampled_collect_port;
  virtual ram_if vif;
  ram_seq_item trans_collected;
    :
    :
    :
virtual task run_phase(uvm_phase phase);
    forever begin
      @(posedge vif.MONITOR.clk);
       // write transaction
      if(vif.monitor_cb.wr_en) begin
        trans_collected.wr_addr = vif.monitor_cb.wr_addr;
        trans_collected.wr_en = vif.monitor_cb.wr_en;
        trans_collected.wr_data = vif.monitor_cb.wr_data;
      end
        //read transaction
        trans_collected.rd_addr = vif.monitor_cb.rd_addr;
        @(posedge vif.MONITOR.clk);
        trans_collected.rd_data = vif.monitor_cb.rd_data;
      end
      sampled_collect_port.write(trans_collected);
    end
  endtask : run_phase

In above case, when i wait for 1 clock to collect rd_data from DUT, i might miss read sampling for that clock cycle, right? Though, I can take care of write transaction easily, thinking about read transaction.
How do i overcome that?
can’t we do continuous reads? i think, this shouldn’t be the case.
Any lead to solve above problem would be appreciated.
Thanks in advance

In reply to proinuvm:

What you are describing is not a UVM topic. It is simply a SV modelling problem.
Follow the waveforms and the BRAM spec to implement your monitor.

In reply to chr_sue:

Thank you chr_sue. my BRAM spec does require continuous reads. I will look into it further.

Probably the problem is with SV modellingv or the way, driver is coded.
But most of the code/flow i have referred for UVM driver too is almost the same. Was wondering if i missed to go through any specific uvm topics. Please provide me the links, if so.

In reply to proinuvm:

The key question is: what is the protocol? Is it ‘AXI4-Lite’. This protocol ha single and multiple writes and reads.

In reply to chr_sue:

Its a simple Block ram with write_en control. wr_data is written in the mem at addr wr_addr when wr_en is high.
There is no rd_en control. rd_data comes out for rd_addr in next clock cycle.
I could take care of it now. But default value setting drive task of driver is creating some issue. will get back, if i dont get it.
thank you!

In reply to proinuvm:

You need a protocol description like this:
https://www.xilinx.com/support/documentation/ip_documentation/axi_bram_ctrl/v4_0/pg078-axi-bram-ctrl.pdf

This helps you to implement your driver and monitor.

In reply to chr_sue:

thank you chr_sue! I did go through RTL interface and I have a working UVM TB for that now.