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

Silicon Errors on OMAPL138

Marc48067
Expert 2000 points
Other Parts Discussed in Thread: OMAPL138

Hello,

we just had a look at the errata sheet sprz301e.pdf were several silicon errors for the OMAPL138 are mentioned. For our application advisory 2.0.17 and advisory 1.1.2 could be critical. L2 is configured as 128k Cache and 128k RAM. We have a buffer in L2 RAM which is filled by QDMA. The CPU triggers the QDMA and waits for its completion. Then the CPU processed the new values stored in this buffer. It only reads out the buffer and does not modify it (no dirty lines in L1D). The buffer is aligned on a L1D Cache Line and is a multiple of L1D Cache Line size large. We are not able to move the buffer to L1D RAM, Shared RAM or DDR RAM! So I have 2 questions:

 

1. Does advisory 2.0.17/1.1.2 apply to this buffer, e.g. is there a risk to get corrupted data

2. Is calling BCACHE_Inv() for that buffer before starting the qdma sufficient as a workaround

 

Thanks for your efforts

  • 0
    TI__Guru 62975 points

    Marc,

    I'm glad that you checked the advisories.  Please note that the advisories for this device are numbered with the newest applicable Silicon Revision for the first two numbers so Advisory 1.1.2 only applies to revisions 1.1 and 1.0.  Since revision 1.x is no longer manufactured, you can safely ignore any of the 1.x.x advisories for new devices.

    So looking at Advisory 2.0.17 by itself, it looks like your buffer could potentially suffer from cache corruption, however you can just use the --c64p_dma_l1d_workaround compiler flag from Workaround Method 1 to avoid the issue.

    Invalidating the cache can work too, but there is a greater performance hit and requires more programming effort than using Method 1.

    -Tommy

  • 0 in reply to tlee
    Expert 2000 points

    Hi Tommy,

    I just recognized that we still have some OMAPL138 chips with silicon revsion 1.1. Does advisory 1.1.2 apply to our scenario mentioned above? Since there is no compiler switch for this, is calling BCACHE_Inv() for the buffer before starting the qdma a workaround? So perhaps we could use this as a workaround for both advisory 2.0.17 and 1.1.2.

    Thanks

  • 0 in reply to Marc48067
    TI__Guru 62975 points

    Marc,

    If your application does not modify any data in L2 RAM through CPU, Advisory 1.1.2 would not apply.  However, if you have other variables in L2 RAM that are read/modified by DSP, it's possible that they may share the same L1D line as your QDMA buffer and contribute to a corruption.

    Using a L1D cache write-back-invalidate operation before initiating the QDMA would prevent corruption for both instances.  However, there is something that I would consider:

    1. Advisory 1.1.2 only requires a cache write-back (no invalidate needed)
    2. Advisory 2.0.17 requires a cache write-back-invalidate

    Instead of a full cache write-back-invalidate before QDMA, you could use just a cache write-back for Advisory 1.1.2 and then use the compiler switch for Advisory 2.0.17.  This would save your application from all of the cache misses after the cache invalidate.

    -Tommy

  • 0 in reply to tlee
    Expert 2000 points

    Hi Tommy,

     

    thanks for your fast answers. As mentioned above, the buffer in L2 RAM which is filled by qdma is only read out by cpu but never modified. Additionally the buffer is aligned on a L1D cache line boundary and is a multiple of the L1D cache line size large. So there is no cache line sharing with other dirty lines. So advisory 1.1.2 doesn't apply to our application, right? As a workaround for advisory 2.0.17 I would use the compiler switch you mentioned.

    Thanks again

  • 0 in reply to Marc48067
    TI__Guru 62975 points

    Marc,

    That sounds right.

    -Tommy