Tools for Test and Debug : Embedded designers face a myriad of multiprocessor challenges

Because the size of applications is growing dramatically, software designers are challenged to deal with multiple operations simultaneously, which often go well beyond just flow control inputs and synchronization functions, said Gord on Stufferfield, product manager, who, with Paul Kimmelman, technology architect, ARM, Ltd. (Cambridge, England) author an article on how multicore SoCs are impact the debugging process.

"Many designs are moving beyond RTOS kernels and are relying on platform operating systems with built in memory management and higher end facilities," he said. "For instance, instead of pure flow control models such as code/decode functions, the DSPs in these environments may become involved in doing more conversions or transforming processes where they are inserting or injecting information into the data stream and/or demuxing multiple streams of data."

According to contributor Chuck Brokish, senior member, technical staff, Texas Instruments (Austin, Texas), that is all the more reason that, in addition to keeping an eye out for new test and debug tools and methodologies, it is also important to take full advantage of existing tools, from hardware breakpoints to real-time trace. "This encompasses understa nding what capabilities are embedded into the device, and knowing how to use them such that you can get maximum entitlement from those resources," he said.

One important area of focus for the developer is how to deal with designs that now often have several processors incorporated into the board, or even more problematic, into the system on chip. Typical embedded applications where this is beginning to occur are in board level components in wireless base stations where there is a need to handle a variety voice and formats each coming in from several separate data streams. In the wireless devices, multiple processors are used, one to enable processing of voice and another for Internet related data processing.

Such combinations, while not necessarily handling external events that are either real time or deterministic, still require careful attention to timing relationships internal to the device where proper timing is key, making tight integration between hardware and software development cr itical.

According to Stufferfield, the use of multiple processing cores within a single silicon implementation has become a vital enabling factor for many of today's leading edge designs that must effectively balance the convergence of higher functionality, smaller form factors and lower power consumption. He points out that "not only can multiple cores on the same die boost the raw processing capacity of a chip, but the silicon-level integration of heterogeneous cores along with on-chip memory, mixed signal and other support functions also can greatly reduce the higher power levels typically needed for driving multiple off-chip interfaces."

That is why, it is important to build both comprehensive and selective visibility into the tools at the system and chip level, said Pete Hardee, director of product marketing, CoWare, Inc. (Santa Clara, Calif.) Such tools, he believes, represent the next logical step for multicore designs, especially in SoCs.

"Previously users would have to debug each processor with separate tools and then somehow try to blend all of the results together," he said. "Any attempts at multi-processor synchronization would have to be handled via the overlay of separate software controls and/or laborious step-by-step manual control processes, which often would lose sight of the critical real-time inter-processor relationships that can impact overall system operation."

A second issue facing developers in many designs: Not only are multiple processors required, but also multiple heterogeneous combinations of CPUs, mixing RISC, VLIW, and DSP. In addition, the list includes traditional register and accumulator based microcontrollers, each with different pipeline structures, methods of handling and processing of data, and each with different ways of using cache and on-chip SRAM and DRAM.

"When heterogeneous processors are used," said ARM's Stufferfield, "developers also must be able to go beyond limited proprietary debug tools that only have knowledge of one vendor's cores. The debug tools must be able to logically "see" the entire chip design and be aware of RTOS and/or applications software, while selectively monitoring and controlling specific inter-processor functions." In addition, he said, the debug and monitoring tools need to be able to immediately stop the entire processing sequence upon specified failure modes while comprehensively capturing and analyzing the exact state of all processors.

According to contributor, Gerard Vink, Program Manager, Tasking Platform Technology, Altium, Inc. (San Diego, Calif.) processing cores for SoC implementation cover a wide performance range, and each has its own particular programming characteristics, some of which conflict with other types of processors in a design. "On one end of the spectrum, existing 8- and 16-bit processors are optimized for implementation in FPGA and are available as synthesizable HDL models" he said. On the other end of the spectrum, new complex architectures serve the high-en d market. Typically, these cores have a VLIW architecture, may support single instruction multiple data operations (SIMD), support advanced cache, memory, and peripheral systems to feed the core with data, and are user-configurable to tune the architecture towards a given application, he said.

The third issue that developers face: such complex arrangements are often implemented in the form of an FPGA based programmable SoC, or in ASIC form as a high density SoC with complex mixtures of CPUs, memories, I/O combinations and application specific peripheral functions. There, the problem is integrating hardware and software development, when actual physical hardware in the form of an actual piece of silicon that can be programmed, probed and analyzed has not actually been built yet.

According to Hardee, part of the problem is definitional. "System is a problematic word," he said. "It implies many different things to different people. Typically, it is applied to the level of design immediately a bove the current scope — the level that the current design plugs into. Others insist the system is the full end product, and all mechanical and aesthetic aspects of product design must be considered too." Most usefully, in the context of SoC, he said, the system level is at least the level at which the hardware and software aspects of the design must be considered as one.

In the context of the multiprocessor requirements of some of the most compact iAppliance designs and embedded applications in networking and telecomm — what is needed — and what many embedded tool vendors and EDA houses are trying to provide, is some way to bring all these parameters together within a single unified environment, said CoWare's Hardee. In this space, the newest generation of multi-processor debug tools will enable designers to interactively control every aspect of the system, while capturing detailed debug information for analysis against a uniformly defined model. Designers could then, he said, indep endently analyze critical parts of the design or can synchronously capture failure state conditions using selectively defined break-point triggers.

Nor do the design issues facing developers end there, as end users eye hungrily the potential of integrating more and more memory of various types --- SRAM, DRAM, flash, and specialty architectures such as content addressable memory --- onto a single SoC. "It is no longer just the processor that is embedded inside of the chip, said David Lin, vice president of applications engineering, Denali Software, Inc. (Palo Alto Calif.). "Most embedded systems today have also large amounts of memory, more peripherals, and cache."

Meanwhile the amount of program content, program content, data flow, and system features have increased exponentially — increasing the system complexity and making the need for visibility into the application that much more important. "Not only does this mean moving to more advanced methods of analyzing the underlying ha rdware logic, but looking at the makeup of the embedded memory: it's size, its architecture, down to the specifics of the type, location and timing dependencies of the data mapped into the memory device or array," said Lin.