Testing and Debugging DSP Systems, Part 5

High-Speed Data Collection and Visualization
The process of stopping an application with a breakpoint to exchange data "snapshots" with the host computer in a technique that's called "stop-mode debugging." This is an intrusive approach to debugging systems and can even be misleading, because the isolated snapshot of a halted high-speed application cannot show the system's real-world operation.

DSP vendors have solved this problem using technology that allows real-time data exchange with the processor. This technology goes by different names (TI calls it real-time data exchange [RTDX]). This capability gives designers continuous, real-time visibility into their applications by providing asynchronous exchange of data between the target and the host, without stopping the target application. This is important for debugging many real-time applications.

The technology is a data link that provides a "data pipe" between the DSP application and the host. The bidirectional capability provides the capability to access data from the application for real-time visibility, or to simulate data input to the DSP, perhaps before real-time sensor hardware is available. This can give the developer a more realistic view of the way their systems operate.

This technology requires support from the standard emulation technology discussed earlier. The data rate performance is dependent on the emulator used and the host computer. The data rate requirement is also application dependent (Figure 10).

(Click to enlarge)
Figure 10 Data bandwidth required for debug and validation is dependent on the application.

Applications such as CD audio and low-end video conferencing may require up to 10K bytes per second. Higher end applications such as streaming video and ADSL will require much more, perhaps over 2 Mbytes per second.

This data transfer capability requires some level of support and will vary depending on the DSP vendor. When planning to use this technology, verify the following:

• A special high-speed peripheral on the target DSP device is present, if needed.
• A supporting emulator is available.
• The application is linked with the appropriate library to enable the capability. The TI technology, for example, is implemented with a small monitor (2 to 4 Kbytes of memory) that is included as a part of the RTOS. There is a minimal amount of CPU overhead required to implement the capability.

Scalability is Essential Since these on-chip capabilities affect the chip's recurring cost, the scalability of debug solutions is of primary importance. "Pay only for what you need" is the guiding principle for on-chip tools deployment. In this new paradigm, the system architect specifies the on-chip debug facilities along with the remainder of functionality, balancing chip cost constraints and the debug needs of the product development team. Figure 11 shows examples of DSP applications and the types of DSP debug capability that are used to address the integration challenges for these various application spaces. (Click to enlarge) Figure 11 The DSP debug technology needed depends on the application space (courtesy of Texas Instruments)

This data transfer technology runs asynchronously, in real-time, between the target and the host. Once the target data is in the host, it can be viewed in various ways, using custom or commercial viewers such as MathWorks or Labview.

These viewers can be used to check the correctness of embedded DSP algorithms. This can be done by comparing the results of the embedded algorithm with those obtained from a known correct algorithm from a standard data analysis or signal processing algorithm. Direct comparisons of the results can be done visually or a script can be used to check the accuracy of the data at a finer level of accuracy.