Author: Trevor Marshall
Source: March 1992 BYTE, Pages 131-134, 136, 138

IBM has taught us that compatibility is the single most important attribute for a mass-market bus. Without compatibility, there is no incentive to produce the innovative, third-party peripherals that have largely determined what we can expect for today's personal computers.

The second most significant characteristic is speed. The bus must be fast enough to transfer data from modern high speed peripherals to the host CPU with no noticeable degradation in system performance.

The original IBM XT was shipped with a very limited 8-bit expansion bus. It was not long before add-in cards started to tax its capabilities, so, with the release of the IBM AT, this 8-bit bus was widened to 16 bits and increased functionality was added. This created a clumsy (but standard) protocol now dubbed Industry Standard Architecture (ISA).

Four years ago, IBM announced with great fanfare that it had created the most advanced bus a desktop computer would ever need. It was called the Micro Channel. Soon after, a consortium of IBM competitors announced its own "perfect" bus, dubbed EISA (for Extended ISA). Both of these buses were claimed to be extensible, to have much higher performance than ISA, and to be its obvious successor.

Yet despite the Claims (and hopes) of both EISA and Micro Channel promoters, neither architecture has managed to take a significant share of the market. Less than 5 percent of PC compatible machines sold worldwide use the EISA bus. The remainder are mostly still ISA (AT-bus) compatibles. The Micro Channel has made an impact, but primarily in applications where bus speed is not a factor, such as point-of-sale terminals and data-entry stations. Consequently, the volume of Micro Channel add-in boards sold is still small.

Mastering the Buses

The XT bus was designed to complement a 4.77-MHz 8088 processor. It did that job well, delivering adequate transfer speeds for the add-in adapters of that day.

By the time the AT was released, it was becoming evident that microcomputers were soon going to catch up with the performance of the minicomputers and mainframes that still dominated computing. Consequently, the designers of the AT enhanced the XT bus by adding more DMA channels, more interrupts, and, most important, a 1 6-bit data bus. And they did this while retaining downward compatibility with the XT bus.

The AT bus proved adequate for the types of add-in adapters needed to complement the performance of an AT -class machine. The bus structure was reverse-engineered, multisourced, and dubbed the ISA bus.

Both the Micro Channel and EISA designers sought to overcome some of the limitations remaining in the ISA design. First, they provided a 32-bit data path to match the newly emerging 32-bit processors, such as the 386 and 486. Second, they paid a lot of attention to increasing the data transfer rates by more tightly specifying the bus transfer protocols. Third, they gave both buses considerable capability to support multiple bus masters.

A bus master is another, usually peripheral, processor that plugs into the bus yet can access the host processor' s memory and usually all the system peripherals as well .You need bus-master capability if your system is going to support intelligent drive controllers, such as those used in high-end network servers. It is also useful in many industrial applications, such as image grabbing and image processing.

The ISA bus can only support bus masters if they are set up as DMA controllers. This limits the data throughput to around 1.5 MBps. In addition, the host CPU is usually halted during any bus-master transaction.

A bus master should be able to, for example, transfer data from another peripheral card without affecting the control program running on the host CPU. EISA and Micro Channel both permit such concurrent processing; ISA does not.

Speed Limits on Buses

The speed of light limits how fast signals can propagate down a bus structure. But today's buses operate nowhere near this fundamental limit, do they? On the contrary.

An electrical signal travels down a perfect bus at about 7.86 inches per nanosecond. A 33-MHz CPU executes instructions as fast as one every 30 ns. Thus, if this CPU sent out a request on a perfect bus to a perfect pe1ipheral, you would lose one complete computational cycle for every 20 feet the signal had to travel. Naturally; in our imperfect world, things are much worse. To comprehend the fundamental performance limits for buses, you need to understand something about transmission-line theory (see the text box "Signals on the Wire" on page 132).

Signals on the Wire

A transmission line is a wire down which a signal from the CPU propagates to a peripheral. The simplest case, where only resistive terminating elements exist, is shown in figure A (see reference 1).

Figure A: A Typical Transmission-Line Bus Structure

Figure A: The electrical model of what seems like a simple line of copper on a circuit board. The input signal (in this case, a typical 0- to 4. 7-V logic transition) is modeled as the voltage source (V_s) for the transmission line. It must drive not only the relatively docile loads of pure resistance ( R_S, the source resistance, and R_L the load resistance) but also the more difficult reactive components Z₀ (characteristic impedance of the transmission line), r_L (normalized impedance of the load), and r_s, (normalized source impedance).

A 5-volt source with a series damping resistance of Z₀/4 ohms (Z₀ is the characteristic impedance, typical of most printed circuit board conductors) feeds the bus wiring. A typical Z₀ on a printed circuit board is 50 to 150 ohms (see reference 2). The peripheral terminates the bus with an effective resistance of 5 x Z₀ ohms.

Due to the loss in these resistances, only 4.7 V of the 5-V TTL high level that the CPU generates will be available to drive the peripheral. Because of signal reflection, you can't decrease the series resistance to transfer more energy along the bus.

Consider an 8-inch bus. When the CPU's signal reaches its far end, some of the energy is reflected to the source, giving rise to a theoretical waveform (see figure B).

Figure B: Waveforms At Near And Far End Of Bus

Figure B: A logic transition occurs at the near end of a bus at time 0 and arrives at the far end at 1T, with significant overshoot. The overshoot propagates back to the near end and changes the voltage there. The reflections travel up and down, decreasing, until at 8T the bus settles near its final logic level.

The voltage on the bus oscillates around the final value. If the oscillation grows too great, it exceeds the threshold value at which a logic device (e.g., a bus receiver) is triggered to change state. The receiver may then change its output value based on a false input generated by circuit ringing. Usually, the circuitry will fail to work properly, but sometimes the system can read the false value as a valid bit. In the real world, there is capacitance, not just pure resistance, to drive.

Figure C: Clock Waveform From A Poor PC Clone

Figure C: This oscillograph is taken from an early ISA clone. It shows the system clock (pin AXX) measured at the end of the bus and severe overshoot.

Figure C is an early ISA clone's system clock (pin AXX) measured at the end of the bus. The signal badly overshoots the 0-V level and, in fact, reaches a negative voltage of about -3 V. Then the signal "rings" back t o a level of about 0.8 V, causing most logic gates to malfunction.

On the positive transition, almost no overshoot occurs, although the peak voltage is only 3 V-much less than the theoretical 5-V maximum. The difference is due to an asymmetrical driving impedance.

The designer of the bus in figure C mistakenly used a very fast buffer device (a 74F245) to drive the clock resistor. The output impedance of this buffer (which should be greater than Z₀/2 to control overshoot) is extremely low when the signal goes from high to low (the pull down cycle) but fairly high when the signal goes from low to high (the pull up cycle).

If a slower logic gate had been used, the designer would have achieved faster system operation overall, less overshoot would have occurred, and the final voltage would have been achieved more quickly. This is what happens on the positive side, which is only half as fast as the negative. On the negative side, the signal achieves the steady-state level almost instantaneously.

The oscilloscope time base was set for one horizontal division every 20 nanoseconds with the CPU speed at 50 MHz. So, here is a bus where one handshake transaction would make a modern CPU wait almost a full cycle for it to complete. ISA, Micro Channel, and EISA buses require at least three transactions in every bus transfer cycle.

Figure D: Mac IIfx NuBus Oscillographs

Figure D:

(1) An oscillograph taken at the far end of a Mac IIfx NuBus, with just two cards (the test card and the video card) plugged in. A small amount of overshoot is present, but not enough to cause logic to malfunction. The rise and fall times of the signals are quite fast, and the ultimate signal levels are very close to 0 and 5 V.

(2) Another measurement from the far end of a Mac IIfx NuBus but this time every slot on the bus has been filled. The rise and fall times have now been reduced by the extra loading of the four additional peripheral cards, and the overshoot and settling are insignificant compared to the transition times. This performance is typical of a bus designed using the best technology available today.

In an optimally designed system, these transactions occur much faster. Parts 1 and 2 of Figure D are taken from a Mac IIfx NuBus. Part l was taken at the far end of the bus, with two cards (the test card and a video card) plugged in. A little overshoot exists, but not enough to cause logic to malfunction. The rise and fall times of the signals are fast, and the ultimate signal levels are close to 0 and 5 V. The two signals shown are the system clock and start.

Part 2 was taken under the same conditions, but this time with every bus slot filled. The extra loading that the four additional peripheral cards impose has reduced the rise and fall times, and the overshoot and settling are insignificant compared to transition times. This performance is typical of a bus designed using today's best technology.

So, the fastest time in which a transaction can occur seems to be 10 ns; 20 ns would be safe. So you can expect an ISA, EISA, or Micro Channel bus to manage one transaction every 30 to 60 ns using interface chips like the IIfx's. Thus, even the fastest bus transaction will take between one and two instruction cycles on a 33-MHz CPU.

Editor's note: All oscillographs reproduced here are 20 ns per division horizontally and 2 V per division vertically. Equipment used for testing bus signals was as follows: oscilloscope- 500-megasample-per-second Fluke digital scope; probes- 100x resistive probes, 1500-MHz bandwidth, Philips PM8912.

REFERENCES

1 . Arabi, Tarif. National Semiconductor Application Note 707 .

2. Jordan, Edward, ed. Reference Data for Engineers: Radio, Electronics, Computer, and Communications, 5^th ed., pp. 22-25. Indianapolis: Howard Sams, 1985.

Since bus physics fundamentally limits bus speed, the only easy way to improve the data transfer speed is to increase the width of the data bus (i.e., the number of data bits that can be exchanged for each set of bus transactions) or decrease its length. With today's driver technology, a 32-bit bus can achieve a data rate of about 60 MBps, a 16-bit bus can reach about 30 MBps, and an 8-bit bus can attain about 15 MBps.

The PCXI Consortium has been formed to define a variant of the EISA bus that is better able to serve the needs of scientific, engineering, industrial, and other power users. It has extra undefined pins capable of carrying signals between cards on high-speed local buses. These pins can also be used to carry Data Translation's (Marlborough, MA) DT-Connect bus architecture. The DT-Connect bus can transfer data at a rate of 100 MBps using standard 74FCT bus-driver ICs.

Bursts and Streams

To reduce the number of signal transactions needed per data transfer, you would use so-called burst or streaming data modes. The data rates that the Micro Channel and EISA promoters quote, 40 MBps and 33 MBps respectively, are possible only with data streaming.

The problem is that for data streaming, the data needs to be of a continuous nature. Data from a drive controller is often continuous. But the speed of data being sent to a video card is more likely to be determined by CPU processing speed, and the data's transfer is usually performed in the slower single-transaction modes.

For example, a typical 8-bit ISA bus achieves a data rate of only about 1 MBps in practice- 10 percent of the theoretical maximum. Its primary limitations are the response time of the cards in the bus and the nature of the motherboard logic, which uses wait states to slow down the bus to synchronize with its own internal response times. These limitations apply equally to wider buses and to EISA and Micro Channel implementations.

I recently checked the relative speeds of a 16-bit Ethernet adapter card and an 8-bit version of the same product. The 16-bit card provided only a 20 percent performance improvement. You don't need to use an advanced EISA system when the primary limitations are still processor- and network-related.

The Compatibility Factor 

Compatibility among the ISA, EISA, and Micro Channel systems implies, at least, that software designed to run on ISA machines will run the same way on EISA and Micro Channel systems. By and large, this has proved to be true.

In addition, compatibility implies that you can expect hardware designed for the Micro Channel to run in any Micro Channel machine and, similarly, EISA-designed hardware should run in any EISA machine. EISA promoters also claim that ISA adapter cards will run in an EISA machine (see the text box "Compatible May Not Mean Easy").

Compatible May Not Mean Easy

I recently tried to install one of the new low-cost fax-modem cards into a Hewlett-Packard 486 EISA-based computer. The EISA bus is compatible with ISA, right? So you just plug in the ISA card and it should work, right? Wrong.

I plugged in the fax card and installed the BitFax software as described in the manual. When I ran the program, it informed me that no fax card was present.

A check of the manual showed that all the DIP switches were set correctly for COM3, so there shouldn't have been any clash with the hardware already installed in the computer. Then inspiration struck me. I remembered seeing a press release about EISA doing away with the need for "complex" DIP switches and replacing them with a setup program. Referring to the HP manual confirmed that the EISA machine would not recognize the ISA add-in card until it had been "installed" and that I would need an Adapter Configuration File from the add-in's manufacturer before the EISA bus could recognize the fax card.

I borrowed a copy of the EISA Programmers Reference Manual from HP and, over the course of an hour or so, learned yet another programming language, wrote the Adapter Configuration File, and got the fax card up and running. A call to HP technical support later revealed that HP could send me a file containing a set of common adapter descriptions. If a card is sufficiently similar to a "common" adapter, then that file would have worked.

But why? Why couldn't I just plug the card in and have it work?

From day 1 of the IBM announcements, I had fully understood the proprietary nature of the Micro Channel bus. It was obvious that if I chose to go the Micro Channel path to higher performance, I would have to buy specialized adapter cards, there would be fewer sources for them, and they would be more expensive. But I never anticipated that EISA would have similar barriers to the free-market economics that have made personal computer technology such a success.

Luckily, now that third-party (clone) vendors are starting to ship EISA machines, software has been written to ease the installation task. Most clones now ship with installation software that scans the bus, looking for I/O ports and memory maps that it recognizes, like the COM ports on a fax adapter. If you have a nonstandard peripheral, however, you are still out of luck.

However, some problems have occurred that have delayed achieving compatibility within Micro Channel systems. The early interface chip from Chips & Technologies (the 6311 ) worked fine in the IBM PS/2 Model 50, but it did not work well with the later Models 70 and 80 because the IOCHRDY signal operated incorrectly (see the text box "Which Micro Channel Is It?" on page 136).

Which Micro Channel Is It?

Figure A: IBM PS/2 Micro Channel Signals

Figure A: (1) is from a bus measurement in an IBM PS/2 Model 50, and (2) is from a test of an IBM PS/2 Model 70. The two waveforms represent measurements of the address strobe (upper trace) and command strobe (lower trace) lines and are supposed to show two distinct phases of the transaction cycle. Notice that on the Model 50 the lines actually overlap, causing a period of uncertainty that add-in card manufacturers can handle by building in bus-settling delays when designing Micro Channel cards. While the same waveforms on the Model 70 look more as they should, the quality of the signals on this bus is still nowhere near as good as that of those measured on the NuBus of the Mac IIfx.

Not all Micro Channel implementations are the same, even when they are from IBM. Figure A shows two oscillographs; part 1 was taken from an IBM PS/2 Model 50, and part 2 from an IBM PS/2 Model 70. The two waveforms, ADL (Address Latch) and CMD (Command), are supposed to delineate two different phases of the transaction cycle.

Notice that on the Model 50 the waveforms actually overlap. While the same waveforms on the Model 70 look more like the data book says they should, the quality of the signals on this bus is still nowhere near as good as those on the Mac IIfx's NuBus (see the text box "Signals on the Wire" on page 132).

Peripheral designers have to design cards that will work in all machines, both slow and fast. The only way to ensure this compatibility is to avoid the use of the advanced features that are available only on faster bus implementations.

Therefore, an add-in card designer has to use logic slow enough to accommodate the timing variations seen on the Model 50, instead of designing a card that will be upgradable to the 160-MBps peak Micro Channel data rate.

For the RISC System/6000 series of workstations, IBM introduced another version of the Micro Channel architecture, this one allowing for the use of larger option cards. The workstation version of the Micro Channel began as a 32-bit-wide bus, but there are plans to upgrade it to a 64-bit-wide revision supporting block transfers.

Thus, some manufacturers who embraced the Micro Channel early in its development had to redesign their Micro Channel products at an early stage in their life cycle. Not only did this reduce the number of available adapters, it also increased their cost. But these early problems have been overcome, and both Micro Channel and EISA have now achieved the levels of hardware compatibility expected of them.

However, with the RISC System/6000 series of RISC workstations, IBM introduced a Micro Channel with a larger physical card size (it is now almost as big as an AT ISA card) and new, higher-speed, burst-transfer modes. So is the Micro Channel add-in you are buying PS/2 Micro Channel-compatible or RS/6000 Micro Channel-compatible?

Why Buy ISA Machines Now?

EISA and Micro Channel machines are still considerably more expensive than their ISA counterparts. Part of this difference is due to how much the EISA chip set costs the computer manufacturer. The other part is due to a recognition that an EISA machine won't sell as well as an ISA system will. In addition, only Intel currently ships an EISA interface chip. It is expensive compared to the ISA chips, which are available from a number of vendors.

In return for the higher price of the EISA and Micro Channel systems, greater levels of system performance are expected. But in actual use, this expectation has often not been met. Meanwhile, many designers have found a better way of increasing system speed: close coupling.

Close Coupling  

RAM is the most speed-critical resource that a CPU needs. To improve system speed and bypass bus limitations, you can closely couple the main memory system to the CPU over its own dedicated bus.

Although the original XT had only 64K bytes of closely coupled (motherboard) memory and needed add-in memory cards to run any significant software, most computer systems sold today have several megabytes of high-speed, closely coupled memory on the motherboard. Add-in memory cards are rarely needed. Thus, bus-speed limitations no longer affect the CPU's ability to obtain data quickly from its main memory.

Local Intelligence

The same design methodology is now being applied to all the subsystems that make up a computer system. Vendors often claim that you need a fast bus for faster video (for applications such as multimedia). But as Nick Baran warned (see "The Bus Stops Here," February 1990 BYTE), none of these expansion buses really has enough raw bandwidth to directly transfer pixels at the rates needed for real-time video displays.

Peripherals need more local intelligence to off-load some of the host CPU's computing tasks. This is already happening in two areas: drive controllers and video display cards. The data rate of the ISA bus is slower than that of many modern hard disk systems. However, if you mount a memory cache on the drive controller, it acts as a buffer between the disk data rate and the bus data rate.

Even though the disk speed of the original AT computers was limited to around 260 KBps (the 2-to- 1 interleave data rate), most controllers now operate at the 500-KBps rate of 1 -to- 1 interleave disks. The data from a whole track is stored in memory on the drive controller. It is then available when the host CPU is ready to use it. This architecture doubles system performance without needing any changes in the bus itself.

Enter Localbus  

Intel has defined a bus for closely coupling peripherals to the CPU. Called Localbus, it essentially connects peripherals directly to CPU control lines. Similar connections to VGA controller chips have yielded a significant performance improvement over the same VGA chips on either EISA or Micro Channel adapter cards.

True, there is a limit to the number of peripherals you can connect through the Local bus. However, that limit is now mainly the limit of capacitive loading. Placing the Local bus chips on the motherboard very close to the CPU has reduced the inductive (transmission-line) component.

Moving beyond Localbus performance, CPU technology is migrating toward the "PC on a chip." In that vein, the CPU is incorporating more and more of the key peripherals into itself.

High-Speed RISC Connections

RISC processors are already operating at 50-MHz and 60-MHz clock rates, requiring efficient connections between the CPU and memory and between the CPU and peripherals. The SPARC Consortium has defined a bus, called MBus, that is very similar to Localbus and incorporates several important innovations likely to be seen in the very near future.

First, the MBus emphasizes the use of surface-mount technology to achieve small size and, hence, low parasitic inductance and capacitance. Thus, the bus never really becomes a "transmission line" (for electrically oriented readers, it behaves more like distributed lumped capacitors). The maximum card size is less than 20 percent of that of a standard AT expansion card, yet, by using smaller (surface-mount) components, it has basically the same functionality.

Second, the MBus uses a wider data transfer width: 64 bits. Since the bus can operate at 40 MHz, the useful bandwidth is 80 MBps, and the peak rate is 320 MBps.

Third, you can stack multiple MBus modules. Unlike ISA, EISA, and Micro Channel buses, the MBus modules are very close together, and very close to the CPU. Thus, although transmission-line effects definitely exist, the ringing and other artifacts occur at much higher frequencies and don't affect overall system performance.

The Bottom Line

If you're planning to buy a Micro Channel machine today based on its promise of extensibility to 160 MBps, forget it. The Micro Channel may support that data rate one day, but just as you had to upgrade your CPU from 8086 to 286 to 386 to 486 to get their advantages, you will have to upgrade your system and peripherals to get that sort of data rate.

The same situation pertains to ISA or EISA. Until all manufacturers design their machines using the best technology available, the peripheral vendor will have to compromise, thus limiting the performance your system can achieve. Manufacturers are offering a lot of innovative solutions to overcome these limitations. Unless you are running a Unix or NetOS-based network (which needs blinding speeds from the drive controller), then ISA-based machines using Localbus technologies will probably do the job.

Select a system that does what you want today. The industry will provide brand-new products to choose from tomorrow.

Trevor Marshall is a consulting editor for BYTE. You can reach him on BIX as "tmarshall"