Synchronous clocking between Cyclone III and SDRAM

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 
towards the SDRAM so that we can compensate for the propagation delay of 
the clock towards the SDRAM. With this mechanism we do not see how 
process, temperature and voltage variations impacts on propagation delay 
will be taken care of. Could someone provide us with more explanations ?
We are familiar with some board deskew features once available with 
Xilinx parts such as Virtex II or Virtex II Pro using two DLLs and 
performing board deskew but Altera does not seem to promote such mechanisms.

Best regards,

JF

jean-francois hasson wrote:

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

http://www.google.com/search?q=zero+delay+clock+buffer

>jean-francois hasson wrote:
>
>> 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. 
>
>http://www.google.com/search?q=zero+delay+clock+buffer
>

I assume the fpga will write and read to the sdram with same clk. I wonder
why the clk should stay in phase since the write implies source
synchronous
interface(clk and data go together, any delay affects both data and clk).
while the read is destination synchronous(clk opposite data).
I have done sdram at 154MHz with stratix II and simply optimised the
timing window for both directions having estimated the board delay,without
problem.

>>jean-francois hasson wrote:
>>
>>> 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. 
>>
>>http://www.google.com/search?q=zero+delay+clock+buffer
>>
>
>I assume the fpga will write and read to the sdram with same clk. I
wonder
>why the clk should stay in phase since the write implies source
>synchronous
>interface(clk and data go together, any delay affects both data and
clk).
>while the read is destination synchronous(clk opposite data).
>I have done sdram at 154MHz with stratix II and simply optimised the
>timing window for both directions having estimated the board
delay,without
>problem.
>
one more issue,just realised. What do you mean by compensating for board
delay,clk will always suffer the delay. Do you have another clock in
sdram?

jean-francois hasson wrote:

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

Altera provides a comprehensive sdram controller wizard that should
satisfy all your requirements.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

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
> towards the SDRAM so that we can compensate for the propagation delay of
> the clock towards the SDRAM. With this mechanism we do not see how
> process, temperature and voltage variations impacts on propagation delay
> will be taken care of. Could someone provide us with more explanations ?
> We are familiar with some board deskew features once available with
> Xilinx parts such as Virtex II or Virtex II Pro using two DLLs and
> performing board deskew but Altera does not seem to promote such mechanisms.
>
> Best regards,
>
> JF

To be honest, I'm not sure why you are concerned with the routing
delay on the PWB.  Your SDRAM should be close to the FGPA to minimize
SI issues and I would expect the routing delay to be under 1 ns.  If
you are using SDRAM that should be a reasonably small portion of the
cycle time that it won't matter much.

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.

Rick

Hi,

What I was more worried about is the PVT compensation. Using the setup
you suggest it should do. However we don't have much margin on the
design so any ns we can get is welcome.

Best regards,

JF

>Hi,
>
>What I was more worried about is the PVT compensation. Using the setup
>you suggest it should do. However we don't have much margin on the
>design so any ns we can get is welcome.
>
>Best regards,
>
>JF
>

I believe cyclone III allows for dynamic PLL configuration, see AN507

kadhiem

rickman <gnuarm@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.

-- 
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!"
--------------------------------------------------------------

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

Rick