• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 368 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.

DDR2 signal slew rates

Nick Borton
Genius 3595 points

Other Parts Discussed in Thread: TMS320C6472

I have a 6472 on a custom board, and I am trying to get the DDR interface up and running. The PLL is configured correctly, and the interface appears to be configured as it should. The clock to the memories is correct, and the 6472 appears to be running refresh commands periodically. While looking at the RAS and CAS signals, they are transitioning very slowly. They take about 50%-75% of the clock period transitioning. I have changed the series termination resistors on these signals from 22 ohms, to 10 ohms and then to 0 ohms, with no change to the signal slew rate. Should I also be changing the series resistors on the gate signals as well?

  • 0
    TI__Genius 12790 points

    Before suggesting things to look at, were the Guidelinse followed per 'SPRAAT7D' 'TMS320C6472 DDR Implementation Guidelines?

    Are there any differences between your DDR layout and that of the C6472 EVM?  Are you using GEL to set values?

    Regards,

    Marc

  • 0 in reply to pathfinder
    Genius 3595 points

    We are configuring through runtime code. There is an initialization function we wrote based off the EVM, which we are calling before BIOS starts.

     

    Layout is a possibility..... We did follow the DDR guidelines to the best of our ability, which is why I was questioning our series termination values. Those resistors are much easier to change than layout, and was implied in the guide to be customized per the design. I do not believe our layout is a direct copy of the EVM. I'll have to ask how closely our artwork guy tried to keep our board to the EVM.

  • 0 in reply to Nick Borton
    Genius 3595 points

    Quick update and new question:

    We have our 6472 accessing the DDR. We have configured it with both a gel script based off the EVM and our own code, it acts the same. The slew rates of the signals have not changed. It still takes close to 75% of a clock cycle for an address or command bit to transition from a '0' to a '1'. What we are noticing is that accesses from memory where the physical A0 line is high is causing A3 to invert. Which is very odd.

    The question: when performing only column accesses (read and write commands) to the DDR, will the controller ever assert A0? A1 and A2 will be asserted through out our tests to read and write the memory, but A0 will not. When accessing larger regions of memory A0 is asserted during row activate commands. So A0 is toggling. Is this normal?

  • 0 in reply to Nick Borton
    TI__Expert 6815 points

    Can you please clarify "accesses from memory where the physical A0 line is high is causing A3 to invert."?

  • 0 in reply to Aditya
    Genius 3595 points

    It turns out that we were programming the CAS Latency incorrectly into the register. The Rev H documentation on how to program the CAS Latency was different from Rev I. Once we found that we should be programming CAS + 1 to the register it appears to be working OK, even though the slew rates are much slower than I've seen on most other DDR controllers, it seems to be functioning so far.

  • 0 in reply to Nick Borton
    Genius 3595 points

    I have not received and answer to this question yet:

    When performing only column accesses (read and write commands) to the DDR, will the controller ever assert A0? A1 and A2 will be asserted through out our tests to read and write the memory, but A0 will not. When accessing larger regions of memory A0 is asserted during row activate commands. So A0 is toggling. Is this normal?

    I would like to know to help narrow down where my issue is. All even 32 bit addresses I have inspected access normally, but odd 32 bit addresses are incorrect.