Contributed by Mike Stanley
Originally posted on Freescale’s Smart Mobile Devices Embedded Beat Blog
About two years ago, I joined the Freescale sensors team, which focuses on accelerometers, pressure sensors, and touch sensors.
Prior to that, I spent a number of years in the Freescale’s microcontroller solutions group, where I was an architect for several digital signal controller and microcontroller product families. One of the first things I learned when I moved into the sensors group was that certain “rules of the game” that relate to microcontroller design needed to be adapted when dealing with sensors. An example is package selection. With most microcontrollers, package selection is based upon number of functional and power pins required, PCB assembly processes targeted and (sometimes) thermal characteristics. Performance considerations are often secondary, if they exist at all. Sensors interact with the real world. Mechanical stresses introduced during both package assembly and PCB mounting can affect electrical performance of the device; often showing up as additional offset or variation of performance with temperature. Even the compound used for die attach has a demonstrable effect on sensor performance, and must be considered early in the design process.
An early rendering of the MMA9550L package
In my last post, I introduced the MMA9550L Xtrinsic Motion Sensing Platform. Now I’d like to share an overview of the design philosophies incorporated into this product. With one foot in the world of sensors and another in that of microcontrollers, I’m in a rather unique position to comment on design tradeoffs. I compiled the product specification for the MMA9550L and worked with the design teams who designed and built the various components. During the course of the project I met and learned from a large number of talented engineers in a variety of fields. Here they are, in no particular order.
Small size: Cell phones are one of the markets targeted by this device. PCB real estate is precious and even package height is important, as it can be a limiting factor in the thickness of today’s super thin smart phones. The product definition team was told early on that we needed to target a 3X3X1 mm package. Bear in mind that this tiny package needs to enclose two die: the MEMS transducer and the ASIC controller. The package dimensions placed pressure on the ASIC die size, and we subsequently moved to a smaller CMOS process node to accommodate all the circuitry needed. A detailed die size estimator was created very early in the definition cycle, and feature mix was constantly measured against the real estate cost. An LGA package was selected because it allowed us some ability to route signals within the package, which in turn allowed us to minimize die area allocated to the controller pad ring.
Power: The MMA9550L is one of the first products in the market intended for use as a smart sensor hub. Data from multiple sources attached to the MMA9550L master I2C port can be consolidated and pre-processed before sending it along to a host processor. The MM9550 includes significantly more intelligence than analog and state-machine-based digital accelerometers1. Yet its power requirements will still be measured against those products. As an example, at a sample rate of 100 samples per second, in normal mode of operation, the MMA8450Q typically consumes a bit over 70uA. In shutdown mode, that drops to less than 1uA. Conceptually, a state-machine-based product, compared to a microprocessor-based product on the same technology, will always consume less power. Dedicated data paths don’t include memory and instruction overhead associated with an MCU. The trick is to bring the MCU-based system power down to a level where the benefits arising from the MCU outweigh the incremental power consumed by that MCU and associated memories. Low power requirements impacted the following:
- Process selection: We chose an ultralow leakage process, with CMOS logic running off a native 1.8V supply. No regulator was needed for the logic supply, minimizing DC bias currents.
- Memories: We scouted IP sources both inside and outside of Freescale to select the most power conscious memories we could find. This included both flash and RAM blocks specifically designed for low power.
- AFE: The analog-front-end was enhanced for improved noise and sensitivity at minimal power levels. The architect who designed this block measured power consumed in micro-coulombs/ADC conversion.
- CPU: A few years ago, I was a member of the team that designed the first members of Freescale’s “Flexis family” of parts. We created socket compatible 8-bit and 32-bit devices, allowing users to trade off cost versus performance. Along the way, we discovered that for any given task, our 32-bit ColdFire devices consumed significantly less power than their 8-bit counterparts. At first this seemed counter intuitive, until we realized that the ColdFire-based parts needed many fewer instructions to accomplish the same task. After comparing area, power consumption and code size requirements for a variety of architectures (including S08 and ARM architectures), we ultimately settled on the same ColdFire V1 architecture used in the Flexis family. An S08 implementation would have been smaller, but we wanted to keep power down. The added performance from the 32-bit architecture was a big boost as well.
Clocks: In addition to the AFE improvements already mentioned, we spent a lot of time considering how we were going to clock the system. Standard MCUs often have multiple on-chip and off-chip clock sources, including crystal oscillators, relaxation oscillators and phase-locked-loops. Because of the noise sensitive nature of an inertial sensor, we kept our clock sources to exactly one. An on-chip oscillator runs at a nominal full rate of 8MHz, a reduced rate of 62.5KHz (typical), or can be turned off entirely. The clock generation and distribution system can shut down power to the CPU and digital peripherals while the AFE (running from 8MHz) takes measurements during the device’s “quiet time”. After the CPU has completed software tasks associated with each sample frame, it slows down the clock to 62.5KHz, where it remains until the next sample interval. Clock distribution to unused peripherals can be disabled to save even more power. Data and frame rates can be changed on a frame-by-frame basis if desired. And all of the above is software configurable, allowing changes on-the-fly to adjust to environmental conditions.
Data from inertial measurements is placed in a series of mailboxes, which can be read by a host processor via the slave port interface. That interface must be available to the host 100% of the time, even when the on-chip oscillator has been completely shut down to conserve power. I2C and SPI ports on most standard microcontrollers will sample externally supplied clock and data pins with an internal clock running at least 2X the communications rate. MCU designers use this technique because it eliminates (by design) metastability risks associated with moving data across clock domains. The low power nature of the MMA9550L didn’t allow us to use an over-clocked scheme. Instead, we designed custom circuits to negotiate the clock domain boundaries with no corruption of data.
Intelligence: The ColdFire V1 architecture includes options to support a range of cost/performance tradeoffs. The instance used in the MMA9550L includes a 16X16 hardware multiplier to improve performance on DSP-intensive tasks.
Another unique aspect of the design is a firmware-based flash controller. Most Freescale MCUs include a hardware-based controller which is responsible for implementing flash program and erase functions. Since we already have a CPU available, we decided to implement these functions using code stored in an on-chip ROM. The ROM-based controller implements the same functions as a hardware controller, but consumes less than half the area. Once the Freescale marketing team realized we had ROM on the device, it was quickly expanded to include bootloader functions and a ROM-based command interpreter (CI). The CI contains functions for reading/writing memory (including flash), pulling the device configuration from memory, protecting memory, running a CRC over memory and more. Ultimately, we doubled the size of the ROM from our original estimate of 2K bytes to 4K bytes.
Flash memory blocks typically include a lot of area overhead for sense amplifiers and charge pumps. It’s more efficient to include one large flash block than two blocks of half the capacity. Freescale will be shipping devices with approximately ½ of the 16Kbyte flash pre-loaded with a task scheduler and algorithms for sample processing, trim and gesture recognition. We needed mechanisms to protect Freescale code while enabling easy integration of customer code. The solution was to include features in the firmware-based flash controller for “locking” pages of flash memory. Lock status is automatically checked when code or development tools attempt to program and/or erase any page in memory. Software hooks are provided for designers to add their own tasks to the frame by frame schedule of activities. Customer code can be added/modified as desired without risk to Freescale supplied software routines.
I should note that the device has a hardware security feature which restricts the debug port and ROM CI from accessing memory inside the device. The ROM CI also includes functions for data rights management. This allows software-based functions to be locked and/or unlocked using a “shared-secret” handshaking protocol. Lock status is stored in a reserved location in flash memory which is normally invisible to code running on the device.
By now, I think you can see why I’ve titled this post “The Zen of Sensor Design”. During any design process, there is always a constant tension between cost, function and time-to-market. Sensor projects bring together a wider set of engineering disciplines than most semiconductor projects. This project leveraged a wide breadth of Freescale technologies to create a new class of product that breaks existing sensor paradigms. The science involved was intense, but artistry still played a role, and compromise between competing requirements was one of the few constants. Navigating that mix to produce a balanced product took remarkable team work and the courage to change the way sensors will be seen in the future. I think it’s worth the effort.
Notes
1) By “state-machine-based” I am referring to products which include dedicated (and fixed) analog and digital data path circuitry. This class of product often has many configuration options, but ultimately is not programmable in the CPU sense of the word. An example of this class of product is the MMA8450Q, shown below.
MMA8450Q Block Diagram
