Jump to content
Sign in to follow this  
Kamlesh Shah

Pipelined RAL access

Recommended Posts

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

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...