Choosing the right multiprocessor development tools - Embedded.com

Choosing the right multiprocessor development tools

While multicore system-on-chip (SoC) devices may be relatively new in the desktop market, the embedded world has been using them for the past decade. There are several advantages to using a multicore device in an embedded application. One reason is power efficiency.

Take the example of mobile handsets, where battery life is an important requirement. Many of these systems are based on dual-core heterogeneous chips containing a microprocessor and a digital signal processor. These heterogeneous multicore devices offer better performance per watt as compared to a DSP or MCU alone. System designers will partition tasks to the DSP and the MCU, letting each processor perform the tasks for which it has been optimally designed.

Programmable multicore system-on-chip (SoC) processors are common in many applications, from wireless handsets to desktop computers and automotive controllers. While there are clear benefits to multicore SoCs in terms of cost, performance and power consumption, the burden is on the embedded software developer to manage the additional complexity of programming and debugging multiple processors. Depending on the system architecture, issues include taking advantage of parallelism, managing interprocessor communication, using embedded operating systems, and coordinating the behavior of multiple processors during a debug session.

Another class of multicore programmable devices contain “intelligent” programmable on-chip peripherals, such as DMA controllers or IO processors, in addition to a microprocessor. The on-chip peripherals have their own instruction set and are C programmable. Finally, there are homogeneous multicore devices, with multiple identical cores on a single chip. A telecom basestation processing thousands of data channels may use hundreds of multicore DSPs. Putting multiple cores on a single chip helps reduce board space and increase density.

From a software development perspective, a multicore system is one in which there is more than one core for which software needs to be written, whether these cores are found all on one chip, as in the examples above, or spread across multiple chips or boards. What are the things to be aware of when choosing development tools for a multiprocessor system?

For multicore programming and debugging, the tools requirements will depend on the level of interaction between the multiple cores, and the hardware support that the chips provide for multicore programming and debugging. We’ve identified five levels of multicore tools requirements which can serve as a guide to determining tools needs for a given project. The requirements are cumulative as the levels increase. If you are at level 1, only the requirements at that level apply. If you are at level 4, you should consider all the requirements from levels 1 through 4.

Level 1: applications programming on a multiprocessor OS
At level 1, the embedded software engineer is writing applications on a pre-existing multitasking/multithreading embedded OS, and the OS is handling interprocessor communication and scheduling. Tools here should provide OS awareness, and support the OS’s multithreading model. Since we assume that the OS handles the underlying hardware, and the OS is stable, the tools do not need to provide access to multicore hardware features. Commercially available multicore operating systems are available from several companies including Enea, QNX and Wind River Systems.

Level 2: Board bring-up, multiple cores, independent of one another
A level two system has multiple programmable processors in separate chips, with no interprocessor communication or dependency – each processor functions independently from the others. The processor chips may be on separate hardware debug scan chains, or may share a single scan chain. If a developer does not need to program more than one processor at a time, there are no particular multicore debug requirements for a level 2 system. If the same developer will be writing code for more than one of the cores, then it may be useful to have a tool set which can program and debug multiple cores inside a single IDE session. How does the tool set manage debugging more than one processor at a time? Does the project manager have the ability to load code for multiple CPUs?

Level 3: Board bring-up, multiple cores with loose coupling
Level three adds loose coupling between multiple chips, where there is interprocessor communication, typically by message passing or shared memory. The architecture may be homogeneous or heterogeneous, and devices may share a debug scan chain. Since there is a level of synchronization, the devices may have a specific initialization sequence that a debugger needs to follow. Considerations here include: does the IDE handle more than one core in a single session, or do you need to run multiple IDEs, one for each core? How does the IDE manage screen real estate when working with multiple cores? Does the IDE have a multicore project manager which can load files for each core, and specify any particular initialization sequence? How do you customize the JTAG scan chain to reflect the devices to debug?

Another useful debugger technique will be the ability to specify multicore debug control. If you are debugging interprocessor interaction and detect an error on one core, it can be useful to stop multiple cores simultaneously. Does the debugger provide the user a way to start, stop and step more than one processor simultaneously? If a core halts due to an illegal instruction, can the debugger stop other cores as well?

Level 4: multicore device with on-chip multicore debug logic
Here, one or more of the devices have on-chip multicore debug features. Many multicore devices have debug registers which can trigger behaviors like stopping core B when core A halts due to a breakpoint or illegal instruction. This makes the two cores halt almost simultaneously, with a much smaller skid as compared to a debugger on the host detecting that core A halts, and then sending a halt command to core B. Do the debug tools provide a simple way to access hardware multicore debug features?

Level 5: device with multicore trace support
Level five is for multicore devices with hardware support for multicore trace. The key thing to look for here: do the debug tools support multicore trace?

Developers embarking on multicore software development need to deal with the additional complexity that multicore brings in order to harness the advantages. Having robust debugging tools which support the particularities of multicore can go a long way to help.

One size does not fit all. A developer’s particular requirements depend on what stages of software development they program to, and what level of multicore support their system implies.

Joseph Dubin is a product manager inthe Developer Technology Organization at Freescale Semiconductor, Inc.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.