For the 2 cases ( +define+M1 N +define+M2 ) I observe different O/P across Simulators ::
(a) For +define+M1 ::
On Simulator1 I Observe :: **TIME : 49 STRICTLY1ACK FAIL**
While others give No O/P due to Incomplete assertion ( same as my expectation )
My question is the expression within the ’ not ’ Operator is Never True . So the consequent is Never :: not( 1 )
So how come the assertion FAILS ??
The consequent seems to act as an implicit ’ strong ’ operator
(b) For +define+M2 ::
On Simulator1 I Observe :: **TIME : 45 STRICTLY1ACK FAIL**
While on Simulator2 I Observe ::
**TIME : 45 STRICTLY1ACK FAIL
TIME : 45 STRICTLY1ACK PASS**
My expectation is that the assertion would PASS at TIME:45 since consequent would be :: not( 0 )
(a) When you negate a property, you switch its strength. (16.12.3 Negation property). Since the consequent is now strong, an incomplete property fails. To get the behavior you expected, write it as
(b) There are two assertion attempts, one starting at time 5, and the other starting at time 45. There is no strength involved in the first attempt, all tools agree it should fail. But since the second attempt begins on the last clock cycle and you are using non overlapping implication, the consequent never begins evaluations, so it is incomplete.
We normally recommend only using the overlapping implication to avoid confusion and writ the property as
You see that the tool that printed the passing message for the cover directive does not print a passing message for the assert directive. That is a contradiction and incorrect behavior.
@( posedge clk ) rose( req ) |=> not( !ack[*1:] ##1 $rose( req ) ) ;
does NOT check ’ ack ’ is received after ’ req ’ is asserted
Your assertion says: If(rose(req) then no new ack until a new req.
Generally, I tend to avoid the “not” operator unless I have to. It can be hard to understand if the property is complex, like having an implication operator.
LRM 16.12.3 Negation property :: " The not operator switches the strength of a property "
On updating the stimulus for an addition clock tick for +define+M2 gives Failure for the same reason as +define+M1 .
Although I understand that we don’t discuss tool issues , personally I find it quite amusing that one of the Top Tools falls so short when it comes to assertions ( Even the licensed ones ) .
Apart from this ( not ) peculiar case I have observed that ’ strong ’ , ’ reject_on ’ , ’ s_until_with ’ isn’t supported .
(1) " does NOT check ’ ack ’ is received after ’ req ’ is asserted "
However if ' ack ' is received before next ' req ' the assertion passes
Have updated the [EDA_LINK](https://www.edaplayground.com/x/8Scu) with 3rd case for +define+M3
(2) " If( rose(req) then no new ack until a new req. "
However the assertion would Fails in such case which isn’t the Ideal case but such cases need to be shown as error