[uvm_event] wait_trigger could not be cancelled by disable fork. why?

[SeanChou]

Hi,

After several hours' debug, I realized the truth that uvm_event.wait_trigger could not be cancelled by disabling fork. Could any one let me know the reason why?

uvm_event a0, a1;

a0 = uvm_event_pool::get_global("a0");

a1 = uvm_event_pool::get_global("a1");

fork: fork_name

a0.wait_trigger();

a1.wait_trigger();

begin

#100

a1.trigger();

end

join_any

disable fork_name;

// a0 is still waiting here

if ( a0.get_num_waiters() != 0 )

`uvm_fatal(...)

[SeanChou]

After second thought, I think it is not safe theoretically to kill other thread, since we are not sure if it aquires locks at this moment. so it would be much better to send an event to ask the thread commits suicide.

[jadec]

disable fork_name will disable the fork statement, that is, it will stop waiting on its children (but in this case the fork has already ended). If you want to kill the children, you need to use "disable fork" instead. Be careful as both of these can have unexpected consequences. I tend to agree that having the thread end itself is easier to understand and debug.

[SeanChou]

Thanks Jadec, however, uvm_event a0 is still waiting after replacing the original "disable fork_name" with "disable fork" as you mentioned in both irun and vcs.

[uwes]

hi,

what do you mean with "still waiting". the wait_trigger() task should be aborted BUT without cleanup. this probably looks like as if there are still num_waiters waiting. if you do use "disable fork" to break the wait_trigger() you probably have to call cancel() to indicate that you removed one waiter.

/uwe

[SeanChou]

uwes,

Yes, you are right. it should be actually killed without cleaning up the num_waiters.