Dual core architectures in automotive SoCs
Amit Goel & Ankur Sharma, Freescale Semiconductor
8/23/2010 2:17 PM EDT
Automotive SoCs have traditionally been single core, since not much computational work or high end applications were targeted on them. Automotives were simpler, so were the applications and so were the SoCs.
As more and more electronics made room in the automotives, the complexity of the SoCs kept on increasing.
Now the focus is to have most of the automotive under electronic control.
High end automotives produced these days provide features like
electronic stability control (ESC), t
raction control system (TCS),
advanced driver assistance systems (ADAS) etc.
These features require complex SoCs at heart which can collect, process
and transfer data at a fast rate from multiple peripherals.
No matter at how much high frequency the single core is operating on, it will always have performance bottlenecks & challenges while performing multiple tasks. Single core running on higher frequency consumes more power. This makes the single core architecture unfit for ultra low power applications. Dual core based SOC architecture provide better tradeoff in performance and power consumption than single core based architectures.
As a result, the dual core SoCs have now been featuring prominently in the automotive designs. Besides providing higher performance than single core, dual core based architectures are being used for safety applications.
Safety is one of the major concerns for automotive manufacturers. With complex applications been introduced, there is a higher chance of failure of hardware or Software. The designs have to be robust enough so that any failures can be detected and corrective actions be taken.
Dual core based SoCs are also being favored in safety application because of the architectural advantages that they provide.
This article deals with various dual core architectures present in Automotive SoCs
- Heterogeneous dual core architecture
- Homogenous dual core architecture
1. Lock step mode (LSM)
2. Decoupled parallel mode (DPM)
Heterogeneous dual core architecture
Heterogeneous architecture as the name suggests has two different Cores. Since the architecture consists of two cores one of a higher configuration and second one could be of lower configuration, the smaller core is also called the co-processor. While the main core does the bulk of the application, the small core is used for some lesser complex operations like continuously sending data out on I/Os. Hence the term co-processor because even though a second core is present but its main function is to support or compliment the main core.
Fig 1: The architecture of MPC5668G: dual core 32-bit MCU for gateway applications.
The MPC5668G provides two e200 series cores of Power Architecture. E200z6 acts as the main core and e200z0 act as the co-processor. E200z6 Core has the support for floating point unit (FPU), signal processing engineer (SPE), memory management unit (MMU) etc while e200z0 core is much smaller and with fewer features.
Both cores have access to all memory and peripherals along with the other ‘bus masters’ like FlexRay controller and eDMA. The crossbar switch is used to control access and arbitration. Simultaneous requests to a single slave port are granted by round robin arbitration or by fixed priority arbitration. Interrupt controller is enhanced to route the interrupt to any core or both the cores.
When the SoC comes out of reset only the main core e200z6 is up. The main core releases the z0 core out of reset by writing the key in SoC defined registers. Once z0 core is up it can be used for various functions and supporting z6 core.
The z0 core once up can function independently of the main core and can be used for a number of tasks like running communication between different SoCs, I/O processing etc. Thus it reduces the load on the main core and hence freeing up its bandwidth.
Apart from core there is no duplication of any other IP or peripheral. Thus both the cores share rest of the modules in the SoC. For example code (application/debugging) for both cores will be stored in the same flash and they will be using the same SRAM with a single SRAM controller during code processing.
Access to shared peripherals is controlled through semaphores. Semaphores play a key role here and are an integral part of dual core SoCs and are discussed in little details later in the article.
Co-processor approach can be used for various applications:
- For executing a single complex function which can be called by primary core whenever necessary. This gives primary core some free bandwidth to execute other applications. In this way the code can be split between the two cores to ease the load on the primary core. An example is ADC Average Driver Using the IO Processor (IOP) in the MPC5510 (Freescale Semiconductors Application note – AN3813)
- In some safety applications it can be used for error checking of the processes being carried out by the primary core.
- To pre-process incoming data from high speed networks like FlexRay and FEC
- For emulating functionality of certain IPs in the software and getting it executed from the co-processor. Some good examples for this are:
- Emulating a PWM module using the IO processor (IOP) on the MPC5510 (Freescale Semiconductors Application note – AN3737)
- Emulation of a SCI module using the IO Processor (IOP) in the MPC5510 (Freescale Semiconductors Application note – AN3810)
http://www.eetimes.com/design/automotive-design/4206395/Dual-core-architectures-in-automotive-SoCs
——————————————————————————————————————————-