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.
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