SDR: Implementation Challenges

A software-defined radio (SDR) is a radio communication system where components that have been typically implemented in hardware (eg, mixers, filters, amplifiers, modulators/demodulators, detectors, etc) are instead implemented by means of a software on a personal computer or embedded computing devices. While the concept of SDR is not new, the rapidly evolving capabilities of digital electronics render practical many processes which used to be only theoretically possible.

Basic SDR system may consist of a personal computer equipped with a sound card or other analog-to-digital converter, preceded by some form of RF front end. Significant amounts of signal processing are handed over to the general-purpose processor, rather than being done in a special-purpose hardware. Such a design produces a radio which can receive and transmit widely different radio protocols (sometimes referred to as a waveforms) based solely on the software used.

More than Just Implementation

It is more than just an implementation in a software solution. It means the hardware platform obtains its functionality only when the software and the hardware development is independent, but it is influenced by the software development. The concept relies on the split between a suitable hardware platform and a suitable set of functionalities to be implemented on the platform.

Today, the cost for the development, layout, test, and production of deep submicron ASIC designs easily are continuously increasing. A dominant development cost factor is in the layout and mask generation. In addition, the time-consuming qualification of the chip for an automotive grade, for example, is required for each and every chipset product. Again, this increases the overall cost of such solutions. If hardware-related costs are shared among many applications, a significant cost advantage for SDR platforms can be achieved.

A dedicated hardware design does not allow for such sharing of resources, but the design can be optimized more aggressively for the intended use cases. This may reduce the silicon area and the power consumption, especially for portable and mobile applications running on battery supply.

One advantage of the SDR design flow is the flexibility to combine software modules and map them into a family of the SDR platforms of a given vendor. Developments based on such platforms show that the implementation on a selected platform represents a challenge. Because each platform has different features and needs and radio applications are real-time, we can use special programming tricks to achieve the best performance. In addition, the internal memory is limited and does not provide for extensive data buffering, making it necessary for the processing of the data to be scheduled as efficiently as possible.

Challenges

Several tasks or applications must run in parallel within the real-time constraints of the software implementation included in the data transfer to and from each executed task. Leveraging such parallel executing modern SDR platforms includes several processing elements (DSP, hardware accelerators, interface modules, etc), running concurrently. The challenge is to balance the load of required data processing and memory access to avoid conflicts in the processing pipelines. Normally the bottlenecks of such platforms are internal buses, which transfer the data from one module to the next or to an external memory or interface.

In the case of different applications, which are running independently on the same device, it is necessary to solve another aspect of the functional scheduling. There are phases where hardly any workload is required, while in another time slot heavy peaks of computation and memory access are encountered. For a real-time application, this leads to dropouts, which may be visible or audible. Technical and cost limits often do not allow dimensioning a platform for all worst-case scenarios. To avoid processing overload of the platform, the software implementation should monitor the overall required resources.

Complete testing may become almost impossible, as the number of testing scenarios may far exceed the envisioned testing capabilities and time. The parallelism of independent processors running on the same platform is also a challenge for the scheduling of bus transfers. In principle, the same difficulties encountered for the workload have to be solved