AnsweredAssumed Answered

BF607 anomaly WA_16000042 seems not yet fixed in silicon revsion 0.2 

Question asked by robin.hu Employee on Aug 3, 2017
Latest reply on Sep 7, 2017 by Jithul_Janardhanan

I am using ADSP-BF607, the silcon revision marked on the chip is 0.2. I met an issue on ICACHE enabled in my project.

 

There was an anomaly associated on BF60x on L1 I-Cache with parity enabled, WA_16000042.

 

1. In anomaly_macros_rtl.h, it was said the anomaly was fixed in 0.2 silicon:

/*
** 16000042 : Instruction Cache Failure When Parity Is Enabled
**
** Impacted : ADSP-BF60[6789] revisions 0.0 and 0.1. Fixed in 0.2.
*/
#if !defined(WA_16000042)
#define WA_16000042 \
  (defined(__ADSPBF60x__) && defined(__SILICON_REVISION__) && \
   (__SILICON_REVISION__ == 0xffff || __SILICON_REVISION__ < 2))
#endif

 

2. When I troubleshot my project, without the walk-around of WA_16000042,  there was an error "parity error in L1 instruction bank C cache", as illustrated in attached JPG file; while if I enabled the walk-around of WA_16000042 by defined the silicon revision to "any" in CCES project option, my project ran without error.

in startup.s:

#if WA_16000005 || WA_16000042  /* L1 I-Cache with Parity Enabled anomalies. */
      // If L1 instruction cache is enabled, then disable L1 instruction
      // parity checking (IMEM_CONTROL.RDCHK).
      R0 = 59;              // cplb_ctrl = 59
      CC = BITTST(R0, CPLB_ENABLE_ICACHE_P);
      IF !CC JUMP .skip_disable_l1_instruction_parity;
      LOADIMM32REG(P2, IMEM_CONTROL)
      // P2 is MMR so anom 05000245 doesn't apply.
      .MESSAGE/SUPPRESS 5508 FOR 1 LINES;
      R0 = [P2];
      BITCLR( R0, BITP_IMEM_CONTROL_RDCHK);
      [P2] = R0;
      SSYNC;
      .skip_disable_l1_instruction_parity:
#endif /* WA_16000005  || WA_16000042 */

 

3. Can someone help confirm if the anomaly did fixed in silicon 0.2?

 

The project I am using is also attached and I am using CCES2.6.0.

Attachments

Outcomes