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

I can think of three scenarios under which an X might be advisable: Uninitialized variables, erroneous or unknown values, and value contention. By value contention I mean a floating-point signal whose value cannot be deterministically resolved, for example driving two or more distinct voltages with 0 impedance onto a common signal. An unknown value can model several conditions, for example an undriven signal that is leaking charge at some unknown rate (for instance during power shutdown) then after some time the value becomes unknown.

I agree that in real world modeling there may be less need for an X value, but it can still be a useful abstraction. Note that unlike X, a Z value is not just an abstraction. Z does represent a real condition - in a voltage discipline it is a high impedance condition.

        Arturo

-----Original Message-----
From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of John Michael Williams
Sent: Thursday, December 09, 2010 12:12 PM
To: sv-dc@eda.org
Subject: Re: [sv-dc] 4-state vs 3-D

Hi All.

Expanding on this idea:

For brevity, I am writing "variable" here as referring
both to nets, ports, and variables:

I think the use of 'x' values for float-format variables should
be determined not by logic but by pragmatism: When would someone
operating a simulator WANT to see such an 'x' (or, 'X')?

An 'x' in a discrete-valued variable means that the simulator,
for some reason, can't assign a '1' or a '0'. In VLSI
design, the strength of such an 'x' would be strong. This helps the
designer to find possible errors in the verilog. Usually, the
cause is a race condition -- racing between two alternative threads,
or racing (by the simulator) to display something not yet initialized.

Now, under what circumstances would a user WANT a float-format
number to include bits (or, a value) of 'x'? I think this
should be the question.

Clearly, a variable intended to retain a float-format number
almost never would be intended to be either 1.0 or 0.0 (exactly).
And +/- infinity usually would mean a computational error, not
a race condition.

My suggestion:

I think that assigning 'x' to such a variable should be treated
as an error, not as some decision representing a conflict between
1.0 and 0.0 (or +/- overflows).

Also, I don't see any benefit to displaying 'x' (or 'X') as the
value of such a variable, except only if it was uninitialized.

So, I think that 'x' (or 'z', which is a highz 'x') should be
illegal once a float-format variable has been initialized legally.

On 12/09/2010 07:21 AM, Scott Cranston wrote:
> First question to answer:
>
> What does the notion of 'X' mean in the real valued space? Which is another way of saying "what does real modeling" mean? All else is just semantics.
>
> What does 'X' mean in logic modeling: the net is in a 1 or 0 state, but I don't know which. Note that X does *not* necessarily mean "it is floating somewhere between the two voltage levels corresponding to the logic values" since the notion of voltage levels is an implementation (hardware implementation) detail. In pure logic modeling there is 0 or 1, that's it.
>
> Now X's arise from two sources (in classic Verilog):
> 1) uninitalized behavioral constructs such as registers
> 2) nets driven with strength-modeled drivers which result in an ambiguous strength or undriven strength (Z).
>
> Let's ignore the first for purposes of this discussion. In the second, the X's arise from a lower level of modeling abstraction (strength or switch-level modeling) which understands "more" about the world then just 0 or 1. For purposes of logic modeling, Z can be treated the same as X when considered as an input, however it should be noted that pure logic operations *never* result in an X - you need that lower level of abstraction to generate them.
>
> We need to do a similar analysis of real level modeling: what does an 'X' mean, i.e. what type of modeling requires the notion of an X *in the real domain itself* ? Is real modeling a lower level of modeling than logic, so that it can introduce X's into the logic world, or is it a higher level of modeling, which merely encapsulates the logic values in some other form. In other words, does it know more about the world, or less?
>
> -- Scott
>
> -----Original Message-----
> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Kevin Cameron
> Sent: Wednesday, December 08, 2010 7:26 PM
> To: Arturo Salz
> Cc: sv-dc@eda.org
> Subject: 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.
>>>
>>>
>>
>
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
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.