PRIXP425BC Intel, PRIXP425BC Datasheet - Page 24

• Manufacturer Part Number: PRIXP425BC
• Description: IC NETWRK PROCESSR 400MHZ 492BGA
• Manufacturer: Intel

Specifications of PRIXP425BC

• Processor Type: Network
• Features: XScale Core
• Speed: 400MHz
• Voltage: 1.3V
• Mounting Type: Surface Mount
• Package / Case: 492-BGA
• Core Operating Frequency: 400MHz
• 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: Lead free / RoHS Compliant
• Other names: 869083

Non-Core Errata
17.
Problem:
Implication:
Workaround:
Status:
18.
Problem:
Implication:
Workaround:
Status:
19.
Problem:
24
Intel XScale
If an exception occurs in thumb mode and a non-branch instruction is executed at the corre-
sponding exception vector, that instruction may execute twice. Typically, instructions located at
exception vectors must be branch instructions that go to the appropriate handler, but the ARM
architecture
(0x0000001c/0xffff001c) without requiring a branch. Because of this condition, the first instruction
of such an FIQ handler may be executed twice if it is not a branch instruction.
Instruction may be executed twice if an exception occurs in thumb mode and if it is a non-branch
instruction.
If a no-op is placed at the beginning of the FIQ handler, the no-op will execute twice and no
incorrect behavior will result. If a branch instruction is placed at the beginning of the handler, it
will not be executed twice.
No
IRQ3 Is Locking the System ‘Disable’ (SCR 2143)
When performing bi-directional wire-speed bridging of 64-byte Ethernet packets — between both
NPE Ethernet ports using MontaVista* Linux Support Package (LSP) 3.0 and System Test code to
do the bridging — the IRQ for IxQMgr interrupts can be disabled by the kernel when it detects the
occurrence of more than 100,000 IxQMgr interrupts. This symptom occurs when the interrupt
source does not get cleared in time before the next interrupt occurs — causing the interrupt to
constantly trigger and overload the CPU with fake interrupt requests and “lock the system.”
The system gets locked because the IRQ is not getting cleared in time before the next interrupt
occurs.
Implement the following software routine to enforce a write completion by reading the very same
memory mapped register and forcing a data-dependency stall:
Be advised that this workaround requires Intel XScale core cycles, so should be done carefully.
No
EX_IOWAIT_N Timing (SCR 3051)
There are two problems with the functionality of the expansion bus IOWAIT protocol. If T2 and T3
are both programmed to be 0 (normal timing), the expansion bus controller will not extend the T3
data state as described in Figure 60 “Expansion Bus I/O Wait Operation” on page 303, of the Intel
IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor Developer’s
Manual. This occurs because there is a synchronizer on the EX_IOWAIT_N signal which causes
the expansion bus controller to transition to the T4 state before EX_IOWAIT_N is detected.
Additionally, the Intel
Processor Developer’s Manual states that the expansion bus controller will transition to the T4
state upon the de-assertion of EX_IOWAIT_N. The expansion bus controller does not do this —
instead waiting for the T3 count to expire before proceeding to T4. This issue also affects HRDY
signal for HPI mode.
mov r0, #regloc
str r1, [r0] @ initiate a write operation
ldr r1, [r0] @ read back: this will flush the write
mov r1,r1 @ stall: ensure the read is complete
Fix.
Fix.
Intel
®
IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor
allows
®
Core Non-Branch Instruction in Vector Table (SCR 2871)
®
the
IXP42X Product Line of Network Processors and IXC1100 Control Plane
FIQ
handler
to
be
placed
directly
at
the
FIQ
vector
®