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.