Reply by JosephKK March 30, 20102010-03-30
On Sun, 28 Mar 2010 19:22:10 -0500, "krw@att.bizzzzzzzzzzzz" =
<krw@att.bizzzzzzzzzzzz> wrote:

>On Sun, 28 Mar 2010 16:29:21 -0700, Jon Kirwan =
<jonk@infinitefactors.org>
>wrote: > >>On Sun, 28 Mar 2010 16:06:04 -0700, >>"JosephKK"<quiettechblue@yahoo.com> wrote: >> >>><snip> >>>It all starts with Amdahl's Law. Double the speed of one thing and if=
none=20
>>>of the rest of the system can use the speed increase you get nothing.=20 >>>(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.
Reply by Ulf Samuelsson March 29, 20102010-03-29
Anders.Montonen@kapsi.spam.stop.fi.invalid skrev:
> In comp.arch.embedded Nico Coesel <nico@puntnl.niks> wrote: >> "TheM" <DontNeedSpam@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
Reply by Ulf Samuelsson March 29, 20102010-03-29
Anders.Montonen@kapsi.spam.stop.fi.invalid skrev:
> In comp.arch.embedded Nico Coesel <nico@puntnl.niks> wrote: >> "TheM" <DontNeedSpam@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
Reply by Ulf Samuelsson March 29, 20102010-03-29
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@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
Reply by March 29, 20102010-03-29
In comp.arch.embedded Nico Coesel <nico@puntnl.niks> wrote:
> "TheM" <DontNeedSpam@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
Reply by Jon Kirwan March 28, 20102010-03-28
On Sun, 28 Mar 2010 19:22:10 -0500, "krw@att.bizzzzzzzzzzzz"
<krw@att.bizzzzzzzzzzzz> wrote:

>On Sun, 28 Mar 2010 16:29:21 -0700, Jon Kirwan <jonk@infinitefactors.org> >wrote: > >>On Sun, 28 Mar 2010 16:06:04 -0700, >>"JosephKK"<quiettechblue@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
Nice! Jon
Reply by krw...@att.bizzzzzzzzzzzz March 28, 20102010-03-28
On Sun, 28 Mar 2010 16:29:21 -0700, Jon Kirwan <jonk@infinitefactors.org>
wrote:

>On Sun, 28 Mar 2010 16:06:04 -0700, >"JosephKK"<quiettechblue@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
Reply by Jon Kirwan March 28, 20102010-03-28
On Sun, 28 Mar 2010 16:06:04 -0700,
"JosephKK"<quiettechblue@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. Jon
Reply by JosephKK March 28, 20102010-03-28
On Fri, 26 Mar 2010 17:27:16 -0700 (PDT), "langwadt@fonz.dk" =
<langwadt@fonz.dk> wrote:

>On 27 Mar., 01:02, Ulf Samuelsson <u...@a-t-m-e-l.com> wrote: >> TheM skrev: >> >> >> >> > "Nico Coesel" <n...@puntnl.niks> wrote in =
messagenews:4bacf169.1721173156@news.planet.nl...
>> >> "TheM" <DontNeedS...@test.com> wrote: >> >> >>> "Spehro Pefhany" <speffS...@interlogDOTyou.knowwhat> wrote in =
messagenews:5elnq5d2ncjvs91v1cu5dmt5tbntuhefg3@4ax.com...
>> >>>> On Thu, 25 Mar 2010 13:19:46 -0800, "Bob Eld" =
<nsmontas...@yahoo.com>
>> >>>> wrote: >> >> >>>>> "Peter" <nos...@nospam9876.com> wrote in message >> >>>>>news:9lhmq5plg1gr3sduo9n52mdi5g6iiqucqc@4ax.com... >> >>>>>> They have doubled their prices and the lead times are 18 weeks. >> >>> Is this limited to EEPROM/Memory only or uCPU as well? >> >> >>> Definitely worth considering getting out of AVR. >> >>> 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. >> >> > Not bad, I ordered a couple books on ARM off Amazon, may get into it=
finally.
>> > From what I see they are same price as AVR mega, low power and much =
faster.
>> > And NXP is very generous with samples. >> >> > M >> >> The typical 32 bitters of today are implemented using advanced >> flash technologies which allows high density memories in small chip >> areas, but they are not low power. >> >> The inherent properties of the process makes for high leakage. >> When you see power consumption in sleep of around 1-2 uA, >> this is when the chip is turned OFF. >> Only a small part of the chip is powered, RTC and a few other things. >> >> When you implement in a 0.25u process or higher, you can have the chip >> fully initialized and ready to react on input while using >> 1-2 uA in sleep. >> >> That is a big difference. >> >> While the NXP devices gets zero waitstate from 128 bit bus, >> this also makes them extremely power hungry. >> An LPC ARM7 uses about 2 x the current of a SAM7. >> It gets higher performance in ARM mode. >> >> The ARM mode has a price in code size, so if you want more features, >> then you better run in Thumb mode. The SAM7 with 32 bit flash is >> actually faster than the LPC when running in Thumb mode, >> (at the same frequency) since the SAM7 uses as 33 MHz flash, >> while the LPC uses a 24 Mhz flash. >> In thumb mode, the 32 bit access gives you two instructions >> per cycle so in average this gives you 1 instruction per clock on the =
SAM7.
>> > >how does that make any sense? wheter an instruction is 16 or 32bit, >24MHz * 128bit is still more that 33MHz * 32 bit ... > >snip > >> >> Best Regards >> Ulf Samuelsson > >-Lasse
It all starts with Amdahl's Law. Double the speed of one thing and if = none=20 of the rest of the system can use the speed increase you get nothing.=20 (slightly overstated)
Reply by Nico Coesel March 28, 20102010-03-28
"TheM" <DontNeedSpam@test.com> wrote:

>"Nico Coesel" <nico@puntnl.niks> wrote in message news:4bad36dd.1738952703@news.planet.nl... >> "TheM" <DontNeedSpam@test.com> wrote: >> >>>"Nico Coesel" <nico@puntnl.niks> wrote in message news:4bacf169.1721173156@news.planet.nl... >>>> "TheM" <DontNeedSpam@test.com> wrote: >>>> >>>>>"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message news:5elnq5d2ncjvs91v1cu5dmt5tbntuhefg3@4ax.com... >>>>>> On Thu, 25 Mar 2010 13:19:46 -0800, "Bob Eld" <nsmontassoc@yahoo.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>>"Peter" <nospam@nospam9876.com> wrote in message >>>>>>>news:9lhmq5plg1gr3sduo9n52mdi5g6iiqucqc@4ax.com... >>>>>>>> They have doubled their prices and the lead times are 18 weeks. >>>>> >>>>>Is this limited to EEPROM/Memory only or uCPU as well? >>>>> >>>>>Definitely worth considering getting out of AVR. >>>>>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. >>> >>>Not bad, I ordered a couple books on ARM off Amazon, may get into it finally. >>>From what I see they are same price as AVR mega, low power and much faster. >>>And NXP is very generous with samples. >> >> The books on ARM may be too generic. Most of the things you need to >> know are in the user manual and the datasheet. NXP's Cortex based >> LPC1000 series need no assembly at all to get running. Even interrupt >> routines do not need special care. > >The datasheet I've seen for one of the NXP ARM did not seem as elaborate as Atmel usually supplies. Probably need general family >user manual to cover gray areas.
You need the user manual. Just scroll down on NXP's web page for the specific controller and you'll find it between the appnotes and example software. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------