Embedded Processing

As part of a continuing effort to determine what is different between embedded software and application level software, this week's design feature ("Shedding light on embedded debugging") explores how embedded developers are using debugging tools. One difference is that many embedded systems must resolve whether unexpected inputs are due to the variable nature of real world interfaces or artifacts of closed-loop control algorithms where outputs affect inputs. In fact, several inputs may be influenced by multiple outputs in complex relationships. In many cases, characterizing the behavior of the whole system cannot be performed until system level integration is underway.

A primary capability of a debugger is to provide the developer with visibility into how the system is working. It is this core capability that makes debuggers expedient tools to characterize the behavior of a complex sense-and-control system during system level integration. Is it still debugging, or is it a design aid, if developers are using debugging tools to characterize a poorly understood set of sense and control relationships?

While debugging tools may provide visibility into the operation of the processor core, correlating the software state with the rest of the system is pretty much an exercise left to the developer to patch together. While system-level simulators that can support virtual as well as hardware-in-the-loop simulations can help with this exercise, they are often an order of magnitude more expensive than traditional software development tools. As embedded systems incorporate ever more intelligence in their behavior, the need for the developer to understand the system level interactions becomes that much more important, and the lack of many of today's software development tools to provide that level of correlated understanding of the system is an area of ripe opportunity for future tool differentiation.

Multicore or multiple-processor designs further increase the amount of complexity and difficulty in correlating the different components affecting a system's behavior. With these types of systems, the developer needs to be able to understand how the data and memory architectures affect the flow, timing, and latency of data and messages between processors. At this point, developers are using ad hoc configurations of tools to capture and aid the visualization of the behavior of the multiple processor system.

EEMBC's MultiBench is an industry-level first attempt to enable developers to characterize the behavior and performance of a set of software across different multiple processor configurations. Markus Levy, EEMBC president, and Shay Gal-On, EEMBC director of software engineering, have authored an article, "Challenges and design decisions for measuring multicore performance," that discusses a few of the challenges and design decisions facing developers that want to measure system performance for multiple processor designs.