The automotive electronics meant for safety applications are increasingly implementing multi-CPU architectures with on-chip redundancy to safeguard applications using minimal software overhead. On one hand, having on-chip redundancy is good for safety measures, but on the other hand it has attached baggage like higher die-area, higher noise, higher power consumption, etc.
This article discusses the factors that should be considered when calculating the power numbers of such SoCs. These factors if not decided judiciously may lead to inaccurate power numbers in the product datasheet, which could result in lost sales or customer dissatisfaction.
Power consumption of a device under typical run conditions is one of the important parameters specified on a datasheet. In the case of SoCs, the power consumption number depends on multiple factors like frequency of operation, modules enabled during the operation, CPU and DMA (direct memory access) operations with cache enabled/disabled, etc. For multi-CPU (multi-core) SoCs, another factor is whether the CPUs are working in lock-step or a decoupled parallel mode.
This feature discusses the various factors considered to define the typical Run-Idd (drain current) conditions (TRC) for the power measurement. This is a very important step before proceeding to make measurements and justify the power numbers on the datasheet. The analysis presented here is for a dual-CPU SoC, but is well applicable to all multi-CPU SoCs.
Overview of dual-CPU architecture
Figure 1 below shows the architecture of a typical dual-CPU SoC. The blocks in blue implement on-chip redundancy which we call Sphere of Replication (SoR). Each SoR contains identical CPUs (e200z4), eDMA controllers, interrupt controllers, crossbar bus systems, system timers, software watchdog timers, etc.
The blocks in pink are redundancy checkers (RC), which check the outputs from both the SoR and signals fault to FCCU (fault control and collection unit) in case of a mismatch. The blocks in yellow are the modules accessible by both of the CPUs.
Dual-CPU SoCs may broadly operate in two modes:
Defining typical run conditions for current consumption
- Lock Step Mode (LSM): CPUs in both the SoRs execute the same instruction cycle by cycle and any differences between the outputs of the CPUs indicates a fault and triggers a reaction to prevent propagation of the fault and to put the microcontroller into a fail-safe mode.
- Decoupled Parallel Mode (DPM): In this mode, each CPU runs independently. This mode of operation puts the chip into a symmetric multi-CPU processor mode with both processors having individual control of their peripherals. DPM increased performance can be estimated as about 1.6 times the performance of the LSM operation at the same frequency.
As discussed earlier, defining typical Run-Idd conditions (TRC) is the first and foremost step before proceeding to measure the power requirements of a SoC. Bear in mind that customers are interested in knowing the worst-case power requirements of the device, but still realistic enough to match closely with the most probable operation of their application.
For the dual-CPU SoC under consideration, there were various discussions held with systems, applications, and design teams. Some prototype experiments were conducted on silicon to accurately define the TRCs. The factors which were found to have direct influence on the Run-Idd numbers are:
1) LSM or DPM mode of operation:
Selection of SoC mode of operation is mainly dependent on the customer use-case scenario. But for the worst case power consumption, because LSM mode has both CPUs executing instructions simultaneously all the time, the maximum core activity occurs in LSM mode and hence is TRC1
for the worst-case power measurement.
2) Frequency of operation:
The CPUs in SoC under consideration work at a maximum frequency of 180 MHz with the rest of the system operating at 90 MHz. Experiments done on real silicon showed that the current numbers are directly proportional to the frequency of operation. The graph of Figure 2 below depicts the dependency of core and I/O current on the CPU operating frequency.
Figure 2 Power vs. operating frequency
So it was decided to take current measurements at the highest frequency of operation, i.e. 180 MHz. This is TRC2
3) Cache enabled operation:
The enabling of the instruction and data cache allows faster CPU execution owing to lesser memory access time, which in turn should cause higher current consumption on the core voltage. This was established during our prototype experiments and hence is TRC3
4) CPU execution time vs. peripheral execution time: For SoCs, the total execution time is divided between CPU execution time and peripheral execution time. Experiments done on real silicon showed that for a given condition, power consumption on core voltage is directly proportional to the CPU execution time, i.e. the higher the CPU execution time, the higher the core current consumption.
A quick look at the graph shown in Figure 3 provides a clear picture of this dependency.
Figure 3 Power vs. CPU execution time
To obtain the optimum numbers matching with typical customer use cases, we decided to keep the CPU-to-peripheral execution- time ratio as 80:20. This is TRC4
5) Miscellaneous Factors:
There are many other factors which are SoC specific that can have considerable effect on the current consumption. For example, for the SoC under analysis, the CPUs implement complex signal-processing and FFT (fast Fourier transform) instructions. The execution of these instructions by a CPU has a direct impact on the core current consumption. For other SoCs, such factors having direct impact on the core current have to be identified and that becomes the TRC5