In my IP, which has many 3rd party IPs, such as: AXI/AHB master/slave agents. Different MIPI CSI/DSI controllers and etc.
I receive thousands of next prints in the test log:
UVM_INFO | 198288000 ps | TEST_DONE | ‘run’ phase is ready to proceed to the ‘extract’ phase
UVM_INFO | 198357000 ps | TEST_DONE | ‘run’ phase is ready to proceed to the ‘extract’ phase
UVM_INFO | 198422000 ps | TEST_DONE | ‘run’ phase is ready to proceed to the ‘extract’ phase
UVM_INFO | 198491000 ps | TEST_DONE | ‘run’ phase is ready to proceed to the ‘extract’ phase
UVM_INFO | 198555000 ps | TEST_DONE | ‘run’ phase is ready to proceed to the ‘extract’ phase
…
…
Source of the print is the UVM1.2 source code file: uvm_objection.svh, line: 1270 , task: all_dropped
Any hints why do I have so many of these prints, and what should be done in order to remove it?
(But not using demotion, or post-processing of the log)
These messages indicate that somewhere in your environment you are raising and dropping objections frequently, perhaps in a monitor, scoreboard, sequence, etc.
It is recommended to only raise and drop one objection at the test level.
You can use +UVM_OBJECTION_TRACE on the simulation command line to determine where these objections are being raised/dropped.
Debugged the test using: +UVM_OBJECTION_TRACE
And found the problem,
in the test-bench, we have 22 input channels, each channel is connected to AXI VIP agent (master/slave). Source of the objection raise/drop is the drivers of the master/slave agents.
But not all agents are really active in all tests since traffic is being read/written through random number of channels. However in the build_phase we build all agents with:
axi_sys_cfg[0].slave_cfg[0].is_active = 1;
axi_sys_cfg[0].master_cfg[0].is_active = 1;
This is why we have so many prints in test log of the message: ‘run’ phase is ready to proceed to the ‘extract’ phase
the source of it are agents who were built as “active” but no traffic runs through it during the test.
What would you advice to do?
It is not easy to change now, with how the Test-bench is written the is_active configuration of each master/slave.
Is the AXI VIP from a third party or written in house? My first recommendation would be to change the driver and remove any objection raise/drop. I would expect that a driver would only raise an objection after receiving a sequence_item from a sequencer (but even this is really bad), so I’m not sure why it would raise/drop objections even when no sequence_item is received.
If the AXI VIP is from a third party, I would contact them and express your displeasure at receiving all of these messages and ask how to fix it.
The AXI VIP is from a third party, so code is protected and cannot see how the driver is implemented.
And yes it sounds not likely it would raise/drop objections when no sequence_item is received, maybe wrong with my analysis.