Imagine an Arduino development board with the same footprint as an Arduino Mega or Due, but with the equivalent of 16 processor cores.

I just heard from my chum Tobias Strauch in Germany. It seems he's launched an interesting crowdfunded project called Arduissimo over on Indiegogo.com.

Tobias is a big proponent of a design realization technique he calls system hyper pipelining (SHP). Other people are interested in this. I just received an email from a university professor in England saying "Have you seen this project" (not knowing that I know Tobias, of course).

Here's the way I think about SHP. Have you ever worked a microcontroller-based project (for something like a robot or an embedded application) and run out of peripheral resources? One common solution is to create soft peripherals using code running on the main CPU coupled with some form of interrupt scheme. The problem is that this becomes very complicated very quickly.

Tobias's solution would be to provide a flexible set of virtual peripherals solely based on software, instead of having a fixed set peripherals implemented in hardware. He says using SHP won't hurt the main CPU's performance dramatically, because the virtual peripheral implementation is very efficient.

Another aspect to consider when using a microcontroller is that many applications could be quite naturally partitioned into sub-algorithms. In the case of a robot, for example, executing different functions on different processor cores in a multicore system is an obvious way to go.

All of which brings us back to Tobias's Indiegogo project, which we can think of as implementing multiple virtual Arduino processor cores on a single chip. First consider a traditional Arduino being programmed with the Arduino IDE.

The key point here is that there is a single Atmel AVR microcontroller core, along with program and data memory and a set of peripherals. You can program this using the Arduino IDE or other IDEs like the Atmel Studio.

Now consider the Arduissimo, as illustrated below, which boasts the equivalent of 16 processor cores, along with more program and data memory to run your code.

In this case, you program the board using an enhanced Arduino IDE -- called the Arduissimo IDE -- or (once again) alternatives like the Atmel Studio.

Tobias isn't simply replicating a single core multiple times. The whole point of SHP is to have a single instantiation of each of the functional units in the processor and to hyper-pipeline the inputs and outputs to each unit. This allows him to create the equivalent of more processor cores on a small FPGA, for example, than you would think possible.

In fact, the current Indiegogo project will be deployed on an FPGA-based development board with a footprint that looks identical to an Arduino Mega or Arduino Due.

Tobias tells me that, once the SHP concept is proven in the field using this FPGA-based project, then he may well launch a follow-up crowd-funding campaign to implement the Arduissimo on a much higher performance ASIC.

"The concept is also interesting to be used use in combination with the Raspberry Pi," he says. "But there are so many other aspects covered by this project that you have to visit my Indiegogo page and see everything for yourself."

Well, at a certain point, it is not about how many cores, it is more about, how can you feed them with instructions. When the memory wall reduces the system performance, then you might be better of with less processors. This is what I want to demonstrate with this project as well, that SHP pushes the limitation we have from the memory wall a little bit.

I remember having seen the 6502 on opencores.org. If it turns out to be a stable core, it shouldn't be a big deal to apply SHP on it.

By the way, you might want to tell your good lady wife, that this board will make you really happy. She should have a considerable amount of interest to make you happy, doesn't she ?

The initial version is based on the Atmega 2560 (so the full AVR-8 instruction set).

But there are others in the pipe: (MSP430, ARM3,) OpenRISC 1200 and a self designed Cortex M3, but I would like to release the AVR-8 first. You know, this project is not set up to compete with some other guys, it is more about to demonstrate how you can make off-the-shelf CPUs (e.g. opencores.org) more efficient using SHP, that's it. But I guess you know that since our good old APP times.

I'm not sure if SHP is a very, very known technique – otherwise it would be used more often, I guess. I will unroll the full technology concept of SHP in one of my next blogs on this site. So stay tuned.

So this project is more or less driven by some research fun and the enjoyment you have when analyzing the concept and when you are playing with it in real life. We will see where this all leads to and how it differs from other concepts (like the one you are referring to for instance).

If you like to go with some other concepts, go with it.

If you like to play with a new system architecture and providing suggestions how to improve it (just like some nerds do right now as I pen down these words) then feel welcome and help us by funding this project.

But since hyper pipelining is a known technique , whose to say someone like XMOS isn't using it in their chips ? It certainly looks so from their low cost.

So i wonder , whose you're target customer, and what benefits over xmos do you offer him ? one that justify the drawbacks of this against xmos(more expensive, less mature tools, no virtual periperial libraries, much less value in learning this system for experience ) ?

Well, I never said that I invented virtual peripherals, for sure I didn't. But the point is, that the technology I'm using (System Hyper Pipelining) has many advantages, especially for the system architecture. One out of many potential features is, that it is very, very suitable for virtual peripherals. Only because virtual peripherals are known since the beginning, does that mean I should not optimize the flow for it so user can utilize it.

I've never determined where the product name Arduino comes from, other than it's an Italian given name or surname. However, it seems to me it could be derived from the Italian word arduo which means "difficult" or "arduous". However, -ino is a diminutive suffix so arduino would mean "only a little difficult".

Following this reasoning, arduissimo would mean "really, really difficult". Not a great marketing concept for an FPGA product IMO :-)