Article View: comp.arch
Article #21745Re: VME Bus Standard
From: afgg6490
Date: Fri, 15 Dec 1989 10:30
Date: Fri, 15 Dec 1989 10:30
25 lines
1570 bytes
1570 bytes
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).
Technical Details
Message-ID:
<112400016@uxa.cso.uiuc.edu>Path:
arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!afgg6490References:
<11759@phoenix.Princeton.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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