>> 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
Audio DSP Software Development Engineer (Boston, MA) My client, a nationally recognized manufacturer of consumer electronics (CE) devices, is seeking DSP engineers with expert embedded software development skills and some experience developing algorithms for audio. You'll join the Boston-based team developing new and exciting audio-centric CE products.