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