Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!apple!voder!dtg.nsc.com!dave From: dave@dtg.nsc.com (David Hawley) Newsgroups: comp.arch Subject: Re: VME Bus Standard Summary: Futurebus' relation to suggested bus improvements Keywords: Futurebus, RISC Message-ID: <390@blenheim.nsc.com> Date: 8 Dec 89 18:05:55 GMT References: <7172@pt.cs.cmu.edu> <112400007@uxa.cso.uiuc.edu> <11759@phoenix.Princeton.EDU> <3070@cello.UUCP> <5693@eos.UUCP> Reply-To: dave@dtg.nsc.com (David Hawley) Organization: National Semiconductor, Santa Clara Lines: 92 > 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.