Parallella Community

20-20 hindsight suggestion I made to Diana already:

Most of Aptiva's Parallella issues have nothing to do with core Epiphany competence, but are general board-level or Unix-level issues. Epiphanies built onto an Arduino
shield so they could offload that aspect to eg the new Intel Galileo or Arduino Due or the upcoming TRE now that those boards have reasonable horsepower, or even to a BeagleBoard or the Raspberry Pi itself, might have been a lot easier for the company to get out the door, leaving the general board development to someone else, and for users to work with. Still could do a shield or RPI daughter card I suppose, once the Parallella is fully out the door.

Dan

Even with the recent more powerful Arduino models it's still a microcontroller platform, and as such this would severely limit what you could do with it.

The trouble with a Raspberry Pi or BeagleBone add-on is going to be bandwidth to the Epiphany. Plus also you're then into a two board solution before you start thinking about any hardware expansion/peripherals for your particular application.

It's still early days and things with get a lot smoother, and I suspect quite quickly as boards start shipping in volume.

Cheers,

Andrew

I'd just like to add that the Raspberry Pi is not even worth considering, on the basis that it's using an ancient ARM v6 processor that doesn't support VFP v3.

IMO the Zynq is key to the usefulness of Parallella because the Epiphany's outside would interfaces are e-links and these are not available off-the-shelf. Having the host tightly coupled to the FPGA logic keeps the board simple and the relatively powerful host (by uC standards) gives one a fighting chance to keep the Epiphany fed with data (there's a LOT of raw processing power there!). The powerful host also permits a variety of programming styles (e.g. OpenCL needs a fairly tightly coupled system) and strategies for dividing functionality between the host and Epiphany.

So I'm not convinced that an Epiphany shield/daughterboard would not have significantly reduced the amount of new technology (and thus risk of delay) involved. Maybe the lesson is to avoid non-essential risks (e.g. the single-sourced RAM chip) and set delivery expectations based on the knowledge that where there is new technology, there too Murphy and his law will make an appearance. Writing that, I see the finger pointing more at myself than anyone else, and it's probably time to go off and read "The Mythical Man-Month" AGAIN.

Well, all those sound like great reasons.

But having had the uUSB and uHDMI connectors snap off one of my 4 gen1 boards, the 3 remaining USBs fry out apparently due to high current draw from unpowered usb wireless ethernet adapters (NOT powered hubs), and now one of the 4 rendered useless even for ssh due to rebooting over and over even with fresh image and sd card for some unknown reason, I have to conclude that the boards seem incredibly fragile and not ready for prime time yet. Even aside from component availability delays.

Software-wise, they're also just a time-consuming struggle to work with. Some of that is the relative immaturity of ARM versus x86; some of that is the old Ubuntu 12.04 PoC image, some of it I don't know what. For example, my project uses NFS mounts from a Synology appliance. From a $100 x86 AMD E2-1800 Zotac running Ubuntu 13.10, apt-get install nfs-common and you're done in minutes with decent performance. From the Parallellas, nfs-common installs... but it's broken, and you spend hours trying stuff. Even the older ARM_based original 1G gige Cubox that I'm using as a project scheduler, though non-existent support and no Epiphany, is a lot more stable due to the optimized server Ubuntu 12.10 version they put out. Andreas has promised improvements to that Ubuntu image weeks ago, but they haven't happened yet, so I guess everyone is on their own OS-wise to get something more workable at least for the moment... Yes, I understand everyone is tied up with manufacturing issues right now.

So you can see why I wish I were working with a lot more mature board like a BeagleBoard or a Galileo as a base, and could access the Epiphanies via some much-less-problematic daughter card, even if that were a much less ideal architecture. Sure, IF I ever get the stable working clusters I paid for before the end of my project, and IF I ever get the Epiphany cluster cables, I'm sure all that tight coupling will be nice...

Dan