scaleable parallella eLink connector

[piotr5]

what is needed is a connection between pec-south of one board to pec-north on another. this connector should read the eLink-protocol and alter addresses: messages going beyond row 33 must alter destination address by decreasing the row-number by 4. in that case whatever source-address must also be decreased by 4. row number of messages going in the opposite direction (i.e. before row 30) must be increased by 4. the actual row-numbers 30 and 33 don't need to be hard-coded, maybe draw some sign on the connector telling you which end goes to south and which goes to north.

the aim of such a connector is that you create a circle out of 16 parallella boards, and each board gets its parallella hardcoded so that epiphany-core 0 is located in row 30. maybe this violates specs for flat memory-space in amd's lib. but this way parallella truely is scaleable, with the possibility to connect an infinite amount of parallellas in a ring-topology for the Mesh-network. the way it is now, with connecting porcupine boards, you could only chain up 64 cores, 16 parallellas, and it can't be chained in a circle.

and as , the cable doing the connection must either be flat or the connector must have the connector going out at the side, or the connector must be practically without an actual cable in the strict sense and just have some elastic material between both sides which can allow both connectors to assume some angle between them, maybe rotate a bit maybe bend a bit to the side, nothing that could damage the actual connections. and of course the flexible material would need to remain flexible for a long time, not some cheap plastic...

also useful would be an actual connection between fpga, making use of the high bandwidth fpga actually is capable of. afaik a mere network-connector wont suffice. maybe 4x10G/s? the goal should be to let the arm processors communicate on a fast-lane...

and all this doesn't need to be done by adapteva. I'm just suggesting some possible project which eventually could actually be sold in a shop. and I'm no maker myself, so it's up to you to judge if such a project is feasible...

[jahorin]

[piotr5]

as was said in : to access another epiphany-core your dma-request contains a memory-address for 1M memory, and 2D coordinates, each coordinate with 6bit width. that means, future parallellas are limited to 1M on-core memory, and a grid of 64x63 epiphany cores...

if a message is sent, and the receiver is in the same column, then the message travels up or down till it leaves epiphany, and then goes through pec-north or pec-south. on the next epiphany it will continue to travel that way or go to the destination core. once it arrives there, the actual memory-address is used. so if you connect more than 16 parallellas that way, each occupying 4 rows, then eventually you'll have over-flow in the address space and messages will never arrive at the desired destination. now, if there were pec-west, then maybe you could add some more, but also this is limited -- and it's quite impossible to drill a pec-west connection anyway. eLink east is connected to fpga, so every message beyond column 3 will end up in arm if the fpga is programmed to handle that. if the destination to a message is to the east, no matter if north-east or south-east, it will always go to the east first, and once it leaves epiphany it wont go to pec-north/-south anymore.

I said 64x63 cores, but such a 4k-core parallella wont have pec-north and pec-south at all. and arm-access will be limited to 64M, this last row in the east which hopefully is not occupied by epiphany. (maybe first eCore could be set to column 63 to disable it.) in a similar way I guess also a 32x32 core epiphany makes little sense since only half of the pec-north and pec-south cores will be accessible. however, if there were a connector rewriting the address, even a 32x32 system could be possible since all epiphany processors start out in the middle-rows, leaving half the rows of neighbouring epiphany chips available. so, if adapteva doesn't change elink-protocol, then maybe I should add to my design-suggestion above that the number 4 shouldn't be hard-coded in hardware, for future generations to adapt...

you're right, it could be possible to attach a 17th parallella on whatever fpga-connectors. but this uses the same connection as data-transfer to arm. and theoretically it could be possible to redirect messages to another direction on software. but nobody has tried and it's likely more complicated than a hardware solution.

saying all this, it could be also my ignorance. I really don't know what RX and TX means. I'm assuming it means receiving and transferring, and the x stands for individual cables doing the connection. for this case I've written all the stuff, just to explain that the fault is on the epiphany chip and not in the porcupine-hardware, and that the problem could also be solved in software if you're stubborn enough. the point is that the message wont use pec-south if you're in the south-most core of this 64x64 grid, unless you redirect the message that way!

[9600]