Digital Signal Processor (DSP) 66

The most important part of the system is the DSP. The DSP handles controlling all the chips 

involved including; Direct Digital Synthesis (DDS), Digital Receive Signal Processor (DRP), and 

both VGA’s. It also handles the data capture, processing, and storage of the down‐sampled 

data from the DRP. The DSP board has an external 16k x 24bit memory for storage of data 

from the DSP. This means that the amount of data points per program run is limited to the 

amount of memory that is available and if too many points are stored an overflow will occur, 

causing errors. The DSP is interfaced to the computer via a USB 1.1 connection enabling data 

transfer speeds of up to 12 Mb/s. This USB interface enables the uploading of programs and 

data variables to the DSP as well as the ability to download the data captured from the DSP. 

2006) and is now sold by the company Magritek (http://www.magritek.com/) which specialise 

in NMR software and hardware. 

Figure 4.4: Picture of the DSP board developed and sold by Magritek – Dykstra (2006). 

The DSP used is the 24bit processor created by Motorola named DSP56309 as seen in Figure 

4.5. This uses a high performance pipelined one clock cycle per instruction engine enabling fast 

processing for digital signal processing applications. The DSP56309 can process up to 100MIPS 

at 3.3V and also contains a large amount of on‐chip memory. The DSP56309 has direct 

memory access (DMA) and so enables fast communication to external memory. It also has an 

enhanced synchronous serial interface (ESSI) enabling fast communication to serial peripherals 

such as amplifiers. This DSP is sufficient for what is needed in this system. 

The DSP runs an operating system (OS) created by Dykstra (Dykstra 2006). This OS handles the 

communication between the DSP and the PC via USB. It enables a compiled pulse program 

(usually written in assembler) to be uploaded to the DSP. It can then start the program running 

and sends a signal back to the PC when the program has finished running. It also has another 

function which enables data to be written or read directly to or from the addresses within the 

DSPs internal or external memory. The normal process for running a program on the DSP 

would be to upload the program, write any data needed for the program, run the experiment 

Figure 4.5: DSP56309 Block Diagram (Motorola 1998). 

Although the DSP to PC USB connection has been introduced one vital component that has not 

yet been discussed in detail is prospa. Prospa is a mathematical software package that is 

specifically tailored by Magritek for scientists working in the field of NMR – basically a simpler, 

faster, customised version of Matlab. Prospa has multiple features including: 1D, 2D, and 3D 

plotting; simple GUI development; huge amount of built in post processing macros such as FFT; 

most common mathematical functions; and support for most matrix operations. Prospa also 

has specialty drivers developed to communicate to the DSP board via USB. The DSP is 

controlled using a DLL plug‐in in prospa which enables control of the commands mentioned in 

the previous paragraph and a list of the functions used from prospa as can be seen in Table 

4.1. 

Macro Name  Description 

dspsrec  read an s‐record and store in a vector 

dspwrite  write data to the DSP 

dspwritepar  write pulse program parameters to the DSP 

dsprunpp  run a pulse program in the DSP 

dspabort  send abort signal to DSP 

dspread  read data from the DSP 

dspreadpp  read pulse program from file and store in a vector  Table 4.1: DSP DLL module listed from prospa. 

There are a series of commands needed to run a pulse program from prospa – these are 

shown in Table 4.2. The first step is to read the pulse program from the hard drive and save it 

as a variable – variable pp. This variable is then written to the program memory or p‐space at 

the running of the program (such as the frequency range to scan over) are written to a place in 

memory (x or y memory) predetermined by the pulse program. Now that all the setup has 

been performed the DSP pulse program can be run, and once run the prospa macro waits until 

the function returns a value before continuing. The only thing to do once an experiment has 

been run is to read the data (from a predetermined memory location) and perform any post 

processing necessary. Once the pulse program has been loaded into memory the program can 

be run multiple times without having to reload it. So the input variables can be updated and 

the pulse program can be run sequential in a loop involving multiple experiments.  pp = dspsrec("FFT_Cap.p") # read pulse program

dspwrite("p",0x1000,pp) # read data points

dspwritepar("x",0x00,p) # Send parameters to DSP

r = dsprunpp() # Run pulse program

D = dspread("y",0x10000,nrDataPnts) # read data points

Table 4.2: Typical sequence of commands to run a program and download the data in a prospa script. Before a prospa script to control the DSP can be run a pulse program must be written and 

compiled. This pulse program is usually written in Motorola assembler code (as opposed to a 

high level language) to enable an accurate idea of how long different processing tasks are 

taking to complete.   Though writing in assembler enables a significant amount of speed and 

code optimisation, errors can occur at a much higher rate than using a high level language. 

One of the deciding factors to using assembler was the problems with working around the 

operating system running on the DSP, to enable C‐complier definitions to define areas not 

used. This is much simpler in assembler at the expense of some of the more advanced memory 

and stack features on the DSP.  For further information see Dykstra (Dykstra 2006). 

To write in assembler the ConTEXT editor was used with a 56300 assembler highlighter created 

by Rob Ward as colour highlighting makes writing much easier. The complier used was the 

Motorola “ASM56300.exe” to create the linking “*.cld” file and then the “srec.exe” to create a 

“*.p” file for running on the DSP. This can be seen in Table 4.3, with “Filename.asm” as the 

input and “Filename.p” as the output. For further information on this compiler see the 

“Assembler reference manual” from Motorola.  

asm56300.exe -a -b -l -z Filename.asm srec.exe Filename.cld

Table 4.3: Typical sequence of complier options to compile an ‘asm’ file into a ‘p’ file.

The DSP Board plugs into a 96pin back plane and though this the DSP can communicate to the 

other boards in the system. To communicate with the digital transceiver the DSPs DMA bus is 

used which enables addresses to be mapped to x or y memory within the DSP. This is done 

using address attributes AA2, and AA3 in conjunction with the WR (write) and RD (read) 

control lines. When the corresponding address attribute line is low and the WR or RD is low 

then a write or read will occur. The DSP uses DMA to setup and read data to and from the 

digital transceiver board. Therefore all that is required for the DSP to setup chips is a memory 

For the DSP to communicate to the amplifiers, the enhanced synchronous serial interface 

(ESSI) is used. ESSI when used for write‐only operation is made up of only 3 outputs signals. 

The first is a clock signal which is generated internally in the DSP and this clock is fed to the 

device to be controlled (in this case an amplifier). The next is the data line which sends the 

data to the device. Finally is the chip select signal which enables only the chip that is required 

so that multiple devices can use the same clock and data lines.  

This DSP is a highly versatile device which is will enable support for the all the functions that 

maybe required including most complex.