Subject: Re: [sv-ac] check: How will we do this?
From: Prakash Narain (prakash@realintent.com)
Date: Mon Feb 10 2003 - 09:41:44 PST
Cindy,
I was posing the question in the context of the proposal that we get rid
of check.
I was pointing that a hole will be created.
Best Regards,
Prakash
Cindy Eisner wrote:
>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 : Mon Feb 10 2003 - 09:42:51 PST