Selecting wireless SoCs for IoT designs

Selecting a wireless system-on-chip (SoC) for your design isn’t easy. It requires careful consideration around several factors, including power consumption, size and cost. The SoC also needs to support the right wireless protocols for the IoT application and network, which then entails factors like range, latency and throughput.

One way to ensure that your IoT design is optimized for the application is by carefully considering your choice of wireless SoCs. It also requires a careful evaluation of the key requirements of your design—including battery life, compute and memory resources, and footprint—because there will be performance tradeoffs, depending on the application.

Designers have many factors to consider when selecting wireless SoCs for their products, said Max Palumbo, product marketing manager for wireless connectivity, secure connected edge, at NXP Semiconductors. “There is no right answer in terms of what device or architecture to choose, as this depends on the series of engineering tradeoffs that the product designer is willing to make to satisfy the needs of their end customer.”

There is also industry agreement that a strong development ecosystem with comprehensive support tools and service is paramount. These product and prototyping tools and services can help designers reduce their time to market and cost.

So let’s address some of the top-of-mind design issues that engineers should consider when selecting wireless SoCs for their IoT designs, as well as some of the biggest challenges and tradeoffs.

Use cases dictate design

Most wireless SoC manufacturers agree that the application requirements determine the selection of the wireless SoC and help narrow down the options for the IoT design. One of the most critical factors is power consumption, they said, followed by a host of other considerations, such as wireless protocols, performance, cost, size, tool support and ease of integration.

While power consumption is tapped as one of the most critical factors in selecting wireless SoCs, choice of the wireless protocol is governed by the application.

The end application determines the priorities, said Brandon Bae, senior director of product marketing for wireless connectivity at Synaptics Incorporated.

He cited a few application examples in which design priorities define the selection of the wireless SoC.

“For example, if it’s a battery-powered device, such as a wearable with a single Bluetooth connection, they may choose our SYN20703P [single-chip Bluetooth transceiver and baseband processor],” Bae explained. “If it’s a drone, they may need our SYN43400 Wi-Fi SoC, as power consumption and size—and weight—are very important and developers have to make the decision based on their go-to-market strategy.

“A drone may also need both Wi-Fi and Bluetooth,” he added. “At that point, the number of wireless interfaces required for the application becomes important, and an integrated SoC with both is typically the best approach. Our SYN43756 [single-chip IEEE 802.11ax 2 × 2 MAC/baseband/radio with integrated Bluetooth 5.2] is a good solution for that.”

Bae also noted that “application dependency can be extrapolated to include aggregation points or gateways for the IoT where multiple heterogeneous wireless networks come together.” This would benefit from a higher level of integration, with Bluetooth, Wi-Fi and Zigbee/Thread (IEEE 802.15.4 PHY), such as that provided by the Triple Combo SYN4381 wireless SoC, he said.

Dhiraj Sogani, senior director of wireless product marketing at Silicon Labs, agreed: “Every wireless protocol is playing a different role, and the end-application use cases are the most important in deciding one or more of these protocols for an IoT device.”

Sogani said there are several key factors in selecting a wireless SoC for an IoT device, which vary by the application. His top five considerations, which are important for all kinds of IoT devices, include wireless protocols; security; battery life; hardware and software support, including peripherals, GPIOs, IDE support, cloud support and networking/wireless stack integration; and compute and memory resources available for the application after the OS, networking stacks and the wireless stacks have been integrated into the wireless SoC.

For wireless protocols, requirements include application throughput, latency, number of network nodes and range, he said. “IoT devices are becoming more complicated every day as more functionality is getting integrated into the devices. Adding wireless to the IoT devices increases the complexity manifold. There are many wireless protocols being used in IoT devices, including Wi-Fi, BT, BLE, Zigbee, Thread, Z-Wave and cellular. The choice of wireless communication protocols for a particular device depends upon the application, size, cost, power and several other factors.”

Sogani cited several examples in which the application, together with the performance requirements, are key to the decision-making.

“BLE is a good protocol to use for a home-temperature sensor, as it consumes low power, it is lower in cost than some other protocols and it provides the necessary range in a typical home environment,” he said. “NFC provides the lowest throughput and the shortest range, making it ideal for contactless-payment–like applications. Wi-Fi provides higher application throughput needed for several applications, such as security cameras.”

Design challenges

Most chipmakers agree that wireless SoCs can simplify designs by integrating the different wireless protocols and handling the coexistence challenges between multiple protocols. They also deliver space savings, a key concern in many IoT designs. However, there are use cases where discrete solutions could offer the best value in terms of both performance and cost.

“The benefits of a wireless SoC are many and include the assurance of a proven design, shorter time to market, smaller overall footprint, lower bill of materials [BOM] and lower inventory management costs,” said Synaptics’ Bae. “These advantages apply to mostly all end applications, but there may be instances where a discrete solution may work better if the customer has specific requirements and has the RF design skills and resources to implement in that direction.”

NXP’s Palumbo said that when determining how to architect an end product that includes wireless connectivity, “one of the first decisions a product designer must make is whether they will use a single, integrated wireless SoC or separate the wireless from the processor. An equally important decision that needs to be made is which operating system will be used. The decision of the operating system will quickly shift designers either to lower-cost, RTOS-based microcontrollers or toward larger, more scalable, Linux-based processors.”

Integrated wireless SoCs are physically smaller and may be lower-cost due to the integration, enabling the end-product designer to deliver a smaller product or a more innovative form factor, said Palumbo.

“However, the challenge with an integrated wireless SoC is that the designer lacks flexibility to optimize the compute performance or the wireless performance independently and the capabilities of the wireless SoC itself are invariant, so there is not as much ability to optimize individual components of the product,” he said.

Whether using an integrated or discrete solution, power consumption is still a key factor that is influenced by the system architecture and use cases. “This means in some cases, multi-chip solutions involving separate radio and processor chips may be easier to optimize,” said Palumbo. “In other cases, wireless processors may provide all the necessary flexibility needed for specific applications and use cases.”

Palumbo provided some key examples in which power consumption plays a critical role. “For example, simple end applications like a sensor or actuator that have a low communications duty cycle and do not perform any ancillary networking functionality, such as routing, designers will see the lowest power consumption when using an integrated wireless SoC.” This type of application can be addressed with devices like NXP’s K32W148 wireless microcontroller.

“However, for more complex devices—a thermostat, for example—where packet routing is an important feature for the overall user experience of the end device and the target ecosystem, a discrete solution may be lower power,” he said. “If a network co-processor [NCP] is included alongside the primary compute SoC, then this allows the networking stacks to be offloaded so that only the co-processor itself is required to wake up to route packets.”

In this example, an NXP i.MX microprocessor like the i.MX 8M Mini can be used as the compute SoC, the NXP RW612 wireless MCU can be used as an NCP and the IW612 tri-radio solution can be used as a radio co-processor. “This can help reduce the power consumption of the system significantly—especially when an NCP is used with a Linux-based microprocessor as the primary compute platform,” said Palumbo.

The product designer has to analyze these tradeoffs and select the architecture that makes the most sense for the value they are trying to bring to their customers, he added.

Design tradeoffs

Wireless integration can be quite challenging especially as it relates to RF circuitry, according to manufacturers of wireless SoCs, and all tradeoffs are driven by the use cases.

The challenge is often about the radio-integration part of the solution to deliver good-quality product performance and to meet regulatory and protocol certification requirements, said Nathalie Vallespin, wireless product line marketing manager at STMicroelectronics.

“A wireless SoC simplifies the integration phase, as most customers first moving to wireless solutions are not RF experts, so integration simplifies and accelerates their development and production,” she said. “Product sourcing for end customers is also simplified by an integrated solution [SoC] and can be even further simplified using a module, which includes the whole reference design.”

In addition, Vallespin said that “an SoC also ensures more efficient power and performance levels of the radio protocol and application, while a multi-chip solution creates connection interface constraints and complexity for software management. A discrete/multi-chip approach can also potentially lead to overconsumption to keep both host and radio running to communicate properly.”

Synaptics’ Bae said there are many challenges with RF, but “they can be addressed through careful consideration of board layout, grounding, relative positioning of other digital ICs in the design to avoid interference, and antenna placement and routing. Aside from layout, the designers or developers need to be cognizant of the impact on the SoC from power-source switching, other sources of electromagnetic interference and materials choice for enclosures.”

Wireless SoC integration can become challenging, depending on the number of wireless protocols it supports and the use cases, said Silicon Labs’ Sogani.

He cited several challenges, including hardware integration (antenna placement, RF design, etc.), software development (wireless stacks, networking stacks, cloud connectivity, application development), RF testing (including extreme conditions), interoperability testing (with other devices it is supposed to connect to), wireless coexistence (multiple protocols need to co-exist), production testing (minimizing the test time and yield), regulatory certifications (for countries to be supported), protocol compliance (for protocols integrated in the device), power optimization (based on the battery requirements), system security (to ensure device and data security) and solution cost (based on the target).

Designers need to make a tradeoff at every step to optimize between various parameters, and all of these tradeoffs are eventually drive by the application use cases, said Sogani.

“With IoT devices needing to support multiple protocols, wireless SoCs provide an integrated solution that simplifies designs by integrating these protocols and handling the coexistence challenges between multiple protocols on the same ISM band internally, as well as not having to worry about managing and worrying about RF design for multiple devices,” he added. “This helps in faster development cycles and more seamless functionality between the various protocols. End applications do play a role, as it may be possible to use discrete chips for simpler applications, but as applications become complicated, it makes more sense to use integrated solutions.”

Vallespin said understanding and selecting the right technology that will be the best fit for the application and market demand is a key challenge. Another challenge is understanding the chosen radio protocols and picking the right hardware (antenna, routing, BOM selection) and matching software, which can be specific to each technology, she said.

The key tradeoffs are balancing price versus features as well as choosing the architecture—a host + co-processor approach or a single application processor, Vallespin added.

Support and availability

In addition to performance concerns, development and design support along with supply-chain issues like continued availability are priorities for many IoT designers.

Key concerns include how effectively the product and its development ecosystem can reduce their time to market and cost, the availability of the product and prototyping tools and the long-term availability of the product, said Vallespin.

There are also several questions that designers need to ask, such as if there are guarantees that the SoC will be available as long as their product is in the market, what the roadmap of the SoC is and if it aligns with their product development plan, and if there is sufficient support availability, including for documentation, ecosystem and contact to ensure success, she added.

NXP’s Palumbo believes longevity requirements are part of the tradeoff equation.

“Once a product has shipped, the hardware itself is unchanging; however, there is an expectation from the end customer that the product will continue to be supported and receive updates for some time after their purchase,” said Palumbo. “Selecting a device—and a product architecture—that enables product designers to provide updates for the lifetime of the product is a criterion that is gaining importance.”

The software architecture is also another critical consideration when selecting a wireless SoC, said Palumbo. “Regardless of the product architecture—be it integrated wireless SoC or discrete—the software tools and environment for these SoCs are equally important components to the hardware. Whether a device is Linux-based, Android-based, or RTOS-based—even without considering the wrinkle of which RTOS to use from the myriad of solutions available—makes a massive impact on the end product.”

The article originally published in EE Times Embedded in the IoT Era special report.