It seems Atmel are doing the next logical thing, and releasing FLASH variants of their AVR32. See: http://www.ecnasiamag.com/print.asp?id=13245 Top MHz still seems to be Flash constrained - we've been stuck in the 50-100MHz zone for what seems like years.... Seems to make the Cortex M3 look 'ordinary' - but will the peripheral specs be as impressive as the new Infineon XC2200 ? http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-103995&pageTypeId=17099 5V operation, Automotve specs, and ECC flash -jg
Atmel releasing FLASH AVR32 ?
Started by ●March 19, 2007
Reply by ●March 19, 20072007-03-19
"-jg" <Jim.Granville@gmail.com> skrev i meddelandet news:1174294678.342488.171510@p15g2000hsd.googlegroups.com...> It seems Atmel are doing the next logical thing, and releasing FLASH > variants of their > AVR32. > > See: > http://www.ecnasiamag.com/print.asp?id=13245 > > Top MHz still seems to be Flash constrained - we've been stuck in the > 50-100MHz zone > for what seems like years.... > > Seems to make the Cortex M3 look 'ordinary' - but will the peripheral > specs be as impressive as the new Infineon XC2200 ? >The AVR32 chips so far have been using the same set of peripherals as the SAM7/SAM9> http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-103995&pageTypeId=17099 > > 5V operation, Automotve specs, and ECC flash >The article mentions Ethernet and USB. This is not available for the XC2200.> -jg >-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Reply by ●March 19, 20072007-03-19
> Top MHz still seems to be Flash constrained - we've been stuck in the > 50-100MHz zone > for what seems like years....I am having difficulty to understand why they cannot read 10 instructions at 50 Mhz from flash in parallel and run processor at 500 Mhz. Branch operatons (unpredictable PC changes depending on user input etc) will still run at 50 mhz but it is still a good gain..
Reply by ●March 19, 20072007-03-19
"tesla" ...> I am having difficulty to understand why they cannot read 10 > instructions at 50 Mhz from flash in parallel and run processor at 500 > Mhz. > Branch operatons (unpredictable PC changes depending on user input > etc) will still run at 50 mhz but it is still a good gain..I think most of these "50 MHz, directly from Flash" processors are already taking 256 bits wide from the flash. See for example the LPC series from Phi^H^H^H NXP. Arie de Muijnck
Reply by ●March 19, 20072007-03-19
Ulf Samuelsson wrote:> "-jg" <Jim.Granville@gmail.com> skrev i meddelandet > news:1174294678.342488.171510@p15g2000hsd.googlegroups.com... > >>It seems Atmel are doing the next logical thing, and releasing FLASH >>variants of their >>AVR32. >> >>See: >>http://www.ecnasiamag.com/print.asp?id=13245 >> >>Top MHz still seems to be Flash constrained - we've been stuck in the >>50-100MHz zone >>for what seems like years.... >> >>Seems to make the Cortex M3 look 'ordinary' - but will the peripheral >>specs be as impressive as the new Infineon XC2200 ? >> > > > The AVR32 chips so far have been using the same set of peripherals as the > SAM7/SAM9 > > > >>http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-103995&pageTypeId=17099 >> >>5V operation, Automotve specs, and ECC flash >> > > > The article mentions Ethernet and USB. This is not available for the XC2200.I realise they push into different sectors, but the industrial/embedded market is somewhere in the middle. [Article does not mention CAN bus] The 3 key points I mentioned are relevent to industrial users, perhaps less so to a MP3 vendor! When will the Atmel link referenced in the press release above actually be relevent to the UC3 ? With no package or price infos, it's hard to judge just how significant this really is. -jg
Reply by ●March 19, 20072007-03-19
On Mar 19, 5:14 pm, "Arie de Muynck" <no.s...@nospam.com> wrote:> "tesla" ... > > > I am having difficulty to understand why they cannot read 10 > > instructions at 50 Mhz from flash in parallel and run processor at 500 > > Mhz. > > Branch operatons (unpredictable PC changes depending on user input > > etc) will still run at 50 mhz but it is still a good gain.. > > I think most of these "50 MHz, directly from Flash" processors are already > taking 256 bits wide from the flash. See for example the LPC series from > Phi^H^H^H NXP.The NXP parts are the only ones I am familiar with that do that trick to get speeds up to 75 MHz, IIRC. The Luminary Micro Stellaris parts run at up to 50 MHz with no wait states without prefetch from flash. Most other devices run at up to about 35 MHz or so before the flash wait states have to be added. That reminds me, I need to update the ARM MCU reference sheet at www.gnuarm.com. There are a few typos I need to fix and there are a number of new devices I need to add.
Reply by ●March 20, 20072007-03-20
-jg wrote:> It seems Atmel are doing the next logical thing, and releasing FLASH > variants of their > AVR32. > > See: > http://www.ecnasiamag.com/print.asp?id=13245 > > Top MHz still seems to be Flash constrained - we've been stuck in the > 50-100MHz zone > for what seems like years.... > > Seems to make the Cortex M3 look 'ordinary'More info has popped up here : https://william-baldwin.com/ftp/ATMEL_AVR32_UC3_Core.doc https://william-baldwin.com/ftp/ATMEL_UC3_80MIPS-40mA_MCU.doc This shows 512KF, 64KR, 100p/144p 10/100 Ethernet USB OTG 12 Mbps [Shame it's not 480Mbd, like the other AVR32's :) ] two master/slave SPIs, one SSC, one master/slave TWI four USARTs with hardware flow-control. One USART has special extensions to support modem, IrDA and smart-card ISO7816 serial protocols. "DSP Instructions - The UC3 �s multiply-accumulate unit executes, in a single cycle, a plethora of multiply and multiply-and-accumulate instructions on standard and fractional numbers, with and without saturation and rounding. Multiply or MAC results can be 32-, 48- or 64-bit wide; 48- and 64-bit results are placed in two registers. DSP instructions also include many add and subtract instructions as well as data formatting instructions such as data shift with saturation and rounding." "The two first devices of the UC3 Series A are sampling now and will be available in volume production in 4Q-2007. The AT32UC3A0512, with EBI, comes in a QFP144 and is priced at $9.24 in quantities of 10,000 The AT32UC3A1512, without EBI, comes in a QFP100 package and is priced at $8.67 in quantities of 10,000." Compare with ARM7 line ? : "Pricing for the 512K Flash variants of the SAM7S, SAM7X and SAM7XC devices start at US$6 in quantities of 10,000 units." - so there is a slight premium for the higher performance AVR32 core. -jg
Reply by ●March 20, 20072007-03-20
"tesla" <yusufilker@gmail.com> skrev i meddelandet news:1174331419.729975.262570@e65g2000hsc.googlegroups.com...> >> Top MHz still seems to be Flash constrained - we've been stuck in the >> 50-100MHz zone >> for what seems like years.... > > I am having difficulty to understand why they cannot read 10 > instructions at 50 Mhz from flash in parallel and run processor at 500 > Mhz. > Branch operatons (unpredictable PC changes depending on user input > etc) will still run at 50 mhz but it is still a good gain.. >Maybe the sense amplifiers for the flash are large, or draw a lot of current. I still remember page mode DRAM memories with 4096 bits per page, and noone has been able to tell me why this is not possible with flash. After talking to multiple memory companies about this, my conclusion is that memory people do not understand microprocessors and their needs. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Reply by ●March 20, 20072007-03-20
"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message news:etoeuu$ea4$3@aioe.org...> "tesla" <yusufilker@gmail.com> skrev i meddelandet > news:1174331419.729975.262570@e65g2000hsc.googlegroups.com... >> >>> Top MHz still seems to be Flash constrained - we've been stuck in the >>> 50-100MHz zone >>> for what seems like years.... >> >> I am having difficulty to understand why they cannot read 10 >> instructions at 50 Mhz from flash in parallel and run processor at 500 >> Mhz.There is no point if you branch every few instructions as most programs do...>> Branch operatons (unpredictable PC changes depending on user input >> etc) will still run at 50 mhz but it is still a good gain..Not at all. If you run a CPU at 500MHz but branches take 10 cycles then you're lucky if you get the performance of a 150MHz CPU with 5 times the power consumption... The solution is to use a cache and branch prediction.> Maybe the sense amplifiers for the flash are large, or draw a lot of > current. > I still remember page mode DRAM memories with 4096 bits per page, > and noone has been able to tell me why this is not possible with flash.Even if it were feasible, a cache with 1 line of 512 bytes is totally useless. A fully associative cache with 32 lines of 16 bytes would be better, but likely still too small to be useful (about 4KB is the absolute minimum). Combining prefetch with a branch target instruction cache would make even better use of such a small cache.> After talking to multiple memory companies about this, my > conclusion is that memory people do not understand microprocessors > and their needs.Most memory (flash, DRAM, even SRAM) is optimised for density, not speed. RLDRAM attracts a premium, so is rarely used. Hopefully new technologies like MRAM will become mainstream soon. Wilco
Reply by ●March 20, 20072007-03-20
> There is no point if you branch every few instructions as most programs > do... >Unless you branch to another part of the page. I think most branches are pretty short, even though I do not have hard data.>>> Branch operatons (unpredictable PC changes depending on user input >>> etc) will still run at 50 mhz but it is still a good gain.. > > Not at all. If you run a CPU at 500MHz but branches take 10 cycles then > you're lucky if you get the performance of a 150MHz CPU with 5 times > the power consumption... > > The solution is to use a cache and branch prediction.Really, I think a large page memory and H/W multithreading is a much better solution. Cache and branch prediction is waste of energy and gates. H/W multithreading simplifies the CPU, No need for nasty feedback muxes in the datapath allowing higher frequencies. No need for branch prediction, since you can execute computable threads while you are waiting for the flash access to complete.>> Maybe the sense amplifiers for the flash are large, or draw a lot of >> current. >> I still remember page mode DRAM memories with 4096 bits per page, >> and noone has been able to tell me why this is not possible with flash. > > Even if it were feasible, a cache with 1 line of 512 bytes is totally > useless. > A fully associative cache with 32 lines of 16 bytes would be better, but > likely still too small to be useful (about 4KB is the absolute minimum). > Combining prefetch with a branch target instruction cache would make > even better use of such a small cache. >I think you need to think about worst case and best case behaviour. Adding a cache leads to more unpredictability. A cache can even reduce worst case performance since it can introduce delays in the critical path. I would not be surprised if a 512 byte page could fit an entire interrupt routine. If you can read the flash in one cycle in page mode, then I do not see how the cache/branch prediction brings a lot of benefit. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB