prototyping environment for digital signal processing systems

SIGNAL PROCESSING

Prototyping environment for digital signal processing systems

by Dr. S. F. A. Ip, F. A. Westall, R. J. Knowles, P. R. Benyon and P. W. Easton

The growing worldwide interest in exploiting programmable digital signal processors (DSPs) in telecommunication applications and systems has established the need for a prototyping environment. This environment comprises various computer-aided software and hardware tools to meet the requirements of the development process, including specification, algorithm simulation, analysis, implementation and verification. This article discusses the issues concerning a prototyping process and the need for support tools for developing DSP applications. It is followed by an overview of existing tools and techniques. An integrated signal processing application development environment (SPADE) is then described.

A digital signal processor (DSP) is a programmable device which is specialised for applications that require extensive arithmetic computations. The architectures

of DSPs have traditionally been designed to handle conventional signal-processing operations very efficiently, for example, a typical 'multiply and accumulate' operation in digital signal filtering can be carried out by a DSP as quickly as 25 ns.' Over the past ten years, programmable DSPs have evolved to become more versatile and capable of carrying out more parallel operations. A recent example is the floating-point DSP from Motorola, the DSP96002, which can achieve up to 50 MFlops (million floating-point operations per second), and carry out up to 10 operations at the same time.' The range of applications for DSPs continues to grow rapidly, with many practical real-time systems emerging, such as voiceband data modems, echo cancellers, speech recognisers and music synthesisers. Non-real-time DSP applications such as graphics, medical imaging and simulation are also becoming well-established. With the increasing performance and expressive power of

assembler languages, DSP applications will soon become ubiquitous.

The programming of a DSP usually requires knowledge of the specific DSP assembler language. If there is a link to a high-level computer language, it is usually via the compilation of the high-level language program into the target assembler. However, DSP programs generated in this way are usually inefficient, due to the deficiencies in existing commercial DSP cross- compiler technology. Until recently, the design and development of a system using DSP has often followed an ad hoc path of algorithm development closely coupled to target DSP implementation.3j If a theoretical study of the algorithm was undertaken, it was usually based on a mathematical model simulated using a high-level computer language. Frequently, under cost constraints, programmers could not afford the inefficiencies of the compiler to obtain DSP programs directly from the corresponding high-level language programs. Therefore, for the sake of exploiting the fullest possible processing power and memory efficiency, DSP programs were usuallv handcrafted with little emphasis on the

COMPUTING & CONTROL ENGINEERZNG JOURNAL APRIL 1995 83

SIGNAL PROCESSING

programming structure. Even for an experienced DSP programmer, the design

and debugging process tended to take months to complete and, under pressure of timescales, the DSP programs were frequently not documented with sufficient detail. Moreover, since DSP programming skill tended to be very specialised and took time to acquire, the hand-crafted programs were not only 'device-specific' but were often 'programmer-specific'. As a result, DSP programs were hard to maintain and even harder to modify. Hence, DSP code developed using this route tended to have a high design risk and also a low tolerance to key staff changes. The whole design and development process, from initial concept to a tested implementation, could take many months, if not years.

With increasing demand to exploit the processing power of more complex DSPs, it therefore became essential to devise a design route which would allow algorithmic ideas to be implemented efficiently. Hence, a prototyping process is required for designers to specify, simulate, analyse, implement and verify an algorithm on a target DSP. The programmability of DSP allows the design to be prototyped and studied until a much later stage before it is frozen. The prototype may implement only part of the functionality of the final system, leaving details such as hardware control or real-time optimisation to be finalised later. A prototyping environment is currently being set up in BT Laboratories and is called the signal processing application development environment (SPADE). SPADE is a con- glomerate of commercial and home-grown computer-aided software and hardware tools which aims to bridge the gap and shorten the timescale between initial conception and DSP implementation.

The next section describes a typical DSP application development process. It outlines the areas where a prototyping environment is required and problems that are likely to be encountered. In order to establish how some of the existing technology can meet the requirements, an overview of the existing tools and techniques for the design and development of applications using DSPs is then provided.

which include the Signal Processing Worksystem (SPW is the trade-mark of a COMDISCO Systems Inc. p rod~c t )~ .~ Signal Processing Operating executive (SFOX is the trade-mark of a SPECTRON MicroSystems Inc. product)81o and KINDRA."11,12 It is stressed that the views expressed in this article are those of the authors and do not reflect an endorsement by, or a policy of, BT towards any mentioned commercial products.

DSP application development process Fig. 1 shows a schematic diagram of a 'typical' DSP

application development process. It consists of four main stages:

specification 0 simulation 0 analysis

implementation.

In the specification stage, a signal-processing idea or algorithm may be specified or expressed using an appropriate description technique, such as a set of mathematical equations, data-flow diagrams or natural languages. However it is achieved, a good specification technique should foster the development of a well-

algorithm r specification

software specification

simulation

r - l analysis

implementation 0 The tools incorporated in Fig. 1 Iterative prototyping process for de! SPADE are next described, DSP applications

84 COMPUTING & CONTROL

structured, consistent, clear and easy-to-understand statement of requirements. This should minimise the chance of 'rework' at a later stage of the development process. In order to establish the validity and the target performance of the algorithm, a prototyping phase is usually followed. The algorithm is initially studied by simulation using high-level languages such as Fortran, C or Pascal, based on the specification details. This requires another level of specification for the simulation program using, for instance, flow charts. A good specification technique, at this stage, should encourage the programmer to produce well-structured programs.

Computer simulation can study various parts of the design jointly or individually, and provide the designer with valuable information that is not easily attainable from a hardware implementation. It allows algorithms to be developed and optimised without loss of focus through con-

EEIUNG JOURNAL APRIL 1995

SIGNAL PROCESSING

siderations of any hardware constraints such as finite- length arithmetic, real-time requirements and even the availability of the actual hardware. It also facilitates the analysis and debugging of the algorithm in a more easily understandable form with the aid of computer-aided graphical tools. As a result of the simulation, the specification may be modified accordingly (Fig. 1). Hence, computer simulation addresses the initial prototyping phase and models the algorithms based on some mathematical assumptions to provide some early evidence to establish the feasibility of a design.

In the implementation stage, the algorithm needs to be tested on a DSP. Using the same specification for the high- level simulation, key parts of the simulated system may be compiled and downloaded onto a target DSP development s y ~ t e m , ~ , ~ ~ In this prototyping phase, the results can be analysed and compared with those of the simulation, and the system can be further debugged. This provides the designer with the means to verify and optimise the performance of the algorithm under the constraints of the hardware such as the real-time execution speed and the finite-length arithmetic precision.

The specification, simulation, analysis and implementation stages are likely to form an iterative cycle (Fig. l), until a certain performance goal is achieved. During the prototyping cycle, the specification may be progressively modified while the results are being verified both by simulation and implementation. At the output of the prototyping phase, the refined specification is then subjected to further, more detailed, levels of specification, design and code optimisation. The system is then released after system integration, conformance testing and field trials have been satisfactorily completed.

Prototyping provides an opportunity to demonstrate the objective and subjective quality, technical feasibility and capability of the system to the customer at an early stage. It therefore provides an opportunity to modify the design and eliminate design error as early in the development cycle as possible. This is vital as subsequent detailed design and development specification will be progressively less flexible and more costly to alter. Finally, it convinces the customer of the design’s correctness and usefulness, and helps to establish confidence in the subsequent system.

Problem areas in the prototyping process and the need for tools

Programmable DSP has rendered much of the prototyping concept (or process) possible by allowing the system to be prototyped and tested to a much later stage before the design is frozen. However, earlier tools to support prototyping for DSPs were limited to simple debuggers and software simulators. The previous lack of tool support for developing DSP applications caused problems in a few areas of the prototyping process:

The validity of simulation results relies on the setting up of a realistic simulation model of the actual hardware system. This would be difficult to achieve as simulation models were mostly based on mathematical assumptions which might not be sufficiently accurate and realistic. Therefore, it affected the validity of the simulation results and did not aid the hardware implementation process. There was no clear route between the HLL simulation stage and the DSP implementation stage that did not involve some rewriting of the program. The programming might be carried out b>- two different persons as the skills required were different. Although cross-compilers were available from some DSP manufacturers to solve this problem, the cross-compiler might not produce a run-time efficient DSP assembler program. In order to ensure that certain real-time requirements are met, DSP programs were usually handcrafted and optimised in assembler. Under the pressure of timescales, programs might not be specified, and written, in a well-structured fashion and documented with sufficient detail. Hence, the programs developed were hard to maintain and even harder to modify. The emergence of new DSPs required a considerable overhead in familiarisation. Despite the possible superior performance of a new DSP, the non-trivial cost to migrate programmers’ skill and the existing algorithms to the new DSP has often made the move unattractive. Hence. the application subsequently might not exploit fully the available DSP technology. With the current market competition to produce better systems, such a constraint is no longer acceptable.

The cost of maintaining a complex DSP application (in terms of bugfixing, migration to a new DSP and product enhancement) can be more than twice the initial development cost. The cost of undetected softxvare or hardware design errors escalates throughout the development cycle. An error in the specification stage can cost up to 100 times more, if it permeates through to the final stage of development, than would be the case if it had been found earlier. Due to the lack of support tools for prototyping, errors found in the final system can cause an unnecessarily long testing phase. These factors ultimately underline the need for employing tools to support the design of DSP applications.

Overview of existing tools and techniques

The research and development of computer-aided tools and techniques for designing applications using DSPs is an active and rapidly-growing area. Whilst it is not possible to give a full survey of all the existing tools and techniques, it is useful to have a brief overview relevant to the establishment of a prototyping environment.

Computer programming has been used for many years

COMPUTING & CONTROL ENGINEERING JOURNAL APRIL 1995 85

SIGNAL PROCESSING

to simulate signal-processing applications and problem solving. High-level languages @ILL), such as Fortran, Pascal and C, have been popular among signal- processing designers. In 1979, the IEEE collected a set of programs and published them as a signal-processing library,l3-I5 which was subsequently published by IMSL Inc.I4,l6 Both libraries consist of optimised programs which can be used as subroutines in a designer's program to perform many commonly known signal-processing operations. The libraries started the important process of establishing a structured programming technique for signal processingI4 since HLL programs are generally easier to write, structure and maintain than assembler programs. In order to take full advantage of the HLL programming and the existing libraries, compilers are required to translate HLL programs into DSP assemblers. There are commercial C compilers available such as those for Motorola's DSP56001,17 Texas Instrument's TMS320C3018 and AT&T's DSP32.19 In addition, there is the non-commercial BT Pascal compiler for the DSP32.20

Over the last decade, a large body of computer-aided techniques have been developed to assist the process of specifying, simulating, analysing, implementing and verifying DSP algorithms and applications. Available tools range from digital filter design and signal analysis packages, such as the FDAS,2] HypersignaP and ILSu to packages that encompass a large part of the DSP application development process. In recent years, tools based on a graphical block diagram approach have emerged. Using these tools, algorithms can be specified, described and simulated without the need for programming languages. Examples of commercial tools are BOSS,% DSPlayZ and the Signal Processing Worksystem (SPW)!,7 Other examples of non- commercial block-diagram tools are a system from the Lincoln Gabriel,n,28 GOSPL,B QuickSig30 32 and CADiSP?

These tools often incorporate a library of building blocks for the frequently used signal-processing functions, and these basic building blocks can be used to hierarchically build up more complex applications. If a block required by the user is not available in a tool's library, the user can define a new block to add onto the library using an HLL programming language. These tools support different HLL languages. BOSS allows users to construct its own blocks using Fortran,z4 while SPW uses C or Fortran? Gabriel allows the user to define a block in Lisp for algorithm simulation.28 Some tools allow the target DSP assembler program to be generated directly from a block-diagram specification. For instance, SPW has code generation systems that can produce generic C programs and the assembler for the TMS32OC30 DSP. Gabriel is capable of generating assembler code for the Motorola 5600Ln

Although all the tools mentioned above are based on the block-diagram approach, they do have some differences. For instance, the BOSS library is equipped

with blocks for simulating communication links and SPW is aimed more towards designing DSP applications and algorithms. Both DSPlay and SPW can be used for simulation, signal analysis and DSP code generation. However, BOSS and SPW are primarily equipped with blocks to simulate systems with a single sampling rate. The simulation of systems with multiple sampling rates using these tools can be achieved through the use of a control signal to disable and enable blocks appropriately. Both the system from Lincoln Labs and Gabriel target parallel processor applications, and are capable of simulating systems with multiple sampling rates. GOSPL is again constrained to simulate systems with a single sample rate and does not attempt to parallelise the DSP assembler code.n

The sequential nature of HLLs such as Fortran, C and Pascal has long been recognised as being inefficient in expressing and exploiting the inherent parallelism that exists in many DSPS.'~,~ To overcome compiler inefficiency, some global or local post-optimisation can be performed to maximise the amount of parallel processing in the DSP.34-37 HLL, such as C, can also be extended to accommodate DSP In CADiSP, a language called ImDiSP is introduced to make accessible the special functionality of a DSP to a high-level programmer.33 SPOX offers a set of optimised DSP assembler library functions which can be used directly in a C program. The library functions are specifically written for the development of DSP applications. The program can then be compiled and run on a DSP direct1y.8lo There is also a strong argument put forward in the QuickSig case study32 that some object-oriented programming (OOP) languages3 are suitable for solving signal-processing problems. QuickSig is written in Common Lisp and New Flavors, which is close to the Common Lisp Object System (CLOS) standard.40 Gabriel exploits the flexibility of an OOP language called Franz Lisp for the simulation and code generation processes.n There are also functional languages, such as Silage41'4z and that were designed specifically to describe DSP applications. It may be possible for such functional languages to be combined with the block diagram approach to form an efficient environment for DSP simulation and implementation in the future.n

Signal processlng. appllcatlon development environment CSPADEI The need to integrate took

Despite all the advantages of prototyping, currently there is no one tool that can encompass all aspects of the design and development process. Moreover, different types of DSP applications may have different requirements on tools for prototyping. Therefore, it is necessary to incorporate a number of tools to reap the full benefit of prototyping. SPADE is an integrated environment to provide prototyping capability for design and developing DSP applications. SPADE allows easy

86 COMPUTING & CONTROL ENGINEERING JOURNAL APlUL 1995

- __ - _ _ _ -__ ~

SIGNAL PROCESSING

IBM PC compatible

DAS

DSP system board

SPOX

.. ... " ILS SPARCstation

SPARCstation w DSP system

board

J

IBM PC compatible -7 target DSP Emulation

Macintosh

m DAT recorder

BONeS KINDRA VAX DAS MOSES W A S )

Fig. 2 Network diagram of SPADE

programming, compiling, debugging, analysis and implementation of real-time signal processing algorithms on a DSP platform. As new DSP and DSP support tools emerge, SPADE must be able to absorb the technology quickly. Hence, not only is there a need to integrate, but also there is further need to integrate quickly. This means that SPADE must be fairly flexible and modular in nature.

SPADE comprises tools for developing a range of DSP systems for data, audio and network applications. It is not possible to list out all the components of SPADE but a few are shown here to illustrate how it can jointly perform the prototyping process,

Signal Processing Worksystem (SPW6.' Signal Processing Operating executive (SPOX)alo " D ~ 1 , 1 1 , 1 2

Data Acquisition System (DAS) VAX Data Acquisition System W A S ) Interactive Laboratory System DSP development system boards for Motorola 56001,'@

Modem Simulation Evaluation System (MOSES) Block Oriented Network Simulator (BONeS).

These tools will be discussed in more detail later. The tools are installed either on Sun SPARCStations,

PCs (IBM-compatible personal computers) or a MicroVAX minicomputer. All the workstations and computers are connected on a network backbone and communicate with each other using a proprietary networking technique and protocol (see Fig. 2). This allows the tools to be able to share and transfer design specifications, data files and simulation and implementation results easily. It facilitates the use of

Motorola 96002 and TMS320C3O4j

more than one tool to develop a DSP application. SPADE provides designers with the flexibility to use the operating system and the tools with which they are familiar. It also provides a multi-disciplinary design team with the means to communicate with each other using the same specification language, The technical details of the networking arrangements are beyond the scope of this article; commercial software and hardware packages for the networking of these tools are readily available.

Tools to provide realistic simulation SPADE provides the capability to perform simulation

as realistically as possible. The deficiencies of the simulation model are reduced by substituting part of the simulation model with the capture of signal data from a real-world system (e.g. at the receiver end of a telephone circuit). The use of captured data in simulation becomes particularly important when effects, such as non- linearities, transmission channel impairments and unpredictable network events, are important and not easily simulated. Depending on the application, the data captured can be digitised speech or data signals. The real-world system could be that of the BT network or an isolated piece of hardware related to the signal- processing function. The captured data is stored in SPADE as digitised signal files and can be re-used in SPW, SPOX or KINDRA simulations and implementations. The captured data can also be employed to analyse and validate the algorithm on a DSP development board. The data can also be fed into and recaptured at the output of the DSI? An analysis tool such as ILSu or SPW can then be used to analyse the signals graphically. Hence, captured real-world data provides a common reference for verifying the algorithm both in the simulation and the implementation stages.


SIGNAL PROCESSING

. -

Fig. 3 (a) Typical signal processing application for data-transmission implemented using the SPW block diagram editor; (b) A typical signal processing application for data-transmission analysed using the SPW signal display editor Iphotos: courtesy of Comdisco Systems Inc.]

In SPADE, tools available for capturing real-world signals are the DAS, VDAS and the Sun SPARCStation built-in analogue-to-digital input device. The DAS hardware is commercially available and is installed in a PC controlled by software. It can capture data of up to a sampling rate of 16 kHz dual channel with 16 bit accuracy. The VDAS5* provides SPADE with further capability to use data recorded using a digital audio tape @AT) recorder system (Fig. 2). The data recorded on a DAT tape is transferred to the MicroVAX using software developed at BT The transferred data has 16 bit accuracy dual channel and has a sampling rate of 48 kHz. The data can be downsampled to 8, 16 or 24 kHz when

necessary. Other means to capture data in SPADE includes the use of the built-in analogue-to-digital (m) and digital-to-analogue @/A) devices on the Sun SPARC- Stations. These A/D and DIA devices can be controlled from within SPW to record and play the data on the audio input and output, respectively, of a Sun SPARCStation. These data-acquisition devices generally produce data files which can be used directly by SPW and other simulation tools in SPADE such as M0sEs.5~

MoSES is a form-based system developed at BT Laboratories to simulate a generalised high-speed data-transmission system?* The simulation program and the interface to the forms are written in C. Once a simulation is established, MoSES provides a set of forms to enter simulation parameters, trace program variables and control graphical displays. The simulation can then be compiled, executed and analysed without having to refer to the underlying C program. MOSES also has a seamless interface to ILS where further signal analysis can be carried out. With the use of VDAS and MoSES, a real-world signal on a data- transmission channel has been captured, processed and analysed using MoSES which enhances the validity of the result?’

Another simulation tool in SPADE includes BONeS (Fig. 2) (BONeS is the trade mark of a Comdisco Systems Inc. product) to

simulate communications networks characteri~tics.5~,~* BONeS is an event-driven networks modelling tool for the analysis and prediction of various networks performance. In SPADE, SPW and BONeS have been used to study the quality of digitally encoded speech due to the network events?* It further demonstrates the added-value of SPADE in the joint exploitation of event-driven (BONeS) and data sample-driven (SPW tools?*

Took to provide a clear route to implementation

have to be met on two fronts: The provisions for a clear route to implementation

88 COMPUTING & CONTROL ENGINEERING JOURNAL APRIL 1995

SIGNAL PROCESSING

efficient DSP code generation consistent specification.

As far as the efficiency in converting HLL programs into low-level DSP code is concerned, it is still dependent on the HLL compiler or the DSP programmer. However, the problem may reduce or even disappear in the future as the efficiency of compilers improves. In the short term, a cross-compiler can be used in conjunction with handcrafted assembler to improve efficiency. Provided that a structured approach is established, libraries of efficient DSP code modules can be set up and reused. Consistency in the specification can be achieved by using some of the existing tools. In SPADE, the tools used to achieve this are SPW,' SP0Xlo and KINDRA." Each of these three tools fulfils a different role and complements each other.

Signal Processing Worksystem (SPW) SPW is a workstation-based software package. An

algorithm is specified and described by constructing a diagram using the SPW block diagram editor @DE). SPW provides the user with a set of library blocks to carry out most of the common signal-processing operations (refer to Reference 7 for further details of the library). Fig. 3 depicts a typical signal-processing application implemented using SPW. The simulation of an algorithm is constructed directly from the block diagram level using a simulation program builder (SPB). The simulation results and output signals can be analysed and processed using the SPW signal display editor (SDE). A block with specific functionality that is not available in the library can be constructed by using the provided library blocks. A new block can be hierarchically defined to carry out the same function as a connected set of blocks. This approach has proven to be useful for algorithm designers who have limited HLL programming experience. Alternatively, a new block can be created and customised by inserting C code into a provided program structure template that is associated with the block. This approach suits more experienced HLL programmers and can be more efficient in terms of run-time. Customised blocks are important at the implementation stage, when the block diagram is required to be compiled and run on a DSP using an automatic code generation system (CGS). The code efficiencies associated with the blocks beome a crucial factor to the real-time performance of the algorithm.

In SPADE, various signal-processing algorithms52 have been implemented on a commercial floating-point TMS32OC30 DSP system board45 via SPW. Using SPW, the real-world data captured by DAS and a DSP system board, the performance of the algorithm can be specified and analysed in the same environment. The real-time requirement can also be studied. It was found in one example52 that the SPW implementation could be optimised to meet real-time criteria without having to carry out any hand-crafting on the DSP assembler.

Signal Processing Operating executive (SPOX) SPOX exists within SPADE to provide users with

another way of testing DSP applications without having to write DSP assembler programs. A programmer can use the standard C language with the additions of some SPOX library C functions. SPOX provides the user with a set of functions which can be inserted into a program, some of which are optimised with DSP assembler code in order to improve the run-time efficiency. SPOX also provides the programmer with functions to manage the DSP memory usage, input and output interfaces and host communications. The program can be compiled using a DSP HLL compiler and the algorithm can be run on a DSP. SPOX also provides a consistent specification from the simulation stage through to the implementation stage, and hence is suitable to be used in a prototyping environment. However, SPOX does not have a user- friendly graphical interface, such as block diagrams, to accommodate users who do not have C programming skills.

In SPADE, a signal-processing application5* has been implemented on the TMS3X30 DSP system board" via SPOX and SPW. Most of the signal-processing operations for this application are implemented on SPW with a specific part, the fast Fourier transform (FIT), implemented using SPOX. The data at the input to the FFT is transferred from SPW to a file and is accessed by the SPOX program. The data at the output of the FFT is then transferred to a file and is subsequently used by the SPW implementation. The experiment demonstrates the possibility to jointly exploit the SPW and SPOX libraries in prototyping a DSP application. This would not have been possible if these tools were not integrated under SPADE.

KINDRA KINDRA was developed by BT.11'2 It was an early

implementation of the 1984 CCITT (International Telegraph and Telephone Consultative Committee) standardised Specification and Description Language (SDL).l2 It is a set of software design tools based on the use of state-transition diagrams, symbols and extended flowcharts to specify the software structure. The charts can be hierarchically decomposed from top-level charts into lower-level charts to reveal further software specification details. Charts can be created, edited and maintained using an interactive graphical editor or a text editor. Text can be entered into the chart symbols using the graphical editor or the text editor. Furthermore, graphical charts can also be generated from a text file. If the charts are used for documentation purposes only, SDL or any type of statement can be used as text input. Fig. 4a shows a typical signal-processing simulation example, which involves the input of signal data, processing of the data and output of signal data or results. Fig, 4b shows the hierarchical decomposition of the chart symbol labelled 'process data' (Fig. 4a). It then reveals


SIGNAL PROCESSING

Fig. 4 (a) Typical simulation programming structure illustrated using a KINDRA chart; (b) Further level of KINDRA chart to reveal details of the 'process data' chart symbol in Fig. 4(a)

typical simulation _ - - - _ _

input 9 4

output 9 a

main program ..........

5p5termination

b

further detail such as the chart initialisation, signal data processing iterations and the termination chart symbols (further details of the KINDRA tools can be found in Reference 11).

At the simulation stage, if compilable C statements are used in the charts, KINDRA tools can be used to generate C simulation programs directly. Using the information given by the symbols and the C statements in the charts, a KINDRA C coder (one of the KINDRA tools) can generate the corresponding C program automatically. At the implementation stage, the KINDRA tools can be employed to structure the DSP assembler program using the same specification as for the simulation. However, since the DSP assembler program is not generated automatically, any type of statements can be used as text input to the chart. The KINDRA charts are then used only as a template for the program structure. The DSP program is then constructed according to the template, using the target DSP assembler.

In SPADE, algorithms have been implemented, via KINDRA, for the fixed-point Motorola DSP56001 system board." The integrated use of KINDRA, SPW and SPOX is possible again via the use of common data files. Due

to the way KINDRA is used for developing DSP applications, it should be suitable for both fixed and floating-point DSP implementations, while SPOX is currently targetted for floating-point DSP implementations. On the other hand, KINDRA tools were not originally designed for developing DSP applications, the program structure produced may not be efficient and no automatic DSP code generation is provided. However, as SPW is dependent on a signal-flow and block-diagram approach, KINDRA tools can be used to implement certain DSPapplications which do not rely on signal-flow structures such as the control software of signal processing or system operations.

Further comments and future trends By using a structured design method within SPADE,

the communication between the simulation programmer, the DSP programmer and the customer is generally enhanced. The SPW block diagrams and the SDLiKINDRA charts provide good sources of documentation and are easier to maintain. The block diagram approach in SPW and the chart symbols in KINDRA encourage the programmer to split the program

90 COMPUTING & CONTROL ENGINEERING JOURNAL APRIL 1995

SIGNAL PROCESSING

into manageable modules which improves re-usability. The hierarchical design approach in both SPW and KINDRA allows the smaller tasks and details to be hidden when necessary. With automatic DSP generation facilities, these tools enable DSP software to be developed by programmers with very little or no knowledge of DSP architectures. As a tool continues to support automatic code generation for more DSPs, it will minimise the effort to change the initial specifications or a built-up set of library blocks, or to retrain the designer, when the need to migrate to a new DSP arises.

Conventional software design tools and languages do not take advantage of the parallel processing capability of DSPs. As a result, there are potential run-time inefficiencies in both the C and the DSP programs in return for a better structured and maintainable software output. However, by combining the skills of both an HLL programmer and an efficient DSP programmer, the structured approach will help to identify sections of the program where such inefficiency can be remedied. Moreover, in order to minimise the inefficiency, it is possible that the library functions of SPOX can be combined with the program structure provided by tools such as KINDRA.

SPADE has provided the tools to develop DSP applications with a well-defined set of working practices. These not only improve the ease in designing and analysing signal-processing algorithms but also produce an easily maintainable and portable system for future enhancement. In SPADE, data acquisition, SPW, SPOX and KINDRA have been utilised both individually and jointly. Data processed by one tool can be seamlessly transferred to another tool for further processing. This was often done to take full advantage of each tool, for instance, the efficiency of the SPOX library and the user- friendliness of SPW block diagram specification. Hence, SPADE demonstrates the capability to integrate various tools into a prototyping environment, to reap the value- added benefit of the integration.

As the complexity of DSP applications and the capability of DSP increase steadily, the demand for tools also grows. Future design techniques and tools need to support a

high degree of parallelism for high processing

mixture of processors (heterogeneous platform)4y mixture of synchronous and asynchronous

mixture of processing operations using different

implementation using analogue, DSP core and random

throughput"'

opera tions4'

sampling rate"'"

logic on one slice of

An integrated environment will be required to provide the tools to

0 simulate and study the effect of finite-length arithmetic: study the interactions between signal processing and

0 schedule and monitor multi-tasking and multi-

produce run-time efficient code from high-level

0 ensure the portability of previous design.

In future, the programming of DSP will gradually migrate away from handcrafting assembler code. As tools havemadeprogrammingand documentation easier, much of the effort will be focused on the studying and implementation of algorithms for DSP applications and the development of reusable specifications. According to the requirements of the applications, SPADE will continue to evolve and incorporate the appropriate tools.

Conclusions

network events'.52

processing operations"

specification'.16

SPADE employs a variety of computer-aided tools to form a common basis for generating high-level language simulation and DSP implementation programs. Although these tools use different methods to specify and implement an algorithm, they have generally provided a consistent and well documented design process. SPADE provides the means to capture and store real-world data for use in both the simulation and implementation stages. This ensures that the results obtained during the prototyping stages are as realistic as possible. Various DSP system boards also exist in SPADE, for implementation and verification purposes. Currently, because the cost of DSP and the demand on its real-time performance is high, the need to produce run-time efficient code is the overriding concern. In the longer term, however, when cheaper and more powerful devices emerge, then easy maintainability and portability will take precedence. In order to exploit the available technology fully for the maximum gain in developing DSP applications, a development environment such as SPADE must be capable of incorporating appropriate tools for the different stages of the process.

Acknowledgment

Laboratories for his support in this project.

References

The authors wish to thank Mr. Alwyn Lewis of BT

1 LEE, E. A.:'Programmable DSPs: a brief oren-iew'. IEEE .2-%o.o

2 '>fore megaflops for your L Y E , 1EERr.ilcir. 1990. 36, (8). p.288 3 CAREY, \I. J.: 'System opportunities when designing with digital

signal processors', Digital Signa: Prccessinx: Technology and Applications Seminar Prcceedings. ERA report 89-0161. ER.4 Technology Ltd.. 1989, pp.l l . ld

4 IP. S. F. .A.. KNOWLES. R. J.. and EASTON. P. U:: 'Digital processing sl-stem design methodolog)-', It% Colloquium Dig 1990/120, E E Computing R- Control Division. 1990. pp.2'1-1

5 KSOWLES, R. 1.. P, S. E A, and EASTON. P IT.: 'Structured DSP design methodology', IhSTED Int. Coni. Signal Proceasing and Digital Filtering, Lugano. 1990

.Wagmine, October 1990. pp. 11-16


SIGNAL PROCESSING

6 LAMB, K. J.: 'System level DSP tools for exploitation of future ASIC technologies', Digital Signal Processing: Technology and Applications Seminar Proceedings, ERA report 89-0461, ERA Technology Ltd., 1989, pp.4.1.1-9

7 'Signal Processing Worksystem', COMDISCO Systems Inc., Bristol, 1991

8 KEELING, N. J., and AHLUWALIA, K.: 'Enhancing high level DSP software portability and productivity with a real-time DSP operating system', ERA Seminar Proceedings for Digital Signal Processing Technology and Applications, ERA Report 890461,1989, pp.4.2.1-8

9 KEELING, N. J., and AHLUWALIA, K.: 'SPOX a high level approach to DSP, EIectronic Engineering, 1990, pp.77-83

10 'Application Programming Guide, TMS32Oc30 Version, SPECTRON Microsystems Inc., 1989

11 'KWDRA User Manuals', British Telecom Research Laboratories, Martlesham Heath, UK

12 ORR, R. A., NORRIS, M. T., TINKER, R., and ROUCH, C. D. V: 'Systematic method for realtime system design', Mfi~oprocessors and Microsystems, 1988, 12, (7), pp.391-3%

13 LAUWEREINS, R., ENGELS. M., PEPERSTRAETE, J., STEEGMANS, E., and GINDERDELJREN, J. V: 'GRAPE a CASE tool for digital signal parallel processing', I E l Z Acoufics, Speech and SigndProcessing Magazine, 1990, 7, (Z), pp.3242

14 SLANEY, M.: 'Interactive signal processing documents', IEEE Acoustics, Speech and Signal Processing Magazine, 1990. 7, (21,

15 'Programs for digital signal processing', Digital Signal Processing

16 'IMSL Library, Reference Manual', IMSL Inc., Houston, TX, 1980 17 'DSPSKCC, DSP56ooo/1 C Cross Compiler users manual', Motorola

Ltd, Milton Keynes, UK 18 TMS32K30 C Compiler reference guide', Texas Instruments Inc.,

Dallas, USA, 1990 19 'WE DSP32 and DSP32C C Language Compiler user manual',

AT&T Documentation Management Organization, 1988 20 'User Guide for the BT AT&T DSP32C Compiler, Speech

Processing and Speech Coding Section, British Telecom Research Laboratories, Martlesham Heath, UK

21 'Filter design and analysis system', Momentum Data Systems, Costa Mesa, USA, 1988

22 'Hypersignal user manual', Hyperception, 1988 23 'Interactive Laboratory Systems users manual', Signal

Technology Inc., Goleta, USA, 19% 24 SHANMUGAN, K. S., MINDEN, G. J., KOMP, E., MANNING, T. C.,

and WISWELL, E. R.: 'Block-oriented system simulator (BOSS)', Internal Memorandum, Telecommun. Lab., University of Kansas, 1984,17

25 'DSPlay XL ZPM32 Graphic Development Environment for the Burr-Brown Corporation ZPB32 DSP Board', Burr-Brown

26 ZISMAN, M. A.. OLEARY G. C., and JOHNSON, D. H.: 'A block diagram compiler for a digital signal processing MIMD computer', Proceedings of the Acoustics, Speech and Signal Processing Workshop, 1986, pp.8.1.2-8.1.2

27 LEE, E. A., HO, W. H., GOEI, E. E., BIER, J. C., and BHATTACHARYYA, S.: 'Gabriel: a design environment for DSP', IEEE Transactions on Acoustics, Speech, and Signal Processing, 1989, 37 , (ll), pp.1751-1762

28 BIER, J. C., GOEI, E. E., HO, W. H., LAF'SLEY, I? D., OREILLY, M. I?, SIH, G. C., and LEE, E. A.: 'Gabriel: a design environment for DSP', IEEE Micro Magazine, October 1990, pp.2&45

29 COVINGTON, C. D., CARTER, G. E., and SUMMERS, D. W.: 'Graphic oriented signal processing language--GOSPL', Proceedings of Int. Conf. Acoustics, Speech, and Signal Processing, 1987, pp.187%1882

30 KARJALAINEN, M., ALTOSAAR, T., and ALKU, P.: 'QujckSig-an object-oriented signal processing environment', Proceedings of IEEE Int. Conf. Acoustics, Speech, and Signal Processing, 1988, pp.1682-1685

31 KARJALAINEN, M.: 'A Lisp-based high-level programming environment for the TMS32oc30, Proceedings of IEEE Int. Conf. Acoustics, Speech, and Signal Processing, 1989, pp.ll50- U53

32 KARJALAINEN, M.: 'DSP software integration by objea- oriented programming: a case study of QuickSig', I= Acoustics, Speech and SignalProcessing Magazine, 1990,7, (Z), pp.21-31

PP.8-2o

Committee, IEEE Press, John Wiley and Sons, 1979

Corp.

33 KNOLL, A., and NIEBERLE, R.: 'CADiSP-a graphical compiler for the programming of DSP in a completely symbolic way', Proceedings of h t . Cod. Acoustics, Speech and Signal Processing, 1990, pp.1077-1080

34 HARTUNG, J., GAY, S. L., and HAIGH, S. G.: 'A practical C language compiler/optimiser for real-time implementation on a family of floating point DSPs', Proceedings of Int. Conf. Acoustics, Speech and Signal Promsing, 1988, pp.1674-77

35 SIMAR, R., JUN, and DAVIS, A.: 'The application of high-level languages to single-chip digital signal processors', Proceedings of Int. Conf. Acoustics, Speech and Signal Processing, 1988, pp.167%1681

36 KAFKA, S. M.: 'An assembly level global compacter for digital signal processors', Proceedings of Int. Conf. Acoustics, Speech and Signal Processing, 1990,4, pp.1061-1064

37 KIM, B. M., and HECK, L. P.: 'Automatic design of parallel implementations of DSP algorithms', Proceedings of Int. Conf. Acoustics, Speech and Signal Processing, 1990, 4, pp.lOS1056

38 LEARY, K. W., and WADDINGTON, W.: 'DSP/C a standard high level language for DSP and numeric processing', Proceedings of Int. Cod, Acoustics, Speech and Signal Processinn, 1990.4. DD.~S~@%

39 SAUNDERS, J. H.: %survey of object-oriented programming languages', Journal of Object-Oriented Programming, 1989,1, (6)

40 KEENE, S. E.: 'Object-oriented programming in COMMON Lisp' (Addison-Wesley, Reading, MA, 1989)

41 HILFINCER, P.: 'A high-level language and silicon compiler for digital signal processing', Proceedings of the Custom Integrated Circuits Cod., 1985, pp.215-216

42 GENIN, D., HLFINGER, P, RABAEY, J., SHEERS, C., and DE MAN, H.: 'DSP specification using the SILAGE Language', Proceedings of Int. Conf. Acoustics, Speech and Signal Processing, 1990,4, pp.1057-1060

43 LE GUERNIC, I?, BENVENISTE, A., BOTJRNAI, P., and CAUTER, T.: 'S IGNAGa data flow-oriented language for signal processing', IEEE Transactions on Acorcsh, Speech, and Signal Processing, 1986,34, (2)

44 'Motorola 56001 FC system board', Loughborough Sound Images Ltd, Loughborough, UK

45 'Texas Instruments TMS32Oc30 PC system board', Loughborough Sound Images Ltd., Loughborough, UK

46 LEARY, K. W., and CAVIGIOLI, C.: 'The ADSP-21020: an IEEE floating point and fixed point DSP for HLL programming', Proceedings of Int. Conf. Acoustics, Speech and Signal Processing, 1991, pp.1077-1080

47 BUCK, J., HA, S., LEE, E. A., and MESSERSCHMITT, D. G.: 'Multirate signal processing in Ptolemy', Proceedings of Int. Conf. Acoustics Speech and Signal F'nxessing, 1991, pp.12451248

48 BARRERA, B., and LEE, E. A.: 'Multirate signal processing in Comdisco's SPW. Roceedina of Int. Cod. Acoustics. SDeech . . ~ ~~~~~ ~

and Signal Proc&ing, 1991,&dll3-1ll6 49 ENGELS, M., LAUWEREINS, R., and PEPERSTRAETE, J. A.:

'Rapid prototyping for DSP systems with multiprocessor?.', IEEE Design & Test of Computers Magazine, 1991, 8, (Z), pp.52-62

50 SIMAR, R., JUN.: 'TMS32oc40: a DSP for parallel processing', Proceedings of Int. Cod, Acoustics, Speech and Signal Processing, 1991, pp.108%1092

51 'Special guide to data communications: high-speed networks and interconnection', IEEE Spectrum Magazine, August 1991, pp.22-44

52 WESTALL, E A., and P, S. E A.: Special issue on DSP in telecommunications, Brihkh Tekcom Technolog_v Journal, 1992, 10, (1)

0 IEE 1995 _ _ _ _ _ _ ~ ~

Dr, S. E A. Ip, E A. Westall, R. J. Knowles, P. R. Benyon and P. W. Easton are with the BT Laboratories, Martlesham Heath, Suffolk IP5 7RE, UK. Mr. Westall is an IEE Member; Dr. Ip, Mr. Knowles and Mr. Benyon are IEE Associate Members.

92 COMPUTING & CONTROL ENGINEERING JOURNAL APlUL 1995

- ~~ ~~ ___ ___-~

prototyping environment for digital signal processing systems

Documents