Kamlesh Shah Posted April 10, 2013 Report Share Posted April 10, 2013 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 ===================================== Quote Link to comment Share on other sites More sharing options...
walkeranderson Posted November 20, 2014 Report Share Posted November 20, 2014 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. Quote Link to comment Share on other sites More sharing options...
uwes Posted November 21, 2014 Report Share Posted November 21, 2014 i filed http://eda.org/svdb/view.php?id=5069 to track the issue /uwe Quote Link to comment Share on other sites More sharing options...
walkeranderson Posted November 21, 2014 Report Share Posted November 21, 2014 FWIW, Later yesterday I found this bug logged which seems to be the same thing. http://www.eda.org/svdb/view.php?id=4820 Quote Link to comment Share on other sites More sharing options...
rangervaloy Posted November 26, 2014 Report Share Posted November 26, 2014 No, it didn't get fixed in 1.2... Quote Link to comment Share on other sites More sharing options...
Ramababu Posted May 4, 2020 Report Share Posted May 4, 2020 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? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.