COTS Software-Defined Radio And SCA Compliance

The SCA Core Framework (CF) connects the SCA-compliant waveforms with the SCA-compliant hardware within the JTRS radio set. This allows the platform developers who produced an SCA-compliant radio set and the waveform developers who independently generated SCA-compliant waveforms to expect that the waveforms will function properly with the radio hardware.

SCA Operating Environment
The SCA Operating Environment (OE) is shown in Figure 2. It basically depicts all the layers of the software and how they interact.

Figure 3 illustrates an expansion of the OE components. These components consist of the CF, the OS, the Board Support Package (BSP), the Common Object Request Broker Architecture (CORBA), the Object Request Broker (ORB), and the Network Services. The SCA recognizes the need for separating the black or secure components of an application from the red or nonsecure components. So what we have here are basically two parallel and complete OE sets that exist in the same application to support both black and red components of the system.

Figure 3. Detailed Breakdown of SCA Operating Environment
Click here to see larger image

Core Framework
The SCA specification defines the CF as the essential core set of open application layer interfaces and services. It provides an abstraction of the underlying software and hardware layers for software application designers.

The CF includes the base application interfaces that can be used by all the software applications and the framework control interfaces that provide system control: the Domain Manager, the Device Managers, the Framework Service that supports core and non-core applications, and the Domain Profile that describes the properties of the hardware devices and the software components of the system and domain profiles. These are written in eXtensible Markup Language (XML), which actually is a protocol used for web design and a number of software development applications.

Operating System
The OS layer is defined by SCA to include real-time embedded OS functions that provide multithreaded support for applications including the CF applications.

The architecture requires a standard OS interface for OS services to facilitate portability of applications. The OS must comply with the Portable Operating System Interface (POSIX), an established industry standard. The SCA uses a small subset of the POSIX definition, specifically the real-time controller system profile.

Board Support Package
The BSP, basically the last layer, is the closest to the hardware functionality of the actual hardware platform. The SCA specification allows for operation on commercial bus architectures, so the operating environment can support reliable transport mechanisms. These may include error checking and correction at the bus support level. Possible standards are VME, PCI, CompactPCI, Firewire, and Ethernet.

Again, the SCA operating environment recognizes the use of red and black components of the system. In Figure 3, you can see that there are two different sets of BSPs, one for each side of the application.

CORBA ORB Middleware
As a message-passing technique, CORBA is used for distributive processing throughout the software environment. Distributive processing is a fundamental aspect of the SCA specification, and CORBA is a widely used middleware for cross-platform frameworks. These cross platforms can be used to standardize client and server operations when using distributive processing.

All CF interfaces are defined in Interface Definition Language (IDL) that is independent of programming language and can be compiled into programs created in C++, ADA, or Java. The SCA IDL defines operations and attributes that serve as a contract between the components.

Network Services
The SCA specification calls for Network Services that allow commercial components to support multiple unique serial and network interfaces. As a result, possible serial and network physical interfaces include RS-232, RS-422, RS-423, RS-458, Ethernet, and 802.11 wireless protocols. To support these interfaces, low-level network protocols may be used including point-to-point (PPP), serial line Internet protocol (SLIP), and others.

Elements of waveform networking functionality also may exist at the OS level. An example of this would be a commercial IP stack that performs routing between waveforms.

SCA Applications
The Applications group in Figure 3 includes functions such as modem-level DSP, link and network protocols, I/O access, and security services. The applications must use the CF Interfaces and Services and consist of one or more Resources. The resource interface provides a common Applications Programming Interface (API) for the control and configuration of software components.

The various hardware elements of a SCA-compliant radio are referred to as Devices, and they can include general-purpose processors (GPPs), A/Ds, D/As, digital receivers, upconverters, field-programmable gate arrays (FPGAs), DSPs, and other types of equipment.

From a software point of view, the software proxies that act to interface to the hardware also are referred to as Devices. This may be a little confusing, but in the overall theme it does work since all communications to the underlying hardware must flow through these structures.

Devices are divided into four classes. Simple elements like A/D and D/A converters that require basic control monitoring and data connections are called Devices. More complex elements like GPPs capable of accepting and executing program code are called ExecutableDevices.

An FPGA is capable of performing a signal-processing function, but typically it cannot really execute program code although embedded PowerPC cores in the FPGAs can do some execution. In general, FPGAs first must be configured for a particular task, so they�re called LoadableDevices.

The fourth class of a Device is a combination of Devices, so it�s termed the AggregateDevice. An example of this class would be a board that contains both A/Ds and FPGAs.

Adapters
Adapters are Resources or Devices used to support non-CORBA-compatible elements in the domain. For that reason, Adapters provide that translation between the non-CORBA-compatible component and the CORBA-compatible resources.

Since an Adapter implements the CF CORBA interface known to other CORBA-compatible resources, the translation service should be transparent to the CORBA-compatible resources. Some examples of Adapters are modems, security I/O, and host processing elements.

FPGA Technology in Software-Defined Radios
FPGAs are a crucial part of many SDR systems due to the outstanding performance they provide. While dynamic loading and control of FPGAs still are not mature parts of the SCA specification, FPGAs can be preconfigured to extend the hardware performance and functions of a system component outside the SCA specification. Some of their key advantages include the following:

� Replacement for Interfacing and Glue Logic: The FPGA flexible I/O pins can mimic various logic levels to implement a wide range of high-performance interfaces to components, buses, memory devices, and communications ports.
� Control Structures: The FPGA includes specialized hardware structures such as synchronous DRAM controllers for target memories. An advanced dual-clocking, timing, and synchronization system built into the FPGA logic simplifies data acquisition and timestamping and supports multichannel operation.
� Custom Signal Processing: The FPGA also provides custom signal processing afforded by its DSP structures such as block RAM, hardware multipliers, and logic slices. You can add your own IP or install commercial off-the-shelf (COTS) IP for specialized tasks. This often saves months of development time and offloads signal processing chores from other processors in the system. In this role, this newly acquired function of the FPGA often is fixed during deployed operation.
� Reconfigurability: In this role, the FPGA often is reconfigured during system initialization or run time, based on the current needs of the application. Here is where FPGAs will further extend the scope of software-defined radios.
� PowerPC Processors: The on-chip PowerPC processors can be equipped with an OS and programmed to execute C code. Since the processors are surrounded by a wealth of device interfaces, memory, and real-time signal processing hardware, they may not be allocated as freely as a generic processor within a pool of GPPs. However, these immediate resources could be extremely efficient for data flow and real-time processing tasks.

Build vs. Buy Trade-Offs
The usual factors in the decision to build vs. buy still apply, but we have to consider an additional set of variables when looking at the various software layers and tools needed for SCA systems. These are some of the trade-offs to look at when you�re either building or buying a hardware component for such a system.

Buy Advantages
� The product probably is or soon will be available off the shelf.
� COTS vendors are competitive so there�s always pressure on them to keep their prices low.
� You have the option to buy similar products from an alternate source should there be a problem with the prime vendor.
� Very often a vendor�s product line will include multiple versions of a product introduced over a number of years with the latest technology in each version.
� The latest software technology should be available with the minimum effort if the APIs, the BSPs, and the drivers were written with a long-term goal in mind.

Buy Disadvantages
� The hardware most likely is not an exact match for the system specifications, or in some cases, there may be no real perfect fit with a COTS product. In this case, you may have to reduce or change the system spec to match the hardware available.
� Software could need some work, especially if there�s an existing software application that needs to be ported to support the new hardware. This is where quality and complete BSPs and drivers from the vendor can minimize supporting efforts.

Build Advantages
� The biggest advantage is producing an exact hardware match for the requirements of your system.
� Similarly, if you know the software requirements at the time of hardware design, the hardware has a better chance of matching the software requirements and meeting an existing software spec or API.

Build Disadvantages
� If you�re not a hardware design and manufacturing business with the appropriate engineering resources in place, you can be affected by delays in availability of the hardware.
� You will run into development costs that may or may not be covered throughout the product life.
� The technology may expire, and component obsolescence always is a problem.
� The product can continue to require ongoing engineering for many years.

COTS Hardware for SCA
What requirements does a COTS vendor need to meet in an SCA-compliant software radio board design so that the product is flexible enough to satisfy custom, in-house development requirements?

A/Ds and D/As: Devices
The need here is flexibility of software-configurable clocking, gating, triggering modes, and any other mode of the A/D or D/A. The data paths must be configurable and high bandwidth data paths included to satisfy typical frequency requirements of software radio systems.

Other ASICs: Devices
Digital downconverters and upconverters also would be considered SCA devices. They, too, need to be fully programmable with the capability to be bypassed should the situation arise. As an example, consider a downconverter chip on a board that has a programmable decimation range consistent with most applications.

However, there are a few applications where the decimation isn�t low enough. In this case, the downconversion, with the proper decimation, may be performed in an adjacent FPGA using a downconverter IP core.

And while something like the ASIC downconverter can be an extremely useful asset to the overall processing, it�s not really consistent with the spirit of the SCA spec, which wants flexibility so it can address all applications. Again, having that chip as a bypassable resource is a way to use it when you need it or have it out of the way if it�s not needed for the job.

FPGA Resources: LoadableDevices
The next consideration is FPGA resources, which are classified as LoadableDevices. The processing power and flexibility of an FPGA are good fits for software radio systems. However, a key component to fully integrate the FPGAs into an SCA system still is missing. SCA is working to catch up to the technology and best incorporate the features of FPGAs into the specification. The FPGA connection to the rest of the system must be flexible and configurable.

Non-CORBA DSP and GPP Resources
Non-CORBA DSP and GPP resources also are considered LoadableDevices. GPPs can be considered Executable Devices in some applications, but here we are addressing items such as the embedded PowerPCs in a Virtex FPGA. In the case of processors, the executable code must be software downloadable�which should seem obvious.

Any peripherals needed to support the processor must be present. Again in the case of Virtex FPGAs, we�d expect to see the built-in processor core supported by external memory, a boot ROM, interrupt connections for some of the critical hardware, and programming paths that can be accessed so the PowerPC can be loaded, among other things.

About the Author
Rodger H. Hosking is vice president and co-founder of Pentek. Previously, he served as engineering manager and project engineer at Wavetek and Rockland Systems. In more than 30 years in the electronics industry, Mr. Hosking has authored hundreds of articles about DSP and The Digital Receiver Handbook. He holds a B.S. in physics from Allegheny College and B.S.E.E. and M.S.E.E. degrees from Columbia University. Pentek, One Park Way, Upper Saddle River, NJ 07458, 201-818-5900, e-mail: [email protected]

FOR MORE INFORMATION
on the Joint Tactical Radio System
www.rsleads.com/608ee-177
on SCA compliance for COTS SDR
www.rsleads.com/608ee-178

August 2006