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.

RTOS/66AK2H12: Accessing DDR3A with DSP

Part Number: 66AK2H12


Tool/software: TI-RTOS

Hello,

I'm running the platform_test project from the RTOS SDK (ver# 5.03.00.07). My main focus on this example is the platform_memory_test function on the DRAM memory. The test function performs the tests over the 2.5 GB of DDR3B on board the EVMK2H, but doesn't run on the 2GB of DDR3A located in the SO-DIMM slot.

Based on other forum posts and documentation that I've read, the DDR3A is not by default addressable by the DSP cores and needs to be set through the MSMC to allow for 36-bit addresses, because it resides address range of 0x08 0000 0000 - 0x09 FFFF FFFF. My questions are:

  • Is it possible to make this address region usable by the DSP cores and if so are there any example programs/projects which do this?
  • Is there documentation on how to configure the MSMC to allow the DSP cores to access this memory region?

Thank you,

Kevin O'Connor

  • Kevin,

    Please check the guidance that we have provided on using DDR3A and DDR3B in a earlier post here. This requires configuring of MPAX setting in MSMC physical to logical address translation:

    https://e2e.ti.com/support/processors/f/791/p/796879/2962249

    https://e2e.ti.com/support/processors/f/791/t/804376?66AK2H14-DDR3A-configuration

    Document with description of MPAX settings:

    http://www.ti.com/lit/ug/sprugw0c/sprugw0c.pdf

    Best place to also understand software to setup DDR3A and DDR3B is the GEL file code used to setup the PLL here:

    C:\ti\ccsv8\ccs_base\emulation\boards\xtcievmk2x\gel

    Hope this helps.

    Regards,

    Rahul

  • Please also refer to a few new posts that were created on this topic

    https://e2e.ti.com/support/processors/f/791/t/810973

  • Hi Rahul,

    Thanks for the response. I've looked at the other posts you provided and I'm still confused. Based on the second post:

    It was stated that the GEL file uses only 32-bit addressing only for the ARM is this true for the DSP core as well?

    I've copied the XMC example they have done for the DSP core but it doesn't seem like the DDR3A region has changed.

    Is the DDR3A region (0x8 0000 0000 - 0x09 FFFF FFFF) directly addressable or is it always mapped to a 32-bit address like the 0x8000 0000? What else do I need to configure and how should I configure it to directly address the DDR3A regions separately?

    My end goal is to have the entire 2.5GB DDR3B region addressable over the 0x6000 0000 - 0x FFFF FFFF and the DDR3A directely addressable over the 0x8 0000 0000 region.

    Thanks,

    Kevin

  • Hello,

    Any update?  I'm still a little lost.

    Are the DSP cores only capable of accessing memory in the 08:0000 0000 - 0F:FFFF FFFF region by aliasing it to the 32-bit regions of 0x6000 0000 - 0xFFFF FFFF?

    I've looked at the MSMC address extension and while we can achieve a 36-bit address with the EMIF to memory map the larger memory regions, we are still limited to the 2.5 GB memory region above because we are aliasing it through the 32-bit logical memory. How do we get around this if we want something like a 4GB DDR memory in the DDR3A region. It just seems to me like it can't be all addressable. and we would lose 1.5GB of that memory?

    Thanks,

    Kevin O'Connor

  • Kevin,

    I have looped in the DDR design expert and author of the DDR initialization app note for this device. to see if he can provide any input on this configuration.

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

    RTOS/bare-metal usecases typically don`t require greater than 2GB DDR memory so we don`t support this usecase out of the box in the GEL or in the board library in Processor SDK RTOS. K2HK Linux offering supports upto 8 GB DDR configuration.and the configuration details can be found here in uboot configuration:

    https://lists.denx.de/pipermail/u-boot/2014-July/183452.html

    One way to test this could be to bring up uboot on the device and read the MSMC and DDR settings. 

    Regards,

    Rahul

  • Hi Rahul,

    Maybe I haven't been exactly clear on my question. Let me try rephrasing it.

    I want to attach a 4GB bank to the DDR3B interface.  Based on the memory map below, it looks like only 2.5 GB is physically available for the DDR3B region. How can I access the other 1.5GB of DDR3B (to allow me access to the entire 4GB bank attached to DDR3B)?

    Thanks,

    Kevin

  • Hi Kevin,

    Have you look into MPAX registers configuration both for DSP corePac and MSMC ?

    Regards,

    François

  • Hi François,

    Yes I've looked into the MPAX registers and it makes sense with the DDR3A memory, where the physical address range covers all 4 GB (0x8:00000000 - 0x9:FFFFFFFF) . With the DDR3B data, based on the picture above, it looks like only 2.5GB is addressable on the physical address range (0x60000000 - 0xFFFFFFFF). So to my understanding setting the MPAX allows us to map 32-bit logical addresses as a 36-bit physical address. It also allows us to set how our memory mapping works. The problem is that it looks like there is no physical addresses for the remainder of the DDR3B memory.

    What I don't understand is how we can map a logical address to the missing 1.5GB of physical address for the DDR3B data? Is it possible to map this region?

    Thanks,

    Kevin

  • Kevin,

    You are not interpreting the address map properly.  The DDR3A EMIF can support up to 8GB of DDR3 memory.  The DDR3B EMIF can only address a maximum of 2GB of DDR3 memory.  Even though you see these EMIFs on multiple rows in the table, these represent aliased windows into the same physical memory.

    Tom

  • Hi Tom,

    I see, I have been reading the map wrong. That 512 MB region is just an alias to the DDR3B physical memory.

    >> Even though you see these EMIFs on multiple rows in the table, these represent aliased windows into the same physical memory.

    Is this in reference to the 512 MB and 2GB region being aliased to the same physical memory or are you saying the DDR3A and B EMIFs  are actually the same physical memory. I believe it is the former, but I just want to make sure I'm understanding you.

    So based on all of this if we went with just populating the DDR3B memory, it looks like we would be constrained to 2GB of DDR3 memory for the DSPs?

    Thanks,

    Kevin

  • Kevin,

    DDR3A and DDR3B are distinctly different physical memory blocks.  On the chip, there are separate memory interfaces for them.  All chip cores and other masters can access all of both memory implementations.  However, if you analyze the infrastructure, you will see that the ARM cores have best performance accessing DDR3A while the DSP cores and many other masters have best performance accessing DDR3B.  Some applications that are computationally intensive while processing lots of streaming data have system throughout that is improved by having memory implemented on both DDR3A and DDR3B.  Although this is true, most customers only implement SDRAM on DDR3A.

    Tom

  • Tom,

    Thanks for the info

    >> Some applications that are computationally intensive while processing lots of streaming data have system throughout that is improved by having memory implemented on both DDR3A and DDR3B.

    That is what is currently planned. We are currently putting a 4GB bank on the DDR3A and a 4GB bank on the DDR3B. I want to make sure that the 4GB on the DDR3B is fully accessible and not limited to the 2GB PHY region specified on the memory map and how to access it if it is accessible.

    Thanks,

    Kevin

  • Kevin,

    As stated previously, the maximum addressable size on DDR3B is 2GB.  To increase the total accessible SDRAM on the processor, you should increase the SDRAM on DDR3A to 8GB.  The SDRAM on DDR3B can be reduced to 2GB since the upper half cannot be accessed.

    Tom

  • Tom,

    I appreciate the help. It would seem we need to re-evaluate our memory layout, but I'm confident I have enough information to move forward on this though.

    Thank you,

    Kevin