The integration imperative
4 mins read
In today's high mobility society, the car is becoming just another connected device in the web. The driver expects to access the same information in their vehicle as they do in all other areas of life. These expectations will not be met without a significant contribution from electronics.
![](/media/iujnkhni/soc1.jpg?width=1002&height=564&bgcolor=White&v=1d9d7669f79b590)
Information technology is becoming the mainstay of driver assistance, trip support, vehicle management and car-to-x communication concepts that are being developed, such as the EU funded Intersafe-2 project, which is looking to reduce the number of accidents at intersections.
Some of the required technologies have been available for some years in other engineering domains, including highly efficient electric drives in automation and connectivity in mobile communications. Others have been tested successfully in prototype vehicles. The challenge now is to adapt them to mass production in the automotive environment and to make them available in the volume segments, rather than the premium segment.
While first system generations are often discrete multichip implementations using COTS devices, the main challenges for large scale adoption are reductions in cost, power consumption and the overall installed size, while achieving automotive quality and lifetime goals.
Progress in semiconductor technologies has enabled higher chip integration. Through smaller dice and higher yield, deep submicron processes allow the efficient implementation of high gate count devices, of SoCs.
In contrast with a microcontroller, which typically has a generic peripheral mix designed to address a whole market segment or a broader range of applications in very high volume production, a SoC is typically more complex and tailored for a dedicated application.
To achieve the set goals, SoCs often have to accommodate diverging or conflicting requirements emerging from different worlds, whether they are architectural, real time or physical semiconductor process requirements.
One of the first automotive application areas that will benefit from SoCs is sensing. Elaborate control schemes require more accurate knowledge of the state of the vehicle in order to efficiently control complex physical processes, such as combustion and vehicle dynamics. The control strategies need to process a growing number of physical parameters. Sensing element, data processing and data transmission require different process optimisations.
ARM has been involved in the automotive microcontroller and system on a chip markets for many years; initially through implementations which used the ARM7TDMI processor and, more recently, with the ARM Cortex family.
CMOS technology is the best choice for digital performance and scaling while bipolar transistors are usually optimal for analogue performance. The advent of technologies like high performance cmos and bicmos have removed many of the compromises that previously had to be made. However, mixed signal processes are typically on a coarser technology node than mainstream cmos processes.
Lower logic density implies that 8bit cpus, such as the 8051, are still widely used. The ARM Cortex-M0, with its small footprint and low power consumption, removes the last remaining compromise, making the processing performance, ease of use and programmability of 32bit risc cpus available in automotive friendly semiconductor manufacturing processes. We will see ARM based devices for battery monitoring, tyre pressure monitoring and many more.
Under the hood systems are a second area to benefit from SoCs. Safety critical systems mandate compliance to ISO26262, which states that for the highest safety class – ASIL-D – 99% of all dangerous faults need to be detected, including transient and intermittent faults in the processing elements and memories.
This requires a dedicated diagnostic channel to monitor the cpu as well as error correction for the memories. There are several approaches to implement this diagnostic channel. From heterogeneous multicore architectures with integrated safety controller based to lock-step architectures, ARM's embedded Cortex-R4F and Cortex-M3 cpus are both designed to support ISO26262 compliance. With Cortex-R4F, lock-step architecture is a synthesis option, while Cortex-M3 features an observation port for Yogitech's fr_CPU diagnostic module to simplify implementation of safety critical systems (see figure 2).
A further domain subject to stringent regulation is engine management. The EU has defined a series of Directives introducing increasingly tight emission control standards. The latest, Euro 6, will be introduced in September 2014. To comply with these standards and achieve the emissions goals, models are needed that employ complex mathematics to control and diagnose a physical combustion process efficiently. On the other hand, hard real time response is mandatory to control injection and ignition timing. These two approaches impose different architectural choices for the cpu. The optimal solution is multiprocessing, with one or more Cortex-R4Fs to handle the maths and a Cortex-M3 to service the engine timer in the real time domain.
But probably the greatest opportunities for SoCs are found in instrumentation and infotainment. The days of the dashboard being a 'dial and switch housing' are numbered: analogue gauges with pointers, rudimentary dot matrix graphics and warning lights are no longer sufficient to present the increasing load of information to the driver. The trend is towards new concepts combining a classic speedometer and RPM gauge with enhanced WQVGA or WSVGA graphics. But there is also a move towards fully reconfigurable instrument clusters based on tfts or lcds. Classic 'head down' instruments are being supported by 'head up' displays, making the most critical information available in the driver's field of view.
The instrument cluster is still a typical Autosar based system, whereas the most popular graphics technology, OpenGL-ES, originates in the consumer world and has different software requirements to the operating system, as well as to the device architecture. Today, this is solved using two devices, but the next step will be integration to address a broader range of vehicles.
Devices combining a Cortex-R4F cpu with a graphics processing unit are emerging, while Cortex-A based devices are being prepared for the following generation. The challenge is to make Autosar and a platform OS coexist safely and securely on one device and this will be solved through multiprocessing and hardware supported virtualisation.
New driver information and multimedia concepts take this complexity one step further. Tools and functions to design and implement GUIs and HMI, audio and video codecs and stacks for handling the consumer connectivity to the outside world are best supported by a platform OS. Autosar connectivity (CAN) is still required for integration in the vehicle network.
Some proposed system solutions look quite similar to a computing platform, with a processor, system hub, fpga and collection of other devices, including an mcu for the automotive side. However, this bill of materials is far too expensive for a large scale adoption in the high volume segments. Here, ARM11 and Cortex-A based system chips, combining the connectivity modules and the processing elements of both worlds, allow significant cost, power and size reductions.
SoC designs usually consume less power and have a lower cost and higher reliability than the multichip systems that they replace. And with fewer packages in the system, assembly costs are reduced as well. They enable more reliable, more robust, power and cost efficient solutions. With a coherent portfolio of cpus covering all performance points, ARM is well positioned to serve growing demand for automotive SoCs.