Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Generation of Acknowledgment from Power2* Super Chip for Input/Output Exception Cycles

IP.com Disclosure Number: IPCOM000118399D
Original Publication Date: 1997-Jan-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 153K

Publishing Venue

IBM

Related People

Griffith Jr, TW: AUTHOR [+2]

Abstract

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 39% of the total text.

Generation of Acknowledgment from Power2* Super Chip for Input/Output
Exception Cycles

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.

      The RISC 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.

      Note that, 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
System.

      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:

      As mentioned 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.

      To clearly understand why the above solution does not pose any
data integrity problems, it is ne...