What is required to get set_drain_time() to make the objection mechanism object ovm_test_done wait for another raise after it’s last objection is dropped?
I’m setting set_drain_time from the run() task of my ovm_test and it doesn’t seem to be having any effect on the operation of the objection system. I’m raising a dropping objections in an object derived from ovm_monitor and as soon as the number of objections hits zero, the objection mechanism calls global_stop_request() and terminates the simulation. There should be another objection raised within the drain time I’ve specified, so it appears the objection mechanism isn’t paying attention to the drain time setting.
Here’s the call to set_drain_time(). I’m calling it passing ovm_top as the object, that’s the only part I’m not sure of.
task run();
ovm_test_done.set_drain_time(ovm_top, 32000);
endtask // run
I finally solved this. Turns out I had some hierarchy issues which I believe was causing this not to work. I’m calling it from my ovm_test and it’s working fine according to the timestamps on displayed messages.
I’m actually now calling it referencing this instead of ovm_top.
One final update to this for the benefit of anyone trying this in the future.
It seems that if you call raise_objection() and then drop_objection() without any time passing in between, it’s possible that the objection mechanism will “miss” the objection and the drain time will not be reset. In order to avoid this, I had to put one tick of time between the raise and drop calls. (Functionally for me this was not a problem, hopefully it won’t be for you.)
ovm_test_done.raise_objection(this);
... (do things) ...
#1 ovm_test_done.drop_objection(this);
As far as I’ve dug into it, it seems that this is caused by some sort of race condition in the way the drain time handling routine forks. The re-raise passes by before it actually gets recognized and so the global_stop_request() proceeds as though no re-raise had occurred.