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.

Although EISA 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 and EISA 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 over ISA is the issue of bus arbitration. 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 around.

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 following close behind. Such devices are called "bus mastering devices" or "bus masters" because they become the master of the bus.

The EISA DMA 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. MCA, on the other hand, uses edge-triggered interrupts, which enables interrupt sharing. EISA 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 level-triggered.

As with MCA, EISA 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.

User Comments: