Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Tools

Testing and Debugging DSP Systems: Part 1


Vanishing visibility
In 1988, the embedded system industry went through a change from conventional In Circuit Emulation[2] to scan based emulation. This was motivated by design cycle time pressures and newly available space on the embedded device for on-chip emulation. Scan-based, or JTAG, emulation is now widely preferred over the older and more expensive "in-circuit emulation," or "ICE" technology.

Debug Challenges for DSP
The have been a number of industry forces that have been changing the DSP system development landscape:

System level integration; As application complexity has increased and system on a chip complexity has led to smaller footprints, the visibility into the system components has diminished (Figure 2). Embedded system buses lead to an instrumentation challenge. Wider system buses also lead to system bandwidth issues. Program control in these environments is difficult.


Figure 2 System level integration leads to diminishing visibility (courtesy of Texas Instruments)

In order to restore visibility, DSP vendors have addressed the issue on several fronts:

On-chip instrumentation – As systems become more integrated, on-chip visibility into the device operation is becoming blocked (Figure 3). Bus snooping logic analyzer functions have been implemented in on-chip logic. Examples of this include triggering logic to find the events of interest, trace collection and export logic to allowing the viewing of events, and maximizing export bandwidth per available pin on the DSP core. Debug control is through an emulator which extracts the information of interest.


Figure 3 Vanishing visibility requires advanced debug logic on-chip (courtesy of Texas Instruments)

Off chip collection foundation – Once the data is exported from the DSP core, the data must be stored, processed, filtered, and formatted in such a way as to be useful to those test engineers to interpret the data meaningfully.

Data visualization capability – DSP integration capabilities include the ability to easily view the data in different configurations. The entire chain is shown in Figure 4. The logic analyzer functions are now on-chip, the control and instrumentation collection is primarily through the emulation controller, and the data is displayed on the host in a visualization container. The key challenge, then, is to properly configure the system to collect the right data at the right time to catch the right problem.


(Click to enlarge)

Figure 4 DSP tools are used to visualize debug data extracted from the DSP (courtesy of Texas Instruments)

Application space diversity – DSP applications are becoming more diverse and this presents challenges to DSP test and integration engineers. This diverse application space spectrum requires different cost models for debug support:

  • DSP basestation applications require high bandwidth, high frequency debug capabilities.
  • Voice over IP applications require MIPS density and many homogeneous processors per board.
  • Cell phone and other wireless applications require heterogeneous multiprocessors and very high system level integration.
  • Automotive DSP applications require low cost debug solutions where DSP chip pins are at a premium.

User development environment; the development environment for DSP developers is changing and DSP debug technologies are changing to accommodate these new environments. DSP engineers are transitioning debug platforms from desktop PC systems to laptops that are portable to the field for debug in the customer's environment. Portable remote applications require portable DSP debug environments.

Continued clock rate increases; as DSP core clock speeds increase more data is required to perform debugging. In fact, the amount of data required to perform debug and tuning is directly proportional to the DSP core clock speed. More DSP pins and more data per pin are required to maintain the required visibility into the behavior of the device.

The different levels of DSP debug capability provide a range of benefits in the integration process. The out of box experience allows the user to become productive as quickly as possible. Basic debug allows the DSP developer to get the application up and running. Advanced debug capabilities, such as the ability to capture high bandwidth data in real-time, allow the developer to get the application running in real time. Basic tuning capabilities provide the ability to perform code size and performance tuning.

The combined on and off chip emulation capabilities provide a variety of benefits. Execution control in real-time provides standard capabilities such as step, run, breakpoints (program counter) and data watchpoints. Advanced event triggering (AET) capabilities provide visibility and control of the programmer's model. Real-time data collection provides real-time visibility into algorithm behavior by tuning a stable program. Trace capabilities provide real-time visibility into the program flow through the process of debugging an unstable program.

Used with the permission of the publisher, Newnes/Elsevier, this series of six articles is based on chapter nine of "DSP Software Development Techniques for Embedded and Real-Time Systems," by Robert Oshana.

Part two explains the workings of the JTAG (IEEE 1149.1) boundary-scan technology. It defines the test pins and the test process associated with a JTAG port.

Footnote
2. In-circuit emulation technology replaces the target processor with a device that acts like, or "emulates," the original device, but has additional pins to make internal structures on the device, like buses, visible. ICE modules allow full access to the programmer model of the processor. These devices also allow for hardware breakpoints, execution control, trace, and other debug functions.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.