Selecting debug tools for embedded-processor-based systems

Selecting debug tools for embedded-processor-based systems

System requirements and complexity drive tool selection

BY GEORGE BAKEWELL
Novas Software
San Jose, CA
http://www.novas.com

The appeal of embedded systems is clear. A high degree of configurability, readily available commercial intellectual property (IP), and the use of well-understood and accepted protocols and bus architectures have made it possible to design highly complex systems in shorter periods of time, all the while allowing the application design team to focus on their particular value-added design content.

Such systems are inherently reusable, and can be retargeted to different applications and products with relative ease. Further, because embedded systems allow for the shift of more functionality into software, the risks associated with hardware design�physical issues and verification coverage�are reduced as the software can be updated and modified after chip development and fabrication.

Fig. 1. The complexity of embedded processor-based SOCs can challenge the most sophisticated debugging tool.

This same flexibility in design, implementation, and reuse can wreak havoc on a design team's ability to comprehend, verify, and debug overall system operation in a timely manner. The inclusion of unfamiliar or third party IP means that major portions of the design are not well understood from a detailed functional standpoint.

The straightforward, so-called “plug-and-play” interconnection of varied components at design time leads to tremendously complex interactions that defy understanding, particularly during the system integration phase. This complexity becomes more acute if designers are forced to track and inspect signal level activity when validating the system.

While standard protocols and bus architectures provide a common backbone for how components in the system should communicate, they also can be highly intricate in their own right. The mixing of, and bridging between, protocols and buses only adds to the complexity. Finally, the functional separation between hardware and software severely limits the usefulness of traditional debug approaches that only provide visibility and analysis capabilities in the hardware domain.

Traditional methods
As system design evolves and the use of embedded processors gains popularity, engineers naturally attempt to apply familiar, time- and production-tested techniques to the development and debug of these systems. This usually involves the use of independent, highly specialized tools, each of which focuses on a single aspect of the system – waveform and HDL source code viewers for hardware debug; processor-specific instruction-set simulators and/or standard C/C++ debuggers like gdb for software debug; and vendor-provided viewing and tracing tools for purchased IP.

This make-do approach, while viable for relatively simple systems, becomes a liability as system complexity increases, and can threaten both project schedule and overall design reliability. To identify a better approach, and the tools that support it, designers must consider the following three paramount goals for their development and debug environment:

1. Abstraction : The ability to track system operation at the bus-level or above, without the need for inefficient manual interpretation of the signal-level details.

2. Unification : The ability to view, analyze, and debug all aspects of the system in a consistent manner, without sacrificing debug capability in any one domain.

3. Customization and reuse : The ability to tune the environment to the targeted platform and to reuse it for similar target applications.

Abstraction, unification, and methodologies for customization and reuse each bring a specific set of requirements that can help guide tool selection and deployment.

Abstraction
Complex interactions between heterogeneous components that comprise typical embedded processor-based systems make it difficult to track, understand, and debug overall system operation. Bus and interface protocol standards make it easier to incorporate blocks and IP from different sources, but the protocols themselves are often quite involved�consisting of many signals and long sequences of control and data operations�and nearly impossible to recognize from the details at the signal-level.

A promising solution to this problem is the use of transaction-level modeling and debug. Transactions allow the engineer to effectively take a step back from the signal-level detail.

This in turn permits the designer to monitor, trace, and debug system operation at a higher level – based on major bus operations, the processing of data packets according to a standard protocol, or the interaction of hardware and software components via a mutually-understood command set (see Fig. 2 .)

Fig. 2 . Transaction visualizations provide a big-picture-view of signal-level details.

Although there is currently no standard way to define transactions, some languages (such as. SystemC) provide built-in constructs that allow users to describe and use transactions during the modeling process. In addition, some IP vendors provide the ability to output transaction information from their models�information that can be used during the debug process.

Still others offer transactors for commonly used bus protocols that either monitor and generate transaction data during simulation, or reconstruct transactions from the signal-level details. Clearly, a debug system that supports transaction-level visualization and analysis is a must.

Unification
Unified access to the diverse set of components that comprise a typical embedded processor-based SOC (reference Fig. 1 ) requires a debug system with broad support for languages and methodologies, as well as design and verification tools. Individual components�whether homegrown or acquired from a third-party�may be described using a mix of hardware description languages (HDLs).

Therefore, flexible support for Verilog, VHDL, and now SystemVerilog is a must. Automated verification environments are often employed to provide directed or random system-level stimuli and constraints.

This requires enhanced support for special-purpose verification tools and languages. Relatively new methodologies�such as the use of assertions to monitor and verify activity at component interfaces or on buses�are becoming commonplace, requiring access to, and visualization of, new types of design and verification data during the analysis and debug phase.

Customization and reuse
Embedded processor-based systems provide adaptable platforms that can be retargeted to different applications. Typically, the major aspects of the system remain unchanged and thus can be reused.

The platform, however, is customized for a particular application through changes in configuration, modified software, and the addition of new design content to support application-specific features. Efficient development and debug demand that the same tenets of customization and reuse be applied to the debug system.

From a debug standpoint, many of the customization requirements relate to the unification issues discussed earlier. Flexible support of languages, methodologies, and verification tools naturally provides the foundation for customization as the platform is modified for different applications.

Another important form of customization is the capture and use of specialized design views that allow important platform information to be preserved and shared with others in an automated, flexible way. This process allows the designer of the original embedded system or platform to capture his or her knowledge of the system and pass it along�or publish it�to the end-users of the platform.

Fig. 3. Applications allow the evolution of customized design views from an original schematic.

The flexibility of embedded systems continues to drive their expanded use in electronic applications of all types. Engineers would do well to keep in mind three primary goals�abstraction, unification, and support for customization and reuse�when searching for tools and solutions in this space.