Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!mucs!r4!mshute From: mshute@r4.uucp (Malcolm Shute) Newsgroups: comp.arch Subject: Re: Bus Partitioning? Message-ID: <647@m1.cs.man.ac.uk> Date: 8 Feb 90 12:21:43 GMT References: <1990Jan30.174807.14657@ncsuvx.ncsu.edu> <6960003@hp-and.HP.COM> Sender: news@cs.man.ac.uk Reply-To: mshute@r4.UUCP (Malcolm Shute) Organization: University of Manchester, UK Lines: 39 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@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