Subject: [sv-ac] The case for retaining check
From: Prakash Narain (prakash@realintent.com)
Date: Thu Feb 13 2003 - 13:45:22 PST
I want to challenge that we can't get rid of check without
leaving a permanent hole in the specification capability of
assertions. I am also challenging that a better scheduling
of procedural assertions can't be designed.
Let me elaborate on the issue I was trying to raise in the
meeting today. I want to say (A=>B in the current cycle). I
want to say this as the first element of the sequence in a
procedural assertion. I can't do that with the proposed
scheduling/evaluation semantics when the procedural block
is a sequential block. An example is given below.
always @(posedge clk)
case(sig1)
junk1:
if (sig2) begin
.
.
.
if (sig3) begin
check(foo) ;
//desired behavior if (!foo) $display("assertion failed");
//simulation solution if (!foo) $error("assertion
failed") ;
.
end
end
endcase
In our experience, such specification has been encountered numerous
times.
If we change the evaluation semantics such that the first element of a
sequence in a procedural assertion is evaluated right away, we can get
rid of this limitation. However, that can cause false firing of assertions
in combinational blocks. The way around that will be to employ the
methodology that procedural assertions in combinational blocks begin
with true. The user has to code that explicitly.
However, this will cause serious mismatch between cycle based and
event driven evaluation semantics. Cycle based semantics can't
schedule an intra-cycle evaluation.
If we get rid of check, we will leave a permanent hole. This is a
corner case situation.
Best Regards,
Prakash
This archive was generated by hypermail 2b28 : Thu Feb 13 2003 - 13:48:33 PST