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: <112400016@uxa.cso.uiuc.edu>
Date: 15 Dec 89 10:30:45 GMT
References: <11759@phoenix.Princeton.EDU>
Lines: 25
Nf-ID: #R:phoenix.Princeton.EDU:11759:uxa.cso.uiuc.edu:112400016:000:1062
Nf-From: uxa.cso.uiuc.edu!afgg6490    Dec 14 10:32:00 1989


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

(1) All transactions are disconnected or split.
    Possibly an arbitration preemption line if the response is
    immediately available. (IE. you don't assume connected
    and then change over to split depending on ACK. You assume split.
    Connected = split with immediate response separate).

(2) Throw out all the fancy synchronization operations.
    Provide (i) a LOCK signal that can be applied only to a single
    resource of less than bus width. Let software protocols handle
    multiple resource locking - don't require the bus interfaces
    to track it.
      If you feel adventurous, provide (ii) a remote load-store-fixed
    or compare-and-swap, or (ii) a remote fetch-and-add.  These
    because they possibly permit combining.
      Probably only provide one of them.


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).