RE: [sv-ec] semantics of wildcard bins

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Thu May 11 2006 - 10:44:42 PDT
Ray,

The parenthetical comment in the LRM that mentions the ==? operator is
incorrect. In version 3.1a, that comment read "(similar to the =?=
operator)". That operator was not asymmetrical, hence, the comment only
intended to draw a parallel between the two syntactical forms, that is,
an X, Z, or ? would act as a wildcard. It was not intended to specify
the semantics of the operator. Later, when P1800 changed the symmetrical
=?= operator into its asymmetrical form ==?, that section was simply
changed.

Not incrementing bin counts upon matching an X or Z value is something
that was explicitly requested by users. From a coverage perspective,
those are typically unimportant or error conditions that users do not
wish to include in coverage. As Shalom pointed out, the LRM is very
specific about matching only 0 and 1 values, not X or Z. If we modify
the wildcard semantics, we will render this coverage feature largely
useless. If this is creating any confusion, I would much rather remove
the parenthetical comment. It was only there in the first place because
wildcard equality was new to Verilog.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Ryan, Ray
Sent: Wednesday, May 10, 2006 12:42 PM
To: Bresticker, Shalom; sv-ec@eda.org
Subject: RE: [sv-ec] semantics of wildcard bins

Hi Shalom,

 
For #2 the sample exclusion is different from the semantics of '==?'.  

The '==?' operator is asymmetric. The '?', 'x' or 'z' values 
are wildcards in the right operand. An 'x' in the right operand 
matches any value in the left operand (including 'x' or 'z'). 
An 'x' in the left operand only matches a wildcard ('x' 'z' or '?') 
in the right operand.

When applied to the context of bin matching, the bin value 
correspond to the right operand (wildcards recognized) and 
the sample value is the left operand. If the sample value 
contains an 'x', and the corresponding bit of the bin value 
is '?' (as in my example) application of 'sample ==? bin_value' 
would yield TRUE - indicating a match and presumably the bin
should be incremented.

However, the LRM text seems to state that if the SAMPLED value 
contains an 'x' or 'z' value, the sample value is excluded - 
and thus the bin would NOT be incremented.

I would expect the behavior to be that of the '==?' operator and 
the bin should be incremented. That is, a wildcard matches any 
value not just 1 or 0.

Ray

> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
> Sent: Wednesday, May 10, 2006 4:15 AM
> To: Ryan, Ray; sv-ec@server.eda.org
> Subject: RE: [sv-ec] semantics of wildcard bins
> 
> Hi, Ray.
> 
> As a user reading this section for the first time, here are 
> the interpretations I would come to as answers to your questions:
> 
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> On
> > Behalf Of Ryan, Ray
> > Sent: Wednesday, May 10, 2006 3:49 AM
> > To: sv-ec@server.eda.org
> > Subject: [sv-ec] semantics of wildcard bins
> > 
> > The last last paragraph of the section on wildcard bins (18.4.3)
> states:
> > 
> > "A wildcard bin definition only considers 2-state values; sampled
> values
> > containing X or Z are excluded. Thus, the range of values 
> covered by a 
> > wildcard bin is established by replacing every wildcard 
> digit by 0 to 
> > compute the low bound and 1 to compute the high bound."
> > 
> > 
> > 1) The statement about the range of values is not right or is
> confusing.
> > 
> >    For example:
> > 	wildcard bins bx = { 4'b?0?0 };
> >    This does not cover the values in the range 0000 to 1010. It
> doesn't
> > cover 0001.
> > 
> 
> [Shalom] Agree.
> 
> 
> > 2) What does it mean that sampled values containing X or Z are
> excluded.
> > 
> >    For example:
> > 	wildcard bins bx = { 4'b?0?0 };
> >    I would expect that if the sample value is:
> >         0000	- increment the bin count
> >         1000      - increment the bin count
> >         0001      - don't increment
> >         000X 	- don't increment
> >         0010      - increment
> >         00X0      - increment
> >         00Z0      - increment
> >     However, the text seems to indicate that the last two sample
> values
> > are excluded and
> >     so don't increment the bin count.
> > 
> 
> [Shalom] Yes, they are excluded. The text explicitly says 
> that the ? is a wildcard for 0 and 1 and that it works like ==?.
> 
> 
> > 3) How many bins are created for
> >     	wildcard bins bx[] = { 4'b?0?0, 4'b?000, 4'b00?0 }
> >    I would expect that 3 bins are created.
> > 
> 
> [Shalom] Agree.
> 
> 
> > 4) How are wildcard ignore_bins handled?
> >     For example:
> > 	bins BA[2] = { 2'b00, 2'b1x };
> >       bins BB[2] = { 2'b10, 2'b0x };
> > 	wildcard bins BC = { 2'b0?, 2'b11 }
> >       wildcard ignore_bins ivals = { 2'b00, 2'b?0, 2'b0? };
> >       ignore_bins vals = { 2'b01, 2'b00, 2'b0x, 2'b0z };
> > 
> >     The ignore value 2'b00 will be removed from the first BA bin
> causing
> > the
> >     bin to be ignored.
> >     Will the ignore value 2'b?0 remove the 2'b10 value from BB ?
> 
> [Shalom] Yes.
> 
> 
> >     Will the list of values in the last ignore_bins remove the
> wildcard
> >     value 2'b0 from BC ?
> 
> [Shalom] Yes.
> 
> Two more editorial quibbles:
> 
> The first example in this section is called g12_16 and 
> increments "when the sampled value is between 12 and 16". 
> Actually the range is only 12-15.
> 
> Also, the first and third paragraphs in this section refer to 
> "wildcard bins", with both in Courier font. As a reader, I 
> would be in doubt whether or not this implies that 'wildcard' 
> may only be used with 'bins'
> and not with 'ignore_bins' and 'illegal_bins' (going back to 
> the rule that the BNF does not contain all the information 
> and the text supplements it). The simplest correction would 
> be to de-Courierize "bins' in those two places.
> 
> Shalom
>  
> 
Received on Thu May 11 10:44:43 2006

This archive was generated by hypermail 2.1.8 : Thu May 11 2006 - 10:44:54 PDT