🚀 go-pugleaf

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