One or two DLLs for a SDRAM controller?

Been there, done that,...If you have only one external device (SDRAM) it may be easy to adjust the trace/propagation... The situation get worse when more SDRAMS are ppopulated at different locations on your board. The board then need to be carefully designed and of course a second DLL is a big help too. Refer to xapp132 for details,

Regard,

Marius Vollmer wrote: [...]

same

work

1024x768 [... snip good drawing of OSC pin feeding two DLLs using a net called "ext clock"...]

DLL1

Howdy Marius,

Very close. The difference doesn't impact anything in this case, but I believe that the main and sdram clocks actually have zero phase offset when compared to the GCLK input pin. Said another way, the DLL/DCM has some automatic delay compensation in it to account for the delay through the IBUFG and associated routing, at least when in SYSTEM_SYNCHRONOUS mode (which is the default for DLLs and DCMs).

signals

You've actually produced a variation of the original drawing. Here's a simpler version of what you have, just ignoring the fact that the FPGA buffers the clock:

OSC ---+ | +--> SDRAM | | | | : buf clock | : v +--:---> IBUFG ----> DLL0 ---> BUFG -+--> main clock : ^ | : +--------------+

Assuming there isn't much phase difference between when the clock reaches the SDRAM and when it reaches the GCLK input, the above is how a "system synchronous" clock setup works. Your main clock will have the same phase as (or often times, it will slightly lead) your input clock signal, measured when it hits the FPGA GCLK pin.

So now the only question is if using the FPGA to buffer the clock causes any problems. The answer is it should not. Keep in mind that you can't expect your DLL/DCM to lock until well after the device is configured and asserts its DONE bit. I've not read up on the S3 DCM, but I assume it is the same as the in V2Pro, where you need to release the reset to the DCM *after* the clock is present at the DCM input. As long as you're doing that, I don't see a problem with it.

Good job!

Marc

Ahh, yes. I guess this is not specific to SDRAMs, right? When you have multiple chips on your PCB that are driven by the same clock and are thus one big, multi-chip clock domain, you of course needs to make sure that timing is met withing that big clock domain.

I don't see yet why the use of one or two DLLs (as sketched in my original post) _guarantees_ that timing is met since I would right now say that only the delay from SDRAM to FPGA has been taken into account. The path from FPGA to SDRAM is just as critical, I think, and has not been considered. In fact, I would say that one needs to use two separate clocks, one for sending to the SDRAM, and one for receiving.

In essence, you need to give up the one big clock domain idea, and use some kind of self clocking data pipe, one for every direction.

If you do insist on a single clock domain that covers both the FPGA and the SDRAM, you need to make sure that you PCB layout meets the timing constraints (in essence, PCB layout becomes part of your FPGA P&R run...), and then there should be no need to play tricks with DLLs other than as to compensate for an internal BUFG delay, which makes it possible to take that delay out of the P&R problem.

So, I am still confused, I have to admit...

I will, thanks!

Yes, I think I understand this now, thanks!

So, as I wrote in my other reply, the DLL is used to compensate for the BUFG (and IBUFG) delay so that the internal FPGA clock is properly synchronized with the external system clock. Since the P&R tools should know enough about the timing situation in the FPGA anyway, they might even be able to determine the delay needed in the DLL statically, and there would be no need for a feedback loop and no need to explicitely instantiate a DLL. (Maybe future FPGAs and their tools will use DLLs automatically if they are needed to meet the timing constraints?)

So, in the picture above, the FPGA is now properly part of the system clock domain, but the SDRAM still needs to be considered. As I see it now, this is not a problem of the delay of the signals between FPGA and SDRAM, but a problem of the delay between the oscillator and the SDRAM. The SDRAM must be close enough to the FPGA so that they can be in a single clock domain, in any case. Right?

I don't think I am doing this right now, but I will look into it. I guess the usual trick is to use shift register (that is clocked directly by the oscillator) that shifts out a couple of ones and the sticks at zero, right?

Thanks everybody!

they

need

tools

Certainly seems possible for a default case. Just need a way to easily override it for the exceptions.

it

be

There are several ways to make sure that the clock arrives at the same time for both the FPGA and the other external devices, so in my mind, the main problem is the delay between the FPGA and the SDRAM - which is usually a function of not only prop delay due to distance, but setup time and clock-to-out as well, which can eat into your clock period as it did for this application:

(click on "Multi-FPGA PCB data aggregation?" at the top to get the other msgs)

the

Yep. Just make sure the shifts add up to more than all the prop delays (the prop delay across the chip on the way out to the SDRAM is probably the longest).

[From your other posting]

make

Correct - DRAM is just the most common example.

now

Very correct. But for the clock frequencies (atually, data-eye widths) that most people deal with, you can get away with just using one.

use

A number of RAM's do this, including QDR SRAM. At even medium high frequencies (150 MHz), the data-eye is so small (effectively 300 MHz) on those devices that it would be very difficult to do as a part of a system-synchronous design.

Marc