[sv-ec] Wildcard Bin Expansion - clarification needed

From: Vaibhav Bhutani <vbhutani@cadence.com>
Date: Thu Dec 09 2010 - 04:18:17 PST

Hi Shalom and All Coverage Experts,

This is a query regarding the Mantis discussion http://www.eda.org/svdb/view.php?id=1474 on wildcard bins.
Here it is concluded that wildcard vector bins should not expand the wildcard expressions to create separate bins for each expanded value.
Only the wildcard values should be used with bin-names. Hence in the following example,
wildcard bins b1[] = {4'bx110, 4'1x00};
the two bins will be named as b1[4'bx110] and b1[4'1x00].

But in the LRM there is no example/clarification on this for wildcard vector bins. I have quoted following excerpt from LRM,
which, I believe, can make user interpret that the expanded 2-state values of the wildcard vector bins should be used as bin names.
Hence for the above example, there will be four bins which are b1[4'0110], b1[1110], b1[1000], b1[1100].

LRM-2009 19.5.3, Pg 502
"A wildcard bin definition only considers 2-state values; sampled values containing X or Z are excluded"

The above statement clarifies that the sampled value should not have X or Z .
In this case, there is no point in keeping the wildcard bin definition unexpanded because the sampled value is a 2-state value (0 or 1) and not "don't care value".
Hence showing the exact 2-state value with bin name of vector bins makes sense because user knows which exact value matched. The only intention to provide wildcard entries in case
of wildcard bins is to match the wildcards with 0 or 1.

Now, for non-wildcard vector bins, for which === operator is used, it makes more sense to show the wildcard value as bin name. For example,
for "bins b1[] = {4'bx110, 4'1x00};", we can show 2 bins like b1[4'bx110], b1[4'1x00].

Please let us know your comments.

Vaibhav Bhutani | SMTS, Incisive Comprehensive Coverage, Functional Verification | Cadence

P: 91.120.3984000 M: 91.9899811123 F: 91.120.3984203 www.cadence.com<http://www.cadence.com>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Dec 9 04:22:25 2010

This archive was generated by hypermail 2.1.8 : Thu Dec 09 2010 - 04:22:50 PST