Heterogeneous Multi-core Processing

What is Heterogeneous Multi-core Processing (HMP)?

In general, a processor with multiple cores of different types enables Heterogeneous Multi-core Processing, or HMP for short.

Cores that have been optimized for different things are combined to create the best of different worlds. More specifically in the i.MX world, it allows a feature rich OS, like Linux, to run on Cortex-A cores and a Real-Time OS (RTOS) to run on the Cortex-M4/M7 core.

Benefits with HMP

  • Keep control over real-time properties, while running management/administrative tasks
  • Improved system reliability and security
  • Reuse existing microcontroller (MCU) software, see migration benefits in section below
  • Possibility to lower power consumption
  • Reduced BOM cost

Challenges with HMP

  • Shared resources require isolation and protection mechanisms
  • Debugging of the application is more complex in a multi-core environment
  • More complex application development compared to a single-core system

Benefits of having a Cortex-M4 core

(video presents the benefits on the i.MX 6SoloX, but the benefits are general for all HMP systems).

Migrating from Microcontroller

Do you have a microcontroller (MCU) based design and need a lot more performance for the next generation?

A very interesting option is to migrate that MCU based design to an i.MX processor with HMP capabilities. Place the existing application on the Cortex-M core.

Let the application grow on the Linux side. Place all management functions there – all the new features customers want you to add to your product – for example advanced graphical user interfaces, databases, file system handling and complex communication protocols.

Benefits with migrating an MCU based design to an HMP architecture

  • Saved BOM cost because the Cortex-M core is basically free
  • Get access to the best of both worlds; a feature rich OS, like Linux, and a real-time operating system (RTOS)
  • Keep full control over real-time requirements and get separation between critical and non-critical tasks
  • A future-proof platform is created!

Migrating to i.MX HMP from an MCU design

COM boards with HMP support

Embedded Artists offers several COM boards with HMP support. The table below lists the COM boards that are currently available (and under development) and a few of their features.
Board Cores
iMX6 SoloX COM Cortex-A9 / Cortex-M4
iMX7 Dual COM 2x Cortex-A7 / Cortex-M4
iMX7 Dual uCOM 2x Cortex-A7 / Cortex-M4
iMX7ULP uCOM Cortex-A7 / Cortex-M4
iMX8M COM 4/2x Cortex-A53 / Cortex-M4
iMX8M Mini uCOM 4/2/1x Cortex-A53 / Cortex-M4
iMX8M Nano uCOM 4/2/1x Cortex-A53 / Cortex-M7

Get started / Hands-on experience

Get practical experience working with HMP systems by using ARM’s DS-MDK, our iMX7 Dual Developer’s Kit and our iMX7 Dual HMP Labs Instructions (only the index to the document is published here).

The document contains a lot of information of how you get started developing applications with ARM’s DS-MDK.

  • Download and debug applications on the Cortex-M4 core
  • Download and debug applications on the Cortex-A7 core (under Linux)
  • Communication between cores – RPMsg
  • Explore resource sharing between cores
Other documents and links of reference:
Creating and debugging a Linux image with DS-MDK on the iMX7 Dual Developer's Kit
Creating and debugging a Linux image with DS-MDK on the iMX6 SoloX Developer's Kit
iMX7 Working with Cortex-M4
iMX6 SoloX Working with Cortex-M4

Demonstration of real HMP implementation – Inverted Pendulum

Communication between cores

In a multi-core environment you need a way of communicating between the cores. This could for example be sensor data that is collected by one of the cores and need to be forwarded to the core responsible of processing the data or presenting it in a user-interface.

One communication API that is implemented both in Linux
and in FreeRTOS is the OpenAMP RPMsg. The RPMsg implementation contains a ring data structure to manage buffers in shared memory. The Messaging Unit (MU) peripheral which is included with the i.MX processors is then used to notify a kernel that data is available in the shared memory. NXP has published a document that describes their contributions to the RPMsg layer: RPMSG RTOS Layer User’s Guide.

In Linux a RPMsg TTY driver has been implemented that lets a user-space application communicate with a remote core just as communicating via a serial port (open, read, write primitives). The RPMsg TTY device is available at /dev/ttyRPMSG.

Webinar: Managing inter-processor communication with Arm

HMP dts document

Resource usage between cores

When developing an application that will run on a multi-core processor it is important to decide how resources should be used. You must decide which resources that must be shared between the cores and which resources can be given exclusive access to a specific core. The general recommendation is to avoid shared resources whenever possible.

Resource Domain Controller
The Resource Domain Controller (RDC) provides a way to support isolation and sharing of memory and peripherals in a multi-core environment. Resources can be assigned to a specific core. The other cores in the processor will then not have access to the resource.

Hardware Semaphore (SEM4)
Another feature of the i.MX processors that can be used to synchronize access to resources are Hardware Sempahores (SEM4). If you are used to semaphores in software this is a similar mechanism, but implemented in hardware.

Device Tree Files (DTS)
Linux is using device tree files to describe the hardware. If a specific hardware component, peripheral, is not listed in the device tree file it is normally not initialized and made available by the Linux kernel.

If your application is using Linux on the powerful core (for example Cortex-A7/A9/A53) and an RTOS on the less powerful core (Cortex-M4/M7) DTS files can be used to “assign” peripherals to the Cortex-M core. The way this is done is to disable the peripheral in the dts file resulting in Linux not having access to it.