Hi SVA Experts,
I have a requirement where there are 2 signals sig1 and sig2.
Whenever sig1 rises followed by some latency sig2 rises. (Latency should be calculated/displayed b/w sig2 and sig1)
In the above assertion as the signals are checked for @() it fails for the fall of the signal as there the duration of latency is different. I need only to check when there is a rise of signals and not the falls.
Are any clues/changes expected in the above assertion?
Thanks Ben, the assertion above has worked for most of the cases, except a further addition to one more condition on sig2 for a specific case.
In a specific case the sig2 is toggling for the 2nd time after few ns so the assertion checks for the 2nd toggle of sig2 as well and fails.
How to ensure it only checks for the first posedge toggle of sig2 and not to the 2nd posedge toggle which occurs after few ns.
Required Check
sig1 → sig2
To Ignore 2nd toggle
sig1 → sig2 → sig2 (2nd sig2 toggle to be ignored)
The assertion of this property says that at every posedge sig1 then at posedge sig2 in the SAME or another time step the time comparison is made.
This assertion meets your requirements:
sig1 → sig2
and sig1 → sig2 → sig2 (2nd sig2 toggle to be ignored)
That 2nd sig2 is not considered because the 1st sig2 concludes the attempt for the sig1.
Show me the code where you made that claim because I do not believe it.
Sorry!
Hi Ben,
After some more analysis found that the latency between sig2-sig1 was appearing in real value (115.563ns) and not an Integer Value (may be that’s the reason it was causing a failure for another few cycles), so have accordingly changed the checks to a range.
The above, then works fine for my requirement.
Let know if real value delays have to be handled in a different way.
Another query that I have is how do we know what clock the above assertion is working on? Is it directly understood that the clocks on which sig1 and sig2 are synchronous to, is the clock in which the assertion is getting triggered.
In reply to verif4ravi:
Assertions don’t rely on clocks, but on lead cloking events.
Also an assertion needs ONE leading clocking event to start the attempt.
Example:
event e1;
bit clk. a, b, c, d;
// lead clock
assert property(@(posedge clk) a |-> @(negedge b) d ...); // multiclock
assert property(@( clk) a |-> ...); // every transition of clk
assert property(@(c) a |-> ...);
assert property(@(e1) a |-> ...);
How does the $display display the latency values when there is a failure, I am only seeing values in log during the passing of assertion. In the failure case it did not show in log what value was the latency.
How does the $display display the latency values when there is a failure, I am only seeing values in log during the passing of assertion. In the failure case it did not show in log what value was the latency.
The assertion local variables are not carried into the action block.
You’ll have to use some support logic; something like the following where
the property sets the latency into a module/checker variable and the action block flips a bit to display the latency error.
// untested, but I think it is syntatically accurate
bit freq_error;
reatime latency;
function automatic void set_latency(realtime t);
latency=t;
endfunction
always (@(posedge freq_error)) begin
$display("%t latency error=", $realtime, latency);
#1 freq_error=0;
end
property p_min_time();
realtime start_time;
@(posedge sig1) (1,start_time = $realtime) |->
@(posedge sig2) (($realtime - start_time) == duration, set_latency($realtime - start_time),
$display("\t **Latency_checker**= %d ",$realtime - start_time));
endproperty
assert property (p_min_time)
else begin
freq_error=1;
`uvm_error ("p_min_time,$sformat("%m FAIL p_min_time"));
end ;