In reply to Adarsh24:
Use an immediate deferred assertion
always_comb if(a) am_1: assert final(b);
always_comb if(a) am_2: assert #0 (b);
From 1800: Note that if code in the Reactive region modifies signals and causes another pass to the Active region to
occur, this still may create glitching behavior in observed deferred assertions, as the new passage in the
Active region may re-execute some of the deferred assertions with different reported results. In general,
observed deferred assertions prevent glitches due to order of procedural execution, but do not prevent
glitches caused by execution loops between regions that the assignments from the Reactive region may
cause.
In the Postponed region of each simulation time step, each pending final deferred assertion report that has
not been flushed from its queue shall mature. Then the associated subroutine call (or $error, if the assertion
fails and no action block is present) is scheduled in the same Postponed region, and the pending assertion
report is cleared from the appropriate process’s deferred assertion report queue. Due to their execution in the
non-iterative Postponed region, final deferred assertions are not vulnerable to the potential glitch behavior
previously described for observed deferred assertions