Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!orca!hammer!johnt From: johnt@hammer.UUCP Newsgroups: comp.arch Subject: Re: Futurebus Message-ID: <2947@hammer.TEK.COM> Date: Tue, 9-Jun-87 21:20:05 EDT Article-I.D.: hammer.2947 Posted: Tue Jun 9 21:20:05 1987 Date-Received: Sat, 13-Jun-87 03:08:23 EDT References: <1694@ames.UUCP> Reply-To: johnt@hammer.UUCP (John Theus) Organization: Tektronix, Inc., Graphics Workstations Div., Wilsonville, OR Lines: 101 Keywords: bus, Futurebus, IEEE 896 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)