GCIXP1200GB Intel, GCIXP1200GB Datasheet - Page 27

• 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

Status:
Specification Update
An alternative solution is to use some RW field that can be written to different values without
causing some other problem. At the beginning of the write/verify operation, read the register and
note the value of the chosen RW field. Create the write data with a different value for the RW field,
and the W1C bits set to 1. Test that the write happened or not by comparing only on the value of the
RW field, masking the W1C bit position(s).
For example, the Status Register (PCI_CMD_STAT) W1C bits are for PCI bus error conditions.
Normally, errors are rare so writing multiple times has a low risk of losing an error bit. If the
application does not use I/O space, then the I/O space enable bit [0] could be used.
In the StrongARM* core Control Register (SA_CONTROL), the W1C bit is for the PCI SERR
asserted error. This is normally used for severe errors, so should not occur frequently.
Doorbell (DOORBELL)
The Doorbell (DOORBELL) register is W1S. It is similar in intent to the use of W1C bits. Host and
the StrongARM* core use the bits to request and acknowledge service. Write/verify could lose an
interrupt as described above. Doing the write/verify atomically will be safe. The Host can not clear
the bit again until it sees it as set, which it won’t be able to do fast enough.
DMA Channel Control (CHAN_1_CONTROL, CHAN_2_CONTROL)
Each Channel Control Register has several status bits that are W1C, but more important is the side
effect of starting the channel by writing a 1 to the Enable bit. If the write/verify is done atomically,
the channel will not be able to complete quickly enough such that such that it completes (which
clears the Enable bit) before the read. An alternative is to use the method described under Status
register, and use one of the RW fields as an indicator for the write.
IRQ_ENABLE_SET, IRQ_ENABLE_CLEAR, FIQ_ENABLE_SET,
FIQ_ENABLE_CLEAR
These are W1S and W1C aliases for IRQ_Enable and FIQ_Enable. Doing the write/verify
atomically will be safe because the only thing that can change them is another thread of operation
in the StrongARM* core. Blocking interrupts during the write/verify will prevent that thread from
running. Note that the write is to the xxx_Enable_Set or xxx_Enable_Clear, and the read is from
xxx_Enable. Test only the bit(s) being changed to verify the write operation. For example, if the
operation is to Set bits, use the data of the write to mask the read bits, and verify that all of them are
'1'.
TIMER_1_CLEAR, TIMER_2_CLEAR, TIMER_3_CLEAR, TIMER_4_CLEAR
These registers are WO and each has the side effect of clearing the Timer interrupt. Because the
interrupt is set asynchronously (by the Timer), it is possible that a Timer interrupt could be lost.
This is the same problem described above under Status register. Doing the write/verify atomically
will minimize the probability of that case. There are no RW fields in this register to use the second
proposed workaround for Status register.
I2O Inbound Free List Count (I2O_INB_FLIST_CNT), I
(I2O_OUTB_PLIST_CNT), I
The side effect of a write to these registers is to modify the count by incrementing or decrementing
(based on which register), and discarding the write data. The counts are also modified by PCI bus
operations to the I
if it is correct, since a PCI operation might have modified it between the read/write/read.
MAILBOX_0, MAILBOX_1, MAILBOX_2, MAILBOX_3
The Mailbox registers are RW and have no side effects. The assumption made is that ownership of
each mailbox by either the StrongARM* core or PCI Host is either statically defined in the
application, or coordinated by some other means such as Doorbells.
Fixed
2
O addresses. Therefore, it is not possible to read the value after the write to see
2
O Inbound Post List Count (I2O_INB_PLIST_CNT)
2
Intel
O Outbound Post List Count
®
IXP1200 Network Processor
Errata
27