AED Documentation Manual - Software Overview

4. SOFTWARE OVERVIEW

4.1 TI Documentation References

This board has no software associated directly with it. The software is associated with TI DSP and the EVM board and with the Xilinx FPGA.

For the EVM board, TI supplies software support. Code Composer Studio is now available for the EVM and there is a support library for the board which comes with the debug tools for the board. ANSI C compiler tools are available for Code Composer Studio.

For the Xilinx FPGA, The programming tool choices are Xilinx Foundation Basic and Express. Foundation Basic will support the board without FPGA options. Express is required if any one of the FPGA options is ordered. The CoreGen tool is very helpful in applying this FPGA in the DSP environment.

The one area where there is some necessary software related documentation is for the Expansion Daughterboard interface to the DSP. This interface is defined partly by TI's documentation of the EVM and partly by the configuration you choose to put into the FPGA. Because the details of the interface are defined by the configuration, it is not possible to provide much software documentation. However, some of the hardware related documentation provided by TI is necessary to writing software for this interface.

The most relevant TI manual for the 6201/6701EVM is SPRU305, TMS320C6201/6701 Evaluation Module TechnicalReference. This is available on the TI web site at (not available in paper form):

www.ti.com/sc/docs/dsps/tools/tmds3260a6201.html

The particularly relevant sections are:

1.4.3 Expansion Memory - description of memory space addressable from the FPGA on the daughterboard.

1.5 Expansion Interfaces - general information about expansion daughterboards

1.5.1 Expansion Memory Interface - description of signals used for access to the expansion memory space. All of these bits are available to the FPGA except EA[9:2].

1.5.2 Expansion Peripheral Interface - description of the signals used for access to the serial ports, timers, interrupts, etc.

1.5.3 Daughterboard - description of the mechanical aspects of the daughterboard.

1.8.7 DSP Memory-Mapped Control/Status Registers - particularly the DSP CNTL Register bits 2, 5, 6, 7 and the DSP STAT Register bits 5, 6, 7.

3.5 Board Support Library API - set up of the EVM board.

A.7 Expansion Memory Interface Connector - pin out.

A.8 Expansion Peripheral Interface Connector - pin out.

B TMS320C6x EVM Schematics

----------------------------------------------------------

The comparable information for the 6211/6711 DSK is only available in the help section of the Code Composer Studio that is bundled with the DSK. The information in the help section is aberiviated and without much explanation. It is helpful to have read SPRU305 and view the documentation in the help section as corrections to the SPRU305 descriptions. There is no Board Support Library API available for the 6211/6711. The best substitute is the C6000 Chip Support Library. The Signalware code for the 6211/6711 does not use any support library for the majority of the board support. The interrupt support code from the 6201 is employed as it is the same for all the C62xx and C67xx processors.

Additional documentation that is useful with the expansion interface for the 6201/6701/6211/6711 EVM/DSKs is SPRU190, TMS320C6000 Peripherals Reference Guide. The particularly relevant sections are:

5. Direct Memory Access (DMA) Controller - very useful to download/upload data through the Expansion Memory Interface on the EVM and for using the serial ports on the Peripheral Interface on the EVM.

9.6 (EMIF) Asynchronous Interface - useful to control timing for the Expansion Memory Interface on the EVM.

--------------------------------------------------------------------

And, SPRU273, TMS320C6x Peripheral Support Library Programmer's Reference Guide. The particularly relevant sections are:

2.2.3 DMA Software Interface - set up and operation of the DMA (6201/6701 only)

2.2.4 External Memory Interface Support - set up of memory interface to EVM.

4.2 Description of Example Program

The example program is intended to provide an initial test for the board as well as to provide a framework for development of DSP code that employs the daughterboard. The example program uses the expansion memory interface of the EVM to transfer data at high speeds. The example program makes use of a DMA/EDMA channel, a DSP peripheral, to transfer the data without interrupting the CPU except when a block of data is ready. The example program represents only one of several ways to transfer data that can be implemented with the daughterboard hardware.

The daughterboard uses the FPGA to define its interface with the DSP. A example FPGA configuration is supplied by SIGNALWARE which implements the expansion memory interface to the DSP.

For high speed boards like the AED-100 for example, the implementation takes four samples two from each of the two A/D converters, and places them in 4 FIFOs 80 entries deep in the FPGA. When 64 entries are available in the FIFOs, the FPGA sends an interrupt to the DMA. The DMA generates a series of back-to-back reads (frame sync mode) to which the FPGA responds by placing the first byte of each FIFO in a single 32-bit word and making that available on the EMIF bus. The DMA timing is set to read the words somewhat faster than the sampling rate so that samples are being placed in the FIFO at the same time as words are read out, but such that the FIFO will slowly empty. The frame length is set so that a whole frame of words (e.g. 1024) is transferred without a FIFO underflow. The DMA then waits until the FIFO reaches 64 words again. The net rate is 10 million words per second, or 40 million samples per second split between the two A/Ds.

Finally, the DMA can be set to transfer any number of frames that will fit into on-chip memory. During the frame transfers, the CPU many not use the EMIF because this will not allow the back-to-back reads to take place. This also means that the data may not be transferred to another EMIF location from the FPGA.

For lower speed boards like the AED-102 for example, the implementation takes several samples from each A/D, and places them in one FIFO which is 16 entries long inside the FPGA. Whenever the FIFO has a sample ready, the FPGA sends an interrupt to the DMA/EDMA which performs a read of a half word. The maximum half word transfer rate is governed by the collective sample rates of the A/Ds, the EMIF register settings and the other activity on the EMIF bus.

Finally, The DMA/EDMA can then block the data into frames of any desired size with any number of frames per block (up to 2^16). The frame size then determines the rate at which the DSP is interrupted which can be as frequently or infrequently as desired. The data can be transferred into on-chip memory or other memory on the EMIF.

The example program is written in ANSI C and is itself very simple. It sets up the DMA registers, starts the DMA, starts the FPGA and waits for interrupts indicating a frame of data is ready. The example program takes in 10 frames of data and stops the DMA and FPGA. The program saves the first block, and computes the averages of the samples from the A/Ds for each of the ten blocks. At the end it prints these averages and the first 256 samples it receives in the first block.

The example program uses the CNTL0 line on the EVM to activate the FPGA (high is active). The FPGA returns a signal on STAT0 line if an FIFO overflow occurs (high indicates overflow). The data from the FPGA is read from address 0x016000xx in the TI C6x EVM. Other boards use an address with bits 22-31 constructed from the memory map for that board and 0x002000xx for bits 0-21.

For boards with 24 digital I/O lines (e.g. AED-102), the FPGA provides access and control of these lines through a register which can be read or written at address 0x015000xx in the TI C6x EVM by the example program. Other boards use an address with bits 22-31 constructed from the memory map for that board and 0x001000xx for bits 0-21. Bits 0-23 are the 24 individual I/O lines; bits 24-27 drive spare FPGA pins that are wired to the Logic Analyzer connector (if any); bits 28-30 set the direction of U18, U19, and U20 respectively (0-input, 1-output); and bit 31 is a enable for U18, U19, and U20 (0-enable, 1-disable). The example program activates each of the 24 lines separately for about 1 second at the end of the program.

Because the example program is also intended as a framework for DSP code development, its functions are divided into three modules according to the type of code in them:

1. AED_MAIN --A general purpose main program used to transfer data from the daughterboard are included in this module. These functions are very much application independent and can be used for a number of applications without modification.

2. AED_DMS_DMA/EDMA -- Data Movement Service (DMS) functions set up the DMA/EDMA registers for daughterboard transfer and start the DMA/EDMA. It also includes additional test functions for the DMS.

3. AED-1xx -- Application dependent functions which define the processing on the data from the DMA. This module is generally the only one that need be modified for an application of the daughterboard. This module in the example program demonstrates the use of the five functions which define the real-time processing. Using this module as a model really simplifies real-time programming with a DSP and the SIGNALWARE daughterboard.

The five functions which define an application are:

1. appl_parm() -- allows the application to define the size of the buffers, size of the transfer words and number of buffers used by the DMS for transfer of data from the daughterboard.

2. appl_init() -- allows the application to initialize any internal data, buffers, etc. before the data transfer begins.

3 appl_process() -- allows the application to process a frame of data which is passed to the function from the main program. This function can terminate the application with an appropriate return code.

4. appl_idle() -- allows the application to do any background processing it wants to do between processing frames of data.

5. appl_end() -- allows the application to do any final processing before termination.

Several definition files (.h files), a make file and a link command file complete the example program. Source for these files are included in the SIGNALWARE distribution disk.

4.3 Flash Programming

Flash memory is an option. Programs necessary to load the flash and the to support the flash operation are not included with the daughterboard. However, the FPGA configuration does contain the necessary support to operate the flash memory. If either flash memory option is purchased, programs to clear the flash memory and test the flash memory are included

The flash memory may be used as a non-volatile memory in two ways:

1. Store a boot load program for the DSP that the DSP will use automatically on power up.

2. Store data for the DSP which is not lost on power down or reset.

Sections following on ROM Based Software for DSP and Loading Flash Memory support the first use. A section on Using Flash Memory as a Non-volatile Data Memory is also included.

4.3.1 ROM Based Software for DSP

DSP software which operates out of read-only memory (ROM) is different from software which is down loaded from a host like the PC. The principal difference is in how it is linked. A ROM based program must be used to allow the flash memory to act as a boot load for the DSP.

When the DSP boots up in ROM boot mode, it transfers 64K bytes of data into internal memory and begins execution of the program at the beginning of the 64K byte block. For small programs, this is satisfactory for the main program and support routines. The boot loader can use either 16-bit words or 32 bit words so that either the 1/2 megabyte flash option or the 1 megabyte flash option is satisfactory for the boot loader.

For larger programs, which typically run in the external SDRAM memory, the first 64K bytes of the boot program must include a loader program which copies the code from the flash to the external memory. If this is placed in the beginning of the main program, then the code that runs before main, main itself and any subroutines used before the loader must be in the first 64K bytes of the code. For C programs, the code that runs before main includes boot.obj and INIT section. (The INIT section could remain in the flash and not be transfered to RAM at all.) The link editor should be instructed to locate this part of the program to be copied from the flash to the external memory address space while the first 64K bytes should remain located in the on-chip RAM.

4.3.2 Loading Flash Memory

The flash memory can be loaded with software in the PC host through the HPI interface, or the flash memory can be loaded by the DSP. The steps necessary to load the program code from the PC are:

1. Prepare a ROM based DSP program for loading with the link editor. (The link editor produces a ".out" file).

2. Mount any SPROM with any FPGA program that supports flash access on the daughterboard.

3. Mount the daughterboard on the EVM board and place them in a PC.

4. Execute a PC program that performs the following actions:

a. Use the appropriate COEF load call to download the ".out" file containing the ROM based DSP program into EVM/DSK RAM. This will format the program in memory image.

b. Read the words or half words of code (depending on the memory option) from the RAM.

c. Writes the flash commands and the code words into the flash memory. The address of the flash corresponds with the boot load memory area which varies from board to board and with memory map options. The flash load commands are found in the data sheet for the AMD AM29F400B.

5. Use the disassembly option in Code Composer Studio to verify that the code has been loaded in the flash memory.

6. Set the necessary switches to initiate boot loading for the DSP.

The steps necessary to load the program code from the DSP are:

1. Prepare a ROM based DSP program for loading with the link editor. (The link editor produces an ".out" file).

2. Mount any SPROM with any FPGA program that supports flash access on the daughterboard.

3. Mount the daughterboard on the EVM board and place them in a PC.

4. Use Code Composer Studio to download the ".out" file containing the ROM based DSP program into EVM/DSK RAM. This will format the program in memory image.

5. Download and execute a DSP program in a different part of RAM that performs the following actions:

a. Read the words or half words of code (depending on the memory option) from the RAM.

b. Write the flash commands and the code words into the flash memory. The address of the flash corresponds with the boot load memory area which varies from board to board and with memory map options. The flash load commands are found in the data sheet for the AMD AM29F400B.

6. Use the disassembly option in Code Composer Studio to verify that the code has been loaded in the flash memory.

7. Set the necessary switches to initiate boot loading for the DSP.

4.3.3 Using Flash Memory as a Non-volatile Data Memory

Flash memory may be used as a non-volatile memory for DSP data. This is useful in both stand-alone operation of the EVM/DSK as well as PC hosted operation. This use may be combined with use of the flash for boot program storage.

Reading the flash is no different from any other data memory read. The flash occupies the first 1 million bytes of the expansion memory space. The address of this space depends on the DSP memory mode used (0 or 1). The FPGA configuration used must support flash operation. The 1/2 megabyte option uses lower half words of 16-bit data. The full 1 megabyte option uses full 32 bit words.

Writing data to the flash is a more complex matter. When a write memory operation to the flash is initially executed, the flash assumes that it is in the program mode. Commands must be sent to the flash to tell it what data to erase and where to write new data. Once the write command is issued, then the data is transferred to the flash with write memory operations. Thus a flash write operation must precede the data with a command string to start. See the AMD AM29F400B data sheet for details of the commands.