When the news first broke on the addition of the M7 co-processor to the CPU assets of Apple’s 5s and iPad Air this past fall, the buzz was about how this highly derated, i.e. 145 MHz, low power processor would be used for processing the sensor inputs of the devices.

We discussed earlier that the M7 would de-load the main processor and more efficiently manage apps from the energy consumption point of view (12/4/13 “The BIG NEWS Behind Apple’s September Announcements”). We assumed that this co-processor would be used by developers for fitness apps.

This premise was verified by the fact that the first seven or so apps after launch, that used the M7, were in the fitness family.

Further information emerged on the particulars of this co-processor, primarily from a Chipworks teardown, which identified the key component, an NXP microcontroller, which resulted in the 145 mhz speed factor, and the fact that it was hardwired to the sensors, which would indicate an extremely capable and highly energy efficient, almost application-specific type of CPU.

However, we believe the significance of the co-processor could be far greater. The use of the co-processor may well identify a future architectural approach by Apple, which further extends their philosophy of wrapping hardware and software together in a total package. The M7 (or M7 family) could be used in the future for specific sets of apps, of which sensor aggregation is only one.

All other things being equal – and we are aware of the dangers of this assumption – a co-processor of this type could extend battery life by whole number multiples, maybe by 10 times.

The future in this hetero processor and software world would mean:

• Past: one CPU plus mobile cloud software for all things.
• Today (with M7): a) GHz CPU (currently A7) and mobile cloud software for heavy lifting. b) M7 CPU and mobile cloud, specific software apps for, basically stage one sensor aggregation processing.
• Tomorrow (with M7 family): M7 stage two, characterized by repetitive load relief, ASIC type of functionality, which could include, for example: a) notifications, alerts, b) UMTS/WiFi – on/off but not simultaneous operation, to conserve power, c) Bluetooth/NFC operation, d) Apple AirPlay/printing, e) time, f) simple maps.

In other words the mundane is eventually handled by the M7 plus the cloud, with potentially an enormous improvement in battery life.

The leap from sensors to other types of inputs such as UMTS supervision, comes from the following logical extensions.

We assume that Apple’s goal is to significantly extend battery life without complicating or creating difficult tradeoffs for the existing and future app development ecosystem. Therefore an architectural approach may have to be found to segregate CPU type of activities in a way that radically increases the efficiency of the CPU assets at a radically lower power consumption level.

The classic approach to this problem is to use an ASIC. The world of microcontrollers and rigid standards have come to Apple’s aid.

The UMTS supervisory channels, pings etc. and standards such as Bluetooth Low Energy (BLE) and ZigBee for electrical device management offer very algorithmic, yes/no, solutions in their structure and thus are conducive to ASIC type solutions. Our connecting of the dots in this commentary relies not only on this line of reasoning but also the choice of NXP, a firm that makes an extensive line of UMTS and ZigBee micro-controllers.

It is interesting to note that the almost decade old 802.15.4 IEEE standard (characterized by low data rate, mesh network, low device cost orientation, internet accessible and low energy requirements by design) is growing in use with the Internet of Things and smart grid commercial activities.

It is with a smile that we reflect on news reports that Apple was a bidder for Nest (acquired by Google), Nest being a ZigBee based home network device (thermostat controller).

In this heterogeneous picture, even the device’s relationship to its cloud assets may be further optimized as this processor can be focused on improving the efficiency of the cloud assets-to-device linkages.

These thoughts are really identifying a further asset in the Apple to developer SDK which can probably vastly improve the battery life of the iOS device.

We see the overall likely objective of Apple as being to create a great environment for app development, by simplifying developers’ chores by de-loading the strain on the main processor and putting apps into families where apps that have clearly defined sets of rules can be handled by a family of co-processors.