Connectivity1095801742 5df91efef1fe9

Flexible Hardware Enables Over-the-Air Updates for RF

Dec. 17, 2019
A software-defined approach to design puts greater control in the hands of manufacturers, particularly when its delivered as a total solution.

The phrase “over the air,” often referred to as OTA, is now normally suffixed with the word “update,” which together imply that the way something operates can be changed remotely using wireless communications. OTA has become popularized by the Internet of Things (IoT), particularly in small endpoints that are wirelessly linked to a gateway or, in some cases, directly to the internet.

OTA gives manufacturers a way of modifying the operation of a device long after it’s been shipped. Sometimes this is to add premium features, but generally it’s way to deliver bug fixes in the software or software compensation for deficiencies in hardware updates that improve its functionality or security.

Bugs are present in systems that are largely software-based, because software is inherently buggy. It’s widely believed that no software can ever be thought of as entirely bug-free, and the number of lines of code in all systems is on an upward trend. Security in the IoT is another reason why OTA has become not simply popular, but almost essential. The ability to retrospectively fix security issues in IoT endpoints using OTA updates is now considered an essential feature.

Increasingly, the wireless communication systems used in many devices are now also software-based. This raises the question of whether a system that’s largely defined by software can be updated using OTA techniques. To answer that, it’s worth looking at how software is used in RF systems.

The Evolution of Radio

In broad terms, any radio comprises an RF front-end and a baseband. The front-end is typically largely analogue in nature, involving power amplifiers, mixers and filters. Baseband processing performs the functions needed to access or encode the information locked up inside the radio signal.

Over the last three decades or so, there’s been a migration away from implementing the baseband in dedicated hardware, toward using programmable solutions. This gave rise to the term software-defined radio (SDR), although in practice what that really means is a software-defined baseband.

The IEEE has actually assigned definitions to the terms now used in the area of SDR and it differentiates between software-defined and software-controlled. The former is typically applied to the baseband functions, while the latter is more applicable to how the RF hardware is manipulated. Specifically, SDR refers to the physical layer, the lowest layer on the ISO’s Open System Interconnection (OSI) 7-layer model and the functions within the protocol responsible for processing the baseband signal directly after it’s been received and demodulated.

The ability to apply SDR to the baseband has increased as the protocols involved have become more complex and, perhaps more pertinently, subject to change (which brings us back to the benefits of OTA updates). Not so long ago, the performance requirements of the baseband would have dictated that all of its functionality be implemented in dedicated hardware, often in the form of an ASIC. Over time, more of the functionality moved into the digital domain, while at the same time the performance of digital technology has increased. The emergence of digital signal processors (DSPs) coincided with these developments and the DSP soon became the natural home for some of the baseband functions. This could be seen as the initial adoption of SDR.

Integrated circuitry, developing in step with Moore’s Law, has marched on since those early days of SDR, which still dictated a divide between functions that needed to be carried out in dedicated hardware and those that could be offloaded to a more flexible DSP platform. A key technology in this evolution was the FPGA, which offers a halfway house between dedicated hardware and a completely software-defined platform (Fig. 1).

Newer FPGAs integrate a greater number of hardware blocks to deliver levels of performance that just can’t be achieved in a gate array. While these blocks now tend toward being application-specific, they’re still largely general-purpose in nature, which is necessary to ensure the FPGAs can address the maximum number of application areas—FPGAs aren’t only used in wireless communications.

The IP used to implement FPGAs is highly specialized and fiercely protected through numerous patents held by a small number of device manufacturers. There have been several examples of startups over recent years attempting to break into the FPGA market, all of which have largely been unsuccessful.

However, it remains apparent that an FPGA-type approach to building a hardware platform that offers software-defined configuration offers significant benefits. By applying this philosophy to the RF baseband, CML Microcircuits developed a platform that include the performance and configuration normally found in an ASIC or ASSP needed to meet the specific demands of an application—and still retain the flexibility that comes with a software-defined approach. This platform is known as the FirmASIC family.

Software-Defined Baseband

CML uses its proprietary FirmASIC platforms for a range of ASSPs that offer high levels of customer configuration and customization at the baseband. In addition, by retaining full control over the baseband’s functionality, the company was able to develop a range of software-controlled RF ASSPs that, together, create an inherently configurable radio solution to support significant OTA updates.

To deliver this, the proprietary technology was designed to provide the benefits of ASIC, ASSP, FPGA and DSP solutions in a single device. Figure 2 shows a functional block diagram of a typical device based on FirmASIC. Since its inception in 1999, the platform has been used to develop a wide range of standard and custom products. CML leverages the technology to develop many of its own standard products, and it has the potential for small-, medium-, and large-volume solutions that are semi- or full-custom in nature.

Following the initial development, the nature of FirmASIC allows for functional changes to be made throughout the design, field-trial, and early deployment stages, and even long after volume production has begun. This approach lends itself well to the use of SDR in a range of wireless and wireline voice- and data-communication applications (Fig. 3).

Configuration is achieved using a “Functional Image” data file, much like the configuration file loaded by an FPGA at power-up. The FirmASIC platform is available in RAM and ROM formats, meaning the Functional Image can be fixed (ROM) or updated (RAM). All modifications are made by CML, so the customer’s engineering team doesn’t need to learn or understand the HDL design cycle normally associated with an ASIC or FPGA, or be conversant in DSP programming.

Taking a FirmASIC approach to design, the typical system diagram in Figure 1 can be implemented with fewer components and greater flexibility, as shown in Figure 4.

Conclusion

OTA updates are a part of modern digital communication systems. A typical SDR approach provides flexibility at the baseband but comes with the cost of design complexity. The FirmASIC technology platform offers the benefits of SDR at the baseband plus software control for the RF front-end. Together, it provides OEMs with a more flexible, yet less complex, approach to radio design that includes all of the benefits of SDR with OTA.

Malcolm Lyman is Marketing Manager at CML Microcircuits.

About the Author

Malcolm Lyman | Marketing Manager, CML Microcircuits

With more than 35 years in the Wireless Communications industry, Malcolm Lyman has been involved with the European Telecommunications Standards Institute (ETSI) and major communications companies developing innovative communications solutions for both the wireless voice and wireless data systems.

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!