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

I would be Ok with defining a part-select in two state to be
zero rather than x. In general though, for both indexing and
part selects, I'm not sure that I like the 0 from 2-state selects
since it leaves the user with no ability (in an expression) to
reasonably determine that the result is impacted by a bad
value.

I do want to return to Steven's comments as well.

Steven's intent in 11.3.4 was, as he said, that operands are
all treated as 4-state. While I understand that in the
*evaluation domain* we might want to define things in
that manner so that x values propagate, I'm not convinced
that this is the best answer for the *type* of the expression.
In particular, for a pair of 2-state operands, I think that
users (any me too!) would find it surprising that
     type(a+b)
would yield a 4-state type. Coupling this with the part/indexed
select discussion, it would be very difficult to have anything
other than a simple identifier yield a 2-state type in the
"type" operator. I really don't like that state of affairs.

My preference (I think) is to think about the "final type" of the
expression and the induced value set separately. The type
of "a+b" for 2-state operands should be 2-state. Not doing
so will be very surprising to end users. I don't think that
necessarily conflicts with saying that all expression evaluation
happens in the four-state domain; it merely states that the
"self-determined type" is the natural 2-state projection from
the evaluation domain.

This may be pretty awkward to word/explain in the LRM, but
I think the resulting behavior would be much less surprising.

Gord.

On 3/23/2011 5:50 AM, Bresticker, Shalom wrote:
> 11.5.1 says,
>
> "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."
>
> Shalom
>
>
>> -----Original Message-----
>> From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
>> Sent: Wednesday, March 23, 2011 2:48 PM
>> To: Bresticker, Shalom; Steven Sharp; Gordon Vreugdenhil; sv-bc
>> Subject: Re: [sv-bc] 4-state or 2-state expression types
>>
>> It seems, then, that we can make the problem go away - and completely
>> answer
>> Gord's question that started this thread - by specifying that the
>> result of an
>> out-of-range access on a 2-state packed object is a 2-state '0. That's
>> compatible with the de facto behaviour of three major tools, with the
>> exception
>> of one rather obscure corner case (the tool that treats statically-
>> known
>> out-of-range accesses differently). It would be a straightforward
>> update of the
>> text in 11.5.
>>
>> Any strong objections?
>>
>> One final wrinkle: Suppose I do an invalid part-select that overlaps
>> the valid
>> range. Should the entire result be '0/'x, as the LRM suggests? Or
>> should the
>> bits that are within range be given their "correct" value, as if they
>> had been
>> picked one-by-one using a 'for' loop? Example:
>>
>> logic [7:0] B = 'h55;
>> logic [7:0] Slice = B[11:4]; // Should Slice be 8'hx5 or 8'hxx?
>>
>> Thanks
>>
>> Jonathan
>>
>>
>>
>> ----- Original Message ----
>>> From: "Bresticker, Shalom"<shalom.bresticker@intel.com>
>>> To: Jonathan Bromley<jonathanbromley@ymail.com>; Steven Sharp
>>> <sharp@cadence.com>; Gordon Vreugdenhil<gordonv@model.com>; sv-bc
>>> <sv-bc@eda.org>
>>> Sent: Wed, 23 March, 2011 12:19:56
>>> Subject: RE: [sv-bc] 4-state or 2-state expression types
>>>
>>> Also, Table 7-1, which specifies values to be returned from a non-
>> existent
>>> array entry, already specifies that reading a non-existent 2-state
>> element
>>> returns '0. More generally, a value is always returned that is in the
>> value set
>>> of the corresponding data type. I find it questionable that 2-state
>> integral
>>> types should be exceptions.
>>>
>>> Shalom
>>>
>>>> -----Original Message-----
>>>> From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
>>>> Sent: Wednesday, March 23, 2011 1:46 PM
>>>> To: Bresticker, Shalom; Steven Sharp; Gordon Vreugdenhil; sv-bc
>>>> Subject: Re: [sv-bc] 4-state or 2-state expression types
>>>>
>>>> I spoke a little too soon...
>>>>
>>>>
>>>>
>>>>> 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.
>>>> The third big-name simulator also yields a 2-state result.
>>>>
>>>> In fact the simulator that yielded 4-state 1'bx did so only when
>> the
>>>> subscript
>>>> was statically known to be out of bounds (and it gave me an
>>>> elaboration-time
>>>> warning for that too). An out-of-bounds subscript computed at
>> runtime
>>>> gave
>>>> 2-state 1'b0, just like the other simulator. I don't know whether
>> that
>>>> should
>>>> affect BC's thinking...
>>>>
>>>> Jonathan Bromley
>
> ---------------------------------------------------------------------
> 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.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.