NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/arch/11662

Text File | 1992-12-15 | 14.6 KB | 329 lines

Newsgroups: comp.arch
Path: sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!usc!cs.utexas.edu!wotan.compaq.com!twisto.eng.hou.compaq.com!croatia.eng.hou.compaq.com!simonich
From: [e-mail] (Chris Simonich)
Subject: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Message-ID: <[e-mail]>
Keywords: Bus, I/O, Point-to-Point, High Performance, Low Cost
Sender: [e-mail] (Netnews Account)
Organization: Compaq Computer Corp.
Date: Tue, 8 Dec 1992 00:27:55 GMT
Lines: 317

************************************************************
*                                                          *
*               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: [e-mail]                        *
*   Phone: [phone]                                   *
*   Fax:   [phone]                                   *
*                                                          *
*                                                          *
*                                                          *
*  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: [e-mail]                        *
*   Phone: [phone]                                   *
*   Fax:   [phone]                                   *
*                                                          *
*                                                          *
*   Happy Holidays from Strat Tech Dev...                  *
*                                                          *
************************************************************