The article is incorrect in saying that the (very simplistic...it's supposed to just show the basic components per core, not how it is actually functioning) diagram for a single core is the whole chip... our chip design has 256 of those cores (So in total, 256 64 bit ALUs and 256 64 bit FPUs). We have a custom mesh network that allows for atomic operations on from any core to any adjacent core, and DMA operations that allow for a read or write to any core's local scratchpad memory from any other scratchpad memory.

In comparison to other architectures, we have chose to stick to RISC, instead of some crazy VLIW or very long pipeline scheme. In doing this, we limit compiler complexity while still having very simple/efficient core design, and thus hopefully keeping every core's pipeline full and without hazards. The idea is that we just want to have a bunch of very simple and focused SPMD cores, so that we can have a MIMD/MPMD chip.

We are currently fixing the bugs on our single core FPGA demo, and hope to have our full 256 core cycle accurate simulator done by ~January/February. We want to release that (and our currently very early compilers) to the public ASAP.

I should also point out that it isn't just a bunch of ALUs or FPUs connected by a network... each core has it's own full execution logic, making each core a full 5-stage superscalar RISC core that can independently operate on its own instruction and own piece of data.

At the physical level, each core would have a 128k block that is ascending, but the idea is that our compilers would abstract that away from the programmer, and allocate memory based on what core needs it, and place it in that core's scratchpad, or as close as possible. The DMA capabilities abstract it when actually accessing memory, as it is just a series of (very simple) comparators that get the request to the write block of memory.

There are a lot, and I would recommend reading through this page... the basics on Epiphany (and the same can be said about most others) is the fact that we designed from the start to have a very high memory/IO bandwidth (both on and off chip), stuck to RISC, and focused on floating point (one of the few architectures in this area being fully IEEE compliant with this high of a performance per watt ratio).

So our current initial plans are to open source the ISA through the Open Compute Project (http://opencompute.org), using their reciprocal license. The HPC group within OCP that I co-lead has plans for HDL and RTL level submissions, but we are not sure what the timeframe or what would be included from REX (yet).

The business case for open sourcing the ISA is that we want others to be making compatible chips. As a small startup with a new architecture, it would be GREAT if others were to make competing chips, as it would only further the architecture and software ecosystem, making it more competitive with the existing market incumbents.

To us, our floating point unit is our "secret sauce", but as an open source enthusiast, I don't want that to be locked up forever. My general idea right now is that we want to be able to tape out our first chip (at least the prototypes for it), and will open source the HDL for the non "secret sauce" parts of it. As we get onto further generations, I do want to open source the full design of our previous chips for free/open use.

128K per core, so 32MB per chip. This is really just a fabrication/size limitation... we are planning for 28nm right now, and don't want our memory to use (too much) more power than our actual compute logic ;)

If we can go to 14/16nm in the future, we are planning 512 and 1024 core versions with different amounts of memory depending on if you are memory or compute bound.