Virtex4 CLKX2 DCM Jitter

I guess this is really one for Austin, but I wonder if anyone else has any 
input.

My company supplys a design which is used in a V4LX25.  The design uses 
external QDR SRAM @ 200MHz (400MBit). The design has a built in memory test 
which exercises the memories under worst case conditions (flat out) with 
pseudo random address/data, and all works well. However, the jitter on the 
Kclock to the memories gets a lot higher (>600pS) when this test is running. 
When the system is idle the jitter is <100pS. These "jitter" measurements 
are simply read off the scope eye pattern which is captured over several 
minutes. The jitter analyses software shows the same sort of numbers but I 
don't have them to hand.

All IOs are HSTL I 1.5V.

Due to constraints on the ASIC this thing is attached to, the FPGA currently 
takes in a 100MHz clock, and a single DCM creates a static phase shifted 
clkX2 output which is used to generate the K clock using DDR flops. There is 
a jitter paper on the SI bit of the Xilinx web site I use to convince myself 
(and others) that we can meet the 200pS cycle to cycle jitter requirement to 
the SRAM by the fact the DCM will only add jitter when it switches taps, and 
this will be worst case 80 odd pS or something per cycle ..etc etc.

If I run the memory test but disable the IO drivers of the FPGA (apart from 
the K clock) then the jitter on the clock returns to normal, so the jitter 
is related to the activity on the IO pins, not the core. The traces are very 
short, and I am measuring the K clock at the end terminator.

I also understand the x2 DCM output is more sensitive to VCCAUX noise then 
the x1 output. I thought at first it must be the PCB layout coupling noise 
into VCCAUX but I have played with a number of different boards with 
excellent layout and all behave similarly. Is it possible the coupling to 
the DCM is happening inside the Xilinx package?

I am about to do a board update and am considering adding a linear 2V5 
regulator to feed just the VCCAUX pins ???

Question : if it is possible to change the design to using the x0 phase 
shifted output (tricky, lots of work), does anybody know if it is 
Significantly more resilient to disturbance. Anybody else had a similar 
problem? The jitter when idle I can live with, its with lots of things 
waggling I get into trouble, so I have a feeling the x0 output may behave 
the same ??

I have found the Xilinx FAEs not terribly helpful on this, although there is 
a bit of info on the Xilinx support web (which is quite good, have you seen 
how Mentor have ruined theirs)???

Best regards,
Mike

MikeJ,

Let me study this, and get back to you.

Austin

Answered off-line,

Lots of stuff to go over.

Xapp 623 is the start of the process of review.

If IOs are causing it, then decoupling of the IOs, and ground bounce, is 
critical.

Austin

Thanks Austin,
/Mike

"austin" <austin@xilinx.com> wrote in message 
news:f44mo1$rae2@cnn.xilinx.com...
> Answered off-line,
>
> Lots of stuff to go over.
>
> Xapp 623 is the start of the process of review.
>
> If IOs are causing it, then decoupling of the IOs, and ground bounce, is 
> critical.
>
> Austin 

And one technique that Xilinx recommends for lessening
effects of ground bounce is to drive unused adjacent IO
to GND on the PWB, and drive these as outputs on the
FPGA. ie tie the input to the obuf to logic 0.
Regards,
John Retta
Retta Technical Consulting Inc.
Colorado Based Xilinx Consultant

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


"austin" <austin@xilinx.com> wrote in message 
news:f44mo1$rae2@cnn.xilinx.com...
> Answered off-line,
>
> Lots of stuff to go over.
>
> Xapp 623 is the start of the process of review.
>
> If IOs are causing it, then decoupling of the IOs, and ground bounce, is 
> critical.
>
> Austin 

Mike,

 Assuming you've already checked the likely suspects,
here are some random thoughts on jitter troubleshooting.
(FWIW, many of these will break other things and are not
suggested as a fix, just a troubleshooting aid )

 A) Try to distinguish whether the DCM input clock is
   affected when the I/O switches; or, if the DCM
   itself is being affected; or, if both are

   - clock your DDR clock forwarding flop directly from
     the input clock, with no DCM: does it still get
     the jitters when the QDR I/O switching starts?

     i.e.  100 Mhz input clock -> BUFG -> DDR output

     ( IIRC, you don't need to fiddle with DIFF_OUT buffers
     for global clock forwarding in V4 due to the already
     differential global clock distribution )

   - if you have another clock input ( esp. in a quiet bank ),
     temporarily clock the QDR logic from that ( with and
     without DCM ) and see if the jitter changes

 B) DCM Duct Tape

   - LOC the DCM to the other DCM sites on the chip;
     see if that affects the jitter

     Even if it's not an optimum LOC for the DCM because of
     the GCLK pin location, and there needs to be a long clock
     route to get there, putting the DCM on the other side
     of the chip away from I/O activity may help your jitter
     ( but not meet system timing )

   - change FACTORY_JF as described in Answer Record 13756

     If decide to try CLKFX, see AR 21594 and AR 18181
     ( V2/S3 era advice, not sure how it applies to V4 )

   - change DCM DESKEW_ADJUST to SOURCE_SYNCHRONOUS to turn off
     the internal DCM feedback delay element (more V2 era advice)
     ( see pages 4-5 of XAPP259 )

Other questions:

 - Do you have any spare LVDS input/outputs elsewhere
   on the chip ? ( handy for clock troubleshooting )

 - If you run a 'hammer' test 0000 <=> FFFF instead of
   pseudorandom patterns on the QDR address/data lines,
   does the jitter get much worse and/or the DCM unlock ?
   ( also try changing the toggle rate, 1,2..N clocks )

   FWIW, my S3 Starter Kit SRAM memory test that used a
   x2 DCM would unlock on hammer patterns, even with slow
   slew I/O meeting SSO limits, unless the DCM was LOC'd
   to the other side of the chip away from the SRAM I/O.

 - Is the QDR interface bandwidth sufficient to allow for
   Asteroids vector generator emulation at 1080p resolution?

Brian

On Tue, 05 Jun 2007 15:06:02 -0700, austin <austin@xilinx.com> wrote:

>Answered off-line,

Why, are we chopped liver?

> And one technique that Xilinx recommends for lessening
> effects of ground bounce is to drive unused adjacent IO
> to GND on the PWB, and drive these as outputs on the
> FPGA. ie tie the input to the obuf to logic 0.
> Regards,
> John Retta
> Retta Technical Consulting Inc.
> Colorado Based Xilinx Consultant

Hi John,

Yes, I have done this before on the bigger packages - any spare pins get 
nailed low.
This is a ff668 device and sadly I haven't got the spare pins.
All IOs are HSTL class I and the tools say I am within the SSO limits ..
Investigating the PDS and layer stackup but it looks pretty good to be 
honest.
Cheers,
/Mike 

"MikeJ" <mikej@fpgaarcade.nospam.com> wrote in message 
news:Rui9i.1428$ZA.885@newsb.telia.net...
>
> I am about to do a board update and am considering adding a linear 2V5 
> regulator to feed just the VCCAUX pins ???
>
Linear regulators get rid of noise below c.100kHz. Above that frequency, the 
only attenuation you get is the resistive loss with the bypass caps. I 
imagine your jitter is somewhat higher than 100kHz, so you might get more 
joy (and save $&#4294967295;&#4294967295;&#4294967295;) using passive filtering. Certainly, you must keep VCCAUX 
separate from the Vcco 2.5V.
HTH, Syms. 

Hi Brian, thanks for your tips.
>
> A) Try to distinguish whether the DCM input clock is
>   affected when the I/O switches; or, if the DCM
>   itself is being affected; or, if both are
>
Measurements at the clock input balls show no significant increase in 
jitter.

>   - clock your DDR clock forwarding flop directly from
>     the input clock, with no DCM: does it still get
>     the jitters when the QDR I/O switching starts?
>
>     i.e.  100 Mhz input clock -> BUFG -> DDR output
>
>     ( IIRC, you don't need to fiddle with DIFF_OUT buffers
>     for global clock forwarding in V4 due to the already
>     differential global clock distribution )
>
>   - if you have another clock input ( esp. in a quiet bank ),
>     temporarily clock the QDR logic from that ( with and
>     without DCM ) and see if the jitter changes
>
Good idea. I tried this before and I will need to repeat it to be sure.
I fed in a 200MHz single ended clock of the correct phase into a spare input 
pin and fed this through the same path minus the DCM.
It looked ok which pointed me at the DCM but I need to go back to this.

Also interesting is the other outputs (Address, data etc) show a much 
smaller jitter increase.

> B) DCM Duct Tape
>
>   - LOC the DCM to the other DCM sites on the chip;
>     see if that affects the jitter
good idea.
> <snip>
>
>   - change FACTORY_JF as described in Answer Record 13756
>
>     If decide to try CLKFX, see AR 21594 and AR 18181
>     ( V2/S3 era advice, not sure how it applies to V4 )
>
Tried both of these. CLKFX looks about the same, but the "shape" of the 
jitter is slightly different.
Austin assures me that in V4 the DCM is much less susceptible to noise than 
in the V2 days - I've been through this before :)
>
>   - change DCM DESKEW_ADJUST to SOURCE_SYNCHRONOUS to turn off
>     the internal DCM feedback delay element (more V2 era advice)
>     ( see pages 4-5 of XAPP259 )
>
> Other questions:
>
> - Do you have any spare LVDS input/outputs elsewhere
>   on the chip ? ( handy for clock troubleshooting )

I have an unused bank with 2V5 IO actually so I could possibly get some 
clocks in and out here.

>
> - If you run a 'hammer' test 0000 <=> FFFF instead of
>   pseudorandom patterns on the QDR address/data lines,
>   does the jitter get much worse and/or the DCM unlock ?
>   ( also try changing the toggle rate, 1,2..N clocks )
mmm. The chip actually has a max switching test as well which works (so no 
DCM unlock). I will make some measurements.

>
> - Is the QDR interface bandwidth sufficient to allow for
>   Asteroids vector generator emulation at 1080p resolution?
>

I usually try and keep work and the games separate, but it would make an 
excellent platform and save me finishing the DDR controller !!
I have a broadcast serial digital 720P output module somewhere, but what I 
need to make is a DVI output I think ....

Thanks for all the tips people, I will get some more measurements over the 
next week or two. Thanks also to Xilinx for the support.

My gut feeling is it must be a weakness in the PDS which is effecting the 
DCM particularly, but measuring these things is certainly tricky.

Cheers,
Mike.