Subject: RE: [sv-ac] Conditions over sequences
From: Bassam Tabbara (bassam@novas.com)
Date: Fri Dec 06 2002 - 15:25:11 PST
Hi Joe, I'll let DWG address your question directly, I would like to use
your comment as a jumping off point though if I may ...
I think of "istrue ... in seq_expr", is a way to -pre-empt- while evaluating
seq_expr. So it might make more sense in dynamic validation. Of course if
you are doing formal you can optimize this "pre-emption" in many ways... I
wouldn't necessarily think of this as a constraint, as you adequately point
out the latter is something used to trim/scope evaluations....
That said, if DWG is getting this input, I think what is evident in Joe's
email and my comment is the lack for an adequate "skip/ignore" mechanism, in
my opinion you need something on top of istrue or anything else. There has
been discussion on changing if... then with the implication semantics to
"=>". I would urge to do that, and then "add/keep" the if...then but with a
"skip" semantics, if bool fails do not mark as "failed match" or failed ....
as I said right now if is the only operators for doing precondition type
checks, hate for that to always do either success/fail (redundant/false)
alarms ... that's a lot of useless data.
May be I am answering Joe's question for a better way to "constraint" i.e.
trim checking .... or may be I did go on a tangent :-), this somehow seemed
implicit in Joe's comment (and been bugging me for a long while now :-)!).
-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com (408) 467-7893
> -----Original Message----- > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]On > Behalf Of Joseph Lu > Sent: Friday, December 06, 2002 11:32 AM > To: sv-ac@server.eda.org > Subject: [sv-ac] Conditions over sequences > > > > 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 > -------------------------------------------------- >
This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 15:27:34 PST