Re: [sv-ac] Conditions over sequences


Subject: Re: [sv-ac] Conditions over sequences
From: Stephen Meier (Stephen.Meier@synopsys.com)
Date: Fri Dec 06 2002 - 17:22:25 PST


Hi Joseph:

Yes I think you are missing the intent of the restrictions on sequences.

These operations (istrue, occurs) are to put additional restrictions on
behaviors which must occur in addition to the sequence occuring. It is a
way of creating a more complex sequence.

As an example for occurs

         occurs sequence1 within sequence2

When asserted, then not only does sequence2 need to hold but the sequence1
must hold somewhere within the time window of sequence2.

I think the requirement that you are striving for is to use properties as
assumptions.

This can be achieve by having a tool directive to assume a property.

asssert @(posedge clk1) if ( sequence1) sequence2;

If this property was asssumed then then the verification tool would
constraint things such that if sequence1 did occur then it would need to
generate sequence2. Whenever sequence1 does not occur then sequence2 is
ignored.

I hope this clarifies and corrects the topic.
Steve
----------
At 11:31 AM 12/6/2002 -0800, Joseph Lu wrote:

>Hi,
>
>The DWG Rev0.75 documents states that constraints can be specified as
>conditions over
>sequences. The semantics states that the condition must hold true while
>processing a transaction. Further, it explains that if the condition
>becomes false while the sequence is being evaluated, the sequence does
>not match and a property stated over this sequence would declare a failure
>as shown in the 11.7.7 example.
>
>My question is if we are using constrains to filter out some
>unexpected/uninterested
>inputs combinations to DUT, why should we check if the sequence
>matches when the constraints are not met? If the constraints are
>not met, we are not interested in the sequence specified.
>Making the property stated over this sequence to declare a
>failure when the constraints are not met seems a little bit
>counter-intuitive to me. Even more so for formal verification,
>we use constraints to trim/scope down the interested design space.
>Am i missing something?
>
>Thanks,
>
>
>
>--Joseph
>
>--------------------------------------------------
>Joseph Lu
>Processor Product Group
>Sun Microsystems
>M/S USUN 03-202, 430 N. Mary Ave.,
>Sunnyvale, CA 94086
>408-616-5887
>joseph@eng.sun.com
>--------------------------------------------------

Steve Meier (stephen.meier@synopsys.com) W: 650-584-4476, Cell: 408-393-8246



This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 17:23:13 PST