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 (Vs)
for the transmission line. It must drive not only the
relatively docile loads
of pure resistance ( RS, the source resistance,
and RL the load
resistance) but also the more difficult reactive
components Z0
(characteristic impedance of the transmission line), rL
(normalized
impedance of the load), and rs, (normalized
source impedance).
A 5-volt source with a series damping
resistance of Z0/4
ohms (Z0 is the characteristic impedance,
typical of most printed
circuit board conductors) feeds the bus wiring. A typical
Z0 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 Z0
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 Z0/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, 5th
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"
|