WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 665
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 665
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)
            
arc v 800x100 High Quality (1)
WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 665
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 665
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)

Radio Integration – the Benefits of Built-In

Radio Integration – the Benefits of Built-In
by Bernard Murphy on 08-05-2016 at 7:00 am

It’s always a pleasure when a vendor gives a really informative, vendor-independent presentation on  what’s happening in some domain of the industry and wraps up with (by that point) a well-deserved summary of that vendor’ solutions in that space. Ron Lowman did just that at the Linley conference on Mobile and Wearables, where he talked about when and when not to integrate radios onto the main SoC and why.

Ron started with a characterization of integration options:

  • Standalone RF transceiver, where the MCU provides both app code and the wireless stack
  • Wireless network transceiver where the wireless stack is integrated with an independent RF transceiver
  • Fully integrated solution, where RF transceiver, wireless stack and app code are integrated with the MCU
  • A combo solution where an apps processor with integrated RF MAC connects to multiple independent RF transceivers and pulls app code and wireless stack from flash memory

Based on this, he provided a nice characterization of where different solutions are being used, by type (as defined above) and by process (primarily for Mobile and Wearables, the focus of this conference):

Perhaps unsurprisingly for IoT, health and fitness bands like less aggressive technologies and fully-integrated solutions for size, power and cost, especially if they only need to support one connectivity standard. Higher end products running at more aggressive technologies and needing to support multiple connectivity options prefer combo solutions given practicalities of porting analog IP to aggressive nodes and issues around managing noise. Similar expectations apply for mobile. Augmented Reality applications, while arguably wearable, require significant processing power so will follow mobile rather than wearable trends. Ron expects these trends to continue more or less indefinitely. That said, monolithic solutions will migrate to lower technologies when cost-effective.

An important consideration in integration choices is of course power. Ron referenced a recent study by Microsoft, looking at power consumption for various protocols, cycling through sleep modes. Naturally different protocols consume different currents in receive and transmit, and based on sleep versus active states, according to whichever vendor solution you are using. But Microsoft also made this very interesting observation: “The parameters that dominated power consumption were not the active or sleep currents but rather the time required to reconnect after a sleep cycle and to what extent the RF module slept between individual RF packets”.

In other words, latency between the MCU and the RF module (when waking the RF module) is a significant factor in power consumption. This argues that, all other things being equal, you really want to integrate the radio when battery life is an important differentiator (because latency on-chip will be much lower than latency off-chip). Naturally there are other advantages – integrated solutions will reduce PCB size, are potentially cheaper and possibly also more secure.

Of course there are reasons not to want to integrate. If you buy an RF chipset solution, you don’t have to worry about qualification or certification. The solution may already support multiple standards (WiFi, BLE etc), you may feel latency will be good enough (even though you know this also has an impact on power). However if BLE would be sufficient, you’re wasting a lot of power (and memory) in supporting WiFi. Even if WiFi is the initial use-mode, if the BLE use-mode for your wearable takes off, you’re ready to go with perhaps no more than a software upgrade and you have a built-in advantage of better battery life.

Which brings us back to the integrated part of the story, where Ron started the commercial pitch. Synopsys supports multiple wireless protocols, but let’s just focus on BLE – a likely candidate for a wearable. Here’s what they have:


The solution is available and complete, including a low power PHY. The PHY is ready for integration, with Analog/RF IO pads, deep n-well isolation, guard-ring and more. Since the solution is on chip, it can connect directly to an MCU core, mitigating that power wastage in sleep cycling. Synopsys have already pre-certified and pre-qualified the IP and offer their customers help in getting device qualification and certification. And perhaps what is ultimately most important, solutions for the rest of the wearable market are already moving in this direction, so you don’t want to left behind.

Incidentally, a follow-on presentation from Fawad Khan of MediaTek echoed that they think BLE will be dominant for wearables. You can learn more about the Synopsys Bluetooth IP HERE. The Microsoft study on radio power consumption is HERE.

More articles by Bernard…

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.