Quantcast
Channel: Forums - Recent Threads
Viewing all articles
Browse latest Browse all 262198

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

$
0
0

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.


Viewing all articles
Browse latest Browse all 262198

Trending Articles