You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • A Crossover MCU

    Back in the day we had processors which consolidated computing power onto a chip, and out of these sprang (if you’ll excuse the Biblical imagery) microcontrollers (MCUs) in one direction and increasingly complex system-on-chip (SoC) processors in another direction. SoCs are used everywhere today, in smartphones, many IoT devices, networking switches and many more applications. MCUs played a vital though less glamorous role in machine control, handling our anti-lock braking (ABS) and fuel-injection, in implanted medical devices, power tools and many other applications your probably never realized contained a processor.

    Article: Apple Will NOT Manufacture SoCs at Intel-nxp_i.mxrt_chipshot_oct202017-min.jpg

    A key characteristic of these systems was absolute reliability and real-time responsiveness. You probably don’t care about hooking up your pacemaker or your ABS to iTunes, but you very much do care that they will work dependably (no need to reboot constantly) and will continue to do so for many years. So the great majority of development in MCUs went into cost, low power, reliability and support for RTOS, while functional advances moved more slowly.

    But IoT pressures have changed this landscape. Now there is a greater need for future-proofing as communication, security and other standards evolve. System builders expect to be able to gather data from these systems to process in the cloud, they expect to be able to support over-the-air (OTA) updates to minimize maintenance costs and keep systems relevant and compliant, they need to support higher levels of performance and they need support for the aggressive types of power management used today in applications processors (APs).

    All of this while, of course, still providing the reliability and real-time response for which MCUs are known. You can’t just replace all the MCUs with APs. APs don’t provide RTOS–grade support since they have (among other things) unpredictable interrupt latencies. But you still want all those goodies you get in an AP. Getting to this is a big deal. I think I’m remembering an ARM-provided statistic correctly when I say that ~80% of the systems built on their platforms are MCUs, so these are huge volumes waiting for these devices if this transition is possible.

    Taking a leaf from the automakers playbook, NXP (who are very well known in this market) have chosen to address this need though what they call a crossover MCU. This is quite a device (actually a small family of devices – iMX.RT). It’s based on a Cortex-M7, supporting RTOS operation and delivering, apparently, 50% higher performance than similar products. It provides 2-D graphics support, camera interface, LCD controller and hi-performance audio support. And it provides interfaces to wireless connectivity for WiFi, Bluetooth, BLE, ZigBee and Thread. Remember – this is an MCU.

    It provides a wide range of memory interfaces and on-board supports for AES, High-Assurance Boot and on-the-fly flash decryption. And the device includes an integrated PMIC so you can manage power directly without need for an extra device on your board. You can naturally leverage the NXP and ARM development ecosystems, there are dev boards, and so on.

    NXP told me that this MCU is already available in TSMC 40nm and 28nm FDSOI with Samsung, which they believe provides a good roadmap towards RF and non-volatile additions to the family. And of course they’re working on shrinks and lower node implementations. Sounds to me like these crossover devices may be the wave of the future in advanced MCU applications. And potentially even in less advanced applications if we expect to wire them into the IoT. Maybe not my toothbrush though. You can read more about these processors HERE.