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

C6455 --c64p_dma_l1d_workaround, are there any other options available?

Harish Natarahjan
Prodigy 120 points

We recently ran into an errata that discusses L1-D cache. A workaround proposed is to use a compiler directive (--c64p_dma_l1d_workaround). I also saw some subsequent errata for C674x that provides a bunch of different solutions. One of them is to allocate L1 as cache and all of L2 as SRAM (the default configuration which is how our DSPs are configured as well). Does this workaround also apply to C64X+? 

 

The reason I ask is because I read notes stating that there might be some serious performance ramifications. If so, what are they and under what conditions would we experience it. In other words, is it better to stay away from this workaround if possible. Also, what is the eventual impact of this problem (I read one post that states that the issue will cause the DMA to be non-functional)?

 

Assuming that the only workaround available for C64X+ is the compiler option, would we still run into issues if there are libraries (for instance, libraries from third-party) are not compiled with the option turned on. What about the runtime libraries that TI itself provides. Are they created with this option turned on beginning with the tools version that supports this workaround or is that up to us to insure that? My tendency is to believe that we will minimize the probability of occurrence but not eradicate it (in the context of not turning on the option in libraries). What are our options in this scenario?

Your expedited answer to this question would be very much appreciated.

  • 0
    TI__Guru* 84110 points

    Harish,

    Our errata are very carefully presented to be both descriptive and as robust as possible. TI wants your application to work without problems, so when we find problems we work hard to find any acceptable ways to avoid those problems.

    In this case, we were able to solve this problem using a compiler switch. This is a very rare situation, in which a silicon problem can be solved with the compiler. I only recall it happening once before. In fact, I had to read this one twice to be sure it was not the same one.

    Since we only list this one workaround, this is the only workaround available. Any third party who supplies code that is intended to run on the C6455 should use this compiler switch to be compatible.

    Harish Natarahjan said:
    I also saw some subsequent errata for C674x that provides a bunch of different solutions. One of them is to allocate L1 as cache and all of L2 as SRAM (the default configuration which is how our DSPs are configured as well). Does this workaround also apply to C64X+?

    Only the errata listed in the C6455's errata document apply to the C6455. Errata are not listed for a core, such as the C64x+, but for a device, such as the C6455. If you see an erratum for the C6747, it might not apply to the C6748 or the C6455. You will find all known errata for each device in the errata document for that device.

    Harish Natarahjan said:
    The reason I ask is because I read notes stating that there might be some serious performance ramifications. If so, what are they and under what conditions would we experience it. In other words, is it better to stay away from this workaround if possible. Also, what is the eventual impact of this problem (I read one post that states that the issue will cause the DMA to be non-functional)?

    It is really not possible for us to comment on "I read notes stating ..." or an unnamed post. If you have specific references, we can see if there is a comment to offer. My reaction to both statements is that these do not sound like they would apply, but I cannot comment intelligently other than that.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 120 points

    Randy, thanks for the reply. I attached the note at the bottom (this was for 674x sent by Rupen P. to the folks in the Subscriber team in Florida).

    The intent of my original question was if this errata applied to us with the following configuration. L1D/P are assigned as CACHE (32K). L2 is all RAM. We do not have an L3/DDR2 external memory. In this configuration, does the errata apply to us. For the 6455 specifically, is it as simple as enabling this workaround if a portion of L1 -D is setup as cache or are there other considerations such as how L2 is setup and if L3/DDR2 is available to the CPU.

    Please let me know if there is more information that I can provide.

    Here is the original note I saw:

    "------------------------------------------------------------------------------
    FIXED  SDSCM00035330
    ------------------------------------------------------------------------------

    Summary            : Add compiler and assembler workaround to prevent 2 LDx
         instruction in a single cycle

    Fixed in           : 7.0.2
    Severity           : S1 - Critical / PS
    Affected Component : C/C++ Compiler (cl)

    Description: 
    Add option: 

    --c64p_dma_l1d_workaround 

    to workaround a cache corruption issue. This is to provide a software 
    solution for the FAE Alert titled "DMA Corruption of L1D Allocation".

    - This option will prevent the code generator from scheduling any loads
    in parallel (this includes the linear assembler).

    - This option will also be used to have the assembler issue non-fatal
    remarks when processing input assembly files. The assembler remark
    will
    read
    "REMARK at line xxx[R5003] DMA/L1D bug may be triggered by
    this execute packet."

    - The option will be ignored if compiling for non-Joule targets.

    There are no plans to deliver a runtime support library built with this
    option. We have identified 3 runtime library routines that have been
    implemented in assembly and contain parallel loads (setjmp.asm,
    memcpy64.asm, tdeh_uwentry_c6000.asm)

    It is expected that the use of this option may have a large negative
    impact on performance."

  • 0 in reply to Harish Natarahjan
    Prodigy 120 points

    Randy, I should have mentioned this as well:

     we have our DMA writing directly to/from  L2 to external device (FPGA) over EMIF. EMAC transfers data to/from L2 to the peripheral
  • 0 in reply to Harish Natarahjan
    TI__Genius 12595 points

     

    Hi Harish,

    If the L2 is configured as all SRAM then you will never be able to satisfy this condition because there will be no L2 cache:

                           

     

    This bug does not affect you.  You should be careful though, i.e. if someone changes the cache configuration in the future they may get smacked by this!

     

  • 0 in reply to Brad Caldwell
    TI__Guru* 84110 points

    Harish,

    It looks like Brad's post above has answered your question, and positively for what you wanted the answer to be. Do you agree?

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 120 points

    Randy, I agree. Thanks a lot. I verified the answer as well.