feature article
Subscribe Now

Dawn of a new Ara

What’s Google’s New Modular Smartphone Really About?

It would be easy to blow off Google’s “Project Ara” modular smartphone concept as just another one of those Google science fair projects that will never come to anything. Remember “Google Wave” anyone? Yeah, we were all “waving” bye-bye to that one before it ever got off the ground. As engineers, we all know that only one out of every dozen or more cool technology ideas ever comes to anything interesting. But, Google’s propensity for over-funding lots of blue-sky projects just to see if anything sticks is well known, and it is a fertile breeding ground for highly-public failures.

The marketing for Ara doesn’t help much either. Billed as the “smartphone for the next five billion people,” the marketing concept just doesn’t hold water. The implication is that all those people out there who currently don’t have a smartphone (you know the ones) have been just waiting around patiently until somebody gave them a phone they could customize with various application processors, wireless modules, memories, screens, cameras, and accelerometers. Hmmm… Just take a quick poll of the folks you know who don’t yet have a smartphone. Think it’s because they really really want the quad-core? Yeah, me neither.

Forgetting the five billion fantasy for a minute, just who would want a smartphone that you can customize with a wide variety of plug in modules? Probably folks like engineers, that’s who. So, while Google’s marketing seems to indicate they’re aiming at the long tail of the smartphone adoption curve, they’re much more likely to find their customers in the early-adopter crowd.

That’s all OK, actually. Ara doesn’t have to fulfill the promises of its marketing hype in order to accomplish something truly revolutionary.  But, before we dive into our analysis, let’s take a step back and look at what Ara really is. 

The idea behind Ara is to build an open hardware architecture for smartphones. The core of the device is an aluminum endoskeleton – a frame that can accept plug-in modules of varying sizes. Initally, three different sizes of endoskeletons are planned – small, medium, and large. In theory, you could own multiple endoskeletons and move modules around between them constantly, depending on your needs. Want something tiny to slip into your pocket? Populate the small frame. Need to do some serious work? Grab the big one and slip on a large screen – and you get something like a “phablet.” 

The modules are held into their slots in the endoskeleton by a clever electropermanent magnet scheme. The magnets hold fast with no power applied, and they can be electrically released on command. In order to avoid electrical connectors, close-proximity capacitive connectors are used – with SerDes links that support up to 10Gbps to the backplane. The connections are accomplished via a (new) MIPI standard called MIPI UniPro (which, when combined with MIPI M-Phy creates MIPI UniPort-M). While some of the details of the connectors and the magnet scheme have yet to be completely worked out, the idea is to provide for interchangeable modules that can be completely smooth with no connector pins or sockets.

Modules can be designed by any third party (yep, this means YOU, so go ahead and grab yourself a dev kit and get crackin’). What would such a dev kit look like (we hear you ask)? Well, imagine an FPGA development board with a Lattice FPGA on it – in smartphone module form-factor – and you’re pretty close. Lattice also supplies the tiny tiny FPGAs that connect each module to the backplane, so – counting up modules and backplane connections – there could potentially be a 2-digit number of Lattice FPGAs in a single Ara smartphone. Nice socket score for Lattice, and also an FPGA application that really no other FPGAs were positioned to capture given the form-factor and power constraints. 

Every single component of the phone is modular: applications processor, screen, memory, battery, wireless, accelerometers, camera, GPS, that-thing-you’re-designing – all of it plugs right in. Of course the OS is slated to be Android, and it turns out that making Android work in an Ara-friendly way is no small chore. It seems that Android has historically been custom built for each unique hardware configuration – which is easy when your customers are companies like… Samsung, and there are a small number of phone configurations to support, and end-users aren’t CHANGING those configurations DAILY in the field.

Uh, oh.

So – Android needs a tweak or two under the hood (where “tweak” may be defined as near-total-re-write, but we digress). The team is working on a new, more module-friendly Android as we speak. At the recent Ara Module Developers’ Conference, we got to see the world’s first public demo of an Ara prototype actually booting Android. So – it can be done.

Now, I know you all want to run out and start designing amazing whatsits for Ara phones, and it makes sense. After all, you probably haven’t gotten the call from Apple or Samsung telling you they just had to have your [insert cool thing here] in the next iPhone or Galaxy, but Ara gives you a chance to do it anyway. It’s the self-publishing model for smartphone hardware – complete with a hardware version of an app store. But, before you order your MDK (module developers’ kit) and start cranking out the Verilog, let’s talk a bit about what Ara is and what it isn’t.

It’s pretty easy to imagine being frustrated by a phone that is really a cluster of modules, when we’re used to the hardened, monolithic chunks of tech wizardry we all currently carry around. Will Ara phones survive the drop test, or explode into a frustrating pile of modules and broken displays? How will you recover a bricked phone that has no power – when it requires power to get the endoskeleton to loosen its death grip on the modules? Will it feel cool in your hand? The questions go on and on.

Yeah, they’re working on all that. It’s a prototype, OK?

However, picture available camera modules from players like Canon, Nikon, and Fuji. Imagine being able to choose from a variety of displays. Picture special medical plug-in modules, or a high-end oscilloscope probe interface that slides right into a module bay. When you start thinking about specialized capabilities that could be put into smartphone modules, the architecture suddenly transcends our vision of “smartphone” into something more – a modular, extensible, connected portable computing platform, which could be the base for just about any kind of mobile application.

There are other nice side-effects of the architecture as well. If you drop your phone and break the screen, just pop in a new one. If they come out with a faster processor, a better battery, a really cool blood chemistry analyzer, fitness monitor, or other “oh, I need to upgrade” kinda’ capability – you don’t need to upgrade. You just pop in the new module. Biennial smartphone obsolescence could potentially become a thing of the past.

We don’t know if Ara will take off, or go the way of the Newton. However, like the Newton, some important concepts Ara introduces will almost certainly survive – and that will be good for all of us.

2 thoughts on “Dawn of a new Ara”

  1. Android is Linux-based, and I doubt that anybody would be willing (much less capable) to rewrite a new kernel from scratch. Other than that, I find it likely that the module system may have to be improved.

    Another thing I’d like to comment on is how people will design their modules. Using Verilog (or VHDL or similar languages) would be the best way to make it very hard for anybody but hardware designers to make modules for Ara. This would very much limit the size of the community around Ara, yet a large community is key to the success of many new technologies.

    What if instead we used a modern language, perhaps a little bit higher-level? It would mean that most coders would have the possibility of creating Ara modules. It could make the community 100x bigger. Take a look at Synflow to see what I mean!

  2. The modular construction approach offers up some additional interesting possibilities for what your phone can potentially ‘plug-into’. Imagine an extruded Ara module form-factor receiver built into a front panel of a larger device. Release a spare module cover and connect via that bay to a face-plate dock with an EPM anchor. Your phone now becomes a personalized interface apparatus for a variety of other more complex devices. Imagine an air-plane seat, automobile dash, CNC mill, security system, home automation console, home entertainment system, etc.

    No one has yet to perfect the universal phone dock. However the number of devices on the market that accept iDevice bases proves a large market is waiting for a standard.

Leave a Reply

featured blogs
Aug 19, 2018
Consumer demand for advanced driver assistance and infotainment features are on the rise, opening up a new market for advanced Automotive systems. Automotive Ethernet allows to support more complex computing needs with the use of an Ethernet-based network for connections betw...
Aug 18, 2018
Once upon a time, the Santa Clara Valley was called the Valley of Heart'€™s Delight; the main industry was growing prunes; and there were orchards filled with apricot and cherry trees all over the place. Then in 1955, a future Nobel Prize winner named William Shockley moved...
Aug 17, 2018
Samtec’s growing portfolio of high-performance Silicon-to-Silicon'„¢ Applications Solutions answer the design challenges of routing 56 Gbps signals through a system. However, finding the ideal solution in a single-click probably is an obstacle. Samtec last updated the...
Aug 16, 2018
All of the little details were squared up when the check-plots came out for "final" review. Those same preliminary files were shared with the fab and assembly units and, of course, the vendors have c...
Jul 30, 2018
As discussed in part 1 of this blog post, each instance of an Achronix Speedcore eFPGA in your ASIC or SoC design must be configured after the system powers up because Speedcore eFPGAs employ nonvolatile SRAM technology to store its configuration bits. The time required to pr...