RE: [sv-ec] Re: [sv-ac] Access of covergroup items across covergroups

From: Scott, David <david_scott_at_.....>
Date: Mon Jun 15 2009 - 10:38:20 PDT
Assignments are allowed in procedural code outside the covergroup.  I
believe these examples in 19.7 on page 494 of ballot draft 8 were
intended to show procedural assignments:

	g1.option.comment = "Here is a comment set for the instance g1";
	g1.a.option.weight = 3; // Set weight for coverpoint "a" of
instance g1

The syntax within the covergroup declaration itself, however, is limited
to option and type_option assignments of the covergroup being declared;
see Syntax 19-1, the "coverage_option" production.

-- David Scott


-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of John Havlicek
Sent: Monday, June 15, 2009 5:50 AM
To: rsaha@cal.interrasystems.com
Cc: sv-ec@server.eda.org
Subject: [sv-ec] Re: [sv-ac] Access of covergroup items across
covergroups

Hi Rashmi:

Your questions should be sent to SV-EC, whom I've copied.

My opinion as a user (not on evidence from the LRM) is that it
could be useful to be able to override options from outside a 
covergroup using hierarchical references like the ones you show.

However, doing so from inside another covergroup declaration is
counterintuitive to me.

The LRM today may provide no capability for overriding the options
from outside a covergroup declaration.

J.H.

> X-eda.org-MailScanner-Watermark:
1245655453.65746@tii0XDsSxFPVS9DHsMx9TQ
> X-Authentication-Warning: server.eda.org: majordom set sender to
owner-sv-ac@eda.org using -f
> X-eda.org-MailScanner-Watermark:
1245655344.85606@VBFwkVsm2Q1+wShhGe2enw
> Date: Mon, 15 Jun 2009 12:49:41 +0530
> From: Rashmi Saha <rsaha@cal.interrasystems.com>
> X-Accept-Language: en-us, en
> X-InterraSystems-MailScanner-Information: Please contact the ISP for
more information
> X-InterraSystems-MailScanner-ID: n5F7K32j009749
> X-InterraSystems-MailScanner: Found to be clean
> X-InterraSystems-MailScanner-SpamCheck: not spam, SpamAssassin (not
cached,
> 	score=-2.498, required 6, BAYES_00 -2.60, HTML_MESSAGE 0.00,
> 	RDNS_NONE 0.10)
> X-InterraSystems-MailScanner-From: rsaha@cal.interrasystems.com
> X-Spam-Status: No, No, No
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more
information
> X-MailScanner-ID: n5F7NdfI005847
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> X-Brightmail-Tracker: AAAAAQAAAAI=
> X-Brightmail-Tracker: AAAAAQAAAAI=
> X-Whitelist: TRUE
> X-Whitelist: TRUE
> X-OriginalArrivalTime: 15 Jun 2009 07:34:19.0045 (UTC)
FILETIME=[B1782D50:01C9ED8B]
> 
> This is a multi-part message in MIME format.
> --------------070504080107060700050303
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Hi,
> 
> I have a query regarding visibility of covergroup items across
different 
> covergroups.
> Is one covergroup item accessible from a different covergroup?
> Are there any specific restrictions for any specific member of a
covergroup?
> 
> E.g.
> covergroup gc(int maxA, int maxB) @(posedge clk);
>     a : coverpoint a_var { option.auto_bin_max = maxA; }
>     b : coverpoint b_var { option.auto_bin_max = maxB; }
> endgroup
> 
> gc g1 = new (10,20);
> 
> covergroup gc2(int maxA, int maxB) @(posedge clk);
>     c : coverpoint a_var {
>         g1.a.option.auto_bin_max = 6;  // allowed?
>     }
>     g1.option.per_instance = 1;        // allowed?
>     gc::option.detect_overlap = 1;    // allowed?
> endgroup
> 
> LRM does not clearly state the access rules of covergroup items via 
> another covergroup.
> Most of the simulators do not allow this kind of access.
> 
> Please let me know your comments on this.
> 
> -- 
> Thanks & Regards,
> Rashmi Saha
> 
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> --------------070504080107060700050303
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
>   <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Hi,<br>
> <br>
> I have a query regarding visibility of covergroup items across
> different covergroups.<br>
> Is one covergroup item accessible from a different covergroup?<br>
> Are there any specific restrictions for any specific member of a
> covergroup?<br>
> <br>
> <font color="#3333ff">E.g.<br>
> covergroup gc(int maxA, int maxB) @(posedge clk);<br>
> &nbsp;&nbsp;&nbsp; a : coverpoint a_var { option.auto_bin_max = maxA;
}<br>
> &nbsp;&nbsp;&nbsp; b : coverpoint b_var { option.auto_bin_max = maxB;
}<br>
> endgroup<br>
> <br>
> gc g1 = new (10,20);<br>
> <br>
> covergroup gc2(int maxA, int maxB) @(posedge clk);<br>
> &nbsp;&nbsp;&nbsp; c : </font><font color="#3333ff">coverpoint a_var {
</font><br>
> <font color="#3333ff">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
g1.a.option.auto_bin_max = 6;&nbsp; // allowed?<br>
> &nbsp;&nbsp;&nbsp; }<br>
> &nbsp;&nbsp;&nbsp; g1.option.per_instance =
1;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font
color="#3333ff">//
> allowed?</font><br>
> <font color="#3333ff">&nbsp;&nbsp;&nbsp; gc::option.detect_overlap =
1;&nbsp;&nbsp;&nbsp; </font><font
>  color="#3333ff">// allowed?</font><br>
> <font color="#3333ff">endgroup</font><br>
> <br>
> LRM does not clearly state the access rules of covergroup items via
> another covergroup.<br>
> Most of the simulators do not allow this kind of access.<br>
> <br>
> Please let me know your comments on this.<br>
> <pre class="moz-signature" cols="72">-- 
> Thanks &amp; Regards,
> Rashmi Saha
> </pre>
> </body>
> <br />-- 
> <br />This message has been scanned for viruses and
> <br />dangerous content by
> MailScanner, and is
> <br />believed to be clean.
> </html>
> 
> --------------070504080107060700050303--

-- 
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.
Received on Mon Jun 15 10:40:15 2009

This archive was generated by hypermail 2.1.8 : Mon Jun 15 2009 - 10:40:25 PDT