Wireless SOC selection guide for your Internet of Things product!

While working on wireless communication products, so many times I was in a situation when I needed to select one wireless chipset over the other. There is a sea of wireless SOCs in the market for each technology. Sometimes, I was overwhelmed as marketing material of every chipset vendor makes it look like it has the best chipset out there. In fact, they all look the same. In few cases, I realized it later that it was not the right chipset that I started evaluating for my project and that’s where I felt the need of a checklist. That’s when I’ve decided to note down my learning and share with others.

Processor architecture

Most vendors use ARM based controllers for their low power and wireless SOCs. But there are few which may use RISC based microcontrollers as well. Point here to be noted is that if you use ARM based processor, you are rest assured that you have access to best development and debugging tool set as ARM is the most popular architecture in the world for low power SoCs and embedded devices. In order to avoid ARM licensing fee, some chipset vendors have developed their solutions based on custom RISC processors as well.

If for some reason, you cannot go with ARM based SOCs, then make sure you check the debugging tools such as on-chip debugger, IDEs etc available with the chipset. Not having right set of development tools can increase development time as well as quality of the overall product.

You can also find some SOCs based on 8-bit 8051 architecture. 8051 is an old guard and has been extremely popular for years. It also has good tools and debug support environment such as IAR, Keil etc. For simple control applications, it gives you the best speed. But for larger applications involving IP stack driven internet of things applications, it may not be suitable. 16 or 32-bit ARM core gives better performance in those high end applications. In fact, it is more to do with advantage of 32-bit (over 8-bit or 16-bit) than architecture type. It is a very detailed comparison and out of scope for this discussion.

You may also need to see if your application requires complex processing such as floating-point numbers manipulation, in that case you need to have additional co processor. Therefore, being aware about your application need may help you choose the right chipset.

Memory

There are different kinds of memories needed for 3 reasons- Code, Data, Persistent data. Typically, Flash is used for code storage and RAM is the memory from where code is executed by CPU. During execution, code is copied from Flash to RAM and executed directly from RAM. Sometimes, code can also execute directly from flash (NOR based). It does not make significant difference in this context, so I rest this differentiation for some other discussion.

Additionally, RAM stores run time data as well. So, if your application uses a lot of run time data, then you need to be sure it is available in the SOC. The size requirement for code and data is decided by application. It is important to see the code and data memory requirements of stack and platform software which in turn help to know what is available for user application. For example, if you see Zigbee and BLE software stacks, there is lot of functionality provided by their stacks in the form of clusters or profiles and hence memory usage by stack is in proportion. Simple sensor, home automation and lighting applications do not require more than few KBs for RAM. However, it is a generic statement. See your specific requirement before finalizing. There is no harm in going with extra memory to start with.

Most wireless devices need to support over-the-air (OTA) upgrade, so typically your flash requirement is double or more to support OTA.

Persistent Memory is needed to persist data values across power cycles. Most embedded systems need to store some or more data in persistent memory. This data typically includes user and device configurations, data contexts etc. This is also an application specific requirement. Persistent memory could be an NVRAM, Flash or EEPROM. You need to check if your SoC has internal memory for this purpose or it needs to be interfaced with external memory. If external memory is needed, then what interface it supports. External memory is going to cost bit of design effort as well and hence cost. But it gives you flexibility with respect to size.

Timers

Almost all applications require timer related tasks. Hardware timers provide better accuracy, but they are limited in number as few tasks such as PWM needs them all the time. Software timers are easy to use for short delays.

Timers are nothing specific with wireless SOCs but if you are choosing an SOC which has microcontroller in built, then it is an important criterion. You need to check how many timers are needed in your application against what is available with a wireless SOC in consideration.

Timer granularity is calculated by CPU clock frequency, therefore be aware about what is supported by the wireless SOC and what is needed by your application.

Power consumption

Wireless SOCs sometimes run on battery hence, power consumption should be minimal. Most wireless MCUs support multiple operation modes to support lower power consumption. Typically, there are 3 modes — Active, Normal sleep, Deep sleep. In sleep modes, certain blocks (inside the SOC) are switched off to save power and hence some features also do not work in these modes. Watch out your application requirement and estimate power consumption based on these modes.

Data TX/RX happens in Active mode. TX/RX current consumption is usually higher than all other operations’ current consumption. So, it is extremely important to be watchful of these numbers.

Watch out for power consumption in above mentioned sleep modes. Based on your application, you may make an efficient algorithm by considering at these parameters.

This exercise greatly helps in estimating battery consumption and increase product life cycle.

Radio Performance

Range of wireless communication is an important feature of any wireless technology. Range is decided by multiple factors but if we compare SOC datasheet defined parameters, link budget gives a fair idea about the range supported by a wireless SOC.

Link budget is largely dependent on Rx sensitivity and TX power. It is a comparison (or ratio) between the transmit power and sensitivity level. Hence, lower receiver sensitivity and higher transmit power (note: trade-off with power consumption) is desirable for better range.

Antenna efficiency is another important parameter which is defined by TRP (Total Radiated Power) and TIS (Total Isotropic Sensitivity). But since, Antennas are typically not part of the SOCs itself, lets skip these topics for now.

Boot up time

Compare boot up time initialization time across SOCs in consideration to know how soon your application will come up after power reset and become functional for exchanging data. Most wireless SOCs are quick to boot as they run very efficient code compared to general purpose SOCs.

Peripheral interfaces

Bus protocols should be supported for communicating with peripherals using UART, SPI, SDIO etc. For example, if you decide to use external flash or EEPROM, it is important to see what interface it is going to be connected such as I2C or SPI. Most SOCs do have options for these but you need to imagine your overall product hardware design and see if you have enough of these interfaces for all peripherals.

For lighting and voltage regulator-based applications, SOC needs to provide PWM controllers. Watch out for the number of channels and frequency. As general rule, higher the frequency, better the performance. As per my experience, 1 KHz or more gives good enough performance for optimum performance. Some SOCs also implement the same in software, but hardware PWMs are generally more efficient.

Some peripherals (such as PIR, ambient sensors) gives Analog outputs, so there should be enough ADC pins available for interfacing with these peripherals. Watch out if SOC in consideration supports enough of them as per your specific application requirement.

Security

Security is a critical consideration of your product during the selection process. IOT devices may have various levels of threats and hence require security at each level i.e. firmware, network, user authentication level etc.

Secure boot ensures your device boot only with authorized firmware. Over-the-air upgrade (OTA) is one such vulnerable area where your device could be compromised. Do compare what security provisions (in hardware and software) are available so that it is not upgraded with malicious or corrupt firmware (can make device unrecoverable). 

Check out how the SOCs under consideration protects firmware and prevent it from reverse engineering. Support for TLS security and its supported version is an important requirement for devices that are going to be connected to cloud. 

From hardware perspective, a key component of any security system is a random-number generator. So, check out if your device under consideration supports True Random-Number Generator (TRNG), AES encryption etc needed for cryptographic algorithms.

From user authentication and data encryption perspective, technology specifications (such as Bluetooth, Wi-Fi, Zigbee) provide specification and support. So, generally most chip sets in consideration shall have these offerings.

Cost

This is a self-explanatory requirement. In case of IOT applications, this becomes more important as typically there are several nodes in a typical IOT network system. Therefore, per IC cost is a critical consideration. Check out the price for mass quantity. If your production requirement number is less then, you can consider buying modules directly from module makers.

External components such as EEPROM, Antenna, oscillators are already built in with modules which greatly reduces complexity for application developer. Modules hide wireless technology design related complexity from the reset of the product hardware. Modules are generally certified from their respective technology alliances and come with unique mac addresses needed by respective technology alliances such as Bluetooth SIG or Zigbee Alliance. Thus, application developers spend most of the time focusing on their application rather than investing time on buying addresses from alliances and conducting certifications.

In many cases, IOT product developers buy modules and directly interface on their application PCB hardware.

Other Important points

Development kit availability is an important criterion. This allows early experimenting without the need of actual hardware. Most wireless SOCs now a days, have it but you need to be watchful about it. This may help in getting to see issues early that may force you change the chipset.

Understanding SDK of a chipset, takes its own time and effort. Therefore, it is always beneficial to have chipset vendor’s FAE supporting you technically for initial setup and further support. If you find local development support for SW App integration, then your journey to build your application is going to be very smooth.

Software stacks take its own time to stabilize and require multiple releases. Therefore, it can be considered that if a software stack had multiple releases already, then it is more stabilized compared to a freshly released one.

Shipment time for the chipset and related components can be inquired in advance as sometimes fabrication and delivery takes a lot of time. I have seen it take 3–6 months for some of the vendors. So, be aware of this information in advance before finalizing your chipset and product schedule.

-----

Feel free to comment if you think any other feature that must be looked at for taking making the right wireless SOC selection.