Just to complement this discussion. I fully agree with Scott's write-up. The per_instance option is intended only as a request to persist the coverage information of each covergroup object in the database. As Scott wrote, there is no implication that covergroup instances interact in any way except for aggregation - or perhaps by sampling the same data. I'm sorry Jonathan, but the answer did seem obvious to me as well. Perhaps you can point out what part of the LRM may have mislead you. Arturo From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of David Scott Sent: Friday, August 08, 2008 5:21 PM To: Mark Strickland (mastrick) Cc: jonathan.bromley@doulos.com; sv-ec@eda.org Subject: Re: [sv-ec] Transition coverage and covergroup instances Jonathan's question was whether you could sample foo==0 in one covergroup instance followed by foo==1 in a different covergroup instance and expect the bin to increment. Since sampling is per-instance, I say not. The solution to your problem is sample the values in the same covergroup instance. To use Jonathan's example, if there were a way to make the covergroup cg static within class Data, that would be an elegant way to do it. However, SystemVerilog doesn't offer a syntax for that, so the best bet is to create another class with embedded covergroup, where a variable of that class is declared static in class Data. Then the value "B" gets assigned (and sampled and the transition covered) within the static class variable. If you needed both -- sometimes covering transitions within a given packet, sometimes covering transitions between packets -- then obviously you'd have to maintain sampled variables and covergroups for both intra-packet and inter-packet transitions. David Mark Strickland (mastrick) wrote: 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 <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.Received on Sat Aug 9 20:48:48 2008
This archive was generated by hypermail 2.1.8 : Sat Aug 09 2008 - 20:49:33 PDT