Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!samsung!shadooby!yale!cmcl2!lanl!opus!pfeiffer
From: pfeiffer@nmsu.edu (Joe Pfeiffer)
Newsgroups: comp.arch
Subject: RISC bus (was Re: VME Bus Standard)
Message-ID: <PFEIFFER.89Dec19101719@puye.nmsu.edu>
Date: 19 Dec 89 17:17:19 GMT
References: <11759@phoenix.Princeton.EDU> <112400016@uxa.cso.uiuc.edu>
Sender: news@nmsu.edu
Organization: NMSU Computer Science
Lines: 19
In-reply-to: afgg6490@uxa.cso.uiuc.edu's message of 15 Dec 89 10:30:45 GMT

afgg6490@uxa.cso.uiuc.edu, in <112400016@uxa.cso.uiuc.edu>:

| OK, let me make some suggestions for a RISC bus:

 (neat ideas deleted)

| Now I'll go out on a limb.
|
| (N->infinity)  Forget about arbitration fairness.  Software can implement
|     fairness at the process level (eg. by counting blocked bus cycles and 
|    scheduling processes to even them out).

I don't like this, since multiple DMAs can get troublesome.  How about
the Bus Arbitration Tranceiver Manipulation (that's BATMAN) chip that
is used by all devices for arbitration implementing the algorithm in
hardware?  The busier the bus, the more bus cycles it'll wait before
trying again.  Software programmable for priority, of course.

-Joe Pfeiffer.