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 ) ?
@TonyTip "software defined peripherals has been done before"
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 :-)
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.