66MIPS 8bit microcontroller

Google did not give me useful results. Are there any 8bit microcontrollers available running at least 66MIPS?

Thanks !!

Sam

Reply to
SamSvL
Loading thread data ...

try

formatting link

Reply to
Jim Granville

Jim Granville wrote in news:46a87743 @clear.net.nz:

Thanks Jim, and sigh .... why didn't I find this site

Sam

Reply to
SamSvL

Just to satisfy my own curiosity. If you require that level of performance, where does the requirement to use an 8bit processor come from?

Regards, Richard.

  • formatting link
    A free real time kernel for 8, 16 and 32bit systems.

  • formatting link
    An IEC 61508 compliant real time kernel for safety related systems.

Reply to
FreeRTOS.org

Sure--Silicon Labs and Asix have 8051s that run at 100 MIPS. Also Picoblaze and probably others if you have a corner of an FPGA free.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

Tezzaron Semi may have something, although I don't know what is their product availability, or anything about the company actually.

Does anyone have any experience with their products?

formatting link

D.

Reply to
D.

Hey Atmel,

When are you going to up the ante on AVR performance? Why aren't we seeing 100MHz, 50MHz, or even 33MHz ?

What do folks do with 100MIPS 8-bit controllers anyway? I can think of some uses if the IO and interrupt latency is similarly low. But these would be peculiar applications, not mass market.

What market drives Silicon Labs to make 100MIPS 8-bitters, and why doesn't Atmel compete?

--
Good day!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen

...because Atmel make AVR32, ARM7 and ARM9 devices? Hence my previous question on this thread. If 66MIPS (?) is required, then where did the requirement for 8bits come from?

Regards, Richard.

  • formatting link
    A free real time kernel for 8, 16 and 32bit systems.

  • formatting link
    An IEC 61508 compliant real time kernel for safety related systems.

Reply to
FreeRTOS.org

BTW, it is ridiculous but anything running higher then 25MHz is subject to US export regulations. And it looks like the speed limit for many microcontrollers is exactly there.

There used to be an idea of "virtual peripherals". Running that fast you can simulate whatever peripherals by bit banging. Ubicom was strongly promoting that idea, but nobody seemed to like it.

It would be convenient (in the theory) to simulate exactly what you need instead of trying to find MCU with all necessary features.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

I would guess the market is for people who want to use their familiar

8051 and PIC tools, but want more MIPS.

Perhaps the people originally willing to switch to a non-mainstream core like the AVR, would be just as willing to switch to an ARM if they needed more speed. I.e., there is not as large a user base reluctant to change cores.

--

John Devereux
Reply to
John Devereux

I see that they say that their 200MHz almost 1 cycle per instruction with hardware IEEE floating point support runs almost 3x faster than a standard 8051 computing a mandelbrot pattern. Am I missing something, or is this just slightly short of pathetic ? Just based on the clock frequency and less clock cycles per machine cycle, their

8051 should be close to 150x faster.

Regards Anton Erasmus

Reply to
Anton Erasmus

Given that they also say "up to 100 MFlops", I suspect they're comparing with/without the hardware IEEE on the same "standard" 8051 at the same clock speed. Although even then, I think I'd expect slightly better...

I'm guessing, though.

Steve

formatting link

Reply to
Steve at fivetrees

with/without the hardware IEEE on the same

expect slightly better...

A quick look at the datasheet shows that a floating point operation takes

8 moves to set up the input operands, 1 to set the operation and 4 to store the result (which is valid after 4 cycles). So that's 8 * 4 + 3 + 4 * 4 + 4 = 55 cycles for one floating point operation. This gives 3.6MFlops at 200MHz, a little lower than the claimed 100MFlops. Similarly the 200MIPS maximum speed is more like 75MIPS on actual code as few instructions execute in 1 cycle.

A software floating point implementation on this 8-bit core might take around

200 cycles on average for addition/multiply, so getting a factor 3 speedup from the floating point hardware sounds feasible. Not very impressive indeed.

Wilco

Reply to
Wilco Dijkstra

because they chose instead to target wide vcc and lower power. That's a larger market area than apps that MUST have a 50MHz 8 bit core, and can't (for some reason?) use a 32 bit uC.

The laterst iterations of AVR, have driven down power points, which is what their customers are demanding.

It can be driven by peripherals. I have often had apps where finer time/PWM resolution, or faster SPI, would be nice. In those cases, core speed comes sort of 'for free'

Couple of reasons: SiLabs make 80C51, so they need a point of difference. For them it is (mainly) Analog performance, and secondly MHz. AVRs are older than the Silabs parts, so are on an older process, and AVRs target wide Vcc operation.

Silabs have only recently ~matched the AVR Vcc range, by using an on chip regulator - something that is becoming more common.

-jg

Reply to
Jim Granville

They are something os a niche supplier :)

I also see they state :

"This product is available only in lots of 10,000 or more."

Note that their 200MHz speeds, are with FaStack® SRAM memory, so you also need a boot-prom.

So, you'd probably compare this technology-node wise, with a BlackFIN DSP from ADi - but you'd probably also find the BlackFIN is MUCH faster, and I expect quite a bit cheaper too...

FLASH speeds remain a bottleneck in microcontrollers.

-jg

Reply to
Jim Granville

The AT76C712 has been running 48 MHz for many years now, but it is not so easily found on the website... Some AVRs run a lot faster than the advertised speed. An ATmega8 for instance is easily overclocked, but it is a lot harder to run an ATmega128 at high speed.

I think a lot of the development effort is to add functionality and reduce cost/power consumption. Higher speed will probably not be available until a more dense process can be used. Introducing something smaller than the current 0,35u has some significant disadvantages.

5V operation, no longer possible. Power consumption in deep power down increases - higher leakage.

If you look at the market, there is a certain correlance between speed and required memory size. You need more MHz to handle a larger program and the typical program size for a processor running at 100 MHz is in my very subjective opinion, a couple of MBytes.

The FPSLIC runs at 40 MHz and has max 32 kB code memory and no external bus. This more than anything limits the usability of the FPSLIC.

An FPSLIC in a high density process with maybe 512 kB memory running at 100 MHz is feasable, and would be a much better fit to customer needs.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

"FreeRTOS.org" wrote in news:uh%pi.4554$ snipped-for-privacy@text.news.blueyonder.co.uk:

Hi Richard,

This is for a reaearch application. We want to control a PATA harddisk at UDMA-6 speed (133MB/sec). And using the 8051 structure enables re-use of parts of our s/w. So I am quite happy with the pointer to Silabs, and feel rather bad that I didn't find this product myself :-(

Sam

Reply to
SamSvL

Spehro Pefhany wrote in news: snipped-for-privacy@4ax.com:

Thanks, Spehro, it looks like Silabs will serve my application well.

Sam

Reply to
SamSvL

That brings us to another question... why hasn't the FPSLIC been redone with an ARM CPU and more memory. The AVR may be a nice 8 bitter, but the ARM combined with an FPGA would be a killer app. Of course there are the complications of any combination of FPGA and CPU that involve the complications of differing requirements on CPU memory and FPGA size. Some apps need one larger and the other smaller while others need both small or both large. But combing the two into one device also has significant advantage in size and speed that can make this a great product if done well.

So is Atmel thinking (or better planning) to produce a new, improved FPSLIC or are they going to continue to let it die the death of product neglect?

Reply to
rickman

with/without the hardware IEEE on the same

expect slightly better...

55

I think you'll find that float operations on an 8-bit micro are going to require much more than 200 cycles. Addition will be of the order of 1000 cycles and multiply/divide/sqrt nearer 3000.

Reply to
Everett M. Greene

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.