Parallella Community

Thanks Andreas, that's encouraging info. IMO message-passing makes for a very clean software design.

There is something (probably not for this thread) that has left me puzzled - how to tackle CFD-type problems in the 32KB of memory that is available to each core. From my distant recollections of the Transputer work we did, there was a per-processor overhead of about 128K - mostly "payload" code compiled from Fortran, but also message-passing buffers.

But that's another question for the day that a Parallella board lands in my hands, with a suitably interesting problem to solve!

Mark

I fully agree, having Occam to supply the communication harness is exactly what I would like to see on the Epiphany.
The main problem is that Occam has a model of communicating channels to join the processing nodes together, and that is something that the Epiphany does not yet have.

I have recently ported the Transterpreter version of the University of Kent Kroc Occam to the Rasperry Pi, as a first stage model of porting it to the Parallella - works fine. (A really large chunk of source and tool-chain needed, though).

However the real hold-up for Occam on the Epiphany is the need for the communicating channels - doable, just needs someone who knows what they are doing !
cheers,
Beau Webber

I wouldn't say I know what I'm doing, but do have some ideas for very crude channel and PAR functionality. If a single process is mapped onto a Parallella core, there is no need to implement a scheduler, and the channel primitive can be based on busy-wait synchronisation in the same mould as the e-barrier routine provided by the SDK.

Is there an internet-accessible Parallella board on which I can give this a try?

For a more general solution it looks like the communication would need to be based on master-slave DMA - the documentation is not at all clear how that will behave if more than one master is simultaneously attempting to communication with a particular slave.

BTW a feature request for future versions of the Epiphany chip - for grid-partitioned parallel solvers, there is usually a 5-point stencil, i.e. data must be exchanged with 4 neighbours. Thus if the mesh network can handle 4 parallel transfers to adjacent cores, it would be useful to have 4 DMA engines available to perform those transfers concurrently.

Mark

Hi Mark,

I have a board that I can give you access to if that would help?
I shall send you the details via PM shortly.

Regards,
Ben

I am afraid that Yaniv let the cat out of the bag a little early. We are just now getting around to test some of these experimental features (two years old by now!) and I didn't want to release the spec until they were completely tested.

The message interrupt is indeed #5. Interrupt #8 is another secret one that we will hopefully disclosed by the middle of August. Interrupt #9 is the user interrupt.

Andreas