1. Home
  2. Field-Programmable Gate Arrays
  3. source synchronous DDR bus with non-continuous clock

source synchronous DDR bus with non-continuous clock

I'm hoping to get some help/advise on how to design this interface. We're targeting Spartan-6.

There=92s a bidirectional, source synchronous, DDR, single-ended bus running at only 25Mhz. The problem I=92m stuck on has to do with a non- continuous clock, only running when there=92s data. For the receive side I was thinking the clock would go through a BUFIO2 and clock the data into an IDDR2. Simple enough. Then, to move that data from the IDDR2 into the core=92s clock domain I was planning to use a shallow FIFO. The problem is with the last word and clock edge (after a burst). The last clock edge only gets the data into the IDDR2 register but there=92s not another edge to complete the transfer from the IDDR2 to the FIFO.

Thanks in advance.

Regards, Mike

Reply to
fpgaace
Loading thread data ...

At that speed you can use a faster internal clock at 100MHz or so, detect edges on the incoming clock, and use that to control a state machine handling all your internal timing requirements.

- Brian

Reply to
Brian Drummond

on-

Thanks for the quick reply Brian. That's basically what we have now but its become a challenge in Spartan-6 with all the clocking limitations.

Reply to
fpgaace

That's good to know there are clock limitations in the Spartan6. Would you = explain? Is it global routing or buffers for the clock nets on the S6?

I find it strange that the DDR interface only has a clock when data is movi= ng.=20

From what I can remember, doesn't the source/master on a "typical" DDR syst= em need to drive a clock for a while prior to the data transfer to allow sy= ncing of clocks due to the windowing nature of data on both edges? Meaning = registering on the receiving node needs to be very tightly synced to the so= urce clock. Maybe this doesn't apply in the source sync model you are using= ? Please correct if I am mistaken.

Reply to
Dustin Brothers

If you know you have a minimum time that the clock goes inactive, and can detect this condition, you could just bypass the FIFO when the clock is inactive and the FIFO empties. Then you just need a bit more logic to prevent the last word of the previous burst (the one that bypassed the FIFO) from being pushed into the FIFO at the start of the next burst, or alternately ignoring the first word from the FIFO after a new burst starts.

-- Gabor

Reply to
Gabor

non-

ot

ct

That's perhaps best approach.

Second though, you may try to give the clock 1 or 2 more cycles just to move the data to the FIFO ? I think it's doable

Reply to
Mawa_fugo

Its simple: don't use a FIFO and make sure the incoming DDR clock has a known relationship to the FPGA clock. At 25MHz timing should be really easy. If the transfer is somehow initiated by the FPGA you might be able to tell when to expect the data so you won't need to look at the 25MHz clock.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Reply to
Nico Coesel

-

Thanks to all the input. Here's answers to some of the questions, and the final solution...

Though its only 25Mhz (50Mbps), the data valid window is approx

+/-4ns. Still plenty of margin.

The clocks are all derived from an on-board osc so there's really no way to gaurantee a phase relationship of the derived clocks from two different devices, therefore a FIFO is needed to decouple timing (ie., cross clock domains).

The driving device is an ASSP so we can't make it generate extra clocks.

The solution is to by-pass all IO clocking elements (ie., BUFIO2, ISERDES, etc), and clock data directly into a pair of FIFOs using two BUFGs, one for rising and one for falling edge data.

Regards, Mike

Reply to
fpgaace

Sounds like you have a fpga that could do (async) clk edge detection at a much higher clock and just use the resampled data at the detected edge?

Reply to
Morten Leikvoll

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.