8-bit uC @ 100MHz?

[RogerRowland]

I'm just reading the following article:

http://www.newelectronics.co.uk/electronics-technology/rumours-of-the-death-of-the-8bit-microcontroller-have-been-greatly-exaggerated/114051

In it, Tom Pannell, MCU marketing manager with Silicon Laboratories, said:

... we have an 8051 based device that runs at 100MHz and a 72MHz part in our EFM8 range...

So, which micro is it that runs at 100MHz? I can't find it here http://www.silabs.com/products/mcu/8-bit/Pages/efm8.aspx

I normally only mess around with PIC, but I'd be interested to play with something different for a change.

[chris_leyson]

Be interesting to see what Silicon Labs have to offer, you can still do a hell of a lot with an 8-bit microprocessor, 8051 architecture as well, industry standard back in the day.

As an aside, I've always been a fan of Ken Chapmans Picoblaze 8-bit processor for Xilinx FPGAs, had one running reliably at 100MHz on a high speed Spartan 3 FPGA. On Spartan 6 FPGAs it takes up less room and will probably still run at 100MHz. Only draw back is 2k of program memory, but with paging techniques it's not too difficult to add more memory. You could probably fit dozens of them onto an FPGA.

Chris

[matseng]

From page 27 of the datasheet located at https://www.silabs.com/Support%20Documents/TechnicalDocs/C8051F12x-13x.pdf

With the CIP-51's maximum system clock at 100 MHz, the C8051F120/1/2/3 and C8051F130/1/2/3 have a
peak throughput of 100 MIPS (the C8051F124/5/6/7 have a peak throughput of 50 MIPS).

Also at page 39:

3. Global DC Electrical Characteristics
Table 3.1. Global DC Electrical Characteristics
(C8051F120/1/2/3 and C8051F130/1/2/3)
–40 to +85 °C, 100 MHz System Clock unless otherwise specified


So it seems like the C8051F12x can run at 100MHz at least according to its datasheet.

[RogerRowland]

From page 27 of the datasheet located at https://www.silabs.com/Support%20Documents/TechnicalDocs/C8051F12x-13x.pdf
...
So it seems like the C8051F12x can run at 100MHz at least according to its datasheet.

Ahh, thanks, I wasn't looking at the whole range - I see there's a devkit for that too http://www.silabs.com/products/mcu/Pages/C8051F120DK.aspx ... maybe worth investigating ... hmmmm

[dannyf]

A big fan of c8051. It still holds up with some modern 8bitters today.

[tszaboo]

In other news, there is now a big demand for V12 Ladas and 500 horsepower Trabants.
I wonder, why do manufacturers get stuck in this narrow minded vision. There is a saying in my language: "They cannot see the forest because of the trees"

[Kalvin]

In other news, there is now a big demand for V12 Ladas and 500 horsepower Trabants.
I wonder, why do manufacturers get stuck in this narrow minded vision. There is a saying in my language: "They cannot see the forest because of the trees"

8051 is license-free. And if the older versions of the device family are based on 8051, the old customers have the tools and knowledge to work with the new part ie. easy adaptation. Also the existing development tools (compilers etc.) can be used with the new devices which means faster time to market. Creating new tools for the new devices means new bugs to be tackled, need for extra support for the new tools, investment for the tool development etc. Old tools have bugs too, but they may be well known and there may be already workarounds.

For any new customers the 8051-core may be something of a horror. However, if the 8051 is used only for configuring the registers and performing simple task, and the software development can be done in C, it really does not make big difference what processing core you have.

When the application outgrows from the original application the device was designed for, then the old 8051-based architecture and its architectural inefficiency may become obvious. But as long as the application is simple and it fits nicely within the device's limits, it really doesn't matter whether it is 8051, PIC or ARM.

Edit: Oops! Added missing "does not" into: "it really does not make big difference what processing core you have."

[andersm]

However, if the 8051 is used only for configuring the registers and performing simple task, and the software development can be done in C, it really make big difference what processing core you have.

A core like that is fine if it's only used to configure autonomous peripherals. However, as soon as you have to touch the data in any way, those 100MHz start looking a lot less impressive.

[matseng]

Maybe, but at 100MIPS peak and with more than 75% of its 109 instruction set handled in one or two cycles I'd guess that you'd probably get an average of 70-80 MIPS out of it. That's not to shabby even if it's only 8 bit data being handled.

[wraper]

However, if the 8051 is used only for configuring the registers and performing simple task, and the software development can be done in C, it really make big difference what processing core you have.

A core like that is fine if it's only used to configure autonomous peripherals. However, as soon as you have to touch the data in any way, those 100MHz start looking a lot less impressive.

CIP-51 in average is at least 10x faster at the same clock than standard 8051. It executes most of the instructions in 1-2 clock cycles.
https://www.silabs.com/Support%20Documents/TechnicalDocs/CIP-51.pdf

[wraper]

I remember a some guy made an x86 emulator running on 8 bit MCU, I think from silicon labs, most likely it was 8051 core. It even run some sort of windows, albeit slowly as hell, boot time like 2 hours. Just cannot find this project now, don't remember how it was called. Google throws out completely opposite things, as emulation usually happens the other way.

[wraper]

You can get 8051 even at 200 MHz http://www.keil.com/dd/docs/datashts/tezzaron/tscr8051_0_1.pdf

[macboy]

Sixteen years ago in 2000, the Scenix (later Ubicom, later Parallax) SX-52 ran at 100 MIPS (100 MHz to be pedantic, but the only instructions taking more than 1 clock cycle were branches, taking 3, so 100 MIPS isn't far off). The SX instruction set is essentially identical to the Microchip baseline PIC (lawsuits ensued of course). Adding to the speed was a hardware stack that saved all of the important registers for interrupts, to save having to manually save/restore them as was needed on the PIC itself. The thing that crippled this was a lack of any real peripherals other than a few timers; the idea was that you had so much raw speed and deterministic timing that all peripherals could be implemented in software rather than hardware. You can imagine how well that actually went. (Parallax had the same idea with the Propeller: using its eight cores to implement virtual peripherals). I've used a SX-48 with interrupts occurring at several MHz, with plenty of processor time left over for tasks, quite a feat. Another nice feature: Programming and debugging occurred over the two oscillator in/out pins, so ICSP and ICD used absolutely zero I/O pins. Nice. Why don't we see more often? This MCU is now EOL, with the remaining SX-48 chips being cleared out by Parallax for pennies. Originally they were over $10 in quantity, and ~$20 in singles.

[edavid]

This MCU is now EOL, with the remaining SX-48 chips being cleared out by Parallax for pennies. Originally they were over $10 in quantity, and ~$20 in singles.

They are charging $0.78 each, which is actually pretty high for an 8 bit CPU with 4K EEPROM and 262 bytes of RAM 

https://www.parallax.com/product/sx48bd-g

[Kleinstein]

A 100 MHz 8051 has it's benefits - not so much because of the processing power, but 100 MHz timers could be handy in some applications. There are only rather few applications that need much processing power with just 8 bit data - fast regulation loops are more likely limited by the ADC. The high clock speed also can mean EMI problems, so you may not want this if you don't need it.

Even if you don't need the speed, it always good to have the options to use a faster clock speed in case the software turned out to take longer than originally thought.

[dannyf]

I have never found the 8051s to be slow or primitive: hardware multiplier and divider, 16 bit timers, 16 bit data bus, ... Even today, that's pretty good among 8 bitters.

Plus, being a cisc cpu, each 8051 instruction may require multiple risc instructions to implement.

It wouldn't surprise me that for math intensive applications a 8051 may beat a pic or an avr, MHz for Mhz.

[Corporate666]

In other news, there is now a big demand for V12 Ladas and 500 horsepower Trabants.
I wonder, why do manufacturers get stuck in this narrow minded vision. There is a saying in my language: "They cannot see the forest because of the trees"

On the other hand, engineers very often get way too wrapped up in technical details.

How quickly a program can be developed, debugged and implemented counts for a lot, especially in high mix/low volume industries.  Per-part cost of the chip counts for a ton, especially in high volume applications.  I remember years ago when I first started working with Atmel chips, and the guys at AVR Freaks would quickly start religious wars over the superiority of the Atmel chip/core design.  As a business guy, I didn't really care... I needed a chip that was fast enough to do X, and if a PIC takes 27 clock cycles per instruction vs. 1 of the Atmel... that simply doesn't matter, what matters is whether the chip is suited to the end task.

I have a product that uses the Cypress PSoC1 with an M8 core - some folks complain about how bad that core is and how slow it is... for my application it doesn't matter a bit.  It was the cheapest solution with the needed peripherals.  I have another product using a PSoC3 with an 8051 core.  Again, works great... plenty fast, lots of memory, IO's, peripherals and so on... and the chips are cheap for what you get.  I have some new stuff that I use the PSoC5 with the Cortex M3 core.  They are low volume very expensive products and the chip cost is irrelevant so long as it's under $7 or so.  It's overkill for what we are doing but the reconfigurability of the IO pins and peripherals saved our ass a couple of times on designs, and the ability to get 256k of flash means we can add lots of features without worrying about running out of storage.

I actually think the 'features' of the processing core are the last thing most engineers should care about.  Most of us probably write in C and don't really have to deal much with the intricacies of the core/memory... and all that really matters is price/peripherals/dev time/ease of use.

My .02 anyway.

[Buriedcode]

Most of us probably write in C and don't really have to deal much with the intricacies of the core/memory... and all that really matters is price/peripherals/dev time/ease of use.

My .02 anyway.

Whilst I do care for the intricacies of the core (too much as it often makes little difference), I couldn't agree more.  I learned fairly quickly that its easy to get bogged down, or stuck in the mindset of 'must use this micro for this task' or using one with the most peripherals.  On an early contract I used a fancy shmancy new micro, because it had lots of peripherals, but wasted so much time on learning how to use it.. and later on in that design, I decided to use a very small cheap PIC doing all sorts of clever things, but the software took three days to write.  In both instances I lost focus of the 'time/money/effort' thing.

[justanothercanuck]

i thought some of the newer zilogs (ez180) went up in that range, but having a scrub through their website proves me wrong.  and the ones i thought were close were actually 16bit.

[westfw]

Most of us probably write in C and don't really have to deal much with the intricacies of the core/memory.

Personally, I think I like "discontinuities" caused by the architecture.  Most 8bit CPUs will be twice as slow doing 16bit math, 4 times as slow doing 32bit math, and hit some significant wall when either the code size or data memory exceeds some limit (usually 64kbytes), and lack some HW math (divide, or certainly floating point.)   "Suddenly" you have to be a lot more aware of "stuff" than a C programmer ought to need to be.   You have to explain to beginners that yes, 16MHz means 16 (or perhaps 4) million instructions per second, but that "a=b/c'" line is actually going to take ~500 instructions...

Now, if you stay in the "domain" of 8-bit CPUs, where you don't have more than 65k of code or RAM, and you don't do a lot of wide and fancy math, you don't see this, and everything is swell.

There are fewer such discontinuities in the current crop of 32bit CPUs.  Updating an IO pin is about the same speed as updating a memory variable, 32bit multiply is about the same speed as 8 bit add, and so on.  It's not exactly the same as 8bit CPUs, but ... things are "reasonable."   You still get bitten occasionally, of course: one of my pet peeves about ARM CM0 is that "divide" is a sort of unexpectedly slow operation; a discontinuity...

[miguelvp]

Divide is an expensive operation. Multiplication not so much.

[Kleinstein]

The orignal 8051 needs a lot of cycles (12 and more) for a single instruction. So even at 100 MHz clock they would not be that fast. However the fast one mentioned here are only using the 8051 instuction set and may work with 1-2 cycles for many  instructions, so they are resonably fast, but still slower than even the smaller ARM based µCs. This is especially true for using 16 or 32 bit numbers. 

So this is more like something for the few cases the people used to 8051 want more speed without learning a new µC. When using the same process it is only logical that 8 bit µC could use a clock similar (or even higher) than 32 bit µCs - so its not a supprize from the technical side to find 100 MHz 8 Bit µCs. It's only strange to actually find them because of the limited market.  I remember an old note on an experimental 4 Bit CPU running in the 2 GHz range - at that time the highest clock for any cpu.

[tszaboo]

8051 is license-free.

M0 is royalty free now.

On the other hand, engineers very often get way too wrapped up in technical details.

I wasnt talking about the 8 bit in general. 8 bit is fine, I'll use it, when the design calls for it. But why would you make a 100Mhz 8 bitter? They are some 4.5 USD @ 1K, with some 1K memory... You get cortex M4 for half the price. I'm sure people can come up with kinda-sorta valid arguments for very fast 8 bit micros, but they are missing the point: It should not be an 8 bit micro in the first place.

[westfw]

Divide is an expensive operation. Multiplication not so much.

I understand.   But on CM3, CM4, x86, etc, they both complete in the same time...

[digsys]

I switched to the Silabs chips several years ago, having used pretty much everything over 35+ yrs. I find them pretty awesome.
Just about everything is on-chip. 12b ADCs with prog gain amps, 12b DACs, prog PWMs .. heaps of embedded logic with CPU independent hardware.
plus a huge array of on-board comms .... and I always work in machine code, I have no problem with deadlines etc ..... each to his own