• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 1491 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.

DDR3 setup and xmc_setup() in evmc6678l.gel

Marty
Intellectual 300 points

In the example gel file for the C6678 EVM (in my installation; C:\ti\ccsv5\ccs_base_5.0.3.00028\emulation\boards\evmc6678l\gel\evmc6678l.gel) there is a function called xmc_setup(), doing this:

    /* mapping for ddr emif registers XMPAX*2 */
    XMPAX2_L = 0x100000FF;     /* replacement addr + perm*/
    XMPAX2_H =  0x2100000B;    /* base addr + seg size (64KB)*/ //"1B"-->"B" by xj

I'm trying to understand it to see if I need to do something similar in my startup code, can someone please explain?

I think I know the XMC basics from reading chapter 7 in CorePac User's guide (sprugw0b).
It seems to me that the gel code sets up MPAX segment 2 for remapping:
   from ===> 0x2100.0xxx (i.e. size is 4kB, not 64 kB as claimed by the comment)
   to ====> first 4 kB of DDR3 external memory, at 8:0x8000.0xxx
If I understand this right, this segment 2 therefore is overlapping segment 1 that seems to map to start of DDR3 external memory, at 8:0x8000.0xxx.
Basically, the memories conflict? If this is correct, what is the purpose of this? Is it necessary, and why?

The DDR3 controller document states that its control registers are memory mapped to 0x2100.0000 and that the data manual specifies the mapped memory address. However, sprs691b just repeats the address 0x2100.0000...?

Confused right now, maybe because it's friday :-)

BR /Marty

  • 0
    TI__Mastermind 30825 points

    The way I interpret it is the following

    BADDR = 0x21000 and SEGZ B -> 4KB (not sure why the note list it as 64KB maybe it was F originally and later changed w/o updating the note)

    So it's saying to Remap 0x2100 0000 - 0x2100 0FFF

    Next is what it's being remapped to.

    RADDR = 0x100000, PERM = 0xFF (full permissions) - it says to remap that range to 0x1 XXXX XXXX

    So remap 0x2100 0000 - 0x2100 0FFF to 0x1 2100 0000 - 0x1 2100 0FFF.

    Why it's being remapped I'm not sure but I'll find out.

    Best Regards,
    Chad

  • 0 in reply to Chad Courtney
    TI__Expert 6815 points

    The 32-bit logical address for DDR3 config space starts at 0x21000000. The 36-bit physical address for the same begins at 0x1:00000000. Accesses to DDR3 space (both config and memory) happen via MSMC.

    The CPU converts a 32-bit logical address into a 36-bit physical address using XMC. The MSMC receives this 36-bit physical address which the MSMC needs to map to one of its two master ports: 1) MSMC system master port that forwards the access to the Teranet or 2) MSMC EMIF master port that forwards the access to the DDR3 EMIF. The 36-bit physical address for the DDR3 config space is 0x1:00000000. The XMC mapping in the GEL ensures the MSMC routes the accesses to config space correctly.

  • 0 in reply to Aditya
    Intellectual 300 points

    Aditya, thanks for the explanation.
    Looking closer at the GEL, I agree that your interpretation is correct; i.e. the function remaps
      from ====>   2100.0xxx  (32-bit address space)
      to  =====> 1:0000.0xxx  (36-bit address space)

    All applications that need to use DDR3 memory (including mine) obviously need to configure DDR3 correctly according to their respective board. I did not foresee that this XMC config was necessary to access the DDR3 config registers. I'm getting seriously worried that there are additional XMC segments that need to be configured, that I did not think of!!

    IN WHICH DOCUMENT(S) is the 36-bit address space specified? I cannot find the above information anywhere...

    BR, Marty

  • 0 in reply to Marty
    TI__Mastermind 30825 points

    Marty,

    I talked to Aditya and this is the only item that XMC configuration is actually required.  I believe this is stated in the DDR UG and is part of the sample code for configuring the DDR interface.  The rest of the system does not require the XMC address extension to access it.

    Best Regards,
    Chad

  • 0 in reply to Marty
    TI__Expert 6815 points

    Marty,

    As Chad said you need to only configure XMC for DDR3 config space since the accesses for these pass through the MSMC. The other config spaces should be visible without XMC re-mapping. Information on 32-bit to 36-bit XMC mapping can be found in the CorePac users guide. The MSMC users guide has more information on how the MSMC interfaces with the DDR3 EMIF (functional block diagram is a good start). Note that since the MSMC uses 36-bit addressing, accesses to MSMC ram and DDR3 EMIF always have to be extended to 36-bit. The extension for accesses coming from CorePacs is accomplished using XMC module inside CorePac. For all non-CorePac masters, the extension takes place inside the MSMC via the SES/SMS MPAX registers.

  • 0 in reply to Aditya
    Intellectual 300 points

    Thanks for your answers, I think I understand a little better now how the basic decoding works. With the exception of the case when a "non-CorePac master" accesses DDR3, not sure what this is referring to?

    I did look closely in the Data Manual, CorePac UG, and DDR3 UG and found nothing specific that indicates the need to set up this XMC segment. If there exists something about that, then please point out where, exactly, it is.

    Thanks again, Marty

     

  • 0 in reply to Marty
    TI__Expert 6815 points

    Marty,

    A "non-CorePac master" would be a master like EDMA or PCIe. These masters use 32-bit addressing so the SES MPAX and SMS MPAX within the MSMC are used to extend the addresses to 36-bit. Note: The DDR3 controller uses only the lower 33 bits for 8GB addressable space.

    Information on how to configure SES/SMS MPAX can be found in the MSMC users guide.

    Details on XMC MPAX are present in the CorePac users guide.

    Unfortunately, the specific explanation as to why XMC needs to be configured in that way for accessing DDR3 config space is not present in the DDR3 UG. My apologies for that. We will make sure it gets added.