Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!zephyr.ens.tek.com!orca.wv.tek.com!leia!opus!johnt From: johnt@opus.WV.TEK.COM (John Theus;685-2564;61-183;625-6654;hammer) Newsgroups: comp.arch Subject: Re: VME Bus Standard (really Futurebus+) Keywords: Futurebus Message-ID: <275@leia.WV.TEK.COM> Date: 15 Dec 89 07:25:22 GMT References: <7172@pt.cs.cmu.edu> <112400007@uxa.cso.uiuc.edu> <390@blenheim.nsc.com> <411@blenheim.nsc.com> Sender: johnt@leia.WV.TEK.COM Reply-To: johnt@opus.WV.TEK.COM (John Theus) Organization: Tektronix, Inc., Wilsonville, OR Lines: 82 In article <411@blenheim.nsc.com> des@dtg.nsc.com (Desmond Young) writes: > >One comment, there is a group of (future) Futurebus+ users in Europe >that have sent out fliers (should that be flyers?) encouraging >people to join their effort to: > "define useable subsets of Futurebus +". > This does hint at the very (very) CISC nature of Futurebus+. It has >every facility (almost) ever dreamt of. As an analogy to CISC >processors, it almost has a single instruction to compile a program > :-). (Well, a wee bit of an exaggeration). >Anyway, if you want to go fast, it has too much baggage. >My Opinion etc. I'm not sure what flyer Des has seen, but the one I have was not produced by the FMUG group in England, but by a couple of guys located in the northeast. They are trying to form FIA, the Futurebus Implementors Association. In my opinion they are trying make a buck off the Futurebus bandwagon by setting up this group and then charging management fees. They held their first meeting last week at the site of the Futurebus+ meeting. I should point out that this activity is in no way associated with the IEEE sponsored Futurebus effort, and that the 2 principals have not been contributors to the development of the standard. The stated purpose of FIA is to produce a subset document of the Futurebus+ standard and then lead the development of a silicon implementation. They passed out a strawman proposal to show us how they would subset the documents. Basically, their proposal went down in flames; for several reasons. The simple ones were: hey, we're already doing all that; and technically, you don't know what you are talking about. In the latter case, their subset would have broken several of the protocols. Futurebus+ has a 4 bit transaction command code that is transmitted with each address. In their subset, they picked some of the codes but not others that are required to use the first set. For example, they included some of the cache coherence codes, but left out the codes for invalidate and copyback. In addition, their subset would not have supported any of the lock facilities. In the first case, several commercial silicon companies are working on chip designs that, assuming they follow the spec, will work together properly. At the board level we realize this is a much harder problem. The boards for this bus will occupy a very large design space; much larger than any previous standard bus - the CISC factor. Futurebus+ as a whole provides a large number of facilities that no single board will fully implement. As examples; coherent caches, message passing, live insertion, dual redundant buses, split transactions (write-only protocols), etc. At the physical layer there are issues of board size, electrical environment, and physical environment. The range includes the Navy putting Futurebus+ boards in combat vehicles to HP talking about Futurebus+ boards in a desktop PC. To focus this range of applications into distinct groups, the 896.2 standard (Futurebus is the IEEE 896.x family of standards) will include chapters called profiles. At present 2 profiles are being developed; one for general purpose computing, the VMEbus replacement, and the other for I/O applications, which is being led by DEC. As we better understand the needs of these two applications, these profiles may merge. Clearly the Navy's profile for their combat applications will be very different. The profiles specify the physical, electrical and protocol decisions that are required to ensure interoperability among all boards built to the profile. The question is whether RISC vs. CISC is a meaningful discussion for a bus, especially an industry standard bus. Probably most well-designed proprietary buses are RISC, simply because a company usually designs a bus for a specific application and its not cost effective to carry excess baggage. I don't expect to ever see an industry-standard RISC bus, simply because the market for it will be too small. In fact I think Futurebus+ will be the last great bus. As more and more systems require greater than a few Gbytes/sec of bandwidth, buses will be replaced by switch-based interconnect schemes such as SCI, and I wouldn't call switch routing RISC. Finally, as you might expect from my title, I have a different opinion about the obtainable performance with Futurebus+. Fast is of course a relative term, so I'll just state that I expect to be building hardware next year that can sustain more than 500 MBytes/sec. on a 64 bit wide Futurebus+. John Theus johnt@opus.wv.tek.com Futurebus+ Parallel Protocol Coordinator Tektronix, Inc. Interactive Technologies Div. - shipping the Futurebus-based XD88 workstations