Quartus II taking forever to compile

"Paul Leventis (at home)" <paul.leventis@utoronto.ca> wrote in message
news:vx7Wb.15455$Ovt.7578@news04.bloor.is.net.cable.rogers.com...
> [this is deviating pretty far from FPGAs...]
>
> > There are a few benifits of the AMD-64 architecture beyond the 64-bit
> width
> > (in general I agree with most of what you've written here - it's a good
> > explanation).  In particular, the larger number of registers is a help
in
> > many types of application.
>
> Good point -- I forgot to mention the doubling of the integer and SSE
> register files.  And moving to other 64-bit platforms could bring even
more
> architectural advantages (x86-64 still doesn't have that many registers
> available), though its sounding like x86-64 is going to be the primary
> 64-bit architecture (Intel has indicated they plan to release a 64-bit
> x86-based chip too, though aren't saying if it is same instruction set as
> Athlon64).
>

Theories abound on that one.  But for practical purposes, AMD's x86-64 is
available here and now on sensibly-priced processors, and is thus a far
better target than Intel's 64-bit x86 extensions (which are currently
unspecified vapourware) or the Itanium (which costs a great deal more, and
is slower than the Athlon/Opteron for integer work).


> > Also, for some types of application, convenient
> > 64-bit data items can lead to other benifits - for example, povray runs
> > slightly faster in 64-bit mode than 32-bit mode on an Athlon-64, but
more
> > importantly it runs more accurately, giving finer detail.  I don't know
> > whether this could apply to tools like Quartus (povray deals with
> > approximations to reality rather than absolute logic), but perhaps it
> might
> > have benifits for simulation.
>
> I don't think x86-64 brings any additional accuracy to floating-point
based
> code.  x87 always had 32-bit and 64-bit floating point available, and
> internally operates on 80-bit floating point numbers for increased
accuracy
> especially for things like sin(x) function it supports.  Intel now
> encourages programmers (and more importantly, compilers) to use SSE/SSE2
for
> general floating point computation and hence x86-64 brings no update to
the
> older stack-based floating-point unit.  Instead, it adds another 8 128-bit
> SSE registers to bring the total up to 16.  Floating point representations
> continue to be 64-bit double precesion in x86-64.
>
> One way that the move to 64-bit integers can result in improved accuracy
is
> when programs employ fixed-point representations.  For example, say I know
> that some value will vary from 0 to 1.  I could represent that value as a
> 32-bit integer "x", and implicitly know that the actual number is x /
2^32.
> Programmers used to do this sort of thing a lot back in the 386/486 days
> when integer operations were significantly faster than floating-point ops.
> This is less true than it used to be since integer multiplication/division
> is now handled by the same unit that does floating-point multiplies (well,
> except in the 90 nm version of the P4).  But still there could be some
> advantage since processors have more integer ALUs than floating-point/SSE
> ALUs and are generally geared towards processing integer data faster than
> floating-point data, especially for addition/subtraction/shift operations
> (since they are needed for addressing in addition to integer math).  On
the
> other hand, if you turn all your floating-point into fixed-point, then
your
> floating-point units go unused -- if you kept operations in
floating-point,
> then you can get parallelism inside the cpu with it using integer ALUs at
> same time as FPU.  So the net effect of using fixed-point these days is
> unclear to me.
>
> Anyway, I digress.  After digging around a bit in google, it looks to me
> like povray uses floating-point representations, so I'm not sure why it
> would be more accurate.  Do you have a link I could follow that claims
> increased accuracy?
>

x86-64 does not change the accuracy of floating-point work, as far as I
know, but as you say it would make a difference in fixed point work (with
appropriate source code).  The article mentioning povray accuracy is at:
http://www.linuxhardware.org/article.pl?sid=03/12/17/189239

I don't know anything about why povray is more accurate on the Opteron
beyond what is in that article.


> As for Quartus -- we don't have many cases of approximations which would
> benefit from increased accuracy.  Place and route is a mix of integer and
> floating point code -- but most floating-point calculations don't need to
be
> terribly precise.  Floating point is used (for example) when coming up
with
> a "score" for a given placement choice or to express how badly a signal
> wants to use a wire during routing.  We rarely even need double-precision,
> since by their nature optimization decisions don't need to be
super-precise
> since you're really just trying to figure out which resource/configuration
> is better than another.  If we got to the point that our cost functions
were
> so good at predicting the right configuration that double-precision
> round-off was detrimintaly affecting our optimization decisions, I think
the
> CAD optimization problem would be solved :-)
>
> For things like post p&r simulation and delay annotation, the accuracy
> provided by greater-than-double-precision would not be needed since we
can't
> hope to ever model the exact workings the chip to that fine level of
> accuracy anyway.  If we are ps accurate, that's pretty good -- and
compared
> to a critical path of (say) 100 Mhz, that's 1/10000 accuracy, which is
> easily handled by single-point precision.  Of course, I'm glossing over
> other benefits of increased precisions, such as reducing accumulation of
> error when adding up many small numbers (like in a post p&r timing sim),
but
> still I doubt double-precision loses steam...
>

Having freely available 64-bit integer arithmetic would allow you to do
these things in integers rather than floating point, which could improve spe
ed and accuracy.  In particular, they would let you hold your times in ps,
and have as long delays as you want without having to worry about overflows
or ranges.  Whether it would be worth the effort or not, I have no idea.

mvh.,

David


> Regards,
>
> Paul Leventis
> Altera Corp.
>
>