Extended Industry Standard Architecture EISA
To break the hold that IBM had on the 32-bit bus
market with the Micro-Channel Architecture,
a consortium of computer companies, lead by Compaq, issued their own standard
in September 1988. This new standard was an extension of the ISA-Bus
architecture and was (logically) called the Extended Industry Standard
Architecture (EISA). EISA offered many of the same features
as MCA but with a different approach.
provides some major improvements, it has maintained backward compatibility with
ISA boards. Therefore, existing ISA boards can be used in
EISA machines. In some cases, such boards can even take advantage of the
features that EISA offers.
To maintain this compatibility, EISA
boards are the same size as their ISA
counterparts and provide connections to the bus
in the same locations. The original designe called for an extension of the bus
slot, similar to the way the AT slots were an extension on the XT slots.
However, this was deemed impractical because some hardware vendors had
additional contacts that extended beyond the ends of the slots. There was also
the issue that in most cases, the slots would extend the entire length of the
motherboard, which meant that the motherboard would need to be either longer or
wider to handle the longer slots.
Instead, the current spec calls for the additional connections to be
intertwined with the old ones and extend lower. In what used to be gaps between
the connectors are now leads to the new connectors. Therefore,
EISA slots are deeper than those for
ISA machines. Looking at EISA cards, you can easily tell
them from ISA cards by the two rows of connectors.
Figure 0-3 shows what the ISA
connections look like. Note that the adapters are not to scale.
Image - Comparison of ISA,
EISA and PCI, Connections (interactive)
Another major improvement of EISA
is the issue of bus
Bus arbitration is the process by which devices "discuss" whose turn it is on
the bus and then let one of them go. In XT and AT class
machines, the CPU completely managed control of the bus.
EISA includes additional control hardware to take this job away from the CPU,
which does two important things. First, the CPU is now "free" to carry on more
important work, and second, the CPU gets to use the bus only when its turn comes
Hmmm. Does that sound right? Because the CPU
is the single most important piece of hardware on the system, shouldn't it get
the bus whenever it needs it? Well, yes and no. The key
issue of contention is the use of the word "single."
EISA was designed with multiprocessing in mind; that is,
computers with more than one CPU. If there is more than one CPU, which one
is more important?
The term used here is bus
arbitration. Each of the six devices that EISA
allows to take
control of the bus
has its own priority level. A device signals its desire for the bus by sending a
signal to the Centralized Arbitration Control (CAC) unit. If conflicts arise
(e.g., multiple requests), the CAC unit resolves them according to the priority
of the requesting devices. Certain activity such as DMA
and memory refresh have the highest priority, with the CPU
behind. Such devices are called "bus mastering devices" or "bus
masters" because they become the master of the bus.
controller was designed for devices that cannot take advantage of the
bus mastering capabilities of EISA. The DMA controller
supports ISA, with ISA timing and 24-bit addressing as the
default mode. However, it can be configured by EISA devices to take full
advantage of the 32-bit capabilities.
Another advantage that EISA
has is the concept of dual buses. Because cache
memory is considered a basic part of the EISA specification, the
CPU can often continue working for some time even if it
does not have access to the bus.
A major drawback of EISA
(as compared with MCA) is that to maintain the compatibility to
ISA, EISA speed improvements cannot extend into memory.
This is because the ISA-Bus cannot handle the speed requirements of the
high-speed CPUs. Therefore, EISA requires separate memory buses. This results in
every manufacturer having its own memory expansion cards.
In the discussion on ISA,
I talked about the problems with sharing level-triggered interrupts.
on the other hand, uses edge-triggered interrupts, which enables
uses a combination of the two. Obviously, EISA needs to support edge-triggered
interrupts to maintain compatibility with ISA cards. However, it enables EISA
boards to configure that particular interrupt as either edge- or
As with MCA,
enables each board to be identified at boot
up. Each manufacturer is assigned a prefix code to make the identification of
the board easier. EISA also provides a configuration utility similar to the MCA
reference disk to enable configuration of the cards. In addition, EISA supports
automatic configuration, which enables the system to recognize the hardware at
boot-up and configure itself accordingly. This can present problems for a Linux
system because drivers in the kernel rely on the
configuration to remain constant. Because each slot on an EISA machine is given
a particular range of base addresses, it is necessary to modify your kernel
before making such changes. This is often referred to as the EISA-config, EISA
Configuration Utility, or ECU.