What is happening to Atmel EEPROMs?
in [Embedded]
|
Prev: BT earpieces
Next: USB 3.0 implementation on FPGA
From: Ulf Samuelsson on 29 Mar 2010 18:35 Jon Kirwan skrev: > So much being reposted. I'll focus on this one point, since > it is the more interesting to me, right now. > > > > On Sun, 28 Mar 2010 21:13:40 +0200, Ulf Samuelsson > <nospam.ulf(a)atmel.com> wrote: > >> <snip> >> Not if the sense amplifiers are turned on in both cases. >> There will be some switching current, but I have been >> told that the current in the sense amplifiers are much more significant. > > Again the *if* here. I had imagined (and perhaps > incorrectly) that any chip designer worth their salt (and > perhaps working on generation N, where N > 1) would arrange > to turn them off when not in use. It's not complex to do > that and it doesn't take up real estate to notice. And the > power savings are, as you indicate here, worth the doing. > > I can't imagine they'd miss that opportunity. > > But I'm speaking ignorantly and don't know. It just doesn't > pass a basic rationality test for me, is all. But irrational > things do happen. So... I still wonder. > >> The 1st generation AVRs did not turn off the chip select. > > Note N=1 here. That makes sense. Job 1 is getting a foot in > the door, so to speak. And priorities are much different at > this point. Forgiven. > >> At 16 MHz, the flash will provide data out in < 67 ns. >> When you run at 33 Khz, the instruction cycle is 30 us. >> The flash still delivers data out in 67 ns, but the flash >> burns power almost like it the chip is running at 16 MHz. >> <snip> > > You don't say, but I assume this is true because you claim > here that the sense amplifiers were always on regardless and > that this accounts for the power burn on those parts. I also > gather, reading between your lines here, that this was fixed > and pretty much everything later on now turns these sense > amps off when not in use. If you read a 128 bit word, and then you turn off the chip select, you are going to face extra waitstates when you do a jump. That is why you do not turn off the flash at high speed. If you run at low speed, you can turn off the flash, if you can guarantee that the flash is on again, at the beginning of the next clock. CLK ______|"""""""""""""""""""""""""|______________________|""""""""" /CS """"\______________/"""""""""""""""""""""""""""""""\______________/ DATA --------<=======>---------------------------------------<========> When you run at high speeds, you do not have any clock edges to start the chip select, and you do not want to wait until you do a jump to enable the chip selects, since that adds wait states. > > Why don't you imagine others do the same thing?? You cant do it when your flash access cycle is close to your bus cycle. It only make sense if the flash access is much faster than your clock cycle. > > I'm sure the lesson was learned, especially when considering > opening the door to applications where they might want to run > at 32/33 kHz with your parts and don't want to pay the power > cost. > > I just don't get your argument here about why Atmel learns > and "gets it" and other chip designers are somehow blind and > dumb by comparison. > No, Atmel does not turn off the flash, when running at SAM3/7 at 50-60 MHz. > I would imagine, in this market today, that this is a well > understood issue. TI has forged new territory with the > MSP430 in hyper low power apps and Microchip, for one, and > I'm sure you and other companies as well, have decided that > this market is worth paying at least some attention to. > Besides, it's simply not hard to turn the static draw for the > flash OFF. There is no reason not to do it. Yet you seem to > suggest that there __might__ be the situation here where a > fairly sophisticated team (I can assume) didn't get it and > didn't do it when Atmel only made this mistake on, I take it, > generation 1 AVRs. > > Something doesn't make sense here. Are you arguing you folks > get this right and no one else does? > > Jon See above. BR Ulf Samuelsson
From: Ulf Samuelsson on 29 Mar 2010 18:55 Anders.Montonen(a)kapsi.spam.stop.fi.invalid skrev: > In comp.arch.embedded Nico Coesel <nico(a)puntnl.niks> wrote: >> "TheM" <DontNeedSpam(a)test.com> wrote: >>> Do NPX ARM come with on-chip FLASH? >> Yes, all of them have 128 bit wide flash that allows zero waitstate >> execution at the maximum CPU clock. > > The LP17xx series require flash wait states when run at speeds over 20 > MHz. When running at full speed four wait states must be inserted (see the > description of the FLASHCFG register, p. 71 in the user manual). The chips > do have a flash accelerator (a tiny, simple cache really) to help hide the > latency. > > -a I have done some measurements on CM3 using Dhrystone 2.1 & Keil, and you get the following Dhrystone 2.1 MIPS / MHz. 64 bit 128 bit 0 waitstate 1,223 1,223 1 waitstate 1,068 1,107 2 waitstate 0,915 0,998 3 waitstate 0,774 0,861 4 waitstate 0,660 0,749 based on this, an LPC17xxx running at 100 Mhz w 4 waitstates on non-sequential fetch would run around 75 MIPS or ~61 % of the performance of the zero waitstate memory. Adding one waitstate extra latency on non-sequential fetch removes about 10-15% of the performance from the otherwise zero waitstate. BR Ulf Samuelsson
From: Ulf Samuelsson on 29 Mar 2010 18:55 Anders.Montonen(a)kapsi.spam.stop.fi.invalid skrev: > In comp.arch.embedded Nico Coesel <nico(a)puntnl.niks> wrote: >> "TheM" <DontNeedSpam(a)test.com> wrote: >>> Do NPX ARM come with on-chip FLASH? >> Yes, all of them have 128 bit wide flash that allows zero waitstate >> execution at the maximum CPU clock. > > The LP17xx series require flash wait states when run at speeds over 20 > MHz. When running at full speed four wait states must be inserted (see the > description of the FLASHCFG register, p. 71 in the user manual). The chips > do have a flash accelerator (a tiny, simple cache really) to help hide the > latency. > > -a I have done some measurements on CM3 using Dhrystone 2.1 & Keil, and you get the following Dhrystone 2.1 MIPS / MHz. 64 bit 128 bit 0 waitstate 1,223 1,223 1 waitstate 1,068 1,107 2 waitstate 0,915 0,998 3 waitstate 0,774 0,861 4 waitstate 0,660 0,749 based on this, an LPC17xxx running at 100 Mhz w 4 waitstates on non-sequential fetch would run around 75 MIPS or ~61 % of the performance of the zero waitstate memory. Adding one waitstate extra latency on non-sequential fetch removes about 10-15% of the performance from the otherwise zero waitstate. BR Ulf Samuelsson
From: JosephKK on 29 Mar 2010 23:31
On Sun, 28 Mar 2010 19:22:10 -0500, "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Sun, 28 Mar 2010 16:29:21 -0700, Jon Kirwan <jonk(a)infinitefactors.org> >wrote: > >>On Sun, 28 Mar 2010 16:06:04 -0700, >>"JosephKK"<quiettechblue(a)yahoo.com> wrote: >> >>><snip> >>>It all starts with Amdahl's Law. Double the speed of one thing and if none >>>of the rest of the system can use the speed increase you get nothing. >>>(slightly overstated) >> >>Sounds like the famous "weakest link" phrase, "A chain is no >>stronger than its weakest link," which apparently traces back >>to the English clergyman Charles Kingley's letter, dated >>December 1, 1856, where he wrote "The devil is very busy, and >>no one knows better than he, that 'nothing is stronger than >>its weakest part.'" >> >>Others have also written similarly, since. See very near the >>bottom of page 433 here, for example: >>http://www.archive.org/stream/workslife10bageuoft#page/432/mode/2up >> >>I guess we can add Amdahl to a long list of many stating the >>exact same thing in slightly different words. > >Ahmdahl's Law is more quantitative than that: >http://www.search.com/reference/Amdahl%27s_law > Thanks. If i weren't distracted i might have provided a similar link. |