• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 578 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

6678 switching between 64-bit and 32-bit DDR3 mem

Jeff Brower73
Genius 3420 points

TI experts-

We need to run 64-bit vs. 32-bit DDR3 mem tests on the 8681 (quad C6678) PCIe card.  The card has 64-bit DDR3 mem installed (4x 16-bit devices).  Our question:  is it do-able and if so what is the best way to configure the card for 32-bit mem width (i.e. not use 1/2 the memory) ?

If we set the narrowMode bits in  DDR3Init(), rebuild platform lib, and then download and run init.out normally, before any application code runs, will that work?  What other registers have to be changed?  If so, what is a good way to know that our change is "sticking" ?

-Jeff
Signalogic

  • 0
    Genius 3420 points

    Follow-up question:

    Is writing to SDCFG "enough" to cause DDR3 PHY re-initialization?  Or is there a register write and/or bitfield sequence that must be followed?

    Also, if we have managed to change to 32-bit wide configuration, is there any straightforward way of verifying this (other than reading SDCFG) ?  For example some specific sequence of CPU instructions, DDR3 mem access, and/or EDMA that we can profile and see a difference?

    Thanks.

    -Jeff

  • 0 in reply to Jeff Brower73
    TI__Mastermind 46460 points

    Jeff,

    The DSPC-8681 Quad C6678 board is a product of Advantech, not TI.  You should be asking them for support.

    In general, such as on our EVM, a board with a 64-bit implementation can be configured for x32 operation.  The total memory size will be halved.  The NM bit sould be the only change at the DDR3 interface configuration level.  There may be application changes needed due to the reduction in addressable memory.

    Writes to the DDR_SDCFG register will trigger a SDRAM configuration as stated in the DDR3 Controller UG.

    Tom

  • 0 in reply to Tom Johnson 16214
    Genius 3420 points

    Tom-

    > The DSPC-8681 Quad C6678 board is a product of Advantech, not TI.
    >  You should be asking them for support.

    Yes we do frequently.  In this case I thought it's more of a chip question and I mentioned 8681 to hopefully make the thread more searchable and help other community members.

    > Writes to the DDR_SDCFG register will trigger a SDRAM configuration
    > as stated in the DDR3 Controller UG.

    Ok thanks for confirming this.  Can you suggest a certain sequence of operations that might "highlight" the reduction in DDR3 memory access width?

    Thanks Tom.

    -Jeff

  • 0 in reply to Jeff Brower73
    TI__Mastermind 46460 points

    Jeff,

    There is no direct way to measure this.  The controller supports up to 8GB of addressible memory.  If the physical addressible memory is less than this, the physical memory 'wraps' or is aliased.  You would have to write a program that accesses all of addressible memory and then detects this 'wrap'.  Note that access to memory beyond 2GB requires use of the XMC for address translation since a single DSP core only has 32 bits of addressing.

    Tom

     

  • 0 in reply to Jeff Brower73
    Genius 3420 points

    Tom-

    In 64-bit mode, could we write a known pattern to lower 1 GByte section and another (unique) pattern to next 1 GByte section, then switch to 32-bit mode and verify that we can no longer "find" the 2nd 1 GByte pattern?

    -Jeff

  • 0 in reply to Jeff Brower73
    TI__Mastermind 46460 points

    Jeff,

    Yes, something like that is what would be needed to prove the shift from 64-bit access to 32-bit access.  The 'missing' memory will be interleaved - i.e. data at previous address 0x00 to 0x03 will still be accessible and data at previous address 0x04 to 0x07 will be 'hidden'.  There is some risk that during the new write to SDCFG that changes the NM field will cause the memory contents to be corrupted.  If so, another solution is simply writing a linear test program where a unique value is written into every location (such as writing the 32-bit into each location) and then going back to the beginning to verify the contents.  If there is a wrap, the earlier writes will be overwritten with larger values.

    Tom

     

  • 0 in reply to Tom Johnson 16214
    Genius 3420 points

    Tom-

    Thanks very much for your detailed answer.  We'll try this.

    -Jeff