Debugging DDR3 - refresh signal oddness on DQS

Hi,

We're trying to debug a new board with failing DDR3.  It's a Xilinx Zynq
chip with an ARM Cortex A9 dual core, and built in DDR interface/controller/phy.

We've scoped up the differential DQS lines and are using JTAG to perform
reads and writes but there's a lot of unexplained traffic on the line.

Every 7.8us (i.e. tREFI for the DDR) we see a burst of 33 pulses on the DQS 
(i.e. 64 zero crossings).  Between these long pulse trains, there 
are 39 shorter 5-pulse sets (i.e. 8 zero crossings).

On the (functioning) reference design we based out layout on these
DQS lines are silence

Any ideas what the source of this corrupting signal might be?

Thanks,
Gareth Owen

Gareth Owen <gwowen@gmail.com> wrote:
> Hi,
> 
> We're trying to debug a new board with failing DDR3.  It's a Xilinx Zynq
> chip with an ARM Cortex A9 dual core, and built in DDR
> interface/controller/phy.
> 
> We've scoped up the differential DQS lines and are using JTAG to perform
> reads and writes but there's a lot of unexplained traffic on the line.
> 
> Every 7.8us (i.e. tREFI for the DDR) we see a burst of 33 pulses on the DQS 
> (i.e. 64 zero crossings).  Between these long pulse trains, there 
> are 39 shorter 5-pulse sets (i.e. 8 zero crossings).
> 
> On the (functioning) reference design we based out layout on these
> DQS lines are silence
> 
> Any ideas what the source of this corrupting signal might be?

Taking a wild uninformed guess, something like the DLL recalibrating?

If your PCB trace lengths are signficantly unmatched (or you haven't told
the DDR controller IP what their correct timing is) then you won't be
delivering data in the middle of the signal eye.  The DLL will try to
compensate for that, but if the board layout is out it might struggle.

Also be aware that scoping the DQS lines is likely to add extra capacitance
and may throw out the DLL.

Theo

On Thursday, July 16, 2015 at 10:46:05 PM UTC+1, Theo Markettos wrote:
> Gareth Owen <gwowen@gmail.com> wrote:
> > Hi,
> > 
> > We're trying to debug a new board with failing DDR3.  It's a Xilinx Zynq
> > chip with an ARM Cortex A9 dual core, and built in DDR
> > interface/controller/phy.
> > 
> > We've scoped up the differential DQS lines and are using JTAG to perform
> > reads and writes but there's a lot of unexplained traffic on the line.
> > 
> > Every 7.8us (i.e. tREFI for the DDR) we see a burst of 33 pulses on the DQS 
> > (i.e. 64 zero crossings).  Between these long pulse trains, there 
> > are 39 shorter 5-pulse sets (i.e. 8 zero crossings).
> > 
> > On the (functioning) reference design we based out layout on these
> > DQS lines are silence
> > 
> > Any ideas what the source of this corrupting signal might be?
> 
> Taking a wild uninformed guess, something like the DLL recalibrating?

Very close.  It was the Write Leveling calibration.  
Thank you though, you got us looking in the right direction, and we found the issue (the sampled CLK wasn't getting back to the DDRC).

As a piece of psychic debugging I am in awe,
I'm also very grateful,

Thanks,
Gareth