The Untapped Potential of Wireless SoCs

Good morning, good evening, everyone, and thanks for joining in. 
  
I'm Jayant from product marketing team at Silicon Labs, and I will be your host and moderator for this session. 
  
Today, I will be talking about the untapped potential of wireless SoCs. But before we dive in, let's take a moment to align on a few things. I'm also joined today by Chad Steider, a senior product marketing manager at Silicon Labs. 
  
He will bring his expert perspective to the discussion.We will wrap up with a panelist style Q&A, where I will guide the conversation and take your questions as well. 
  
Let me quickly walk you through the agenda for today's session. We will start by looking at how MCUs are typically used in a system today, setting the baseline. Then we will explore the shift in architecture. What has fundamentally changed in modern wireless SoCs?From there, we will dive into how we can unlock the full potential of wireless SoCs, especially beyond just connectivity. And after that, I will show you a live demo to bring these concepts to life. And finally, we will wrap up with a Q&A session where we can discuss your questions and share additional insights on this topic. 
  
If you look at most IoT systems today, many are still designed with two or even more processors. 
  
Typically, you will find a wireless SoC paired with an external MCU right next to it. 
  
It may sound familiar to you. 
  
We do this almost by default, not always because we need to, but because that's how systems have traditionally been built. 
  
But here's the interesting part. 
  
In many of these designs, the wireless SoCs are already included and are capable and already inside your wireless SoC. 
  
And yet, we often don't use it to its full potential. 
  
So today, I want to explore why that is. 
  
Are there any real limitations that justify adding an external MCU? 
  
Or is it just out of habit that we keep on using an external MCU for all our compute and processing thing? 
  
And more importantly, what changes if we start leveraging the internal MCU instead of relying on a separate one for the compute? 
  
So today, if you look at how wireless SoCs are typically used, they are still treated primarily as radio enablers, focused on connectivity only, not as a system control. 
  
In many designs, they operate as co-processors rather than a main system controller. 
  
Yes, I agree, they often offload your PHYs and MAC stacks from the host MCU. 
  
But beyond connectivity, their role is often limited. 
  
Meanwhile, the external MCU handles most of the heavy lifting, whether it is compute, whether it is memory management, whether it is peripherals or sensors, user interface, or even the RTOS. 
  
But from a system architect's perspective, this approach comes at a cost. 
  
It adds complexity, increases power consumption, and creates integration overhead. 
  
You now need additional interfaces, more memory coordinations, and tighter software integration as well. 
  
And managing communication between multiple processors becomes a challenge in itself. 
  
And all of this makes the system more complex than it often needs to be. 
  
But again, we have that assumption. 
  
Wireless stacks are completely consuming all the compute inside that MCU. 
  
So if wireless SoC were truly constrained, I'm sure we wouldn't be having this conversation today. 
  
But when you look at modern wireless SoCs, something fundamental has changed and it's worth paying attention to, and that shift should make us rethink our design approach. 
  
Why not leverage the MCU already embedded within the SoC itself instead of defaulting to a separate external MCU? 
  
So what exactly changed with this new architecture, which we are going to discuss? 
  
It's not the applications that changed. 
  
It's the architecture itself. 
  
If you look at today's wireless SoCs, they have evolved tremendously. 
  
In fact, they are built on a multi-core architecture that separates workloads by function. 
  
If you see on the right side of the diagram, there is a separate core for application processing, then radio operations, and security as well. And the best thing, if you see, each of these runs independently. 
  
Radio and security have their own dedicated cores, which means latency critical tasks are handled locally without interrupting application core at all. 
  
In many cases, this even eliminates the need for a separate secure element as well. 
  
And on top of that, you have advanced peripherals like PRS, lesense, that allows components to communicate and react directly with each other without waking up your application core. 
  
So what does this mean? 
  
It preserves valuable MCU headroom, which you can utilize for other compute tasks, and you were dependent on an external MCU to do all those compute tasks. 
  
So you are not constantly waking up the main processor for routine tasks. 
  
Instead, the system is event-driven, hardware handles with it, and the application core runs only when truly needed. 
  
The result is clear. 
  
More efficient compute utilization is there. 
  
Power consumption will be very less and significantly more available processing headroom than typically we assume that it is not available. 
  
So in reality, if you ask me, usable application compute now exists inside the wireless SoC itself. 
  
So again, here is the key question. 
  
If the compute is already available, why are we still adding another MCU? 
  
We already have a capable MCU inside the wireless SoC. 
  
So if you ask me, the real reason comes down to history. 
  
There were valid reasons in the past, and I do agree on that, and many of us still assume they apply today as well. 
  
For example, we used to think we needed higher compute performance. 
  
Yes, in some cases, that may still be true, but for most of the IoT applications, it's no longer the limiting factor. 
  
There were also concerns about separating radio and application workloads. 
  
How do they coexist without interfering with each other? 
  
But as we saw in previous slide, the new architecture completely separates radio cores, application cores, and even secure cores as well. 
  
And of course, the belief that using an external MCU gives more design flexibility and of course, scalability as well. 
  
But based on what we just discussed about modern SoC architecture in last slide, do you think these assumptions still hold? 
  
Is compute really limited anymore? 
  
I think not really. 
  
Workloads are now clearly partitioned. 
  
Application processing, radio operation, and security all run on dedicated cores. 
  
The secure element has its own execution environment, and the application core still has significant headroom. 
  
So the real question becomes, does this level of integration actually delivers better efficiency? 
  
And the answer, if you ask me, is yes. 
  
In many cases, it's significantly more efficient than the traditional approach of pairing a wireless SoC with an external MCU. 
  
But the sad story we still architect for old constraints, even when the silicon has moved on and we already have an architecture which is well-partitioned to be used as an internal integrated MCU instead of an external MCU for compute task. 
  
So now let's take a step back. 
  
What really happens if we remove the external MCU? 
  
Do we lose capability? 
  
No, we don't lose capability at all. 
  
In fact, we consolidate it. 
  
What used to be spread across multiple chips, system control, application processing, wireless connectivity, and even AI workloads now comes together on a single platform. 
  
You still have full system and application management, you still have integrated wireless communications, and you still have the processing capability needs for advanced features, including AI at the edge. 
  
But now it's all unified, and that fundamentally changes how we design system. 
  
One controller, less overhead, and simpler design. 
  
And so far, we have talked about concepts and architecture. 
  
Now let's bring this to life with a real example. 
  
What does it actually look like to build a complete system on a single wireless SoC? 
  
Let's walk through a demo that shows exactly that. 
  
So this is our fan demo built on Silicon Lab Series 2 wireless SoC. 
  
Traditionally, this device has been used purely as a wireless connectivity enabler in past, but this time we took a different approach. We asked ourselves, can we use it as a complete system solution, not just for connectivity? 
  
And I'm quite excited to show you this demo, which brings everything we have discussed to life. 
  
At its core, this demo brings together three key functions. 
  
First, motor control, which is a compute-intensive task. 
  
Second, wireless connectivity using Bluetooth Low Energy, providing a real-time user interface to control parameters like speed and receive a status update. 
  
And third, edge intelligence, AI/ML running directly on the device, leveraging the on-chip accelerator. 
  
Now, let's see it in action. 
  
So this is my motor control demo setup. It is based on our Series 2 MG26 solution board, and this is our UI for this. So I will first show you how it is connecting via Bluetooth Low Energy with this demo. 
  
So when you click here, it will show the demo setup here, and we just need to pair it.And once you pair it, you can see it gets connected. And now we will show you its compute capability. 
  
So if I just start it with low RPM. So if you can see, RPM is also displayed on the go.So whenever you are changing the RPM, it will display here itself at what RPM your motor control is running. 
  
So it is showing you the complete compute capability of the motor control and this- So as you have seen in the demo, this solution itself is handling all the compute part of the motor control, which is, again, a heavy lift, not a light one. 
  
So all the compute capability is handled by this Series 2 processor itself. 
  
Demo. 
  
You can start, stop, and do everything with this. 
  
And then again, we can just start it on. 
  
Now, if you see, I will just turn on the auto shut-off mode on to show you the AI/ML capability, which is done on the edge itself for this demo. 
  
So if you see, right now it is spinning. 
  
If I provide it some anomaly or some obstacle, it will read it here, and if it goes beyond 70%, it will just automatically stop my motor control demo. 
  
So let me introduce some anomaly in this. 
  
See? 
  
Due to this auto shut-off feature, it is stopped itself. 
  
So this is one of the edge AI thing which we are doing on this demo. 
  
So as you have seen in this demo that we have induced few AI/ML capability as well in the same SoC instead of using a different processor altogether, and everything is done on the edge itself, inside processor itself. 
  
So the latency and other part are negated through that, and we will show you the other AI/ML capability as well, which we induced in this demo. 
  
Now I will show you the second thing which we did in this motor control with edge AI, which is its capability to use our voice command to start, stop, go slow, and everything. 
  
So I will show you that. Like if I just give it command, go. Stop. Go. Left. Right. Fast. Stop.So this was our demo for motor control. 
  
And what does this mean for the future is we are ready with solution, which in itself is capable to integrate all the three features for which you are using external MCU, external AI accelerator, or a secure chip. 
  
So in this demo, we showed you that we already have solution which can integrate it all together, doing all the compute heavy lifting, doing AI/ML at the edge, and of course, wireless connectivity to show you all the changing parameters on the go on the UI. 
  
So the next generation of IoT nodes will reflect a clear shift in system design from discrete architecture to a highly integrated ones, as we have seen in the past demo. 
  
And instead of multiple components, we are moving towards a consolidation phase of bringing everything onto a single SoC with tighter hardware and software integration as well. 
  
We are also seeing a shift in how intelligence is deployed. 
  
Traditionally, if you remember, devices would sense data and send it to the cloud for processing, and everything was done on cloud. 
  
But with edge AI advancement, now with that, devices can sense and decide locally instead of uploading data on cloud, and they can decide locally all the instructions, and intelligence is moving somewhere from the cloud to the edge itself, and this enables a faster response time, as we saw in the previous demo. 
  
Latency is quite low and more efficient operation and importantly, the focus is no longer on just peak performance. 
  
It's performance per watt, and it's about using available compute more efficiently, not just adding more of it. 
  
With that, I will wrap this up, and I want to leave you with one key question. 
  
Is the compute already inside your wireless SoC sufficient to handle your system needs? 
  
Because increasingly, if you ask me, the answer is yes. 
  
With that, I will move to my live Q&A session as well as the panel Q&A session, where our subject matter expert will share, hey, Chad, share deeper insights on this topic. 
  
Chad, welcome, and thank you for joining the session. 
  
I'm really excited to hear your perspective on this approach of leveraging wireless SoC not just for connectivity, but also for compute, instead of relying on an additional external MCU. 
Yeah, thanks. It's great to be here. 
  
So let's start with our Q&A, and I would really appreciate if you can throw some light from your perspective of why has the industry held on to this external MCU model for so long, even when wireless SoC have evolved significantly? 
  
Yeah, I think there are three reasons why we see this architecture continue to keep momentum, right? 
  
There's a lot of legacy investment in existing ecosystems. 
  
So our customers have spent a lot of time developing code to turn a motor or do specific functionality on a specific host MCU, and then throughout that product's life cycle, it got to a point where, okay, now we need to add wireless, and the easiest path for them to do that was to just add another wireless MCU to the ecosystem. 
And I think that's the first part. 
The second part is the two-chip design does provide greater flexibility. 
It allows users to optimize their application, picking the best motor control MCU that they can find or an MCU with the most peripherals they can find to sit next to a part that's optimized for wireless. 
  
And that flexibility does have an advantage, but it comes at a cost.  
And then I think the third piece is there's some debate around which architecture is actually more power efficient. 
  
There's an argument to be made that if I can turn the radio SoC completely off and just do whatever my system needs to do, and then when I need to do wireless, turn the main system MCU off and just do wireless. 
  
There's an argument to be made that depending on how you architect it, you could be more power efficient that way, but I think there's some conversations to be had around that one.  
And more importantly, what we saw from our own experience while developing this motor control demo, that even if it is running at a higher RPM, let's say 5K or 5,500, still Bluetooth connectivity was quite stable there. 
  
We didn't saw any lag or any glitch. 
  
So this shows that even at highest compute execution, your connectivity is not compromised with that. 
  
So that was one good point, seeing that, okay, if I am using a heavy loading on my compute in the same SoC, will my wireless connectivity will get compromised through that? 
  
So we didn't saw that happening too often there. 
  
Yeah, and I think the other piece is, in a lot of cases, these wireless SoCs are not entirely optimized for something like motor control. 
  
If I need to do very precision, very high-end motor control plus connectivity, the best path is still probably going to be a two-chip solution. 
  
But if I'm doing simple FOC-type motor control, which is what that demo you showed is using, if I'm doing something simple, I don't need that big motor control MCU sitting next to the wireless part. 
  
I can save a dollar, $2, whatever that ends up being on BOM cost by pulling that into a single SoC. 
  
Exactly, and that is a quite good point you brought that we need to understand our application, that for what application we are using this. 
  
If we are well-versed with our application, that it is for heavy duty, heavy loading, like any some industrial robot or some that sort of control, then, of course, we need an external MCU. 
  
But there are a number of applications, especially in IoT segment, where we can leverage such kind of compute capability, which is already inside wireless SoC, maybe in a home automation for your window curtains or a fan or in fact, your blinds. 
  
Those are not very heavy lifting compute things. 
  
So in those applications, you can always use the integrated MCU already inside wireless SoC. So, jumping to the next question, we have shown our connected motor control demo at two major trade shows in this year. 
  
So what was the customer reaction, and were there any major takeaways from those shows you would like to share with us?  
Having been part of both of those shows and been part of the demo, I think people were really impressed to see the ability of this relatively low-cost, low-power MG26 device connecting to a PC or phone, doing the AI/ML at the edge and spinning the motor. 
  
I think when my team did the research on the amount of processor resources that Bluetooth takes up and that the simple FOC motor control takes up, the Bluetooth connection maybe takes up about 20% of the overall processor resources within that MG26 device. 
  
And then when you add the motor control on top of that, we're maybe another 15% to 20%, depending on the algorithms you use and depending on how you want to do it. 
  
So that leaves 60% of those processor resources that are just sitting idle. 
  
And when you start talking to people about the amount of compute that's available, that is literally sitting idle on their board, if it's just doing connectivity, it's sitting idle 80% of the time. 
  
So, what else can I do? 
  
And when you add in the ability to do AI/ML at the edge with our AI/ML hardware accelerator, now you're not even really increasing the processor load that much. 
  
There's a small amount of code addition, and there are a few resources. 
  
But realistically, you're getting this edge AI included in the price of the IC that you're buying. 
  
Now people can really start thinking about how they can leverage it. 
  
I think there are a lot of things that our customers are being asked to do, and our customers are considering edge AI across the board. 
   
Well, it's already embedded in our XG26, XG24, and XG28 devices.  
You already have that capability there. Why not just turn it on? 
   
And just to add on that, when we were doing this experiment with this FOC motor control setup with our dev services team, we were amazed to see that even while controlling, doing all the compute for this motor control, along with connectivity and that AI/ML, we still had headroom left for few more AI/ML stuff, which we still can integrate in that. 
  
So that was very exciting and encouraging thing that even at this heavy loading, along with AI/ML, along with connectivity, we still were left with some headroom to do some more AI/ML thing. 
  
So that was quite encouraging. The first iteration didn't add the voice control. The first iteration of the demo that we showed at CES was just the anomaly detection. 
  
We added the voice control for Embedded World and really saw no performance hit and very little resource creep in the design. So it's pretty cool to see. 
 
In fact, when this demo reached me and I tried it myself, I was pretty amazed with the precision with which it is taking our voice command and doing those start, stop, and left, right, all the things. 
  
So it can be a great application use cases through these AI/ML thing, and there can be a plethora of applications we can try to inculcate with this motor control setup. 
  
So, moving to the next question, for the team that already have a dual-core processor architecture in production, what does the migration path realistically look like? Is this an incremental shift or a redesign altogether? What do you think? 
I think in reality, if we're being honest, it is a complete architecture shift for most places, right?  
When we talked about the first question about what's preventing people from making this change, you have that established code base that you're going to have to port into a new platform, right? 
  
Or you have the connectivity piece that you're going to have to port into a new platform. 
  
So I think it is a fundamental architecture shift that we'd be a little naive if we said it was easy, and it was going to be a simple change.  
But when you look at what things like Zephyr are bringing to the table, Zephyr kind of makes that portability easier. 
  
Zephyr has some motor control algorithms and stuff as part of it.It has the connectivity piece as part of it. 
  
So maybe it's time to think about, well, if I'm going to make this change, do I jump to something like Zephyr? 
  
And that now I have pretty solid portability across a multitude of platforms from a bunch of vendors, or do I stay bare metal and make a change that way? 
  
I think it does require a fundamental architecture shift, which is probably why more people haven't made the leap yet. 
  
But I think it's something to consider, especially as everyone is getting squeezed on design this product cheaper, design it faster, and add features. 
   
And just I can't agree more with this on you that from where we started with those Arduino setup and where we've reached now, it was not just easy to go thing to just implement those things. 
  
So yes, it requires effort, and it is not that easy to implement everything. So of course, it will be a completely new architectural change. 
  
Very good. So moving to our next question. 
  
So how does this consolidating into a single SoC impact power consumption compared to dual processor design? 
  
I'm sure there is plenty of thing which you want to add on this, so please let us know how it is going to help us in power consumption part. 
  
Yeah, I think it depends on the architecture that you choose, right? 
If you look at a lot of the way people have approached this stuff today, it's been really centered around that sleep current, right? 
  
What's the sleep current of my wireless SoC?Because it remains asleep 80% of the time, right? We're only transmitting a short amount of time. Active current probably becomes a little more important in these designs as we start looking at putting everything in a single chip.  
If we have a system that goes from two MCUs that are both asleep, one maybe asleep 50% of the time and one 80% of the time to a single MCU that's maybe asleep 30% of the time, that active current piece does become more important. 
  
Now, if you look at our Series 2 portfolio, we have really good active and sleep currents. 
  
So, if you looked at moving a design like this over to EFR32 Series 2, you probably are going to see an overall power consumption savings, but you really have to dig deeper into what does the overall power profile of my system look like? 
  
What's the percentage of time that I'm going to be awake, and what's the percentage of time that I'm going to be asleep, and how does that affect the overall power budget?  
And there is always trade-off that if you are getting something, then you have to bear the other part as well. So we have to balance it, and there should be trade-off. 
   
If you have to give one piece of advice to engineers designing their next IoT product, what would it be when it comes to choosing between single SoC versus a dual processor architecture? 
  
I think this is easy for me to say as somebody not doing a design. 
  
But I would say take a step back and look at what's best for the product that you're designing. 
 And I said this at the beginning of the panel.We know designers today are getting squeezed on time, they're getting squeezed on cost, they're getting squeezed in all kinds of directions. 
  
But take a step back and look at what the right architecture is for the product that you're designing. 
  
If there is not something that is strictly holding you to that two-chip architecture, maybe it's the time to consider making the switch and at least doing the analysis to determine, is a single-chip architecture a path that I want to consider, or do I need to stay two chip for safety, or whatever reason that is, right? 
  
Do I need to do some really specific motor control? 
  
That's the decision that every designer has to make as they go through the process of designing their product. But I would say, don't just write off some of these low-power wireless MCUs as just a wireless chip, right? They're capable of so much more. 
  
So folks, with that, message is sound and clear. We showed you in demo as well. 
 Don't think that wireless SoCs are just for connectivity enabler. It has a lot to offer you. 
  
So in future, if you are planning to design something, give a thought and see if your application needs that much processing to be handled by an external core, or it can be handled by a core inside that wireless chip itself.