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

David,
 
If the "rise" bin is not incremented in the "not per-instance"
covergroup, how would you describe the coverage such that you could
detect one packet with foo=1 followed a packet with foo=0?  That is a
useful thing to measure.
 
Mark

________________________________

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of David Scott
Sent: Friday, August 08, 2008 5:56 PM
To: jonathan.bromley@doulos.com
Cc: sv-ec@server.eda.org
Subject: Re: [sv-ec] Transition coverage and covergroup instances


Jonathan,

I may be too close to our implementation, and maybe too close to the
covergroup chapter having studied it for a few years now, but the
question never occurred to me.  And I still don't find anything
ambiguous now that you mention it.

The option.per_instance has been recently clarified as a cue for the
requirement of saving an instance in the coverage database.  To my way
of thinking, the use of multiple instances of a given covergroup has an
implication only for the aggregation of coverage: multiple instances
will be aggregated into the "overall coverage information for the
covergroup type" (LRM's words).  I don't think there is an implication
that covergroup instances interact in any way except with regard to this
"overall coverage", which is some kind of aggregation.  The 2009 LRM did
add type_option.merge_instances to allow a couple of different ways to
aggregate instances into the covergroup type.

Your question seems to imply that covergroup instances might interact
with each other in how bins are incremented.  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.



	It may be that the answer to this is so blindingly 
	obvious to coverage experts that it isn't worth saying,
	but it would be nice if the LRM were explicit about it.
	Or have I missed something?


I'm not sure.  The answer was blindingly obvious to me, but sometimes
clarifications don't hurt.  We can see what others have to say ...

Cheers,

David Scott



jonathan.bromley@doulos.com wrote: 

	hi EC,
	
	I know it's too late to change anything now, but this question
arose
	in discussion here recently and I can't find clarification of it
in any
	version of the LRM so it might be worth asking.
	
	How are transition coverpoints incremented when multiple
	instances of a covergroup exist?  It seems reasonable to
	assume that, if the covergroup's per_instance option is true,
	each CG instance detects transitions as seen by just that
	one instance alone.  But what happens when the CG's
	per-instance option is false? 
	
	For example:
	
	module User;
	
	  class Data;
	    bit b;
	    covergroup cg;
	      coverpoint b { bins rise =  (0 => 1); }
	    endgroup
	    function new(bit B);
	      b = B;
	      cg = new;
	    endfunction
	  endclass
	
	  initial begin
	      Data d;
	      d = new(0);
	      d.cg.sample();
	      d = new(1);
	      d.cg.sample();
	  end
	
	endmodule 
	
	At the end of this code we have created one instance of
	the covergroup that sampled b==0, and then a second 
	instance that sampled b==1.  Given that it is not a per-instance
	covergroup, did we increment the "rise" bin?
	
	It may be that the answer to this is so blindingly 
	obvious to coverage experts that it isn't worth saying,
	but it would be nice if the LRM were explicit about it.
	Or have I missed something?
	
	Thanks
	  



-- 
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.