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 19 Jun 2010 18:00 Hi, We're using one of the global DCM blocks in a Xilinx Spartan 3E to regenerate/deskew an important clock in our application. The clock has an input frequency of 31.5 MHz and we're using the 270 phase of the X1 output of the block. 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. We brought out the status signal that indicates "input clock is out of jitter tolerance" and observed that it is pulsing frequently. Indeed, it is during a group of those pulses that the output clock finally dies. Looking at the input clock with a scope doesn't reveal any particular problems. The signal comes from about 2 inches across a 4-layer FR4 board, so it isn't perfect (we've used a 33-ohm series resistor to "match" impedances), but it certainly looks good enough, although I realize that statement is somewhat imprecise and subjective. 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! --Randy -- Randy Yates % "So now it's getting late, Digital Signal Labs % and those who hesitate mailto://yates(a)ieee.org % got no one..." http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELO
From: Gabor on 19 Jun 2010 18:14 On Jun 19, 6:00 pm, Randy Yates <ya...(a)ieee.org> wrote: > Hi, > > We're using one of the global DCM blocks in a Xilinx Spartan 3E > to regenerate/deskew an important clock in our application. The > clock has an input frequency of 31.5 MHz and we're using the 270 > phase of the X1 output of the block. > > 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. > > We brought out the status signal that indicates "input clock > is out of jitter tolerance" and observed that it is pulsing > frequently. Indeed, it is during a group of those pulses that > the output clock finally dies. > > Looking at the input clock with a scope doesn't reveal any > particular problems. The signal comes from about 2 inches > across a 4-layer FR4 board, so it isn't perfect (we've > used a 33-ohm series resistor to "match" impedances), but > it certainly looks good enough, although I realize that > statement is somewhat imprecise and subjective. > > 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! > > --Randy > > -- > Randy Yates % "So now it's getting late, > Digital Signal Labs % and those who hesitate > mailto://ya...(a)ieee.org % got no one..."http://www.digitalsignallabs.com% 'Waterfall', *Face The Music*, ELO While good signal integrity helps, it really has little to do with clock jitter, since the FR4 delay is relatively constant. Spartan 3 DCM's are not particularly jitter tolerant. Also the jitter in the spec is measured inside the FPGA after possible insertion of additional jitter due to ground bounce and power-supply noise. At least make sure that there are no cross-talk issues on the board and that the PLL supplies (Vccaux?) are clean. It helps to avoid outputs with strong drive on IOB's near the clock input. These will inject noise into the receiver on the clock pin, and that noise increases the jitter more when the clock rise and fall rates are slower. What is your clock source? Is it just an oscillator or does it come from off-board? If you're using an oscillator you should also make sure it's Vcc is clean to avoid power-supply induced jitter. HTH, Gabor
From: Randy Yates on 19 Jun 2010 19:58 Gabor <gabor(a)alacron.com> writes: > On Jun 19, 6:00 pm, Randy Yates <ya...(a)ieee.org> wrote: >> Hi, >> >> We're using one of the global DCM blocks in a Xilinx Spartan 3E >> to regenerate/deskew an important clock in our application. The >> clock has an input frequency of 31.5 MHz and we're using the 270 >> phase of the X1 output of the block. >> >> 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. >> >> We brought out the status signal that indicates "input clock >> is out of jitter tolerance" and observed that it is pulsing >> frequently. Indeed, it is during a group of those pulses that >> the output clock finally dies. >> >> Looking at the input clock with a scope doesn't reveal any >> particular problems. The signal comes from about 2 inches >> across a 4-layer FR4 board, so it isn't perfect (we've >> used a 33-ohm series resistor to "match" impedances), but >> it certainly looks good enough, although I realize that >> statement is somewhat imprecise and subjective. >> >> 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! >> >> --Randy >> >> -- >> Randy Yates % "So now it's getting late, >> Digital Signal Labs % and those who hesitate >> mailto://ya...(a)ieee.org % got no one..."http://www.digitalsignallabs.com% 'Waterfall', *Face The Music*, ELO > > While good signal integrity helps, it really has little to > do with clock jitter, since the FR4 delay is relatively > constant. Spartan 3 DCM's are not particularly jitter > tolerant. Also the jitter in the spec is measured inside > the FPGA after possible insertion of additional jitter > due to ground bounce and power-supply noise. At least > make sure that there are no cross-talk issues on the > board and that the PLL supplies (Vccaux?) are clean. > It helps to avoid outputs with strong drive on IOB's > near the clock input. These will inject noise into the > receiver on the clock pin, and that noise increases > the jitter more when the clock rise and fall rates > are slower. Hi Gabor, Thanks - good points to check. > What is your clock source? I'm not sure (don't have the schematic here) but I think it's a TI CDC924. > Is it just an oscillator or > does it come from off-board? On-board. > If you're using an > oscillator you should also make sure it's Vcc is > clean to avoid power-supply induced jitter. That occurred to me but I haven't yet looked. > HTH, > Gabor Thanks for the tips, Gabor. -- Randy Yates % "Rollin' and riding and slippin' and Digital Signal Labs % sliding, it's magic." mailto://yates(a)ieee.org % http://www.digitalsignallabs.com % 'Living' Thing', *A New World Record*, ELO
From: Brian Drummond on 20 Jun 2010 06:30 On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <yates(a)ieee.org> wrote: >Gabor <gabor(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. 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
From: Gabor on 20 Jun 2010 10:38
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. > > 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. Regards, Gabor |