• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 636 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.

Cross core write

Tim Whipple
Intellectual 450 points

I have multiple cores running and when I attempt to have Core1 write to the Core0 L2 and then have Core0 read it back it does not appear. I also read it across the PCIe and it is not there as well.  

(*(volatile uint32_t*)(myAddr[remoteCoreID])) = msg;   //Doesn't work

If I attempt the write twice back to back I can then see the data from Core0 and across the PCIe bus.........what is happening here?  How can I fix this?  As i understand it this shouldn't be a cache problem.  I ran into this when using MSMC but was able to invalidate the address and also remap using MPAX to get it to work.  Isn't cross core L2SRAM cache coherent?

(*(volatile uint32_t*)(myAddr[remoteCoreID])) = msg;
(*(volatile uint32_t*)(myAddr[remoteCoreID])) = msg;    //Works

  • 0
    Intellectual 450 points

    In this post:

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/278386.aspx

    I read

    "you will need to perform a Cache WB on the core that was performing the writes to the other cores memories so that the data is forced back to the L2 memory space of the other core"

    so I tried the code below with no change in results:

    (*(volatile uint32_t*)(myAddr[remoteCoreID])) = msg;      //Only works if I do this twice

CACHE_wbL1d ((void *)myAddr[remoteCoreID], 4, CACHE_WAIT);
CACHE_wbL2 ((void *)myAddr[remoteCoreID], 4, CACHE_WAIT);
_mfence();
  • 0 in reply to Tim Whipple
    Intellectual 450 points

    I have also tried CACHE_invL1d and CACHE_invL2 before reading with the other core.  Still no luck.  Aligned the data to 128 and even increased the flush size to 128 as well.  No change.  Only the double write works still but that makes no sense and isn't a reliable solution.

  • 0 in reply to Tim Whipple
    TI__Mastermind 30825 points

    If I were to guess at the top of my head, you're using local addresses and not global addresses.  These addresses will not be decoded outside of their local CorePac (i.e. CorePac 0 can access to CorePac 0's local memory (L1/L2) w/ local addresses, but must use Global Address to access CorePac 1's local memory.)  And any external peripheral such as EDMA and PCIe must use the Global Address of L1 and L2 memories.

    For example the Local Address of the start of L2 is 0x0080 0000, the global address of CorePac 0's L2 is 0x1080 0000, CorePac 1's is 0x1180 0000, CorePac 2's is 0x1280 0000 (i.e. the global address has address bits [31:28] as 0x1 and [27:24] 0xY where Y is the CorePac number, address bits [23:0] remains the same.

    Best Regards,
    Chad

  • 0 in reply to Chad Courtney
    Intellectual 450 points

    Thanks but it looks like I should have posted a little more of my code.  Right before the write I have a while loop locking a hardware semaphore.  I forgot the semicolon.  Thanks for the suggestion.  I have seen in other posts that L2 is by default non-cachable but between cores they have problems.  Is this indeed something to be aware of?  I have only seen this issue in MSMCSRAM.  With this fix the core to core L2SRAM seems to be coherent.

  • 0 in reply to Tim Whipple
    TI__Mastermind 30825 points

    Glad it was just a syntax issue.

    There is no Cross-Core Coherence maintenance.  This would need to be handled manually.

    Best Regards,
    Chad