🚀 go-pugleaf

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