With their multi-gigabit transceivers, multiplier arrays for parallel signal processing, and reconfigurable logic, Xilinx® Virtex™-II Pro and Virtex-4 FX FPGAs serve as ideal platforms for building flexible and costeffective software-defined radios (SDRs). For instance, by supporting partial reconfiguration – the ability to configure or reconfigure a portion of an FPGA on the fly – these FPGAs allow a single set of processing resources to support multiple waveforms concurrently. System designers can, as a result, eliminate redundant per-channel hardware and reduce power consumption in their SDR devices.

Until recently, the CPU in most SDR designs existed as a discrete component that communicated with the FGPA fabric over a high-speed interconnect. The Virtex-II Pro and Virtex-4 FX devices take a different approach, immersing high-performance PowerPC™ cores directly into the FPGA. This approach not only provides high-speed access ports between the CPU and the FPGA fabric, but also lowers the component count and frees up board space.

Just as important, the embedded PowerPC cores allow SDR designers and software engineers to leverage an array of standards-based, off-the-shelf RTOSs and tool chains, such as the QNX Neutrino RTOS and QNX Momentics development suite.

The term “software” in SDR can be misleading at first. It suggests a device in which software running on the CPU handles functions such as signal generation and detection, modulation and demodulation, encryption and decryption, and signal frequency selection. In reality, most such functions run on signal processors in the FPGA fabric.

Nonetheless, SDR devices must still rely on CPU-based software to download and manage new waveforms for the signal processors, handle voice capture and playback, manage information displays, and coordinate numerous other command and control tasks. Given the complexity and dynamic nature of the typical SDR device, this software must offer a robust mix of reliability, upgradability, and realtime performance. In this article, we’ll explore how the QNX Neutrino microkernel RTOS helps system designers and software engineers achieve these qualities, while significantly reducing development time and effort.

Making the (Up)grade
With Xilinx FGPAs, you can achieve a key objective of SDR: a single, reconfigurable hardware platform that can dynamically adapt to a variety of radio environments. Yet that goal is defeated, or seriously diminished, if the system software running on the FGPA’s PowerPC core doesn’t provide an equivalent measure of upgradability and reconfigurability.

Unfortunately, such dynamic requirements pose a serious challenge to conventional RTOSs. The problem springs from traditional embedded design, where software typically remained stable, with little or no change, over a product’s entire life cycle. Having been created for such products, most RTOSs still reflect the old reality. Consequently, deployed systems cannot easily be maintained, upgraded, or extended unless removed from service.

To address this problem, QNX Neutrino uses a true microkernel architecture (Figure 1). Microkernel RTOSs have two defining characteristics – both critical to building a dynamic and reliable SDR device:

1. The OS kernel contains only a small core of fundamental services, such as timers, messages, and scheduling. All higher level services and programs – drivers, file systems, protocol stacks, and user applications – run outside the kernel as separate, memory-protected components.
2. Most software components communicate through message passing, a welldefined communication mechanism that allows programs to exchange data while remaining safely isolated from each other.

Web Services
With QNX Neutrino’s virtual software bus, SDR devices can operate nonstop, even when being upgraded with new waveforms, applications, drivers, or other software components. Nevertheless, one question remains: When a server makes a new waveform or service available, how do remote SDR devices actually discover that component and learn how to use it?

To discover and activate new waveforms and filters, SDR devices can use Common Object Request Broker Architecture (CORBA) middleware. In fact, the U.S. Department of Defense (DoD) mandates the use of CORBA for this purpose in its Joint Tactical Radio System (JTRS) program. An example of CORBA middleware is Objective Interface’s ORBexpress, a highly efficient, real-time implementation that can run on QNX Neutrino.

Designed to let heterogeneous systems interoperate with one another, CORBA provides distributed processing in a single enterprise and over a closed network, and is well-suited to waveform provisioning. However, its inability to readily traverse Internet firewalls makes it unsuitable for accessing higher level services over a wide area network (WAN), such as the Global Information Grid (GIG) envisioned by the DoD. In net-centric operational warfare (NCOW) systems, for instance, multi-function field radios must access new tactical information services through the GIG as those services become available. For such applications, QNX’s implementation of Web services offers an ideal solution (Figure 2).

Web services offer full access to Web capabilities (such as the uniform resource identifier [URI] for accessing remote resources) and can work with various security protocols, including HTTP-S and IPSec with strong encryption. Web services are also firewall-friendly – through their well-defined transport binding to HTTP, they can use existing Internet security protocols and be accessed from anywhere on the Internet. And because Web services are based on open standards such as XML, SOAP, WSDL, HTTP, and UDDI, they provide a vendor-neutral, language-independent, and platform-independent method of accessing remote services and data.

Put simply, Web services can span multiple enterprises over a WAN and eliminate the complexities of firewall traversal, allowing a JTRS radio to access services on a GIG that has high levels of VPN security and routing.

To help you take advantage of Web services, QNX has developed a Web services technology development kit (TDK). Using this TDK, embedded developers can implement WSDL, SOAP, and XML-based Web service applications in native C or C++ without having to deal with the complexity of XML and protocol transformations. Moreover, the TDK conforms to the Web Services Interoperability Organization (WSI) Basic Profile 1.0. Applications developed with the TDK can therefore interoperate with other standards-based implementations, such as Microsoft .NET. Just as important, QNX designed the TDK to meet the tight resource constraints of SDR devices and other embedded systems.

Mission: Critical
For most SDR devices, reliability is an absolute must. There is little or no tolerance for any software fault that can defeat the device’s main purpose: signaling. If for some reason a software fault does occur, the device should recover from it gracefully, without a system reset.

This requirement poses a challenge to conventional OSs, which bind most system services (drivers, file systems, protocol stacks) to the OS kernel. With this approach, a single coding error in any system service can corrupt memory used by other services or by the kernel itself, causing system-wide failure.

In comparison, a microkernel OS like QNX Neutrino runs all such services outside of the kernel as separate memory-protected components. This architecture offers two key reliability benefits. First, it makes it much easier to isolate and correct coding errors before the errors can make their way into a deployed system. For instance, if any service or application under development attempts to access memory outside of its process container, the OS will identify the process responsible, indicate the location of the fault, and create a process dump file viewable with source-level debugging tools. The dump file can include all of the information the debugger needs to identify the source line that caused the problem, including a history of function calls, contents of data items, and other diagnostic information. Compare this to a conventional OS, where such errors can crash the entire system without leaving a trace of the cause.

Second, microkernel architecture enables dramatically shorter mean time to repair (MTTR). Consider what happens when, for example, a driver faults in a deployed system: the OS can terminate the driver, reclaim the resources the driver was using, and then restart it, often within a few milliseconds. From start to finish, the entire procedure can be orders of magnitude faster than the conventional solution, which is to reboot the entire system.

The process is made even simpler by QNX’s critical processing monitoring technology, which employs “heartbeating” to detect problems before they escalate and allows you to specify the exact recovery actions the OS should follow (Figure 3).

The Real Benefits of Real Time
As a true RTOS, QNX Neutrino offers the hard real-time capabilities needed to coordinate multiple concurrent SDR applications and services. It can, for instance, handle command and control programs, map-based tactical displays (in a JTRS radio), multiple modulation and encryption schemes, and various other applications, while ensuring that time-critical tasks (such as transmission of voice packets between the host processor and a signal processor) always occur in a timely and predictable manner.

To enable this predictable behavior, QNX Neutrino offers numerous features, including a priority-based preemptive scheduler, a preemptible kernel, nested interrupts, mechanisms to avoid priority inversion, and a flexible choice of scheduling algorithms. Together, these features help you ensure that high-priority threads meet their deadlines consistently, no matter how many other threads are competing for CPU time.

Allowing a single set of resources to support multiple waveforms is a key advantage of Virtex-II Pro and Virtex-4 FX FPGAs. Likewise, a mature RTOS like QNX Neutrino allows you to maximize processor resources while minimizing overall cost. There is no need to adopt an expensive high-end CPU, along with its attendant thermal dissipation issues, to achieve the necessary processing capacity. Moreover, QNX Neutrino’s real-time capabilities offer greater design flexibility: you have the option to move applications from a DSP to the host CPU or vice versa. With a general-purpose OS, any tasks with real-time constraints have to be delegated to a DSP.

Bred in the Bone
SDR holds the key to dealing with multiple evolving transmission standards. But for a time, SDR was itself in need of common standards that could ensure software reusability and interoperability across various SDR platforms. To address the problem, the DoD’s JTRS Joint Program Office (JPO) developed the Software Communications Architecture (SCA) and has mandated its use for all JTRS development projects. The Software Defined Radio Forum has since adopted the SCA, while the Object Management Group (OMG) plans to promote it as a commercial standard.

To ensure waveform portability and compatibility with commercial off-theshelf (COTS) technology, the SCA defines an operating environment based on two existing industry standards: CORBA middleware and a Portable Operating System Interface (POSIX) operating system.

QNX Neutrino represents an ideal operating system for SCA implementations. To begin with, it complies with POSIX 1003.1- 2001 and features an extensive set of POSIX options, including real-time extensions and threads. This not only satisfies SCA requirements, but makes it very easy to port Linux, Unix, and other POSIX-based open-source programs to QNX Neutrino’s highly efficient real-time architecture. Just as important, the QNX Neutrino microkernel was designed from the beginning to support POSIX – POSIX is “bred in the bone.” Such an approach obviates the need for a complex POSIX adaptation layer used by other OSs, resulting in greater performance and lower memory requirements.

In addition, this robust POSIX support greatly simplifies the task of porting any real-time CORBA implementation, such as ORBexpress, to QNX Neutrino. This is key, as real-time CORBA provides the framework that allows SCA-compliant devices to dynamically learn new waveforms.

Conclusion
Working closely with Xilinx, QNX Software Systems has developed board support packages (BSPs) for the Virtex-II Pro ML300 evaluation platform, the ML310 Virtex-II Pro development platform, and the ML403 Virtex-4 FX evaluation platform. These BSPs are compatible with the version 6.3 of the QNX Neutrino RTOS and eliminate software/hardware integration issues, allowing you to immediately begin application development.

For more information about these BSPs, or how QNX Neutrino can help enable your SDR project, visit www.qnx.com, or call QNX at (800) 676-0566 (in North America) or +1 (613) 591-0931.

Printable PDF version of this article with graphics.  (9/1/05) 350 KB