FW82371EB Intel, FW82371EB Datasheet - Page 39

• Manufacturer Part Number: FW82371EB
• Manufacturer: Intel

Specifications of FW82371EB

• Lead Free Status / RoHS Status: Not Compliant

25.
26.
Specification Update
Interrupt De-assertion (only .35u process device)
R
SLP# Connectivity in Multi-processor Systems
For multi-processor systems using the PiiX4/PiiX4E, the SLP# signal may be asserted to one of the
processors before it is in a processor sleep state 3, and therefore not yet acknowledged. This could result
in a wakeup problem.
Specifically, For PiiX4/PiiX4E based platforms, STPCLK# from the PiiX4E is connected to all
processors, and SLP# from the PiiX4E is connected to all processors. The following sequence occurs:
While this sequence works for uni-processor systems, processors are put into Processor Sleep State 3,
not State 5, during ACPI S1 state. This means that the SLP# signal must not be connected to any
processor in multi-processor systems.
Note that disabling the SLEEP_EN bit in the PiiX4E Processor Control register is not an accecptable
workaround for this issue since this bit only controls SLP# assertion in C3 state, not in S1 state.
The PiiX4E has transitioned to a smaller and faster manufacturing process (.35u process). The result of
this transition is largely transparent for the majority of operations, however an exception has been
identified for some operating systems, most notably OS/2.
This issue is seen when a system is configured in Virtual Wire mode where 8259 generated interrupts are
delivered through the IO APIC which is configured for edge triggered interrupts on its inputs. This issue
could also manifest itself in other modes such as PIC mode or uni-processor mode where the PiiX4E
interrupt output goes directly to the CPU, or to intermediarycircuitry which may also miss the short de-
assertion pulse described below. Please consult the Microprocessor Specification v1.4 available on
developer.intel.com for details on these operating modes.
A high priority interrupt occuring just as the PiiX4E receives INTACK for a preceding low priority
interrupt can cause a small interrupt de-assertion time from the new PiiX4E (.35u) which can be missed
at either the IO APIC or the processor, depending on configuration, and likely cause a system hang. The
interrupt de-assertion time as specified for the original 8259 interrupt controller is a variable value, and
the PiiX4E was designed to meet this specification and does. However on the old PiiX4E (.6u), the
interrupt de-assertion time was on the order of 100nS, where on the new PiiX4E this time can be as short
as 3nS for the above described condition. While this still meets the original 8259 interrupt controller
specification, it does not meet the interrupt input minimum de-assertion time requirements for the IO
APIC or the Pentium ®-II, Pentium-III, Pentium-II Xeon, and Pentium-III Xeon processors (please refer
to respective data sheets for these specifications). As the LINT[1:0] inputs at the processor are also
configuration pins at reset, the interrupt signal is often routed through configuration circuitry first, and
then to the processor. On some system designs, it has also been identified that the short de-assertion
pulse never makes it through this circuitry, which may also require detection of the short de-assertion
edge, and subsequent pulse stretching circuitry to meet minimum de-assertion time for the CPU.
1) OS writes to PMCNTRL register
2) PiiX4E asserts STPCLK#, then waits for Stop Grant
3) The processor acknowledges with a Stop Grant Acknowledge
4) PiiX4E asserts SLP# after receiving Stop Grant Acknowledge
Intel
®
82371EB (PIIX4E)
39