Parallella Community

typo: "pro-ponent"!

T

That's a relief ! It's funny how one can read something and not notice first time through. I mean, I thought 'proponent' due to the general context and your obvious enthusiasm for Parallella at first reading.

Anyhows one thing is fairly clear - and we've had enough time to sample this now - is that Parallella backers come from a really broad base of interests and initial positions in terms of knowledge and understanding. I knew virtually nothing about FPGA's, and now have a nodding acquaintance. I ( think I ... ) know a good deal about FFT's and I have a very particular application in mind : broadening the hardware set that the Einstein At Home project can run it's astronomical search software upon. That project encompasses many equipment types from the 'ancient' to the 'painfully expensive' ( clusters down to mobile phones ) but that has pyramidal/power-law demographics and so we are always looking to scoop up any otherwise quiescent moments on anything suitable. So for me, low tech is OK.

Cheers, Mike.

T.V. I share your concerns... I tend to see the present Epiphany product as a platform that can be used to develop tools and techniques rather than finished applications. And that seemingly eternal question that you put - "the amount of interest of another processor learning curve with the current surroundings to the project" - keeps bothering me: is it worth investing that time?

However the Investment by Ericsson might be an indication that they have found the Epiphany architecture to be a good match for Erlang and are thus putting some money behind it.

I'd also read that as 'pro-' rather than 'anti'.

There's enough tech built-in to the Parallella board for my purposes - too much. even, since I'll be running them headless, so HDMI and USB are not required. I have no specific applications in mind, although stuff such as E@home looks fascinating.

There will be many and various reasons for plunging in - or not - at this point in the life cycle of this prototype and inovative product. My aims are educational (my own) and have probably more in common with Raspberry Pi buyers, rather than hairy-a$$$d industrial engineers, who get their late-night highs from sniffing solder fumes.
Even without the Parallella board(s) in my hands, I've already learned a lot from background reading and 'thought experiments'. Dare I say, the delivery delays have already proved to be very productive AFAIAC?

Erlang came from Ericsson, but Ericsson are not Erlang (- historically, they effectively tried to kill it at one time!).
The Erlang VM is too big to fit on a single Epiphany core, it seems, so it's more likely that Ericsson have spotted another feature of the architecture, or simply the low-power characteristics. Whatever the reason may be, it's unlikely we'll see Ericsson products based on the E-16 32K chips in their current form.
I get the picture that even Adapteva treat E-16 as a proof-of-concept rather than something that makes serious money.

tery

I think if it works as more or less planned, and such as more than a few are able to try out from existing product delivery, my initial reasoning of Parallella having some suitability as a Poor Man's Zedboard and potential for high FLOPS DSP board will be quite right.

Added to that running a GUI Linux, network/usb, and no work to do to start up and run examples, it's a good deal.

The major "but" is that for the Adapteva chip to live up to some of it's potential, and for getting serious FPGA programming results, sufficient infrastructure and compile tools must be available and working enough. The last bandwidth measurement I recall being mentioned between the chip and the ARM memory simply was so low that my general parallel processing knowledge tells me that there's a problem. I also read the network on the chip takes 8 clock cycles per grid-hop, and there are setup times and so on. I suppose I'd hope for faster and less latency all over the place because I hoped for that possibility in chip design to be utilized.

Just playing around with some (working !) examples and putting some not-so-straining project on it should be fun though.

T.

I would hope some of the good abilities of the FPGA IO bandwidth would somehow have been utilized, even though maybe that actual bandwidth and latency (what is it in reality: .7 GByte/sec, few cycle latency ?) may only be practical when using another high speed device connected to the FPGA, or FPGA internal memory (block or random logic), for as far as there is any left after making the required buffers.

Ok, I wasn't aware read was much faster than write. Is the read only from the 2,3 or 4 nearest neighbors ?

About using the cache from the ARM: that's still not very much memory, and of course it must then be possible to somehow single out a piece of the cache (to keep coherence by having no interference with ARM cache use) AND have a sufficiently fast method of reading and writing it and keeping coherent efficiently, through the FPGA.

I'd rather have an extra bank of Static Rams connected in a fast way. I don't know what the fastest interface is to the Zinq 2010, maybe I'm too optimistic, but there are virtex-6es from only little newer date that have amazing communication bandwidth. Just like at least it will matter what type of IO pin definition you will use.

regards.

T.V.