Hi Dave,
I was revisiting this thread in relation to a task based solution suggested by Ben in repeat-or-for-loop-in-assertion
I tried an alternate solution where I call the task on match of a sequence.
As per LRM the task executes in Reactive region
In the latter 2 cases +define+M2 & +define+M3 I expect assertion to fail
due to sequence expression :: ( ($realtime - v ) >= 20ns ) returning false
(1) For +define+M2, at T:114ns ‘b’ toggles for 5th time as well as ‘a’ is asserted
(Q1) Since $rose(a) has an explicit clock attached to it,
shouldn’t wait( $rose(a,@(posedge clk) ) unblock at the posedge of clk at T:115ns ?
i.e I expected task to complete at T:115ns
// My expected output
...................
T:114 @(b) occurred // Increments cntr to 5
T:115 $rose(a) is True
T:115 Task completes
cntr is 5 // As $rose(a)[->1] in property matches at T:115
(2) For +define+M3 ::
At T:115ns :: ‘b’ toggles for 5th time , ‘a’ is asserted as well as posedge of clk occurs
$rose(a)[->1] within the property would match at the next posedge at T:125ns as the sampled value of ‘a’ at T:115ns is 0
However, as the task executes in reactive region I believe it’s able to detect the 0 to 1 transition and unblocks wait( $rose(a,@(posedge clk) ) ) at T:115ns
(Q2) At T:115ns does there exist a race condition b/w ::
unblocking of forever@(b) in T2 & unblocking of wait($rose(a,@(posedge clk))) in T1 ?
(Q3) At T:115ns would cntr be incremented to 5 before the disable fork executes ?
(Q4) Similar to this thread, should I be using @(evnt) / wait( evnt.triggered ) / uvm_wait_for_nba_region() to eliminate the (possible) race condition in (Q2) at T:115ns for +define+M3 ?