ddr in virtex2

hello folks, i'm working with a avnet board that has a xc2v1500 and i've been trying to use the ddr memory it has. i can't get it to work, when i start the placement, edk complains that the placement constraints, that is the ddr pin assignment, are causing an IOB conflict. i've tried to use floorplanner to solve the conflicts but it didn't help. i'll send the error output and if someone knows of something i can do, or have had the same problem and can help me out i would be glad.

Phase 12.24 ERROR:Place:17 - The placement constraints of the IOBs fpga_0_Generic_DDR_DDR_DM_pin and fpga_0_Generic_DDR_DDR_DQS_pin makes this design unroutable due to a physical routing limitation. This device has a shared routing resource connecting the ICLK and OTCLK pins on pairs of IOBs. This restriction means that these pairs of pins must be driven by the same signal or one of the signals will be unroutable. Before continuing please remove the placement constraints or move one of these IOBs to a new location.

ERROR:Place:17 - The placement constraints of the IOBs fpga_0_Generic_DDR_DDR_CKE_pin and fpga_0_Generic_DDR_DDR_DQS_pin makes this design unroutable due to a physical routing limitation. This device has a shared routing resource connecting the ICLK and OTCLK pins on pairs of IOBs. This restriction means that these pairs of pins must be driven by the same signal or one of the signals will be unroutable. Before continuing please remove the placement constraints or move one of these IOBs to a new location. Phase 12.24 (Checksum:7270df4) REAL time: 1 mins 9 secs

NOTE: the placement constraints are the ones supplied by the board manufacturer.

thank's for any help.

This is a hardware bug on the Avnet boards. As the error message indicates, the Virtex2 chips used shared clocking resources on pairs of pins, restricting how they can be used particularly when using DDR registers. Avnet violated those restrictions. The easiest way to understand what is happening is to open up the chip in FPGA editor, and take a look at how the clocks are to the pair of IO blocks where the problem is happening.

Assuming that during a transfer/burst you will not be changing the DM signals, you can work around this problem by using the DQS clock on the DM signals. In this case, the DM signals would need to be valid half a clock early at the start of a transfer/burst, and held valid for an extra half a clock at the end.

As for the CKE signal, that one doesn't really change after init, so you can just add an extra output FF clocked with the DQS clock.