Most likely cause of DDR Interface Problem?

Jason,

Write to read timing is an SDRAM parameter, T_WTR.  Read to write timing is a Controller and routing parameter.  In the DDR2 implementation supported for the C6457, this is 1 clock cycle.  Section 3.2.4 of the C6457 DDR2 Controller User's Guide (SPRUGK5D) indicates that the Read Latency (RL) value needs to be set to the CAS Latency plus 1.  This sets the read to write turnaround timing in the C6457 controller.  Is this register field being set correctly to CL+1?  Is the CL being set correctly?

Read gate timing is set by the DDRRCVENIN and DDRRCVENOUT pins.  Section 6.4.4 of the C6457 DDR2 Layout Guidelines (SPRAAG6D) clarifies this requirement.  The routed track length from DDRRCVENIN to DDRRCVENOUT must be equivalent to the round trip delay which is the Clock delay plus the Data Strobe delay.  Is this routed correctly?  Is there a series termination resistor implemented in this loop?

Tom

Yes we are correctly setting the RL to CL+1.  We verified the register settings.

We did run an experiment where we changed RL = CL, and the number of failures was dramatically reduced.

So I wanted to understand what the RL relationship to CL is in the controller and I believe you answered that in the response.

The DDRRCVENIN and DDRRCVENOUT are routed correctly per the guidelines with one exception.  A series termination resistor was added, but it is at the input not the output (opposite of what the guide recommends).

Jason,

What do you see when you use RL to CL+2?

Tom

Jason,

DQS and DQ are bidirectional pins.  The RCVENIN pins control the read gate timing.  The write cannot start until after the input read data window is past.  If the RCVENIN was not correct, it could impact the write signal since the pins need to change direction.

Tom

Jason,

The tests thus far are basically poking at the problem without actually analyzing the problem.  We have no context for the failure being observed or the status of the design.  Please provide general information about the design and this observed problem.

Tom

The design utilizes the TMSC6457 device with two DR2 SDRAM chips MT47H64M16-3H industrial grade parts.

Typical T routing for address and control.
Series resistors 22.1 Ohm inline on all signals.
No differential termination on the clock or strobe lines.
Slew Rate pin pulled high on the DSP.
DDR Clock rate = 250MHz

This is the first failure observed out of approximately a dozen cards.

We are currently theorizing the root cause to be a VIA problem, but we are trying to understand the failure signatures we are seeing in order to determine where to look once we get it apart.

Another piece of information. When we enable the VPT compensation to full termination the problem goes away. We ran a test on another passing piece of hardware and when we disconnect the 47.5 ohm resistor from the PVT18 ball of the DSP the failure signature is "somewhat" similar to our failing CCA.

Can you explain in more detail how that works? I've read the documentation (SPRAA6D) on it and have a few questions.

When the DMCCTL[5:4] register is set to 00 that indicates no termination. Does the following have any impact if we have it set to no termination?

So if that external resistor changes in value does it still impact the DDR interface? If so, how?
What is the relationship between that resistor value and the DDR interface?
What signals does it impact? All of them?

Jason,

So you are saying that you have 1 failing boards out of a dozen boards assembled.  Is this a new design or a new build of an old design?  The C6457 is an 8 year old device.

Is there anything physical that you can do to the failing board to make it pass - like heating or cooling the processor which running the code that works on the other boards?  Similarly, is there any way to make one or the passing boards fail?

Tom

Yes we have been trying different things on a known good board to try to make the interface fail.. The design is old, not new..

Turning on ODT in the DDR device fixes the problem. Turning PVT compensation on in the DSP device fixes the problem.

Removing the PVT resistor causes a similar failure on a passing board.

I'm theorizing the DSP uses the PVT18 pin as some type of internal constant current driver. So when that resistor changes it modifies the drive of the IO even if we have the "no termination" option selected in the DSP register settings.

Jason,

The PTV18 input is used to calibrate the DDR I/O buffers at run-time.  The DDRPVTCNTL bits select set Thevenin termination for the DQ pins during reads.  Half termination will provide an equivalent termination approximately equal to the PTV18 resistor.  This is the proper value for boards designed per our guidelines.  No termination will result in excessive overshoot and ringing which may violate the IO spec and may also cause excessive crosstalk.  Full termination will result in an effective termination half the ideal value which may also cause impedance mismatch and may cause the rise and fall times to be too slow for proper operation.  Proper board design and PTV18 resistor implementation and programming are needed to obtain robust operation.

Tom