From what I’ve understood so far, uvm_components have each phase so that all objects are able to go to the next phase when all the same phase of every uvm_component objects are finished.
If so, all uvm_component should finish its own run_phase to go to the next phase. All uvm_components eventually complete all run_phase. Then why do we need to have phase.raise_objection & phase.drop_objection?
Can you help me where I misunderstand…?
The build phases and cleanup phases are implemented as functions, so they are all expected to complete in 0 time.
The run phases will consume time, so the UVM scheduler will fork these tasks in parallel. After forking the tasks, the UVM scheduler uses the objection mechanism to determine what tasks are still actively generating stimulus. When the stimulus tasks are finished and drop their objections, it will then kill all the remaining tasks that were forked. This mechanism allows drivers/monitors to execute in forever loops since they have no knowledge of when to finish.
Thank you for reply.
I am still confused and I have two questions.
If no ones raise phase.raise_objection explicitly, test may finish right after starting run_phase?
From what I understood, All the same phase state should be completed to go to the next phase state. In run_phase state, some components which could not complete run_phase because of no raise_objection can go to the next phase state?
For example, there are two objects which are uvm_components.
In run_phase, test should not be finished until comp1 do drop_objection. After comp1 drop_objection, can comp1 go to check_phase, even if comp2 could not finish comp2 run_phase?
If so, it’s conflicted with my thought that all the uvm components always do the same phase at the same time and should complete the previous phase to go to the next phase. It’s conflicted with my thought because only uvm_component with raise/drop_objection seem to be able to finish. And only those which have finished can go to the next phase such as check_phase, and report_phase.
Please correct me.
The UVM scheduler will start the same phase of each component at the same time.
For a time consuming phase, the scheduler will wait for all objections to be dropped. When all objections are dropped, any additional tasks which are still running will be killed. In the case where no component raises an objection, the phase will immediately be terminated and the next phase will start. This can result in tests immediately finishing in 0 time.
In your example, the run_phase in comp1 and comp2 are forked. Since comp1 raises an objection, the scheduler will wait for the objection to be dropped. When this happens, since there are no outstanding objections, the run_phase of comp2 will be killed. The scheduler will then proceed to the next phase.
A component can’t start a phase on its own. The execution of phases is controlled by the scheduler.
uvm_component divided into three phases
1. Build phases
2. Run phases
3. Clean-up phases
Build phases and run phases start simulation at 0 time unit and then clean up phases start.
Build phases and clean up phases are function and run-phases will time consuming…
Let build start at 0 time and end also,
run_phase start at 0 time unit but it take some time to complete lets take (alpha)
clean-up phase start (alpha time) once run phases over, and then execute all the function like extract, check, report and final…
All these process start when we invoke run_test() or unm_root…