From: simonich@croatia.eng.hou.compaq.com (Chris Simonich)
Subject: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Keywords: Bus, I/O, Point-to-Point, High Performance, Low Cost
Organization: Compaq Computer Corp.
Date: Tue, 8 Dec 1992 00:27:55 GMT

************************************************************
*                                                          *
*               COMPAQ COMPUTER CORPORATION                *
*                                                          *
*              STRATEGIC TECHNOLOGY DEVELOPMENT            *
*                                                          *
*   We're sick of beating our heads against the wall       *
*   trying to expand the performance of I/O busses. Let's  *
*   face it, busses are just not a long term solution for  *
*   high performance computer solutions.   So here is an   *
*   alternative to PCMCIA, PCI, MCA, EISA, ISA, etc.       *
*   for use in future computers                            *
*                                                          *
*                                                          *
*  Note:  Compaq is presenting this solution at the        *
*  CardBus committee meeting in Deerfield Beach, Florida,  *
*  on 12/7/92 for possible adoption as the CardBus         *
*  standard.                                               *
*                                                          *
************************************************************

Our proposed I/O solution is
	- hierarchical 
	- point-to-point
	- low cost
	- scaleable
	- high performance
	- processor & endian independent
	- channel I/O architecture

In short, NOT YET-ANOTHER SHARED, WIDE BUS!!!
 

                  CPU        memory
                   |___________|
                         |
                       MIOC
                       /  \
                     IOC  dev3
                     / \
                 dev1  dev2

                      Figure-1

The basic I/O subsystem [figure-1] consists of a "main" I/O 
concentrator (MIOC) which interfaces the I/O architecture to 
any CPU/Memory architecture.  One or more point-to-point 
channels propagate in a hierarchical manner from the MIOC to 
the devices.  One such device is an I/O Concentrator (IOC) 
which allows the bandwidth of a single point-to-point 
channel to be shared amongst several devices.  Other devices 
might include network interfaces, graphics, SCSI, etc.  You 
may optionally allow a few low bandwidth devices to share 
the same channel under a controlled environment.

An interconnection channel consists of an upstream port 
(residing in either an MIOC or IOC), the physical 
connection, and a downstream port (a device).  The physical 
channel consists of 12 signals:
    -  a 50 MHz synchronizing clock
    -  two handshake signals
    -  eight data bits
    -  a parity bit

The small number of signals reduces the pin requirements for 
interface ASICs and physical size of adapters/connectors, 
reducing the cost of implementation.  Because all data 
transfers in byte wide quantities and in increasing address 
order, the solution transfers in a non-endian specific 
manner.  Also note that the channel pin-out is NOT a 
derivative of any particular CPU chip's memory interface 
signals, allowing the solution to be connected independent 
of CPU architecture.

The proposed solution minimizes "out-of-band" signals.  All 
operations within the I/P subsystem are carried out via 
packets.  Even the synchronizing clock is propagated from 
the MIOC to devices through IOCs.  In other words, the 
channel clock is redistributed in every IOC and each 
channel's timing is independent from all other channels.  
This virtually eliminates clock skew problems common in 
today's systems.

The standard data transfer rate on a channel is 50 
MBytes/sec (MBPS) and the upper bound will be limited by the 
physical environment of the channel.  For example, a current 
high performance implemention with GTL drivers and receivers 
could yield a transfer rate of 200 MBPS.

Two ports on a channel "agree" on a transfer rate during the 
initialization.  Each port multiplies the 50 MHz channel 
clock to generate internal clocks to operate at the agreed 
transfer rate.

Operations occur using packet-based commands that flow 
through the channels.  Each packet generally contains four 
fields
    - command (Read, Write, Error, Extensions/Interrupts,
               etc.)
    - size (data amount transferred)
    - address
    - data

Only the command field is mandatory.  All ports are 
responsible for some encoding and decoding of packets.  Note 
that only one packet at a time can be transferred on a 
channel.  This means that there will be times that the 
devices cannot send or receive when an IOC upstream port is 
busy.  The handshaking protocol allows the ports to perform 
conflict resolution to clear space for a transfer.  

The proposed solution is designed to allow the CPU to 
directly read and write MIOC, IOC, and device registers in a 
programmed I/O manner.  However, the architecture 
particularly lends itself to Command List Processing Master 
devices.  These entities run device specific command 
contexts placed in system memory that define their 
operation.  This potentially frees the main CPU to perform 
other operations.

************************************************************
*                                                          *
*  So, what do you think?  We are interested in making     *
*  this an open Industry Standard.  As such, you may       *
*  request further information, give us your comments,     *
*  or ask questions.                                       *
*                                                          *
*                                                          *
*  Contact:                                                *
*                                                          *
*   David Wooten, Manager, Strategic Technology Development*
*                          Compaq Computer Corporation     *
*                                                          *
*   EMAIL: davidw@twisto.compaq.com                        *
*   Phone: (713)378-7231                                   *
*   Fax:   (713)374-2580                                   *
*                                                          *
*                                                          *
*                                                          *
*  CONTINUE READING IF YOU'RE INTERESTED IN WHY WE SPENT   *
*  TIME DEVELOPING THIS CONCEPT!!!                         *
*                                                          *
************************************************************

The question we asked ourselves was how can one build an I/O 
subsystem that is high performance, easy to interface, easy 
to expand, and inexpensive?

A wide, shared bus is not the solution due to its inherent 
limitations, such as distributed capacitance, one-at-a-time 
transmit, and high pin count for the mother board and add-in 
cards.

In the past, shared bus architectures made sense because of 
the widespread use of TTL technology and the high cost and 
low integration of silicon.  The PC architecture that 
started almost a decade ago with a single, shared, 8-bit 
memory-I/O bus that became known as "ISA", has evolved into 
many variants due to the ever escalating performance 
requirements of x86 based CPU systems.  This phenomena is 
also seen in other architectures based on CPUs other than 
the x86.

One of the first changes in PC evolution was to move the CPU 
and the memory to a faster proprietary local bus when the 
ISA bus became a bottleneck.  The I/O data bus was widened 
to 16-bits and then to 32-bits to provide higher bandwidth 
for some devices.  There were two PC "wide-bus" solutions: 
EISA, a super-set of ISA for backward compatibility, and 
Micro Channel (MCA).

As a tradeoff for the high bandwidth, the system and the 
add-in cards for the wide I/O buses became more expensive 
than comparable ISA solutions.  However, even with the 
presence of high bandwidth busses, ISA provided bandwidth 
adequate for the majority of devices.  As a result, board 
vendors continue to build boards for ISA because of the 
larger available market.  ISA cards could be sold into ISA 
systems and EISA systems, while EISA cards were limited to 
EISA systems only.  More recently, higher resolution color 
graphics and video applications have become popular for PCs.  
The bandwidth demands for the graphics/video devices are too 
large for even EISA and MCA.

To correct this deficiency, several system OEMs have moved 
graphics onto high-bandwidth proprietary local busses.  As 
the practice of moving faster devices onto the local bus 
became common, there was a need for a standard.  Currently, 
there are two local bus standard proposals, namely, PCI (by 
Intel) and VL-Bus (by VESA).

Existing processors do not have a PCI bus and future 
processors will not directly support the VL-Bus.  Besides, 
PCI and VL have limited plug-in (card) support.  
Consequently, PC systems utilizing PCI or VL may have 
multiple layers of buses (CPU bus, local bus, standard I/O 
bus) and IC bridges to interface between different bus 
protocols.  All of this leads to higher system and add-in 
board costs.  Chip and board vendors also need to choose 
between many different interfaces and form-factors to 
support a wide range of system types.

Worse yet, both PCI and VL busses will very likely try to 
satisfy future needs, such as higher bandwidth and 3.3V 
technology, by _changing_ the physical layer.  Examples 
might include: a wider (64-bit) bus once 32-bits runs out of 
steam, and a different driver/receiver technology for higher 
frequencies.  Protocols might also have to change and many 
of these changes will render today's PCI and VL devices 
incompatible (PCI does have a compatible transition to 64-
bits).

Neither PCI nor VL support plug-and-play and ease-of-use 
features.  Depending on implementation, PCMCIA does not 
support hot-swap and may not offer enough performance for 
some applications.  A PCMCIA sub-committee was created to 
come up with a PCMCIA super-set called CardBus.  As 
mentioned earlier, most board vendors made ISA-based cards 
rather than EISA-based for cost reasons and larger market 
share (both ISA and EISA systems).  CardBus will likely 
follow the EISA "pattern" if CardBus is a super-set of 
PCMCIA, i.e., a wider, more expensive 32-bit bus and 
backward compatible for exactly the same reasons previously 
stated.

To summarize: the PC industry has tried several times to 
solve increasingly higher performance I/O requirements by 
utilizing a multitude of wide, shared buses.  Most solutions 
did not last long because they were not scaleable and they 
were EXPENSIVE.  As a result most PC users continue to buy 
cheap and reasonable performance ISA systems.  What the 
computer industry needs is a solution that:

(a) solves today's problems (performance, expansion,
    ease-of-use) in a cost effective manner AND
(b) offers a migration path for those who want it AND
(c) will provide longevity AND
(d) is processor independent.

Our proposed solution can offer these properties!

************************************************************
*                                                          *
*   To summarize the major Features:                       *
*                                                          *
************************************************************

     The proposed solution is scaleable in multiple 
dimensions: performance, expandability and cost.

For performance:
(a) the CPU-memory bandwidth is decoupled from the slower 
device latencies,
(b) point-to-point minimizes the physical constraints and 
GTL enables higher signal rates than TTL,

For expandability:
(c) virtually unlimited number of devices can be connected 
on-board or off-connectors,
(d) expansion can also be made in external boxes via a small 
pin-count robust protocol (e.g., a fast serial link)
(e) hot plug-and-play,

For cost:
(f) small packages/connectors/boards and high integration 
can be achieved because of the small number of pins to 
interface,
(g) the number of PCB layers is minimized because of "clean" 
layout and no long traces (even in the case of bussing, 
the fanouts are fairly short),
(h) development cost is reduced by utilizing common 
functional blocks (e.g., state machines, FIFOs),
(i) time-to-market can be reduced by integrating common 
parts,
(j) common parts for a wide range of systems enable large 
volume, fewer inventory part types and consistent 
test/manufacturing techniques,

For compatibility:
(k) standard I/Os such as ROM and keyboards can be tapped 
off of an MIOC or IOC,
(l) existing standard buses (e.g., ISA, PCMCIA) can also be 
implemented off MIOC or IOC as a migration path, and
(m) Existing application software and operating systems will
    be compatible with some driver updates.

For Longevity:
(n) since devices are processor neutral they can be reused 
in future systems.
(o) the same I/O subsystem or architecture can be used in a 
family of products (portables, desktops, workstations, 
servers)
(p) the same device can be used for different transfer rates 
without changing the physical interface,
(q) changing a device interface in the future on a channel 
does not affect the rest of the devices [we call this 
"damage control"]

************************************************************
*                                                          *
*   Thanks for reviewing our thoughts!  Feel free to       *
*   to contact us for more information, we're here to      *
*   help!!!                                                *
*                                                          *
*  Comments???  Send to:                                   *
*                                                          *
*   David Wooten: Manager, Strategic Technology Development*
*                         Compaq Computer Corporation      *
*   EMAIL: davidw@twisto.compaq.com                        *
*   Phone: (713)378-7231                                   *
*   Fax:   (713)374-2580                                   *
*                                                          *
*                                                          *
*   Happy Holidays from Strat Tech Dev...                  *
*                                                          *
************************************************************