This question was raised in the 'How to implement a secure IoT system on ARMv8-M' webinar, view all the questions in the round up blog post.
There are several reasons that would lead designers to use two cores in a design, but I will mostly focus on the main reason that drove our decision: power consumption.
When you synthesize an RTL block, you give constraints to the tools to reflect your expectations in terms of usage of the design. One constraint that has a big impact on power consumption is the target operating frequency. The same block synthesized to run at a high frequency or a low frequency will have a very different area, and a very different power consumption that comes from:
• leakage current – that is drawing current all the time, regardless of the operations being carried on in the block
• dynamic current – that is actually taking place when the block is running
Now let’s take our Cortex-M33 system. If we had a single processor, we would have to make sure that it can run fast enough to be able to handle the highest peak of processing power. So we would select that high frequency as the target frequency of our processor… and we would incur a high leakage current all the time – even when we don’t need that peak processing power and the processor is in idle mode.
Now with two cores, we can have a fast and a slow one. The fast processor would be sleeping (and power gated) most of the time and would not consume anything. We would just power it up when we need it. During low-activity periods with background processing, the system would just consume a little amount of dynamic and leakage power. In average, this kind of system is much more energy efficient than a single core design.
In the CoreLink SSE-200 subsystem, which is part of the CoreLink SDK-200 System Design Kit, we go even one step further, and allow a mode where we switch off both processors: an always-on domain is then responsible for waking up the system automatically when scheduled or as needed. This allows to build ultra low power systems running for years on small batteries, while still giving the option of having bursts of high processing performance.
This gives energy profiles looking like the one shown in the graph below, and this is the recipe to build very efficient battery-powered IoT nodes.