Bwise blocks on Adapteva Cores

[theover]

Hi, this to let all who have interest know I thinking of starting a little project to run my Tcl/Tk on the Parallella, with the intention to run the processing of connected blocks in a functional decomposition graph on Adapteva cores (see ).

If there's interest I'll explain a little more about the rationale and possible scientific and practical use, but for the moment I'm thinking about how to synchronize the block communication on the Adapteva cores. Informed ideas are welcome!

M.Sc. T. Verelst

[theover]

Let's say I take the FFT example as a guideline, am I to take it that it doesn't really make schedule more than that cores run in a one-time sequence, with messaging being used purely as synchronisation?

Bwise works like this: a block has inputs and outputs, and will "fire" or execute it's function code once it has all it's inputs (fully) available. So if we take an add block, and I'd want to run the block on one core, let's presume it receives (presumably local Epiphany net, and a DMA connected interrupt (I forgot the specifics, but that would be normal)) a message from two other blocks, providing it with it's inputs, the "add" core can run it's code, place the result on it's output(s), and it will message all connected blocks it has run.

The advantage of this method theoretically comes from CSP and such (underlying Unix) and functional decomposition, but that gets into EE territory I might want to prevent here, and practically it could be implemented relatively efficiently an lead to a mapping of large computation graphs onto the 16 or 64 cores automatically. Essentially, if you provide a Bwise (I didn't invent the principle, but BWise is working implementation of the automatic scheduler that gives correct results) graph with it's inputs, the computations can be executed automatically, and lead to the correct result at the output node after all blocks have "fired" once.

So I'm thinking about a simple (but not dumb) implementation of a "block per core" with some C code as functionality for the blocks running on Epiphany cores.

Not a fancy suggestion for automatic load balancing and semi-automatic software parallelizing, but BWise running on the ARM could provide a fun parallel programming visualization which can yield practical real programs running in parallel on the Epiphany cores!

T.V.

[theover]

Ok, a little example for you guys, this is from my F.O.S. "Bwise" package, known for at least a decade and a half already, running on Tcl/Tk, as also runs on the standard Parallella distribution (maybe Tk needs to get installed with apt-get, I forgot):



So here we have an automatically generated array of processing blocks, with connection between them running from left side of a block (output) to right side of another block (input). Starting "funprop" from the popup menu on the left top blocl, will execute the blocks in such an order that the data is available at the inputs before the function associated with a block gets called, and the result of that function gets set at the output.

[theover]

If I would have (or make) the time for it, I could make some actual examples that make clear what my interest is in putting these kinds of block structures onto processing threads on the Adapteva cores.

First though, I will try to explain a major reason for wanting some better interactions between the ARM cores and the FPGA and preferably the possibility to mingle in the communication between the Epiphany and the ARM, by intercepting messages in the FPGA, or at least being able to know at which time which message is being passed from the AXI to the external pins of the Zynq chip.

For making timed computations like in audio, and keeping the possibility for short sample count interactions between audio streams, it will be beneficial to be able to time, and schedule messages or activity with much greater accuracy than the buses in use at the moment easily allow. So if I'd take a simple timer FPGA circuit, consisting of a clock input connected to one of the phases of the 600 MHz clock, connected to a counter with an enable input freely usable from various clocking/message-ready signals, and a "one shot" possibility meaning that the counter will count one time from enable to end of enable, and not after that unless it's reset. I could measure the various phase relations and absolute service times that are present in the current FPGA + connections, memory access and Epiphany activity.

A similar circuit can be used to not measure, but with the best available accuracy schedule activities in the FPGA and the ARMs and the Epiphany. This setup is within the FPGA in most cases a strict and absolute schedule making possibility, which isn't at the moment the case when data runs over all kinds of loosely times interfaces, competition for memory access and unclear Epiphany synchronization patterns. Starting from a correct functional-type graph, it is possible with this setup to work on tight and timing accurate machine designs, without leaving anything to chance, which I'd prefer.

T.V.