Issue with wildcard definition

Hi,

I have a 48 bit variable. I am interested in values where different bits are set.
To handle that I have put bins as:

wildcard bins bitx = {
48’b???1,
48’b???1?,
48’b???1??,
48’b???1???,
48’b???1???,
48’b???1???,

With such a code, ncvlog exits with an error
The wildcard bin definition creates more than 2**20 non-contiguous values.

I believe the number of combinations that are associated with a bin are too many. Is there a way to work around?

Regards,

Hi,

First, I’m not sure this value bin set will do what you want. You are combining your wildcard specs into a single value set. When multiple entries are in a value set, it is like an “or”. That means that the bin counter will increment when any of the values are sampled. With your wildcard values, that essentially means that any sampled value will increment the bin no matter what the value is.

I think you are getting the error because you have an empty set of brackets after your bin name. In this case, SystemVerilog tries to create one bin for each possible value in the set, and you have 2^48 possible values!

You can probably get rid of the error by putting a value like 48 inside the brackets, thus limiting the number of bins created, but I still don’t think that will do what you want (see first paragraph above).

I think you should separate these wildcard specs into different bins, and do not use the brackets on the bin names.

Hope this helps,
-Kurt

Hi,
First, I’m not sure this value bin set will do what you want. You are combining your wildcard specs into a single value set. When multiple entries are in a value set, it is like an “or”. That means that the bin counter will increment when any of the values are sampled. With your wildcard values, that essentially means that any sampled value will increment the bin no matter what the value is.
I think you are getting the error because you have an empty set of brackets after your bin name. In this case, SystemVerilog tries to create one bin for each possible value in the set, and you have 2^48 possible values!
You can probably get rid of the error by putting a value like 48 inside the brackets, thus limiting the number of bins created, but I still don’t think that will do what you want (see first paragraph above).
I think you should separate these wildcard specs into different bins, and do not use the brackets on the bin names.
Hope this helps,
-Kurt

Thanks, Kurt.

In case the intention of putting the bins is not apparent, let me explain through an example …

wildcard bins x = {
3’b??1,
3’b?1?,
3’b1??
}

The first bin increments for a value of 001, but will not increment any other bins.
A value of 111 increments all the bins and so on

I can confirm that the issue is not due to x I have put in my code.
Because I have a statement like:
wildcard bins a = {48’b???..1}

Even this bails out with the same error.

A help on the error message gives:

ncvlog/EHTBCG =
We currently do not support wildcard bins that result in
creation of 220 or more of non-contiguous values. Modify the
wildcard bin definition such that the number of non-contiguous
values is fewer than 2
20 and rerun the compilation.

Regards

wildcard bins x = {
3’b??1,
3’b?1?,
3’b1??
}
The first bin increments for a value of 001, but will not increment any other bins.
A value of 111 increments all the bins and so on

Yes, but the bin specification 3’b??1 actually creates FOUR bins:
3’b001
3’b011
3’b101
3’b111

I imagine that you really want…

wildcard bins x_bit0 = {3’b??1};
wildcard bins x_bit1 = {3’b?1?};
wildcard bins x_bit2 = {3’b1??};

so that you get one bin for each different one-hot value.

Of course, this will be horrible to code if you have 48 bits.

Consider embedding the covergroup in a class. Provide the
class with a sample() method that maps your 48-bit one-hot
value on to the integer range -1 to 47, where 0:47 is each
one-hot bit and -1 is “some other illegal value”. Cover not
the original 48-bit vector, but this integer - now you can
easily create 48 valid bins and one illegal_bins.

A nice example of why it is rarely a good idea to cover
raw data without first massaging it into a meaningful form.

Jonathan Bromley
Doulos

Yes, but the bin specification 3’b??1 actually creates FOUR bins:
3’b001
3’b011
3’b101
3’b111
I imagine that you really want…
wildcard bins x_bit0 = {3’b??1};
wildcard bins x_bit1 = {3’b?1?};
wildcard bins x_bit2 = {3’b1??};
so that you get one bin for each different one-hot value.
Of course, this will be horrible to code if you have 48 bits.
Consider embedding the covergroup in a class. Provide the
class with a sample() method that maps your 48-bit one-hot
value on to the integer range -1 to 47, where 0:47 is each
one-hot bit and -1 is “some other illegal value”. Cover not
the original 48-bit vector, but this integer - now you can
easily create 48 valid bins and one illegal_bins.
A nice example of why it is rarely a good idea to cover
raw data without first massaging it into a meaningful form.
Jonathan Bromley
Doulos

Thanks Kurt and Jonathan. I got a fair idea of what needs to be done.

Regards