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.