Numeric Intensive Real-Time Software Development System

1. Field of Invention

This invention relates to a software development system for digital signal processors (DSP), in particular fixed point DSP's and other programmable devices for the ease of programming, debug, and porting of code to other brands and types of digital signal processors.

2. Description of Related Art

There are several existing software development tools available for particular brands or types of DSP's. The trend in the architecture of these tools is to migrate to high level language for ease of programming, such as C language. C language compilers can deal well with numeric behaviors but are inefficient in real-time code generation and the usage of memory. Another approach is to program DSP's in low level language, such as assembly language. The low level language can handle real-time behaviors and achieve the best optimized code. However, the low level language has difficulty handling numeric behaviors and is difficult to debug causing long development time. In addition there is a growing need to produce code that can be ported to DSP's of different manufacturers and other general purpose programmable devices, such as RISC or CISC microprocessors. This entails considerable rewrite to adjust to a different architecture. Coupled with this is the need to translate digital formats during code development and debug. This is particularly acute for a fixed point processor that is dealing with floating point operations and usually requires tedious time consuming conversions during debug using a hand calculator or the equivalent to check whether the correct data is being generated. In addition code developed in DSP assembly language is time consuming and using a higher level language, like C programming language, for a fixed point DSP can create problems because of inconsistent code optimization and truncation error. Referring to In U.S. Pat. No. 5,375,228 (Leary et al.) is described an emulation system to debug software for a DSP. This is an application dependent configuration which integrates a digital signal analyzer into a specific DSP emulation system and does not appear easily portable to other configurations..

Commercial vendors for DSP products, such as IBM which sells its DSP under the brand name "Mwave", provide development tool kits for programming and debug of application software to run their DSP. The tool kit allows programming in C language or in assembly language, and real time debugging with data being displayed on the computer system monitor. As with other vendors, this tool kit does not provide the capability to easily port code for use with other types and makes of DSP's.

Existing development tools are available for a single type DSP and do not provide a universal capability that can easily produce code for various DSP types and brands. Thus the porting of code to other brand of DSP entails a considerable rewrite and additional debug. Working with fixed point DSP's requires a considerable amount of effort in the debug phase to manually convert to other numerical formats that are used in the program by using hand calculators or equivalent. After a program is written and found to be useful, it is often a time consuming and difficult task to adapt the code for another DSP. Determining which floating point, decimal and thirty-two bit formats were intended for an integer DSP program is difficult especially when it is not being done by the original programmer. For situations where various types and brands of DSP are being used, there is a need for a universal programming environment which allows for easy debug and porting of code.

There are currently two common approaches in developing DSP software. One is to use high level language tools, such as C-language. Numerous C compilers can deal well with numeric behaviors but are not as efficient in real-time code-generation as well as memory usage. The second approach is to use low level language tools, such as assembly language. The low level language can handle real-time behaviors and achieved the most optimized implementation, but has difficulty handling numeric behaviors that in turn cause a long development time. Recently, there has been considerable effort focused on adding more real-time control tools to high level language compilers. This makes the high level language compiler very complicated, and yields little improvement to new algorithms; therefore, a lot of embedded applications are still developed by using assembly languages. Numeric software bugs are normally manifested through inaccuracy in numeric analysis or large scale collective analysis, such as LMS, waveform, and spectrum analysis, and the debugging involves large amounts of mathematical analysis, including the conversion from one data format to another.

The invention describes an universal software development system for developing and debugging real-time digital signal processing software on programmable devices, such as digital signal processors (DSP) or microprocessors. Digital signal processors are fast becoming a generic math engine and are proliferating into many areas, far beyond the traditional filtering applications. Implementing complicated math algorithms in low cost fixed-point DSP's has become one of the biggest challenges in DSP software development. A software development system as described herein provides a new concept in DSP software development. Through leveraging the nature of numeric intensive in all digital signal processing applications, the development software system can significantly improve the efficiency of numeric intensive real-time software development across different hardware platforms.

The numeric intensive real-time software development system of this invention is based on low level assembly language with extensive native mathematical representation formats and high level syntax. The combination of low level tools and high level syntax is called DSP-C. It possesses both the advantages of handling numeric mathematics through an enhanced numeric handler and optimization for code speed and compactness in low level assembly language. Moreover, the software development system is generic for all DSP's and microprocessors since the code is written to a driver interface. When the target processor is changed, only the low level development tools and drivers need to change. Thus porting code from one DSP to another is a relatively easy task. All math utilities are focused on low level native DSP environment and on-line performance. Debugging DSP software is made easy because all data in the physical hardware has been converted into native mathematics representation and displayed on a computer screen. Code developed in the numeric intensive real-time software development system is coupled to a hardware DSP through a set of drivers and a physical interface. The drivers are unique to each different type of DSP and provide a means by which the same code development methodology can be used for different DSP's. Thus a single programming effort can be used for different brands and types of DSP's. When there are no DSP's available to debug the software against, a DSP software simulator can be automatically selected. It is connected through a set of drivers and uses the assembly language library functions to do the simulation, following the behavior of the hardware architecture and producing in the simulation the same as in real mode.

In fixed point DSP programming, programmers are continuously faced with the problem of using limited hardware capability to represent unlimited mathematical operations. To help this problem it is convenient to be able to display to a programmer DSP numerical data in various formats other than the fixed point integer format of the DSP. An important concept in the invention is to separate the logical data presentation from physical hardware data through a format mapping function. This in not a complicated function to implement since the conversions of formats are straight forward, and is provided by an enhanced numeric handler. By identifying all necessary formats and providing them for the programmer's, selection, it gives the programmer the capability to view data in all formats and to search for a meaningful mathematical presentation and format. In debugging a program the programmer can view data logically, as intended in the program, instead of physically as stored in the physical structure of the DSP.

The programmer interfaces the software development system through a user interface providing a display of data in a graphics or text format. The user interface connects to the assembly language enhanced with high level syntax and the enhanced numeric handler to produce code and make modifications. DSP control commands for the target DSP are connected from the user interface to the set of drivers. These commands provide control information for the DSP's connected to the drivers such as start, stop, and single step. Status of the target DSP is connected back to the user interface from the drivers communicating a hardware description file which provides a behavioral description of the target DSP connected to the set of drivers. Register and memory data of an operating DSP is fed back to the user interface from a target DSP through a dissembler and an enhanced numeric handler and the high level syntax function. This provides real-time operating status of the target DSP and facilitates making real-time program changes. Thus a programmer can program a DSP, initiate execution of the program on a target DSP, watch the resulting execution of the program and make changes to the program to correct problems as they occur.

This invention will be described with reference to the accompanying drawings, wherein:

FIG. 1 is a diagram of the software programming environment of the invention.

FIG. 2 is a diagram of the numeric intensive real-time software development system of the invention.

FIG. 3 is a diagram showing the flow of program development and debug of the invention.

FIG. 4 is a diagram demonstrating a method of use of the invention.

In FIG. 1 is shown the programming tools needed to produce code for a DSP using the numeric intensive real-time software development system of the invention. The approach presented herein takes a different direction than that taken by most DSP program development tools. In this invention low level assembly language provides the foundation for programming which is augmented with high level language syntax 10. The assembly language efficiently handles real-time behaviors and achieves the most optimized implementation of the resulting code. The high level language syntax provides an efficient way to handle numeric behaviors. This combination of low level assembly language enhanced with high level syntax 10 is called DSP-C. The DSP-C 10 along with an enhanced numeric handler 11 is connected to an assembler and linker 12. The enhanced numeric handler 11 converts a number into the logical format used by the program from the physical presentation in the target hardware, and allows conversion between various logical numeric formats such as floating point, decimal and hexadecimal. Also connected to the assembler and Linker 12 is a description library 13. The description library 13 provides key information about the internal architecture of the DSP, or microprocessor, being programmed.

Referring to FIG. 2, a diagram of the numeric intensive real-time software system is shown. Embedded within this diagram are the elements 10, 11, 12 and 13 of FIG. 1. The user interface 20 provides a graphics or text presentation of information to the programmer and allows the programmer to communicate with the rest of the system. The DSP-C 10 is connected to the user interface 20 and allows the programmer to program a DSP using the high level syntax of DSP-C coupled with the low level assembly language. A dissembler 21 connects DSP program instructions back from a target DSP 25 through the drivers 24 to the DSP-C 10 for further connection to the user interface 20 and for viewing by the programmer. Each DSP type 25 26, or other programmable device 28 intended for use in numeric compute applications, has a different driver 24 unique to the particular DSP 25 26, or other programmable devices like a RISC processor 28. The dissembler 21 connects register and memory numeric data to the enhanced numeric handler 11 to be converted from the fixed point integer format of the DSP 25 to the logical format of the program for display on the user interface. Upon command by the programmer, the enhanced numeric handler 11 converts the DSP 25 numeric data from one format to another. The description library 13 provides key information about the architecture of the DSP 25 26 and other programmable devices 28 to the dissembler 21 to provide proper structure of the dissembled data.

Continuing to refer to FIG. 2, the drivers 24 provide an interface to which the DSP-C 10 programs are written. This driver interface provides a means to accommodate various target hardware and target processors 25 26 27. Thus, the user of the development system described herein is provided an universal debugging environment, a numeric analysis facility 11, language syntax and code generation 10, and testing facility for all DSP's 25 26 and microprocessors 28. Since all necessary differences have been removed, the user can focus on the architectural related differences to make the overall code porting task much easier. To achieve this, the drivers 24 contain various sets to be used for different target processor platforms. DSP control commands 22 from the user interface 20 are connected to a particular DSP 25 through the drivers 24. The control commands 22 provide such commands as run, stop, single step and which DSP 25 to activate. The target DSP status 23 communicates a hardware description file which provides a behavioral description of the target DSP 25 to the user interface 20, the DSP-C 10 and the assembler and linker 12. If there are no physical DSP's 25 available for programming and debug, a DSP simulator 27 can be attached to the drivers 24 to assist in the debug of the software. The DSP simulator 27 is a software image that allows the exercising of the code as it would be done in a real DSP 25.

In FIG. 3 is shown the diagram of the design flow in programming and debug of a DSP program. Algorithm design and simulation 40 is created in a C language producing C code 41. The C code 41 is fed into the DSP-C 42 to structure the implementation of the algorithm. The result of programming in DSP-C 42 is DSP-C code 43. This DSP-C code is fed through an assembly language translator and compiler 44 to produce assembly code 45. The assembly code 45 is imputed to an assembler and linker to create the final binary form of the of the program to be connected to a physical DSP. A debugger 47 dissembles the output of the assembler and linker 46 for debug purposes and separates the results back into DSP-C level 49 and into native numerical format 48. This translation by the debugger 47 of the final form of the program back into more readable form 48 49 provides a considerable assist to debug of the DSP program.

Referring to FIG. 4 a method for programming DSP's and other processors is shown. A user 60 designs an algorithm 61 in "C" language by which a DSP, or target processor, 67 will be controlled by a program. The user 60 develops instructions 62 in DSP-C language to implement the algorithm 63. The DSP-C language is assembly language augmented with high level "C" language syntax. The output from implementing the algorithm 63 in DSP-C is compiled and translated 65 into assembly code and connected to the assembler and linker 66. Through a numeric handling facility 64 the user 60 chooses the data formats to be used with the assembly code. The output of numeric handling facility 64 is also connected to the assembler and linker 66. The assembler and linker produces machine binary code 66 and is connected to a target processor 67. Continuing to refer to FIG. 4, in order to debug the machine binary code, a dissembler 68 translates the output of the assembler and linker 67 back into instructions 70, and the machine numeric digits back into native numeric formats to be displayed through the numeric handling facility 69. The user 60 views the dissembled results 69 70 by means of a visual display and changes any instructions 62 to the implemented algorithm 63. Through numeric handling 64 different numeric formats are viewed by the user 60 to determine the best data format to improve accuracy and resolution. The output of the numeric handling 64 is connected to the assembler and linker 66 to be combined with any changes in the instructions 62 that have been complied and translated 65. The assembler and linker 66 again produces machine level binary code that can be connected to a target processor 67 or fed back to the dissembler 68 for further review.

While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the spirit and scope of the invention.