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@ieee.org % got no one..." http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELO
Xilinx DCM Block Stability Issues
Started by ●June 19, 2010
Reply by ●June 19, 20102010-06-19
On Jun 19, 6:00=A0pm, Randy Yates <ya...@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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "So now it's get=ting late,> Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 =A0and those who hes=itate> mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 =A0got 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
Reply by ●June 19, 20102010-06-19
Gabor <gabor@alacron.com> writes:> On Jun 19, 6:00 pm, Randy Yates <ya...@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...@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, > GaborThanks for the tips, Gabor. -- Randy Yates % "Rollin' and riding and slippin' and Digital Signal Labs % sliding, it's magic." mailto://yates@ieee.org % http://www.digitalsignallabs.com % 'Living' Thing', *A New World Record*, ELO
Reply by ●June 20, 20102010-06-20
On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <yates@ieee.org> wrote:>Gabor <gabor@alacron.com> writes: > >> On Jun 19, 6:00�pm, Randy Yates <ya...@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
Reply by ●June 20, 20102010-06-20
On Jun 20, 6:30=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote:> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote: > >Gabor <ga...@alacron.com> writes: > > >> On Jun 19, 6:00 pm, Randy Yates <ya...@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 oscillato=r?> > A quick look at the CDC924 datasheet suggests one thing... > check you have spread-spectrum turned off! > > - BrianOne 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
Reply by ●June 21, 20102010-06-21
Gabor <gabor@alacron.com> writes:> On Jun 20, 6:30 am, Brian Drummond <brian_drumm...@btconnect.com> > wrote: >> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote: >> >Gabor <ga...@alacron.com> writes: >> >> >> On Jun 19, 6:00 pm, Randy Yates <ya...@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@ieee.org % but there's a teardrop in his eye..." http://www.digitalsignallabs.com % 'One Summer Dream', *Face The Music*, ELO
Reply by ●June 21, 20102010-06-21
Randy Yates <yates@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@ieee.org % http://www.digitalsignallabs.com % 'Shangri-La', *A New World Record*, ELO
Reply by ●June 21, 20102010-06-21
On Jun 21, 2:22=A0am, Randy Yates <ya...@ieee.org> wrote:> Gabor <ga...@alacron.com> writes: > > On Jun 20, 6:30=A0am, Brian Drummond <brian_drumm...@btconnect.com> > > wrote: > >> On Sat, 19 Jun 2010 19:58:56 -0400, Randy Yates <ya...@ieee.org> wrote=:> >> >Gabor <ga...@alacron.com> writes: > > >> >> On Jun 19, 6:00 pm, Randy Yates <ya...@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 oscill=ator?> > >> 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. =A0There 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. =A0Newer 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "Bird, on the wi=ng,> Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 goes floating by > mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 but there's a teardrop i=n his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face Th= e 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
Reply by ●June 21, 20102010-06-21
Gabor <gabor@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@ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELO
Reply by ●June 22, 20102010-06-22
On Jun 19, 6:00=A0pm, Randy Yates <ya...@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
