Parallella, Raspberry Pi, FPGA & All That Stuff

Hmmmm. So now I'm somewhat more interested in Epiphany again, if V comes through. You may recall, or wish to forget, an analysis I did of the E16 variant of III for FFTs. The basic disappointment then was insufficient memory per RISC core and not enough cores. This would not really grasp the FFT tasks at E@H ie. ~ 2²² data points, at least not without considerable off-chip assistance/processing that yields mainly serial behaviour rather than parallel advantages.

Back Of The Envelope :

- 64KB per core in four banks of 16KB.

- you can have two of those banks for pure data. The other two are for code and stack.

- using single precision floating point you have 4 bytes per operand.

- that gives 32KB / 4 = 8K of single precision operands ( SPO ).

- per original time series data point you then need : 2 SPO for the data itself + 2 SPO for a twiddle factor + 2 SPO for the emitted result = 6 SPO.

( Express result as amplitude + phase per frequency value, or a coefficient each for a sine and a cosine. Remembering that in the amalgamation phase we are generating complex numbers from a lower order FFT to create a higher order FFT. Depending on what you are up to you may ignore phase at the very end* of the analysis but you can't discard it en-route. )

- thus, with some headroom, you can manage 1K = 1024 = 2¹⁰ data points per core

- and we have 2¹⁰ cores !

- hence, at least on room-for-data grounds, we can grasp a 2²⁰ point FFT per Epiphany V chip.

Also keep in mind that a Parallella E16 board/variant had an ARM and an FPGA, oodles of commonly addressed DRAM ( 1GB ). Plenty to manage at least two vectors each 2²² of 4 byte operands ( 32MB total ) ie. input and output no sweat. Interesting ...... :-))

Cheers, Mike.

( edit ) Two banks of 16KB each immediately suggests keeping the real part of operands in one and the imaginary part in the other. For loops, per operand, that's the same index but different constant offsets.

* Or at the very start for that matter.

So here's a thought or nine more :

- the Epiphany V will realise in actual silicon 1/4 of the entire Epiphany architecture ( as patented say ). The total design limit is 64 x 64 = 4096 cores. Think of that entirety as virtual space into which a real device may be inserted/constructed. 

- a given subset will be ( hardware ) mapped to some sub-array of addresses with said architecture to produce a particular SoC.

- software : each core at run time may be given the statically bound subset of the libraries as defined in the provided SDK. That is to say each core may commence operation with it's own little copy of an operating system ( Epiphany Run-Time library & stuff ).

- if so, that is of course convenient because someone else has done all that aspect of the work for you. The libraries are written in C, have an ABI for custom assembler code as mentioned, have some awesome & optimised functions, and will compile smoothly with any application one may write in C & include for some purpose.

- you don't have to do that at all. One may choose to crawl over broken glass on hands and knees to designate and execute every assembly level specified operation from go to whoa on the entire Epiphany V. Just use a host side loader to initialise the core array and then trigger the go button. LOL. What A Great Plan. :-)

- now from the point of view of a given core, some memory is addressable which doesn't truly lie within another core in the physical core array. It may map externally to the chip in fact, but logically seems to be in the Epiphany design space ( a large flat byte granular space ).  

- fortunately there is a host side to the SDK too ( Epiphany Hardware Abstraction Layer ). Here we would be more relaxed in constraints : plenty of memory, plenty of time, at least a decent ARM system to play with ( but could even be a Linux PC say ). No reason to optimise that aspect what-so-ever.

- now an interesting question becomes : what is the memory footprint per-core to allow for the 'luxury' of those library elements being present ? In detail that depends on the intra-library structure, exact choice of routines referred to in code, some linker flags etc.

... that 's the memory used within the above red box. A task then would be to create a “ Hello World” program and then gauge it ..... the provided debugger ( e- gdb, based on gdb ) should do that nicely. By subtraction, and with alignment constraints, one can then estimate more closely the maximum allowable number of operands for an FFT.

Cheers, Mike.