On Fri, 2011-10-28 at 09:26 -0400, V G wrote: > On Fri, Oct 28, 2011 at 8:05 AM, Martin Darwin wrot= e: >=20 > > Sure. Reduce the logic in the critical path. The timing reports should = tell > > you this. > > >=20 > How? By rewriting my code? How would I know which part to rewrite? Yup. As Matrin said, the twr file will report critical paths, it's up to you to determine if there's a way of optimizing that path. Note though that you will very quickly hit diminishing returns, it's VERY likely the next slowest path is only slightly slower. You're already pretty much at the top speed I'd expect the fabric of a Spartan 3 to run at. > Eventually you will hit a hard limit of the internal routing delays takin= g > > up most of the clock cycle time. Doing something useful in a spartan 3 = is > > probably capped at ~250MHz (as you can see). > > >=20 > As opposed to something like a Spartan 6 or Virtex which is of higher > performance? Careful here. You also have to consider the real world here.=20 For example: bigger parts result in logic possibly having to span a larger die. This is where IO pin selection can be critical. To get from one end of the die to the other will obviously take longer in a physically larger part. Another area is clock pin selection. If you are using a regular IO for a clock it will introduce a delay getting to the clock network that can result in a slower design. A good trick for increasing design speed is to break your design up into pipelines, little chunks of logic separated by a flop. This is ESPECIALLY useful for outputs going to human eyes, they won't notice if the LED is updated 1, 10 or even 100 clocks later, but your design might run faster. Also look into location constraints. For example, if you're driving other logic look into locating flops in IOBs, this will result in much more predictable timing on the IOs and allows you to go faster externally. In the end though, trying to push more then about 200MHz in those FPGAs is tough. It's much better to use the parallel potential on an FPGA and run things slower but wider. For example, instead of processing something coming in on an 8 bit bus 8 bits at a type, what about collecting 2 8 bit chunks and operating on them 16 bits at a time. Stuff like that can REALLY improve the performance of your design, without increasing clock speed. TTYL --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .