I am starting a sequence in configure_phase() with an intend to continue running until test ends (i.e through configure_phase() and main_phase())
Sample code as below and I expect the sequence to start in configure_phase() but continue running even after the phase ends. I rather see the error
m_sqr: SEQREQZMB: The task responsible for requesting a wait_for_grant on sequencer <> for sequence <‘’> has been killed, to avoid a deadlock the sequence will be removed from the arbitration queues at /tools/mentor/questasim/10.4c_2/questasim/verilog_src/uvm-1.1d/src/seq/uvm_sequencer_bas e.svh(709)
Do you have objections at any other places as well? For e.g. at test level.
If no, then phase objection mechanism in configure_phase() does not look effective as drop_objection will be called just after raise_objection is being called because fork - join_none is used there.
Yes, the following main_phase() has objection and test continues to main_phase. The problem I see is the sequence getting killed once configure_phase ends
I think all processes called after call to raise_objection() will get killed once drop_objection() is encountered. To keep the sequence running objections should not be called there.
When a phase completes, all forked tasks of that phase will be killed, hence why your sequence stops.
This is one of the reasons that we recommend to only use the run_phase(). Within the run_phase(), use sequences to control the reset, main stimulus generation, etc. This will provide the greatest compatibility across the UVM ecosystem.
How would you control reset and stimulus generation using sequences?
For eg, in a testbench with multiple envs and agents, how do I synchronize such that all env’s complete initilization (backdoor or frontdoor) before all agents start stimulus phase?
Would I need to implement my own synchronization using uvm events?
At your test level, you would fork…join around all your reset sequences. Similarly you would fork…join around all the stimulus sequences. The join will ensure that all of the forked sequences have completed prior to forking the next set of sequences. If you want a sequence to run forever, then use a fork…join_none.
Generally, we configure the DUT in the configuration phase sequence and send any data traffic in main phase.
Is it possible to restructure your configuration sequence so that the DUT configuration resides in configuration sequence and the other thing which runs in forever and should be there till end of test?
This way you will be able to synchronize DUT configuration through configure phase and forever can be called from rum phase.
Reading this discussion gives me the impression you need some education in dealing with the phased approach of the UVM on the one hand and TLM on the other hand.
If you believe you need the sub-phases you can use them. But you have to consider the behavior these sub-phases have. From my point of view with 15+ UVM projects done in the past I’d recommend the sub pahes of the run phase only as an exception. It provides you one way to do the things you need. But using them this might result in consequences you have to consider.
From my professional experience I think there is no need to use them. You can solve all your tasks working the run-phase only. It is very common for all designs that you have a reset mode and a configuration mode before starting the operational mode.
Doing so, you need one or more reset and configuration sequences for each agent or sub-env. They will be executed before you enter a forever loop with your operational sequences.
BTW what do you mean with backdoor/frontdoor initialisation. The usage of backdoor and frontdoor is limited to the register access.