match the process sweet spot - just compare the Icc/Vcc/Freq plots of a non-regulator controller, with those using a regulator.
process sweet spot, and you also gain on the Cpd Calculation :
the process curve, the chip vendor might choose.
I'm still not following what your point is. Since when does a chip require an internal regulator to run at the "sweet spot" on Vcc?
If you lower the internal voltage of the processor and use the same external voltage, you are dissipating power in the regulator that you are saving in the core because the on chip regulator is a linear in my experience. You will get some savings because the current can be less, but it doesn't go by the square of the voltage because the voltage on the chip doesn't change.
If you use an external regulator you can use a switcher and save both on the current and voltage giving you the square ratio in the power.
But I thought this was about async processors. How does any of this bear on using async vs. sync processors?
That is very nice to know. Thanks! I've used the print function of some alternate PDF readers, but they print a graphic version which is no longer searchable mitigating the advantage.
I'll look into the Tracker Software XChange reader. I don't think this would violate DCMA, because I don't think they can say the locking is about copyright. I can still copy the file all over the place. But then I'm not a lawyer.
BTW, on a side note, (vaguely related to DCMA) I have a major issue with many, many web agreements that require you to indemnify the web operators and everyone they know. Indemnify is a dirty word in the legal domain as it is equivalent to insurance. To use a web site they require you to insure them against any loss they have, without limitation, over an unconstrained set of conditions, only that it be somehow related to you which is not the same as your "fault".
I am a kayaker and some kayaking groups require you to indemnify the group leader in order to sign up. I typically don't join unless there is something I want. But I do occasionally go as a guest with someone else. When one group leader repeatedly gave me grief (in a kidding manner up until the last time) I finally emailed him a clear, unemotional explanation of why I would not sign up. His response was that, under advice, I could no longer participate in any of the groups paddles, even as a guest. Nothing had changed, guests are not required to sign waivers. But the fact that I knowingly informed him that I did not agree to the indemnification in their club waiver must have kicked in some legal thing that made me a threat. BTW, this group leader is also a lawyer. I guess my point is that lawyers can really screw up the world if they are allowed to run things. DCMA is the same way, lawyers trying to screw the world.
I don't take at face value anything I read. I want to see the research behind it. This is something I have vaguely learned over my career but has been strongly reinforced recently while working with an expert in cold water effects on the human physiology. It seems there are a number of self proclaimed experts in the field who spout "facts" that are not supported by the research in the field. These include respected organizations like the U.S. Coast Guard. Amazing.
If the U.S. Coast Guard can get it wrong, nearly anyone can - so I want to verify "facts".
I would like to see the justification of the first claim, 3x power savings. In a discussion on async processors a few years back when a low end async processor was announced (maybe an 8051 from Philips?) someone said there is a *huge* power savings from elimination of the clock tree. He successfully argued that the clock tree dissipates a lot of power, perhaps 50% of the power in a large, fast design. I can't say that is not true, but I won't believe that 75% of the power dissipation in designs is from the clock tree unless I see some proof. Otherwise, Intel and many others would not be spending so much time and money minimizing the static power in their transistors. They would be finding ways to reduce the power in the clock tree.
Other than the clock tree, there is little difference in the operation of async and sync designs. Both can be throttled when not needed. Async can be throttled automatically pending transition on and input and sync designs can have the clock gated to sections not needed.
So what supports the 3-4x power savings? One design?
I acknowledge the EMI savings, although it would need to be quantified and evaluated for significance in each design. I've never done a design that had trouble with EMI, but then typically my designs are not especially fast or large.
Although a processor can be designed using async logic, most systems still require a clock for timing which means they need a crystal oscillator. You can't run an ADC without accurate timing. You can't even run most communications without accurate timing which requires a crystal oscillator. To minimize power the oscillator must be shut down and restarted regardless whether the processor is async or sync. So this is a specious "advantage".
Yes, and my point is that you can't just look at the processor, you have to look at the system. How much advantage is there to an asynchronous processor in a synchronous world? This mitigates many of the advantages and means you have to look at the claims with a critical eye.
If they were so great, why aren't they taking off? It's not like they haven't been designed... 8051, ARM, GA144...
Err, because the optimal operating point, for any process might not be equal to Vcc.
The gains are still there, and if you have a large processor then you use a switching regulator. Some uC have switching regulators, most of the small ones use Linear, as they are smaller/simpler and the gain is still positive.
The big players do this now, and their voltage-link is getting more complex, as they balance Speed and Vcc, and chase lower power.
I thought that was self-evident ? Async naturally tracks speed to Process, Vcc and Temperature.
Once you start manually tracking Vcc (and temperature) to speed, you have removed most of the advantages of the Async choice. The overall system design is what the customer is buying. They care less about how the details are done.
This is why Async has not taken off, as you correctly observe.
Welcome to the 1% rule. I essentially agree with you that in most things we do we are responsible for the consequences. There is a very wide gray line subject to a lot of after the fact interpretation that makes companies and individuals liable for something that they had essentially nothing to do with.
The craziest example I know about is and almost 1 to 1 relationship better Cessna aircraft crashes and lawsuits, if they can be found 1% liable than they can be forced to pay the entire cost of liability and it is up to them to collect from the others named. Cessna general aviation products are now mostly manufactured in France.
I am not a lawyer but this crosses my common sense filter.
I don't follow. I said why an "internal" regulator?
switching regulator. Some uC have switching regulators, most of the small ones use Linear, as they are smaller/simpler and the gain is still positive.
The gain is minimized with a linear. On a small processor the gain is small and often of little consequence. But I guess as Vcore drops more it is more significant, but most very small processors don't use the lowest Vcore since they are not pressed for size and use older technology.
as they balance Speed and Vcc, and chase lower power.
If power is important and Vcore is very low, a switcher is the solution, not an internal regulator.
Where is the value in that? I have to design in a synchronous world so my code has to meet the external timing constraints under worst case of PVT. Why do I care if any given processor runs a little faster? The same is true of sync processors. Some can be overclocked but I can't take advantage of that in production.
I certainly don't see the connection with *internal* regulators. In fact an external regulator can have the voltage set to suit the processing requirements.
about how the details are done.
I don't follow your comment about "tracking". What do you mean by that? How does Vcc and temp track speed? I thought it was the other way around?
You may want to have a look at "Atmel Studio". This includes an IDE gcc compiler for the AVR and the SAM3/4/7 ARM Microcontrollers from Atmel. All free of charge.
There is a new Cortex M4 family with real low power coming out SAM4L. About half the power consumption of the "obvious" low power ARM (EnergyMicro), measured in CoreMarks.
You also get the AVR32 support for free.
Anyone really interested, Atmel Sweden hired 2 guys from Microchip, who had been on a tour presenting the PIC32 to 28 customers. They were all using ARM, and most from Atmel. That was when they left...
A long time ago, I had a discussion with Prof Trevor Mudge at University of Michigan, which was (is?) one of the key universities, teaching processor architecture in the U.S. His opinion about asynchronous processors was that, they are nice, except they are half the speed, twice the size, and twice the power consumption.
A few years ago, I visited an exhibition, where there was a student electronics contest. ALL except one, was using the AVR. The black sheep were using a PIC. When the well behaved students noticed I was working at Atmel, then they demanded that I go over to the PIC users booth and talk sense to the teachers... Apparently, they had just finished the development of the PIC course one month ago, and were not that interested in developing a new course, but one month after, I was invited to discuss a new course, where the controller needed CAN, resulting in them selecting the AVR with CAN.
Next exhibition, I talked to some friends in the IAR booth, and told them that at the last exhibition, every university except XXX was using the AVR, but now XXX is also going to use it. "Are we", the gentleman next to me said in surprise. It turned out that he was responsible for course development at XXX. He told me that they have noticed that, while they teach PIC at the university, the students use AVR at home.
time ago now, and I believe Atmel have sold all their French assets.
There are two Atmel locations in France. Rousset, close to Marseille, and Nantes on the Atlantic coast. Nantes was the old Matra Harris stuff. Nowadays, they are busy designing AVRs, AVR32s and ARMs. BR Ulf
Plenty do. The RS08 from Freescale uses a Low voltage core, the latest 8051 from Silabs have on-chip regulators, as do ABOV, and the latest Infineon parts have core voltages down toward 1.5v/0.95V, but 5V IO.
Size does matter, even on 8 bit cores, as that sets price.
Once you have implemented an on chip regulator, beside the energy efficiency gains, and ability to chose whatever CoreVcc your process likes, you also gain Wide VCC. The newest Renesas parts take exactly this approach.
Sure. Especially true on processors.
If you want to focus on the word internal, of course it does not matter if the regulator is *internal* or *external*.
Most small micros now include the regulator, so internal was merely that instance. Most large processors use external, but this is comp.arch.embedded, so I focus more on smaller one-chip parts.
A natural synergy from internal regulator, is full vendor control, but there is nothing stopping a vendor defining an external regulator at 1.456v. Customers will see that as a pain, and worse, if the process changes, they need to change their BOM. With an internal regulator, customers now do not have to care.
but yes, you are right, a uC vendor *could* ignore all this and specify an external regulator.
I have seen some use an external NPN - not sure if that is defined as
*internal* or *external* - the regulator and voltage decision is internal, the power-element in external, and allows multi-rail choices..
On Tue, 16 Oct 2012 00:46:57 +0200, Ulf Samuelsson wrote:
I will do that. Thanks.
I am still struggling (wrestling with myself) about just where, how, and .. well and still just how.. I am going to address 32-bit. It's a complicated environment, partly because when these parts are required by an application space, it's at a professional skill level already so the paths for hobbyists are not nearly as well worn down as I'd like (meaning more work for me, which I don't like.)
I've been looking at the M4 and M4F (seems there are more than one or two implementations of the floating point, too) and considering that direction. I'm also looking closely at the PIC32, partly because of my background with the R2000 series and the education I received directly from Hennessey in the mid-1980's. I admit that my experience there would probably inform me a little better for writing about M4k or M14k, for example. There is another element, which cuts both ways, in that it's a lot easier to focus on something where I only have to worry about one company (Microchip.) ARM is a vast and wide territory. (Which is why I say it cuts both ways -- one may argue that experience with ARM-related tool development would help those students looking to get jobs later on, perhaps a little more than PIC32 would do.) But I'm still working on sharpening the exact vision (which means I'm just immersing myself and hoping that when I come up for air I might find an inspiration.) It's not yet clear that I'm focused on people just looking for jobs, since I really want to reach people for whom this is not just a job, but a love and avocation. Something that regardless of what they do, or where they go, they will always be wanting to do this. People looking for job skills have an entire world of people out there to help them -- from universities to private tutoring to immersion-experience week-long classes to you name it. It is a field already filled with a wide spectrum of services. I'm not interested in focusing on those people who just do this for work. But I don't mean to exclude them, either. I just have my eyes pointed slightly off that beam. If you can understand that.
Now that's cool. From whom? (Here in the US, I mean.)
formatting link
1.pdf
I'm sure they've hired people from Atmel, as well. But I can tell you quite clearly the difference in support I've personally received, halfway across the world. And the parts I could NOT get for a difficult period of time where Microchip kept right on serving us small fry types.
I think Atmel parts are just fine and I use them for hobbyist stuff. I still have my old STK500, too. :) And many other tools and tubes of parts. I like them fine and I honestly believe they are great for the audience I'd like to reach, too. So don't get me wrong about any of this. Atmel figures high on my hobbyist scoreboard.
But too many times had difficulties when there should not have been, for professional tools. And I've so far NOT ONCE in 25 years been let down by Microchip. And when I've cared to ask for it, they never paused and just put me directly in touch with those doing the primary work so that I could get the real scoop from the source (and not a filtered soup I wasn't sure of.) No one comes close there, in my experience. I don't know why they do it. I just know they do. (Or, all of my product experience has somehow been very 'lucky'. But I doubt that.)
Regardless, Atmel is a great company and I'm sure most of its customers are VERY satisfied with them. I don't mean to imply differently.
Now you are making me remember the 8080 days, with separately phased external clocking systems (and therefore the need for a couple of additional ICs, if you didn't want to do the design there.) And the old DRAM products, too. Oh cripes.
Summer 2000, switching an old design from PIC16C71 to 16C711, we found that the transconductance of the oscillator inverter was much lower than stated, about 80uA/V instead of the 450uA/V specified. The old
16C71 had approx 500uA/V. Never got a good answer from Microchip.
When a bunch of MCP3553 had a sample rate of 26/s instead of
60samples/s, I got a better reply: "There may be an issue", they wanted to get the parts.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
I have never had a case where I have not been able to advocate on behalf of one of our customers to Microchip and not got a satisfactory answer. Including private follow-up from Microchip to verify that the customer issue is resolved.
Microchip support is almost now unique in the industry.
I tracked down a silicon bug with the ICE 2000 system (about a year or two after your experience.) The PIC18 involved (PIC18F252, memory serving, and we'd been using the C part beforehand) had its errata changed on the web within 2 weeks and I had new parts in my hand, fixed by a rev, in about 3 months. Might have been even earlier. But I know I was surprised to receive them so fast, having worked peripherally in and around FABs here. I haven't experienced that from other vendors.
I do remember an internal 8-page (or so) document I'd been handed (by Microchip) on their oscillator system, back in the mid 1990's. Learned from it that they ran their oscillators as pretty hot class-A inverters to ensure fewer problems in the field and that I could save half the operating power driving just one pin and going external, using for example Harris's HA7210 (Intersil.)
I've always been able to be put in touch with the right people, for some reason, who actually knew the answers. It didn't always happen the same day, of course. But it has always happened soon.
Did you send them the parts? (Or do I misunderstand?)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.