The Software Communications Architecture (SCA) was developed to standardize the development of Software Defined Radio (SDR) technology; enhancing system flexibility and interoperability, while reducing development and deployment costs. Early implementations of SCA SDRs have struggled to meet performance, cost, size, and power requirements. Arguably, because of their dependency on General Purpose Processor (GPP) to perform all signal processing.

In this project, we are trying to reduce the dependency on GPPs by using specialized hardware optimized for signal processing, Digital Signal Processors (DSP), which have been relegated as secondary elements in the SCA. This implementation is possible thanks to improvements in development tools and middleware technology. This approach brings together the flexibility and reusability of the SCA and the cost and power efficiency of DSPs. For certain systems, this approach could eliminate the need for a GPP in the implementation.

In this project, we leveraged the existing implementation of MPRG's Open Source SCA Implementation:: Embedded (OSSIE). The general software structure can be seen in Figure 1, the SCA Operational Environment (OE):

Figure 1: System Structure

Our Operating System is DSP/BIOS is a scalable real-time multitasking operating system designed specifically for the TMS320 family of DSPs. It is developed and maintained by Texas Instruments. It supports preemptive multithreaded operations via a real time scheduler and provides memory management modules for low overhead dynamic memory allocation. DSP/BIOS is not POSIX compliant. For more information on DSP/BIOS visit: DSP/BIOS Website

The ORB used in this project is PrismTech's e*ORB SDR C++ version for DSP. This is a custom port of their commercially available C version, a very optimized, modular implementation of minimum-CORBA.  Prismtech has released this version to the general public. e*ORB supports the Extensible Transport Layer (ETF) which allows custom transport plug-ins.

The target platform for this project is the SignalMaster Quad C6416 from Lyrtech. This high performance board contains four TI TMS320C6416T DSPs and two Xilinx Virtex II FPGAs divided into two clusters (one FPGA and two DSPs each). The system runs at 720 MHz and has 128Mbytes of SDRAM memory per DSP. 

Porting to the C64 Platform

The original OSSIE runs on an x86 platform running Linux with omniORB as middleware. We have to port it to the C64 platform running DSP/BIOS with e*ORB as middleware

We use Code Composer Studio (CCS) version 3.1  with Code Generation Tools version 5.1.0. This particular version lacks the Standard Template Library (STL) and has limited support for C++ exceptions. The C64 platform does not feature a Memory Management Unit (MMU). The MMU is responsible for handling memory access requests. It takes care of virtual memory management, paging, memory protection, and bus arbitration. In OSSIE C64 all memory management is the responsibility of the developer and certain OS calls, such as fork(), are not supported. Because of the preemptive nature of DSP/BIOS scheduler, task scheduling and priority assignment are developer's responsibility too.

XML Parsing Strategy

The SCA specification requires the reading of the XML Domain Profile at runtime which  is a complicated task for a DSP. In order to facilitate development, reduce memory requirements, and speed execution, we developed a two-step parsing scheme. In this scheme, an offline translation of the XML files into a simplified format is performed.  A graphical representation of this approach is shown in Figure 2. It can be argued that this approach is not SCA compliant. However, having this two-step parsing does not affect the design cycle of traditional SCA waveforms and only adds one extra step at installation time. The savings in time and complexity, along with the uncompromised portability of the resulting waveforms justify this decision.

Figure 2: Two-Step Parsing Strategy

Sample Waveform

The framework functionality is demonstrated by deploying two sample waveforms. These waveforms are intended for demonstration purposes only. There is no extensive signal processing.

The first application includes three simple components: BPSK Modulator, Channel, and Demodulator. The BPSK modulator generates a random stream of 1's and -1's. The stream is passed to the Channel component which adds Gaussian noise to the In-Phase and Quadrature components of the stream. The Demodulator only displays the constellation diagram of the signal. The second waveform includes a QPSK demodulator instead of BPSK. Figure 3 shows a graphical representation of both waveforms.

Figure 3: Sample Waveforms