Sie wird derzeit international von rund 50 autoproduzierenden Unternehmen eingesetzt, ist in jedem zweiten aktuell produzierten Fahrzeug enthalten, und im Bereich der Motorsteuerungen ist die Single-Tricore-Architektur sogar weltweit marktführend. Die weiteren Aussichten: Tendenz weiter steigend.
Die bei den aktuellen TC27x-Derivaten verwendete Aurix-Architektur-Variante verfügt über drei TriCore-Kerne. Die zwei TriCore-1.6P-Kerne – das „P“ steht hier für Performance – können bis zu drei Befehle in einem Zyklus abarbeiten und arbeiten mit einer maximalen Taktfrequenz von 300 MHz. Der Efficiency-TriCore-1.6E hingegen ist auf geringe Leistungsaufnahme und einen effizienten Datenaustausch mit der Peripherie optimiert.
Dem Efficiency-TriCore-1.6E und einem der beiden Performance-Core sind noch je ein Lockstep-Core zugeordnet, der auf dem Chip räumlich und schaltungstechnisch isoliert im Lockstep-Mode mit zwei Zyklen Verzögerung die gleichen Maschinenbefehle wie der eigentlich Core ausführt. Eine Logik vergleicht die Ergebnisse und kann bei Abweichungen mit Interrupt oder Reset auf diese Ausnahmesituation reagieren. Dank diesen hardwaremäßigen Voraussetzungen lässt sich die AURIX-Architektur auch in Applikationen verwenden, die dem ASIL-D-Standard genügen müssen.
Neben den TriCore-Kernen implementierte Infineon noch zwei weitere mit eigener Maschinensprache programmierbare Einheiten auf dem Chip. Das auf einem Standard-Mikrocontroller-Core basierende Hardware-Security-Modul (HSM) dient dem Software-Schutz, das Generic Timer Modul (GTM) hingegen lässt sich für Zeitmessungen, Capture/Compare von digitalen Eingangssignalen und Pulsweitenmodulationen (PWM) einsetzen. Mit Unterstützung des GTM können also einige für eine Motorsteuerung zwingend benötigte Funktionen optimiert und autonom von den TriCore-Kernen ausführt werden.
Obwohl die Architektur der AURIX-Familie vor allem im Hinblick auf Powertrain-Anwendungen optimiert wurde, lassen sich die unterschiedlichen Bausteine dank ihrer uneingeschränkten Automotive-Qualifizierung und vieler flexibel einsetzbarer Peripherie-Einheiten ebenso gut in den Bereichen Aktive und Passive Sicherheit, Body sowie Fahrer-Assistenzsysteme einsetzen.
Einer dieser besonders leistungsfähigen und teils sehr komplexen Peripherie-Blöcke ist das oft erst auf den zweiten Blick auffallende CIF (Camera and ADC Interface)-Modul. Dieses Modul bietet dem Anwender nicht nur eine physikalische Schnittstelle zu verschiedenen Typen von Kamera-Modulen, sondern beinhaltet bereits auch Funktionen für Bildverarbeitung und Codierung. Dabei werden sowohl intelligente, bereits ein YCbCr-Signal liefernde Kameras als auch der Transport von Rohdaten wie zum Beispiel Bayer-Pattern und nicht frame-synchronisierte Datenpakete unterstützt. Weitere Eckdaten des CIF-Moduls sind ein internes 16-Bit-Parallel-Interface mit einem maximalen Durchsatz von 96 MPixel/s, eine maximale Auflösung des Eingangssignals von 4095 x 4095 Pixeln, eine hardwarebasierte Bildstabilisierung, eine integrierte YCbCr-4:2:2-Verabeitung, ein JPEG-Encoder, die Definition von bis zu sechs Subregionen im aufgenommenen Bild/Stream für die Weiterverarbeitung sowie das Vertauschen von Helligkeits- und Farbsignalen (Luminanz/Chrominanz) oder von Rot- und Blau-Signalen für bestimmte Arten der Mustererkennung.
ADAS mit AURIX
Durch das integrierte CIF-Modul lassen sich AURIX-Multicore-Mikrocontroller bei Bedarf jederzeit auch als zentrale Steuereinheit in kamerabasierten Fahrerassistenzsystemen nutzen (Bild 1). Typische Anwendungsbeispiele sind das automatische Umschalten von Abblend- auf Fernlicht, optische und/oder akustische Warnhinweise bei Spurüberschreitung, Kollisionswarnungen oder die automatische Erkennung von Verkehrszeichen. All diese Applikationen können mit AURIX-MCUs zukünftig wesentlich kompakter und mit deutlich geringerem Hardwareaufwand als bisher realisiert werden. Zudem sind die voll ISO26262-spezifizierten Aurix-MCUs deutlich kostengünstiger als FPGA-basierte Lösungen und skalierbar sowie über den gesamten Automotive-Temperaturbereich einsetzbar.
Die grundsätzliche Funktionsweise des CIF-Moduls besteht in der Erkennung von Strukturen, Mustern und Objekten im Videosignal, gegebenenfalls auch ihrer Extraktion beziehungsweise Ableitung von Aktionen. Ein interessanter Aspekt hierbei ist die Softwareentwicklung für solche Systeme. Die Entwicklung und Verfeinerung der Kernalgorithmen erfolgt typischerweise auf Desktop-Rechnern. Dennoch kommt man freilich nicht umhin, irgendwann auch das reale System zu testen, zu debuggen und weiterzuentwickeln.
Mechanismen
Werfen wir zuerst einen Blick auf die Mechanismen, die Infineon allgemein für das Debugging solcher Multicore-SoC und speziell auch für das Kamera-Interface vorgesehen hat. Generell enthält jeder AURIX-Serienchip zwei Debugging-Schnittstellen: zum einen das klassische JTAG-Interface, zum anderen den moderneren Device Access Port (DAP), eine Eigenentwicklung von Infineon. Letzteres zeichnet sich durch eine verringerte Pin-Anzahl aus. Mit erhöhtem Takt wird dennoch die Bandbreite der JTAG-Schnittstelle erreicht, teils sogar übertroffen. Darüber hinaus ist das Protokoll noch durch Checksummen abgesichert, was die Stabilität der Verbindung zwischen Chip und Tool weiter erhöht. Ergänzt werden die Debug-Schnittstellen außerdem von einer On-Chip-Logik, mit der sich bis zu acht Code- oder Daten-Breakpoints pro TriCore-Core sowie weitere Triggerbedingungen realisieren lassen.
Zudem stehen für Kalibrierung, Trace, anspruchsvollere Tests sowie komplexe Fehlersuche neben den Serienchips noch spezielle sogenannte Emulation-Devices zur Verfügung. Diese sind nur für die oben genannten Aufgaben und nicht für den Feldeinsatz vorgesehen. Die Emulation-Devices haben dasselbe Footprint wie die Serienchips, sind aber intern zusätzlich mit einem bis zu 2 MByte großen Emulationsspeicher und zusätzlicher Emulationslogik ausgestattet. Der Speicher wird entweder als Overlay-Speicher für den auf dem Chip integrierten Flash-Speicher von Kalibrierungs-Tools oder von Debuggern als Trace-Speicher genutzt. Neu hinzugekommen bei den Multicore-Emulation-Devices ist außerdem eine auf dem Aurora-Protokoll von Xilinx basierende serielle Hochgeschwindigkeitsschnittstelle für schnelle Datentransfers von bis zu 2,5 GBit/s. Über die Aurora-Lane kann ein Trace-Strom ausgegeben und Off-Chip aufgezeichnet werden. Damit lassen sich auch Messaufgaben wie Profiling und Code-Coverage, die eine große Menge an Trace-Daten erfordern und für die der On-Chip Emulationsspeicher nicht ausreicht, realisieren.
Auch das CIF-Modul ist an das Aurora-Interface angebunden. Nach der Bildstabilisierung lassen sich die internen Daten über einen Debug-Pfad auslesen. Dabei kann zwischen dem gesamten Bild/Frame oder einer der definierten Subregionen ausgewählt werden. Die Verbindung mit dem Aurora-Interface ermöglicht einen schnellen Transfer der Daten auf einen Host-PC und dadurch eine besonders zügige Visualisierung beziehungsweise Analyse und Weiterverarbeitung der Daten für Fehlersuche und Tests.
Demo-Kit
Um den Einsatz von AURIX-SoCs in kamerabasierten Fahrerassistenzsystemen weiter zu vereinfachen, hat Infineon in enger Zusammenarbeit mit PLS ein spezielles Demo-Kit entwickelt (Bild 2). Es besteht aus einem AURIX-TriBoard mit aufgesetzter Kameraplatine und einer Beispielapplikation, welche die JPEG-codierten Daten über die Ethernet-Schnittstelle des AURIX-SoC zu einem PC transferiert und dort in einem speziellen Programm darstellt. Die Kamera stammt von OmniVision, für die Weiterleitung der internen, über das Aurora-Interface bereitgestellten RAW-Daten kommt ein Universal Access Device 3+ (UAD3+) von PLS mit entsprechendem Debug- und Aurora-Trace-Pod zum Einsatz.
Bei herkömmlichen Trace-Aufgaben zeichnet der bis zu 4 GByte große Trace-Speicher des UAD3+ während einer Messaufgabe Daten auf, die anschließend analysiert werden. Das Kamera-Interface hingegen erfordert ein kontinuierliches Streamen der Daten zum Host-PC, um eine Analyse und Visualisierung der Daten nahezu in Echtzeit zu gewährleisten. Letzteres wurde durch entsprechende Anpassungen der UAD3+-Firmware und einer neuen Programmversion der Universal Debug Engine (UDE) möglich, die nun erstmals auch einen Video-Viewer zur Darstellung der gestreamten Daten beinhaltet. Nach dem Laden und Flashen lässt sich die Beispielapplikation direkt über den Debugger starten. Anschließend kann das Bild mittels Video-Viewer aus den internen RAW-Daten des CIF-Moduls decodiert und innerhalb der Debugger-Oberfläche dargestellt werden (Bild 4). Beim zusätzlichen Laden von symbolischen Informationen aus dem ELF-File der Beispielapplikation ist auch ein Debuggen dieser Informationen durch Start/Stopp, Setzen von Breakpoints, Darstellung von Variablen, Registern und Speicherinhalten usw. möglich.
Neben der Visualisierung kommt dem Debugger eine weitere wichtige Aufgabe zu. Er muss die RAW-Daten des CIF-Moduls dritten Applikationen auf dem PC zur Verfügung stellen, die beispielsweise zur Entwicklung von Routinen für die Mustererkennung zum Einsatz kommen. Im Fall der Universal Debug Engine erfolgt dies über eine COM-Schnittstelle (COM: Component Object Model), die sich für die Übertragung der CIF-Daten entsprechend den Anforderungen des jeweiligen Anwenders hinsichtlich Format und Bandbreite erweitern lässt.
Das Beispiel des integrierten CIF-Moduls lässt erahnen, dass die noch junge AURIX-Mikrocontrollerfamilie in den nächsten Jahren nicht nur im Powertrain-Bereich, sondern auch in vielen anderen Bereichen der Fahrzeugelektronik zum Einsatz kommen wird. Für die Hersteller von Entwicklungs-, Test und Debug-Tools stellen solche multifunktionalen Hochleistungs-SoCs indes eine riesige Herausforderung dar, denn um Anwendern die theoretischen Möglichkeiten einer AURIX-MCU in ihrer ganzen Komplexität und Einsatzbreite praktisch zu erschließen, bedarf es komplett neuer intelligenter modularer Lösungsansätze im Hard- und Softwarebereich.
Auf einen Blick
Demo-Kit für AURIX-SoCs
Um den Einsatz von AURIX-SoCs in kamerabasierten Fahrerassistenzsystemen weiter zu vereinfachen, hat Infineon in enger Zusammenarbeit mit PLS ein spezielles Demo-Kit entwickelt, bei dem sich die Beispielapplikation nach dem Laden und Flashen direkt über den Debugger starten lässt.
Dipl.-Ing. Heiko Rießland
(av)