I have a monitor component extended from uvm_monitor.
I’ve used UVM_INFO’s to show that my monitor’s build and connect phases are completing.
However, the run_phase of this monitor never executes.
I’ve proven this with a UVM_INFO in the monitor’s run_phase before even checking the vif for pin wiggles to broadcast.
I’ve verified that my test is raising an objection and dropping it much later after the stimulus is complete.
What are a few things to check which might explain why a component’s run_phase would never execute?
Thank You.
In reply to cturner:
The run_phase of each uvm_component will be started automatically when starting your test. If you are following the basic guidelines this will happen. It is hard to answer your question without seeing some code.
In reply to chr_sue:
Yes, its my experience, like you say, that this run_phase should be started automatically.
I believe we are following the basic guidelines.
I have an additional data point.
This problem is presented when I have deeply nested environments.
This monitor, lets say, is in an agent which is in a sub env B.
env B is declared and created within a higher level sub env A.
Finally, env A is declared and created in env Bench.
In this configuration, the monitor’s build_phase and connect_phase execute, but not its run_phase.
If I take env B out of env A and put it directly in env Bench, then the monitor’s run_phase starts automatically, as expected.
Here are additional details.
env B runs fine standalone in a “unit” test bench verifying a small block within our design.
env A (with sub env B) also runs fine in another standalone bench verifying a larger block of our design.
env Bench is almost an SOC level bench which runs fine without an env A.
This behavior was noticed when I added env A to env Bench to use the monitors and scoreboards we’ve developed in our env B and env A.
I hope that is clear. Thank You for taking the time to read this!
In reply to cturner:
Here is another data point and my hypothesis.
Env A contains commercial AXI and AHB VIP sub environments.
I’d better not say whose it is, but it not a problem with Questa.
The commercial AXI and AHB VIP uses the UVM run-time phases.
My homegrown VIP (env B) just uses the simple run_phase().
Perhaps there is some interactions having two parallel sub environment where one uses the run-time phases and one wisely does not(mine).
As reported earlier, I got expected behavior when I removed env B from env A (the one using the run-time phases). When I took env B out of env A and put it directly in env Bench, this left all the run-time phases stuff only in env A. Both env Bench and env B just use run_phase.
In reply to cturner:
Well if commercial VIP, may be someway the override uvm_monitor or they may user some system macros which have affect on run_phase.
I would suggest just grep uvm_monitor and see if it is not redefined.
Than grep run_phase and see if all is right with that.
And the last item check commercial system task macros and system tasks.
In reply to haykp:
It is not a good idea to use a mixture of run_phase and the run-sub-phases approach. An isea I have in this situation is to rename the run_phase with main_phase.
The run_phase starts with the pre_reset_phase. Are your sub_phases working correctly?
In reply to chr_sue:
I think the sub_phases are working because the AXI VIP (which uses them) is working.
I tried the experiment of renaming my_monitor::run_phase to my_monitor::main_phase.
I was excited about the possibility that it would support our theory of problems when one mixes the run_phase the run sub_phases. Unfortunately, I got the problematic behavior of my monitor::main_phase not executing.
My “solution” to this problem is to avoid it. I’ve moved my home-grown VIP out of the environment which utilizes the commercial VIP (which uses the run sub_phases).
In this configuration of environments, my VIP runs as one would expect.
Because of this empirical data, I wonder if there are rules about UVM phase propagation within nested environments vs parallel, non-nested, environments? Maybe such a rule applies to any nested/non-nested component and nothing is unique to environments? Perhaps this behavior is simulator specific? I can think of many questions and experiments which one could run. Instead, I’m going to keep my UVM benches as simple as possible and not mix the UVM run sub_phases with the run_phase.
In reply to cturner:
Without seeing, what you are doing in all the sub_phases it is impossible to give you an advice. You have to look for an adotion which takes your special implementation into accout. Finally there is no common solution.