This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L138: OMAP-L138: DDR2 considerations to improve signal integrity.

Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAPL138

Hello:

I'm reviewing an old OMAP-L138 design which uses a MT47H32M16HR DDR2 memory, where from time to time apperas certain issues that are attributed to the signal integrity.

So that I'm checking the design, my main corcern are the DQ(15:0) lines, which are bidirectional, I want to make sure that in:

WRITE CYCLES

1) OMAP-L138:

DQ(15:0) Output drivers is matched to 50 Ohms and don't need a serial resistor.

2) MT47H32M16HR DDR2 memory:

DQ(15:0) lines include ODT terminations that can be activated through the SDCR  DDR2TERM(1:0) register. What is the recommended TI configuration? 50Ohms?

READ CYCLES

1) OMAP-L138:

doesn't OMAP-L138 include any ODT?

2) MT47H32M16HR DDR2 memory:

which are the recommended signal strength, selected by SDCR DDRDRIVE(1:0) register when there is a 22 ohmios serial resistor?

In general I would like to confirm the following datasheet statements:

  • "6.11.3.9 No terminations of any kind are required to meet the signal integrity and overshoot requirements" . Why are 22ohm terminal resistor are used in all the DDR2 lines of the OMAP.L138/C6748 LC Dev Kit ?
  • is   omapl138_zwt.ibs the latest IBIS model?

Thanks.

K.M

  • Hi Kepa

    • 6.11.3.9 No terminations of any kind are required to meet the signal integrity and overshoot requirements" . Why are 22ohm terminal resistor are used in all the DDR2 lines of the OMAP.L138/C6748 LC Dev Kit ?

    Please refer to the following doc

    http://www.ti.com/lit/an/spraav0a/spraav0a.pdf

    Pg 7 on FAQ Should signal terminations be implemented?

    We do not necessarily claim our EVM to be a "reference design" so we do recommend customers to look at datasheet and other collateral to make final choice on how to implement their hardware design (not just copy the EVM as is etc) 

    • is   omapl138_zwt.ibs the latest IBIS model

    Yes

  • Thanks for your answer.

    K.M.

  • What specifically led you to believe the issue is signal integrity?  Do you have captures from a scope indicating that's the case?  Also, have you looked at the bus from both ends:

    • DDR write: measure near DDR
    • DDR read: measure near processor

    Are signal integrity issues equally bad for both reads and writes, or is one worse than the other?  There are independent controls for the processor and the DDR.

    Did you implement series resistors in your design?

    Have you triple checked the length of the strobe signal that it is the correct length?

    How much do you need to slow down the DDR before it is stable?

  • Hello Brad:

    What specifically led you to believe the issue is signal integrity?

    -->The customer has noticed some unexpected behaviors in the controller operation (reset and so on ..). We have been outsourced to study the signal integrity of the design.

    Do you have captures from a scope indicating that's the case?  Also, have you looked at the bus from both ends:

      • DDR write: measure near DDR

      • DDR read: measure near processor

    Are signal integrity issues equally bad for both reads and writes, or is one worse than the other?  There are independent controls for the processor and the DDR.

    -->As a first approach we have simulated the design using the Hyperlynx software using IBIS models of the controller and DDR. We have noticed 700mV undershoot/overshoot in the processor sides in READ operations when the DDR output is set to full strength, however when is change to weak the undershoot/overshoot values remain under 350mV

    Did you implement series resistors in your design?

    -->The design includes serial resistors in the DQ(15:0), CSn, WEn, RASn, CASn, DQS(1:0) and DM(1:0) lines but not in the A(13:0) not in the BAM(3:0) lines. I have seen that in the OMAP-L138/C6748 LC Dev KIT includes serial resistor in all lines, so I will like to check whether they are necessary or not (Despite of the fact that the controller (and the simulations results) says that they are not necessary)

    Have you triple checked the length of the strobe signal that it is the correct length?

    -->Yes, all the DDR signal delays are in the 275ps+/-10 ps and also their impedance it is in 50 Ohm+/-5ohm range.

    How much do you need to slow down the DDR before it is stable?

    -->DDR operation frequency is 150MHz, and we have tried to slow it down.

    Thanks for your attention.

     

    K.M

  • What is the length of the trace connecting DQGATE0 to DQGATE1?  Its length is expected to equal the length of the CLK trace plus the average of DQS0/1.

  • Hello Brad:

    I answer to your question bellow:

    What is the length of the trace connecting DQGATE0 to DQGATE1?  Its length is expected to equal the length of the CLK trace plus the average of DQS0/1.

    • DQGATE0: 280ps

    • DQGATE1: 285ps

    • CLK: 277ps

    • average DQS0/1:285ps

    So, delay of these items can be estimated as:

    • DQGATE0 to DQGATE1: 280ps+285ps=565ps

    • CLK+ average_ DQS0/1: 277ps+285ps=562ps

    So, I think the delay between both items are pretty close (565ps/562ps)

    ¿is this what you mean?

    Thanks for your big support.

    K.M.

  • Kepa said:
    • DQGATE0 to DQGATE1: 280ps+285ps=565ps

    • CLK+ average_ DQS0/1: 277ps+285ps=562ps

    That's excellent.  I wanted to make sure that was correct so you weren't chasing issues elsewhere.

  • Hi Brad:

    Thanks for your support!

    Apparently the main issue is related with the strength of the DDR2 outputs in READ operations with 700mV overshoot/undershoot values when they are set to full-strength, which will be reduced to 300mV with the weak-strength option.

    If you think there are some other issues to verify beside the mentioned in previous conversations  let me know.

    Kind Regards.

    K.M.

  • Have you been able to make the corresponding change to the SDCR register and see an associated reliability improvement?  Maybe you don't even need to change the hardware.  Simply updating your configuration might be sufficient if that's the main problem.

  • Hi Brad:

    The change in the SDCR register configuration will be made by the software staff of the final customer, so in a few weeks we will know whether there is any improvement in the DDR2 behaviour.

    Regards.

    K.M.