Quote:
|
Originally Posted by Steve Siener
I heard that the chip(s) you have to work with were somewhat over-spec'd by the suppliers. Plus, running within tight timing constraints on an FPGA is tricky.
|
A better way to put it is that FPGAs are optimistically speced: they won't do many useful things running right at the top of their speed grade, since they achieve the highest speed for only for simple logic. One way around this is to deeply pipeline your logic so each pipeline stage is simple (hence fast), but the overall pipeline still does the thing you need it to do (which is why it's deep: lots of simple logic stages chained together to do something more complicated).
The timing constraints in FPGAs can be very tricky to deal with. I don't know how good the tools that Lumagen is using are, but the ones I've seen can best be described as stochastic in nature: the layout of the chip on the same HDL code and constraints will change from compilation to compilation. Couple this with the fact that not all I/O pins and logic blocks on the chip are really equal in capability (though the specs will claim they are), and you get lots of fun chasing your tail. For example, some logic blocks are closer to the ground pins, so if you have logic that draws high currents (lots of transitions all the time), they can appear stable when routed to be near those ground pins, and unstable if they're routed away from those pins. Hiding hardware behind a procedural language is an interesting and useful idea, but you still have to know what you're doing and what's going on behind the HDL code.
--Andre
