Xilinx DCM Block Stability Issues
in [FPGA]
|
Prev: Difficulty with Xilinx FPGA configuration using Platform FlashPROM
Next: GTKWave 3.3.7 for Windows is available
From: Randy Yates on 21 Jun 2010 02:22 Gabor <gabor(a)alacron.com> writes: > On Jun 20, 6:30 am, Brian Drummond <brian_drumm...(a)btconnect.com> > wrote: >> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...(a)ieee.org> wrote: >> >Gabor <ga...(a)alacron.com> writes: >> >> >> On Jun 19, 6:00 pm, Randy Yates <ya...(a)ieee.org> wrote: >> >> >>> Anyway, if anyone has experienced or heard of such problems >> >>> with the DCM module and knows of a fix, I'd appreciate a >> >>> pointer. Thanks! >> >> >> What is your clock source? >> >> >I'm not sure (don't have the schematic here) but I think it's >> >a TI CDC924. Correction: It's a CDCE706. >> Deriving its own clock from a 14.318MHz crystal, or a reference oscillator? >> >> A quick look at the CDC924 datasheet suggests one thing... >> check you have spread-spectrum turned off! >> >> - Brian > > One more thing, the max jitter specs are all at least 300 ps, > and if I'm not mistaken this exceeds the jitter tolerance of > the Spartan 3E. There is no mention of whether the cycle-to-cycle > jitter depends on the spread-spectrum feature, but I would have > thought that if it did they would spec the presumably lower > number for non spread-spectrum jitter. > > I have used similar chips from Cypress (CY22392) and found that > even without spread-spectrum induced jitter they are only > marginal for use with the Xilinx DCM's. Newer Xilinx parts > have PLL's that can handle 1 ns peak-to-peak jitter, but with > Spartan 3E you might need to clean up your clock externally > or use another part to do the required frequency geenration. Thanks for the tips - but does any of this still go for the CDCE706? -- Randy Yates % "Bird, on the wing, Digital Signal Labs % goes floating by mailto://yates(a)ieee.org % but there's a teardrop in his eye..." http://www.digitalsignallabs.com % 'One Summer Dream', *Face The Music*, ELO
From: Randy Yates on 21 Jun 2010 02:29 Randy Yates <yates(a)ieee.org> writes: > Correction: It's a CDCE706. Also we have initialized it like this: 1. All clock slew rate controls are set to max (11b). 2. Byte 25, SSC modulation selection, is not transmitted, thus the spread spectrum control should be at its default, which is off. --RY > >>> Deriving its own clock from a 14.318MHz crystal, or a reference oscillator? >>> >>> A quick look at the CDC924 datasheet suggests one thing... >>> check you have spread-spectrum turned off! >>> >>> - Brian >> >> One more thing, the max jitter specs are all at least 300 ps, >> and if I'm not mistaken this exceeds the jitter tolerance of >> the Spartan 3E. There is no mention of whether the cycle-to-cycle >> jitter depends on the spread-spectrum feature, but I would have >> thought that if it did they would spec the presumably lower >> number for non spread-spectrum jitter. >> >> I have used similar chips from Cypress (CY22392) and found that >> even without spread-spectrum induced jitter they are only >> marginal for use with the Xilinx DCM's. Newer Xilinx parts >> have PLL's that can handle 1 ns peak-to-peak jitter, but with >> Spartan 3E you might need to clean up your clock externally >> or use another part to do the required frequency geenration. > > Thanks for the tips - but does any of this still go for the CDCE706? -- Randy Yates % "My Shangri-la has gone away, fading like Digital Signal Labs % the Beatles on 'Hey Jude'" mailto://yates(a)ieee.org % http://www.digitalsignallabs.com % 'Shangri-La', *A New World Record*, ELO
From: Gabor on 21 Jun 2010 09:29 On Jun 21, 2:22 am, Randy Yates <ya...(a)ieee.org> wrote: > Gabor <ga...(a)alacron.com> writes: > > On Jun 20, 6:30 am, Brian Drummond <brian_drumm...(a)btconnect.com> > > wrote: > >> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...(a)ieee.org> wrote: > >> >Gabor <ga...(a)alacron.com> writes: > > >> >> On Jun 19, 6:00 pm, Randy Yates <ya...(a)ieee.org> wrote: > > >> >>> Anyway, if anyone has experienced or heard of such problems > >> >>> with the DCM module and knows of a fix, I'd appreciate a > >> >>> pointer. Thanks! > > >> >> What is your clock source? > > >> >I'm not sure (don't have the schematic here) but I think it's > >> >a TI CDC924. > > Correction: It's a CDCE706. > > > > >> Deriving its own clock from a 14.318MHz crystal, or a reference oscillator? > > >> A quick look at the CDC924 datasheet suggests one thing... > >> check you have spread-spectrum turned off! > > >> - Brian > > > One more thing, the max jitter specs are all at least 300 ps, > > and if I'm not mistaken this exceeds the jitter tolerance of > > the Spartan 3E. There is no mention of whether the cycle-to-cycle > > jitter depends on the spread-spectrum feature, but I would have > > thought that if it did they would spec the presumably lower > > number for non spread-spectrum jitter. > > > I have used similar chips from Cypress (CY22392) and found that > > even without spread-spectrum induced jitter they are only > > marginal for use with the Xilinx DCM's. Newer Xilinx parts > > have PLL's that can handle 1 ns peak-to-peak jitter, but with > > Spartan 3E you might need to clean up your clock externally > > or use another part to do the required frequency geenration. > > Thanks for the tips - but does any of this still go for the CDCE706? > -- > Randy Yates % "Bird, on the wing, > Digital Signal Labs % goes floating by > mailto://ya...(a)ieee.org % but there's a teardrop in his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face The Music*, ELO The jitter looks a lot better on the CDCE706. Still at the low end of the VCO frequency range it's perhaps marginal for the Spartan 3E. Look at your VCO and divider settings. The data sheet seems to imply that setting the VCO to a higher frequency will reduce the cycle-to-cycle jitter. So if you are generating 63 MHz and dividing by 2, you might want to instead generate 126 MHz and divide by 4. Regards, Gabor
From: Randy Yates on 21 Jun 2010 10:32 Gabor <gabor(a)alacron.com> writes: > [...] > The jitter looks a lot better on the CDCE706. Still at the low > end of the VCO frequency range it's perhaps marginal for the > Spartan 3E. Look at your VCO and divider settings. The data > sheet seems to imply that setting the VCO to a higher frequency > will reduce the cycle-to-cycle jitter. So if you are > generating 63 MHz and dividing by 2, you might want to > instead generate 126 MHz and divide by 4. Thanks Gabor! -- Randy Yates % "Watching all the days go by... Digital Signal Labs % Who are you and who am I?" mailto://yates(a)ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELO
From: Brian Davis on 22 Jun 2010 21:24
On Jun 19, 6:00 pm, Randy Yates <ya...(a)ieee.org> wrote: > > However, we've observed that the block seems to be marginally > stable. At random, the clock output completely dies, usually > lasting somewhere between approximately 2 to 6 seconds. > How are you resetting the DCM ? Held in reset until well after the external clock oscillator is programmed and stable ? Watchdog type reset logic to make sure it actually locked at startup? > Looking at the input clock with a scope doesn't reveal any > particular problems. Have you looked at the internal-to-the-chip clock signal heading into the DCM by 'forwarding' it back out of the chip with an ODDRsomething output register? Other random thoughts: - VCCAUX Power supplies and the like are OK? - does a test design with just the clock generation & reset logic also randomly die? ( i.e. with all other I/O tied off to static levels ) - look at the input clock and DCM routing and placement in the FPGA editor- on the same side of chip, no wacky local routes in use? - old post about V2 DCM troubleshooting with Answer Record links but the V2 specific stuff probably doesn't apply: http://groups.google.com/group/comp.arch.fpga/msg/e469dd385fe2fcc7 Brian |