• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 832 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.

C6472 Atomic Access Monitor - SL2RAM Questions

CalvinC
Intellectual 990 points

1) When using the C6472 AAM instructions (LL,SL,CMTL) on S2LRAM, does the state of the SMC pre-fetch matter?

2) If we need to set up multiple monitor variables/addresses, is there any minimum spacing required between sequential variables (sizeof(int) or CACHE_L2_LINESIZE)?

3) The ammCrit functions in the SMQT libraries block until a lock can be obtained. That means a poorly behaving routine on Core 0 that won't release a lock can "hang" all other cores that attempt to secure a lock. Is there a version that will timeout and return an error instead?

Thanks,

Calvin

  • 0
    TI__Mastermind 30825 points

    1.) No, it doesn't matter, but it is still recommended to place them in non-prefetchable regions.

    2.) Only that they must be in separate memory banks (which are 256b wide.)

    I'll have to have someone familiar with the SMQT libraries address this.

    Best Regards,

    Chad

  • 0 in reply to Chad Courtney
    Intellectual 990 points

    Thanks for the reply. We are complying with 1) & 2) and staying "tuned" for a answer to 3).

    When a core releases a lock by writing a zero back to the shared (non-prefetched) memory, does it need to perform any CACHE_wb() to ensure that the change propagates to physical memory? The examples don't show this but we've run into enough other issues dealing with L2/L1 cache that we are suspicious.

     

    -Calvin

  • 0 in reply to CalvinC
    Intellectual 990 points

    I looking through the SMQT code (AAMCRIT)  I answered the cache question - YES (_wbInv() ).

    However,  I do have one last question regarding LL,SL,CMTL. Does the address in the instruction need to be the local address 0x0020000-0x002BFFFF or the core specific global address 0x1-200000 -0x1-2BFFFF? I"m currently using the core specific global address but getting unexpected results (not getting the same value with LL as a LDW to the same address).

    -Calvin

  • 0
    TI__Mastermind 23525 points

    Calvin,


    Not familiar with the SMQT libraries, but you should be able to use the .asm spinlock code at:

    http://processors.wiki.ti.com/index.php/C6472

    On that page look for: Spinlock Example Code

    Now there are three versions of the spin lock included, a normal consecutive lock attempt with on limit on attemps, one with exponential backoff with unlimited attempts, and a try_lock with a set number of lock attempts.   The intent of the exponential backoff spinlock is to provide a gap between polls of the lock when you haven't acquired the lock.  When you have multiple cores attempting to get the lock, if they are in sync with each other, they can prevent the lock from being granted.  The backoff spinlock helps with this situation. The try_lock lets the user specify a finite number of lock attempts.  This one may be the closest to what you are looking for.


    Regards,

    Travis

  • 0 in reply to tscheck
    Intellectual 990 points

    Many thanks for the link.

    This zip includes the same spin_lock.asm I have been using, but appreciate that it includes a try_lock function (which is what I really need).

    However, this spin_lock.asm is the file/function that is not working. So I'm still at an impasse.

    The C6472 provides two address ranges to access the shared SL2RAM. Does is matter if the address passed to LL,SL,CMTL is the "local" 0x00200000 address or core specific "global" 0x1-200000 address?

     

    -Calvin

  • 0 in reply to CalvinC
    TI__Mastermind 23525 points

    Calvin,

    There is no such thing as local addresses for the shared L2 space.  I see that line in memory map table of the data manual and it is definitely misleading.  I'm not sure why it is there, but I can definitely say you must use the core specific global addresses 0x1n200000, where n = core.


    Regards,

    Travis

  • 0 in reply to tscheck
    Intellectual 990 points

    Travis,

    Many thanks for the clarification. That is a bit misleading as it inferred that each core can access its L2RAM via either local or global specific addresses. I presumed the same was true for SL2RAM.

    Thanks,

    Calvin

  • 0 in reply to CalvinC
    Intellectual 990 points

    Travis,

     

    Can you confirm the "no such thing as local addresses for shared L2 space". We actually have been using 0x00200000 for core 0 when sharing data to cores 1-5 without any issues. Cores 1-5 use a global address but core 0 does not. Have we been extremely lucky?

    Dazed and confused ...

    -Calvin

  • 0 in reply to CalvinC
    TI__Mastermind 23525 points

    Well I have to apologize and eat my words on this one.  I even double checked with a colleague before replying last time, and we were both mistaken.  You can access SL2 with both the a local 0x00200000 address or global per core address 0x1-200000 from each core.  There is a direct port connection from CPU megamodule to SL2 memory controller and either of these ranges are decoded and use this same access port.


    Regards,

    Travis