EmbeddedRelated.com
Forums

new members coming in AT91 family

Started by Fred* May 21, 2004
Satisfaction wrote:

<snip>
> to answer one of your previous question, > > Q: will it stay at 55MHz or is that the same marketing MHz > of late-AVRs ? > > A: none. The Frequency given is @ 85&#4294967295;C, this means that at lower temp > you can run faster. For example, with the AT91R40008 @ the worst case > T&#4294967295;, it is 66MHz, but at @ 25&#4294967295;C you can boost this part @ 82MHz, with > 256K of 32-bit 0 WS internal SRAM, this chip is flying !!!
Err - I was asking about the New FLASH SAM series, you seem to have quoted for an existing, but SRAM based device ? Do you have numbers for a real, production, SAM device, at 85'C, running from the on-chip FLASH memory ? The few RAM based AVRs Atmel make, can also 'go faster', but their problem has been getting the FLASH to keep up with the core, and recently had to down-spec from 24MHz to 20MHz on FLASH devices. -jg
"Jim Granville" <no.spam@designtools.co.nz> skrev i meddelandet
news:dmqvc.512$NA1.38112@news02.tsnz.net...
> Satisfaction wrote: > > <snip> > > to answer one of your previous question, > > > > Q: will it stay at 55MHz or is that the same marketing MHz > > of late-AVRs ? > > > > A: none. The Frequency given is @ 85&#4294967295;C, this means that at lower temp > > you can run faster. For example, with the AT91R40008 @ the worst case > > T&#4294967295;, it is 66MHz, but at @ 25&#4294967295;C you can boost this part @ 82MHz, with > > 256K of 32-bit 0 WS internal SRAM, this chip is flying !!! > > Err - I was asking about the New FLASH SAM series, you seem to have > quoted for an existing, but SRAM based device ? > Do you have numbers for a real, production, SAM device, at 85'C, > running from the on-chip FLASH memory ? > The few RAM based AVRs Atmel make, can also 'go faster', but their > problem has been getting the FLASH to keep up with the core, > and recently had to down-spec from 24MHz to 20MHz on FLASH devices. > -jg
The AVRs are a 0,35 u 5Volt flash process and the ARMs are in a 0,18u 3.3V flash process. Can't really draw any conclusions between parts in processes that different. Do not know any details why the downspec, but my guess is that you do not want to lose ANY parts due to speed constraint. Some flash AVR parts are known to run much faster than 24 Mhz. You cannot run the flash at 66 MHz (30 ns cycle time) even in 0,18u. You therefore use well known techniques to increase bandwidth from slower memory. Typically these techniques rely on certain behaviour in the application. Therefore you will not get the same number of MIPS from a flash part and a 32 bit zero waitstate SRAM part for all thinkable applications, but you can probably be very close. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This is a personal view which may or may not be share by my Employer Atmel Nordic AB
"Ulf Samuelsson" <ulf@atmel.nospam.com> wrote in message news:<01svc.1251$9n5.203@amstwist00>...
> "Jim Granville" <no.spam@designtools.co.nz> skrev i meddelandet > news:dmqvc.512$NA1.38112@news02.tsnz.net... > > Satisfaction wrote: > > > > <snip> > > > to answer one of your previous question, > > > > > > Q: will it stay at 55MHz or is that the same marketing MHz > > > of late-AVRs ? > > > > > > A: none. The Frequency given is @ 85&#4294967295;C, this means that at lower temp > > > you can run faster. For example, with the AT91R40008 @ the worst case > > > T&#4294967295;, it is 66MHz, but at @ 25&#4294967295;C you can boost this part @ 82MHz, with > > > 256K of 32-bit 0 WS internal SRAM, this chip is flying !!! > > > > Err - I was asking about the New FLASH SAM series, you seem to have > > quoted for an existing, but SRAM based device ? > > Do you have numbers for a real, production, SAM device, at 85'C, > > running from the on-chip FLASH memory ? > > The few RAM based AVRs Atmel make, can also 'go faster', but their > > problem has been getting the FLASH to keep up with the core, > > and recently had to down-spec from 24MHz to 20MHz on FLASH devices. > > -jg > > > The AVRs are a 0,35 u 5Volt flash process and the ARMs are in a 0,18u 3.3V > flash process. > Can't really draw any conclusions between parts in processes that different. > > Do not know any details why the downspec, but my guess is that you do not > want > to lose ANY parts due to speed constraint. > Some flash AVR parts are known to run much faster than 24 Mhz. > > You cannot run the flash at 66 MHz (30 ns cycle time) even in 0,18u. > You therefore use well known techniques to increase bandwidth from slower > memory. > Typically these techniques rely on certain behaviour in the application. > > Therefore you will not get the same number of MIPS from a flash part > and a 32 bit zero waitstate SRAM part for all thinkable applications, > but you can probably be very close.
Hello Jim, I quoted the R40008 because it is an existing part, and with the AT91 Timings Calculator from ATMEL WWeb site, you can evaluate the Max frequency of the part according to VDDCORE, VDDIO and Temp. It was to explain you the 55MHz. It is just derating curve applied to the part. About "...numbers for a real, production, SAM device, at 85'C, running from the on-chip FLASH memory ?" I do not know How can I have those numbers, there is no electrical spec or parts.
Satisfaction wrote:
<snip>
> Hello Jim, > > I quoted the R40008 because it is an existing part, and with the AT91 > Timings Calculator from ATMEL WWeb site, you can evaluate the Max > frequency of the part according to VDDCORE, VDDIO and Temp. It was to > explain you the 55MHz. It is just derating curve applied to the part. > About "...numbers for a real, production, SAM device, at 85'C, running > from the on-chip FLASH memory ?" I do not know How can I have those > numbers, there is no electrical spec or parts.
I think we can agree we need to wait for real parts, before the specs become 'real'. We will then also know the actual memory bandwidth, and if there are any 'wait states' needed for the 55MHz (or revised) number. -jg
Jim Granville <no.spam@designtools.co.nz> wrote in message news:<GGMvc.705$NA1.53964@news02.tsnz.net>...
> Satisfaction wrote: > <snip> > > Hello Jim, > > > > I quoted the R40008 because it is an existing part, and with the AT91 > > Timings Calculator from ATMEL WWeb site, you can evaluate the Max > > frequency of the part according to VDDCORE, VDDIO and Temp. It was to > > explain you the 55MHz. It is just derating curve applied to the part. > > About "...numbers for a real, production, SAM device, at 85'C, running > > from the on-chip FLASH memory ?" I do not know How can I have those > > numbers, there is no electrical spec or parts. > > I think we can agree we need to wait for real parts, before the specs > become 'real'. > We will then also know the actual memory bandwidth, and if there are > any 'wait states' needed for the 55MHz (or revised) number. > -jg
Need to comment on the flash specs. Somebody mentioned that 66 MHz would need 30ns Flash; ooops, how come. It needs 15 ns flash ;-) Or in terms of 55 MHz it needs 18 ns flash. How can this be done? Well Philips did it by interfacing 128-bit wide to the flash memory plus some buffers for prefetch and so on. This is like 4 32-bit fetches at once, and viola, the 60 MHz quoted by Philips are possible with a 60ns Flash. Motorola did something similar on a 56k device with a 64-bit wide interface, so did Infineon with their XC16x series. If Atmel continues to have 16 or 32-bit wide interfaces to flash the only speed increase you get is that wait states will be shorter (but you have to increase the number of wait states). So there will be a new record in wait states executed per second. btw. in our lab we tested the LPC2106 from Philips from RAM just for fun and we stopped at 100 MHz without seeing any problems in execution or the device showing any increase in temperature. May be Philips could come up with a SRAM specification as well and increase the max performance. Right now the LPC2000 is BY FAR the fastest ARM7 running out of Flash and if Atmel or ST will not put a lot of work or bits into the FLash interface this will remain a fact for the time being. On another note there was a posting about a 0.18um 3.3V process. IMHO there is no such thing. The 0.18um process is a 1.8V process. If the only power supply is 3.3V there is a DC/DC somewhere. Cheers, Schwob
Schwob wrote:
> Jim Granville <no.spam@designtools.co.nz> wrote in message news:<GGMvc.705$NA1.53964@news02.tsnz.net>...
<snip>
>> I think we can agree we need to wait for real parts, before the specs >>become 'real'. We will then also know the actual memory bandwidth, and if there are >>any 'wait states' needed for the 55MHz (or revised) number. >>-jg > > > Need to comment on the flash specs. Somebody mentioned that 66 MHz > would need 30ns Flash; ooops, how come. It needs 15 ns flash ;-) Or > in terms of 55 MHz it needs 18 ns flash. How can this be done? Well > Philips did it by interfacing 128-bit wide to the flash memory plus > some buffers for prefetch and so on. This is like 4 32-bit fetches at > once, and viola, the 60 MHz quoted by Philips are possible with a 60ns > Flash. Motorola did something similar on a 56k device with a 64-bit > wide interface, so did Infineon with their XC16x series. If Atmel > continues to have 16 or 32-bit wide interfaces to flash the only speed > increase you get is that wait states will be shorter (but you have to > increase the number of wait states). So there will be a new record in > wait states executed per second. > > btw. in our lab we tested the LPC2106 from Philips from RAM just for > fun and we stopped at 100 MHz without seeing any problems in execution > or the device showing any increase in temperature.
That's pretty much as expected, given typicals, and mfg margins. I recall we tested a 24MHz AT89C2051 to 77MHz 'in the lab'
> May be Philips could come up with a SRAM specification as well and increase the max > performance.
An interesting idea. Would need care in change of speed, and interrupts would be a challenge.... It may be that their change of BUS width means it is not worth the hassle : ie RAM might be ~15ns anyway. > Right now the LPC2000 is BY FAR the fastest ARM7 running
> out of Flash and if Atmel or ST will not put a lot of work or bits > into the FLash interface this will remain a fact for the time being. > > On another note there was a posting about a 0.18um 3.3V process. IMHO > there is no such thing. The 0.18um process is a 1.8V process. If the > only power supply is 3.3V there is a DC/DC somewhere.
It is becomming more common, to put an on-chip regulator : 5V.IO is even seeing something of comeback, as customers point out that 3.3V PowerMOSFETS are rare indeed!. -jg