>> I am looking at selecting a processor for our SoC platform. Currently
>> we use an embedded 8051 core (small, low power, low performance,
>> For our next project, we need more performance, and we are also trying
>> to create a platform suitable for all future projects.
>> The CPU must be available as RTL (VHDL or Verilog) source.
>> Obviously, there are lots of options
>> - Faster 8051
>> - 16-bit ?
>> - 32-bit RISC (ARM Cortext M0, ARC 6XXX, OpenRISC)
>> There are also lots of issues to consider
>> - Power uW/MHz
>> - Area
>> - Performance
>> - Cost/Licensing
>> - Support and tools
>> Can anyone point to any data (comparisons) that would be useful in
>> making a decision.
>I work for ARM so my choice is certainly bias towards ARM cores.
>But the following information might be useful for you.
>8051 IP cores are cheap, but as you can see the performance is limiting.
>The fastest 8051 IP claimed their Dhrystone DMIPS is 0.1/MHz (but many
>others are much slower). But you need to be careful as this often
>require special compiler support or C libraries that make use of the
>extra features. If using standard 8051 instruction set and features you
>would get a lower performance.
>Due to the lower performance you might end up clocking the core faster
>and hence getting higher power consumption. And in highend 8051 cores,
>the register banks are implemented as D-flip-flop rather than SRAM (32
>8-bit registers, to allows single cycle execution of instructions). As a
>result the gate count of the high-end 8051 can be quite large.
>There are not too many commerical 16-bit processors. Most of them are
>proprietary architecture and therefor the choice of compiler tools are
>limited. The performance is several times better than 8051 but mostly
>still less than half of ARM processors. Most of the 16-bit processors
>has a Dhrystone DMIPS from 0.3/MHz to 0.5/MHz.
>The biggest problem you will find with 16-bit core is the 64kbyte memory
>limitation. Some 16-bit architectures has workaround for this by allow
>paging or segmentation of memory map but it will reduce the efficiency.
> If your application requires more than 64kbytes or will expand in the
>future, switching to ARM would be a better choice.
>High performance at small size : Dhrystone DMIPS 0.9/MHz. Smaller than
>most 16-bit cores and very good code density (smaller code size than
>16-bit cores and 8-bit cores).
>There are large number of choices for C compilers and debug tools, and
>certainly future proof (e.g. tools, memory expansion). The processor
>comes with debug features and an integration kit is included to help
And don't count the ARC 600 family out as well.
- Higher performance than an an MO at the same same size (1.2 DMIPS/MHz)
- as low as 12,800 gates
- very low power - 0.0012 mW/Mhz on TSMC 90G
- Robust and mature tools support including an overlay manager to take
advantage of limited local memory
- Code density on par with an 8051 due to it's 16/32 bit ISA
Drop me a line if you'd like more information.
This message was sent using the comp.arch.embedded web interface on
Software Engineer (San Francisco, CA) Implement spacecraft avionics software, implement ground control and telemetry software, implement software for automated testing at component, functional and system levels, including HITL (Hardware in the Loop) testing, implement low level software to interface with various spacecraft components, implement/troubleshoot/improve real time operating system components