• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 1566 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.

REG_CL setting not reflected by reality

Christofer Bengtsson
Prodigy 100 points

Other Parts Discussed in Thread: AM3505

Hello

We have finally managed to eliminate a problem which emerged after introducing a new revision of the DDR2 memory that we use with AM3505.

It seems clear to me that CAS latency is not equal to REG_CL, but instead REG_CL-1 which I haven't found any information about in the reference manual or errata. 

We thought we were running at CL 3 as intended, but in fact we had been running on CL 2 until we found out. This unfortunately resulted in some investigation time and a delayed project. 

Is this a known silicon bug, or have we missed or misunderstood any information?

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will forward this to the DDR experts.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru* 96721 points
    Christofer, I double checked our internal specs, and for DDR2 on AM3505, the REG_CL values of 2,3,4,5, and 6 correspond to CAS latencies of 2,3,4,5,and 6 respectively. There is no -1. Can you give us more information on how you verified the CAS latency? What is the part number for the DDR2 memory that you are using?

    Regards,
    james
  • 0 in reply to JJD
    Prodigy 100 points

    The following picture is showing Ch1: /WE and Ch2: DQS0P when SDRAM_CONFIG is set to 0x48804E21 (REG_CL = 3)
    tCK is 6,024 ns.


    As you can see, the delay from the middle of the command bit to the first edge on the data strobe, generated by the memory controller, is 2*tCK

    On the following picture, SDRAM_CONFIG is changed to 0x48805221 (REG_CL = 4)


    The delay is now increased to 3*tCK.

    SDRAM_CONFIG
  • 0 in reply to Christofer Bengtsson
    TI__Guru* 96721 points
    Christofer, we are looking into this. Can you answer a few more questions:

    -What is your read latency set to in DDR_PHY_CTRL_1? This should be adjusted along with a change in CL.

    -Where along the trace are you probing the signal? Are you closer to the processor or to the memory?

    Regards,
    James
  • 0 in reply to JJD
    TI__Guru* 96721 points

    Christofer, one more questions

    Is the scope shot showing a capture of a read or a write?  I believe it may be a read, so you would need to start counting cycles when WEn is high.

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 100 points

    Hello James

    The traces between processor and memory are about an inch long. The measurement points are about half-way between processor and memory.

    We are pretty sure these are write bursts. The way we deterimine that is by looking at the waveform of DQS0P. It shifts between having two different styles. When the burst has the style seen in these aqcuirements it is always receeded by a /WE pulse, while no bursts of the other style are preceeded by a /WE pulse.

    Given that we were focusing on write bursts, I haven't documented the setting of READ_LATENCY very carefully, but I think it was set to REG_CL +1 in both cases

  • 0 in reply to Christofer Bengtsson
    TI__Guru* 96721 points
    Christofer, is it possible that you are observing a precharge command? Is it possible to capture RAS and CAS at the same time?

    REgards,
    James