Dual Core Processors in Embedded Systems
Over the last decade, processors used in embedded systems have become increasingly sophisticated. Not long ago, simple 8 or 16-bit microprocessors were common. Now ARM core 32-bit processors are almost standard.
Read full article on CIE Online.
Dual core processors arrive
The latest innovation has been dual core embedded processors. For instance, Nordic Semiconductor and ST Microelectronics have launched dual core Bluetooth Low Energy (BLE) devices recently. These pose new design challenges for the embedded developer.
Dual or multi core processors have been common in PC or tablet/smartphone type systems for many years. A modern laptop will have a 4 or 8 core processor inside, often with additional specialist graphics units on top. However, unless involved in deep system level programming, most application developers will not need to handle the details of task sharing between the cores. The sophisticated operating systems manage the complexity of core usage. This allows developers to program largely oblivious to the details of the underlying hardware platform. That is the whole point of the operating system, otherwise apps would have to be re-engineered for hundreds of devices.
Embedded dual core devices
Multi core processors were originally devised primarily to provide additional processing power. After a certain point, it becomes difficult to simply run a processor faster. It will simply overheat. In space constrained or portable devices, cooling is not easy to implement either. Running tasks in parallel on different processors therefore offers a solution. In a complex device like a PC or smartphone there are many largely independent tasks that can be split up.
Embedded multi core devices, multi objectives
In an embedded system, multi core devices can be designed with different objectives. Power saving may be critical coupled with real-time performance. Certain features may be only available on one of the cores. Cost may also be a critical factor and represent a higher percentage of system BOM.
For example, the latest generation BLE device from Nordic Semiconductor has two quite different cores; one high performance core with advanced features such as embedded security, and one optimized for efficiency with more limited features and memory. Other vendors’ devices follow a similar logic.
Dual core aims
The aim in this example is clear – the lightweight core (“Network”) is aimed at supporting the radio protocol, whereas the other (“Application”) is aimed at supporting sophisticated processing. The network core can maintain the radio connection and timing at lower power, whilst the application core can remain asleep until needed. So, reducing power consumption is a principal design goal rather than simply increasing processing speed.
The dual core approach also allows real-time reactivity without contention in two different channels. This could be critical in certain applications.
Other multicore designs may have different use cases in mind. Sony’s CXD5602 has an ARM system core M0+ processor and no less than six M4 cores for applications. The aim here is to run the core system continuously at low power whilst allowing flexible scale up of application processing as required.
Design issues to consider
From a design perspective there are therefore several issues to consider in determining the overall application architecture. The following covers the key topics.
What are the key objectives of the design? Is optimization of power consumption critical, for example? Tasks that run frequently should be placed on the lightweight network core even if they are not directly concerned with the radio network, to minimize use of the more power-hungry application core.
Are there any other inputs requiring a critical real time response? If so, then these may be better placed on the application core so response can be independent of the requirements of the radio connection.
Are there any features that are only available on one of the cores such as advanced security features, or certain peripheral interfaces? Tasks related to these must be located on the relevant core. In the case of security, if only one core has security features such as ARM TrustZone or secure key storage and security is a key feature, then the design must consider that tasks needing to run in a secure environment will have to be located on the core with those features. Arm TrustZone or similar environments are in some ways a kind of virtual dual core within a single hardware core.
Once it has been determined what is running where, then decide how the different tasks will communicate. Ideally one would minimize communications between cores, for the sake of simplicity and thus robustness, but other considerations such as the above may push in the other direction. There are typically various means of inter-core communication such as shared memory space or message transport services allowing inter-process communications across cores. However, the services offered are typically quite basic, and so much of the definition and design of how this works is in the hands of the user.
Advantages
A further potential advantage of the two core approach is the separation of the radio network protocol firmware from the true application firmware. In many cases the system designer and firmware programmer will use tried and tested firmware from the chip vendor in the low power core for the radio and network protocol and develop his application in the application core. This is an approach aimed at robustness and reliability, but not always the power efficient one. This underlines the point that there is not a “right” design, but that key design priorities should be defined at the start.
Conclusion
In conclusion, whilst multicore processors in systems with a sophisticated OS can be simply a feature hidden deep below the surface, for embedded systems, the developer must get to grips with the details of how – and why – the dual core system has been designed to get the most out of it. Careful design is also required to avoid the system becoming a tangled web that is hard to debug. Nevertheless, there will be more and more offerings of this type available, and using them effectively will be part of the future of embedded design.
By: Dr. Nick Wood, VP Sales & Marketing, Insight SiP