Re: [sv-ac] idea of multi matches for cover

From: John Havlicek <john.havlicek_at_.....>
Date: Wed Nov 21 2007 - 05:34:54 PST
Hi All:

Please see Mantis 1768.  For cover property, we no longer count 
all matches.  Only cover sequence counts all matches.

In addition to tool dependent mechanisms suggested by Dmitry,
there are also standard mechanisms for controlling the number of
coverage hits.  E.g., if only one hit is desired per simulation, 
then the pass action of the cover property can call $assertoff for
that cover property.

J.H.

> X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-ac@eda.org using -f
> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.21,445,1188802800"; 
>    d="scan'208";a="323651167"
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Wed, 21 Nov 2007 10:06:07 +0200
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] idea of multi matches for cover
> Thread-Index: Acgroyrugqa3AwUCSEO7kCcCFD4rmgAbr52wAACeisA=
> From: "Korchemny, Dmitry" <dmitry.korchemny@intel.com>
> Cc: <sv-ac@eda-stds.org>
> X-OriginalArrivalTime: 21 Nov 2007 08:06:15.0581 (UTC) FILETIME=[63875CD0:01C82C15]
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> X-eda.org-MailScanner-SpamScore: s
> X-Spam-Status: No, No
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id lAL86fv6019098
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more information
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> 
> Hi Daniel,
> 
> According to the LRM both assert and cover statement will be checked for
> each evaluation attempt. I am not sure the LRM should prescribe the way
> to limit the number of reports by some predefined constant, it might be
> just a tool option. There is always a vague boundary between what should
> be standardized and what shouldn't.
> 
> Regards,
> Dmitry
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
> Behalf Of danielm
> Sent: Wednesday, November 21, 2007 9:46 AM
> To: Neil.Korpusik@sun.com
> Cc: sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] idea of multi matches for cover
> 
> I think that here we hit some kind of misunderstanding.
> I mean stmt like:
> 	cover property(a ##[1:$] b); 
> 
> For single a occurence above have to be checked and raported till EOS,
> while
> 
> 	assert property (a ##[1:$] b);
> Will not be checked and raported after first occuerence of a ##N b
> 
> So for cover we may get huge output, and simulation slowdown much bigger
> than for assertion.
> 
> I just want to have the way to switch raports for "extra" passes of
> assertion.
> 
> DANiel
> 
> -----Original Message-----
> From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] 
> Sent: Tuesday, November 20, 2007 7:29 PM
> To: danielm
> Cc: sv-ac@eda-stds.org
> Subject: Re: [sv-ac] idea of multi matches for cover
> 
> Hi Daniel,
> 
> I suggest that you review 18.3, which describes the strobe option for
> covergroups. Conceptually this is similar to what you are suggesting.
> 
> Neil
> 
> 
> 
> danielm wrote On 11/20/07 04:13 AM,:
> > LRM wants that cover in contrast to assert and assume should react on 
> > all matches of sequence. This aproach may have big impact on 
> > simulation performance - in some case properties used in cover wil 
> > have to be tracked from start point till end of simulation. Maybe 
> > there should be way to turn off such extra passes - similarly to 
> > switching off vacuous passes (see mantis  0001361) Such possibility to
> 
> > turn on off extra passes should be added to covers but also to assert 
> > and assume.
> >  
> > 
> > LRM about cover directive> In addition, statement_or_null gets 
> > executed for every match. If there are multiple matches at the same 
> > time, the statement gets executed multiple times, one for each match.
> > 
> >  
> > 
> > DANiel
> > 
> > 
> > --
> > This message has been scanned for viruses and dangerous content by 
> > *MailScanner* <http://www.mailscanner.info/>, and is believed to be 
> > clean.
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Nov 21 05:35:45 2007

This archive was generated by hypermail 2.1.8 : Wed Nov 21 2007 - 05:35:57 PST