lamaster@pioneer.arpa (Hugh LaMaster) (06/05/87)
I note that the IEEE Computer Society just held a Summer 87 Futurebus Workshop
in Santa Clara, CA. IEEE Micro has had several articles on Futurebus in the
last two years. It is supposed to be very fast, cheap to drive, and the
greatest thing since Velveeta Cheese. Now that the specifications are
finished and everyone on the committee is happy, how about the rest of the
world?
Have people started to design it in to their products?
Is it as practical and cheap as it is cracked up to be?
How does it compare in ease of integration with VMEbus, Multibus (I and II),
Nubus, IBM PC Bus(es)?
Does it have a future?
Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}!
NASA Ames Research Center ames!pioneer!lamaster
Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa
Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov
"In order to promise genuine progress, the acronym RISC should stand
for REGULAR (not reduced) instruction set computer." - Wirth
("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")johnt@hammer.UUCP (06/10/87)
As bus standards go, Futurebus is unique in that it was designed and driven by the needs of the users of the bus, not by a silicon manufacturer. Since to use this bus, we have to implement it, we attempted to make it as easy as possible to design interfaces, and still get the performance required. I believe we have succeeded, and that comes from having built and put into production the first commercial Futurebus based system in 1985. Building that system required only 1 special piece of silicon, the Futurebus transceiver. All the state machines were implemented in a handfull of user programmable logic. Two years later, it is now possible to compare the complexity of Futurebus, Multibus II iPSB and VMEbus interfaces. In fact we have here one individual that has designed interfaces for all three buses. It is our opinion that Futurebus and VMEbus offer about the same implementation complexity at the protocol level. The data path on Futurebus is much simpler to handle because you almost never need to do any byte shifting or muxing. We found iPSB to be much more complicated to implement at both the protocol and data path levels, even when using the MIC and BAC interface silicon. Whether Futurebus is appropriate versus NuBus or the PC buses depends upon the job that needs to be done. Futurebus is oriented toward two main goals: the maximum data transfer rate that can be achieved over an electrical backplane bus, and the support of the most efficient cache coherence protocols known in the industry. NuBus offers simplicity and medium performance. If NuBus meets the performance and protocol needs of your system, then its hard to imagine a more efficient bus interface. The latest PC bus appears to offer capability similar to NuBus, but with its very high connector pin count, will never be as cheap to implement. Futurebus allows growth in performance by using a fully compelled asynchronous handshake that has no wasted state transitions. This handshake protocol was pioneered by Fastbus and is the fastest asynchronous handshake protocol known. We coupled this with a new electrical environment that supplies most of the electrical advantages of ECL (fast, low noise, no required settling time) with a TTL user interface and +5 volt operation. This logic family, called backplane transistor logic (BTL), was developed by National Semiconductor and has been in production for over 2 years. TI is now introducing their first parts in the family. To cater to efficient cache operations, Futurebus offers 4 important protocols. All addresses sent down the bus are broadcast, i.e. every module is guaranteed (using a 3 wire compelled handshake) the time necessary to decide if that address means anything to it, like its cache tag. A bus master can choose to broadcast its data so that multiple slaves can update their memory (caches) simultaneously. A cache can choose to interfere with a connection between a master and a slave, causing the slave to disconnect and be replaced with itself (the cache). This is important when a cache has modified data that does not exist in main memory. This is called intervention. The final protocol is reflection. Again a cache has modified data that the memory does not, but this time the cache supplies the data to the master and the memory stores the data as it goes by, bringing main memory up to date. In conjunction with the above data protocols are a cache command and a cache status bit that are used to supply information necessary for maintaining the coherence model. Which model you ask? Well, all of them. More later. The second phase of the Futurebus development is P896.2, a future standard that will address cache coherence, bus repeaters, message passing, and define the layer of registers between the software and the bus related functions. This work is well underway, particularly the cache model. The cache model unifies all the published coherence algorithms under one set of rules. What was discovered was that when you normalize all the different terms and states people have for their coherence algorithms, they all are talking about the same thing. By following the Futurebus coherence rules, you will be able to implement your favorite coherence protocol, and at the same time will be able to maintain coherence with boards with no caches, and boards with someone else's favorite coherence protocol. If all goes according to plan (see politics below), Futurebus, IEEE 896.1, will become an IEEE standard June 11. At the Futurebus tutorial held June 1 and 2, we had about 60 paid attendees learning about the philosophies and protocols. The European based manufacturers and user group has about 60 paying members. All of the implementation work I am aware of today is going on inside systems. Several companies and government organizations have standardized on Futurebus. It will probably be a year or two before a board market really develops. Part of the delay will be waiting for controller silicon to reach production, and time will be the required for the industry to learn what caches require in bus facilities, and that the other buses do not have them. Its only a matter of time. Futurebus has taken as long as it has to reach this stage because of several things, two of which were the need to break new ground to get the performance up, and politics. Probably a year of the process can be attributed to the latter. There are individuals in the IEEE hierarchy (like most bureaucracies) that do not want Futurebus to succeed. They have raised several roadblocks along the way, and invented new processes that no other IEEE Computer Society MSC working group has had to go through. I am guessing that the scope and organization of the Futurebus working group has been a threat to their power base and they are doing what ever they can to fight back. Their last chance occurs at the IEEE standards board meeting on June 11. If they get their way, Futurebus will not become a standard this week, but at the next standards board meeting in 3 months, it will most certainly will. John Theus johnt@hammer.gwd.tek.com or tektronix!hammer!johnt P896.1 parallel protocol task group coordinator P896.2 cache task group and bus repeater task group member (we always welcome new members)
fenton@trantor.harris-atd.com (S. Fenton McDonald) (12/08/89)
Does anyone know of any companies which are current designing system, chip sets, or backplanes based around the Future Bus Standard? I will compile any replies and mail a summary to any interested parties.
dave@dtg.nsc.com (David Hawley) (12/09/89)
BTL (Backplane Transceiver Logic) bus transceivers are available from National Semiconductor, Texas Instruments, and Signetics. For more detailed information about current product developments, a non- disclosure agreement is usually required. The state of the Futurebus standard probably needs clarification. Futurebus was approved by the IEEE as 896.1 in 1987. Futurebus+ is a wholesale revision to and extension of that standard, including wider address and data paths and faster data transfer protocols. P896.1 (soon to be released for public comment) contains specifications of arbitration, data transfer, caching, message passing, and basic control and initialization. P896.2 (to follow shortly thereafter) specifies board sizes, pinouts, and live insertion, among other things. P896.3 is a guide describing how to use Futurebus+ in secure, high-reliability, and real-time applications. The BTL interface is described in an independent standard, P1194; the new Metral connector in P1101.x. The U.S.Navy has selected Futurebus+ as the standard for future mission- critical computers. It now has prototype contracts out to Raytheon (subs are Nanotek, BICC-Vero, and Ferranti), Litton (sub is Force), and Cable Computer Technology (subs are Prime and Unisys). Tektronix is currently selling products using the old 896.1 standard. I am unable to discuss any other commerical developments based on Futurebus+. Information about Futurebus+ is currently easily available only to active P896 working group members. To find out the schedule for the next meeting, call the VME International Trade Association (VITA) at (602)951-8866, and they can FAX it to you. Dave Hawley National Semiconductor Corp. dave@dtg.nsc.com (408)721-6742
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (12/12/89)
In article <390@blenheim.nsc.com> dave@dtg.nsc.com (David Hawley) writes: >> Futurebus seems to address many problems, and, I recall that the bus driver logic is supposed to be the greatest thing since Velveeta. On the other hand, someone remarked that: "I am particularly concerned about the arbitration protocols - they seem destined to be slow and complicated." Is it too late to do anything about the the arbitration problem? Since the bus appears to be extremely good in many ways for, I would hate to see an Achilles heel sneak in. Some previous posters questioned whether the world needed FUTUREbus, since many systems will use faster, cheaper, simpler, (and proprietary!) private memory buses. I believe that it is needed. A single disk controller card can now saturate a VMEbus, even as an I/O device. See Xylogics' new IPI-2 card, for example. I believe that vendors are going to "discover" a tremendous demand for higher performance I/O once the industry standard is there to support it. VMEbus is great, but two years from now I bet people are going to be wondering how they ever got along with only ~20MB of I/O bandwidth. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
gerry@zds-ux.UUCP (Gerry Gleason) (02/23/90)
We are presently looking at busses for possible future products. Futurebus is one of the possibilities, and I have some questions about how it will be used. From the time I have spent looking over the spec, I get the impression that it is meant to be flexible wherever possible to allow its performance to be scaled along with the technology, but doesn't this make it hard for a true standard to emerge? (my info is based on IEEE Std 896.1-1987, and I don't know if there is anything newer) Maybe instead of going straight for questions about how people plan on implementing it, it would be better to have a more general discussion, identify the places the spec gives the implementer a choice, and determine if or how these choices would effect interoperability. The forward states, "this standard provides users with a 'set of tools' with which to build an implementation, rather than a rigid specification . . ." Doesn't this almost kill any widespread interoperability from the start or are they saying that the 896.1 spec (hardware) can potentially support more than one "firmware" spec (896.2, btw does this exist yet?)? I'm sure others have a much deeper understanding of the spec than I do at this point, so I'll hold off on any more questions, and wait to make sure no one shows me that I'm totally off base, while deepening my understanding further by reading the spec some more. Thanks in advance. Gerry Gleason
josh@planchet.rutgers.edu (J Storrs Hall) (01/07/91)
Is Futurebus for real? How many companies are making products for it? --JoSH