Re: [sv-bc] 4-state or 2-state expression types

As Shalom says, this is highly relevant to the 1067 cleanup.

My instinct was to assume that out-of-bounds reads of 2-state packed arrays
should yield '0 rather than 'x, because it seems to me that any subscript-select
of a 2-state variable is itself inherently a 2-state expression. If this email
thread hadn't happened, I would simply have put that into a proposal.

On the other hand, it would make quite a lot of sense to say that the expression
is in fact 4-state, so that 'x can be returned by out-of-range accesses. In the
common case where that result is copied straight into a 2-state target, the
difference would be invisible. But it could of course make a difference if the
subscript-select were an operand in some other expression, or (as Gord
indicated) if its type() were to be taken. The only sane outcome, I think, would
be to say that any operand having a packed subscript of any kind is of 4-state
type, regardless of the 2/4-state type of the base expression. I'm not at all
sure I like that; it has weird consequences for type equivalence.

The two simulators I can try right now disagree about this. Doing an
out-of-range select on a 2-state vector, one yields 4-state 1'bx, the other
2-state 1'b0. So we can make the right decision with a clear conscience. It's
just a case of finding the right decision :-)

Jonathan Bromley

----- Original Message ----
> From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> To: Steven Sharp <sharp@cadence.com>; Gordon Vreugdenhil <gordonv@model.com>;
>sv-bc <sv-bc@eda.org>
> Sent: Wed, 23 March, 2011 10:49:51
> Subject: RE: [sv-bc] 4-state or 2-state expression types
>
> I have always understood like Steven.
>
> Notes:
>
> 7.4.6 says, "If an index expression is out of the address bounds or if any bit
>in the address is X or Z, then the index shall be invalid. The result of
>reading from an array with an invalid index shall return the default
>uninitialized
> value for the array element type."
>
> This makes no distinction between packed and unpacked arrays, or between
>"single" selects (e.g., bit-select) and "multiple" selects (e.g., part-select).
>
> However, 11.5.1 and 11.5.2 are older text, going back to 1364. Clearing them
>up is the subject of Mantis 1067, which Jonathan is working on.
>
> 11.5.1 currently says, "If the bitselect is out of the address bounds or the
>bit-select is x or z, then the value returned by the reference shall be x," and
>
> "A part-select that addresses a range of bits that are completely out of the
>address bounds of the vector, packed array, packed structure, parameter or
>concatenation, or a part-select that is x or z shall yield the value x when
>read and shall have no effect on the data stored when written. Part-selects
>that are partially out of range shall, when read, return x for the bits that
>are out of range and shall, when written, only affect the bits that are in
>range."
>
> and 11.5.2 says,
>
> "As with bit-selects, the address bounds given in the declaration of the
>memory determine the effect of the address expression. If the index is out of
>the address bounds or if any bit in the address is x or z, then the value of
>the reference shall be x."
>
> This clearly conflicts with 7.4.6.
>
> Shalom
>
>
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> > Steven Sharp
> > Sent: Tuesday, March 22, 2011 11:13 PM
> > To: Gordon Vreugdenhil; sv-bc
> > Subject: RE: [sv-bc] 4-state or 2-state expression types
> >
> > My intent for the wording in 11.3.4 was that if you applied an
> > operator, all operands were converted to 4-state and the result was 4-
> > state (though implementations would be free to optimize by doing 2-
> > state operations if all operands were 2-state and the operator could
> > not produce a 4-state result).
> >
> > So the type of v1 would be 4-state. It would be 4-state even if it
> > were type(a+1), which cannot produce x or z.
> >
> > But the part selects are not officially operators.
> >
> > For a bit-select of a 2-state vector, I believe an out-of-range result
> > is specified to be "the default uninitialized value" for an element of
> > the vector. That would be 0 rather than X.
> >
> > I guess I had assumed that part-selects worked the same way, producing
> > 0 for out-of-range bits of a 2-state vector. But perhaps they were not
> > generalized in the same way that bit-selects were, and still explicitly
> > refer to X.
> >
> >
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> > Gordon Vreugdenhil
> > Sent: Tuesday, March 22, 2011 4:29 PM
> > To: sv-bc
> > Subject: [sv-bc] 4-state or 2-state expression types
> >
> >
> > SV has defined the ability to take the "type" of an expression without
> > evaluating the expression. In some circumstances, there is
> > insufficient description in the LRM about exactly what constitutes the
> > type of an expression versus the values induced by the expression.
> > 11.3.4 has the following wording:
> >
> > Operators may be applied to 2-state values or to a mixture of 2-
> > state and
> > 4-state values. The result is the same as if all values were
> > treated as 4-state
> > values. In most cases, if all operands are 2-state, the result is
> > in the 2-state
> > value set.
> >
> > This doesn't really say that the *type* of the expression becomes 4-
> > state just that the result is in the 4-state value set.
> >
> > So, consider the following:
> > bit [7:0] a;
> > int i;
> >
> > type (a/0) v1;
> > type (a[7:6]) v2;
> > type (a[10:7]) v3;
> > type (a[i+:4]) v4;
> >
> > What is the type of each variable? Does the "partially out of range"
> > result of v3 impact the type (i.e. is it 4-state due to the "x" bits)?
> > If v3 is 4-state, what about v4? Is it 4-state due to the
> > *possibility* of an out-of-bounds select (remember that the expression
> > is not evaluated)?
> >
> > I'm not sure that I'd want to say that *every* select induces a 4-state
> > type, but if we don't, then we have issues with indexed selects, etc.
> >
> > The question is not academic as the user expectations of induced 2-
> > state types interact with the behavior of conditionals, etc.
> >
> > Gord.
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> --
> 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.