http://en.wikipedia.org/wiki/NaN - quiet vs signaling (I think someone
else mentioned that earlier).
Sometimes you are not looking at the result of a bad calculation, so you
would rather it was quiet. It's just another thing to collect
requirements for if you want to do real-valued signals.
Kev.
On 12/16/2010 06:02 AM, Lear, Jim wrote:
> Usually, NaNs generated in normal operations cause exceptions; e.g. divide by zero. Are there any conditions that generate a NaN without an exception being thrown?
>
> Kindest Regards,
> Jim Lear
> Cirrus Logic
> (512) 851-4612
> (512) 293-7248 (mobile)
> -----Original Message-----
> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Kevin Cameron
> Sent: Thursday, December 16, 2010 2:30 AM
> To: J. M. Williams
> Cc: sv-dc@eda.org
> Subject: Re: [sv-dc] 4-state vs 3-D - Voltages
>
>
> There was a long debate on how voltage contributions should work in
> Verilog-AMS. If I remember correctly: the behavior for driving multiple
> voltages from different modules/processes is that they are considered in
> parallel and unless they are identical it is an error, they only sum
> within a particular analog process or on a "named branch". Verilog-AMS
> also supports "switch branches" where the contribution can switch from
> being a current to a voltage - given that, I think it's clear that
> considering the branches as being in parallel makes most sense. The
> simplest example is a number of switches in parallel, either they drive
> 0V or are open circuit (a 0A current contribution, aka 'z'), multiple
> switches being closed doesn't cause a problem (in reality).
>
> Also, given that driving voltages and currents is well defined in
> Verilog-AMS, it would be best to just pick up that syntax and allow
> using it from always blocks etc. if that's all you want to do.
>
> If you want to do superposition of voltages from multiple drivers
> (without named branches) then you probably need to work out how to do
> that as a user-defined type - I'd say it's just a simple summing
> resolution function.
>
> Kev.
>
> PS: Legitimate arithmetic can throw up bad values like NaN, so it needs
> to be handled whether it represents 'x' or not.
>
> On 12/10/2010 01:27 PM, John Michael Williams wrote:
>
>> Hi Arturo.
>>
>> I don't know. Driving two or more different voltages onto a
>> single net (branch) should lead to a well-defined voltage, equal to the
>> algebraic sum (superposition) of the different ones (ignoring
>> impedance, or assuming it 0). Assuming this, I wanted to
>> exclude 'x' as a way of representing contention.
>>
>> In general, the circuit being modelled would resolve any
>> such "contention", according to Kirchoff's laws. I'm not sure
>> that a 0-impedance design should be any different than one
>> with very small, but finite and equal, impedances for each driver.
>>
>> Wouldn't nonconvergence, producing NaN, be a good-enough display
>> for the extreme, limiting case of this? I guess a short-circuit
>> should be defined, somehow, for impedance EQUAL to 0 (as
>> opposed to approaching 0 as a limit).
>>
>> In ordinary verilog, contention is an issue because ordinary
>> verilog is more of an abstraction and can handle only two
>> levels, '1' and '0', as well as the simulation-times at which
>> these levels are applied. 'z' just means no contention.
>>
>> I think the idea that a discrete-value 'x' might drive a
>> continuous-value variable should be a concern, but that the
>> result should not be an 'x' in the continuous regime. There has
>> to be some numerical value associated with 'x', and replacing it,
>> for a realistic simulation. If the 'x' is visible in the
>> discrete regime, isn't that enough for the simulator to warn the
>> user of erroneous or undefined behavior? Shouldn't the continuous
>> value evaluation either be determined by the user or simply
>> superpose the logic-1 and logic-0 values? Depending on polarity?
>>
>> I'd like to disallow the 'x' abstraction in calculations involving
>> float-value variables. It's too unlawful (in the context of Ohm's
>> & Kirchoff's laws).
>>
> ...
>
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Dec 16 13:13:04 2010
This archive was generated by hypermail 2.1.8 : Thu Dec 16 2010 - 13:13:06 PST