From: "Michael Chan" Newsgroups: comp.arch.fpga Subject: DDR-ram interface (xapp200) Date: Sat, 9 Aug 2003 23:24:09 +1000 Organization: University of Queensland Lines: 18 Message-ID: NNTP-Posting-Host: s354025.student.uq.edu.au X-Trace: bunyip.cc.uq.edu.au 1060435157 21273 172.20.36.15 (9 Aug 2003 13:19:17 GMT) X-Complaints-To: news@uq.edu.au NNTP-Posting-Date: 9 Aug 2003 13:19:17 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!news.mel.connect.com.au!news.syd.connect.com.au!news.bri.connect.com.au!bunyip.cc.uq.edu.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31675 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. ###### From: "Bob" Newsgroups: comp.arch.fpga References: Subject: Re: DDR-ram interface (xapp200) Lines: 89 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Sat, 09 Aug 2003 16:21:49 GMT NNTP-Posting-Host: 4.43.224.25 X-Complaints-To: abuse@earthlink.net X-Trace: newsread4.news.pas.earthlink.net 1060446109 4.43.224.25 (Sat, 09 Aug 2003 09:21:49 PDT) NNTP-Posting-Date: Sat, 09 Aug 2003 09:21:49 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!switch.ch!news-fra1.dfn.de!npeer.de.kpn-eurorings.net!newsfeed.news2me.com!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread4.news.pas.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31649 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" 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. > > ###### From: "Michael Chan" Newsgroups: comp.arch.fpga Subject: Re: DDR-ram interface (xapp200) Date: Mon, 11 Aug 2003 14:09:14 +1000 Organization: University of Queensland Lines: 114 Message-ID: References: NNTP-Posting-Host: s354025.student.uq.edu.au X-Trace: bunyip.cc.uq.edu.au 1060574658 11671 172.20.36.15 (11 Aug 2003 04:04:18 GMT) X-Complaints-To: news@uq.edu.au NNTP-Posting-Date: 11 Aug 2003 04:04:18 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.mel.connect.com.au!news.syd.connect.com.au!news.bri.connect.com.au!bunyip.cc.uq.edu.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31666 Thanks for the help Bob. I think I know what I have to do. Cheers, Michael. "Bob" wrote in message news:xc9Za.1457$Nf3.400@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" 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. > > > > > >