Many applications in DSP baseboard may involve communication with the host CPU in some manner. They may have to interact with a host program during the lifetime of the program. Some examples are:
• Passing parameters to the program at start time.
• Receiving progress information and results from the application.
• Passing updated parameters during the run time of the program, such as the frequency and amplitude of a wave to be produced on the target.
Fig. 3.2: Block diagram of Quixote (from [23]).
• Receiving alert information from the target.
• Receiving snapshots of data from the target.
• Sending a sample waveform to be generated to the target.
• Receiving full rate data.
• Sending data to be streamed at full rate.
There are three transfer methods on Quixote, which are DSP streaming interface, CPU busmastering interface, and packetized message interface. The following text is mainly taken from [15].
3.2.1 DSP Streaming Interface
The DSP streaming interface is continuous block based streaming transfer. It is designed for non-stop operation such as A/D and D/A.
The DSP streaming interface is bi-directional. Two stream can run simultane-ously, one running from the analog peripherals through the DSP into the application.
This is called the “incoming stream.” The other stream runs out of the analog pe-ripherals. This is the “outgoing stream.” The mechanism is shown in Fig. 3.3. In both cases, the DSP needs to act as a mediator, since there is no direct access to analog peripherals from the host. This arrangement allows the DSP to process the streams as they move from the application to the hardware.
3.2.2 CPU Busmastering Interface
This method of target-to-host communication is on the Velocia baseboards only. The TI 64x baseboard is capable of using PCI busmastering to move data between target and host memories. This additional busmaster channel can be used to transfer data between host and target applications.
Fig. 3.3: DSP streaming mode (from [15]).
The CPU busmastering interface is packet based transfers which transfer discrete blocks between source and destination. Each data buffer is transferred completely to the destination in a single operation. The data buffers transferred can be of different sizes. Each requested buffer is interrogated for its size and fully transmitted. At the destination, the destination buffer is re-sized to allow the incoming data to fit.
Reallocating buffers can take some time, for best performance buffers should be pre-sized to be large enough for the largest transfer expected.
CPU busmastering uses a simple blocking interface for its sending and receiving functions. The sending function will not return until the transfer has completed and the buffer is ready for reuse. Similarly, the receiving function waits until data have arrived from the data source and transferred into the data buffer before returning.
Since the transfer functions are blocking, they are best avoided in the main user interface thread of a Windows application. The GUI will appear to be frozen until the transfer has completed. For best results, the data transfer function should be
placed in separate threads in target and host applications. In fact, each direction of transfer should have its own thread, so that the two directions of transfer can interleave as much as possible.
The CPU busmastering interface allows separate channels of data between the target and the host. Using separate channels allows multiple, independent data streams to be maintained between the target and host. At present, only a single channel is supported. The largest transfer allowed is half of the total size of the DMA buffer allocated by the INF file (a kind of files used for software/firmware installation in windows system) when the driver is installed. Half of the memory is dedicated to each direction. The default buffer size in the INF is 0x200000 bytes, so the maximum transfer block is 1 MB.
3.2.3 Packetized Message Interface
In addition to the busmastering streaming interface, the DSP and host have a lower bandwidth (limited to about 56 kB/sec) communications link for sending commands or out-of-band information between target and host. Software is provided to build a packet-based message system between the target and host software. These packets can provide a simple yet powerful means of sending commands and information across the link between the two processes.
As shown in Fig. 3.4, the message system’s arrangement provides one bi-directional link between the target and the host. The “CIIMessage” and “IImessage” are host and target side message objects declarations respectively. The detailed contents of the packet formatting are shown in Table 3.1. The “CIIbaseboard::OnMessage” and
“Unsolicited Message Handler” are the messages handler used to handle the mes-sage when mesmes-sages are received for host and target sides respectively. The “Post”
function is just used for sending the message out.
In this study, we use the methods of CPU busmastering and message interface for
Fig. 3.4: The message system (from [15]).
Table 3.1: Message Packet Formatting (from [15]) Function Name Property
Channel Message Channel
TypeCode Message or Command type
MessageId Message counter or other user data
IsReplyExpected Set if reply is needed. Free for use in application Data[ ] Access the data region as 32-bit integers (index 0–13) AsFloat[ ] Access the data region as floating point data (index 0–13) Asshort[ ] Access the data region as 16-bit integers (index 0–27) AsChar[ ] Access the data region as 8-bit characters (index 0–55)
communication between the host and the target. The CPU busmastering interface provides higher bandwidth for data transmission. But the disadvantage is that only one channel is supported. Packetized message interface supports sixteen channels in each direction. But the bandwidth is limited to 56 kB/sec.