Xilinx Timing Constraints and failures

Hi,

I am using Xilinx ISE 8.2 (SP3) targeted at a spartan 3 device.

We are attempting to use an FPGA for F/W and proof of concept work before taping out our ASIC, and are having difficulties with clocking.

Our product requires very low power consumption, and we perform global clock gating to reduce power consumption through the clock tree.

e.g. Master clock 16MHz, some logic is clocked at 8 or 4MHz, therefore only get a pulse every 2 or 4 clock cycles (we actually have about 12 clocks). In an ASIC flow, we can balance everything from the 16MHz clock and it will work.

For FPGA, it considers each clock independent, and we have hold problems, and setup problems (I haven't yet specified the multi-cycle paths for the "slow" clocks.

This is my first complex FPGA, and I have a number of questions

- When ISE has completed, there are a number of unplaced components, even thought utilization is low. Is this because it has failed timing, so it doesn't even bother.

- We may change to locally gated clocks (i.e. so that we only have one global clock). I still need to define the multi-cycle paths. Can anyone supply, or provide a link to, some example constraint files for this type of application.

- Any other pointers or suggestions would be greatly appreciated.

Thanks,

Steven

My suggestions are:

1) Fix the clocking problem:

a) spend money on "Synplify Pro"

formatting link

which is a synthesis tool that will do automatic "gated clock conversion". That is, convert a gated clock to a global clock with clock enables. Mentor has a similar product,

formatting link

b) Or spend time, and write your code so that switching between a gated clock for the ASIC and clock enables for the FPGA is handled by a constant, generic, conditional compile, component, etc. Might want to use a DCM to generate lower frequency clocks, however minimum input frequency is 18 MHz.

2) Unplaced components next. What is "utilization is low", in percent? Gated clocks can limit utilization, so fixing clocking first may very well help this issue. More detail is needed to help much on this one. 3) Timing next. 16MHz isn't very fast, so you may not need to worry about multicycle paths. With the issues of clocking and unplaced components, the timing report isn't very meaningful, so fix the first two problems, then look at timing.