Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!romp!auschs!d75!cello!weasel.austin.ibm.com!alvitar From: alvitar@weasel.austin.ibm.com (Phillip L. Harbison) Newsgroups: comp.arch Subject: Re: VME Bus Standard Message-ID: <3070@cello.UUCP> Date: 29 Nov 89 21:09:06 GMT References: <112400007@uxa.cso.uiuc.edu> <11759@phoenix.Princeton.EDU> Sender: news@cello.UUCP Lines: 124 In article <112400007@uxa.cso.uiuc.edu>, afgg6490@uxa.cso.uiuc.edu writes: > A while back M. Faiman of the UIUC said something to me > that crystallized my feelings on the subject of busses: > It's time we got some RISC busses. > I'd like to start a conversation string on this. > Topics: > What (CISCy) features are there in existing busses that > could be eliminated? [1] No justified data busses! A justified data bus requires byte shuffling such that a byte transfer always takes place on the first byte path and a word transfer takes place on the first two byte paths. I suppose the same concept can be extended to 32-bit transfers over a 64-bit bus. Multibus I, Multibus II, and most PC busses use a justified data bus. An unjustified data bus always transfers bytes within a "stripe" of memory space over the same byte path. For example, on a 32-bit unjustified data bus, the byte path is the address anded with 011 (binary). Therefore, all bytes ending in xxx00 transfer over byte path 0, xxxx01 over byte path 1, etc. Only one transceiver is required for each byte path. Nubus uses an unjustified data bus, and I believe Futurebus does too. VME is inconsistent since it uses unjustified transfers on the 16-bit bus but justified transfers on the 32-bit bus. These transceivers use alot of board space (especially on tiny Eurocards), waste power, and add extra delay. The following table shows the number of transceivers required to implement justified and unjustified busses. Number of Transceivers Bus Size Justified Unjustified Transfer Sizes -------- --------- ----------- -------------- 8-bit 1 1 8 bits 16-bit 3 2 8, 16 bits 32-bit 8 4 8, 16, 32 bits 64-bit 20 8 8, 16, 32, 64 bits Keep in mind that this circuitry must be repeated on every card. For a 16 card system using a 32-bit justified data bus, that's 64 extra chips! Of course the shuffle network has to be implemented somewhere, but why not do it on the CPU card? Most modern micros implement this on the chip anyway. (at the the 68020, 68030, 88200, 386, and probably many more) [2] Get rid of daisy-chained signal lines! I'm talking about signals that go into a board on one pin and out on some other pin. In other words, a board must occupy every slot or you must have a jumper connection to maintain continuity. Not only is this a con- figuration hassle for the user, but it makes it difficult to implement hot card replacement (removing or inserting cards with power on). This is very important in many fault-tolerant systems. [3] Get rid of centralized resource managers. Picture this: your $5000 CPU card, $4000 DRAM card, $2000 disk controller and $2000 serial port controller are all working fine; however, because a $500 system controller card is broken, the whole system is useless. Most older busses used centralized bus arbiters. NuBus, FutureBus, and Multi- Bus2 all use distributed arbiters. > What is the set of "good ideas" that should be in new busses? [1] Geographic Addressing Have some pins on each connector that identify the slot number. The board can use this information to select an address range. Given that each board can be uniquely addressed automatically, it is possible to design systems with few or no jumpers and DIP switches. The system configuration software can probe each slot to determine which resources are present, then install the appropriate drivers, kernel options, device inodes, etc. This feature is supported by NuBus, FutureBus, and MultiBus2. [2] Try-Again Signal There should be a signal or combination of signals that indicate the pending bus cycle should be retried at a later time. This provides a hook for some cache consistency protocols, and makes it easier to implement bus couplers between two busses. NuBus has this, and I believe FutureBus and Multibus2 also have it. This is a glaring deficiency of VME bus since the only option is to complete a bus cycle or issue a bus error. The latter is a severe reaction to what may be a temporary resource conflict. [3] Cache Consistency (or Coherency) This is a must for multi-processor systems, or even single processor systems where there are other bus masters (DMA devices) and the processor has cache. Support should be provided for snooping the bus, preempting a cycle, and performing a write-back operation. FutureBus has already done a great job defining a family of consistency protocols. NuBus has most of the hooks, but last I heard, no standardized protocol. [4] Pin & Socket Connectors Use decent connectors, like the DIN-41612 connectors used in VME, NuBus, FutureBus, and MultiBus2. I hate the edge connectors used in MultiBus I and the PC. Those infernal EISA multi-level connectors are even worse: all the cost of pin & socket connectors without the reliability. Pin & socket connectors have good density and superior retention force and resistance to contaminants. Another good selection would be those 3- and 4-row modular connectors made by Amp. Talk about pin density! [5] Support Redundant Busses Allow two busses to be operated in parallel, sharing the work load, with a clean mechanism to switching all the traffic to one bus if the other bus breaks. [6] Hardware Semaphores Provide semaphore support for multiple processors. This should work much like bus arbitration, with waiting processors spinning on the busy semaphore without using any bus cycles. Just a few ideas to get things started. This is one of my favorite subjects, as if you couldn't tell by the size of this article. :-) If you need to reply to me, use the address below instead of the one in the header since I'll be long gone from IBM (thank God!) before most of the net gets this. ---- Live: Phil Harbison, soon to be at Xavax, Inc. Mail: alvitar@uahcs1.UUCP or alvitar@xavax.UUCP "Skin it back!" - The Unknown Blues Band Brought to you by Super Global Mega Corp .com