🚀 go-pugleaf

> From: lamaster@athena.arc.nasa.gov (Hugh LaMaster)
> Message-ID: <5693@eos.UUCP>
>
> Are there any comments on how well FutureBus meets these improvements? 
[elimination of CISC features; good ideas that should be in new busses]
> There have been several articles describing FutureBus in IEEE Micro,
> as well as the draft standard itself.  My understanding is that the
> 32 bit standard is now complete, and 64bit+ extensions are now being
> drafted.

The new Futurebus+ development supercedes, as well as extends the old
IEEE 896.1 Futurebus standard.  Here are some comments:

> From: alvitar@weasel.austin.ibm.com (Phillip L. Harbison)
> (soon to be alvitar@uahcs1.UUCP or alvitar@xavax.UUCP)
> Message-ID: <3070@cello.UUCP>

> [1] No justified data busses!
> [2] Get rid of daisy-chained signal lines!
> [3] Get rid of centralized resource managers.

Futurebus has none of these.  32-bit transfers are standard; wider data
paths and byte lane enables are supported.

> [1] Geographic Addressing
> [2] Try-Again Signal
> [3] Cache Consistency (or Coherency)
> [4] Pin & Socket Connectors
> [5] Support Redundant Busses
> [6] Hardware Semaphores

Futurebus has explicit support for all of these except redundant busses.
Futurebus is the only standard bus I know of that can support copy-back
cache protocols without using busy-retry.  It now uses a Metral pin and
socket connector (4-row, 2mm grid, 192 pins).

> From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
> Message-ID: <7172@pt.cs.cmu.edu>
> [7] Power Mate Before Signal Mate
> [8] Bus Isolation Mode
> [9] Built In Self Test ( Built In Test Equipment )
> [10] No Byzantine Agreement

All that is required for live insertion is that the board be brought to
the same ground as the system (static discharge) before insertion, as
long as power is sequenced correctly on the board to ensure that the bus
drivers are disabled.  The live insertion facility is available in
Futurebus+, but not required; many systems do not need it.  Bus
isolation, built-in self-test, and "monarch" selection on power-up are
mentioned in Futurebus+, but an exact implementation is not specified.

Some things that Futurebus+ provides that are required in any bus that
have not been mentioned yet are:

[11] Clean Electrical Environment

Futurebus+ uses BTL (backplane transceiver logic), which is designed
to operate in a backplane's transmission line environment.  This allows
reliable incident-wave switching (no reflections) on all signals,
preventing the settling-time performance loss typical of TTL systems.

[11] High-Performance Block Data Transfers

Futurebus+ source-synchronous/packet-mode transfers allow data to be
transferred on the backplane at the physical limits of the media, which
is somewhere between 50 and 100 MHz for BTL.  Unfortunately, specialized
silicon must be developed to take advantage of this protocol.  Futurebus
also specifies a fully handshaken "compelled" transfer mode for more
traditional implementations, up to 25 mega-transfers/second.  A true
RISC bus would probably allow only one type and size of block transfer.

[12] Split Transactions

A write-only protocol has significant advantages in system-wide access
latency.  Of course, the design of all boards, especially memory boards,
gets more complicated.  Futurebus+ supports (but does not require) split
transactions - a "CISC" compromise.

Futurebus meets most of these "requirements" for a RISC bus, but it is
still CISC (and still valuable, I believe).  So what really defines a
RISC bus?  Think about your system implementation requirements, and
strip anything that does not compromise your cost and performance goals.
This will vary for I/O, memory, multiprocessing, real-time, or fault-
tolerant busses.  If you are designing for one of these, you can build a
RISC bus.  If you want to support more than a few of these, look at CISC
Futurebus.

Dave Hawley                                 National Semiconductor Corp.
dave@dtg.nsc.com                                           (408)721-6742

Disclaimer: I do not represent the IEEE or the P896.x Futurebus+ committee.