Hi
How we can report an error if a particular assertion doesn’t hit even one time throughout simulation?
Hi
How we can report an error if a particular assertion doesn’t hit even one time throughout simulation?
In reply to Naga:
Use the strong qualifier. At the end of the simulation you will see the report of the assertion failing. Thus:
ap_ab: assert properly(@(posedge clk)
a |-> strong( ##[1;$] b));
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr
In reply to ben@SystemVerilog.us:
Thanks for your response Ben
If my left side one/antecedent itself doesn’t gets trigger then It won’t work right?
If ‘a’ is ‘0’ throughout simulation in your example, then I want to report with an error indicates Assertion has not triggered.
In reply to Naga:
Create in your TB an endofsim signal triggered a few cycles
before the $stop or $finish
bit endofsim;
bit a_occur;
always @(posedge clk)
if(a) a_occur=1;
assert property(@ (posedge clk)
endofsim |-> strong(a_occur));
Ben systemverilog.us
In reply to ben@SystemVerilog.us:
I would create an additional assertion that says a must occur.
assert property(@(posedge clk) s_eventually a)
ap_ab: assert property(@(posedge clk)
a |-> strong( ##[1;$] b));
I’m assuming that these two properties could be combined into one, but I’m guessing this shows the requirements more clearly.
In reply to dave_59:
Thanks Dave, forgot about the s_eventually.
That is a better s/ cleaner olution.
Ben systemverilog.us
Can’t we use the followed operator instead of the overlapping operator ? #-#, #=#would fail if antecedent or precedent never fired in a run .
In reply to pkumar16:
Can’t we use the followed operator instead of the overlapping operator ? #-#, #=#would fail if antecedent or precedent never fired in a run .
The followed-by operator is a oroperty that contains a sequence followed by a property.
I don’t see how you would use this work here.
Dave_59 solution is the best using 2 assertions. There is nothing wrong in writing multiple small assertions; in fact, it is better to write multiple small assertions, with each one accomplishing a specific goal that trying to cram everything into one.
Engineers (me too) have this tendency of always searching for the “optimum” solution at all costs.
Let’s get practical!
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr