Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!portal!cup.portal.com!mmm
From: mmm@cup.portal.com (Mark Robert Thorson)
Newsgroups: comp.arch
Subject: The Future of Buses (and Futurebus)
Message-ID: <36734@cup.portal.com>
Date: 9 Dec 90 22:34:12 GMT
Organization: The Portal System (TM)
Lines: 30

What are the likely successors to VME, and why?  How is the role of
the bus in computer architecture likely to change?  How significant
will Futurebus+ become?

It strikes me that "Futurebus" is about the worst name that the IEEE
committee could have chosen.  Their goal is an architectural definition
which will live through several incarnations of implementation technology.
Should they succeed, the name "Futurebus" will seem as anachronistic in 30
years as the name "Futuretran" or "Futurebol" would seem today, had it
been applied to Fortran or Cobol.

But much worse is PR image it creates -- the image that "Futurebus" is a
bus in the sense of more familiar buses like Multibus, VME, etc.  It is
an architecture for a network of processors, memory, caches, bus repeaters,
etc.  It is a certain type of model, in which everybody sees the same
memory space, with cache coherency maintained in hardware.

It seems like a very general model, one which can be viewed as a superset
of more restricted models such as those which do not provide cache
coherency, and yet one which should have an implementation cost competitive
with that of the more restricted models.  At the same time, it imposes
very few restrictions on the network architecture.  You can't have loops
or redundant paths, but other than that the network organization is
arbitrary.

So what does comp.arch think?  Is Futurebus+ a model which can serve all
of our needs for the next 10-20 years?  Or is the model inappropriate for
what we'll be doing with buses in the future (i.e. will the role of the
bus change)?  Or am I asking the wrong questions -- what are the right
questions when trying to predict the future of buses?