Re: Potential Contributions

From: <edaorg_at_.....>
Date: Tue Jan 30 2007 - 18:48:30 PST
Geoffrey.Coram wrote:
> Kevin Cameron wrote:
>   
>> According to Marq at least one simulator company has it's simulator
>> handling this with sharing the current across the sources, I'll presume
>> that they had some motivation for doing so.
>>     
>
> Since one simulator actually allowed unequal voltage sources to
> be placed in parallel, it is almost certain that this simulator
> indeed did place GMIN-like resistors in series with the voltage
> sources.
>
> I would guess the motivation was along the lines:
> Customer: hey, why can't I do this?  The voltages are equal!
>   What a dumb simulator.
> AE: OK, I'll ask R&D to fix it.
>
> and R&D might not have ever seen the test case, which might
> have had exactly the sorts of problems Ken mentions.
>   
I'm with the "customer" - if the physics/electronics makes sense it 
should be allowed in the HDL, and the simulator should make it's best 
effort to handle it.
>   
>> We need a definition of the behavior of parallel potentials for the LRM,
>> my view is that they should be allowed as long as the potential is
>> exactly the same and the current will be split evenly across the
>> potentials (and the user gets a warning). If you disagree propose
>> something different.
>>     
>
> As Marq pointed out, the potential is quite likely to be
> not exactly equal: 1/1/3 versus 3.  I've also seen cases where
> (on Intel machines) one floating-point number is stored in 
> an 80-bit register in the CPU and compared to a 64-bit number
> in the cache, and they don't match in those extra bits.
>   
Interesting, but I'd bet 0.0 == 0.0 will always work. Floating point 
numbers in Verilog are all supposed to be 64-bit IEEE, so getting a 
mismatch with an 80-bit register would be something for the compiler 
writers to fix.

Kev.
> -Geoffrey
>   
-- 
http://www.grfx.com
mailto:dkc@grfx.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jan 30 18:49:13 2007

This archive was generated by hypermail 2.1.8 : Tue Jan 30 2007 - 18:49:18 PST