DSP SOFTWARE

This chapter describes DSP software issues that are common to the three boards containing DSPs (timing, utility board, and VME interface). Commands and features specific to each board are discussed in the relevant chapter. Beginning with revision 2.10 the DSP program will only work on boards containing 32k x 8 boot PROMs, and full support for EEPROM programming is provided. This chapter has been updated to reflect software Rev. 2.30.

DSP56001 Description

The heart of the timing board is the Motorola DSP56001, an integer digital signal processor processor with a 24-bit data word, a 16-bit address space, a fast ALU, a Reduced Instruction Set Computer architecture that executes most instructions in one clock cycle (100 nanosec in this design) and extensive on-chip peripheral support. These peripherals include separate address spaces for on-chip program and data memory, a synchronous serial interface, boot logic and a simple interface to an external data bus. A block diagram of the DSP is shown in Fig 7-1.

The DSP is used as a timing generator to write encoded 24-bit data words to its external data bus, which are decoded by external circuitry to control the CCD clocks and video processor. The DSP is also used to collect CCD pixel data generated by the analog readout boards and to send them via a fast serial link to the instrument control computer. The following materials are available from Motorola:

Educational users may obtain the software products through University Support, HW 68, PO Box 2953, Phoenix, AZ 85062 (602-952-3857) at a substantial discount. Literature may be obtained by calling the Motorola DSP marketing group at 512-891-2286. At least the User's Manual and an assembler should be obtained by the user. It is highly recommended that users obtain the User's Manual and one of the assembler/simulator packages.

DSP Source Code Structure

Several DSP source code files have been written to support each of the three boards, and are written in Motorola assembler syntax. This has been changed from earlier DSP code revisions where all the source code for a particular board was contained in a single source file. There is a boot file that contains code to initialize the DSP after reset and provide communication and memory maintenance functions. The boot files are pretty similar from one board to the next and interpret the same set of commands. The boot file is written to the EEPROM by a ROM burner, and it is intended that a typical user will not have to heavily modify this code.

Application programs contain software that is specific to the particular function and set of desired tasks for each board. Application programs are loaded into internal DSP memory by the boot code either from on-board EEPROM or by a downloading procedure from the host computer. Several application programs per board have been written to reflect different system configurations, readout modes and hardware testing needs. The application programs are intended to be heavily modified by users to optimize them to their particular needs. Internal addresses are somewhat different between the application program intended to be written to EEPROM and for downloading directly from the host computer to the DSP, and a command line parameter selects the desired mode during assembly of the application program. The simulation mode of earlier software revisions has been dropped because of the difficulty of maintaining it with the more complex addressing requirements of current revisions.

The boot code is located in the upper half of EEPROM memory starting at address $4000 for the timing and VME interface boards, and address $6000 for the utility board. Writing to the EEPROMs above address $4000 when they are installed in the boards is not allowed in order to prevent inadvertent writes that could make the boot code unworkable enough that the EEPROM would have to be removed from its socket for reprogramming with an EEPROM burner. It is software write protected by the 'WRM' command with the line

JSET   #14,R0,ERROR	; Write protect BOOTROM code. 

The DSP memory is not write-protected, but erroneous changes to it can be undone by simply resetting the board to cause a fresh copy of the write-protected boot program to be loaded into DSP memory from EEPROM. The application programs are all resident below address $4000 so they can be easily edited with the 'WRM' command during development cycles.

Generating EEPROMs with a programmer

It may not necessary for a typical user to program the EEPROMs with a burner, but the following section details how it is done should the need arise. The following is a UNIX script for generating a Motorola S-record containing both boot and application programs for the timing board that can easily be sent to an EEPROM programmer.

#!/bin/csh
  asm56000 -b -ltimboot.ls timboot.asm
  asm56000 -b -ltim1.ls -d DOWNLOAD 0 tim1.asm
  asm56000 -b -ltim2.ls -d REV4C 1 -d DOWNLOAD 0 tim2.asm
  asm56000 -b -ltim4.ls -d REV4C 1 -d DOWNLOAD 0 tim4.asm
  asm56000 -b -ltimsub.ls -d DOWNLOAD 0 timsub.asm
  asm56000 -b -ltimroi.ls -d DOWNLOAD 0 timroi.asm
  asm56000 -b -ltimtest.ls -d DOWNLOAD 0 timtest.asm
  dsplnk -btim.cld -v timboot.cln tim1.cln tim2.cln tim4.cln 
	timsub.cln timroi.cln timtest.cln
  del tim.lod
  cldlod tim.cld > tim.lod
  srec -bs tim

The file "timboot.asm" contains the boot source code, and the files "tim1.asm", "tim2.asm", "tim4.asm", "timsub.asm", "timroi.asm" and "timtest.asm" contain application programs. They are all separately assembled into relocatable files setting the DOWNLOAD command line switch to zero to indicate that code for downloading is not being generated, but rather it is code for EEPROM programming that is needed. The switch REV4C is set to one to indicate that a VME interface board hardware revision level 4C is installed, and is needed for assembly of any VME interface board code or timing applications that requires multiple readout. The linker links together the four relocatable files and resolves all relative address, after which a *.lod format file and a Motorola S-record file are generated.

The development environment this is written for consists of a SUN running the Motorola DSP development software with an EEPROM programmer attached to it via an RS-232 serial link. The Motorola S-records contain the assembler output that the EEPROM programmer program takes as input. A trick is needed to get the boot code properly placed beginning at address $4000 for the timing and VME interface boards since they have only one byte-wide EEPROM. The idea is that the S-records are generated by this script for a starting address of $C000 which is the address from which the DSP normally boots, but is not mapped to anything on the controller boards since the address space of the EEPROMs is limited to 32k and the address line A15 is unused. This procedure will depend on the EEPROM programmer used, but in our case consists of giving a base address of $8000 to the programmer to subtract from all incoming addresses, so $C000 will be converted to the correct $4000. Then the EEPROM is programmed in two steps. First the boot program is programmed with the base address of $8000 by restricing the range of EEPROM addresses that can be programmed to lie between $4000 and $7FFF, then the application programs are programmed with a base address of zero but with a programming range restricted to be zero to $3FFF so the boot program (which is contained in the same S-record file) does not get programmed in this second pass. The instructions for our particular EEPROM programmer are as follows -

  BASE		$8000		; EEPROM programmer command
  PROGRAM	$4000 $7FFF	; EEPROM programmer command
  cat tim.s			; UNIX command to send file
  BASE		$0000		; Now program the application program
  PROGRAM	$0000 $3FFF
  cat tim.s

The procedure for the utility board is simpler since the board has three EEPROMs and executes word transfers rather than byte transfer from memory to the DSP. The EEPROM generating script is -

#!/bin/csh
  asm56000 -b -lutilboot.ls utilboot 
  asm56000 -b -lutilappl.ls -d DOWNLOAD 0 utilappl 
  asm56000 -b -lutiltest.ls -d DOWNLOAD 0 utiltest
  dsplnk -butil.cld -v utilboot utilappl utiltest
  del util.lod
  cldlod util.cld > util.lod
  srec -mw util.lod

The -mw option on the S-record command generates word wide addresses. Three files are generated, "util.p0", "util.p1" and "util.p2" each of which is directly written to seperate EEPROMs.

Generating application programs for downloading

Similar scripts can be used to generate application code for downloading directly from the host computer to EEPROMs located on the boards, saving their having to be removed and placed in an EEPROM programmer. These scripts will generate *.lod format files that are described at length in the Motorola DSP56001 programming literature that can be easily interpreted by a program running on the host computer that writes to the DSP internal memory a word at a time using the WRM command. A similar procedure would be used for writing to EEPROM when they are installed in the boards except that the scripts described above for EEPROM programming would be used rather than the ones that follow since the DOWNLOAD = 0 switch in the scripts above generate correct EEPROM addresses. For the VME interface board the downloading script is -

#!/bin/csh
  asm56000 -b -d REV4C 1 -lvmeboot.ls vmeboot.asm
  asm56000 -b -d DOWNLOAD 1 -lvmen.ls vmen.asm
  dsplnk -bvmen.cld -v vmeboot.cln vmen.cln
  del vmen.lod
  cldlod vmen.cld > vmen.lod

Here only one application at a time is assembled, linked and downloaded at a time. The file "vmen.lod" will contain the boot program as well as the application program, and the user must insure that the boot program assembled with this script is identical to the one resident in the EEPROM on the board of interest. Downloading of the boot program can be esily prevented by having the host program skip over any address greater than $4000, and they won't get written to the EEPROM anyway. The download script for the timing and utility boards differs from this one only in the file names.

BOOTROM commands

Several commands are executed by all the DSP boards by the BOOTROM program, as follows. Every command must be preceded by a header ID.

TDL number - "Test Data Link". The DSP will read "number" and transmit it back to the source in order to test functionality of the communications path.

RDM address - "Read DSP Memory". Read from internal DSP or EEPROM memory. The most significant nibble of the address designates the memory space, as follows:

Bit #20 = 1 implies P: memory.

Bit #21 = 1 implies X: memory.

Bit #22 = 1 implies Y: memory.

WRM address value - "Write Memory". Write "value" to internal DSP or EEPROM memory, following the same encoding of the memory space as RDM.

Note: These two commands are used for both DSP and EEPROM memory access. DSP internal program memory does not exist above address $1FF, and EEPROM memory is inaccessible below $200. All EEPROM memory is accessed with the P: memory type identifier. The DSP software handles the EEPROM data and addresses as three one byte words for the timing and VME interface boards, and does the address conversion from byte to word addresses. The DSP software for the utility board handles all data and addresses as single words that are three bytes in lenghts, and does no conversion from byte to word addresses.

LDA # - "Load Application". This reads the application program starting at address $200 of the ROM, as well as the X: and Y: memory contents. # is the number of the application to be loaded and is between 1 and 10 for the timing and VME boards, and between 0 and 10 for the utility board.

RST - "Reset". This resets the DSP and reboots it from the BOOTROM program located in EEPROM. It is the software equivalent of hitting the reset button or powering up. The timing and utility boards send a 'RST' reply to the host computer after they have completed their booting after a reset has been issued, whether or not it was a hardware or software reset. The VME interface board can't send such a reply since its reply address has not yet been specified.

A handshaking system exists to inform the sender of commands that they are received and that processing can occur. The 'COK' replies of earlier revisions has been dropped entirely since the execution times of all commands outside of reading out the CCD are short enough that the added complexity of supporting the 'COK' protocol in the DSP code and host computer code was judged to be not worth the trouble. Most commands reply with a 'DON' when they finish executing, though there are important exceptions to this. The table below lists all commands for all boards, their approximate execution time and possible reply.

A timeout routine has been implemented in the command processor for all boards that requires that all words of a command be received by the command processor within one millisecond of receiving the header ID. The TIMEOUT parameter in the boot files can be changed by the user if desired. If the number of words specified in the header is not received in time then the words are simply discarded, with not even an error message being sent.

The following table lists all the commands for Rev. 2.25 boot and application programs. The required arguments are listed together with the reply and the approximate execution of the command. Instantaneous reply time indicates that the reply time is of order the communication time between boards in the system, which is a maximum of about 100 microseconds. The CCD clearing and readout times can be fairly long and are dependent on the parameters entered in the timing board readout parameter table.

The times are approximate. The execution time for LDA and RST for the utility board are about 1/3 those listed because its operations are word-wide rather than byte-wide.

Program Notes

Following are some notes on the programming of the three boards. The intention is not to be exhaustive or complete since examination of the source code can often be a quicker and more reliable guide, but to be helpful with some of the subtleties of the code. The user is encouraged to be careful in modifying boot code, and might find some of these remarks of some help.

A ROM identification area is provided at addresses P:06 and P:07, and is encoded as follows:

Institution, location and instrument codes are no longer entered by SDSU when the ROM is burned to facilitate ROM maintenance and verification, but the user can easily enter the information with with WRM command if desired. Users may access these identification codes once the ROM software is loaded into the DSP by executing the RDM command on these two memory locations to verify that the correct version of the ROM software is installed.

The boot program starts at the location P:START that is specified in an equate table at the beginning of each source code file. It is chosen to be as low as possible and uses interrupt service routine vector locations that are assigned by the DSP but unused by the particular board. As a result a warning message is generated during assembly to the effect that illegal instructions for interrupt service routines are being generated, and these warnings should be ignored.

Command processing is done by having interrupt service routines linked to input data devices add incoming commands to circular buffers indexed by address registers that are permanently allocated to that task. The address register assignment is listed after the ROM_ID table in the source code. The circular buffers are set up to be 32 words long, which is enough to contain typically ten commands, and resides in the Y: memory space. This allows several commands to be sent to a given board in sequence without having to wait for each one to be executed; they will be executed in the order in which they are received. Each input device is assigned a separate circular buffer to prevent intermingling of commands. (The exception to this is the VME interface board code, which has not yet been fixed up for this.) If a command is not being executed then the program is scanning the address register values for an increment caused by an incoming command. As soon as one is found a consistency check is performed to verify that its first word is a valid header. If it is correct then the last byte is read to determine when the complete command has been received. If there is more than one input data source then the command is moved to a separate buffer that contains commingled commands. A loop is entered to check that the entire command has been entered, and no time-out is presently implemented, so the program can hang indefinitely waiting for the complete command. Once the command is complete the header destination number is examined to see if the command needs to be executed by the board or passed on to another one in the chain. If it to be executed by the board then a table of valid commands is examined for a match with the second word of the command. If no match is found an 'ERR' reply is returned to the source. Otherwise execution continues at the address indicated by the command.

A reply routine, named FINISH, constructs the reply header ID by moving the source byte to the destination byte location, tacking on the correct source byte number, and adding two for the number of words in the reply. All replies are two words in length. The reply is added to the circular command buffer and then processed as any other command would be.

The serial communication interface (SCI) receiver is handled by an interrupt service routine on the timing and utility board. It is not used on the VME interface board. Care is taken in the routines to save and restore all registers that are used by the routine, which is done by writing them to X: memory. The routines just add together the three bytes that comprise a 24-bit word by reading the bytes from three sequential memory-mapped addresses in the X: I/O memory space dedicated to SCI support. Separate interrupt service routines are maintained for error conditions to clear the SCI hardware of the error condition.

A special de-bug command has been implemented for the timing board. It is very useful to examine command execution since most command pass through the timing board, and exposure sequences typically require several commands passing back and forth through the timing board. While the RDM command could be used to examine the command buffers, it is inconvenient since its execution alters the buffers, making interpretation difficult. Instead a completely separate command that does not go to any of the buffers is implemented. It can be executed by sending:

The contents of Y: at the indicated address will be returned to the host computer. The two dummy words are there just to make up the total of five words per command. Since none of the commands presently implemented contain five words it can be separately processed. A host processor command can easily be written to read all three timing board buffers and display them in a convenient table, with even the command words converted to their mnemonics. Locations other than Y: memory can be accessed by reprogramming the MOVE Y:(R7) command to whatever is desired. Or the whole thing can be turned off by replacing the simpler instruction in the SSI_ISR routine located just after the equate table.

The INIT routine is executed once by the DSP on boot up. It is overwritten application code once the LDA command is executed. The INIT routine initializes DSP control registers, sets up the circular buffers and registers, reads in X: memory from ROM, and initializes for the processing of interrupts. The timing board INIT routine goes on to set the DC bias DACs with safe intermediate values in preparation for the power-up sequence, and asserts the LATCH6 line as a signal to the utility board that is has completed the digital portion of the initialization. A jump table exists right before the INIT routine to allow the boot code to access application commands after application code has been loaded. Before it is loaded the jump table is a simple do-nothing, but the jump table is overwritten with valid addresses by the application code.

The boot code stores all the constants it needs to operate in X: memory. The application code generally stores constants it needs in Y: memory, although its command table is still stored in X: memory as an extension onto the boot command table. When an application program is loaded the command table entries for it are added to the boot command table in X: memory by the LDA command. Many constants are stored in X: or Y: memory as a device to conserve P: memory space. As an example, the command MOVE #$FFB0,R6 occupies two locations of P: memory and takes two clock cycles of execution time, whereas the instruction MOVE X:

Overlays have been implemented for four of the boot commands - RDM, WRM, LDA and RST - in the timing vne VME interface board boot programs. A 48 word area is set aside in the DSP P: internal memory area from $1D0 to $1FF for routines to be read into from EEPROM when a command calling for their execution is received. The routines are stored just above the X: data memory space, which is above the P: memory space containing the boot program code. When one of these four commands is received a jump is made to a routine to read in the overlay program, after which execution resumes at the overlay starting address. Repeated calls will cause a read from EEPROM each time, but even so the overhead introduced by the overlaying process is still just 10 microseconds. For the utility board overlays are not needed since the routines execute directly out of EEPROM memory, and these four routines are executed out of EEPROM memory rather than internal DSP memory.

Overlays are not implemented for application programs because it is intended that applications that are too parge to fit in the internal DSP memory space will be split into two or more independent applications, and loaded each time they are needed by executing the LDA command. Different from the case of boot overlay routines which are transparent to the user, the host computer must keep track of which application numbers contain which routines, and issues the LDA commands appropriately. These comments are made in the interests of future expandability of the application programs, since the ones being released with Rev. 2.30 all fit into individual application programs that would only need to re-loaded if hardware or wiring changes are made.

Back to Document List Page.