Re: [sv-ec] Transition coverage and covergroup instances

From: <jonathan.bromley_at_.....>
Date: Sat Aug 09 2008 - 01:18:24 PDT
David,

Many thanks for your quick, complete and kindly reply.

> Your question seems to imply that covergroup instances might 
> interact with each other in how bins are incremented. 

No - it implied that I was clueless about that :-)

> The bin 
> increment -- not least because sample() is an instance method -- is 
> entirely local to the covergroup instance.  Whether there is a bin 
> associated with the type is really just an artifact of aggregation: 
> with type_option.merge_instances==1, the type can indeed appear to 
> have a bin; with type_option.merge_instances==0, the type probably 
> does not (although I suppose a tool could do report one if it chose.)
> 
> Anyway, to answer your last two questions directly, from my perspective:

>> Given that it is not a per-instance
>> covergroup, did we increment the "rise" bin?
> 
> No.

Had I looked more carefully at the Mantis 1897 verbiage 
on merge_instances, it would have been obvious even to me:
the correct mental model is that each CG instance has its own
set of bins (and, therefore, its own transition history) and
these bins then get aggregated in various ways depending on
how the options are used.  It was precisely Mark Strickland's
point about inter-transaction transitions that motivated 
my question; the solution is straightforward, as you say.

Thanks again.
-- 
Jonathan Bromley
Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
UK
Tel: +44 (0)1425 471223                   Email: 
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: 
http://www.doulos.com

This message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat Aug 9 01:19:25 2008

This archive was generated by hypermail 2.1.8 : Sat Aug 09 2008 - 01:20:32 PDT