DDR3 Command/Address lines parallel in dual stripline - how critical is crosstalk?

,

ely

l

ious

s

a

People seem to focus on the integrity of the data signal. It is my experie nce that the clock signal is much more susceptible. The data needs to be c orrect only during the sampling instant and really is insensitive the rest of the time. The clock is ALWAYS sensitive to any false edges. A glitch an ytime on the clock signal will cause an extra clock pulse which will create an error in the received data.

m

Putting more layers and forget about it

Or if you truly that cost critical then go by hyperlynx and figure it out in a methodical proper way

I believe you are describing traces running parallel on adjacent layers

0.2 mm apart? If the traces run far enough you can find significant cross talk. "Far enough" will require analysis with all your data. But if these are data lines on the same clock, why would you be worried about cross talk?

You will need to pay careful attention to detail to make sure the only traces involved are on the same clock. Get one trace in the mix that is changing when the line needs to be stable and you will be hosed. This is not the sort of thing that many layout packages will track for you. It will all be manual.

--

Rick C

But i can't image that a differential clock signal can be so much influenced on its stable phases by crosstalk that the receivers detect a false clock pulse. What is critical are the clock edges where crosstalk increases jitter. And there, the data setup clock edge should be unimportant for the receivers, only the sampling clock edge should be critical.

erience that the clock signal is much more susceptible. The data needs to be correct only during the sampling instant and really is insensitive the r est of the time. The clock is ALWAYS sensitive to any false edges. A glitc h anytime on the clock signal will cause an extra clock pulse which will cr eate an error in the received data.

If the clock lines are routed near other lines that have transitions during the time the clock is supposed to be stable, i.e all the data lines for ex ample, a transition on the data lines can cause a glitch into the clock whi ch creates an extra clock and an error.

My point is when clock and data are routed together, it is usually the cloc k (not the data) that ends up being the victim.

m

"Can't imagine"? It absolutely does happen in poorly designed boards. Lee Ritchey told about a company that was aggressively pushing the technology but didn't have a PCB design that was up to snuff (I think it was a backplane). The problems were exactly this sort of crosstalk. They wanted a bandaid that would let them go to production. Lee did his analysis and found it required a whole new design approach which would delay their schedule too much. They didn't listen to him and never got the product out the door before the doors closed.

--

Rick C