[sv-bc] "default initial value"

Sorry for beating this to death, but the phrase "default uninitialized
value" appears twice, in 5.3 and in 8.18.

Is this intended to be the same as "default initial value"?

Thanks,
Shalom


>-----Original Message-----
>From: Rich, Dave [mailto:Dave_Rich@mentor.com]
>Sent: Sunday, November 06, 2005 10:36 AM
>To: Bresticker, Shalom; Steven Sharp; sv-bc@eda.org
>Subject: RE: [sv-bc] 4.10.4 "Enumerated types in numerical
>expressions" - unclearness
>
>Shalom,
>
>I agree with you that this needs to be explicit defined and is
>not that
>difficult to do so. Variables have initial state, and require a
>definition for their default initial value. Nets have an un-
>driven state
>when they are unconnected or driven with high impedance. The
>only
>situation where the default initial state and un-driven state
>for a
>given type would be different is when the type is 4-state.
>
>The question is: what's the best way to clearly define this?
>Can it be
>fully described in a single table? Or do need a description for
>each
>type?
>
>Dave
>
>
>> -----Original Message-----
>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of
>> Bresticker, Shalom
>> Sent: Saturday, November 05, 2005 10:53 PM
>> To: Steven Sharp; sv-bc@eda.org
>> Subject: RE: [sv-bc] 4.10.4 "Enumerated types in numerical
>expressions" -
>> unclearness
>>
>> Hi,
>>
>> See below.
>>
>> >In SystemVerilog, there are too many types to make this
>> >approach practical.
>> >What was needed was a concise generic term for the value to
>be
>> >used in these
>> >situations.  Since the most obvious place where this value
>is
>> >used is the
>> >default initial value of a variable, the term "default
>initial
>> >value" came
>> >into use.  And as the standard was clarified and new
>situations
>> >needing an
>> >"undefined" value were identified, they were generally
>defined
>> >to use this
>> >"default initial value".
>>
>>
>> [Shalom: ] The phrase "default initial value" is actually
>only used in
>a
>> small number of places:
>>
>> - Here in 4.10.4.3 and 4.10.4.4, regarding enumeration next()
>and prev
>> ()
>> - In 4.11, p. 30, with respect to a variable of an unpacked
>union type
>> - In 5.6.1, with respect to dynamic arrays
>> - In 5.9.6, with respect to non-existent members of
>associative arrays
>> - In 5.13, in a similar context
>> - In 5.14.1, in a similar context with respect to queues
>> - In Table 6-1 with respect to variables
>> - In 19.12.1, with respect to variables
>>
>> Thus the phrase used in 4.10.4.3 and 4.10.4.4 as it currently
>stands
>is
>> at best not well defined. The "default initial value" of an
>> "enumeration" is not well defined. What is defined is the
>"default
>> initial value" of an enumeration variable, which is not the
>same
>thing.
>>
>>
>> >When some of the new data types were allowed on nets, this
>> >phrase became
>> >less accurate.  It really should have become "default
>initial
>> >value for
>> >a variable of this type", but that is no longer concise and
>may
>> >even be
>> >more confusing.  Perhaps these places should have been
>changed
>> >to say
>> >"the value from Table 6-1".
>>
>> [Shalom: ] I am not sure that in the case of enumerations,
>"the value
>> from Table 6-1" would be unambiguous. For enumerations, Table
>6-1
>says,
>> "base type default initial value". But that brings us back to
>the
>> original question, as "default initial value" is defined for
>variables,
>> not for types.
>>
>> You might have to say something like "default initial value
>for a
>> variable of the base type".
>>
>> Since Table 6-1 does not apply to nets, it might be wise to
>avoid
>saying
>> "default initial value" of a type, but rather "of a variable
>of this
>> type", as you said, even though you have some reservations
>about it.
>>
>> Thanks,
>> Shalom
>>