Embedded Systems Design Europe - February 2008 - (Page 30)

feature languages for embedded systems. Surveys in recent years have shown C and C++ (which lack native thread support) accounting for about 80% of embedded software, with no signiﬁcant downward trend. If your software base is hopelessly dependent on a real-time operating system (RTOS) that doesn’t support SMP, then SMP may not be for you. If you have the freedom to select a new operating system, your best bet at future portability is to select one that supports both POSIX and SMP. An SMP operating system will simply schedule concurrent threads to run on the extra cores in the system. This automatic load balancing is the primary advantage of SMP: adding cores will increase performance, often dramatically, without requiring software modiﬁcations. There’s one important exception to the automatic reusability of multithreaded applications on an SMP system. Most SMP operating systems will allow threads at varying priority levels to execute concurrently on the multiple cores. Most real-time embedded software is written for a strictly prioritybased preemptive scheduler. Trouble will ensue if the software is using priority as a means of synchronization. For example, software may manually raise a thread’s priority to preempt another thread. On an SMP system, this preemption won’t occur if the two threads are the highest priority runnable threads on a dual-core system. Embedded designers must analyze their systems to ensure that the SMP scheduling algorithms won’t pose a problem. CORE BINDING If your embedded system has tight real-time deadlines, than SMP may pose a problem: context switches can be delayed due to the overhead of interprocessor interrupts (IPIs) and cache inefﬁciency. For example, when an interrupt service routine executes on one core and signals a thread to run, the SMP scheduler may decide to run the thread on a different core, requiring an IPI. If the thread didn’t last run on that same core, there will be additional 30 overhead to rewarm the cache with the thread’s code and data. SMP operating systems tend to migrate threads, making it difﬁcult to predict whether this overhead will be incurred. The good news is that most SMP operating systems provide the ability to map interrupts and bind threads to speciﬁc cores to speciﬁc cores. Thus, real-time performance can be accommodated while other software is optimized across the multiple cores as deemed appropriate by the RTOS. The bottom line: real-time systems can take advantage of SMP, but designers should be prepared to spend time tweaking the system’s scheduling parameters. NUMA FOR EMBEDDED SMP’s single memory-bus architecture may be a poor ﬁt for memory- and I/ O-bound applications, relative to compute-intensive systems. The only way to be sure of the payoff is to run the software on an SMP. However, engineers sitting on the SMP fence may be excited about the prospect of NUMA (non-uniform memory access) systems. NUMA is similar to SMP except that the system contains more than one memory source, where the time to access each memory source varies. This architecture is depicted in Figure 2. NUMA represents a compromise in which code can still be shared and auto- matically load-balanced in the manner of an SMP. Yet you can optimize memory access times by running threads on the core for which the thread’s memory references are local. One way to do this is simply to take advantage of the aforementioned binding capabilities of the SMP operating system. You can locate thread-required memory to a core’s local memory bank and bind the thread to the same core. The NUMA-aware operating system may automate this optimization of memory and thread binding. Although NUMA isn’t available in mainstream embedded devices, there are rumors about future parts that could provide an intriguing alternative to SMP in the future. When moving to an SMP platform for the ﬁrst time, developers must be prepared to use tools required in the multicore development, debugging, and optimization process. Tightly coupled multicore processors often provide a single on-chip debug port (such as JTAG) that enables a host debugger, connected with a hardware probe device, to debug multiple cores simultaneously. With this capability, developers can perform low-level, synchronized run control of the multiple cores. Board bring-up and device-driver development are two common uses of this type of solution. The development tool lets develop- JANUARY – FEBRUARY 2008 | embedded systems design europe | www.embedded.com/europe 028-029-030-031_ESDE.indd 30 6/02/08 11:51:55 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - February 2008

Embedded Systems Design Europe - February 2008 Contents ARTEMIS and ENIAC Get Parlimentary Approval Product Teardown Videos Come On Screen Esterel and Abslnt Integrate Products Microsoft Opens Windows to Networked Embedded Applications Trango Embeds Virtualization Tool in Cavium's Multicore CPUs MindTree - ADI Develop Security DVR Platform NXP Extends Deal with ARM to Cover MCUs Automotive and Embedded to Dominate DATE 08 ZigBee Spec Gets Smart On Energy Updated Card Spec Provides for Power-On Boot The Basics of Embedded Multitasking On a PIC Cover Feature: The Art of FPGA Construction Is Symmetric Multiprocessing For You? Accelerating MATLAB Using MEX-Files ARM Provides the Microcontroller Solution Embedded World Advertising Contracts

Embedded Systems Design Europe - February 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.