SPRZ536A september   2022  – june 2023 AM69 , AM69A , TDA4AH-Q1 , TDA4AP-Q1 , TDA4VH-Q1 , TDA4VP-Q1

 

  1.   1
  2. 1Modules Affected
  3. 2Nomenclature, Package Symbolization, and Revision Identification
    1. 2.1 Device and Development-Support Tool Nomenclature
    2. 2.2 Devices Supported
    3. 2.3 Package Symbolization and Revision Identification
  4. 3Silicon Revision 1.0 Usage Notes and Advisories
    1. 3.1 Silicon Revision 1.0 Usage Notes
      1.      i2134
    2. 3.2 Silicon Revision 1.0 Advisories
      1.      i2049
      2.      i2062
      3.      i2063
      4.      i2064
      5.      i2065
      6.      i2079
      7.      i2097
      8.      i2102
      9.      i2120
      10.      i2134
      11.      i2137
      12.      i2146
      13.      i2157
      14.      i2159
      15.      i2160
      16.      i2161
      17.      i2163
      18.      i2166
      19.      i2177
      20.      i2189
      21.      i2190
      22.      i2196
      23.      i2197
      24.      i2205
      25.      i2215
      26.      i2216
      27.      i2219
      28.      i2232
      29.      i2234
      30.      i2242
      31.      i2244
      32.      i2245
      33.      i2249
      34.      i2253
      35.      i2271
      36.      i2272
      37.      i2278
      38.      i2279
      39.      i2310
      40.      i2311
      41.      i2312
      42.      i2320
      43.      i2326
      44.      i2351
      45.      i2362
      46.      i2366
      47.      i2371
      48.      i2372
      49.      i2378
      50.      i2381
      51.      i2383
  5.   Trademarks
  6.   Revision History

i2272

C7x SE: SE Corrupting First End-of-Stream Reference After SEBRK With FILLVAL Enabled

Details

SE sends errors to the C7x CPU with accompanying zeroed out data. It zeroes out the data by de-asserting the clr_n pin of the interface-driving register for the data via a sticky "error is present to go to CPU" bit. After an SEBRK SE clears that error bit in preparation to send valid data again, but, in the case of SEBRK prematurely ending the stream, it ends up doing so after pushing the first end-of-stream reference to the interface.

Because of this, the first end-of-stream reference will be created with zeroed out data. When FILLVAL is enabled (set to non-zero fill mode), then that non-zero fill data is supposed to be sent after the end of the stream, but this bug corrupts it for the first reference by forcing the data to actual zero for a single cycle.

Workaround

There is no true workaround for this issue, but the scenario can be avoided by doing any of the following in a given stream:

Not using stream breaks that will end the stream prematurely

Not using end-of-stream references for computation

Specifically not using the first end-of-stream reference for computation

Not using the FILLVAL feature

This issue has been discussed with MMALIB/TIDL teams, who are currently the only users of the FILLVAL feature and the requestors to have it added for J7AEP and J7AHP. End-of-stream references are not utilized for computation, making this bug un-hittable, so performing an ECO to fix it is not currently planned.