The automotive industry is going through quite a change in the way it designs electronics for in-vehicle systems. The traditional approach has been to procure an Electronic Control Unit (ECU) for each major functional area, and to glue them together via control buses (typically CAN bus, but also others like FlexRay). This started in the 1990s when CAN bus was called ‘multiplex’ (because it allowed multiple signal wires to be eliminated and the transmission of small signal values over a sigle bus). Since then this approach has grown like crazy: multiple CAN buses with gateways and many, many ECUs (it’s not unusual to see a hundred in a car now). This is clearly getting out of control, and there’s now a trend towards a centralised architecture: a few powerful ‘domain controllers’ talking to smart I/O devices (e.g. motors with integrated control devices).
A centralised architecture brings a new set of challenges: software partitioning. If ECU functions are to be moved into a single CPU then how can the failure of one component be prevented from cascading into another component? No supplier of software can assume liability if the behaviour of unrelated software causes it to fail. This applies to performance, of course, but it also applies to security: a vulnerability in one component cannot be allowed to breach the secuirty of another.
The problem is made worse by the performance required: if the microcontrollers of a hundred ECUs are to be replaced by a single CPU then this far exceeds the performance of high-end CPUs we see today. The clock rate is limited to about 1GHz (particularly over the temperature range of automotive systems have to run reliably), which is not 100x the clock rates of ECU microcontrollers. The current approach of putting more cores on a CPU doesn’t scale: the memory architecture with multiple cache levels and a shared bus matrix simple won’t handle dozens of cores.
What’s needed is a new CPU architecture that can handle the high performance computing requirements of automotive systems:
- Allowing software components in binary form from different suppliers to run on a single CPU.
- Components with security and real-time performance guarantees.
- Highly efficient architecture able to cope with thousands of components with a CPU load equivalent to dozens of today’s high-end CPUs.
We have published a white paper [22 page PDF] that looks to history as a guide to addressing these problems. Modern CPU design is now stuck, similar to when CISC computing was stuck in the early 1980s: designed for a problem that wasn’t relevant to a new way of building software. What is needed today is a repeat of the then RISC revolution in CPU design, formulating a new architecture designed specifically to address the requirements as they are now. We looked to history for a solution, one that failed then but where today the time is right to revisit the concepts: the Inmos Transputer.
Instead of a few fast CPU cores, we propose a large number of small efficient cores. The key metric for high performance automotive CPUs will not be MIPS/MHz but MIPS/MHz/mm². We show how a small CPU core like the Arm Cortex M0+ is seven times more efficient than a Cortex M7 when silicon real estate is taken into account: when dealing with thousands of software components it is better to have very many slower CPU cores rather than a few fast ones. We also propose hardware support alongside each CPU core for a secure real-time execution environment, with RTOS functions in hardware and a predictable memory caching scheme.
CPU design is currently going through an exciting phase: RISC-V has led to huge interest and innovation across the board. Our hope is that this white paper stimulates ideas in this field for the next generation of automotive silicon.
