• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 2900 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM335x DDR3 software leveling INV_CLK question

Sung-IL
Mastermind 31310 points

Dear Champs,

My customer faced boot fail when they set 'INV_CLK = 1' for DDR3. could you please advice how they can debug this?

They used 'INV_CLK = 0' for DDR3 before, and their board works well in this case. but, I recommended to use 'INV_CLK = 1' because DDR_CK length < DDR_DQSx length.

But, they faced boot fail with 'INV_CLK = 1' setting and SW leveling values getting after SW leveling using CCS.

With 'INV_CLK=0' setting, it seems there is an compliant issue in DDR signal integrity although there is no issue to use at development stage.

Could you please advice me on this issue?

Thanks and Best Regards,

SI.

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will forward this to the DDR experts.
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 9655 points
    Just to update the forum -- I've been working with Sung-IL offline on a couple of tests. We'll summarize our observations and post in the forum.

    Regards, Siva
  • 0 in reply to sivak
    TI__Mastermind 31310 points
    We solved this issue after modifying CL and CWL values correctly based on datasheet.

    Siva,
    Thanks for your help and finding out our mistake!

    Thanks and Best Regards,
    SI.
  • 0 in reply to Sung-IL
    TI__Genius 9655 points
    Sung-IL

    Please also update if the original issue is resolved i.e. JEDEC compliance violation on tDQSCK timing parameter with the INVERT_CLKOUT=1 setting and optimal timings.

    Regards, Siva
  • 0 in reply to sivak
    Genius 5940 points

    Hi, Siva-san,

    I'm interested in your comment.

    As a result of our software leveling for 400MHz DDR,
    When INVERT_CLKOUT is 0,  the RANGE of RDATAx_PHY_RD_DQS_SLAVE_RATIO is wide.
                                                                    => tDQSCK timing parameter of JEDC compliance is Pass.
    When INVERT_CLKOUT is 1,  the RANGE of RDATAx_PHY_RD_DQS_SLAVE_RATIO is narrow.
                                                                    => tDQSCK timing parameter of JEDC compliance is Fail.

    If DDR3 runs 303MHz, tDQSCK is pass with INVERT_CLKOUT=1. Use of TI EVM or Cutomer board does not matter.
    We are thinking, there are some problem with INVERT_CLKOUT=1 & DDR400MHz.
    What do you know about that?

    Best Regards,
    Takahiro Ogo

  • 0 in reply to Takahiro Ogo
    TI__Genius 9655 points
    Takahiro-san

    Is the original issue still unresolved? Per Sung-IL comment on Aug 31st, 2015 the issue seems to have been resolved. Did you use the right CL/CWL settings that were incorrect earlier.

    I also recommend increasing Read latency by an extra clock cycle in case of invert_clkout=1 usage. Additionally, can you share more details on the issue and the test reports? I'm unaware of any issue using invert_clkout=1 and DDR running at 400MHz clock rate.

    Regards, Siva
  • 0 in reply to sivak
    Genius 5940 points

    Hi Siva-san,

    sivak said:
     
    Is the original issue still unresolved? Per Sung-IL comment on Aug 31st, 2015 the issue seems to have been resolved. Did you use the right CL/CWL settings that were incorrect earlier.

    Yes, of course. I use the right CL/CWL parameters.

    sivak said:

    I also recommend increasing Read latency by an extra clock cycle in case of invert_clkout=1 usage. Additionally, can you share more details on the issue and the test reports? I'm unaware of any issue using invert_clkout=1 and DDR running at 400MHz clock rate.
     


    Wow!!! After "Read Latency" was increased +1(equal to CL+3), the RANGE of RDATAx_PHY_RD_DQS_SLAVE_RATIO becomes wide despite INVERT_CLKOUT is 1.
    Thank you for your great support!

    Read Latency was set by CL"+2" until now. In TRM, the Read Latency is described as "The minimum read latency must be equal to CAS latency plus 2 clock cycle" in TRM.
    Why are you recommend increasing Read latency in case of invert_clkout=1? I'd like to know the mechanism.


    INVERT_CLKOUT=1 & Read Latency= CL+2
    ************************************************************************
    PARAMETER                        MAX  |  MIN  | OPTIMUM | RANGE |
    ************************************************************************
    DATA_PHY_RD_DQS_SLAVE_RATIO    0x023 | 0x007 |  0x015  | 0x01c
    DATA_PHY_FIFO_WE_SLAVE_RATIO   0x192 | 0x022 |  0x0da  | 0x170
    DATA_PHY_WR_DQS_SLAVE_RATIO    0x0ef | 0x016 |  0x082  | 0x0d9
    DATA_PHY_WR_DATA_SLAVE_RATIO   0x0ec | 0x089 |  0x0ba  | 0x063

    INVERT_CLKOUT=1 & Read Latency= CL+3
    DATA_PHY_RD_DQS_SLAVE_RATIO    0x066 | 0x005 |  0x035  | 0x061
    DATA_PHY_FIFO_WE_SLAVE_RATIO   0x1ce | 0x043 |  0x108  | 0x18b
    DATA_PHY_WR_DQS_SLAVE_RATIO    0x104 | 0x017 |  0x08d  | 0x0ed
    DATA_PHY_WR_DATA_SLAVE_RATIO   0x0fd | 0x093 |  0x0c8  | 0x06a

    Best Regards,
    Taka




    Best Regards,
    Taka

  • 0 in reply to Takahiro Ogo
    TI__Genius 9655 points
    Taka-san

    Read latency is the total latency involved from when a read command is issued to when the read data is available on the memory bus. So, this involves all the SoC and memory latencies including round trip delay (IO/board delays of CLK+DQS) etc. The typical recommendation for read latency is CL+2 to comprehend all the latencies involved. If you use invert_clkout the outgoing CLK to the DDR memory is shifted in phase by 180 (due to clock inversion) thus adding an extra 1/2 clock latency. Therefore, I recommended adding extra clock cycle since you cannot program 1/2 clock cycle. Hope this is clear.

    Regards, Siva
  • 0 in reply to sivak
    Genius 5940 points

    Hi Siva-san,

    Thank you very much for your understandable explanations. So clear now!
    You have helped me greatly!

    Thanks,
    Taka