Subject: Re: [sv-ac] check: How will we do this?
From: Cindy Eisner (EISNER@il.ibm.com)
Date: Sun Feb 09 2003 - 07:03:48 PST
prakash,
the example you gave is for "check", which is an immediate assertion,
whereas the proposed scheduling was intended for concurrent assertions
only, as i understand it. does this resolve the issue? if so, perhaps all
that is needed is a clarification in the document.
regards,
cindy.
Cindy Eisner
Formal Methods Group Tel: +972-4-8296-266
IBM Haifa Research Laboratory Fax: +972-4-8296-114
Haifa 31905, Israel e-mail:
eisner@il.ibm.com
Prakash Narain <prakash@realintent.com>@eda.org on 07/02/2003 00:01:31
Sent by: owner-sv-ac@eda.org
To: sv-ac@eda.org
cc:
Subject: [sv-ac] check: How will we do this?
Let us look at the following code snippet:
always @(posedge clk)
.
.
.
case(sig1)
.
junk1:
.
if (sig2) begin
.
.
.
if (sig3) begin
check(foo) ;
//desired behavior if (!foo) $display("assertion failed")
;
.
.
end
end
endcase
Basically what I am trying to say procedurally is that when
the clk rises and ((sig1==junk1)&&(sig2 is true)&&(sig3 is true)) then
foo should be true.
In the proposed scheduling, the evaluation of an assertion is just before
the next rising clock. foo needs to be checked relative to (just before/
right after) the current rising clock.
Does this makes sense?
Best Regards,
Prakash
This archive was generated by hypermail 2b28 : Sun Feb 09 2003 - 07:01:06 PST