FWIXP422BB Intel, FWIXP422BB Datasheet - Page 30

• Manufacturer Part Number: FWIXP422BB
• Description: IC NETWRK PROCESSR 266MHZ 492BGA
• Manufacturer: Intel

Specifications of FWIXP422BB

• Processor Type: Network
• Features: XScale Core
• Speed: 266MHz
• Voltage: 1.3V
• Mounting Type: Surface Mount
• Package / Case: 492-BGA
• Core Operating Frequency: 266MHz
• Package Type: BGA
• Pin Count: 492
• Mounting: Surface Mount
• Operating Temperature (max): 70C
• Operating Temperature (min): 0C
• Operating Temperature Classification: Commercial
• Lead Free Status / RoHS Status: Contains lead / RoHS non-compliant
• Other names: 852276

Core Errata
Core Errata
1.
Problem:
Workaround:
Status:
2.
Problem:
Workaround:
Status:
3.
Problem:
30
Abort is Missed When Lock Command is Outstanding
A bus abort occurs on a code fetch while an instruction TLB or I-Cache lock Move to Coprocessor
from XScale core Register (MCR) command is outstanding. The core fails to abort and instead
executes the instruction returned on the aborting transaction. Parity errors are not affected. The bus
abort may be due to an abort pin assertion.
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
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 4-word
range that has not been modified from the core since it was last loaded 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 4-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.
The boundary condition where this might occur:
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
Performance Monitor Unit Event 0x1 Can Be Incremented
Erroneously by Unrelated Events
Event 0x1 in the performance monitor unit (PMU) can be used to count cycles in which the
instruction cache cannot deliver an instruction. The only cycles counted should be those due to an
instruction cache miss or an instruction TLB miss. The following unrelated events in the core also
cause the corresponding count to increment when event number 0x1 is being monitored:
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
4. The cache line at A then ages out or is explicitly cleaned. The original data from location A is
•
•
Fix.
Fix.
permissions, and is backed out of the cache. That line normally is not marked dirty, but
because of this errata, is marked as dirty.
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.
Any architectural event (for example, IRQ, data abort).
MSR instructions that alter the CPSR control bits.
Intel
®
IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor