Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Processors/DSPs

Selecting DSP development tools

Posted: 02 May 2003 ?? ?Print Version ?Bookmark and Share

Keywords:dsp code development? dsp tool? on-chip debugging? target-hardware debugging? c/c++ compiler?

To achieve fast time-to-market with a new DSP design, the designer needs best-in-class development tools. These tools, which include an integrated software development environment, evaluation system and emulator for rapid on-chip debugging, can make the difference between success in the marketplace and a missed opportunity. All of the components of the development system must be tightly integrated and must offer programmers a rapid, seamless transition from development in a simulation environment through to target-hardware debugging.

An integrated software development environment provides efficient project management software, which allows designers to manage projects from start to finish within a single interface and to move easily among editing, building, and debugging. The user interface should be intuitive--easy to learn and use. Visualization of the output data should be simple and straightforward, with a graphical representation that lets the designer quickly determine the performance of an algorithm. The source code editor should be fully integrated and offer features such as syntax highlighting, object linking and embedding, drag-and-drop, and bookmarks. All project, tool and file configurations should be user-definable on a project-wide or individual file basis through easy-to-use property page dialog boxes. The development environment should support the latest programming methodologies, including component software engineering.

Programmers new to DSP code development will appreciate a development environment that includes an easy-to-use algebraic syntax assembly language. Programmers also welcome the ability to develop applications using an optimizing C/C++ compiler, which lets them put their microprocessor programming experience to use. The development environment should be able to intersperse in-line assembly language statements with C/C++ source code, to speed development using canned math and DSP routines while allowing optimization of critical sections of code. To take full advantage of the DSP hardware, the linker should graphically support multiprocessing, shared memory and code overlays.

The best DSP development tools provide a RTOS. The most simple and useful systems support automatic code-generation templates for the tasks that embedded developers will program. The OS should be closely integrated with the debug environment to allow for thread history tracing and debugging, and should be small, fast and highly scalable.

Debug: Critical component

Every programmer knows that even the simplest code rarely works the first time. Thus, a good debugger ranks as high as the use of good code development tools. Debuggers allow the user to view source files, profiles and trace instruction execution in C/C++, assembly or a mixture of both. Watch points can be set on processor registers, stacks, program memory and data memory to help determine the cause of stack overflows or underflows, out-of-range data being written or out-of-range memory locations being accessed.

The debugger should simulate standard inputs and outputs as well as interrupts and data streams, and must be able to support multiprocessing. The output should be presented in an easy-to-understand graphical format. The pipeline viewer visually displays the instruction flow through the pipeline sequencer, which enables the programmer to view stalls, bubbles, and other pipeline events and to gain a better understanding of why latencies or stalls occur. The cache viewer permits the designer to view the cache statistics pictorially, which in turn makes analysis of cache usage easier. The debugger should be capable of profiling the processor's performance.

Statistical profiling enables the programmer to non-intrusively poll the processor while it is running a program to attain a complete visualization of those routines that are consuming the majority of the processor's execution time. This feature lets the software developer gather information on where the application is spending the majority of its time without interrupting the real-time characteristics of the program. This process allows the developer to quickly and efficiently evaluate the program's efficiency and identify bottlenecks in the software. The code execution metrics provided by the profiler allow the programmer to find the "hot spots" in the code, focus on those areas in the program that affect performance the most and take corrective action.

The JTAG sampling is completely nonintrusive, so the process incurs no additional runtime overhead.

Choosing a new DSP can be a major investment, both in time and in dollars. Ideally, a low-cost desktop evaluation board should be available; they can provide a cost-effective method for initial evaluation of the DSP. They provide code-development software-including compiler, assembler and linker, as well as a debugging software to facilitate architectural evaluations through a PC-hosted tool set. Users can learn about the hardware and software as well as develop and prototype applications. Evaluation boards usually limit the size of the program memory. In addition, the software provided will usually work only with the evaluation system.

Emulators can connect the DSP to a desktop PC, laptop PC, or workstation via the serial port, USB port, or PCI bus. The simple plug-and-play architecture of the USB interface allows the emulator to be automatically detected and configured by the host operating system. It can be connected and disconnected from the host system without opening up the PC or powering it down. The PCI bus, on the other hand, provides higher emulation speeds for DSPs that have a JTAG port.

Background telemetry

A background telemetry channel is a mechanism for exchanging data between a host and a target application, with minimal intrusion on the real-time characteristics of the target system. The main channel for data exchange is a shared group of registers to which both the hosts and the target have read/write access while the application is running.

The background telemetry channel enables real-time data collection and status messaging. The channel further eliminates the overhead involved with halting the target application, getting the desired information and then restarting the target application.

The Crosscore family of DSP development tools from Analog Devices is an example of the kind of state-of-the-art integrated development system described above. The Crosscore family incorporates the VisualDSP++ software development environment, EZ-KIT Lite evaluation systems, and high-performance USB- and PCI-based emulators.

- Giuseppe Olivadoti

Technical Marketing Specialist

Analog Devices Inc.

Article Comments - Selecting DSP development tools
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top