In reply to chr_sue:
I guess the terminology I’m using is a bit confusing…
Yes, there is always an adapter, otherwise there is no way to map RAL to DUT transaction. The difference is where to “call” this adapter. In common use case we call uvm_reg_map.set_sequencer(seqr, adapter) to tell RAL which seqr to use, and how to convert abstract level RAL to transaction through a adapter. Then we use RAL-level “sequence” just to do RAL writes/reads. There is no extra sequence involved. Adapter in this case will go to m_adapter of uvm_reg_map, then do_write and do_bus_write, where RAL is converted into BUS transaction.
In this layered example reg2apb_seq or uvm_reg_sequence is the translation (low-layer) sequence I was talking about. It is not needed in common RAL case. There is also an extra sequencer (reg_seqr). This is on top of the sequencer typically in bus agent. uvm_req_sequence also has a adapter to do RAL/bus transaction conversion. In this case RAL/BUS transaction conversion is “done” here instead of through uvm_reg_map directly. But again it will go through uvm_reg_map do_bus_write eventually.
Now back to the issue I’m facing. In uvm_reg_sequence’s body, there is a forever loop to fetch item from reg_seqr. What I’m seeing is that the loop gets stuck when phases moves from configure to main.
forever begin
uvm_reg_item reg_item;
reg_seqr.peek(reg_item);
do_reg_item(reg_item);
reg_seqr.get(reg_item);
#0;
end