On 6/26/06, Ryan Osial <[EMAIL PROTECTED]> wrote:
Requested Frequency: 84.6 MHz, worst slack -3.542 ns Requested Frequency: 33.0 MHz, worst slack 2.659 ns
Ah, I didn't realize it was doing this.
If I wanted to know its maximum frequency, I'd perform a essentially a binary search of the frequency space: try a frequency, and go up or down depending on the slack. I found 42 MHz with 0.265 slack as the fastest it could produce. That's about half as much as the synth guessed was the fastest frequency. By the way, I think this would be a good topic for a lesson after you start into synthesis.
It would be, if I knew more about it. I have a hard time predicting what kind of max delay I'll find in code before I first synthesize it. I do have rules of thumb I use that tend to yield good results, but what I'm much better at is optimizing code for speed after I've run it through the synthesizer once. Sometimes I can just tweak it. Sometimes, I have to rewrite, but at that point, I have a much better idea. Sometimes, things aren't what you expect. For instance, say a 16-bit adder by itself meets timing. Add combinatorial logic, and it may or may not. Add sequential logic before its input register or after its output register, and that may affect it. Put too few registers between a block ram and some pins, and your timing will be miserable, because P&R has to stretch the logic out across the chip. Have any kind of complex design, and the routing complexity may make all kinds of "simple" things break (like inserting a 5ns wire delay where you least expect it). Howard once described chip logic as being like a balloon. Squish it in one place, and it expands in another. And where it expands may be logic delay, or it could be power consumption, like with the P4, or any number of other things. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
