source synchronous DDR bus with non-continuous clock

[fpgaace]

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

There’s a bidirectional, source synchronous, DDR, single-ended bus
running at only 25Mhz. The problem I’m stuck on has to do with a non-
continuous clock, only running when there’s 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’s 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’s not another edge to complete the transfer from
the IDDR2 to the FIFO.

Thanks in advance.

Regards,
Mike

 

[Brian Drummond]

On Wed, 20 Jul 2011 20:32:09 -0700, fpgaace wrote:

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

There’s a bidirectional, source synchronous, DDR, single-ended bus
running at only 25Mhz. The problem I’m stuck on has to do with a non-
continuous clock, only running when there’s data.
The last
clock edge only gets the data into the IDDR2 register but there’s not
another edge to complete the transfer from the IDDR2 to the FIFO.

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

 

[fpgaace]

On Jul 21, 4:30 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:

On Wed, 20 Jul 2011 20:32:09 -0700, fpgaace wrote:
I'm hoping to get some help/advise on how to design this interface.
We're targeting Spartan-6.

There’s a bidirectional, source synchronous, DDR, single-ended bus
running at only 25Mhz.  The problem I’m stuck on has to do with a non-
continuous clock, only running when there’s data.  
The last
clock edge only gets the data into the IDDR2 register but there’s not
another edge to complete the transfer from the IDDR2 to the FIFO.

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

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.

 

[Dustin Brothers]

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 moving.

From what I can remember, doesn't the source/master on a "typical" DDR system need to drive a clock for a while prior to the data transfer to allow syncing 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 source clock. Maybe this doesn't apply in the source sync model you are using? Please correct if I am mistaken.

 

[Gabor]

fpgaace wrote:

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

There’s a bidirectional, source synchronous, DDR, single-ended bus
running at only 25Mhz. The problem I’m stuck on has to do with a non-
continuous clock, only running when there’s 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’s 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’s not another edge to complete the transfer from
the IDDR2 to the FIFO.

Thanks in advance.

Regards,
Mike

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

 

[Mawa_fugo]

On Jul 21, 5:45 am, fpgaace <mikegulo...@gmail.com> wrote:

On Jul 21, 4:30 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:



On Wed, 20 Jul 2011 20:32:09 -0700, fpgaace wrote:
I'm hoping to get some help/advise on how to design this interface.
We're targeting Spartan-6.

There’s a bidirectional, source synchronous, DDR, single-ended bus
running at only 25Mhz.  The problem I’m stuck on has to do with a non-
continuous clock, only running when there’s data.  
The last
clock edge only gets the data into the IDDR2 register but there’s not
another edge to complete the transfer from the IDDR2 to the FIFO.

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

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.

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

 

[Nico Coesel]

fpgaace <mikegulotta@gmail.com> wrote:

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.

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=.)
--------------------------------------------------------------

 

[Morten Leikvoll]

"fpgaace" <mikegulotta@gmail.com> wrote in message
news:65471e92-9834-48df-a40e-01b925571c8b@a12g2000vbf.googlegroups.com...

Though its only 25Mhz (50Mbps), the data valid window is approx
+/-4ns. Still plenty of margin.

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?

 

[fpgaace]

On Jul 20, 10:32 pm, fpgaace <mikegulo...@gmail.com> wrote:

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

There’s a bidirectional, source synchronous, DDR, single-ended bus
running at only 25Mhz.  The problem I’m stuck on has to do with a non-
continuous clock, only running when there’s 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’s 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’s not another edge to complete the transfer from
the IDDR2 to the FIFO.

Thanks in advance.

Regards,
Mike

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