Multicore processors are adding a new dimension of performance to the traditional realm of embedded software design. To take advantage of multicore processors, developers must learn the ins and outs of concurrency and parallel code programming.
Because of the top-down sequential programming approach, control models have inherent limitations when mapping to parallel hardware. In contrast, with a dataflow model, nodes on a block diagram are connected to one another to express the logical execution flow, and they can be used to easily express parallelism. When a block diagram node receives all required inputs, it produces output data and passes that data to the next node in the dataflow path. The movement of data through the nodes determines the execution order of the functions on the block diagram.
The inherently parallel nature of dataflow languages is well suited to programming concurrent systems.
Choosing the right method to express parallelism is critical in a multicore design; however, that alone does not ensure a successful project. Examining the complete software stack helps to evaluate key problem areas in developing multicore-ready software.
The real-time software stack consists of development tools, libraries, device drivers and a real-time operating system. Most companies built previous-generation applications on a real-time software stack intended for single-processor designs. Companies migrating this software to a multicore processor experience varying levels of scalability.
One critical software stack element is the debugging tools that developers use for insight into how code is executing on multicore hardware. The visualization aspect plays a key role in debugging multicore systems in particular, because it helps the developer look at what is happening on multiple cores at the same time.
At the bottom layer of the software stack, with each layer above dependent on it, is the RTOS. Multicore systems implement an architecture scheme based on symmetric multiprocessing (SMP) or asymmetric multiprocessing (ASMP). The RTOS supports one or the other.
In SMP systems, processors reside on the same board or chip and share global resources such as memories, buses and peripherals. General-purpose operating systems, such as the Windows, Mac and Linux OSs, have supported SMP for years. However, the deterministic behavior of an RTOS must be preserved to meet hard real-time timing constraints while distributing tasks across the different processors--so SMP is an added challenge for RTOS vendors to implement. Traditionally, very few commercial RTOSs have supported this functionality although there has been a rush to add support in the past year. QNX Neutrino and the LabVIEW Real-Time OS are two examples that support SMP. The advantage of SMP is that the OS handles autoload balancing tasks across the available processor cores.
Asymmetric multiprocessing systems are those in which processors do not share resources with one another. An OS is required to govern each processor (as opposed to SMP, where only one OS is required), so more development overhead is incurred. Processors must be programmed separately, and a communication scheme to pass data between processors must also be implemented.
For multicore development, choosing an OS with SMP support is the recommended implementation because of its ability to take advantage of autoload balancing.
Jeff Meisel (firstname.lastname@example.org) is a software product manager for LabVIEW Real-Time at National Instruments.