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

To go back a bit in the discussion, part of the idea was to move off the 4-state representation to something more comprehensive. The idea of "strength" is part of the "driven" dimension, "z" corresponds to undriven/zero-strength, if you add in the other Verilog strength levels then "driven" is more of an enum than a boolean.

If you mix up the concepts and do a real-value driver with strength, you can do resolution across types such that a "weak" logic '1' would be beaten by a "strong" real - e.g. a logical pull-up gets beaten by driving a stronger voltage. This is easier to do (in some respects) if you consider the net state as multi-dimensional rather than simple enums as in VHDL.
On the 'x' stuff: the point is not really to decide how it should be done, but how to let users describe the behavior they want, i.e. if you think assigning an 'x' to (say) a real valued type is a mistake, then you should be able to define a real valued type with that behavior, and someone else can allow it for their real-valued type. Likewise translating an "x" to NaN is something to leave to the user (but you do have to support NaN in the Language to do it).

Kev.

On 12/09/2010 12:11 PM, John Michael Williams wrote:
> 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.
>>>>
>>>>
>>>
>>
>>
>

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