RE: [sv-ec] Ambiguous naming convention for fixed sized bins and automatically created bins with in covergroups.

From: Scott, David <david_scott_at_.....>
Date: Thu Jan 22 2009 - 14:39:27 PST
Saurabh,

It's not ambiguous, though it is arguably inconsistent.  However, it is
an intentional and approved inconsistency.

The reason it's inconsistent is because the language allows constructs
like this:

bins b[2] = { 1, 1 };

Since this truly declares two bins, each needs a distinct name.  The
simplest way to provide a distinct name, for this as well as much more
complex cases, is index-based naming, rather than based upon the values
on the right-hand-side.

Dave


-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Saurabh Sharma
Sent: Wednesday, January 21, 2009 12:32 AM
To: SV_EC List
Subject: [sv-ec] Ambiguous naming convention for fixed sized bins and
automatically created bins with in covergroups.

Hi All,

I have a query regarding naming conventions for fixed sized bins and
automatically created bins with in covergroups.

As per section "19.11.3 Type coverage computation" of draft8 of system
variable::

For state bins declared as "binname[n]", bin names range "binname[0]" 
through "binname[ n-1]"
and
For automatically created bins, bin names are of the form "auto[value]" 
or "auto[low:high]"

SizedBins distribution is according to size specified with them.
AutoBins get distributed according to auto_bin_max option.

Why are we following index based naming for fixed sized bins and value
or value range based naming for auto bins.

Shouldn't we follow the same consistent naming convention for both.

Please provide with your comments.

Thanks
Saurabh Sharma
saurabhs@cadence.com

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


-- 
This email was Anti Virus checked by Astaro Security Gateway.
http://www.astaro.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jan 22 14:41:32 2009

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2009 - 14:42:21 PST