GCIXP1200GB Intel, GCIXP1200GB Datasheet - Page 20

• Manufacturer Part Number: GCIXP1200GB
• Description: IC MPU NETWORK 200MHZ 432-BGA
• Manufacturer: Intel

Specifications of GCIXP1200GB

• Rohs Status: RoHS non-compliant
• Processor Type: Network
• Features: 32-bit StrongARM RISC Core
• Speed: 200MHz
• 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: 839428

Intel
Errata
31.
Problem:
Implication:
Workaround:
Status:
32.
Problem:
Implication:
Workaround:
20
®
IXP1200 Network Processor
Tval max Timing Issues When Running at 66 MHz for all PCI Signals
The PCI Local Bus Specification, Revision 2.2 specifies a maximum Signal Valid Delay (Tval)
time of 6.0ns in Section 7.6.4.2. The IXP1200 guarantees a worst-case Tval maximum of 6.5 ns.
The Tval maximum value of 6.5 ns requires a reduction in maximum flight time (Tprop) when
running at 66 MHz.
System designers must constrain their design to tighter than worst-case PCI timing. One recom-
mendation is to limit the trace length of the PCI bus resulting in a reduction of Tprop.
NoFix
Bit Test & Set and Bit Test & Clear SRAM Operations from the StrongARM* Core
StrongARM* core instructions that use the Bit Test & Set or the Bit Test & Clear SRAM address
ranges (0x1980 0000 - 0x19FF FFFF and 0x1900 0000 - 0x197F FFFF, respectively) do not return
correct data value in the SRAM_TEST_MOD register.
StrongARM* applications that share data structures with the Microengines cannot rely on the
SRAM Bit Test & Set and Bit Test & Clear operations to provide atomic access to those data
structures. When a StrongARM* application writes to an SRAM Bit Test & Set or Bit Test & Clear
address, the SRAM controller places the original test data value in the SRAM_TEST_MOD
register and modifies the contents of memory by setting or clearing the specified bits. The value in
the SRAM_TEST_MOD register is read by the application to determine the pre-modified state of
the specified bit(s). The bit setting and clearing works correctly, however, the SRAM controller
incorrectly returns invalid data in the SRAM_TEST_MOD register. This will create a state
whereby the application cannot determine if any of the specified bits were set or cleared.
With some source code changes, code that uses the Bit Test & Set or the Bit Test & Clear
operations can be modified as explained below to use SRAM Bit_set and Bit_clear operations as a
communication mechanism between the Microengines and StrongARM* application. This
alternate method does not require the use of the SRAM_TEST_MOD register. Note that this
workaround may incur additional SRAM reads from the StrongARM* core. Two bits are used for
the semaphore between the Microengines and StrongARM* core - one bit is used by the
Microengines to control semaphore ownership across Microengines and a second bit is used to
indicate a request from the StrongARM* application to acquire the semaphore.
In the example that follows, bit 0 is the test-and-set bit, used to arbitrate between the Microengine
threads, and bit 1 indicates the StrongARM* core wants to get ownership. At a high level, the four
operations are:
1. StrongARM* core takes semaphore:
2. StrongARM* core releases semaphore:
3. Microengine takes semaphore:
StrongARM* core sets StrongARM* core bit (0x0002). StrongARM* core polls, until word
== 0x0002 (i.e., the StrongARM* core requests the semaphore, and then it polls waiting for
any Microengine that has the semaphore to release it.)
StrongARM* core clears StrongARM* core bit (0x0002).
Start:
Microengine does test-and-set of bit 0 (0x0001)
Switch (test-and-set result data)
case 00: Microengine now has semaphore
Specification Update