For cost comparison, many different aspects must be considered. The costs for deep submicron ASIC designs are continuously increasing.
Today, the cost for the development, layout, backend, test and production of such a solution easily ramps up to several million dollars. A dominant development cost factor is in the layout and mask generation. In addition, the time consuming qualification of the chip for 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.
Modern SDR platforms integrate dedicated hardware components to reduce the processing load of the DSPs. Especially software unfriendly functionalities like Turbodecoder or Viterbi decodes that are built as coprocessors or dedicated hardware blocks.
When contemplating other costs in the development cycle, the situation may appear similar and comparable. The system development and verification effort, with respect to all defined test and use cases, do not vary significantly among hardware or software-centered developments. Software-based solutions must be validated with the same care as hardware developments. The main difference is the point in time in which this extensive and expensive validation becomes relevant. For a pure hardware design, all validation and tests conclude at time of the silicon production, with a limited option of fine-tuning of the intended functionality. In the case of a software development, the hardware is already available, and the validation can be performed at the end of the development process. This appears as an advantage, but it is only a shift within the development schedule, which requires careful overall planning.
Challenges of SDR development
One advantage of the SDR design flow is the flexibility to combine software modules and map them into a family or roadmap 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 efficient as possible.
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. The workload of the different applications may vary heavily over time. There are phases where hardly any workload is required, while in another timeslot heavy peaks of computation and memory access are encountered. As the peaks of different applications are by definition uncorrelated, this can result in overload conditions, and, in the case of radio applications, cause a short signal's loss. 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.
A suitable strategy to overcome these implementation challenges is to build in mechanisms to separate essential real time tasks from second order tasks. This generally helps to stabilize the system and handle conflicts to access internal resources and leaving enough headroom for unexpected scenarios.
Although the topic is broad in nature, I do appreciate the effort to highlight some of the implementation architectures. Great way to enlighten us!
However, was the goal to constraint the discussion to the physical layer implementation?
Lifewingmate, brought a good comment regarding the application layers were SDR shines and provides features that a strictly fixed or programmable hardware solution cannot.
I wonder if software-defined radio can sync with social media and become interactive with the use of applications and smartphones. Is XM radio a form of this popular technology? Would Pandora, Grooveshark, and other songlist/station builder software pieces empowering the continued design of smart software-defined radios? This is an interesting article and I'm interested to hear more about the salabilitly challenges which drive the demand.
Nice to our colleagues in Iraq joining in the discussion.
I think C Davis identified the biggest challenges for SDR in consumer products: cost, power and size. SDR makes much more sense for military applications, where there are so many different waveforms to support and legacy radios to emulate.
Dear Editor... I need to thank the authors of this paper.. I faced the problem of SW defined Radio at the begining of my Phd at 1981. Since that time many scientists facing such challenges, due to many big problems in designing and implementations of the normal transceivers in any specified frequency band or specified applications. What really facing us now after such long period (more than 30 years!), what is really the main challenges for such direction of Radios?.. I think such aspect needs more discuissions.
Dr. Eng. Sattar B. Sadkhan
Chairman of IEEE IRAQ Section
University of Babylon - Computer Technology College
Itís a good technology for the military (and is deployed heavily). I looked at starting up a company to do this in 2003. For the commercial/consumer space, my estimates indicated that SDR always consumes more power and space (i.e. cost) for 3 and less radios. This is a killer for consumer type devices. With life spans of devices of 24 months or less, the additional flexibility doesnít have much perceived value. If we come up with a use case where we have 5+ radios that can be time sliced, it would likely make sense.
I would say Spectrum Sensing Reallocation Strategy would by far be the most powerful of the use cases. Could lead to a stage where spectrum auctions would need to include usage stats rather than selling chunks.
Fairly high level.. SDR as a concept is great but when trying to meet timing requirements on several of the new technologies, it requires a lot of tweaking and in some cases might just not apply.. Discussion on implementation details of a design might help the audience more
Software defined radio continues to be a hot topic with its best applications still up for debate. Sound off here in the comments on what you think the future is for SDR, or if you have questions for the authors.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.