Also wish you good luck and recommend change focus: First figure out, what kind of real world problems this architecture can handle and how to do it best. The a

Also wish you good luck and recommend change focus: First figure out, what kind of real world problems this architecture can handle and how to do it best. The architecture will perform very well, if the number of operations, which can do done on a set of data fitting into the scratchpad memory is large, so that communication overhead is small or if the problem can be mapped to the grid in a way that they only require communication with the neighbours. However I would assume that typical real world big data problems don't fulfill these requirements and problems fulfilling them also run well on classical architectures. As soon as you start to need a lot of data transfer, only the cores close to the border of the grid will be able to work, as they get data, the ones at the border are busy with forwarding data to the memory and the innermost just wait ... Therefore before investing a lot of effort, money and time into a hardware, which many others also do in very similar ways and ask the community to find out, how to use it, spend the energy in innovative ideas to actually efficiently use such architectures. I.e. languages, profiling and debug tools, ... That's where the real innovation is needed and where there is a lot of room for improvement. And if you want to stay with hardware it is probably much easier to convince investors, if you can show in a simulation of FPGA prototype that 2 or 3 real world applications showing a very bad performance on classical machines can achieve a substantive boost on your architecture ...