Archived from groups: comp.sys.ibm.pc.hardware.chips (
More info?)
Larry R. Moore <larry.r.moore@att.net> wrote:
> David Wang wrote:
> >
> > My understanding of the EIB is that the rings are controlled by the
> > switching network actually labelled as EIB in the center of the chip.
> > The rings themselves as physical wires runs over parts of the SPE, and
> > the EIB reaches into the SPE's to direct on/off/repeat buffer
> > operations. The scheduling for the EIB is coordinated with the little
> > block labelled as MBL (Master Bus Logic? I'm not sure)
> But let me back up a little. When you refer to an "on/off/repeat
> buffer", is this a buffer of 128 bits that can be written (on), read
> (off), or transmitted to the next buffer on the ring (repeat)? Does
> this mean that a word outbound from SPE#1 is moved to the SPE#2 buffer
> in one bus cycle and then repeated to the SPE#3 inbound buffer in a
> second bus cycle? Is it accurate to say that the data rings are
> comprised of 128 twelve-stage shift registers, with additional logic at
> each stage to support read/write functions? This is, of course, an
> oversimplification. It must be a little more complicated than this
> because the Hofstee paper suggests that there are both inbound and
> outbound interfaces that can be used simultaneously to effect twelve
> transfers in one bus cycle.
I haven't thought about what happens when you have one buffer dumping
data off at the "off ramp", and the "on ramp" driving data onto the
next state. Perhaps that's where you'd lose half of your efficiency
@ 4 GHz, and get the 96 byte per second concurrency.
I'll think about it and draw myself a structure to illustrate the
dataflow later. Right now I'm supposed to be doing something more
productive.
> > Anyways, the reason why I think the "tag" runs to/from different places
> > is this: Data doesn't have to travel to all SPE's, it just has to travel
> > from source to destination, but the tag's have to be broadcast to all
> > SPE's due to the fact that the SPE's do have to snoop the tag (bus?)
> > for coherency of addresses in the host processor's address space.
> >
> Oh! You believe that "tag" is the name of a bus? Perhaps it was meant
> in the sense of "playing tag" with the data. They could be simple
> signals controlling ring selection, on, off and repeat logic at each
> interface. I don't know if 64 bits would be enough, though.
I think of it as the "tag" of a block of memory. Sort of like a
tag for a cacheline, but this is a tag for a block of memory
explicitly passed to and from the LS. That's what contains the
request in terms of PPE address pointer/size/source/destination.
> > That's why I think that the tag part is a differnt sort of animal
> > that lets you broadcast things, put address request on it, the EIB
> > controller then sets up the switching fabric that directs the
> > on/off/pass through operations on the data rings.
> You may be right. In order to avoid bus contention, the MBL could be
> bus master, polling each of the interfaces for data transfer requests
> and writing data transfer schedules. It must be an interesting
> algorithm.
I don't think the MBL needs to "poll" in the sense of asking each guy
what its status is. I'd imagine that a lookup table would exist
somewhere near the MBL that tells the MBL about which trasfer(s)
are occuring on the EIB, how long the trasnfer is for, and when
"resoruce X" will be free. The PPE can then tell the MBL to
schedule the next trasfer based on resource availability.
> > I don't think it's a packet network. I think the data rings just carry
> > data, and the request is encapsulated in the tag ring/bus/blah, that
> > request goes through the EIB/MBL, sets up the transfer, and tells the
> > destination guy that something is coming.
> Yes, it doesn't make sense to shove the tag onto a data ring that may
> already be in use and blocked. A fabric switch would have packet
> buffering and that capability has to be shoved back into the computing
> elements. Better to send the tag to the scheduler, the MLB, right away.
> I think it is safe to assume, however, that the data will be sent in
> measured packets to minimize the number of tag requests.
I think part of the request is "size". Doesn't seem like there's a need
for fixed size packets, I think since the LS is limited in size and
the user (through the use of the PPE) has explicit control as to when
the data migration occurs and when the data processing occurs, he/she
should be able to trade off packet sizes for specific applications.
Some threads may want to deal with 1 KB data chunks, while others may
be better with 64 KB data chunks. (Just a WAG)
--
davewang202(at)yahoo(dot)com
Facebook
Twitter
Instagram