Search the Community
Showing results for tags 'phase'.
Found 8 results
-
Hi I was planning to move my TB flow from run_phase to main_phase and other runtime phases to take advantage of these phases. But I've received the attached snapshot indicating these phases would be removed in the future UVM versions. Is this change approved?
-
Hi why does phase.find_by_name(.name(uvm_main_phase::get().get_name()), .stay_in_scope(0)); from run_phase and uvm_pkg::uvm_phase run_phase = phase.find_by_name(.name(uvm_run_phase::get().get_name()), .stay_in_scope(0)); from main_phase return null. Is this intentional? I have created a sample example to check, or you can use the attached file as well. https://www.edaplayground.com/x/5Py7 test.svh -
Hi, I have a doubt about requirement of raise/drop_objection. Why does a compiler need objections in run_phase? Why can it not just wait for time given like 100ns as following example? Ex. task run_phase(uvm_phase phase); //phase.raise_objection(this); #100ns; //phase.drop_objection(this); endtask
-
Hi, As per my understanding, connect_phase does not start until all build_phase do not complete. How is this mechanism controlled? I did not find anything in uvm reference manual about this. Please let me know if there is any. Thanks. -
T or F: Objections should not be used in the uvm phases which are functions (i.e. build_phase, connect_phase, check_phase, ...). If True, why? -
In our testbench , we have added a new schedule pcie_main_schedule which runs in parallel with uvm_main_phase. This schedule consists of four phase lets say phase_a , phase_b , phase_c and phase_d. So the flow looks as shown below: pre_reset_phase | | <Other run time phase > | | Main_phase | phase_a | | | | | phase_b | | | | | phase_c | | | | | phase_d | / | / | / | / | / | / | / | / | / |/ Post_main_phase When we enter into phase_b , we issue a phase jump to uvm_pre_reset_phase. In this case I see that phase_b is killed and control goes to uvm_pre_reset_phase. But uvm_main_phase keeps on running in parallel.So simulation has both uvm_pre_reset_phase and uvm_main_phase running in parallel which is not expected. As per UVM user guide , if the jump to phase is outside of current schedule then the jump affects other schedules which share this phase. As the jump is happening from phase_b ( part of pcie_main_schedule) to uvm_pre_reset_phase( part of m_uvm_schedule) , uvm_main_phase should also have jumped . But this does not happen. -
In our testbench , we have added a new schedule which runs in parallel with uvm_main_phase. This schedule consists of four phase lets say phase a , b , c and d. These phases are added into uvm domain(m_uvm_domain) itself. So the flow looks as shown below: pre_reset_phase | | <Other run time phase > | | Main_phase | phase_a | | | | | phase_b | | | | | phase_c | | | | | phase_d | / | / | / | / | / | / | / | / | / |/ Post_main_phase I want to issue a phase jump from phase_b to pre_reset_phase. So I use uvm_domain::jump. With this, I see that pre_reset_phase is entering twice while it should have entered only once. Phase_b and uvm_main_phase share the same domain i.e m_uvm_domain. Even though there are two active phases in this domain , when a jump is requested jump should happen once. But currently it seems it happens for all the active phases. So we see pre_reset_phase entering twice. Is this expected behavior?
-
Hello, I was wondering if anyone had any ideas on why my test is hanging at the end of the run phase and how to resolve it correctly. The last of the output is listed below. The testbench has a series of agents, each including a monitor, producer driver, consumer driver, and scoreboard. At the end of the run phase when the test is hanging I'm able to step through code and see it's executing in a forever loop in the monitor and consumer driver. In both of these I'm never raising any objection. Tracing through the UVM code it seems it's waiting for all threads to exit before moving on. Some questions: Why should it wait for threads to exit if they never raised any objection? Do I need to kill these threads? What is the best practice? thanks! UVM_INFO uvm_objection.svh(1245) @ 31166250: reporter [TEST_DONE] All end-of-test objections have been dropped. Calling stop tasks UVM_INFO uvm_objection.svh(1268) @ 31166250: reporter [TEST_DONE] 'run' phase is ready to proceed to the 'extract' phase UVM_INFO uvm_phase.svh(1199) @ 31166250: reporter [PH/TRC/EXE/ALLDROP] Phase 'common.run' (id=255) PHASE EXIT ALL_DROPPED
