QG80331M500SL9BE Datasheet, PDF (43/67 Pages) Intel Corporation – Intel 80331 I/O Processor Specification Update

Core Errata
Intel^® 80331 I/O Processor
Core Errata
1.
Problem:
Workaround:
Status:
Abort is missed when lock command is outstanding
A bus abort occurs on a code fetch, while an instruction TLB or I-Cache lock MCR, Move to
Coprocessor from ARM Register, command is outstanding. The core fails to abort, instead
executing the instruction returned on the aborting transaction. Parity errors are not affected. The
bus abort may be due to either an abort pin assertion or a multi-bit ECC error.
Branch flush after every I-TLB or I-Cache lock. For example, the following instruction does this:
SUB PC, PC #4;flush the pipe.
No Fix. See the Table , “Summary Table of Changes” on page 9.
2.
Problem:
Workaround:
Status:
Aborted Store that Hits the Data Cache May Mark Write-Back Data as Dirty
When there is an aborted store that hits clean data in the data cache (data in an aligned four word
range that has not been modified from the core since it was last loaded in from memory or cleaned),
the data in the array is not modified (the store is blocked), but the dirty bit is set. When the line is
then aged out of the data cache or explicitly cleaned, the data in that four word range is evicted to
external memory, even though it has never been changed. In normal operation this is nothing more
than an extra store on the bus that writes the same data to memory that is already there.
Here is the boundary condition where this might be visible:
1. A cache line is loaded into the cache at address A.
2. Another master externally modifies address A.
3. A core store instruction attempts to modify A, hits the cache, aborts because of MMU
permissions, and is backed out of the cache. That line normally is not marked dirty, but
because of this errata is marked as dirty.
4. The cache line at A then ages out or is explicitly cleaned. The original data from location A is
evicted to external memory, overwriting the data written by the external master. This only
happens when software is allowing an external master to modify memory that is, write-back or
write-allocate in the core page tables, and depending on the fact that the data is not 'dirty' in the
cache, to preclude the cached version from overwriting the external memory version. When
there are any semaphores or any other handshaking to prevent collisions on shared memory,
this is not a problem.
For this shared memory region, mark it as write-through memory in the core page table. This
prevents the data from ever being written out as dirty.
No Fix. See the Table , “Summary Table of Changes” on page 9.
Specification Update
43