Compact solution for camera-based driver assistance systems
The single TriCore architecture is currently in use internationally by around fifty automobile manufacturers, it is contained in every second vehicle that is currently produced, and in the field of motor controls it is even the market leader worldwide. This is a success story that Infineon hopes to top in future with the AURIX (AUtomotive Realtime Integrated neXt generation architecture) multicore microcontroller (MCU) family. Given the enormous performance of this new architecture, the chances of achieving this are certainly not bad.
Figure 1: AURIX architecture (source: Infineon). For full resolution click here.
Figure 1 shows the AURIX architecture variant with three TriCoreTM cores used with the current TC27x derivatives. The two TriCore 1.6P cores — P stands for performance — can execute up to three instructions in one cycle and operate with a maximum clock frequency of 300 MHz. The efficiency TriCore 1.6E, on the other hand, is optimized for low power consumption and an efficient data exchange with the periphery.
The efficiency TriCore 1.6E and one of the two performance cores are also each assigned a Lockstep core, which is from the circuit and spatially isolated on the chip. In Lockstep mode, this core executes the same machine instructions as the actual core with a delay of two cycles. Logic compares the results and in the event of deviations can react with an interrupt or reset to this exceptional situation. Thanks to these hardware structures, the AURIX architecture can also be used in applications that have to meet the Automotive Safety Integrity Level D (ASIL‑D) standard.
In addition to the TriCore cores, two further programmable units with their own machine language were implemented on the chip. The standard microcontroller core-based HSM (hardware security module) serves to protect the software. The Generic Timer Module (GTM), on the other hand, can be used for time measurements, Capture/Compare of digital input signals and PWM (pulse width modulation). Therefore, with support of the GTM, some of the indispensible functions for motor control can be optimized and executed autonomously from the TriCore cores.
Although the architecture of the AURIX family was especially optimized with regard to powertrain applications, thanks to their unrestricted automotive qualification and many flexibly useable peripheral units, the different devices can also be used equally well in the fields of active and passive safety, body as well as driver assistance systems. One of these especially powerful and in part very complex peripheral blocks, which is often only noticed at a second glance, is the CIF (Camera and ADC Interface) module. This module not only offers the users a physical interface to various types of camera modules, but also already contains functions for image processing and coding. At the same time, both intelligent cameras that already deliver a YCbCr signal and the transport of raw data such as, for example, Bayer pattern and data packets that are not frame synchronized are supported. Other key characteristics of the CIF module are an internal 16-bit parallel interface with a maximum throughput of 96 Mpixels/s, a maximum resolution of the input signal of 4095 x 4095 pixels, a hardware-based image stabilization, an integrated YCbCr 4:2:2 processing, a JPEG encoder, the definition of up to six sub-regions in the captured image/stream for further processing as well as interchanging brightness and color signals (luminance/chrominance) or from red and blue signals for specific types of pattern recognition.
With the integrated CIF module, AURIX multicore microcontrollers (MCUs) can, when required, also be used as central control unit in camera-based driver assistance systems (Figure 2). Typical application examples are automatic switching from low to high beam, optical and/or acoustic lane departure warning, collision warnings and automatic traffic sign recognition. In future, with AURIX MCUs, all of these applications can be realized significantly more compactly and with considerably less hardware effort than previously. In addition, the fully ISO 26262-compliant AURIX MCUs are considerably more cost-effective than FPGA-based solutions, scalable and can be used over the entire automotive temperature range.
Figure 2: AURIX as camera electronic control unit (source: Infineon). For full resolution click here.
The basic functioning of the CIF module is the recognition of structures, patterns and objects in the video signal, also their extraction where applicable or deriving actions. The software development for such systems is an interesting aspect here. The development and refinement of the kernel algorithms is typically carried out on a desktop computer. Nevertheless, it is obvious that at some point also testing, debugging and further development of the real system can not be avoided.
Let us first look at the mechanisms that Infineon has generally provided for debugging such multicore System-on-Chip (SoC) and in particular also for the camera interface. Each AURIX production chip generally contains two debug interfaces: On the one hand, the traditional JTAG and, on the other hand, the more modern Device Access Port (DAP) which was established by Infineon. The latter features a reduced pin count. Nevertheless, with increased clock the bandwidth of the JTAG interface is reached, in part even exceeded. Furthermore, the protocol is protected by a checksum that further increases stability of the connection between chip and tool. What is more, the debug interfaces are supplemented by on‑chip logic with which up to eight code or data breakpoints per TriCore core (!) as well as other trigger conditions can be realized.
Additionally, beside production devices, special so-called Emulation Devices are available for calibration, trace, demanding tests and complex troubleshooting. These are only intended for the previously mentioned tasks and not for use in the field. The Emulation Devices have the same footprint as the production devices, but are equipped internally additionally with up to 2 MBytes of emulation memory and additional emulation logic. The memory is used either by calibration tools as overlay memory for the on-chip flash or by debuggers as trace memory. Furthermore, a new addition to the multicore Emulation Devices is a serial high-speed interface, based on the Xilinx Aurora protocol, for fast data transfers of up to 2.5 Gbits/s. A trace stream can be outputted via the Aurora lane and be recorded off-chip. Therefore, measurement tasks such as profiling and code coverage — which require a large amount of trace data and for which the on-chip emulation memory is not sufficient — can also be realized.
The CIF module is also linked to the Aurora interface. After image stabilization, the internal data can be read out via a debug path. Thus, it is possible to select between the entire image/frame or one of the defined sub-regions. The connection with the Aurora interface enables fast transfer of the data to a host PC and thereby a particularly rapid visualization, respectively analysis and further processing of data for troubleshooting and tests.
In order to further simplify the use of AURIX SoCs in camera-based driver assistance systems, Infineon developed a special demonstration kit in close cooperation with PLS Programmierbare Logik & Systeme GmbH (Figure 3). It comprises an AURIX TriBoard with an attached camera board and an example application, which transfers the JPEG encoded data via the Ethernet interface of the AURIX SoC to a PC and presents it there in a special program. The camera originates from OmniVision and a Universal Access Device 3+ (UAD3+) from PLS with corresponding debug and Aurora trace pods is used for forwarding the internal, RAW data provided via the Aurora interface.
Figure 3: Block diagram of the demonstration kit for the camera interface (source: Infineon)
With conventional trace tasks, the up to 4 GBytes trace memory of the UAD3+ records data during a measurement task that is subsequently analyzed. On the other hand, the camera interface requires a continuous streaming of the data to the host PC in order to ensure an analysis and visualization of the data almost in real-time. The latter was possible through corresponding adaptations of the UAD3+ firmware and a new program version of the Universal Debug Engine (UDE), which now for the first time also contains a video viewer for displaying the streamed data. After loading and flashing, the example application can be started directly via the debugger. Afterwards, by means of the video viewer, the image can be decoded from the internal RAW data of the CIF module and displayed within the debugger interface (Figure 4). When additionally loading symbolic information from the ELF file of the example application, debugging of this information is also possible through start/stop, setting breakpoints, displaying variables, registers and memory contents, etc.
Figure 4: Universal Debug Engine with video viewer (source: PLS). For full resolution click here.
Besides the visualization, an additional important task is given to the debugger. It must make the RAW data of the CIF module available to third party applications on the PC, which for example are used for development of routines for pattern recognition. In the case of the Universal Debug Engine, this takes place via a Component Object Model (COM) interface, which can be extended for the transmission of CIF data according to the requirements of the user with regard to format and bandwidth.
The example of the integrated CIF module indicates that the yet young AURIX microcontroller (MCU) family will not only be used in powertrain applications over the next few years, but also in many other areas of automotive electronics. However, such multi-functional, high-performance System-on-Chip (SoC) presents a huge challenge for manufacturers of development, test and debug tools. Because, in order to practically open up the theoretical possibilities of an AURIX MCU in their entire complexity and range of applications to users, completely new intelligent modular approaches to solutions are needed in the hardware and software fields.
About the author:
Heiko Riessland (Dipl.-Ing.) studied information technology at the Dresden University of Technology (TU Dresden) in Germany. After the successful completion of his studies, he worked for 12 years in the design and sales of software development tools and emulators for 16-bit and 32-bit microcontrollers. For the past eight years, Heiko heads product marketing at PLS Programmierbare Logik & Systeme GmbH in Lauta, Germany.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
