🚀 go-pugleaf

In article <6960003@hp-and.HP.COM> panek@hp-and.HP.COM (Jon Panek) writes:

>[...]  So far, most of the responses have
>quickly extrapolated to the NxM cross-bar architecture.  While this is
>obviously the most general-purpose and most flexible one, it also incurs
>the highest implementation cost.

But going further to the NxN case *can* allow a sudden halving in the
implementation cost over the NxM case (with M -> N )
(You can dispense with half the switches if
you treat each bus as being owned by a particular node).

>By having a single linear bus with CPUs and Memory distributed along it
>in sections which can either be connected to the segments on either side
>of it or not, the implementation aspect becomes much more tractable.

This sounds like a variation of a nearest-neighbour vector network:

               -O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-

where "-O-" is a module containing all of the CPUs and memories
which share a common local bus.


And in article <AGLEW.90Jan31205148@dwarfs.csg.uiuc.edu> aglew@dwarfs.csg.uiuc.edu (Andy Glew) writes:

>One of the busses may be designated the "global" bus, listened to by all 
>processors.
>    Others might be allocated to connect groups of processors (and I/O
>controllers) as needed.  This reconfiguration would be done infrequently.
>    So, for example, if you have an I/O going on, allocate it a bus
>for the (long) duration of the I/O.
>    Or, if a group of programs appear to communicate heavily, allocate
>them a private bus.

This sounds like an implementation of a tree network.

Malcolm Shute.         (The AM Mollusc:   v_@_ )        Disclaimer: all