August 14, 2008 -- Embedded designers put microprocessors in everyday products like cars, phones, cameras, TVs, music players, and printers, as well as the communications infrastructure, which the general public doesn’t get to see. They know how important it is for their products to work—and work preferably better than their competitors’ products.

But the systems-on-a-chip (SOC) behind them continue to grow in complexity, making that simple goal harder to achieve, particularly with the rise of multicore systems. Getting these systems to work well means giving engineers throughout the design and test cycle visibility into what their systems are doing. At the modeling stage, visibility is provided in the modeling tool. Once you move to a physical implementation, though, the designer must include specific mechanisms to provide visibility.

Choosing which mechanism to provide should be a direct response to the needs of the different engineers doing hardware bring-up, low-level system software, real-time operating-system (RTOS) and OS porting, application development, system integration, performance optimization, production test, in-field maintenance, returns failure analysis, and other functions, which need to be satisfied. Although their respective tools may handle and present the data in different ways, they all rely on getting debug and trace data from the target SOC.

By William Orme. (Orme is a product manager with ARM.)