Why don't AVRs run at 60-100 MHz?

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This question popped up from the AVR/ARM thread. If $3 ARMs can and do run this fast, why don't $3 AVRs? Is it a technical thing, a marketing thing, what?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Is it a technical thing,

Yes. There are simply parts of AVRs that don't run that fast.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
Is it a technical thing,

Yes. There are simply parts of AVRs that don't run that fast.

I guess my question is really more a muse as to why it would not be to Atmel's advantage to make them run that fast. Would an 80MHz AVR not be attractive to a lot of potential customers?

One thing I do see being a little problematic at higher clock rates is the relatively low bit-count prescalers and timers. But that's not a deal breaker by any means.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The simple AVR bus architecture allows fetching only one 16-bit code memory word per clock cycle. Since the Flash read cycle is technologically limited to 25..30 ns this establishes an execution speed limit - the fastest XMega can not run faster than 32 MHz.

To achieve higher execution speed it's necessary to implement a multi-word Flash reads (2 or 4 words per clock) using a wide flash read access bus. This leads to all cache-like issues (hits, misses, stalls etc.) and requires a second low voltage core power supply, but can increase the peak throughput up to 120..150 MIPS.

Existing AVR silicon structures (except the Flash) already can work at these frequencies (e.g. XMega128's PWM runs at up to 128 MHz clock) but I do not think Atmel would ever implement this on its 8-bitters because it would compete with Atmel's own 32-bitters.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The main problem is that flash memory is relatively slow. NXP has a trick that allows flash to run at up to 100 MHz - they use a 128 bit wide interface with accelerator hardware.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
If $3 ARMs can and do run this fast, why don't $3 AVRs?

Since nobody need it.

8-bitters are typically not used for sound and image processing.

They are perfectly suited to control motors, lamps, heaters, relays and so on.

So they are still over 1000 times faster as the user.
The CPU speed was not the limiter, the human slow down the speed.

I run most AVRs with the factory setting (1MHz), which was fully sufficient for many applications.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I run most AVRs with the factory setting (1MHz), which was fully sufficient for many applications.

LOL--and here I thought OUR apps were stodgy. We've got well over 100 production AVR designs over the years. Lately we also have been doing some simple no-crystal apps that run at 1MHz or 2MHz. Most of our apps have comms links and 3.6864MHz and 7.3728MHz cover most of our apps. Only one app runs faster, at 20MHz.

Typically a "complete" industrial or commercial control app running at 7.37MHz with one or more UART links, continuous conversion on many A/D channels, keypad, display, plus the app "loop", is loafing.

In general I don't need speed just for speed. But it is a bit of a chicken-and-the-egg: as mentioned, one doesn't use an AVR for apps not suited. And we might only pick projects that an AVR can reasonably handle.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIW, SiLabs makes 8051s that can be clocked at 100 MHz. Now you could say that it's the only way to get performance out of an 8051, but to me it says that currently there are no AVR customers with extremely deep pockets, new requirements and lots of existing code they can't or don't want to port over to something more sensible.

If the AVR-based designs you lot are making are still around in twenty years' time you might well see some 100+ MHz ATmega with all kinds of bizarro extensions shoehorned in.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They are also single-cycle, unlike the original 8051 that divided the clock by 12, IIRC.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Silabs C8051F1xx 100 MHz chips use a 256 byte code cache with all its drawbacks. Moreover, the 8051 core they are using can execute only 20..25% of instructions in a single cycle. All this along with a single accumulator 8051 architecture's bottleneck gives a maximum PRACTICAL throughput circa 15..25 MIPS only on a well optimized pure assembly code, not even speaking of any C code.

The few C8051F1xx advantages are a decent 12-bit ADC and the high speed (100 MHz) timers. Been there, done that :D

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i don't know if it's true but if you cold a avr to
−273,149 999 999 9 °C (absolute point of zero) you can drive it at any speed you want and i know this have nothing todo with this (a body told me that and i wisch that i had some liquid helium laying around)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

i don't know if it's true but if you cold a avr to
−273,149 999 999 9 °C

you'd challenge this constraint, stated in most (all?) data sheets:
Quote:
Temperature Range:
– -40°C to 85°C

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> absolute point of zero) you can drive it at any speed

Except you've got no charge carriers moving anymore. ;-)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
They are also single-cycle, unlike the original 8051 that divided the clock by 12, IIRC.

It was not plainly divided by 12, but each instruction cycle is divided up in 12 states, each doing a little bit of work. No pipelining either.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Quote:
They are also single-cycle, unlike the original 8051 that divided the clock by 12, IIRC.

It was not plainly divided by 12, but each instruction cycle is divided up in 12 states, each doing a little bit of work. No pipelining either.

And every instruction could take one or more instruction cycles to execute, thus taking N*12 oscillator cycles.

Almost like the 68HC11, but it only divides the crystal clock by four (for two internal clock signals in different phase, most likely to get four execution states per instruction), and this E clock is used to access the memory bus. Instructions take at least two E cycles (one to fetch it, one to execute).

It has also been speculated if AVR uses both edges of the clock cycle, as the duty cycle is only 45%-55% and if frequency is to be changed it must not be changed over 2% per cycle.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lets back up a bit.

Historically, one of the speed limiters in AVRs has been EEPROM. Do ARMs have EEPROM on chip like AVRs? That could be a speed difference if they don't.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ARMs I've used don't have eeprom but you can write to flash pages - not quite as flexible but not much of an issue especially since you've got more ram to play with and can keep a flash page copy in ram (actually you need to as you have to copy ram to flash).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Lets back up a bit.

Historically, one of the speed limiters in AVRs has been EEPROM. Do ARMs have EEPROM on chip like AVRs? That could be a speed difference if they don't.


I haven't seen any ARMs with EEPROM, but technically, how would EEPROM limit clock speed?

Think of it this way. A 1GHz processor can use an external EEPROM chip, right? Or is there something fabrication-related?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
The main problem is that flash memory is relatively slow. NXP has a trick that allows flash to run at up to 100 MHz -Leon
Actually, the flash is no faster, NXP just has a very wide flash and gets more bytes read in one cycle.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
This question popped up from the AVR/ARM thread. If $3 ARMs can and do run this fast, why don't $3 AVRs? Is it a technical thing, a marketing thing, what?
Probably the same reason that Henry Ford didn't start making the Mustang first and skip all of the earlier models.

Cheers,

Ross

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or that not every car needs a 500 BHP twin turbo charged V8.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XM128A1 wrote:
i don't know if it's true but if you [freeze] an avr to −273,149 999 999 9 °C (absolute point of zero) you can drive it at any speed you want.
Nope, not true. Although freezing CMOS will give you great speed returns (2-5X), you must realize that nothing in nature is linear. You eventually run into a speed limiter that lowering the temperature will not help.

The main limiters on the AVR speed are still the flash access time (sense amps will be faster, but not infinitely so) and the inherent resistance/capacitance of the design. It takes time to fill/drain on-chip buses; play with SPICE and distributed R/C networks some day. Also, the capacitance and resistance will not change radically with temperature, so reducing temp does not help with this delay problem.

---

So, here's the solution (and to be honest, I don't like it): Build an AVR that runs instructions from a static RAM instead of flash. Download the RAM from flash at startup. You could even integrate the flash into the chip, like now. There is at least one advantage to this approach: boot loaders (downloading new firmware to the flash) could potentially be easier.

On-chip static RAM access times are boatloads faster than flash. You get to keep the same AVR core - no caching, stalled or flushing of pipelines, and all that crud. You could easily get a factor of 8X speed increase from RAM access time reduction.

However I doubt that the more expensive chip (it will be bigger and yield may be lower) would sell all that well.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

o, here's the solution (and to be honest, I don't like it): Build an AVR that runs instructions from a static RAM instead of flash. Download the RAM from flash at startup. You could even integrate the flash into the chip, like now. There is at least one advantage to this approach: boot loaders (downloading new firmware to the flash) could potentially be easier.


Given this thread, and your comments, why didn't the AT94 "take off"? (IIRC it is practically dead.)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

So, here's the solution (and to be honest, I don't like it): Build an AVR that runs instructions from a static RAM instead of flash. Download the RAM from flash at startup. You could even integrate the flash into the chip, like now. There is at least one advantage to this approach: boot loaders (downloading new firmware to the flash) could potentially be easier.


Given this thread, and your comments, why didn't the AT94 "take off"? (IIRC it is practically dead.)
Good question. Obviously users of 8-bit processors look at things other than speed (or maybe "as well as speed").

Stu

PS: Aren't all ARM designs inherently running instructions from RAM? The only ARM chips I've looked at ran from RAM.

On the other hand, the ARM is designed with wide-bus transfers, cache misses, and all that stuff.

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
Quote:
the fastest XMega can not run faster than 32 MHz.

Not that it makes much difference, but I've found that the ATXmega128A1 seems to run fine at 36Mhz. I haven't noticed any problems yet at room temp, but I certainly wouldn't try it for production. I haven't tested all the peripherals at that speed, so something might not work right.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The NXP ARM chips run from flash memory.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Or that not every car needs a 500 BHP twin turbo charged V8.

But somebody running an AVR at 3.686MHz could make that argument against having AVRs able to run at 20MHz. Why is 20 sensible but 80 is not? What changes?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What changes?

Well, I don't do much CE stuff, but don't you get more emissions at the higher frequencies?

As mentioned, flash read is limited to about Xmega speeds. And that speed is roughly the same in the AT91SAM7. Also mentioned is that to go "faster" you can't just do simple faster reads, you'd need to read wider and/or buffer somehow.

Except for the DMA of the Xmega, the AVR8 is limited in I/O transfer anyway. Weher is all the "stuff" coming from, and where is it going?

What apps need that kind of speed? Certainly not the "true" microCONTOLLER apps that I work on. Do you want to make the AVR into a DDS, or a DSP? There are existing alternatives that are more purpose-built; heck, we don't even have a MAC instruction.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
The NXP ARM chips run from flash memory.
As do STM's, Luminary's etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

What changes?

Well, I don't do much CE stuff, but don't you get more emissions at the higher frequencies?

As mentioned, flash read is limited to about Xmega speeds. And that speed is roughly the same in the AT91SAM7. Also mentioned is that to go "faster" you can't just do simple faster reads, you'd need to read wider and/or buffer somehow.

Except for the DMA of the Xmega, the AVR8 is limited in I/O transfer anyway. Weher is all the "stuff" coming from, and where is it going?

What apps need that kind of speed? Certainly not the "true" microCONTOLLER apps that I work on. Do you want to make the AVR into a DDS, or a DSP? There are existing alternatives that are more purpose-built; heck, we don't even have a MAC instruction.


I think this all hints at what could be the main reason. I think there is an expected balance of speed, memory size and features, and a hyper-speed AVR would be seen as an out-of-balance design. It would have the speed but when compared with other devices of similar speed it would be lacking in other areas. And it's not even obvious any more that it would be able to win designs based on price. It may be that the world above 25-50MHz is expected to be 32-bit, with all that entails, and there's nothing that an 8-bit device would bring to the party that would be enough to offset that expectation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Remember that most ARM's only can run true full speed from RAM, so if there is need for a extra gear put filteres interrupts etc. in RAM
I had a 2138 project that decoded 2 9600 baud radio signals. And I actually gained 5-10% from code in RAM over code in Flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very interesting discussion, so please pardon the cheap shot: If you need ARM-like performance and ARM-like prices, why not just use an ARM?

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some people seem to want to use an AVR for everything, even if it's not suited for the task :)

Of course, if you have invested in AVR tools, especially as a private person, you're more likely want to maximize their usage.

A company I worked at more or less refused to step up to something more powerful than a 8051 for some application that really screamed for more, because they invested in tools like Lauterbauch ICEs and Keil compilers; instead they resorted to multiple 8051s, ultraexpensive DPRAMs and bankswitching.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:

A company I worked at more or less refused to step up to something more powerful than a 8051 for some application that really screamed for more, because they invested in tools like Lauterbauch ICEs and Keil compilers; instead they resorted to multiple 8051s, ultraexpensive DPRAMs and bankswitching.

Umm, and your point is?

Just kidding! I get it, really. Bank switching, gak!! Never again!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The point is that changing to a more suitable MCU can save a lot of hassle ;)

The product in question had to run some type of field bus, it took 90% of 8051 processing bandwidth, all the time. So they used another 8051 and connected them with a dual ported async SRAM that costed $60 or so, in the process also defying their own second source strategy (one of their reason for choosing for 8051).

The 64Kb code limit, if not using bankswitching, also meant some features had to go, but management could not decide what had to stay or what had to go, so it changed every week, driving the programmer insane :)

This was around 2000 IIRC, I'm not sure which AVRs were available then, but a big AVR surely was a much better choice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I once started working at a company that was planning to use an 8051 as an industrial controller, since that was what they had been using. It quickly became evident that the 8051 coudn't cut it in this new application, so they moved up to the 80251 (I'm guessing that chip is long gone). After fussing around with that for a bit, I convinced them to move to the Siemens (Infineon) C167, and that worked out well, even though the continuous feature creep that always happens. Today I'd put an ARM or other small 32-bit chip in there without blinking (that C167 was not cheap!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They planned to upgrade to the Philips XA series, but I don't know if they ever did because I left in 2001. I'm guessing that XA is long gone too :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that NXP still makes them.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just checked and they are still being made. The RCA1802 is also still manufactured :)