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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: constraints for DDR bus with 133MHz write and 66Mhz read clocks
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.


Quoted text here. Click to load it



Re: constraints for DDR bus with 133MHz write and 66Mhz read clocks
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


Re: constraints for DDR bus with 133MHz write and 66Mhz read clocks
Quoted text here. Click to load it

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.

Site Timeline