Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | new members coming in AT91 family

There are 26 messages in this thread.

You are currently looking at messages 20 to 26.

Re: new members coming in AT91 family - Jim Granville - 16:00 02-06-04

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°C, this means that at lower temp
> you can run faster. For example, with the AT91R40008 @ the worst case
> T°, it is 66MHz, but at @ 25°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




Re: new members coming in AT91 family - Ulf Samuelsson - 17:48 02-06-04

"Jim Granville" <n...@designtools.co.nz> skrev i meddelandet
news:dmqvc.512$N...@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°C, this means that at lower temp
> > you can run faster. For example, with the AT91R40008 @ the worst case
> > T°, it is 66MHz, but at @ 25°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   u...@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB




Re: new members coming in AT91 family - Satisfaction - 14:46 03-06-04

"Ulf Samuelsson" <u...@atmel.nospam.com> wrote in message
news:<01svc.1251$9n5.203@amstwist00>...
> "Jim Granville" <n...@designtools.co.nz> skrev i meddelandet
> news:dmqvc.512$N...@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°C, this means that at lower temp
> > > you can run faster. For example, with the AT91R40008 @ the worst case
> > > T°, it is 66MHz, but at @ 25°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.

Re: new members coming in AT91 family - Jim Granville - 17:24 03-06-04

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


Re: new members coming in AT91 family - Schwob - 00:46 09-06-04

Jim Granville <n...@designtools.co.nz> wrote in message
news:<GGMvc.705$N...@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

Re: new members coming in AT91 family - Jim Granville - 01:19 09-06-04

Schwob wrote:
> Jim Granville <n...@designtools.co.nz> wrote in message
news:<GGMvc.705$N...@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



previous | 1 | 2 | 3