[PCB_FORUM] Re: Metric to English - English to Metric

  • From: "richard moffat" <richard.moffat@xxxxxxxxxxxxxxxxxxx>
  • To: <icu-pcb-forum@xxxxxxxxxxxxx>
  • Date: Thu, 25 Aug 2005 09:51:38 +1200

Hi Austin
 
I agree - don't convert, because Allegro can't handle it!  It doesn't use 
enough significant digits when converting.
 
However, speed is still an issue.  Take a large board, lots of vias and layers, 
turn on negative plane islands, set it to dynamic, and then delete a via.  Then 
go have a cup of coffee, read the newspaper, go to the gym.  Then come back to 
see the hourglass still there. 
 
The CPU imposes the restriction that uses "standard" floating point 
representation, and the compiler is written for the CPU.  
 
Oh, the religious wars - Ford vs. GM, Microsoft vs. Linux, ...

>>> austin@xxxxxxxxxxxx 25/08/2005 9:25:48 a.m. >>>

Hi Richard,
 
Perhaps more than a decade ago, the CPU and code speed may have been an issue.  
But, in the realm we are talking about (a printed circuit board and the range 
of numbers and precision necessary) IMO and IME the compiler imposes no 
significant restrictions, nor does the "math processor" in the CPU.  Again, it 
is simply a matter of knowing where the decimal point is.
 
In Allegro, you don't convert because the tool can not handle it.  In a tool 
that can adequately handle it, this is not an issue.
 
Regards,
 
Austin 
 
 -----Original Message-----
From: icu-pcb-forum-bounce@xxxxxxxxxxxxx 
[mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx]On Behalf Of richard moffat
Sent: Wednesday, August 24, 2005 5:15 PM
To: icu-pcb-forum@xxxxxxxxxxxxx
Subject: [PCB_FORUM] Re: Metric to English - English to Metric


Cadence is probably making a compromise for speed.  The way that other tools 
may allow a seemless interchange is to have a greater length of significant 
numbers in the internal database, especially converting metric->imperial.
 
The programmers are restricted to that they are given:  The C compiler, and the 
maths processor on the CPU.
 
In short:  don't convert!


>>> austin@xxxxxxxxxxxx 25/08/2005 9:08:15 a.m. >>>

Hi,

> Conversely, 1/10 (0.1) cannot be exactly represented in base 2...

I design ASICs, and I have done a LOT of arithmetic functions in ASICs, and
use decimal points all the time.  All hardware arithmetic functions are done
in base 2.  It's simply a matter of knowing where the decimal point is and
using enough digits.  Yet, it goes on to explain the solution (as I said,
knowing where the decimal point is)...so I fail to see the *real* problem.

As was pointed out, PADS has no problem switching back and forth between the
two unit systems, so I simply don't believe Allegro can't do it as well.  It
seems like this may be a self imposed restriction:

> The real issue is that some numbers can't be represented exactly in the
> standard floating point representation.

Why do they have to use "standard" floating point representation anyway?
Sounds like someone programmed themselves into a corner, and instead fixing
it, they are trying to come up with explanations...instead of solutions.
Sigh.  To me, this is a huge weakness of Allegro.

Regards,

Austin





NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesyn Research Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesyn Research.

Other related posts: