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

Yes, of course you are right that user may write different codes which will
slow down simulation and tools should take care.

The problem was that language specific constructs action block is executed
few times for each attempt. So standard can not leave it tool dependent

I was proposing solution to cotnrol action block execution by some system
task to switch off extra passes of cover (solution similar to vacuous action
block control), but SV committee have approved cover property and cover
sequence  i think that this is solve my problem in some way.

Thanks all for responces.

DANiel

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
Sent: Wednesday, November 21, 2007 2:54 PM
To: danielm@aldec.com.pl
Cc: yaniv.fais@freescale.com; dmitry.korchemny@intel.com;
Neil.Korpusik@sun.com; sv-ac@eda-stds.org
Subject: Re: [sv-ac] idea of multi matches for cover

Hi Daniel:

There have been a number of discussions of the capability of collecting
all-match coverage for sequences, and my opinion is that this is a useful
capability.

The major detraction of the 2005 description of cover property was that an
ambiguous syntactic criterion was used for determining whether the coverage
would be counted on all matches per attempt or on at most one match per
attempt.

Mantis 1768 fixes this problem, and I think it is a move in the right
direction.

It is still possible for users to write code that slows down simulation in
wasteful ways.  The standard generally leaves it to methodology, linting
tools, etc. to guide users to more efficient and effective code rather than
trying to declare such usages as illegal.

J.H.

> X-Authentication-Warning: server.eda.org: majordom set sender to 
> owner-sv-ac@eda.org using -f
> From: "danielm" <danielm@aldec.com.pl>
> Cc: <sv-ac@eda-stds.org>
> Date: Wed, 21 Nov 2007 12:00:07 +0100
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
> Thread-Index: 
> Acgroyrugqa3AwUCSEO7kCcCFD4rmgAbr52wAACeisAABKnNoAABAMWQAACUydA=
> X-OriginalArrivalTime: 21 Nov 2007 11:00:07.0249 (UTC) 
> FILETIME=[AD499410:01C82C2D]
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> X-Spam-Status: No, No
> 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
> 
> So you may add "cover sequence" to list of deprecated contstruct at 
> once;) because it will slow down the simulation heavily for some kinds 
> of sequences
> 
> 
> 
> DANiel
> 
> -----Original Message-----
> From: Fais Yaniv [mailto:yaniv.fais@freescale.com]
> Sent: Wednesday, November 21, 2007 11:48 AM
> To: danielm; Korchemny, Dmitry; Neil.Korpusik@sun.com
> Cc: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] idea of multi matches for cover
> 
> 
> Hi,
> 
> it was poorly defined in the 2005 version but in the current version 
> of the LRM (2008 draft 4) it is defined properly such that for a cover 
> property only one match should count and cause an execution of the action
block.
> 
> 
>  16.14.3
> 
> "The difference between the two categories is that for sequence 
> coverage, all matches per evaluation attempt are reported, whereas for 
> property coverage the coverage count is incremented at most once per 
> evaluation Attempt"
> ....
> for cover property:
> "The pass statement specified in statement_or_null shall be executed 
> once for each successful evaluation attempt of the underlying
property_spec"
> 
> For cover sequence:
> ...
> "For a given attempt of the cover sequence statement, all matches of 
> the sequence_expr that complete without the occurrence of the disable 
> iff condition shall be counted, with multiplicity, toward the total 
> number of times matched for the attempt. No other match shall be 
> counted towards the total for the attempt.
> The pass statement specified in statement_or_null shall be executed, 
> with multiplicity, for each match that is counted toward the total for 
> the attempt."
> 
> 
> Yaniv
> 
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of 
> danielm
> Sent: Wednesday, November 21, 2007 12:19
> To: 'Korchemny, Dmitry'; Neil.Korpusik@sun.com
> Cc: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] idea of multi matches for cover
> 
> This is obvious that both assertion and cover should be checked for 
> each evaluation attempt, and lets say that  this is also ok.
> 
> That tool may limit reports.
> 
> The problem is action blocks. Standard has to define how it should work.
> IMHO currently standard defines that for cover each attempt (each 
> starting
> time) may have multiple covers (cover action block will be executed ) 
> while for assertion the same property for single attempt will have 
> single result (pass, fail, vacuous fail, disable) and action block will be
called once.
> 
> So the language is responsible for control action block behavior 
> (exactly like it was done for vacuous passes mantis  0001361)
> 
> 
> DANiel
> 
> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> Sent: Wednesday, November 21, 2007 9:06 AM
> To: danielm; Neil.Korpusik@sun.com
> Cc: sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] idea of multi matches for cover
> 
> 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.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.