GCIXP1200GA Intel, GCIXP1200GA Datasheet - Page 29

• Manufacturer Part Number: GCIXP1200GA
• Description: IC MPU NETWORK 166MHZ 432-BGA
• Manufacturer: Intel

Specifications of GCIXP1200GA

• Rohs Status: RoHS non-compliant
• Processor Type: Network
• Features: 32-bit StrongARM RISC Core
• Speed: 166MHz
• Voltage: 3.3V
• Mounting Type: Surface Mount
• Package / Case: 432-BGA
• Mounting: Surface Mount
• Operating Temperature (max): 70C
• Operating Temperature (min): 0C
• Operating Temperature Classification: Commercial
• Lead Free Status / Rohs Status: Not Compliant
• Other names: 839427

Workaround:
Status:
38.
Problem:
Implication:
Specification Update
2.1 The workaround is to precede all references to the IXP1200_PCI_REG_WRITE() macro with an
2.2 Optionally, a more global workaround which avoids coding each PCI_REG_READ() occurrence
2.
In a multiprocess system, however, the PCI CSR write/read combination may be interceded by an
interrupt which can cause a context switch; the new process may initiate PCI memory writes thus
possibly corrupting PCI CSR Registers. Workaround 1 above isn’t affected since it executes with
interrupts disabled.
However, there are two modules: ixp1200HPC.c and ixp1200IntrCtl.c, which use the macro
IXP1200_PCI_REG_WRITE().Two functions in ixp1200IntrCtl.c: ixp1200IntLvlEnable(),
ixp1200IntLvDisable(), for example, are called by the OS functions intEnable(), intDisable().
These can be called by user functions; if they are, the code needs to be modified to do intLock(),
PCI_REG_WRITE(), PCI_REG_READ(), intUnlock() sequences to avoid problems. Similarly
with code in ixp1200HPC.c.
intlock() function call and follow such references with an intUnlock() function call:
intLock();
PCI_REG_WRITE();
PCI_REG_READ();
intUnlock();
is to call taskSwitchHookAdd() with a pointer to a function that does a PCI_REG_READ(). This
function is called on every context switch and virtually guarantees that the PCI CSR is not left in an
indeterminate state. Care and good programming practice must be observed in calling complex
functions when interrupts and scheduling are disabled.
NoFix
SRAM[WRITE_UNLOCK,..., BURST_COUNT] Instruction
The SRAM[WRITE_UNLOCK,..., ref_cnt] optional_token(s) instruction does not work correctly
when ref_cnt > 1. Note that the command works correctly when the ref_cnt is equal to 1.
The SRAM[WRITE_UNLOCK,…,ref_cnt] command may not be completed by the SRAM unit
when the ref_cnt is greater than 1. Instead a different SRAM command may get executed twice.
This behavior is observed sporadically, when certain sequences of commands get queued to the
SRAM unit. Because the commands arrive at the SRAM unit from different Microengine threads, it
is impossible to determine if a software using this mode of command is prone to failure, or, when it
will fail. The exact symptoms observed by the user will depend on the system software design and
implementation.
For example, if the thread waits for the completion of the write_unlock command that gets dropped
(either using the ctx_swap optional token, or, the sig_done optional token and ctx_arb[SRAM]
command), then that thread will hang indefinitely. Further, the write to the memory location will
not complete leading to data corruption problems. And, because a different command gets executed
twice, two SRAM signals may be generated to a different thread, leading to improper program flow
and data corruption.
It is recommended that the software programs not use the SRAM[WRITE_UNLOCK,…,ref_cnt]
command with a ref_cnt > 1. If more than one long word needs to be written to memory, the
software should use the workarounds described below.
Intel
®
IXP1200 Network Processor
Errata
29