WP_Term Object
(
    [term_id] => 13
    [name] => Arm
    [slug] => arm
    [term_group] => 0
    [term_taxonomy_id] => 13
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 392
    [filter] => raw
    [cat_ID] => 13
    [category_count] => 392
    [category_description] => 
    [cat_name] => Arm
    [category_nicename] => arm
    [category_parent] => 178
)
            
Mobile Unleashed Banner SemiWiki
WP_Term Object
(
    [term_id] => 13
    [name] => Arm
    [slug] => arm
    [term_group] => 0
    [term_taxonomy_id] => 13
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 392
    [filter] => raw
    [cat_ID] => 13
    [category_count] => 392
    [category_description] => 
    [cat_name] => Arm
    [category_nicename] => arm
    [category_parent] => 178
)

NXP Pushes GHz Performance in Crossover MCU

NXP Pushes GHz Performance in Crossover MCU
by Bernard Murphy on 11-20-2019 at 6:00 am

I first heard about NXP crossover MCUs at the 2017 TechCon. I got another update at this year’s TechCon, this time their progress on performance and capability in this family. They’ve been ramping performance – a lot – now to a gigahertz, based on a dual-core architecture, M7 and M4. They position this as between 2 and 9X faster than competitive solutions, certainly a major performance advantage.

RT1170 system

Quick refresher on why they’re doing this. MCUs used to be the staid but inexpensive and reliable cousins of the flashier processors you’d find in your phones. What you wanted in your car, appliances, printers and many applications wasn’t a lot of flash and features; you wanted reliability and low cost. Now thanks to the explosion in expectations for what everything and anything should be able to do, we now want very high performance and very low power, communications, human machine interfaces, voice recognition and face id everywhere. Still at very low cost.

Perhaps you could do this by scaling advanced processors down to MCU price levels (few $), but that’s a big stretch. And there are other considerations besides cost. Many MCU apps depend on real-time support and for that they have to run real-time operating systems rather than the Linux OS used by their up-market cousins. On top of that, requiring a large base of MCU application developers to switch OS would be impractical. Also, while product teams using MCUs want to take advantage of AI capabilities, they have limited resources and expertise. For all these reasons, NXP argues that it’s best to start with architectures built for MCU developers and grow them into supporting advanced features. Makes sense to me.

The dual processor approach follows a familiar big.little kind of theme, in which a high performance (1GHz) M7 core handles advanced applications only needing to run intermittently, such as smart speaker functions (audio pre-processing through echo cancellation, noise suppression, beamforming, etc). A lower-performance (400MHz), more power efficient core (M4) can handle lighter weight and standby tasks such as wake-word processing. In fact the M4 can handle more than that, according to Gowri Chindalore, Head of Strategy for embedded processing. He told me it can also handle fingerprint sensing, quick voice recognition and quick face id. The two cores are in separate power domains; on detecting a wake-word or gesture, the M4 wakes the M7 for phrase recognition, perhaps “hey it’s dark in here, turn on the lights”. Gowri said the system can support between 100 and 150 phrases.

NXP became one of the pioneers in machine learning (ML) programmability across a range of platforms when they introduced their eIQ ML software development environment. This can start from any of the standard ML trained network representations and map to differing targets, optimizing the mapping as needed to best suit the resources of a given target. All this without having to understand all the technical details of TensorFlow Lite, Glow and other models. Another plus for MCU developers who want the capability without a lot of extra training.

There are a few more important features. The RT1170 hosts a 2D GPU, an addition to earlier processors, so it can generate complex graphics for appliance and industrial systems. It’s also automotive-qualified, so think cockpit displays and graphical steering wheel controls. This MCU also provides a hardware root of trust (HRoT) through their EdgeLock subsystem (HRoTs are the way all serious hardware security is going now). EdgeLock provides secure boot, a range of cryptography options and a secure real-time clock, useful in many contexts eg forcing a timeout after an unreasonable delay.

One more point that has raised some questions: the RT1170 doesn’t use embedded flash but rather 2MB of (embedded) SRAM. This decision was apparently customer driven; customers didn’t want the performance hit or the cost of flash. To ensure there is no security problem as a result of this change, data is stored encrypted in SRAM and is decrypted on-the-fly in zero-cycles as it’s read into the MCU.

The RT1170 is built on 28nm FDSOI technology, providing all the low-power management features you need (power islands, low leakage) but still at a much more price-conscious level than you’d find in application processors or GPUs at more advanced FinFET nodes.

NXP sees this platform having multiple applications: industrial and retail (factory automation controllers, unmanned vehicles, building access controls, retail display controllers), consumer and healthcare (smart home, professional audio applications and patient monitoring systems) and automotive applications (in-vehicle HMIs and 2-wheeler instrument clusters). Lots of opportunities – we can’t all build our own custom devices, in fact most of us can’t; we need more solutions like this. You can learn more about the RT1170 HERE.

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.