What is happening to Atmel EEPROMs?
in [Embedded]
|
Prev: BT earpieces
Next: USB 3.0 implementation on FPGA
From: Jon Kirwan on 27 Mar 2010 04:01 On Sat, 27 Mar 2010 08:15:03 +0100, Ulf Samuelsson <nospam.ulf(a)atmel.com> wrote: ><snip of LPC2xxx vx SAM7S discussion> >The 128 bit memory is overkill for thumb mode and just >wastes power. ><snip> Ulf, let me remind you of something you wrote about the SAM7: "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." I gather this is regarding the case where there is 1 wait state reading the 32-bit flash line -- so 2 clocks per line and thus the 1 clock per 16-bit instruction (assuming it executes in 1 clock.) Nico's comment about the NPX ARM, about the 128-bit wide flash line-width, would (I imagine) work about the same except that it reads at full clock rate speeds, no wait states. So I gather, if it works similarly, that there are eight thumb instructions per line (roughly.) I take it your point is that since each instruction (things being equal) cannot execute faster than 1 clock per, that it takes 8 clocks to execute those thumb instructions. The discussion could move between discussing instruction streams to discussing constant data tables and the like, but staying on the subject of instructions for the following.... So the effect is that it takes the same number of clocks to execute 1-clock thumb instructions on either system? (Ignoring frequency, for now.) Or do I get that wrong? You then discussed power consumption issues. Wouldn't it be the case that since the NPX ARM is accessing its flash at a 1/8th clock rate and the SAM7 is constantly operating its flash that the _average_ power consumption might very well be better with the NPX ARM, despite somewhat higher current when it is being accessed? Isn't the fact that the access cycle takes place far less frequently observed as a lower average? Perhaps the peak divided by 8, or so? (Again, keep the clock rates identical [downgraded to SAM7 rates in the NXP ARM case.]) Have you computed figures for both? Jon
From: bigbrownbeastie on 27 Mar 2010 04:38 On Mar 25, 12:57 pm, Leon <leon...(a)btinternet.com> wrote: > On 25 Mar, 11:20, Peter <nos...(a)nospam9876.com> wrote: > > > They have doubled their prices and the lead times are 18 weeks. > > > Yet, others are making them OK. > > > Are Atmel trying to get out of the business? > > x----------x > > They got rid of their fabs, and are now having to join the queue at > TSMC or wherever they get their chips made. They are probably having > to pay a lot more for them, because of demand for the manufacturing > facilities. Microchip have their own fabs, and seem able to keep up > with demand. Some ARM cored micros are on 40 week lead times, good thing atmel manafacture the AVRs themselves. For related see here: http://www.electronicsweekly.com/blogs/david-manners-semiconductor-blog/2010/03/when-youve-got-your-customer-b.html
From: Nico Coesel on 27 Mar 2010 05:56 Ulf Samuelsson <ulf(a)a-t-m-e-l.com> wrote: >TheM skrev: >> "Nico Coesel" <nico(a)puntnl.niks> wrote in message news:4bacf169.1721173156(a)news.planet.nl... >>> "TheM" <DontNeedSpam(a)test.com> wrote: >>> >>>> "Spehro Pefhany" <speffSNIP(a)interlogDOTyou.knowwhat> wrote in message news:5elnq5d2ncjvs91v1cu5dmt5tbntuhefg3(a)4ax.com... >>>>> On Thu, 25 Mar 2010 13:19:46 -0800, "Bob Eld" <nsmontassoc(a)yahoo.com> >>>>> wrote: >>>>> >>>>>> "Peter" <nospam(a)nospam9876.com> wrote in message >>>>>> news:9lhmq5plg1gr3sduo9n52mdi5g6iiqucqc(a)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. I think this depends a lot on what method you use to measure this. Thumb code is expected to be slower than ARM code. You should test with drystone and make sure the same C library is used since drystone results also depend on the C library! >Less waitstates means higher performance. >By copying a few 32 bit ARM routines to SRAM, >you can overcome that limitation. >You can get slightly higher top frequency out of the LPC, >but that again increases the power consumption. > > >For Cortex-M3 I did some test on the new SAM3, which can be >configured to use both 64 bit or 128 bit memories. >With a 128 bit memory, you can wring about 5% extra performance >out of the chip compared to 64 bit operation. >From a power consumption point of view it is probably better >to increase the clock frequency by 5% than to enable the 128 bit mode. >It is therefore only the most demanding applications that have >any use for the 128 bit memory. > >Testing on other Cortex-M3 chips indicate similar results. > >Someone told me that they tried executing out of SRAM on an STM32 >and this was actually slower than executing out of flash. >Executing out of external memory also appears to be a problem, >since there is no cache/burst and bandwidth seems to be lower >than equivalent ARM7 devices. That doesn't surprise me. From my experience with STR7 and the STM32 datasheets it seems ST does a sloppy job putting controllers together. They are cheap but you don't get maximum performance. >Current guess is that the AHB bus has some delays due to >synchronization. Also if you execute out of SRAM >you are going to have conflicts with data access. >Something which is avoided when you execute out of flash. NXP has some sort of cache between the CPU and the flash on the M3 devices. According to the documentation NXP's LPC1700 M3 devices use a Harvard architecture with 3 busses so multiple data transfers (CPU-flash, CPU-memory and DMA) can occur simultaneously. Executing from RAM would occupy one bus so you'll have less memory bandwidth to work with. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
From: Paul Carpenter on 27 Mar 2010 06:03 In article <4BAD45B3.2000507(a)a-t-m-e-l.com>, ulf(a)a-t-m-e-l.com says... > Leon skrev: > > On 25 Mar, 11:20, Peter <nos...(a)nospam9876.com> wrote: > >> They have doubled their prices and the lead times are 18 weeks. > >> > >> Yet, others are making them OK. > >> > >> Are Atmel trying to get out of the business? > >> x----------x > > > > They got rid of their fabs, and are now having to join the queue at > > TSMC or wherever they get their chips made. They are probably having > > to pay a lot more for them, because of demand for the manufacturing > > facilities. Microchip have their own fabs, and seem able to keep up > > with demand. Different manufacturers have different levels of outsourcing, from all processes are outsourced (100% outsourced), to all in house. Sometimes some of the processes are outsourced because the majority of their machinery is now for smaller geometry, and the wafers only may be outsourced for some products to be made somewhere that has the larger geometry proceses. > While at least some memory chips are outsourced, the AVRs are still > manufactured inside Atmel. ..... > If there is no stock, then it normally takes 16 weeks to > produce new things for any semiconductor manufacturer. > > Quite often, the fab capacity is not the problem, but testing is. > If you can't buy new testers, then capacity cannot increase. > Companies doing test equipment cant deliver, because they > have long lead times on components. Hmmm... Reminds me of an ASIC company whose customer in purchasing wanted to bring forward the next 6 months of production to that week, and asked "can't you just put more people on it?". At the time that would have been impossible even with stocks of wafers, as this was an avionics ASIC. The testing procedure for this avionics ASIC was Wafer test electronically room temperature Package good parts Package test electronically room temperature Place large batch in oven and power all devices with clocks attached, and leave all parts running for a week at 125 deg C After a week slowly drop temperature to then test electronically at room temperature lower temperature to -55 deg C electronically test Parts needed a second packaging process and then retest at room temperature. All with full serial number of device and batch testing logged. If new wafers are needed you can add 12 weeks in front of that. Environmental chambers and testing for full temperature range is a long job and about every 12 to 18 months you have to strip down and replace ALL the internal wiring, connectors and boards. Imagine the setups required for testing upto 120 off 100 pin devices in enviromental chambers and how many you require. Designing the PCBs is also fun... -- Paul Carpenter | paul(a)pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
From: Ulf Samuelsson on 27 Mar 2010 08:56
Peter skrev: > Ulf Samuelsson <ulf(a)a-t-m-e-l.com> wrote > >> ATmega128A is probably a better choice. > > We have a development kit for the 128 (bought ~ 2 years ago) so we > will get a new one of those. > > What kind of price is the 128A, 1k+, these days? No clue, but they should be lower than the ATmega128. Should have lower power consumption as well. BR Ulf Samuelsson |