Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!afgg6490
From: afgg6490@uxa.cso.uiuc.edu
Newsgroups: comp.arch
Subject: Re: VME Bus Standard
Message-ID: <112400015@uxa.cso.uiuc.edu>
Date: 15 Dec 89 10:29:43 GMT
References: <11759@phoenix.Princeton.EDU>
Lines: 48
Nf-ID: #R:phoenix.Princeton.EDU:11759:uxa.cso.uiuc.edu:112400015:000:2604
Nf-From: uxa.cso.uiuc.edu!afgg6490    Dec 14 10:23:00 1989


>Nubus, Multibus II, and Futurebus all use the same basic parallel
>contention logic for resolving multiple requests.  A "fairness"
>protocol is layered over this logic.  In order to allow real-time
>priority scheduling, a priority protocol also must be layered.
>None of this is easy; all of it takes time, bus lines, or both.

Does the "distributed arbitration" protocol not implicitly
provide priority arbitration directly? IE. cannot the arbitration code
be a fixed numerical priority?  
    I think that the problem is that when non-priority arbitration codes
get layered on top of the distributed arbitration scheme (ones in which
you effectively manipulate the level of the arbitration code) you have to
devote sufficient logic that the simplicity of fixed priority arbitration
gets lost.

>Some aspects of Futurebus+ arbitration are limited by the slowest logic
>in the system, some by the slowest in a group of competitors, and some
>only by the speed of the winning board.  This makes the implementation
>of the protocol critical.  Synchronizing to any clock is suicide.  The
>protocol is complex, but the committee had a number of historical,
>political, and schedule constraints, as well as functional ones (eg,
>real-time priority scheduling).  Bus interface silicon should eventually
>hide some of this complexity, as well as improve speed.

(1) Could you list, for the benefit of readers, which actions are
limited by what? (Else I'll have to dig through my spec).

(2) It would be interesting to see what bus interface implementations for
existing busses, both discrete and integrated, are truly asynchronous
versus synchronous, synchronizing the asynch bus signals to an internal
clock.
    Saying "bus interface silicon should hide complexity" is a bit of a
cop out - yeah, sure, but look how long it took for decent VME bus interface
chips to come out (particu;larly the VITA chip, for people who didn't
want to buy Motorola's VME chip).  I do not know of any VME chip 
interface that is truly asynchronous.  It sure would be nice if
the spec made real asynch implementations easier.

(Of course, there is some hope that the resurgence of asynch techniques,
a la Sutherland, may make asynch implementations easier for the average
Joe designer of the bus interface logic.  That's been the real bottleneck
- not that asynch is terribly hard, just that it's less well known).

Note that I am not against FUTUREBUS and FUTUREBUS+ -- the fact that
they are becoming standards is great.
    What I am asking about is what a RISC bus would look like,
faster than FUTUREBUS+, or less complex.