Revolution in der Auto-Kommunikation

»Eine einzige Architektur für unterschiedliche Physical Layer!«

2. November 2022, 11:20 Uhr | Heinz Arnold
Roland Neumann, CTO von Inova
Roland Neumann, CTO von Inova: »Die virtuellen Datenpfade sehen für die Anwender einfach formuliert wie ein Draht aus, egal ob zwischen bestimmten Knoten mit 6 Gb/s seriell oder zwischen anderen mit 60 Gb/s optisch übertragen wird.«
© Inova Semiconductors

Auf der diesjährigen electronica stellt Inova »ADXpress« vor, ein Bus, der die Kommunikation im Auto revolutionieren soll. Was es mit der neuen Unabhängigkeit von den Physical Layers auf sich hat, erklärt Roland Neumann, CTO von Inova, im Interview mit Markt&Technik.

Markt&Technik: Sie haben das Team von Inova geleitet, das den »Automotive Data Express«, kurz »ADXpress«, entwickelt hat. Aus »APIX« hervorgegangen unterscheidet sich »ADXpress« jedoch so stark von seinem Vorläufer, dass Inova dem jüngsten Spross einen neuen Familiennamen verliehen hat. Was ist der Hauptunterschied?

Roland Neumann: Beim »Automotive Pixel Link«, kurz »APIX«, handelt es sich um eine Punkt-zu-Punkt-Verbindung mit dem Schwerpunkt auf der Übertragung von Videodaten. Diese Beschränkung wollten wir aufheben und haben deshalb erstens die Architektur geändert und zweitens die Art und Weise, wie die Daten übertragen werden. ADXpress überträgt beliebige Daten unabhängig voneinander über virtuelle Datenpfade.  

Die Änderung in der Architektur dürfte den Anwendern zunächst am meisten ins Auge fallen. Was hat sich genau geändert?

»ADXpress« ist ein Netzwerk: Die »APXpress«-Chips bilden jeweils die Knoten in dem Netzwerk, das sich beliebig konfigurieren lässt. Die Verbindungen sind jeweils bidirektional, bei jedem Knoten handelt es sich also um einen Router im Netzwerk, der Daten annimmt und weiterleitet. Jeder Knoten kann aber auch eine Gateway-Funktion übernehmen, denn er packt die Daten in Pakete und schickt sie über die virtuellen Kanäle. Deshalb sind die Chips mit seriellen Schnittstellen ausgestattet. Das gelingt unabhängig davon, ob es sich um Streaming-Daten handelt, die nicht unterbrochen oder wiederholt werden können, oder ob es sich um Burst-Daten handelt. Dafür stehen ebenfalls die entsprechenden Schnittstellen wie SPI oder I2C zur Verfügung. 

Wie viele virtuelle Datenpfade stehen zur Verfügung?

Es können bis zu 128 virtuelle Datenpfade realisiert werden. Die Datenpfade basieren auf Datenpaketen konstanter Größe. Die Datenpakete erhalten eine Adresse, die einen eindeutigen Weg durch das Netzwerk festlegt. Wenn beispielsweise Daten von Knoten 1 über Knoten 2 und 3 zu Knoten 4 geschickt werden, erhält das Paket die Adresse 4 zugewiesen. Die Adresse ist statisch, die Pakete werden immer über denselben Weg versendet. Es entstehen also paketierte Datenströme, die Datenübertragung ist deterministisch. Wir stellen auf unserem Stand zwei Demonstratoren auf Basis unterschiedlicher FPGAs vor. Ein Demonstrator erreicht 20 Gb/s, der zweite wird bei voller Ausbaustufe 30 Gb/s oder 4 x 24 Gb/s über Lichtwellenleiter erreichen. Die Summe der Datenraten aller virtuellen Kanäle einer Verbindung von Knoten zu Knoten darf dabei die Physical Layer Bandbreite zwischen diesen Knoten nicht überschreiten. Die Datenrate von 30 Gb/s haben wir deshalb gewählt, weil die Kabel im Auto diese Datenraten gerade noch schaffen. Die virtuellen Datenpfade sehen für die Anwender einfach formuliert wie ein Draht aus, egal ob zwischen bestimmten Knoten mit 6 Gb/s seriell oder zwischen anderen mit 4 x 24 Gb/s optisch übertragen wird.   

Die Datenübertragung auf dem seriellen Medium passiert nach wie vor wie bei »APIX« mit einer Framestruktur aus Sync- und Daten-Symbolen und nicht in Paketen?

Ja, die Datenübertragung findet in Frames statt und die Datenraten sind über die jeweilige serielle Schnittstelle definiert. Jeder Frame wird mit codierten Daten (Symbolen) und einem regelmäßig wiederkehrenden Synchronisationssymbol belegt und so über die jeweiligen Links geschickt. Das war auch das Prinzip von »APIX«. Die Anwendungsdaten werden aber in Datenpakete verpackt und diese zu einem Paketdatenstrom zusammengefasst. Auf serieller Ebene sind wir also in Frames unterwegs, in die die Pakete eingebunden werden. Sie können groß oder klein sein und wenn keine Daten (Pakete) zu übertragen sind, dann werden leere Pakete verschickt. Damit wird die Paketdatenrate der seriellen Framedatenrate für eine kontinuierliche Übertragung angepasst. Die Physical Layer wird praktisch von der Paket-Ebene entkoppelt. Auf der Paket-Ebene, der Ebene der virtuellen Kanäle, werden verschiedene Pakete – je nach Applikation – verschickt, beispielsweise für Video oder LiDAR. Ich vergleiche das gerne mit verschiedenen Straßen – Nebenstraßen, Bundesstraßen und Autobahnen. Die Knoten entsprechen den Kreuzungen und die Datenpakete entsprechen in diesem Bild den Autos. Grüne Autos wären dann die Videodaten, blaue Autos die LiDAR-Daten. Wir können die Daten so über beliebige serielle Physical Layers übertragen, die Bandbreiten sind einstellbar – dabei muss die Summendatenrate der virtuellen Datenpfade kleiner gleich der Bandbreite des seriellen Mediums zwischen den entsprechenden Knoten sein. Die Physical Layer kann je nachdem gewählt werden, wie viel und wie schnell zwischen den jeweiligen Knoten übertragen werden muss.

Die entsprechenden Schnittstellen und die Funktionen für das Packen der Pakete sind auf den Chips integriert?

Ja, das unterscheidet uns von anderen Bussen, die oft in Software paketieren. Bei uns geschieht alles in Hardware. Unsere Chips benötigen keine Treiber für die Datenverarbeitung! Das spart eine Menge Overhead. Alles in Hardware zu realisieren, war übrigens von Anfang an die Strategie von Inova, von unserer ersten »GigaStar«-Familie über die drei »APIX«-Generationen bis zum neuen »ADXpress«. Der große Vorteil: geringe Latenzzeiten.

Warum ist auch die Übertragung über LWL vorgesehen, sie spielt doch im Auto kaum eine Rolle?

Derzeit nicht, aber ich halte es für sehr wahrscheinlich, dass auch die optische Übertragung demnächst ins Auto Einzug halten wird. Darauf wollten wir mit »ADXpress« vorbereitet sein, wir wollen eben maximal unabhängig sein. 

Eine weitergehende Unabhängigkeit will Inova auch auf der Ebene des Design-Prozesses schaffen. Was ist in dieser Hinsicht neu?

Für die Entwicklung der Architektur haben wir sie zuerst mit SystemC modelliert. Es handelt sich einfach gesagt um C++ plus einer Bibliothek. Wir haben unseren Coding-Style so gewählt, dass sich das Ergebnis fast eins zu eins in eine Hardwarebeschreibungssprache umsetzten lässt, gleichzeitig lässt sich aber auch alles, was man in C machen kann, einbinden. Man kann so beispielsweise das Spektrum des seriellen Datenstroms berechnen und verschiede Kanalmodelle mit unterschiedlichen Fehlercharakteristika modellieren und simulieren. Weil die Entwickler das System also auf dem PC modellieren, können sie sehr schnell simulieren und ausprobieren, ob alles funktioniert. Dann wird das Design in ein FPGA übertragen. Auf diese Weise lassen sich viele Systemfehler vermeiden. Das fällt bei der hohen Komplexitätsebene, die »ADXpress« erreicht, stark ins Gewicht. 
 
Was bedeutet der Einsatz von SystemC für den Entwicklungsprozess?

Wir können sehr früh im Entwicklungsprozess das Gesamtsystem deutlich schneller simulieren als bisher. Darüber hinaus führt dieser Design-Prozess zu zusätzlichen Vorteilen: Erstens liegt jetzt eine eindeutige Systembeschreibung vor, über die so definierten Spezifikationen lässt sich nicht mehr streiten. Zweitens hat es auch einen Effekt auf unser Ökosystem und wird uns viele neue Möglichkeiten eröffnen. Wir können jetzt zusammen mit den Kunden Hardware-nah modellieren und sie in die Modellierung des Systems mit einbeziehen. Das führt zu einem funktionierenden System im ersten Schritt, was entscheidend für die Kosten ist. Denn teure und langwierige Re-Designs wollen und können sich die Systemhersteller gar nicht mehr leisten! 
 

Anbieter zum Thema

zu Matchmaker+

Das könnte Sie auch interessieren

Verwandte Artikel

INOVA Semiconductors GmbH