The flexibility and enhanced performance offered by software-defined radios (SDRs) in RF transceiver applications is driving an increased demand for their use across many industries such as defence, telecommunications, aerospace and government. Coupled with the rise of 5G, it is no surprise that the projected global market for SDRs is expected to top $39 billion by 2027. As the market for SDRs grows, many engineering organisations are wrestling with the age-old question: build or buy? With SDRs, however, the answer is not straightforward.
Even with industry standards like SOSA (Sensor Open Systems Architecture) and CMOSS (C4ISR/Electronic Warfare Modular Open Suite of Standards) helping to move SDRs toward a single architecture while reducing size, weight and power consumption (SWaP), the flexibility promised by software keeps pushing technical and hardware requirements for SDR modules to handle ever-wider frequency ranges and increasingly complex protocols. SDRs, at their simplest, are complex digital circuits that provide a combination of radio frequency (RF), data conversion and digital signal processing. Building them has traditionally been difficult, but evaluating a commercial off-the-shelf (COTS) SDR is not easy either.
With numerous considerations and decisions needing to be made, the path to arrive at a final build or buy answer for an SDR can be complicated. This article explores these and other considerations throughout the RF transceiver development process to help decide which avenue is best suited to your needs.
Getting started with SDR development
It is easy to underestimate the amount of time and the breadth of technical skills required to develop an SDR for a particular use-case. The advances in both radio frequency integrated circuit (RFIC) and field-programmable gate array (FPGA) technologies have simplified the development process, but this does not mean that development is simple. It is not uncommon for companies to have the engineering talent to develop a flexible SDR transceiver on their own – the question is whether this is an effective and appropriate use of engineering resources.
For a summary of how much goes into SDR development, Figure 1 provides a high-level overview of the wide range of expertise required. To help make an informed decision on building versus buying, let’s look more in depth at the development effort and skills needed for each.
RF hardware engineering
The advancement of RFIC technology has single-handedly been one of the most enabling factors in recent years to facilitate SDR development. The integration of RF synthesisers as local oscillator (LO) sources, quadrature mixers, configurable baseband filters and data converters in a single chip helps to minimise the ‘black magic’ of RF circuit design. But even with these integrated RFICs, there is often a significant amount of RF engineering still required between the antenna and the digitised samples.
Low-noise amplifiers, RF filtering, careful power supply design, accurate reference clocks and more are still needed for a successful design that is ready to be used in the real world. It can be easy to assume that the RF performance of two solutions using the same RFIC will be identical when, in reality, the supporting RF hardware around the RFIC makes a significant difference. It also usually takes a few iterations of the RF hardware design to get to the desired level of performance.
Digital hardware engineering
In addition to integrating the RFIC hardware, there is a substantial amount of digital hardware engineering needed for SDRs as well. At the start of this process, a digital hardware engineer needs to make the following major considerations:
• FPGA device selection (almost all SDRs have an FPGA these days).
• Boot memory for the FPGA.
• Local compute element (CPU, memory, etc.).
• High-speed digital interfacing, which often reaches into the high GBps range.
• Power supplies, which need to be sized to support a wide range of operational scenarios.
These items must be decided on before you start developing the FPGA code necessary to do something meaningful with the digitised RF spectrum.
FPGA development
Field programmable gate arrays (FPGAs) play a central role in creating a flexible RF frontend within SDRs. They provide the high-speed, low-latency digital infrastructure needed to enable substantial amounts of processing and data transport. This all starts with the ability to interface to the high-speed analog-to-digital (A/D) and digital-to-analog (D/A) converters utilised on the SDR, which often requires management of high-speed parallel data buses or SERDES (serialiser/deserialiser) protocols such as JESD204b and JESD204c. The FPGA also manages the high rate of digitised RF spectrum that needs to be carried to a CPU for processing using a transport bus such as USB, Ethernet or PCIe.
Finally, lower-speed interface buses such as SPI and I2C are often managed through an FPGA to control hardware peripherals on the SDR. All these FPGA functions are required as part of the typical SDR infrastructure even before any actual signal processing takes place. In many cases, there is also application-specific signal processing that needs to happen in the FPGA.
Developing the software infrastructure
Once the steps are taken to create a flexible RF frontend with baseband A/D and D/A converters that interface to an FPGA with a high-speed transport up to a CPU, the real programming fun with the software stack can begin. There are multiple layers of software required as part of the SDR infrastructure to make this type of system work. An example software/FPGA stack is shown in Figure 2, based on Epiq Solutions’ SDR portfolio.
Figure 2. A typical SDR technology stack, based on Epiq’s software-defined radios.
At the lowest level, there are software device drivers that run in kernel space to interface with the transport bus supported by the FPGA. Since an SDR is often dependent on continuously streaming a high rate of digitised radio spectrum to the CPU where the core of the signal processing can take place, these kernel-space device drivers are critical in supporting efficient, high-rate data streaming between the FPGA and the CPU.
The next level above the kernel-space device drivers is a user-space API which is typically required to expose a control layer for the underlying hardware. This control layer is the foundation upon which all application-specific software is developed. It allows a user of an application to perform functions such as changing the RF centre frequency, reducing the RF receiver gain, setting the A/D converter’s sample rate, and starting or stopping streaming of the digitised radio spectrum to the CPU. These types of functions are usually included among dozens of other parameters that must often be exposed to application software. Each parameter needs to have its own set of underlying control functions, which are typically then split between user-space libraries, kernel-space drivers and the FPGA.
Of course, all this SDR-specific software may need to operate on a variety of different host operating systems and/or CPUs. This could include different versions of Windows or Linux, 32-bit vs. 64-bit operating systems, and all the other differences that come along with the host CPU where the software will run. Each option dictates the flexibility of the SDR, which ultimately impacts decisions that will ripple through the entire development lifecycle to the end application.
Design iteration to ensure optimal performance
Once all the above pieces of hardware and software are developed and integrated, it is time to ensure the radio performance meets the requirements of the application, which can often take multiple hardware design iterations as illustrated in Figure 3. After each iteration that does not result in the desired performance requirements or achieve the SWaP objectives, the process starts over. Each revision typically includes making subtle adjustments to the RF frontend and/or digital hardware to minimise interference and spurious signals.
Each hardware iteration typically requires a full cycle of schematic adjustments, PCB layout updates, PCB fabrication and assembly, before finally getting the latest iteration of the hardware back in your hands. This process can take eight to ten weeks – per iteration – beyond the application development and engineering time required to assess performance each time.
Functional test
Upon completion of the final design iteration, the SDR hardware will need to be functionally tested. Ideally, the development of the testing infrastructure is happening in parallel with the development of the SDR along the way.
Setting up an automated functional test environment to perform the necessary digital and RF validation of the SDR can be a significant undertaking. Performing functional testing requires additional hardware resources to develop the test pods for the SDR, software to control the RF test equipment such as the RF signal generators and spectrum analysers, and software to measure the performance of the SDR.
This testing and validation step is critical to ensure the quality of the SDR module itself, and often requires a team separate from the engineering team which is dedicated to supporting this type of test development.
Beyond development logistics
It is also important to note that simply having the technical capabilities to develop the hardware and software components is not enough. For many applications, RF engineers are constantly being asked to improve the SWaP of all components, and SDRs are no exception.
Having a requirement to optimise an SDR for SWaP can extend development time and further complicate many development stages of the build process for a couple of reasons. To begin, when building the SDR, the first iteration or two will generally be much larger than what is needed, resulting in additional time and effort required to reduce its size. Second, there are unique technical challenges associated with RF devices as size is reduced, that will require additional hardware cycles to be built in as part of the optimisation process. Careful part placement, component shielding and PCB layer stackup management can make a significant difference when it comes to the performance of the final solution.
Supply chain reliability and management
Managing component availability and lead times can also be an unforeseen obstacle when building a custom solution. For example, in 2018, the lead time for capacitors, a simple passive component, extended up to 50 weeks due to unexpected and unpredictable market forces including raw material shortages and increased tariffs on steel and aluminium.
Compounding these factors was the expansion of electronic technologies into new markets like electric vehicles (EV) and hybrid electric vehicles (HEV). EVs use a lot more capacitors than their gas-powered counterparts, so the global demand for most electronic components – and capacitors in particular – increased, which resulted in a supply shortfall.
More recently, the semiconductor industry has seen a surge in component lead times from RFICs to FPGAs to simple passive components such as inductors. Given the current shortage of components, minimal availability of raw material and dependence on manufacturing in other countries, challenges with component availability are likely to extend well into 2023.
Besides market forces, natural forces can cause sudden and unexpected delays as well. In late 2020, a fire devastated the Asahi Kasei Microsystem (AKM) semiconductor factory in Nobeoka, Japan. The facility was known for producing components for high-end audio devices and high-stability reference clocks often used in SDR development. Production was expected to be delayed for at least six months, potentially crippling global semiconductor supply and forcing buyers to find other suppliers or redesign their applications. A COTS SDR vendor will not be as vulnerable to these events because part of their responsibility is to have inventory on hand, and therefore be in a better position to navigate supply chain shortages.
The importance of flexibility and long-term support
Now that there is a high-level understanding of what is involved in developing an SDR, all the way from chip selection to functional test, it is time to think more in depth about what is feasible for your organisation. Putting together a dedicated team with the diverse skills required to develop all the necessary hardware and software components is an expensive and time-consuming proposition, so it may be that heading down this road is clearly not viable.
However, it’s not always so clear. In general, if the requirements for your SDR are highly specific, if the flexibility required from your SDR platform is not a necessity, or if schedule demands or time-to-market pressures are not a concern, then building an internal team to custom-design a software-defined radio system may very well be the best option. But if development time is tight or budgets are not flexible, selecting a COTS SDR should be considered.
Supporting the SDR once it is shipped to the customer is another important consideration. If an SDR is developed in-house and a product team gets deep into product development, there might not be adequate support for a proprietary SDR if technical issues arise.
This also applies to the expectations being placed on the product being developed. If you know that the end-product will never need or be expected to evolve beyond what it is being designed for, then in-house development of a purpose-built RF transceiver may be perfectly suitable. But chances are, if an SDR is required, it needs to be part of a system that can be enhanced over time as application requirements evolve.
One of the primary reasons an SDR would be used in the first place is its ability to be updated and reconfigured. Without continued innovation or development, an in-house SDR solution will be only as good as the day it was designed. Taking an honest look at the likelihood of shifting requirements can be extremely beneficial for answering the build versus buy question early in the project development cycle.
On the other hand, a COTS SDR will have dedicated product teams whose sole jobs are to enhance the functionality of your SDR and provide ongoing support. It is not uncommon for SDR vendors to offer new features as simple software updates, as development evolves. This perpetual product innovation can be an easily overlooked benefit when considering building a custom solution, not to mention rigorous support documentation, as well as having a consistent API library and user experience across new radio cards from the same vendor if the need arises for future projects.
Knowing what is required to fully realise a flexible SDR transceiver is important, as is having an idea of where the financial break-even point is for going it alone. The team at Epiq Solutions has been through this process numerous times while developing its portfolio of COTS SDR modules. The financial investment is not small, extending well into the millions of dollars required in upfront engineering/development investment. Estimating the financial commitment, coupled with the technical expertise required to deliver something that works well, can help you realistically evaluate whether to undertake the development on your own or buy from a trusted vendor.
Finally, time constraints are always part of the decision-making process. An SDR vendor will have the steps discussed earlier – RF hardware development, digital hardware development, FPGA development, software development, testing and documentation – down to a science. The time efficiencies realised with a highly specialised team can be significant when compared to even an experienced company that is starting from scratch.
Selecting the right vendor and COTS SDR solution
Let us assume the big decision has been made to buy instead of build. At this point, you might think the decision-making is at an end. But now is the time for another monumental decision: which SDR vendor and COTS solution to select. If SWaP is also a consideration, the candidate pool of options is quite small.
Evaluating a potential vendor for their ability to support development and evolution of the SDR product is also a priority. Choosing a vendor who deals with standard commercial form factors such as PCIe cards, MiniPCIe cards, M.2 cards, 3U/6U VPX cards or similar, can radically simplify the interfacing and integration of the SDR into the intended host system.
Furthermore, these commercial form factors typically provide a significant number of options for the system topology in terms of compute resources and peripherals. Standards simplify the system development process, and choosing a COTS SDR aligned to a standards-based form factor can increase the attractiveness of the end-product to numerous buyers.
Have confidence in your decision
At Epiq Solutions, developing radically small SDRs that deliver on flexibility, performance and functionality is one of the core principles. The company’s portfolio of SDR cards, FPGA reference designs and software are field-proven to function reliably in mission-critical mil/aero andcommunications applications.
If you find yourself weighing up the pros and cons of developing an SDR in-house versus using a COTS SDR from a proven supplier, the team at Epiq Solutions would welcome the chance to discuss your application.
| Tel: | +27 12 667 5212 |
| Email: | [email protected] |
| www: | www.rfibersolutions.com |
| Articles: | More information and articles about RFiber Solutions |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version
