Tools for Test and Debug : Specialized net backplanes needed for DSP debug in distributed environments

Specialized net backplanes needed for DSP debug in distributed environments
By Rodger H. Hosking, Cofounder, Vice President, Pentek, Inc., Upper Saddle River, N.J., EE Times
June 3, 2002 (10:20 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020531S0031

Communication between the host and target in a development system is one of the most important issues and difficult tasks for a system designer. Making it even more of a challenge is the varied combinations of host platforms, DSP boards and development tools that are out in the market, not to mention the variety of embedded applications, such as wireless base stations, which require multiple DSPs operating in a loosely linked distributed environment.

To help solve these issues a complete host-to-target link solution must support all possible combinations of platforms, tools and boards while accommodating the special needs of embedded DSP systems. This can be done by creating an appropriate host-target communication protocol that host tools and DSP applications can access through a well-defined, portable application programming interface (API). This greatly simplifies application development, provides increased tool interoperablility, and allow s tool vendors and end-users to port effortlessly to new host platforms, communication links, or DSP boards.

A host-target communication link has two basic requirements. One is to allow the host control of the DSP for debugging and the other is to make host resources available to the DSP. A common technique for connecting the embedded DSP to the workstation is to use an emulator. Although the emulator approach may provide a reasonable solution for a single-processor system, it's not satisfactory for multiprocessor systems, as the emulator lines from all the DSPs must be connected in a daisy chain fashion leading to extremely cumbersome cabling and slow performance.

A solution for host-target communication is to use a specialized powerful networking protocol that supports a network of distributed VMEbus systems and allows the developer to run development tools on the host, while maintaining remote access to the VMEbus system.

Such a networking protocol is actually a large collection o f drivers, libraries, and utilities that supports software development and run-time connectivity between workstations and any number of DSPs. Every DSP development system consists of a workstation, a DSP, and some type of electrical connection between them. To support dozens of possible combinations among the three elements, networking protocol drivers are modular and based on the popular TCP/IP communication protocols.

To properly steer messages, the networking protocol tags each element with a unique "handle" that specifies the workstation, the embedded CPU board, the DSP board name, and the processor number on the board. Each networking protocol signal is a TCP/IP packet that consists of the header with the networking protocol handle followed by a variable-length data payload. The signal allows an unlimited number of DSPs to be accessed by either a distributed work group or a single user.

This specialized networking protocol includes both client and server functions that generate and resp ond to TCP/IP networking protocol signals. Since networking protocol signals are uniform across all hosts, any combination of workstations can be connected to the network and participate successfully in networking protocol messaging to any DSP target, regardless of the operating system.

Each DSP runs a small kernel that includes an interrupt service routine for responding to networking protocol requests. In this way, the DSP isn't burdened with networking protocol traffic unless a message arrives. A small networking protocol driver passes client requests across the backplane to the cage server. Although the host-client functions are implemented in very different ways on the workstation and the DSP, they look exactly the same from a programming point of view. This symmetry allows the same set of functions to be used across all networking protocol platforms.

To see how such a DSP optimized networking networking protocol simplifies both debug and run-time applications, let's look at an intellige nt digital receiver data acquisition system. Deployed for detecting and archiving specific types of radio traffic in sparsely populated areas, several systems are connected over the Internet to a central monitoring facility.

The VMEbus system consists of a RF front end, multichannel digital receiver module, quad TMS320C6701 DSP processor and an embedded Pentium host processor equipped with a hard disk and modem in a small chassis. The DSP application issues coarse tuning commands to the RF front end and then sweeps the digital receiver section within each band, searching for radio signal energy much like a scanner.

When a signal of interest is detected, the narrowband digital receivers lock on to the signals, sending the down-converted receiver output to the DSPs. Here, the baseband signals are classified by modulation type by analyzing the frequency and time characteristics. Further DSP processing completes the demodulation and then determines if the information is of interest.

If a signal needs to be stored, it is sent to the embedded Pentium host for archiving on the hard disk along with the time and date, ready for periodic uploading to the central facility.

For development, networking protocol TCP/IP drivers provide an Ethernet link from the embedded host to an external Pentium workstation running Code Composer Studio (CCS) for debugging. The workstation launches the networking protocol Debug Manager application for Windows, which allows each DSP to be accessed by the development tools.

The embedded Pentium computer board in the VME card cage uses the Cage Server application to link specialized network protocol messages between CCS running on the workstation and each DSP within the card cage. As each CCS command is generated during debugging, the client function on the workstation generates a networking protocol command that is sent out through th e Ethernet link to the embedded Pentium CPU board.

The Cage Server function on the embedded Pentium translates the message into reads and writes across the VMEbus backplane to the target DSP device. The commands typically require a value or status from the DSP that's passed across the VMEbus to the embedded Pentium. The return value is then sent to the workstation as a networking protocol message over Ethernet to complete the debugging transaction.

Many programmers find it extremely helpful to embed temporary printf() commands at strategic points in DSP programs to track program execution and status. This is relatively straight forward in a distributed networking protocol optimized for such operations.

To receive the messages, the workstation must first be set up to run the SNIO Server function by invoking the command:

snio recvr_cage board_1 DSP_3

The embedded Pentium host computer name in the VME card cage is recvr_cage, the processor board name is board_1, and the target processor is DSP_3.

In the DSP program, set up the networking protocol Standard I/O library functions (snstdio) by including the header file at the beginning of the DSP program:

#include

The standard I/O connection to the workstation (in this example, named ws1) is then opened up by issuing:

snstdio_init(ws1);

The programmer can now send a message to the workstation from any point in the program by simply inserting a printf() instruction:

printf("Now Entering Demod Function %s ",demod_num);

When the DSP program is executed, the message conveniently appears in a text window on the workstation. To more easily evaluate the content and format of the files that the DSP application will eventually send to the embedded host disk drive, send these files to the workstation file system during the development phase.

Since we've already set up the standard I/O Ethernet connection to the workstation for the printf() functions, we can ta ke advantage of the SNIO file functions.

First we define a file pointer, and then we open or create a file on the workstation for writing, as follows:

FILE *fp;

fp= fopen("data_file","w+");

Data from a memory buffer of a specified size on the DSP board can be easily written to the workstation file and then closed by executing:

fwrite(fp,buffer,size);

fclose(fp);

Once the file is closed, it can be opened by any application on the workstation for analysis or inspection.

At this point, the DSP program has successfully created and written files to the workstation file system. Now we can begin to wean the workstation away from the system and replace it with the embedded host. The embedded host must accept and store data files from the DSP subsystem during the day in preparation for a nightly file transfer to the central facility computer.

The Cage Server function, previously loaded on the embedded host at start-up to support the workstatio n Ethernet connection, now also supports local file system access by the DSP. In the C program for the DSP, all we need to do is change the server name in the DSP snstdio initialization function from ws1 (the workstation) to the name of the embedded host, recvr_cag:

snstdio_init(recvr_cage);

By changing just this one argument in the DSP program, we've redirected all networking protocol messaging and file I/O to the embedded Pentium. The change allows the DSP board to create and write output files directly to the embedded host file system for archiving.