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

One thing to be careful about with NaN encodings is that the 754 std
allows for implementations to produce arbitrary results in some
cases. There are some "should" statements that most implementations
don't follow. If 'z' is actually encoded as a NaN as well as 'x' then
there
some problems with operations such as "a + b" with an x-NaN and
a z-NaN. There are other issues related to the production of
quiet NaNs in various circumstances and behaviors in which
NaN behaviors produce different NaNs that were not part of the
operation input.

Overall, if one wanted to have "any NaN" represent an 'x' then
things might be Ok (although I'd have to look a bit more carefully
about some circumstances) but having "distinguished NaNs" for
specific values is likely to have problems.

Gord.

On 12/8/2010 12:04 PM, Kevin Cameron wrote:
> It's mostly a performance issue, using NaN is supported by FPU hardware, so it's efficient. You can bury it a layer down in syntax, e.g. 1'bx ==<real var>,<real var> = 1'bx are the same as testing for NaN and assigning NaN, so users don't see it directly, but stuff goes in and out through PLI/DPI, so you need external code to know what pattern/value to use. In this case using NaN seems to work well, and it's hard to see a downside, but it's only a suggestion - feel free to make others.
>
> Uncertainty arises in type conversions and initial conditions, if you need to automatically convert a logic X to a voltage picking a "good" value like 0.0 is going to hide errors, throwing exceptions can unnecessarily kill your program, assigning NaN (or something similar) allows things to continue - e.g. if you have a two-way mux selecting between voltages and one of them is NaN (from a 1'bx conversion) but it doesn't get selected then the uncertain value is not a problem.
>
> As I mentioned elsewhere: "Z" is not really a value, just an indication that nothing is driving a net - i.e. a floating node has the value "Z", assigning "Z" to a driver is the same as disabling it. You might consider it a value in VHDL because in VHDL the logic types are usually just enums, and it's what you get out of the resolution function for no inputs. As such you can deal with Z/undriven separately from value propagation in a lot of cases, but since the value is definitely uncertain mapping it to NaN too seems to make sense.
>
> Anyway, the 3-D approach is just a more abstract way of looking at values on drivers/nets, the SV logic and wreal cases are special and I think we need a better semantic model going forward than "4-state".
>
> Kev.
>
> On 12/08/2010 09:26 AM, Scott Cranston wrote:
>> If we are going to use a specific value (NaN) to denote "uncertainty" in real, then there is no point in separating "value" from "certainty".
>>
>> I never liked using "NaN" or some specific value to denote "unknown" for reals - it bleeds implementation details into the language.
>>
>> In fact I never fully understood what "uncertain" means in the real domain - defining an X state or Z state for reals is nothing more than mapping the 4 logic states to 4 discrete real values, in which case what is the point of using reals at all, since it is just a renaming of logic?
>>
>> -- 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 12:13 PM
>> To: sv-dc@eda.org
>> Subject: [sv-dc] 4-state vs 3-D
>>
>>
>> 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.
>>
>>
>

-- 
--------------------------------------------------------------------
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.