Path: utzoo!utgpu!attcan!uunet!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: Self-modifying code (and bitblt
Message-ID: <489@m3.mfci.UUCP>
Date: 31 Jul 88 02:51:02 GMT
References: <308@laic.UUCP> <28200183@urbsdc>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 65

>Just read the IEEE Transactions on Computers article on 
>Multiflow's TRACE machines. 
>
>    Questions: Exactly how does the store register file
>on the floating point subsystem operate?

The data that you'd like to have end up in memory, you put into the
SRF first.  When you kick off a memory store, it's an integer opcode
-- the integer section has the DTLB.  This was done so that the
floating section can keep cranking out flops while the integer
section can keep track of loop indices, memory addresses, and other
scalar types of things.  The SRF is a legitimate target of a flop or
an integer op.

>    You mention that there are only 8 32 bit busses across
>the board edge. Exactly what are they? Are address and data busses split?

By "address bus" I assume you mean physical address bus to memory;
those are "dedicated" in the sense that they only carry addresses,
never data.  There are also a set of store buses that carry data to
the memory controllers on stores.  There are eight other buses,
four FL buses and four IL buses.  The "L" means Load, but these buses
are also used to carry certain cluster-to-cluster transfers.
Buses are all tagged as to destination, and self-drain in the event
of stalls, traps, etc.

>Are there more busses
>in the system, but only a subset to any board? 

Yes, the integer boards get the four IL buses, one of the physical
address buses each, and two IF buses (that don't count because
they're carried over very short cables to their floating-point
board-pair).  The floating boards touch all four FL buses and all
four Store buses -- that's where the eight comes from.  By the way,
if it wasn't clear -- in figure 4 of the paper, the "I3,I2,I1,I0"
boxes are the Integer boards, the Fn boxes are the Floating boards,
and the Mn boxes are the memory controllers.

>    Everybody I know who has a reason to know the details of
>the TRACE says that it is loaded down with crossbars. How and
>where?

There are a lot of crossbars, but "loaded down?"  If you have a lot
of general-purpose buses, you need a fair amount of muxing hardware
somewhere in order to take advantage of it.  Once you've paid the
price for having all those buses (bus drivers everywhere you look),
providing the crossbars to maximize the win only seems right.
Besides, in this architecture, you can put those crossbars into the
gate arrays.  The only place we couldn't make them fit was on the
store buses, so there's a bunch of PALs to handle it there (10 or so
per F board, I guess?).  The main places that come to mind are the
inputs to the Register Files (both integer and floating -- they're
built from the same gate array type), and the store file outputs.

Also, don't skim over the point we made in the article too fast about
putting a full crossbar between address generators and memory.  If
you don't do this, the compiler has to exactly where something is in
memory (or is going to be) in order to schedule the bus to transfer
the datum.  With a crossbar, the compiler only has to know where
something is relative to everything else, an easier task.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090