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 core.
Benefits with HMP
- Keep control over real-time performance, 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
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!
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.
|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|
|Upcoming iMX8M-Nano uCOM||4/2/1x Cortex-A53 / Cortex-M7|
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
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.
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 or Cortex-A9) and an RTOS on the less powerful core (Cortex-M4) DTS files can be used to “assign” peripherals to the Cortex-M4 core. The way this is done is to disable the peripheral in the dts file resulting in Linux not having access to it.