Pipelined RAL access

[Kamlesh Shah]

I am using UVM RAL (version 1.1c) and with my bus agent which supports pipelined requests and out of order responses. In RAL adapter I have set provides_responses=1.  Now when I have two read requests active in same sequence under fork-join. Now response can come in any order. I see that once the response comes for any read requests, RAL unblocks both the read requests. I looked into source code and I found that in uvm_reg_map::do_bus_read() API, while calling get_base_response(), it does not pass the "transaction_id" as an argument. So it takes default = -1 which mean it waits for response and if any response comes, it returns that does not seem right. As I have initiated both read requests from same sequence,there will be only one parent sequence(rw.parent) and responses for both read request will land in same "response_queue".  Now while picking the response from parent sequence "response_queue", we should have use the "transaction_id". 

 

I would like to know if I am making any mistake to understand the behavior or it is indeed an issue.

 

 

uvm_reg_map::do_bus_read() implementation:

======================================

   if (adapter.provides_responses) begin
        uvm_sequence_item bus_rsp;
        uvm_access_e op;
        // TODO: need to test for right trans type, if not put back in q
        rw.parent.get_base_response(bus_rsp);
        adapter.bus2reg(bus_rsp,rw_access);
      end
 

======================================

 

 

uvm_sequence_base::get_base_response task implementation:

 

==========================================

virtual task get_base_response(output uvm_sequence_item response, input int transaction_id = -1);

    int queue_size, i;

    if (response_queue.size() == 0)
      wait (response_queue.size() != 0);

    if (transaction_id == -1) begin
      response = response_queue.pop_front();
      return;
    end

    forever begin
      queue_size = response_queue.size();
      for (i = 0; i < queue_size; i++) begin
        if (response_queue.get_transaction_id() == transaction_id)
          begin
            $cast(response,response_queue);
            response_queue.delete(i);
            return;
          end
      end
      wait (response_queue.size() != queue_size);
    end
  endtask

=====================================
 

[walkeranderson]

I just hit this same problem and tracked it down to the same underlying problem in the UVM code.

 

This change, to both the do_bus_read() and do_bus_write() tasks in uvm_reg_map.svh, seemed to fix it for me.

 

Changed:

        rw.parent.get_base_response(bus_rsp);

to:

        rw.parent.get_base_response(bus_rsp, bus_req.get_transaction_id());

 

Any comments on whether this is a bug or not.  It is not changed/fixed in the UVM 1.2 release.

[uwes]

i filed http://eda.org/svdb/view.php?id=5069 to track the issue

/uwe

[walkeranderson]

FWIW, Later yesterday I found this bug logged which seems to be the same thing.

 

http://www.eda.org/svdb/view.php?id=4820

[rangervaloy]

No, it didn't get fixed in 1.2...

[Ramababu]

Hi, 

can any one tell here how to resolve the above issue?

it's a uvm_pkg source code and we can't change it right? 

how to implement it in our TB? do we need extend any classes?