AVR32 availablilty ?

Also check on if the release dates are for (final) sample qtys, or production qtys.

-jg

Every time someone reminds me of the AVR32's existence, I find myself wondering why exactly the world needed yet another proprietary 32-bit core.

While you can get engineering samples now, they are not the production revision.

The production revision is planned to sample in January so mid Feb seems to be right for volume.

Production volume will be based on first come first serve, and you are only 8 weeks away from January 1. I advise you to order the parts now, if you have not done that before. With current lead times, it still looks like February

Same for the new 24c512/1024...... 12 weeks del.... :(

Money, bro, money!!! Everyone wants a peace of cake! Yet another core means someone will hook up on that core, make some product and sell it to that world, make some money and pay Atmel (or whoever makes a core) back for using that core. Atmel will thrive and make better and cheaper chips (in theory). If it's sounds utopian, oh, well... but Intel did it, Motorola did it, ARM did it, so why not do it again....

Isn't an IP (or chipmaking to be exact) a wonderful business? There wil be always some programmer around to make that core a great business and make sure to prove him/herself as a genius and in turn to prove that exactly that core is the "right one". Maybe ARM is almost everywhere but, lets be fair and give a chance to Atmel to prove that AVR32 is better.

In another words, to quote Michael Douglas from movie "Wall Street": "The greed is good"

The world is always hungering for better performance, lower power consumption, lower cost, new combinations of peripherals and better tools. If you manage to get the right combination for the right customer(s) you will be successful.

While there will be die-hard ARM enthusiasts, ARM themselves is diluting the ARM architecture with the release of the incompatible Cortex leaving room for other architectures.

and then there is this recent news : [ MIPS to enter the 32-bit MCU fray The current 32-bit MCU market is dominated by proprietary 32-bit microcontroller suppliers such as Renesas (27.7 percent market share), NEC (22.9 percent) and Freescale (17.3 percent), said Tony Massimini, Semico's chief of technology.

While the MIPS MCU venture as an IP supplier is unlikely to change that landscape, MIPS "can open up new markets" just as ARM has enabled "very strong growth" for MCU vendors with ARM-based products, Massimini said. Along with ARM, "MIPS becomes another choice for designers" within the very competitive 32-bit MCU market, he added. ]

and even those already with cores, expand them, see Freescales V1 Coldfire, and Infineon's extensions to move into the 32 bit Automotive area, with some nice wide-temp spec high end uC. So cores DO keep proliferating....

Infineon even had a release [Infineon Enters Motorcycle Engine Control Applications; Introduces New MCU Family]

Ahhh I thought, small but nimble processors, perhaps ?

but no, [For instance, the XC2766X with 66 MHz frequency, 768 kBytes of flash memory, 16 channels, LQFP-100 package and an automotive temperature range of -40°C to +125°C is priced at approximately Euros 5.50]

I'm somewhat amazed one really needs 100 pins, and 768K Flash, to control a motorcycle engine ?!

-jg

This is disingenuous. The best way of achieving perfect tools is by opening documentation on the debugging protocols in use, and reducing the number of target cores - more targets means a more dilute development effort.

I have yet to see what AVR32 adds to the world in terms of new performance mixture (that is not already available from some other core). And don't tell me the same peripherals couldn't be put on AMBA or whatever internal bus some other 32-bit micro uses?

Yes and no. If the development is done in C, there is little dilution. Certainly the 'debug stub' is unique in each core, but in man-day terms, that is not large (especially not once you've made the decison to add the silicon to support debug), and it is done once, and the cost bourne by the chip vendor.

Indeed, there is a good counter argument, that Debug is very important, and benefits from the ChipMaker putting resource into that. Those that buy a core and leave debug to others, also have a diluted solution. So Atmel's AVR studio is an important piece of the offering.

Also if you follow your argument, no one would ever change a core ? If fact, how far would you go in 'reducing the number of cores' ?

From a vendor viewpoint, they look at license fees, and decide if they could set up a team of designers, to create a better core, for less money.

In Atmel's case one logical comparison is an ARM7 - that's a Microprocessor that's been press-ganged into microcontroller space, mainly to coat-tail on tools and IP. That core has no Divide opcode, and no MAC, so that makes it relatively easy to make a 'better core'.

How much better, becomes a std engineering trade-off of silicon area, vs performance. Add a hardware MAC, and performance goes up (but so has the die area )

Even ARM do this, and they now have MANY cores, with MANY HW acceleration choices - and it makes sense, whenever a large enough market segment presents a price/performance target.

As time goes by, the core itself actually matters less and less.

That's also why we see more and more "Low CostEval" offerings - what matters now, is 'time to first test', and often sees designers choosing Core+Debug colution as one.

-jg

There are tools for hardware and tools for software. Not if the CPU core in itself limits how tools can be designed. The AVR32 has a Nexus interface allowing you to access the microcontroller, without stopping the execution. Can't do that on the EmbeddedICE based ARM7/9 or on an 8051.

Ultimately, it is a matter of cost. If the license fee of a CPU core is higher than the cost of developing a new CPU core, then the new CPU core will be developed, and in real large volumes where the end customer cost is the key parameter, then the proprietary core will win.

Look at the smart card market. Noone cares if the smart card contains an ARM or an AVR32. The only thing which counts is cost, once you have reached the minimum feature requirement.

If you look at performance, I have seen benchmark figures putting

• uC3A0512 @ 66 Mhz at 89 Dhrystone MIPS

• LPC2xxx @72 Mhz at 62 Dhrystone MIPS

• ST Cortex-M3@72 Mhz at 63 Dhrystone MIPS.

Why the ST is so low, I can only speculate. Two waitstates access from flash at 72 MHz is an obvious issue. Possible "tuning" to make them look bad, is another. Dearly would like to hear if these figures are real. If they are, then this is a motivation in itself. While probably the majority of the applications for these parts do not require this type of performance, some do, and would find the extra 41% performance nice.

You can look at small details, but in reality the issue is that of the license cost, mentioned above. The customers will make the choice, and if they like it, they will use it, if they don't they won't.

gy.

My Suzuki SV1000 V-twin engine has a 32-bit controller. It revs at up to 12,000 rpm which means that that the ECU is handling a lot of data, and needs that sort of computing power.

Leon

news: snipped-for-privacy@o3g2000hsb.googlegroups.com...

All ARMs, including ARM7 and ARM9, support realtime debugging via EmbeddedICE-RT or CoreSight in newer cores. Do Atmel's ARM cores not support this?

According to your logic nobody would ever develop a new CPU as licensing costs are a fraction of the cost of developing a new core (as the cost are split between many licensees). Proprietary single source cores carry a lot more risk as you're dependent on one company setting prices or discontinuing a core etc. Which will be cheaper, a single source core or a core that is available from many competing manufacturers?

The datasheet says it is 83 when running from flash. Surely you agree it would only be fair to quote numbers running from SRAM if you have them for the other cores too?

This looks like running from flash (it would be 68 with 0 wait state)

That is only 70% of max performance, so it seems something is wrong with that number. Do you have a link showing the details?

Two wait states wouldn't make that much difference on the M3 since it has prefetch buffers and branch prediction to reduce the effect of waitstates. The ST part itself adds 2 more 64-bit prefetch buffers. So I'd expect it to do about 77 DMIPS with 2 waitstates.

Top performance of low-end MCUs is not really interesting - it is limited by the particular flash implementation, not at all by the core. If Luminary wanted they could do a 100MHz part with 1 waitstate (they have the fastest flash, 0 wait state at 50MHz) and claim to be the world's fastest MCU. But few need that much performance as you say.

I don't believe license cost is an issue at all. The vast majority of core licenses are in the $1-2 million area, which is nothing compared to the cost of developing a new architecture and micro architecture(s) from scratch. Add to that the cost of creating high quality debuggers and compilers, all of which are recurring unlike the license fee.

Wilco

The underlying fact of the matter is much more likely that someone approached Atmel for an ASIC, and you said "Well, if you want a hundred thousand of them, we will put in someone else's licensed core, but if you want ten million of them, the economics favor developing a custom proprietary core. Your unit costs will be cheaper, but you'll be locked into our parts forever. And by the way, we'll sell them on the general market as well to help recoup our NRE".

Sounds plausible, but so what? Diversity is always a good thing to most of us, and is rarely if ever caused by anything except competition...

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

that's been press-ganged into

All ARMs have MAC instructions. Whether a core has a divide or a MAC instruction is not as relevant as the ability to run real world code well. Lots of 8/16-bitters have divide opcodes but an ARM7 can easily outperform them even when emulating division in software. What actually matters is having a streamlined instruction set, a good micro architecture and a high quality compiler and debugger.

The ARM7 is an old design of course, so it is certainly possible to make a better ARM7 MCU - which is where Cortex-M3 comes in.

choices - and it makes sense, whenever a

Sure, but Larwe's question was what new features does the AVR32 bring? I don't see the promised speeds (it was orignally announced as a 266MHz core trying to compete with the 600MHz ARM11, but the fastest one available is just 150MHz...). The instruction set is similar to Thumb-2 with similar codesize. So it's just another ARM imitation aimed at the same markets. At that point the question is whether it is worth the risk of going with a single source proprietary core.

If the core doesn't matter much, couldn't we just replace all existing cores by (say) 8051? You must love it as it does have a divide opcode...

Wilco

Since when was the perfect 32 bit core invented? I am all in favor of someone building a better mousetrap. All in favor of someone figuring out how to do without the mousetrap entirely.

We should worry when new cores are *not* being introduced in the market else we'd be stuck with 8051.

No, you normally have a per unit cost, which is not present if you develop your own. Multiply $0,5 (for an ARM9) with 100 Mu and you get 50 M$ in license cost. You can develop a CPU core for much less than that. Even at 10 cents, you pay $10M. I have seen a student develop a RISC processor for $50k. This was using a commercially available architecture, and the students implementation was superior to "the real thing"...

All numbers are for running from flash. I just don't know where the discrepancy comes from.

No, I am looking for independent numbers.

Anyone sane, will do several versions, one where you try to get top performance, and one where you try to get best power consumption. Luminary is not "best" at anything, it appears.

You forget the "per unit" cost.

Well sort of, I assume it is more an anticipation that you will get these projects. Smartcards is an obvious market where people will switch to another CPU architecture if they can gain a few cents.

Tools are so cheap nowadays, that the lockin effects, while it exists is much less of an issue, than it used to be.

"Wilco Dijkstra" skrev i meddelandet news:rV2Xi.118447$ snipped-for-privacy@newsfe7-gui.ntli.net...

And the AVR32 is 5-10 times faster than the ARM7 on DSP operations when running real code.

The Cortex in itself shows why it is a good idea to develop the AVR32 core.

Certainly from where I am.

I think the AVR proves, that staying with the industry standard (8051) is not always the best strategy.