Let’s play with numbers
The study covered 88 CPU projects.
16 (18%) CPU have no license text and no license header in the files. To my opinion that makes them unusable, anyway most of them are also not active. In any case it show that the developer didn’t really care about how other could use his work.
At least 47 (53%) appear to be inactive. Most looks like design dropped here and forgotten. Well that’s life, but if you start a project with such core, you will end-up being your own support… not a comfortable place.
On the other hand, 24 (27%) looked really active with 13 (14%) being marked as ‘stable’ (whatever that means).
Let’s look at the category, I must admit that I didn’t fill the category for some inactive project as I didn’t look into enough detail to choose one. Also few projects are clones of legacy architecture, well this could be a category on its own…
So we have:
- 20 (22%) embedded CPU
- 1 (1%) high end CPU
- 3 (3%) portable CPU
- 41 (46%) tiny micro-controller
- the rest being unclassified for various reason stated above.
Well I guess my limit between embedded CPU and portable CPU is kind of subjective, I would say that embedded CPU don’t need and MMU nor 64bit data path.
Anyway That’s more embedded CPU than I though, I mean I had the impression to fill only tiny micro-controller, as many small project driven by one developer are just that anyway.
29 (32%) uses GCC or provide patch to GCC. (Some CPU are clone so they kind of have it for free). And most of the embedded CPU have gcc support, and all portable and high end CPU have too.
And most tiny micro-controller don’t use GCC, except mainly AVR clones. But that’s normal, most are programmed in assembly anyway, others are so simple that writing a compiler would be longer than writing the CPU !
What looks really usable ?
Well first I’m not looking at tiny micro-controllers, their use is really specific to one’s need and it’s hard to be generic. Also some need are simple enough to let you write your own core and add it to the long existing list of tiny useful only to one person micro-controllers 😉
There is not much to say about high end and portable CPU. You have to like SPARC, as most of them are. The alternative and that looks more in the open source spirit of all is Open RISC 1000 with it’s OR1200 implementation.
Now about embedded CPU, my primary target for this study anyway. What do we have?
- Several MIPS like/clone/based (call them what you want): well, the letter on Yellow Star kind of push me to discard all those as a whole. The option is not clear enough.
- Several 68k clones: well there is no threat visible but those are still clones… Can’t we have something really free.
- Some MicroBlase clones: Well xilinx pushed to get linux support for MicroBlase, so they started to understand what open source is… but still this is not based on a free architecture.
Sad picture…
So what live project remains then ?
The LatticeMico32, an open hardware project already adopted it: Milkymist so you won’t be the first to use it.
Sadly I’m not really convinced by their open source view… maybe I’m wrong.
The other Idea is to cut the MMU out of the OR1200 to get an embedded CPU 😉 but I don’t know how much support one would get from the authors then.
The final word
Also I’ve not run any performance tests but I don’t think I’ve found any CPU that would perform like an ARM7TDMI with thumb or a MIPS with mips-16 instruction set.
The compact (16bit) instruction set on a 32bit architecture gives a real gain when the memory bandwidth is limited. I am thinking about the kind of device that use a 16bit external memory combo (16bit NOR-Flash with a pseudo SRAM).
Well I don’t know if this feature is patent encumbered though… But it should not as basically all Cisc are using variable length instructions.
So if you want to design a new Open Source CPU this is an area that’s not covered by the offers yet !
Pingback: CPU review first conclusions « Silicone's web | Free-PCSupport.COM
ARM7TDMI is not a very fast machine, neither in MHz nor in CPI. A standard configuration LEON3 will easily outperform it with at least 50%. Even OR1200 will probably beat it, at least in CPI …
Thanks for the clarification, the “performance” word was probably not well chosen.
CPI is a good indicator.
MHz is probably more a question of technology (unless one want to do a P4 again, tuning the architecture beyond limits to get more MHz is not that useful).
Here I wanted to highlight the limited memory bandwidth of some embedded systems. And in such context the code size really matters.
So the comparison should be in code size versus performance. Something like a mean instruction size.
I just can’t find the reference, but as I remember ARM Thumb and Mips-16 are giving a gain of little less than 40% in size. Taking that base that will make a mean of 19.2bit instruction size.
Suppose we have a low memory bandwidth, let’s say 16bit per cycles (that’s very low on purpose).
So we can calculate a number of memory cycles by instruction:
For a 19.2bit instruction size it’s 1.2 memory cycles per instructions.
For a 32bit instruction size it’s 2 memory cycles per instructions.
So for a 32bit instruction size there seams to be no need to have a CPI better than 2, as it will be wasted on the memory bandwidth anyway.
This can be partially balanced with fast cache memories, but the size of on chip memory has a cost too. And embedded systems often have realtime issues that makes the designer consider some worst cases anyway.