Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST

Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | DDR-ram interface (xapp200)

There are 3 messages in this thread.

You are currently looking at messages 0 to 3.

DDR-ram interface (xapp200) - Michael Chan - 2003-08-09 09:24:00

Hi,

I'm working on a University project that requires ddr-ram interfaced to a
Vertex-EM device.  I am basing my design off xapp200 from xilinx.  The
design uses DLLs to deskew the system clock and ddr-ram clock.  The signal
fed back to the DLLs (sys_clk_fb) is apparently the ddr clk.  What I don't
understand is where I take this signal from.  Should I have tracks on my PCB
comming back from the ddr-ram chips to inputs on the fpga?  Or can the
feedback signal come from inside the fpga?

I am a little lost as to how the DLLs manage to sychronise the two clocks.
Any help would be appreciated.

Thanks.

Michael.





Re: DDR-ram interface (xapp200) - Michael Chan - 2003-08-11 00:09:00

Thanks for the help Bob.  I think I know what I
have to do.

Cheers,

Michael.

"Bob" <n...@earthlink.net> wrote in message
news:xc9Za.1457$N...@newsread4.news.pas.earthlink.net...
> Michael,
>
> There are two basic ways that DLL's are used to de-skew clocks. For lack
of
> any other names, they are:
>
> 1) internal de-skew
> 2) external de-skew
>
> Internal de-skew means that the global clock net, within the FPGA,
> transitions at the same time (phase) that the FPGA's input clock
> transitions.
>
> External de-skew means that a clock at an FPGA output pin transitions at
the
> same time (phase) that the FPGA's input clock transitions.
>
> Here are some terms you should know:
>
> IBUF/OBUF -- an FPGA input/output pin (what most of the FPGA pins are).
> IBUFG -- really just a standard I/O pin, but physically close to the
DLL --
> such that the DLL knows what its routing delay is to it. These are where
> clock inputs (and external clock feedback signals) are supposed to connect
> to.
> DLL -- the phase detector, etc...
> BUFG -- a global clock buffer. The output of the BUFG's are the global
clock
> nets.
>
> With internal de-skew, the output of the BUFG (global clock net) is fed
> directly back to the DLL's clock feedback input -- with the FPGA itself.
> With external de-skew, the output of the BUFG feeds an OBUF (output pin).
> Then, a trace on your circuit board connects that OBUF to an IBUFG.
>
> With a synchronous RAM design (like your DDR project), the idea is to
first
> get a clock to the RAM that has the same phase as one of the FPGA's
internal
> global clock nets. This is so that the timing of the RAM read data, at the
> FPGA IBUF's, has a known time relationship. One of the DLL's in the design
> is used to do this -- via external de-skew.
>
> The other DLL is used (via internal de-skew) to create the "read RAM data"
> clock.
>
> I haven't looked at XAPP200 carefully, but here's how we do our DDR
> controllers:
>
> 1) Use external de-skew to create the RAM's CLK/CLKB, and DQS clocks. Note
> that the DQS clocks (strobes) are tristated during RAM reads, and are not
> used during RAM reads. Additionally, this DLL's 90deg output is used to
feed
> the OBUF's that create the RAM DQ lines -- but only for RAM writes.
>
> 2) Use internal de-skew to create a separate clock net for RAM reads (and
> other FPGA functions).
>
> Having said all this, I must say that it's amazing to me that a Virtex-E
> device can be used for this type of application. I say this because the
data
> from the RAM is valid during the time "between" the RAM's DQS clock
(strobe)
> edges. So, when the RAM read data gets back to the FPGA pins, its valid
data
> position is not ideal (i.e., suitable setup and hold time). It is much
> easier to use a Virtex-II device, wherein a third internal de-skew clock
net
> can be generated (which has phase shift via the DCM) in order to properly
> capture the RAM read data.
>
> Either way, you'll learn a lot with this project.
>
> Regards,
> Bob
>
>
> "Michael Chan" <s...@student.uq.edu.au> wrote in message
> news:bh2scl$kop$1...@bunyip.cc.uq.edu.au...
> > Hi,
> >
> > I'm working on a University project that requires ddr-ram interfaced to
a
> > Vertex-EM device.  I am basing my design off xapp200 from xilinx.  The
> > design uses DLLs to deskew the system clock and ddr-ram clock.  The
signal
> > fed back to the DLLs (sys_clk_fb) is apparently the ddr clk.  What I
don't
> > understand is where I take this signal from.  Should I have tracks on my
> PCB
> > comming back from the ddr-ram chips to inputs on the fpga?  Or can the
> > feedback signal come from inside the fpga?
> >
> > I am a little lost as to how the DLLs manage to sychronise the two
clocks.
> > Any help would be appreciated.
> >
> > Thanks.
> >
> > Michael.
> >
> >
>
>


______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: DDR-ram interface (xapp200) - Steven K. Knapp - 2003-08-11 11:25:00

I highly recommend the section on Eliminating
Clock Skew in XAPP462:  Using
Digital Clock Managers (DCMs) in Spartan-3 FPGAs.  The section begins on the
bottom of page 25.
http://www.xilinx.com/xapp/xapp462.pdf

Although the application note is written for Spartan-3 FPGAs, the DCM is
functionally very similar to Virtex-II and Virtex-II Pro.  The differences
are also described in the application note.
---------------------------------
Steven K. Knapp
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC

"Michael Chan" <s...@student.uq.edu.au> wrote in message
news:bh2scl$kop$1...@bunyip.cc.uq.edu.au...
> Hi,
>
> I'm working on a University project that requires ddr-ram interfaced to a
> Vertex-EM device.  I am basing my design off xapp200 from xilinx.  The
> design uses DLLs to deskew the system clock and ddr-ram clock.  The signal
> fed back to the DLLs (sys_clk_fb) is apparently the ddr clk.  What I don't
> understand is where I take this signal from.  Should I have tracks on my
PCB
> comming back from the ddr-ram chips to inputs on the fpga?  Or can the
> feedback signal come from inside the fpga?
>
> I am a little lost as to how the DLLs manage to sychronise the two clocks.
> Any help would be appreciated.
>
> Thanks.
>
> Michael.
>
>