the following code illustrates an issue I’m facing with umm_event usage,
I have 3 parallels processes as labeled in each fork process 1)triggering, 2) waiting and 3) resetting,
when running the code only the first message is seen on console (“ev triggered”) the message of the
second process (“after wait_trigger”) never appeared,
as a conclusion when uvm_event is reset all wait_trigger of the event will be disabled even if the event is triggered afterwards.
could anybody explain this strange behavior (from my point of view)? is there any idea how to re-activate the wait_trigger after the reset?
thanks,
fork
begin: triggering
@a;
ev.trigger();
`uvm_info("FORK","ev triggered", UVM_MEDIUM);
end
begin: waiting
ev.wait_trigger();
`uvm_info("FORK","after wait_trigger", UVM_MEDIUM);
end
begin: resetting
#20;
ev.reset();
#10;
//to trigger the event
a = 1;
end
join_none
In reply to Mohamed_TN:
I think you should stay away from using events unless you have a very good understanding of how event driven simulation works. I’m looking at the source code for uvm_event_base and see a number problems.
One problem is the UVM reference fails to define the behavior of ev.reset() when its wakeup argument is not set. The default wakeup is not set, and looking at the code, it appears that any process suspended waiting on wait_trigger or wait_ptrigger never wakes up. Given that reset sets the number of waiters back to 0, that seems to be the intended behavior and should be documented.
Another problem is when the wakeup argument is set, reset() triggers the event, but then immediately replaces the event handle with a new event. That could create a race condition if the process waiting on the trigger is in a loop. The waiting process may or may not see the new event.
And finally I see a number of #0’s elsewhere the uvm_event code. Procedural #0’s in your code do not fix race conditions, they just move them to another delta cycle.