search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Embedded Technology Catch here


Dual core processors in embedded systems


By Dr Nick Wood, VP of sales and marketing, Insight SiP O


ver 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.


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.


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 optimised for efficiency with more limited features and memory. Other vendors’ devices follow a similar logic.


Dual core aims


Embedded dual core devices In embedded systems, it is a different story. Normally software is written for a defined hardware platform. It is up to the designer to decide which part of the device does what tasks. At a more fundamental level, the rationale for an embedded dual-core device may be different to that in a PC. Multi core processors were originally devised primarily to provide additional


www.cieonline.co.uk


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.


insightsip.com Components in Electronics July/August 2021 33


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58