Section 1
Exceptions

1.1 Interrupts

• Routing of any PCI interrupt to any combination of from 1 to 4 CPUs.
• Assignment of the interrupt vector and threshold level to any PCI interrupt source.
• Assignment of the interrupt threshold level for each CPU.
• Handling of ISA interrupt by conventional means via cascaded 8259s mapped to a single interrupt input to MPIC. This combined interrupt is assigned a threshold level, a vector, and CPU routing attributes as needed.
• Implementation of CPU to CPU interrupts.
• Software control of soft reset to each CPU.
• Hardware and software control of hard reset to each CPU.
• Use of global timers to interrupt each CPU for SMP time sharing and other applications.

The MPIC chip referenced in this document is not currently generally available from IBM. The Verilog source of MPIC is available from IBM under license at no charge. Contact your IBM representative for details.

1.1.1 PCI interrupt handling

1. The PCI device asserts an interrupt to MPIC.
2. MPIC routes the interrupt to a CPU, based on the assigned attributes for that interrupt and the CPU.
3. The CPU receives the interrupt vector by reading a memory mapped MPIC register.
4. MPIC responds with the interrupt vector.

1.1.2 ISA interrupt handling

1. An ISA or X-Bus device asserts an ISA interrupt (to the ISA Bridge).
2. The cascaded 8259A controllers in the ISA bridge route the ISA interrupt to MPIC.
3. MPIC routes the interrupt to a CPU, based on the assigned attributes for that interrupt and the CPU.
4. The CPU receives the interrupt vector by reading a memory mapped MPIC register.
5. MPIC responds with the vector assigned to all ISA interrupts.
6. The CPU then performs a memory mapped read to BFFF FFF0, which causes the 660 Bridge to initiate a PCI interrupt acknowledge cycle.
7. The ISA bridge responds to this PCI cycle with the 8 bit ISA interrupt vector.

1.1.3 CPU to CPU Interrupt Handling

1.1.4 PCI Interrupt Assignments

Table 1. MPIC Interrupts
Number	TYPE	ASSIGNMENT OR CONNECTION
0	Level (Active High)	ISA Interrupts from PCI to ISA Bridge
1	Level (Active Low)	PCI Slot 2 (Upper) INTA,B,C,D
2	Level (Active Low)	PCI Slot 1 (Lower) INTA,B,C,D
3,4		Reserved (Should be masked)
5	Level (Active Low)	SCSI HDD
6	Level (Active Low)	Ethernet
7		Reserved (Should be masked)
8-15		Not Used (Should be masked)

1.1.5 ISA Interrupt Assignments

Table 2. ISA Interrupt Assignments
	IRQ	PRIORITY	ASSIGNMENT or CONNECTION
Master	0	1	Timer 1 Counter 0 (Internal to the ISA Bridge)
	1	2	Keyboard
	2	3-10	Cascade from Controller 2
	3	11	COM 2, COM 4, ISA Pin B25
	4	12	COM 1, COM 3, ISA Pin B24
	5	13	Parallel LPT 2,3, ISA Pin B21, Audio (note 2)
	6	14	Floppy Disk, ISA Pin B23
	7	15	Parallel LPT 1,2, ISA Pin B21, Audio (note 2)
Slave	8#	3	Time of Day (aka RTC)
	9	4	ISA pin B04, Audio (note 2)
	10	5	ISA pin D03
	11	6	ISA pin D04, Audio (note 2)
	12/M	7	Mouse, ISA pin D05
	13#	8	DMA Scatter/Gather completion (programmable)
	14	9	ISA pin D07, Audio (note 2)
	15	10	ISA pin D06
Notes: Note 1) IRQ10 and IRQ15 are available for ISA option cards. Also, either IRQ5 or IRQ7 can be used for ISA option cards, depending on which IRQ line the parallel port and the Audio controller are configured to use. IRQ9, IRQ11, and IRQ14 can be used for ISA option cards, depending on which IRQ lines the Audio controller is configured to use. IRQ0, IRQ1, IRQ2, IRQ8 and IRQ13 are not connected to the ISA slots. IRQ3, IRQ4, IRQ6, and IRQ12 are connected to motherboard devices and should not be used by ISA option cards. These IRQs are wired to the ISA option slots so that cards may detect, by sensing low levels, that they are used . Note 2) IRQ5, IRQ7, IRQ9, IRQ11, IRQ12, and IRQ14 are available to the Audio subsystem. Enabling these interrupts can be done inside the Crystal CS4232 controller. The interrupts are connected to the system as follows: CS4232 IRQ System IRQ A 5 B 7 C 9 D 11 E 12 F 14

1.1.5.1 Scatter/Gather (SG) Interrupts

Scatter/gather (SG) DMA support can use either IRQ13 or end of process (EOP) to indicate to the system that the SG sequence has been completed by the DMA controller. The use of EOP is recommended, since IRQ13 can be used by other ISA devices. The EOP signal from the ISA bridge generates the Terminal Count (ISA_TC) signal on the ISA bus.

IRQ13 can be connected optionally to the SCSI INT output on the motherboard to assist in the development of software that uses drivers which do expect an ISA-based HDD interrupt, and which do not support MPIC interrupts.

1.1.6 SCSI Bus Interrupts

1.1.7 MCP# Considerations

1.1.8 SMI# Considerations

1.2 Resets

1.2.1 HRESET# Logic

1. POWER_GOOD. When a power supply out-of-regulation condition is signaled by a low on POWER_GOOD from the power supply, the logic generates a hard reset to each CPU and to the motherboard devices.
2. CPU Enable Register. As detailed in the I/O Subsystems section, a CPU-specific hard reset or system reset is generated by using the system EPLD CPU Enable Register (Port 871) and the HRESET PAL.
3. RESET Jumper. When pins 1 and 2 of the RESET jumper J38 are shorted together, the logic generates a hard reset to each CPU and to the motherboard devices.
4. RISCWatch Reset. The ESP connector J18 allows the use of the RISCWatch tool, which is a JTAG-based debugging system. This tool requires the ability to initiate and hold all CPUs in the system in hard reset. When the RISCWatch asserts HRESET_ESP#, the HRESET PAL generates a hard reset to each CPU. The motherboard devices are not reset.

1.2.1.1 JTAG Interface Hard Resets

The JTAG interface with the 604 CPU(s) must be held in reset while HRESET# is active. The HRESET PAL supplies the TRST_CPU1# signal to reset the JTAG interface with the CPU(s) in CPU slot 1, and supplies the TRST_CPU2# signal to reset the JTAG interface of the CPU(s) in CPU slot 2.

TRST_CPU1# is asserted whenever HRESET_CPU1A# or HRESET_CPU1B# is asserted, and TRST_CPU2# is asserted whenever either of the HRESET#s for that CPU slot is asserted.

The reference design also asserts both TRST# signals while the RISCWatch interface is asserting OCS_OVRIDE.

1.2.1.2 HRESET PAL Equations

TITLE Hard-Reset Logic
PATTERN hrst2.pds
REVISION 0
COMPANY IBM
DATE 05/17/95 05:45pm
CHIP hreset PAL16L8

;-------------------- PIN Declarations -------------- 20plcc PIN

;PIN NC ; INPUT 1
;PIN NC ; INPUT 2
PIN 3 CKST_P2_ ; INPUT 3
PIN 4 CKST_P1_ ; INPUT 4
PIN 5 KSRS_P1A_ ; INPUT 5
PIN 6 KSRS_P1B_ ; INPUT 6
PIN 7 KSRS_P2A_ ; INPUT 7
PIN 8 KSRS_P2B_ ; INPUT 8
PIN 9 OCS_OVRIDE ; INPUT 9
;PIN NC ; gnd 10
PIN 11 HRST_ESP_ ; INPUT 11



PIN 12 CKST_ESP_ COMBINATORIAL ; OUTPUT 12
PIN 13 HRST_P1A_ COMBINATORIAL ; OUTPUT 13
PIN 14 HRST_P1B_ COMBINATORIAL ; OUTPUT 14
PIN 15 HRST_P2A_ COMBINATORIAL ; OUTPUT 15
PIN 16 HRST_P2B_ COMBINATORIAL ; OUTPUT 16
PIN 17 TRST_P1_ COMBINATORIAL ; OUTPUT 17
PIN 18 TRST_P2_ COMBINATORIAL ; OUTPUT 18
;PIN NC ; INPUT 19
;PIN NC ; vcc 20

;------------ Boolean Equation Segment ------

/CKST_ESP_ = /CKST_P1_ * /CKST_P2_

/HRST_P1A_ = /HRST_ESP_ + /KSRS_P1A_

/HRST_P1B_ = /HRST_ESP_ + /KSRS_P1B_

/HRST_P2A_ = /HRST_ESP_ + /KSRS_P2A_

/HRST_P2B_ = /HRST_ESP_ + /KSRS_P2B_

/TRST_P1_ = /OCS_OVRIDE + /KSRS_P1A_

/TRST_P2_ = /OCS_OVRIDE + /KSRS_P2A_

1.2.2 SRESET Logic

The reference design uses the circuit shown in Figure 4 to generate the SRESET# signals to the CPUs. There are three methods of generating an SRESET# to an individual CPU. Two of the three are not CPU specific and will generate an SRESET# to all of the CPUs. Note that none of these methods will reset either the motherboard devices or any power management controller which may be in the system.

• RISCWatch Reset. The ESP connector, J18, allows the use of the RISCWatch tool, which is a JTAG-based debugging system. This tool requires the ability to issue SRESET# to all CPUs in the system. When the RISCWatch asserts SRESET_ESP#, the SRESET PAL generates a soft reset to each CPU (by sending each SRESET# low). Note that while SRESET_ESP# is active, soft resets from other sources will be masked and not stored. It is, therefore, important to deactivate SRESET_ESP# once the CPUs have been reset.
• Port 92. When a 1 is written to bit 0 of port 92, the ISA bridge generates a low pulse to the SRESET PAL, which in turn pulses each SRESET# low.
• CPU Init Register. As detailed in the MPIC data sheet (see the Data Sheets section), a CPU-specific soft reset can be generated by using the memory-mapped MPIC INIT register to assert INIT_CPU_x_MPIC#. (Note: The SRESET# is a negative-edge-triggered signal.) The best way to do this is to first write a 0 (to send INIT_CPU_x_MPIC# high) then a 1 (to send it back low). The first write may or may not effect a change in the state of the SRESET#, but the second write will send the SRESET# low. Sending the INIT_CPU_x_MPIC# back high (to restore it) can be done either by the SRESET# service routine, or as above.

Figure 4 shows certain signals that are physically present on the motherboard but are not supported. These signals are subject to change or elimination from the reference design at any time. Each CPU slot is shown with reset support for two CPUs per slot; however, SRESET_CPU1B# and SRESET_CPU2B# are unsupported signals.

1.2.3 SRESET PAL equations

;------------------------ PIN Declarations --------- 20plcc PIN
PIN 1 SRS_ESP_ ; INPUT 1
PIN 2 SRS_PORT92 ; INPUT 2
PIN 3 INIT_P1A_MPIC_ ; INPUT 3
PIN 4 INIT_P1B_MPIC_ ; INPUT 4
PIN 5 INIT_P2A_MPIC_ ; INPUT 5
PIN 6 INIT_P2B_MPIC_ ; INPUT 6
PIN 7 HLTQ_P1A ; INPUT 7
PIN 8 HLTQ_P1B ; INPUT 8
PIN 9 HLTQ_P2A ; INPUT 9
;PIN NC ; gnd 10
PIN 11 HLTQ_P2B ; INPUT 11
PIN 12 RUNH_ESP COMBINATORIAL ; OUTPUT 12
PIN 13 SRS_P1A_ COMBINATORIAL ; OUTPUT 13
PIN 14 SRS_P1B_ COMBINATORIAL ; OUTPUT 14
PIN 15 SRS_P2A_ COMBINATORIAL ; OUTPUT 15
PIN 16 SRS_P2B_ COMBINATORIAL ; OUTPUT 16
PIN 17 HALT_P1 COMBINATORIAL ; OUTPUT 17
PIN 18 HALT_P2 COMBINATORIAL ; OUTPUT 18
;PIN NC ; INPUT 19
;PIN NC ; vcc 20
;
;
;
;----------------------- Boolean Equation Segment ------
;
; Enable edge sensitive Sreset on MPIC output. SRESET from ISA ; bridge is assumed to be a negative pulse.
;

EQUATIONS

/SRS_P1A_ = /SRS_ESP_ + /(/SRS_PORT92 :+: INIT_P1A_MPIC_)

/SRS_P1B_ = /SRS_ESP_ + /(/SRS_PORT92 :+: INIT_P1B_MPIC_)

/SRS_P2A_ = /SRS_ESP_ + /(/SRS_PORT92 :+: INIT_P2A_MPIC_)

/SRS_P2B_ = /SRS_ESP_ + /(/SRS_PORT92 :+: INIT_P2B_MPIC_)
;
; Halt outputs are active high when both halt inputs are high
;

/HALT_P1 = /HLTQ_P1A + /HLTQ_P1B

/HALT_P2 = /HLTQ_P2A + /HLTQ_P2B

/RUNH_ESP = HLTQ_P1A * HLTQ_P1B * HLTQ_P2A * HLTQ_P2B

1.3 SMP Reset Considerations

1.3.1 Hard Reset

Booting an SMP system is more complex than booting a uniprocessor system, and has the following additional requirements:

• Each processor must have a unique identification number stored in its Processor Identification Register (PIR).
• A single processor must assume control of the boot process. All other processors must be placed in a harmless state until the operating system restarts them.
  

1. After hard reset, one processor is selected as the master for the first phase of booting. All other processors are disabled. The initial master does some minimal system initialization (memory and ISA bridge) then begins resetting each processor slot in sequence until a processor is reset.

2. Upon being reset, each processor does some processor-specific initialization, tries to reset the next available processor, and then waits until all processors have been reset.

3. After all processors have been reset, the lowest numbered processor becomes the system master and proceeds with the remainder of the system initialization sequence. All other processors are placed in a loop, waiting for a memory flag to be set, after which they will branch to an address contained in a predetermined memory location.

1.3.1.1 Hard Reset Phase 1

A processor enters Hard Reset Phase 1 if it is executing instructions out of ROM (address 0xFFF00100) and if bit 15 of the HID0 register is 0. This bit is guaranteed to be a zero after the assertion of the processor's HRESET input.

HID0:15 is set to 1 so that subsequent execution from 0xFFF00100 will be correctly interpreted as a Soft Reset.

Each processor reads the System Control Register (0x8000081C). The first processor to read this register will read a 0 in the FirstRead# bit (D0). All other processors will read a 1.

The processor that reads the 0 becomes the master for the remainder of this phase of the boot process. All other processors set their MSR:IP to 0 so that on a subsequent soft reset they will begin executing out of RAM at address 0x00000100. They then begin looping until they are reset.

The Phase 1 master does some minimal system initialization (SIO, memory, &etc.) and copies the firmware image from ROM address 0xFFF00000 to RAM address 0x00000000.

The Phase 1 master sets its MSR:IP to 0 and uses the MPIC Processor Init Register to issue a Soft Reset to processor 0. Three possibilities now exist:

1. If Processor 0 was the Phase 1 master, then it has just reset itself and enters Hard Reset Phase 2, described below.

2. If Processor 0 was not the Phase 1 master, then the Phase 1 master waits up to 10ms for processor 0 to set a flag indicating that it has been successfully reset. If processor 0 has been reset, then the Phase 1 master spins in a loop until it is reset.

3. If Processor 0 was not reset, then the Phase 1 master increments the CPU sequence register by reading it and discarding the result. This ensures that the number returned by the CPU Sequence register is in sync with the number of the processor currently being reset. The Phase 1 master then tries to reset processor 1, and repeats this process until a processor is successfully reset.

1.3.1.2 Hard Reset Phase 2

A processor enters Hard Reset Phase 2 if it is executing instructions out of RAM at address 0x00000100.

Upon entering Hard Reset Phase 2, each processor sets a bit in a processor reset table to indicate that it has been reset.

The processor then reads a Proccessor ID number (PID) from the CPU Sequence Register and stores the result into its Processor Identification Register (PIR).

The processor then tries to reset the next processor, using the same procedure used in Hard Reset Phase 1.

If a subsequent processor cannot be reset, then the current processor sets the LAST_PROC_RESET flag to indicate that the last processor has been reset. If a subsequent processor is reset, then the current processor waits for the LAST_PROC_RESET flag to be set.

1.3.1.3 Hard Reset Phase 3

After all processors have been reset, the processor with the lowest Processor ID number becomes the system master for the remainder of the boot process. All other processors loop, waiting until the MEMORY_TEST_COMPLETE flag is set (which indicates that the system memory test is complete).

Then the system master initializes the rest of the system hardware.

After the system memory has been tested, the system master sets the MEMORY_TEST_COMPLETE flag, which releases all other processors from their polling loop. These other processors then begin polling a field in the residual data structure.

The system master loads the operating system loader from the selected boot device and transfers control to it.

The operating system now has control of the system. When it wants to start up the other processors, it uses two fields in the residual data structure, which is passed by the firmware. Residual.VitalProductData.SmpIar is loaded with the address that the second processor should branch to. The appropriate Residual.Cpus[].CpuState field is set to CPU_GOOD. The second processor, upon seeing CPU_GOOD in the CpuState field, branches to the address stored in the SmpIar field.

1.3.2 Soft Reset

A processor enters Soft Reset phase if it is executing instructions from ROM address 0xFFF00100 and HID0:15 = 1. This can happen either by branching to address 0xFFF00100 or by setting MSR:IP = 1 and issuing a SRESET to the processor. The SRESET Logic subsection describes how SRESET is generated.

Upon entering Soft Reset phase, a processor writes the value 0x00 to the CPU Enable Register (Port 871). This causes a Hard Reset to be generated, which resets all system hardware and causes all processors to enter Hard Reset Phase 1.

1.4 Error Handling

1.4.1 Data Error Checking

For each memory read operation, eight bytes of memory are read, and parity on eight bytes is checked regardless of the transfer size; therefore, all memory must be initialized (at least up to the end of any cache line that can be accessed).

The reference design does not generate or check CPU bus address parity.

1.4.1.1 CPU to Memory Writes

During CPU to memory writes, the CPU drives data parity information onto the CPU data bus. Correct parity is then generated in the 660 and written to DRAM memory along with the data. The L2 SRAM is updated (when required) with the data and the parity information that the CPU drove onto the CPU data bus.

During CPU to memory writes, the 660 Bridge checks the data parity sourced by the CPU, and normally reports any detected parity errors via TEA#.

1.4.1.2 CPU to Memory Reads

When the CPU reads from memory, the data and accompanying parity information can come from either the L2 SRAM or from DRAM memory. If the data is sourced from the L2, the parity information also comes from the L2.

If the data is sourced by memory, the parity information also comes from memory. The L2 SRAM is updated (when required) using the data and parity from memory.

During CPU to memory reads, the 660 Bridge samples the DPE# output of the CPU to determine parity errors, and reports them back to the CPU via MCP#. The particular memory read data beat will be terminated normally with TA#.

1.4.1.3 PCI to Memory Parity Errors

During PCI to memory writes, the 660 Bridge generates the data parity that is written into DRAM memory. The 660 Bridge also checks the parity of the data and asserts PCI_PERR# if it detects a data parity error.

During PCI-to-memory reads, the 660 Bridge checks the parity of the memory data, and then generates the data parity that is driven onto the PCI bus. If there is a parity error in the data/parity returned to the 660 Bridge from the DRAM, the bridge drives PCI_PAR incorrectly to propagate the parity error (and also reports the error to the CPU via MCP#). The data beat with the bad parity is not target aborted because doing so would slow all data beats for one PCI clock (TRDY# is generated before the data is known good); however, if the agent is bursting and there is another transfer in the burst, the next cycle is stopped with target abort protocol.

During PCI to memory reads, the 660 Bridge also samples the PCI_PERR# signal, which other agents can be programmed to activate when they detect a PCI parity error.

1.4.1.4 CPU to PCI Transaction Data Parity Errors

During CPU to PCI writes, the 660 Bridge sources the PCI parity information, and monitors PCI_PERR#, which other agents can be programmed to activate when they detect a PCI parity error.

During CPU to PCI reads, the 660 Bridge checks the data parity and asserts PCI_PERR# if it detects a data parity error.

1.4.2 Illegal CPU cycles

1.4.3 SERR, I/O Channel Check, and NMI Logic

No address is associated with this type of error; therefore, the contents of the error address register are not defined.

1.4.4 Out of Bounds PCI Memory Accesses

1.4.5 No Response on CPU to PCI Cycles - Master Abort

The 660 Bridge also checks for bus hung conditions. If a CPU to PCI cycle does not terminate within approximately 60 usec after the PCI is owned by the CPU, the cycle is terminated with TEA#. This is true for all CPU to PCI transaction types except configuration transactions. This feature may be disabled via a 660 Bridge control register.

In the case of configuration cycles that do not receive a DEVSEL# (no device present at that address), the PCI cycle is master aborted, and TA# (normal response) is returned. Write data is thrown away and all 1's are returned on read cycles. No error register is set and no address is captured in the error address register.

1.4.6 CPU to PCI Cycles That Are Target Aborted

1.4.7 Error Status Registers

1.4.8 Reporting Error Addresses

See the System Error Address BCR information in the Bridge Control Registers section of The IBM27-82660 PowerPC to PCI Bridge User's Manual for more information.

1.4.9 Errant Masters

1.4.10 Special Events Not Reported as Errors

• A PCI to memory cycle at any memory address above that programmed into the top of memory register.

• CPU to PCI configuration cycles to which no device responds with a DEVSEL# signal within 8 clocks (no device at this address).

• A CPU read of the IACK address having a transfer size other than 1, or having other than 4-byte alignment.

• A read of the IACK address when no interrupt is pending.

• Parity error in Flash/ROM.

• Write to Flash with TSIZ other than 4.

• Caching ROM space.

• Running any cycle to the PCI configuration space with an undefined address.

• Accessing any ISA device with the wrong data size for that device.