Re: [sv-dc] 4-state vs 3-D

To look at it slightly differently: if the user wants to encode their X/Z net states as NaN, how will they do that?

You could do the X/Z stuff by having the real-value resolution function return a composite type that includes bits to indicate that the value is uncertain or the net is undriven, and have the receiver conversion do the translation to NaN - the local type being a simple real value, the net/resolved type being the one you use for the X/Z tests.

And/or you could let users annotate types with which values in the type represent X or Z, e.g. something like:

  typedef real real3d (z => NaN,x => NaN); // gives NaN as initial and undriven value

Users probably need to be able to test for NaN and set things to be NaN anyway, so I'd say just push it into user space.

Kev.

On 12/08/2010 01:20 PM, Arturo Salz wrote:
> I think discussing a particular encoding is not a good solution. If the capability to represent X and Z for real numbers is built into the language then the particular encoding becomes an implementation detail. Note that for the digital domain, the encoding of X/Z used by the simulation kernel is not visible to users (even when some API's make it seem so).
>
> What you seem not be discussing here is an encoding that can be adopted by convention, and, as long as the same value can be deposited on the floating-point variable by some other mean then there is ambiguity as to whether that particular value is indeed a Z, an X, or some other malformed number due to some other reason. This does bring up some real use issues, for example, how should a waveform tool display a floating-point variable that contains NaN: should it show NaN, Z, X.
>
> I contend that the X / Z should be handled internally by the implementation. Attempting to formalize the encoding using an existing floating-point value seems like a memory optimization to avoid storing the information elsewhere (say 2 more bits), which is probably not the best use of the committee. This something that the implementation can better address.
>
> Arturo
>
> -----Original Message-----
> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Achim Bauer
> Sent: Wednesday, December 08, 2010 12:42 PM
> To: Kevin Cameron
> Cc: sv-dc@eda.org
> Subject: Re: [sv-dc] 4-state vs 3-D
>
> Hi Kev,
>
> looks good, just my analog five cents:
>
> In the analog or real domain "x" or undefined might be interpreted as
> undriven (strength=0!) or floating. A floating or high-impedance
> (strength=0) node can not really maintain a stable signal, it is prone
> to any kind of (unknown) disturbances, the (voltage) value is kind of
> undefined. For real values z and x are kind of the same.
>
> So one might even code it in a 2-dimensional way:
>
> Value ( real: -inf -> +inf )
> Strength ( real: undriven/undefined = 0, driven = ]0:+inf) )
>
> Which would comply nicely with a sparse struct notation.
>
> Achim
>
>
> On Wed, 2010-12-08 at 09:13 -0800, Kevin Cameron wrote:
>> 4-state refers to the received values "0,1,Z,X", since 0,1 are the range of known good logic values (for a single bit), the same nomenclature doesn't really apply for real values (since there are a lot of valid discrete values).
>>
>> I'd prefer to call it "3-Dimensional", the dimensions being:
>>
>> Value (logic: 1,0, real: -inf -> +inf)
>> Strength (undriven = z, regardless of type)
>> Certainty (uncertain logic = x, uncertain real = NaN)
>>
>>
>> Comments?
>>
>> Kev.
>>
>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.