Generation of Acknowledgment from Power2* Super Chip for Input/Output Exception Cycles
Original Publication Date: 1997-Jan-01
Included in the Prior Art Database: 2005-Apr-01
Griffith Jr, TW: AUTHOR [+1]
Figure DAT_VAL low with control bus bits (0..7) at x 'C0' indicate an "I/O Exception Reply Cycle". The system expects an ACK during the second cycle after the exception reply.
Generation of Acknowledgment from Power2* Super Chip for
Figure DAT_VAL low
with control bus bits (0..7) at x 'C0' indicate
an "I/O Exception Reply Cycle". The system expects an ACK during the
second cycle after the exception reply.
System/6000* Model 595 is a high-end, uniprocessor,
desk side server of the RISC System/6000* product line and is a
derivative of and successor to the Model 591.
On this Model
595, which is based on the Power2* Super Chip
(P2SC), single chip, 32 bit microprocessor, a problem occurs during
Input/Output (I/O) Exception cycles. During these cycles, the P2SC
fails to acknowledge a load Data Storage Interrupt (DSI) from the
Extended I/O chip (X/O). This happens in 2 to 1 mode and causes a
Checkstop Condition, forcing the System to a complete halt.
In the Model
595, the System I/O Bus (SIO Bus) and the Memory
Bus have been designed to run at half the Processor Speed (2 to 1
Mode). Under these conditions, when the System is doing a data load
from I/O Space and there is no adapter present, the XIO signals a DSI
to the Processor. The DSI software handler determines what happened
and causes the System to respond correctly to the interrupt, but the
P2SC does not respond correctly to the DSI Request from the XIO and
does not generate an Acknowledge to this request, causing an XIO
Checkstop, which in turn is fatal to the System, causing it to halt.
this is a Special Exception and is only seen during
AIX* Device Configuration time and does not occur during Normal
System Operation. During the Normal Case, P2SC responds correctly
with an Acknowledge to any request from the XIO.
There are two
possible solutions to this problem, but only one
of these solutions is customer shippable. The other is a useful
workaround, but only during the laboratory testing phase for the
One of these
solutions involves ignoring all XIO checkstops and
proving that without this checkstop detection logic enabled the
System will still be able to detect failures on the SIO bus. This is
a feasible solution but not totally error proof. The second solution
is customer shippable, as it addresses the real problem caused by the
P2SC, and allows the System to function exactly as designed. Details
of the two proposed solutions are as follows:
earlier, the first solution involves the Disabling
of the XIO Checkstop logic in the XIO. This can be done via a
microcode change in the On Chip Sequencer (OCS), a microcontroller on
the Planar, that is used to perform BIST on all the Modules present
on the CPU Planar. This is not a customer shippable solution, but
there are no data integrity problems associated with it. Therefore,
it can be used as an Engineering solution for test purposes.
understand why the above solution does not pose any
data integrity problems, it is ne...