This article refers to the address: http://

The automotive industry is booming, and in-vehicle infotainment systems are no longer the exclusive facilities of luxury cars. More and more mid- and low-end cars are starting to have their own infotainment systems.

However, the in-vehicle infotainment system is a highly integrated and complex system, which can include navigation systems, audio-visual systems, telephone systems, air-conditioning ventilation systems, and other control systems for interior and exterior comfort devices. The communication networks involved in these systems can include LINK_KEYWORD0. , MOST, LIN, Bluetooth and other wireless network protocols. Designing such a complex system requires not only the performance and cost of the system, but also the flexibility of the design to keep the product competitive in a rapidly changing market.

Automotive electronic systems require a wide range of temperature adaptations, which facilitates production standardization and long design life. The in-vehicle infotainment system is a system that is rapidly developing and adapting to various users. If you want to maintain a design with a long life and a high degree of flexibility, then this design must be very good in hardware and software, especially in hardware. Strong scalability.

In general, in-vehicle infotainment systems have complex human-machine interfaces (buttons and knobs) with a liquid crystal display that can display maps, images, and car information, and sometimes a touch screen. Such systems are typically centered on a high performance MCU with a variety of standard interfaces and a video acceleration device.

DSP, ASSP and FPGA can be used to implement a variety of interfaces and video processing. D

Designed for signal processing, the SP features high flexibility and low power consumption. However, the computing power of DSP currently cannot meet the requirements of higher image processing and wireless communication at the same time. ASSPs are typically designed for a standard image processing and wireless communication, in other words, they do not have programmability to accommodate multiple standards. The FPGA also has high computing power and field programmability of internal logic, which can adapt to the flexibility of the in-vehicle infotainment system. In addition, the field programmability of the FPGA makes it possible to replace many of the functional units that were originally implemented by the ASIC, which gives the hardware design a lot of freedom.

With the design of the MCU+FPGA, the software and peripheral hardware can be changed in the FPGA. The whole system is equivalent to a software that is easy to upgrade. Changing the hardware is as simple as changing the software. Such systems can meet the requirements of design, test and production of low-end to mid- to high-end automotive electronics. Therefore, the design based on MCU+FPGA brings great flexibility to the in-vehicle infotainment system.

After establishing the basic hardware framework, it is time to consider the choice of chips based on this framework. For a complex human-computer interaction system such as in-vehicle entertainment information system, a high-performance and high-security embedded real-time operating system is the preferred software foundation. The chipset supported by the operating system will be the main candidate for the MCU. Currently, the combination commonly accepted in the automotive industry is SH4 (MCU) plus QNX (Operating System).

The choice of FPGA is relatively easy, at least the products of five companies including Xilinx, Altera, Lattice, Actel and Quicklogic can be considered. Xilinx and Altera are industry leaders in FPGAs, and their products are widely used and there are a large number of standard libraries available. The block diagram of Figure 1 is a schematic diagram of the basic structure of a hardware.

After considering the hardware, the architecture of the software becomes clear. Because QNX supports the POSIX specification, modular applications and application development libraries based on it are well ported, which is a cost-effective solution for the development of other platforms that support similar software architectures.

硬件的基本构成示意图

Click to see the original picture

Figure 1: Schematic diagram of the basic structure of the hardware.

The conceptual design of the software architecture can actually begin before the operating system is clear. Software design does not have to comply with the POSIX specification, but to meet the high performance of the system, the modularity of the design, the scalability of the application, and the reusability and portability of the code.

Usually a complex software system based on MCU should define the following software layers:

BSP: handles transactions related to MCU initialization, such as IPL (Initial Program Loader) and Startup Program;

Device driver: All hardware-related programs, such as FLASH driver, CAN driver, and graphics driver;

OS: The core operating system, which provides services such as resource management and security task scheduling. It can even include some high-level drive devices, such as standard input and output device drivers.

Middleware: Programs between the operating system and applications, such as various APIs and FPGA Loaders;

Application: A highly reusable program module that performs specific functions, such as media players and navigation software.

Under the MCU+FPGA architecture, each FPGA-related application comes with an initialization routine. The initialization routine maps the application to the FPGA before it needs to be launched, and then the application runs on the FPGA. Depending on the requirements of the application, the MCU can maintain strong or weak communication with the FPGA after the mapping is completed. This structure partially liberates the MCU, enabling it to efficiently perform task scheduling and resource management, while FPGAs can operate efficiently in specific environments. Another benefit of this system is that it is very stable and easy to maintain. Bad actions or crashes of applications running in the FPGA usually do not affect the operating system running in the MCU. After discovering that an application has failed, the operating system can gracefully restart the application's new routine without having to restart the entire system.

Applications running in FPGAs, although seemingly indistinguishable from systems running in ASICs or ASSPs, actually have a very different structure. The system running in the ASIC or ASSP is designed according to the determined hardware environment with specific functions, and the application running in the FPGA adjusts the logic unit of the FPGA to adapt to the environment according to the functions to be completed. It is the field programmability of FPGAs that allows us to launch the right application at the right time, which greatly increases the flexibility of the design.