feature article
Subscribe Now

Ambiq Apollo MCU Gets Funky With Voltage

Leveraging Physics for the Betterment of Humankind

“Reality is that which, if you stop believing in it, doesn’t go away.” – Philip K. Dick

 

We all work with the same laws of physics. That’s why they’re laws, not guidelines. We deal with Ohm’s Law, Shannon’s Law, Cole’s Law (thinly sliced cabbage), and others. And one of the immutable laws of electronics is that power consumption is proportional to voltage. Raise the voltage, and you raise the power consumption, all other things being equal. And of course, that works the other way, too. Lower voltages reduce power. Very tidy.

So why, oh why, do chipmakers have such a hard time reducing the power consumption of their microprocessors, microcontrollers, DRAMs, and other devices? Just lower the voltage! Did you not attend Electronics 101? How hard can that be?

Pretty hard, as it turns out. Although voltage, wattage, power, current, and energy all behave very nicely in the theoretical realm, they’re much more recalcitrant in reality. Real semiconductor transistors don’t work on a sliding voltage/current scale. They like to switch on and off at discrete voltage levels, determined by the design of the transistor and the geometry and chemistry of the semiconductor materials. You can’t merely dial the voltage up or down and get a clean, tidy, ramp in current consumption. Set the voltage too low and the transistors fail to switch. Crank the voltage up too high and you release the magic smoke that makes all electronics work.

As it stands, most low-power transistors toggle at somewhere around 1.0V. Even though we supply the chips with 3.3V (or even 5V in some cases), the internal transistors really treat 1.8V as fully “on.” That’s a lot more power efficient than earlier 3.3V or 5V transistors. But not as efficient as they could be.

Lowering the supply voltage and/or the switching-threshold voltage sounds like a no-brainer, but implementing it is tricky. CMOS transistors don’t like voltages hovering in that big gray area between fully off and fully on. They leak current badly, and they behave erratically, acting like analog circuits (which, ultimately, they are) instead of digital switches. Sub-threshold voltage levels are a digital no-man’s land.

Unless you work at Ambiq Micro. Then it’s your bread and butter. The small (25-person) company based in Austin thrives in that off-limits zone where other CMOS transistors fear to tread. For Ambiq, 0.5V is considered high voltage. The company designs its digital transistors to switch at extremely low voltages where other transistors just leak, dither, and do weird things. Ambiq’s low-voltage party trick means they had to design all their own digital libraries, transistor models, and testing procedures – but hey, once that was out of the way, it was all smooth sailing.

Ambiq first showed off its low-voltage design expertise with an RTC (real-time clock) chip a few years ago. Like most RTCs, you supply the thing with 3.3V. But, unlike most RTCs, it consumes just a dozen or so nanoamps while it’s running. That’s a remarkably low current draw, even for an RTC. Granted, an RTC isn’t likely to be the biggest energy consumer in your system, so even the world’s most psychotically power-efficient RTC won’t make a huge difference in the overall power budget. But it did make a nice proof-of-concept for Ambiq’s technology.

This week, the company is rolling out its first microcontroller, an ARM Cortex-M4F device it calls Apollo. (Yes, another ARM-based MCU company. When will the madness end?) As such, Apollo joins other M4F-based chips from Atmel, Freescale, Infineon, NXP, Silicon Labs, Spansion, STMicroelectronics, and Texas Instruments. At first blush, all of these MCUs are roughly equivalent, with the same M4F processor core, on-chip RAM and ROM, and a plethora of I/O goodies. Most developers are likely to pick their favorite from out of this candy basket based either on the mix of peripherals or on their experience with the vendor. Did we use a Freescale MCU last time? Splendid, let’s go with them again this time.

Where Ambiq sticks out, of course, is with Apollo’s very low power consumption. How low? How does 30 µA/MHz grab you? That’s the data book spec for Apollo’s active current, and it’s almost an order of magnitude lower than the other vendors’ M4F-based parts. Freescale, for example, boasts run-time current consumption of “under 200 µA/MHz” for its Kinetis K22 device family. NXP’s LPC54100 Series consumes 100 µA/MHz, according to the company.

Perhaps the closest low-power competitor is the delightfully named Wonder Gecko chip from Silicon Labs (after its acquisition of Norwegian-based Energy Micro). Like Apollo, Wonder Gecko is based around a modestly clocked Cortex-M4F core, on-chip RAM and ROM, and the usual assortment of on-chip I/O. Silicon Labs says Wonder Gecko burns 225 µA/MHz while it’s running out of on-chip ROM, while Ambiq claims Apollo uses just 30 µA/MHz: a 7.5:1 difference. In sleep mode, the specs say 63 µA/MHz for the super lizard (and 950 nA for “deep sleep” mode), versus 100 nA/MHz for Apollo.

Of course, sleep modes are notoriously difficult to compare because they have so many different variations, details, and footnotes. No two chips’ sleep modes are directly comparable, and most chips have several different modes. Still, it’s instructive to see that each company’s best marketeering efforts still produce numbers that are off by factors of tens, if not hundreds.

The downside? In spite of its namesake, Apollo ain’t fast. The chip maxes out at a measly 24 MHz. The mighty Wonder Gecko runs twice that fast, Kinetis hits 120 MHz, and some Spansion M4F-based MCUs peak at 200 MHz (although they outrun their on-chip ROM above 72 MHz).

Still, you can’t have it all. If what you’re worried about is minimizing power consumption, then you’re probably not going to be clocking your MCU at triple-digit speeds. At least, not until we see a quantum leap in semiconductor technology or MCU design. Apollo certainly has adequate compute power for a ton of embedded and IoT applications; it does have a floating-point unit and DSP-like features, after all. It doesn’t need to be all that fast. And with prices that start at $1.50 for the small-memory configurations in big quantities, Apollo isn’t the cheapest M4F-based MCU out there, but it’s not hideously expensive, either. It’s a new MCU in a market crowded with similar MCUs, but with one very good trick up its sleeve. Let’s see how the laws of supply and demand play out for Ambiq. 

7 thoughts on “Ambiq Apollo MCU Gets Funky With Voltage”

  1. Pingback: car crash usa
  2. Pingback: bandar judi bola
  3. Pingback: slots
  4. Pingback: Stix Events
  5. Pingback: iraq Seo

Leave a Reply

featured blogs
Apr 7, 2020
Have you seen the video that describes how the coronavirus has hit hardest where 5G was first deployed?...
Apr 7, 2020
In March 2020, the web team focused heavily on some larger features that we are working on for release in the spring. You’ll be reading about these in a few upcoming posts. Here are a few smaller updates we were able to roll out in March 2020. New Online Features for Ma...
Apr 6, 2020
My latest video blog is now available. This time I am looking at the use of dynamic memory in real-time embedded applications. You can see the video here or here: Future video blogs will continue to look at topics of interest to embedded software developers. Suggestions for t...
Apr 3, 2020
[From the last episode: We saw some of the mistakes that can cause programs to fail and to breach security and/or privacy.] We'€™ve seen how having more than one program or user resident as a '€œtenant'€ in a server in the cloud can create some challenges '€“ at leas...

Featured Video

Automotive Trends Driving New SoC Architectures -- Synopsys

Sponsored by Synopsys

Today’s automotive trends are driving new design requirements for automotive SoCs targeting ADAS, gateways, connected cars and infotainment. Find out why it is essential to use pre-designed, pre-verified, reusable automotive-optimized IP to meet such new requirements and accelerate design time.

Drive Your Next Design to Completion Today with DesignWare IP® for Automotive SoCs