Re: Network coprocessor on the F21

[Eugen Leitl <ui22204@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, 18 May 1995, Penio Penev wrote:

> On Thu, 18 May 1995, Eugen Leitl wrote:
> 
> > I understood Jeff meant that once initiated, the action will
> > run without requiring further attention from the processor.
> 
> > The only thing I didn't quite understand: how many links are
> > there? 
> 
> One input and one output.

So it is a kind of token-ring. This means the total cluster
size is severely limited. For large clusters this is a
clear bottleneck.
 
> > Can one patch through through every link to every link?
> 
> The signal has to travel through all intermediate processors, which 
> imposes a one-bit delay per node. This is essentially a ring topology. 

This is not so very. No big cluster, then.

> The only thing I didn't get was can you run the ring in both directions,
> or the direction is fixed once the processors are wired on the board. 
> 
> > Did you actually integrate a crossbar switch on the die?
> 
> No, it is not needed. There is no need for arbitration at the network
> level, since there is only one input and one output. The only arbitration
> is done for memory access by the memory coprocessor. But then, it is not a
> crossbar -- the low priority devices just wait. 

You are making it seem like a plus. It is certainly not. For a
time I thought this to be a kind of 4th Transputer. Obviously,
I was wrong.

> > Or does each transfer virtually block the processor?
> 
> If the packet isn't for the node, it is not noticed by the memory
> coprocessor. If it is, it consumes memory bandwidth. Whether the stack

I understand. I assumed there were several links. I thought there
was a means for each links to go off system until a message header
slides by, not blocking the other links. I was wrong.

> processor can do actual work meanwhiles depends on the total bandwidth to
> the DRAM requested by the various coprocessors, including the network one. 

Of course. It would be interesting to know how massive video action
does reduce mem bandwidth. But of course there are no benchmarks yet.

> I hope, that I'm not confused on this point :-)
> 
> --
> Penio Penev <Penev@venezia.Rockefeller.edu> 1-212-327-7423
> 
>