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.

RTOS/66AK2G12: Clarification of K2G errata and PDK workarounds

Part Number: 66AK2G12

Tool/software: TI-RTOS

Perusing pdk_k2g_1_0_9, there is a lot of source that is irrelevant to the K2G processor and gets preprocessed out.  However, there is also some code that does get compiled that seems unrelated.  In particular, pdk_k2g_1_0_9/packages/ti/csl/csl_cacheAux.h CACHE_invL1d et al contain several workarounds-- disabling interrupts for the duration of the invalidation, explicit invalidation of the prefetch buffer, a second mfence operation-- with little description other than "advisory 6".  There is no advisory 6 in the K2G errata.  I found no advisory 6 on ti.com, but I did find advisories 9 and 13 for the C665x which matches the workarounds.

Please clarify-- are these workarounds are unnecessary for the K2G (ie, should they have been guarded by preprocessor conditions)?  

Are there other workarounds in the K2G PDK that are unnecessary on the K2G?

Thank you

  • Hi,

    All the necessary erratas should be implemented in the Processor SDK RTOS (or linux for that matter).
    The reason you see an unrelated code is because the source code for all Keystone I and Keystone II devices is common (in this particular case the CSL package is common) and that is why you get compiled only the source files relevant for the K2G and the others are processed out.

    In this particular case, it seems that the cache invalidation procedure is similar for all dsps.

    Best Regards,
    Yordan
  • Yordan Kovachev said:
    In this particular case, it seems that the cache invalidation procedure is similar for all dsps.

    Just to be clear-- you're saying that the disabling of interrupts and the double mfence are necessary for all DSPs (ie, that the errata for K2G and probably other DSPs should to be updated)?

  • No, I am not saying that this is an errata.

    I've notified the C66x experts to elaborate on this.

    Best Regards,
    Yordan
  • Hi,

    I looked at Keystone II Errata for K2H, K2E and K2G, and don't see the erratas about those. As explained by Yordan, the C66x cache source code for all Keystone I and Keystone II devices is common, the errata may affects for some Keystone I devices or certain PG versions. We put software workaround based on the errata document and don't release different codes based on the silicon revisions.

    This is the CSL code that all of our top level driver and application software tested. Certainly, those software workaround takes additional cycles. If you don't come into a situation of cycle critical, it is advised to keep those workaround code.

    Regards, Eric