82801BA Datasheet, PDF (64/498 Pages) Intel Corporation – Intel 82801BA I/O Controller Hub 2 (ICH2) and Intel 82801BAM I/O Controller Hub 2 Mobile

Functional Description
Note:
If the processor issues a locked cycle to a resource that is too slow (e.g., PCI), the ICH2 will not
allow upstream requests to be performed until the cycle completion. This may be critical for
isochronous buses that assume certain timing for their data flow (e.g., AC’97 or USB). Devices on
these buses may suffer from underrun if the asynchronous traffic is too heavy. Underrun means that
the same data is sent over the bus while ICH2 is not able to issue a request for the next data. Snoop
cycles are not permitted while the front side bus is locked.
Note:
Locked cycles are assumed to be rare. Locks by PCI targets are assumed to exist for a short
duration (a few microseconds at most). If a system has a very large number of locked cycles and
some that are very long, the system will definitely experience underruns and overruns. The units
most likely to have problems are the AC'97 controller and the USB controller. Other units could get
underruns/overruns, but are much less likely. The IDE controller (due to its stalling capability on
the cable) should not get any underruns or overruns.
Note:
The ICH2 was designed to provide high performance support to PCI peripherals using its data
prefetch capabilities. If a PCI master is burst reading and is disconnected by the ICH2 to pre-fetch
the requested cache line, the ICH2 will Delay Transaction the cycle while it prefetches more data,
and give the bus to another agent. Once the bus is given back to this bus master, if it does not return
with the successive previously requested read address, which was prefetched by the ICH2, the
ICH2 will keep retrying the bus master until either it comes back for the prefetched data, or the
Delayed Transaction Discard Timer expires (1024 PCI clocks) before discarding this prefetched
data and servicing the request. This induces long latencies to PCI bus masters that behave this way.
To reduce this latency, the Discard Timer Mode bit (D30:F0;CNF(50-51h):[bit-2]) can be set to 1.
This will reduce the discard timer from 1024 PCI clocks (32 us) to 128 clocks (4 us) and improve
latency for masters with this behavior.
5.1.2
PCI-to-PCI Bridge Model
From a software perspective, the ICH2 contains a PCI-to-PCI bridge. This bridge connects the hub
interface to the PCI bus. By using the PCI-to-PCI bridge software model, the ICH2 can have its
decode ranges programmed by existing plug-and-play software such that PCI ranges do not
conflict with AGP and graphics aperture ranges in the Host controller.
5.1.3
IDSEL to Device Number Mapping
When addressing devices on the external PCI bus (with the PCI slots), the ICH2 asserts one address
signal as an IDSEL. When accessing device 0, the ICH2 asserts AD16. When accessing Device 1,
the ICH2 asserts AD17. This mapping continues up to device 15 where the ICH2 asserts AD31.
Note that the ICH2’s internal functions (AC’97, IDE, USB, and PCI Bridge) are enumerated like
they are on a separate PCI bus (the hub interface) from the external PCI bus. The integrated LAN
Controller is Device 8 on the ICH2’s PCI bus and, hence, uses AD24 for IDSEL
5.1.4
SERR# Functionality
There are several internal and external sources that can cause SERR#. The ICH2 can be
programmed to cause an NMI based on detecting that an SERR# condition has occurred. The NMI
can also be routed to, instead, cause an SMI#. Note that the ICH2 does not drive the external PCI
bus SERR# signal active onto the PCI bus. The external SERR# signal is an input into the ICH2
driven only by external PCI devices. The conceptual logic diagrams in Figure 5-1 and Figure 5-2
illustrate all sources of SERR#, along with their respective enable and status bits. Figure 5-3 shows
how the ICH2 error reporting logic is configured for NMI# generation.
5-2
82801BA ICH2 and 82801BAM ICH2-M Datasheet