Tools for embedding DSP As the applications of embedded DSP designs increase so do the number and scope of development tool packages

Digital signal processing @SP) chips are more capa- ble today than ever before, and so are finding their way into many more embedded systems. Nowadays, engi- neers working with DSP chips on designs for an

embedded system have a wide variety of de- velopment tools at their disposal-tools that provide assistance throughout the many stages of the design effort. Additional tools for developing systems with multiple DSPs, along with special operatjng systems tailored to the needs of DSP, are becoming available.

In general, DSP tools address three main design stages: algorithm development, soft- ware coding, and debugging. Tools for de- veloping algorithms help the engineer evalu- ate the effectiveness of different approaches to the problem at hand, and many of these DSP software packages include as an option the ability to generate ready-to-run code for several popular DSP chips.

Once the engineer is satisfied with the code, it can be integrated with the rest of the DSP system software, using a compiler- assembler-linker to produce a final loadable module to execute. Then the software can be debugged with some combination of hard- ware emulators, software simulators, and code profilers. ALBORITHM DEVELOPMENT. The heart of a DSP system’s functionality is its algorithms. They describe the mathematical procedures the DSP uses to operate on the input to generate the output. A number of software packages are available for algorithm design, which is independent of the specific DSP chip selected for the final implementation. For the most popular processors, some of these packages offer code generation op- tions. These are a trustworthy method of producing a ready-to-run code segment that is fairly well optimized.

For designing and evaluating an algorithm, simulation of the DSP portion of the embed- ded system is required. In addition, it should

Robert W. Robison Southwest Research Institute

IEEE SPECTRUM NOVEMBER 1992

provide a flexible graphics interface, access to standard DSP functions (fast Fourier transforms, digital filters, and so on), the ability to represent the rest of the system as a macro or other high-level description, and the ability to accept user-supplied data as input. A wise engineer will test the al- gorithm using not only ideal, simulated input signals but actual signals that are represen- tative of the expected system environment as well.

Two of the more popular programs that Mi these requirements are DADiSP/PRO- 32 from DSP Development Corp. and Block Diagram from Hyperception. They provide detailed signal-analysis capability and are fairly easy to use. Generic math programs such as Siglab, MathCAD, and Pro-Matlab [see table, pp. 74 and 761 often include several DSP functions and can be applied quite easily to evaluating spectral analysis, digital filtering, and other operations.

Tools for structured software design and analysis (common in the computer industry) are now beginning to appear for embedded DSPs; computer-aided software engineer- ing (CASE) tools such as Dynetics Inc.’s DataFlo and Multiprocessor Toolsmiths Inc.’s CaseworklRT are two examples.

Sometimes the system being used to de- velop the algorithm is fitted with an acceler- ator board containing the target DSP, in which event the algorithm coding can be readily checked for speed as well as accura- cy. In the case of fiued-point processing, it is especially important to verify the accura- cy and stability of the algorithm as finally im- plemented. Some packages, such as DFDP3/Plus by Atlanta Signal Processors Inc. and DSP Designer by Zola Technologies Inc., handle the analysis of fiiued-point quan- tization effects in software.

Responding to the needs of their cus- tomers, DSP chip manufacturers now usual- ly provide a reasonable code development environment for their own products. Today’s DSP chips, with their large address space and rich set of registers, make it much easi- er to create compilers with decent efficien- cies. So high-level-language (HLL) compil- ers for DSP-executable code are much more common now than they were in the early days of DSP.

A typical cycle in the development process begins with codmg everythug in a high-level language to get the system running. Next a code profder is used to determine where im- provement is needed in the performance of the code, which is then optimized.

0018-9235/92/$3.00@1992 IEEE

Segments that need optimizing can always be rewritten in assembly language, but it may be possible to dmnaticaly improve per- formance by restructuring the HLL code, taking into account the target DSP architec- ture and the way the compiler works. When code is written in a high-level language, it is easier to maintain-it is always simpler to follow the flow of a program written in C, with its WHILE loops and SWITCH statements, than to interpret the mnemonics and regis- ter usage of assembly.

Also, source-level debugging tools are available for symbolic debug of HLL DSP code. There are in-circuit DSP emulators and DSP-chip simulators, too. These tools compare favorably to those available for popular microprocessors and, in general, the debugging concepts used for the micropro- cessors carry over fairly well for DSP.

There is a complication with the embed- ded DSP environment, however, that is not typically seen with microprocessors. It arises from the fact that an embedded DSP system is often designed to deal in real time with a continuous stream of input data, so setting breakpoints and single-stepping through code must be done with care.

Some DSP emulators provide a mecha- nism for reading simulated input data from a file; using a repeatable data set can be very helpful in isolatmg a problem in the algorithm or system operation. A simulator can pro- vide results similar to those of an emulator, but it runs sigruficantly slower and, by its M- ture, precludes the use of real-time data. Then, too, it can be difficult to simulate the complex interconnections found in many embedded system designs. On the plus side, DSP simulators are available for most pro- cessors and can usually be run on a PC or workstation without any DSP hardware. ADVANCED OSP. Of late, DSP systems using multiple processors are becoming more prevalent. MultiProx, a part of The DSP Framework by Comdisco Systems Inc., is a graphical DSP development environment that addresses some of the needs that arise in the design of a multiprocessor system. Debugging a multiprocessor DSP system brings a whole new set of problems beyond those found with a single-processor system. Controlling and monitoring the state of each processor can be difficult. Here special in- circuit emulators from leading DSP chip manufacturers can be helpful in debugging the software.

For instance, the new XDS-510 in-circuit (Continued on p. M)

81

Embedded systems software for digital signal QrOCeSSinfl

PC 4DSP-2100 emulators enhanced with digital oscillo- scope functionality; signal generator; spectrum analyzer

$3995 ($1995, Beta version)

In-Circuit Sipnal 4nalyzer :8/92)

Monarch DSP Software

The Athena Group Inc. $99

$1195 (with code generator) $1500 (DOS); $2000 (Unix)

IBM PC/XT 286/386/486 and

DOS

DOS

FIR and IIR digital filters; code generators for DSP microprocessors; Siglab signal-processing toolkit simi- lar to Matlab Filter redesign; quantization after design; contour plotter

:4/92) 3FDP3/Plus 1 .O

compatibles PC AT and com- Atlanta Signal Processors

Inc. :9/92) patibles

AT&T Microelectronics 1600 ST 2.1; fixed- 3oint develop- nent environment lor the AT&T DSP 16xx family 19/92)

HP; IBM PCs and compatibles; Sun

DOS, Unix In-circuit emulation provided for up to 8 independent processors; window-based interface to the device simu- lator and other platforms; optional optimizing compil- er in C language for 16xx family

Chronology Corp. Timing Designer [3/90)

$1295 (FC); $2495- $4495 (work- station)

HP 9000/700; IBM PC and com- patibles; Sun Sparcstations

Microsoft Win- dows. Unix

Interactive timing analyzer for digital circuits; complex timing diagrams entered; diagrams analyzed to com- pute timing margins and highlight timing violations

Comdisco Systems Inc. Unix System-level design and implementation; multipro- cessing code and assembly code generation (the lat- ter for fixed-point DSP chips) from system-level block diaorams

SPW 3.0-The DSP Framework (9192)

DSP Navigator (4192)

$25 000

$20 000- $35 000

$7400

$1895- $5995

DECstations; HP 9000/400 and 700; Sun Sparcstations

DECstations;

IBM RS/6000; Sun 4, Soarc-

H P-Apollo; Block diagram and VHDL entry; advanced compiler technology; specialized DSP optimized library support

Unix Compass Design Auto- mation

stations Sun Sparcstations Real-time kernel; Unix-compatible libraries; multipro-

cessor development tools Native 32-bit, 386 mode; Microsoft Windows support; dynamic, multidimensional graphs

CSP Inc.

DSP Development Corp.

Integration Tool kit

DADiSP Work- sheet Version 3.01 19/92)

(1/91) Sun OS

VMS, DOS, Unix

DECstations;

NeXT; Silicon Graohics: Sun

HP-Apollo; IBM PC;

Dynetics Inc. DataFlo 18/92)

$4800 Sun Sparcstations Dataflow software methodology; graphical program- mina: oarallel-orocessina computing

Sun OS, Unix

Hyperception Inc. IBM PC/AT and compatibles

Windows 3.1 Real-time OSP blocks running on accelerator boards; many new functions for visually programming al- gorithms; user is able to define and add functions in C Support of over 20 DSP boards; real-time displays and high-speed data acquisition; calls OEDesign package for filter design and analysis

$1995

$495 (PC Windows, Mac); $20001 $2500 (Sun) $12 000

$695 (standard); $895 (advanced)

$4200- $12 000

Block Diagram v.1.2 (7/92)

DSPworks (1/92)

Momentum Data Systems Inc.

Windows, Mac OS, Unix

IBM PC; Macintosh ; Sun Sparcstations

Graphic design; simulation; code generation Unix, PSOS+ Sun Sparcstations Multiprocessor Toolsmiths Inc. National Instruments Corp.

Caseworks/RT (1990) Labwindows for DOS 2.2- standard and ad- vanced analysis (5/92) N!Power/ Developer 12/92)

IBM PC/AT, EISA, PS/2 or compatible

DOS 3.0 or higher

Real-time DSP support; enhanced graphical user in- terface and interactive graphics; new signal condi- tioning

Filter code generator for DSPs; fixed-bit filter design: real-time data acquisition and device control

VMS, Ultrix, HP-UX, Sun OS

DOS, 0512, Mac OS with MPW, Sun OS, VMS

DEC-, VAXstations; HP 9000 series 7xx; Sun Soarcstations

Signal Technology Inc.

Texas Instruments Inc. $1500 (PCs); $3500 (Sun)

IBM PC; Macin- tosh; Sun Sparc- stations 3, 4; VAX

Argument passing in registers for more efficient calls; TMS320C5X support; improved optimizations

Optimizing C compiler, assem- bler, and linker for TMS320C2X/C5X (6192) DSP Designer 1.2.2 (7/92)

Zola Technologies Inc. $895 Macintosh Sound playback; many new plot options and styles; new sound file formats

Mac OS with MPW

response I I R = inti -duration impulse response MPW = Macintosh Programmers Work- ISP = diaital sianal Drocessina El = extended industrv standard architecture FIR = finite-duration impu " I

shop VHDL = very high-speed I C hardware description language

82 IFFF SPEC'TRL'hI NO\EMBEK 1992

I Users’ panel (Continued from p. 42) last few years have built lots of glossy menus and other wonderful stuff, but it has not helped.

SPECTRUM: Is there anything important we have missed in our discussion?

VU: Yes. People expect the framework will take care of everything. And the expec- tation is so high that fiameworks usually fall short.

What I find helps in implementmg a h e - work is taking a small step at a time, rather

than expecting to replace everything with the framework.

MERCIER: In the education field, the problems may be slightly different. Our stu- dents, the users, don’t usually have a prob- lem. But the teachers [the management] are not ready now to change old habits and to go to the framework. Nevertheless, we at Ville d’Avray are starting teaching with the framework. And we use this as a window for other institutes in France.

SPECTRUM: Any comments about the cost of implementing a framework?

WILMORE: CFI estimates that a company spends twice as much on tool integration as

Circle No. 215

84

on buying an actual tool. I wouldn’t be a bit surprised if that’s accuiate. (I understand that CFI is planning to undertake a survey and get some hard numbers). We vastly un- derestimate integration costs.

SCHULZ: As I see it, the fiamework con- cept arose from a real need in industry. The increase in quantity of tools, vendors, and data to manage has exploded. Frameworks are here to stay. But we definitely and desperately need the standardization to make it meet its goals cost-effectively.

DIESING: We want to reach the point where it doesn’t matter if we use a Falcon framework or a DFII. The tools should be seamlessly integrated, not just encapsulat- ed in either framework.

VU: I wanted to add one last thought. I think the best framework is the invisible framework.

SPECTRUM: Thank you all for your partic- ipation. I hope the readers will benefit from your experience and insight. +

DSP (Continued from p. 81) emulator from Texas Instruments Inc., Houston, Texas (for its TMS320C40 DSP chip), is aimed at multiprocessing environ- ments. It allows global s W s t o p and single- step operations-a big help in debugging several interconnected C40s at once.

Implementation of embedded DSP is often very specialized. Real-time constraints on processing time often prevent the DSP re- source from providing the functions normally handled by operating systems. As a result, very few DSP-based operating systems are available.

Recent advances in DSP design and per- formance are generating an interest in providing operating system features such as multitasking, memory management, event scheduling, I/O and communications facili- ties, timer services, interrupt handling, and device-driver support within embedded DSP systems.

Spectron Microsystems’ SPOX is proba- bly the first operating system that was de- veloped specifically for use on DSP chips. In some cases this allows the DSP in the sys- tem to move from being dedicated to a few specific algorithmic tasks up to the role of system controller. This arrangement has the potential to eliminate a geneml-purpose pro- cessor from the embedded system design. Its fast task switching and event-driven scheduling can also be useful when a DSP chip is handling several unrelated data streams. ABOUT THE AUTHOR. Robert W. Robison is a senior research engineer in the special ap- plications section of the Electromagnetics Division at Southwest Research Institute in San Antonio, Texas. He is currently work- ing on real-time applications of multiple dig- ital signal processors in radiolocation systems. +

IEEE SPECTRUM NOVEMBER 19!