1. Home
  2. Embedded Programming
  3. Debugging DDR3 - refresh signal oddness on DQS

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

Reply to
Gareth Owen
Loading thread data ...

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

Reply to
Theo Markettos

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

Reply to
Gareth Owen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.