Debugging DDR3 - refresh signal oddness on DQS

Jul 16, 2015 2 Replies
G

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


Vote
Twitter Facebook LinkedIn
T

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

Vote
Twitter Facebook LinkedIn
G

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

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required