constraints for DDR bus with 133MHz write and 66Mhz read clocks

I'm working on a design that needs to be able to write to a DDR ram at

133MHz but only needs to read back the data at a slower rate. I thought I could greatly ease the design by slowing down the clock on reads to say 66MHz. This really opens up my read timing budget. Doing fast writes is easier because I can use a 90 degree shifted clock to drive the DQS lines.

The problem is I'm not sure how to create a constraints file that enforces the timing required for different read and write clock speeds. Anybody have any ideas? I'm using a Spartan-3[E] and ISE 8.1.

Thanks, David Carr

Reply to
DC
Loading thread data ...

Doesn't DDR have a system clock that runs a DLL? The physical interface will have to maintain the same clock. Your reads can come into DDR IOB registers in bursts of 2 rather than 4 or 8 allowing the input registers to be read at your slower clock speed.

Look at the system level clocking that includes the DDR and the FPGA clocks.

Reply to
John_H

Good point about the DLLs in RAM itself. In this application (a digital scope) I do all writes in essentially one long burst and then go back and read the aquired waveforms. I could potentially pause while the DLLs relock at the new clock rate for the reads. The physical interface to the DDR RAM itself is presenting the problem. At

133MHz you really need to use the DQS strobes to latch the data. Unfortunately in the Spartan 3, its difficult to use the DQS as a latch signal and as a result most Spartan 3 DDR designs only use the system clock for reads.

-DC

Reply to
DC

By matching the DDR clock to the data I'm convinced that the read interface is doable without using the DQS though lane-to-lane skew matching has to tighten up to achieve that goal. Generating the DDR clock with the FPGA and routing a copy of that clock out to your memories and back will give you a matched round trip such that the clock copy can return to the FPGA at the same time as the read data would return. I started the design process and got great timing results but never got to where working silicon showed all the timings were precise. So I'm convinced it's straightforward, I'm just not certain of the numbers I was achieving.

Reply to
John_H

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.