In reply to v-markovic:
My recommedndation is to comment-out all begin_tr/end_tr. This will ease your debug process.
BTW all simulators offer a built-inn transaction recodingat maybe different places. Then you do not need any begin_tr/end_tr. But you have to make sure you have overwritten the method do_record for the seq_item.
The thing is that when I call reg.write(), on the next clock cycle I see that:
env.reg_agent.seqr.has_do_available()=1
which is not the case for all previous transactions which are executed correctly.
Could this somehow be the reason for transaction not being sent from sequencer to the driver?
It remains env.reg_agent.seqr.has_do_available()=1 forever, and never changes back to 0.
In reply to v-markovic:
The RAL is not designed to work with its command on the pinlevel.
Finally you do not need the function has_do_available().
What I see in your contributions on top is you are mixing structural with execution aspects.
bus_req.set_sequencer(sequencer);
Is the wrong command. You have to specify the sequencer for executing register sequences in your environment.
Simply follow the guidelines the UVM Cookbook is recommending. See here the details:
https://verificationacademy.com/cookbook/registers
Actually I am specifying sequencer in my env, according to cookbook.
The code:
bus_req.set_sequencer(sequencer);
is something I just put above in the post, it is from UVM source code (uvm_reg_map), I do not use it in my env. I just wanted to give more details about what is the flow.
Basically everything is connected and working properly until this one transaction, when something differently happens. I don’t think the problem is in the UVM, it is definitely in my env, but it is very difficult to trace why driver does not receive transaction from sequencer. This is why I am trying to add different printouts in my env by calling some predefined UVM functions, like has_do_available() etc.
In reply to v-markovic:
In your env you have to do (best is to do this in the connect_phase of your env):
if (regmodel.get_parent() == null) begin
my_adapter reg2ad = my_adapter::type_id::create("reg2ad",,get_full_name());
regmodel.default_map.set_sequencer(m_sequencer, reg2ad); // Add adapter
regmodel.default_map.set_base_addr(BASE_ADDR_REGION); // System base address
end
Note the set_sequencer has a 2nd argument.
Yes, this is exactly how it is connected in my env.
I see that for all transactions that are executed:
env.m_reg_agent.sequencer.m_req_fifo.used() = 1
but for the last one that gets stuck I see that (after I call reg.write(…)):
env.m_reg_agent.sequencer.m_req_fifo.used() = 0
Looks like sequencer is not getting transaction at all.
In reply to v-markovic:
The sequencer is generating the transactions. Looks like something went wrong with the handshake between sequencer and driver.
Which approach you are using? get or get_next_item.
I am using get_next_item().
So it looks like sequencer generates transactions correctly for some time, but then for some reason it stops. Strange…I was also trying to see if I have some “disable fork” statements that may have caused the problem, but looks like it is not the case.
I wonder what would make sequencer stop generating transactions.
I also see that driver is locked at get_next_item() and waits, which is ok, but does not get anything from sequencer.
Maybe something between the sequence and the sequencer stops working
In reply to v-markovic:
If it does not get an item you should look to your sequence body task, what happens there.
I just have:
regmodel.reg.some_field.set(0);
regmodel.reg.update();
I see only reg2bus() is executed, but something is stuck after that.
In reply to v-markovic:
The set is modifying the mirror register. The update command will update the DUT register field.
What are the next commands?
There are few commands but they are never reached, regmodel.reg.update() never returns
Same behavior.
I will try using disable fork statement or stop_sequencer() or something like that, maybe I get some results
In reply to v-markovic:
I believe this will not help.
Please check the access rights of the corresponding fields and the register it belongs to.
And try
regmodel.reg.some_field.update();
I had one process started at the beginning of the test with fork-join_none and it was running in background. This process was something like:
fork
begin
forever begin
wait(regmodel.cfg0.is_busy() == 1’b0);
regmodel.cfg0.enable.set(N); // N can be 0 or 1
regmodel.cfg0.update(status);
// Wait some delay
end // forever
end
join_none
When I removed this process, then everything works ok, not sure what exactly is the reason, but if I find out I will post it.
Thank you very much for your time and suggestions.
I found the real reason for RAL model getting stuck.
Beside using regmodel.reg_name.write() or read(), I was also sending transactions from another process using start_item()-wait_some_delay-randomize-finish_item().
Of course, the problem was the delay between start_item() and finish_item(), which should never be used! After removing the delay, everything worked.
In reply to v-markovic:
Great to hear this and one of the very important findings with delay on the transaction level!
i am stuck on RAL integration, i dont know where i did mistake my error is :[UVM_FATAL @ 15: uvm_test_top.uenv.apb_agnt.apb_sqr [apb_sqr] send_request failed to cast sequence item.
and one more thing i have given display statement inside reg2bus of adapter class its display is coming but if i am putting display statement inside bus2reg into adapter class then display is not appear.
please help me.