Synchronous clocking between Cyclone III and SDRAM

rickman <gnuarm@gmail.com> wrote:

>On Apr 16, 12:46 pm, n...@puntnl.niks (Nico Coesel) wrote:
>> rickman <gnu...@gmail.com> wrote:
>> >On Apr 15, 4:19 pm, jean-francois hasson <jfhas...@club-internet.fr>
>> >wrote:
>> >> Hi,
>>
>> >> We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90
>> >> MHz. We are considering having the FPGA generate the clock to the
>> >> interface and find a way to ensure both the sdram and the cyclone III
>> >> are in phase regarding the clock. We could not find up to now a
>> >> mechanism that would ensure that both the SDRAM and the cyclone III will
>> >> have their clock  almost with the same phase relationship over
>> >> temperature, voltage and process. Could someone provide us with
>> >> indications regarding the implementation ?
>> >> Today we thought of using a specific PLL to generate a delayed clock
>>
>> >Still, if you need to reduce that, you can have the FPGA generate the
>> >clock, routing it to the SDRAM with a trace of a known length.  Also
>> >route a second, identical clock output back to the FPGA with the same
>> >length trace.  This may require some serpentine coils, but with a
>> >short route it shouldn't use too much board space.  Then both devices
>> >will be receiving an external clock that is totally in phase other
>> >than any skew generated internally in the FPGA.
>>
>> Totally useless. You don't need to synchronise the internal FPGA clock
>> with the SDRAM. Just clock the SDRAM from the FPGA and make sure you
>> meet setup and hold times on both FPGA and SDRAM. Thats all that
>> matters.
>--------------------------------------------------------------
>
>Isn't that a little bit like saying to make money in the stock market,
>you just buy low and sell high?  The point is *how* you meet setup and
>hold.
>
>The OP has said that his timing margins are tight and he has to be
>concerned with PVT variations.  Sourcing the clock from the FPGA is
>not a magic bullet.  In fact, I think doing that without routing it
>back to a clock pin makes it very difficult to even determine the
>timing of the I/O signals to the output clock, much less assure that
>it meets requirements of the SDRAM.  FPGAs have clear specs on timing
>relative to a clock *input*.  I have never seen specs on timing of I/
>Os relative to a clock *output*.

Its simple: If you source the clock from the FPGA, then the I/O will
have 0 delay with the clock edges (give or take the skew between
output buffers). When capturing data you can determine a window in
which the data from the SDRAM is stable (clock to SDRAM output delay +
routing delay combined with the setup and hold time. You'll probably
need 2 clocks with a phase shift (one for sending data to the SDRAM
and one for capturing data from the SDRAM). A 90 degree shift will
probably do. If you are unlucky you need a phase shifted clock for the
SDRAM as well. All these clocks can be produced inside the FPGA.

It goes without saying that the FPGA output and inputs must be inside
the I/O buffer cell. The external SDRAM signals should not be routed
inside the FPGA otherwise you'll be in a world of pain.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

nico@puntnl.niks (Nico Coesel) wrote:

>rickman <gnuarm@gmail.com> wrote:
>
>>On Apr 16, 12:46 pm, n...@puntnl.niks (Nico Coesel) wrote:
>>> rickman <gnu...@gmail.com> wrote:
>>> >On Apr 15, 4:19 pm, jean-francois hasson <jfhas...@club-internet.fr>
>>> >wrote:
>>> >> Hi,
>>>
>>> >> We are looking at interfacing the Cyclone III EP3C40 with an SDRAM at 90
>>> >> MHz. We are considering having the FPGA generate the clock to the
>>> >> interface and find a way to ensure both the sdram and the cyclone III
>>> >> are in phase regarding the clock. We could not find up to now a
>>> >> mechanism that would ensure that both the SDRAM and the cyclone III will
>>> >> have their clock  almost with the same phase relationship over
>>> >> temperature, voltage and process. Could someone provide us with
>>> >> indications regarding the implementation ?
>>> >> Today we thought of using a specific PLL to generate a delayed clock
>>>
>>> >Still, if you need to reduce that, you can have the FPGA generate the
>>> >clock, routing it to the SDRAM with a trace of a known length.  Also
>>> >route a second, identical clock output back to the FPGA with the same
>>> >length trace.  This may require some serpentine coils, but with a
>>> >short route it shouldn't use too much board space.  Then both devices
>>> >will be receiving an external clock that is totally in phase other
>>> >than any skew generated internally in the FPGA.
>>>
>>> Totally useless. You don't need to synchronise the internal FPGA clock
>>> with the SDRAM. Just clock the SDRAM from the FPGA and make sure you
>>> meet setup and hold times on both FPGA and SDRAM. Thats all that
>>> matters.
>>--------------------------------------------------------------
>>
>>Isn't that a little bit like saying to make money in the stock market,
>>you just buy low and sell high?  The point is *how* you meet setup and
>>hold.
>>
>>The OP has said that his timing margins are tight and he has to be
>>concerned with PVT variations.  Sourcing the clock from the FPGA is
>>not a magic bullet.  In fact, I think doing that without routing it
>>back to a clock pin makes it very difficult to even determine the
>>timing of the I/O signals to the output clock, much less assure that
>>it meets requirements of the SDRAM.  FPGAs have clear specs on timing
>>relative to a clock *input*.  I have never seen specs on timing of I/
>>Os relative to a clock *output*.
>
>Its simple: If you source the clock from the FPGA, then the I/O will
>have 0 delay with the clock edges (give or take the skew between
>output buffers). When capturing data you can determine a window in
>which the data from the SDRAM is stable (clock to SDRAM output delay +
>routing delay combined with the setup and hold time. You'll probably
>need 2 clocks with a phase shift (one for sending data to the SDRAM
>and one for capturing data from the SDRAM). A 90 degree shift will
>probably do. If you are unlucky you need a phase shifted clock for the
>SDRAM as well. All these clocks can be produced inside the FPGA.
>
>It goes without saying that the FPGA output and inputs *** must be inside
>the I/O buffer cell. The external SDRAM signals should not be routed
>inside the FPGA otherwise you'll be in a world of pain.

*** should say flipflops. The clock output for de SDRAM should also be
duplicated by a flipflip in the I/O cell. A DDR flipflip is the
easiest way. Otherwise you'll need to double the frequency and make
the clock output flipflop part of a divide by 2 counter.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------