Audio Video Bridging (AVB) Ethernet Implementierung mit XMOS
XMOS Ethernet AVB Implementierung mit XMOS-Controller
Trotz permanenter Erhöhung der Bandbreite und Erweiterung des Standards um Quality-of-Service hat Ethernet heute noch immer mit der Problematik fehlender Echtzeitfähigkeit zu kämpfen. Vor allem zur Übertragung multimedialer Inhalte mit der Notwendigkeit möglichst synchroner Paketzustellung macht sich dieser Mangel unangenehm bemerkbar. Dies könnte sich nun ändern, denn mit der Standard- Erweiterung „AVB“ entsteht eine Möglichkeit zur deterministischen Zustellung von Paketen in einem lokalen Netzwerk. Dies ist recht nützlich zur Distribution von hochwertigem Audio, aber unabdingbar, wenn Ton- und Bild lippensynchron transportiert werden sollen.
 |
Mit 802.1BA zum synchronen Ethernet
Der neue IEEE Standard 802.1BA oder Audio-Video Bridging (AVB), derzeit noch als Entwurf vorliegend, besteht im Wesentlichen aus 3 Erweiterungen, die Ethernet rückwärtskompatibel zur Echtzeitfähigkeit verhelfen. 802.1AS liefert die notwendigen präzisen Zeitinformationen, 802.1Qav beschreibt die Sicherstellung von QoS über Queuing- und Forwarding-Regeln und 802.1Qat definiert die Reservierung und Allokation von Übertragungsressourcen sowie Identifi zierung der Medienströme. All diese Standards stellen letztlich Erweiterungen des Media-Access-Verfahrens auf Ebene 2 des OSI-Schichtenmodells dar und folglich führen sie in der praktischen Umsetzung zu Änderungen des Media-Access-Controllers (MAC) eines NICs. Zudem ist für das Einrichten einer AVB-Domäne eine geringfügige Erweiterung des „Link Layer Discovery Protocols“ notwendig, ein Layer-2 Protokoll, das von Netzwerk-Geräten verwendet werden kann, um ihre jeweiligen technischen Eigenschaften und Identifizierung zu kommunizieren. AVB benutzt LLDP, um die Eignung eines Netzwerk-Devices festzustellen und somit die Mitglieder einer AVB-Wolke zu bestimmen. Dazu wurde ein neues Data-Unit Format (DU) mit spezifischen AVB-TLVs (Type Length Value) definiert.
 |
Einrichtung der AVB-Wolke
Der in der Literatur häufig zu findende Begriff der “AVB Cloud” ist etwas irreführend, da er Assoziationen mit der Internet-Cloud weckt, die letztlich globale Ausdehnung besitzt und von Manchen als „prediction than a defi nition“ verstanden wird. Die AVB-Wolke lässt sich hingegen recht gut eingrenzen, denn sie bezeichnet jene Domäne, die durch das Precision- Time-Protocol (PTP) im gleichen Takt arbeitet. Da es auf Layer 2 keinen übergeordneten Server gibt, der das LAN nach AVB-geeigneten Devices „abklappern“ kann, sind es die Teilnehmer selbst, die mit dem LLDP und Austausch von Botschaften die Grenzen ihrer Domäne feststellen.
Nach dem Power-Up eines AVB-Devices oder dem Anbinden an ein Ethernet-LAN und der darauf folgenden Link- Negotiation (automatische Ermittlung der maximalen gemeinsamen Übertragungsgeschwindigkeit) steht schon einmal fest, ob das jeweilige Gegenüber voll duplexfähig ist, wie für AVB obligatorisch. Grundsätzlich unterstützt AVB keine “Shared Media”- Systeme wie z.B. x-Base-2 auf 50 Ohm Koaxkabel. Drahtlose Netzwerkgeräte mit 802.11 sollen aber zumindest in der endgültigen 802.1BA Fassung als AVB-Teilnehmer möglich sein.
Danach tauscht das Device mit seinem Partner LLDPU`s aus und stellt damit sicher, dass beide „AVB-capable“ sind, also über die notwendigen Erweiterungen des MACs verfügen. Nachdem dieser Prozess auf allen Ports eines lokalen Netzes abläuft, ergibt sich auch ohne zentrale „Intelligenz“ die Ausdehnung einer AVB-Domäne. So bilden z.B. AVB-Bridges, die nur einen Link-Partner mit AVB-Capabilities aufweisen, automatisch einen Grenzposten und bestimmen so die Grenzlinie. Ein Switch ohne AVB-Unterstützung in einem größeren AVB-Konglomerat reicht damit natürlich aus, um das Netz in 2 Domänen zu zerteilen.
Als dritter Schritt ist nun die Synchronisierung zu bewerkstelligen, indem über ein spezielles Auswahlverfahren ein „Clock Grandmaster“ definiert wird, der im Weiteren den zentralen Takt des Netzes vorgibt
Medientransport
Um in der existierenden AVB-Cloud möglichst flexibel multimediale Inhalte auszutauschen, ist eine Kapselung standardisierter Medienströme in den unterschiedlichsten Formaten vorzunehmen. So muss z.B. bei Audioströmen als begleitende Information die Sample-Rate, Anzahl der Kanäle und ggf. der verwendete Codec mitgegeben werden, bei Video sind Dinge wie Auflösung (SD, HD) oder Kompressionsverfahren zu definieren.
 |
Dazu wurde der IEEE-Standard P1722 geschaffen (derzeit in Version Draft V1.7), der auf AVB aufsetzt und folgende Medienprotokolle behandelt:
- 61883-2: SD-DVCR data transmission
- 61883-4: MPEG2-TS data transmission
- 61883-6: Audio and Music data transmission protocol
- 61883-7: Transmission of ITU-R BO.1294 System B
- 61883-8: Transmission of ITU-R BT.601 style Digital Video Data
- IIDC: Instrumentation and Industrial Control Digital Camera
P1722 legt aber auch fest, wie die Medienströme mittels der sog. Presentation Time und der globalen 802.1AS-Zeit zu synchronisieren und wiederzugeben sind. Die AVBTP Presentation Time ist also nicht zu verwechseln mit dem globalen Zeitstempel eines 802.1AS-Pakets.
Presentation Time
Die Presentation Time repräsentiert den Zeitpunkt, zu dem ein Medien-Sample an den Talker gefüttert wurde zusätzlich zu einem Aufschlag, der Max Transit Time, um die ermittelte Latenzzeit der Netzwerkstrecke zu berücksichtigen. Die maximale Durchlaufverzögerung Max Transit Time beträgt 2 ms für den AVB Class-A-Verkehr und 50 ms für Class-B. Talker und Listener können aber auch eine geringere maximale Transit Time aushandeln, wenn dies beispielsweise bei 1000-Base-T Netzen möglich ist.
Implementierung im XMOS-Prozessor
Ethernet AVB mit seinen Substandards verlangt spezifische Erweiterungen der Media-Access-Controller aller Teilnehmer, dazu die Unterstützung digitaler Medienaufzeichnung- und Wiedergabe. Zur Implementierung eignen sich ganz generell Prozessoren aus dem Embedded-Bereich, doch müssen sie in hohem Maße determinierbar, also echtzeitfähig sein, um den Anforderungen des synchronen Ethernets gerecht zu werden.
Architekturen auf Basis von State- Machines auf der anderen Seite, implementierbar beispielsweise in FPGAs und CPLDs, erfüllen diese Forderung natürlich in idealer Weise, sind aber recht sperrig in der Formulierung der benötigten Funktionsblöcke als HDL-Code. Ideal also ist ein hoch deterministischer Prozessor mit der Möglichkeit zur Programmierung in gewohnter Hochsprache, wie er seit einiger Zeit von der Firma XMOS als „Event Driven Processor“ (EDP) mit der sog. XCore-Architektur angeboten wird.
 |
Event-Driven-Processor
Die Idee ist im Grunde recht einfach: Defi niere so viele Funktionen wie möglich in Software, auch solche, die klassischerweise in Hardware realisiert sind und lasse dies auf einer Anordnung von Prozessorkernen ablaufen. Jeder Task belegt einen Thread und 8 davon laufen in exaktem Zyklus auf einem Core. Eine gegenseitige Beeinflussung ist ausgeschlossen und so lässt sich bei der Entwicklung exakt vorhersagen, wie lange eine bestimmte Aktion dauern wird.
Das hohe Maß an Determinismus ist die zentrale Schlüsseleigenschaft der Chips und versetzt Entwickler in die Lage, nicht nur Systemprozesse wie Protokollstacks, sondern auch Hardwareschnittstellen in einer gemeinsamen Umgebung zu definieren. Dieser integrierte Hardware/Software Development-Flow basiert auf einem modifizierten C-Compiler namens XMOS-C (XC), letztlich eine C-Erweiterung, die den Zugriff und die Steuerung des Multi- Threadings und der I/O-Ressourcen ermöglicht.
 |
 |
Hier die wesentlichen Eigenschaften der XMOS-Prozessoren:
- Jeder XCore kann gleichzeitig bis zu 8 Threads mit einer Geschwindigkeit von 400 MIPS bearbeiten und jeder Thread verfügt dabei über einen eigenen Registersatz, wird damit quasi selbst zu einem logischen Core.
- Die 8 Threads teilen sich 64 kByte Unifi ed Memory Defi nition der Unified Memory Architecure ohne Zugriffskollisionen.
- Integer- und Festkommaoperationen zur effizienten Signalverarbeitung und kryptographischen Operationen sind möglich.
- Es sind 64 GPI/O-Pins verfügbar, die durch Software programmiert werden können.
- Die Ausführung der Threads ist absolut deterministisch und daher kann mit jedem Thread ein “harter” Real-Time- Task implementiert werden, unabhängig vom Verhalten der anderen Tasks.
- I/O-Pins sind als logische Ports mit Breiten von 1, 4, 8, 16 und 32 Bit gruppiert. Jeder Port beinhaltet zudem einen SerDes, Synchronisationsmöglichkeiten mit externen Schnittstellen und ein präzises Timing.
- Jeder XCore beinhaltet 8 Timer, die Zeiten relativ zu einem 100 MHz-Takt messen können.
Mit dieser Ausstattung also empfiehlt sich der XMOS-Prozessor in ganz idealer Weise zur Implementierung von AVB. Hatte XMOS in seiner ersten Version noch lediglich Fast-Ethernet unterstützt, so ist es zwischenzeitlich mit der zweiten Generation der EDPs auch möglich, AVB-Teilnehmer mit Gigabit-Ethernet anzubinden.
Kommunikationskanäle
Die notwendige Datenkommunikation zwischen den Threads wird über sog. Channels (= Kanäle) bewerkstelligt, deren Endpunkte („Channel Ends“) sich sowohl auf einem CPU-Kern befi nden können als auch auf verschiedenen Kernen auf dem gleichen Chip oder sogar auf verschiedenen Chips über eine Verbindungsstruktur namens XLink. Für den Software-Entwickler macht es daher bei seiner Implementierung auch keinen grundlegenden Unterschied, aus welchen physikalischen Strecken die von ihm verwendeten Kanäle bestehen, er kann sie mit gleicher Notation verwenden, um Messages zu transportieren, die aus Daten- und Steuer-Token bestehen.
 |
Design Flow
Die Entwicklungsumgebung, immerhin verfügbar für Windows-, Linux- und Mac- Betriebssysteme, ist gegen Registrierung kostenlos auf der Webseite von XMOS verfügbar. Nach XMOS-Angaben wird jedes funktionierende C-Programm in der XC-Umgebung und Einbindung der spezifischen XMOS Include-Bibliotheken problemlos übersetzt. Passt der Code auf den Footprint des Chips, läuft er dort ab und der Baustein verhält sich vergleichbar dedizierter Hardware. XC ist eine a u f Gleich - zeitigkeit und Echtzeit zielende Programmiersprache, die speziell für die XS1-G Architektur entwickelt wurde.
XC Programme sind einfach zu schreiben und debuggen – keine Deadlocks, keine Race Conditions, keine Speicherverletzungen.
XC benutzt die beschriebenen Channels, um eine schnelle, bidirektionale Kommunikation sowie Synchronisation zwischen den Endpunkten der Channels zu erzielen. Die Endpunkte können sich innerhalb eines Threads auf demselben Prozessor befinden, aber auch auf 2 Prozessoren des gleichen Chips oder sogar auf Prozessoren in 2 verschiedenen Chips.
Die XS1-Prozessorarchitektur implementiert Hardwarefunktionen als Software und daher sind Hardware- Lösungen aus dieser Perspektive nichts weiter als Software-Bibliotheken. Sie können compiliert und gelinkt werden wie normaler C-Code und die dabei entstehende Binärdatei wird auf den Prozessor geladen und dort ausgeführt.
Das AVB-Referenzdesign ist dementsprechend eine Bibliothek von Quelldateien, die in größere Anwendungen eingebunden werden können. Zur Entwicklungsunterstützung und –dokumentation sind im Referenzdesign natürlich auch Projekt-Templates und Beispielprogramme enthalten.
 |
Entwicklungsplattformen
Wie schon erwähnt ist die gesamte SW-Entwicklungsumgebung kostenlos von der XMOS-Webseite zu beziehen. Einmal registriert, erhält man Zugang zu den Tools und Beispielprogrammen sowie zur Seite Xlinkers, der offiziellen XMOS Web-Community Darin eine große Zahl an Projekten, Programmen sowie Code-Snippets aber auch Blogs mit Besprechung von Problemen und Lösungen, die einem das Leben als Entwickler leichter machen.
Hardwareseitig bietet XMOS mehrere Evaluierungs-Boards auf Basis des XS1- G4 und dem neuen Single-Core-Device XS1-L1. Für die AVB-Implementierung nutzt XMOS das XS1-G, eine Break- Out-Box mit QVGA-LCD im schwarz glänzenden Gehäuse und Anmutung eines Modder-PCs, umfangreich ausgestattet mit LVDS-Schnittstellen, Audio-I/O und Ethernet, einen Slot für SD-Cards und die auf Pfostenleisten herausgeführten XIOPorts.
Im Auslieferungszustand sind bereits einige Beispielprogramme installiert, die Über ein On-Screen-Menü und der Tastatur gestartet werden können. Neben „Pong“ und „Mandelbrot“ gibt es auch einen Audio Frequenzanalyzer, der den Audio-Eingang des Evalsystems in Echtzeit analysiert und als Frequenzdarstellung auf den Bildschirm bringt.
 |
Ethernet AVB
Zur Präsentation seiner Referenzanwendungen hat XMOS kurze Videos aufgezeichnet und auf seine Webseite eingestellt. Eines davon zeigt die Implementierung des Ethernet AVB-Standards sowie IEEE1722 und IEEE1588 als Ethernet AVB Demo. Die Referenz-Software ist als Source-Code ebenfalls frei auf der Webseite verfügbar und kann daher beliebig in eigenen Projekten verwendet werden.
Das Referenzdesign besteht im Wesentlichen aus diesen 3 Komponenten:
- Ethernet-MAC und MII-Interface
- Die Precise-Time-Protokollimplementierung (PTP, IEEE1588 oder 802.1AS)
- Die Audio Streaming-Komponente (Talker und Listener)
Ethernet-MAC Komponente
Die MAC-Komponente, Schlüsselelement der AVB-Implementierung, packt Daten in Ethernet-Frames und liefert sie sendeseitig zur MII-Schnittstelle bzw. holt empfangene Frames von dort ab und zerlegt sie nach Inhalt und Header-Informationen. Die PHYs sind nicht im Prozessor integriert und müssen samt notwendiger galvanischer Trennung extern implementiert werden (XMOS verwendet dazu den LAN8700 PHY von SMSC). Die Komponente besteht aus 6 Threads, die auf dem gleichen Core laufen müssen und über Channels (Verbindungsstrecken) mit anderen Komponenten oder Threads kommunizieren. Mit Hilfe sog. Filter lassen sich die zu übertragenden Daten dieser Links steuern. Die Einrichtung und Konfiguration der Channels wird mittels einer Client C-API durchgeführt, Details dazu sind in den jeweiligen Header-Files dokumentiert. Die MAC-Komponente unterstützt neben den bekannten Funktionen 2 für AVB wesentliche Features:
- Timestamping ermöglicht den Empfang und das Senden von Ethernet-Frames mit Zeitstempeln in Bezug auf ein Taktsignal, z.B. einen 100 MHz-Takt mit einer Auflösung von immerhin 10 ns.
- Flow Control (Flußsteuerung) realisiert den 802.1Qav Standard zur individuellen Behandlung von Daten mit unterschiedlichen Prioritätsklassen und Beschränkungen bei der nutzbaren Bandbreite.
 |
PTP-Komponente
Die Precise-Time-Protocol- Komponente (PTP) liefert die netzwerkweite Zeitinformation zur Synchronisierung aller Teilnehmer einer AVBWolke. XMOS hat in sein Referenzsystem sowohl eine Implementierung des Standards IEEE1588 (V2) als auch des neuen Standards 802.1AS gepackt, die wahlweise in die Applikation eingebunden werden können.
Die Komponente besteht lediglich aus 2 Threads, ist mit dem Ethernet-MAC verbunden und bietet sog. Channel Ends für Clients, um darüber Zeitinformationen abzufragen. Sie interpretiert die PTPPakete vom MAC und stellt die Verfügbarkeit der globalen Zeitinformation sicher. Sie kann während der Laufzeit, entsprechend 802.1AS und dem Best Master Clock Algorithm als Grandmaster oder Slave definiert werden. Als Grandmaster liefert sie globale Zeitinformation für alle Teilnehmer der AVB-Wolke und wird somit zum zentralen Taktgeber, als Slave bezieht sie die Zeitinformation von einem externen Grandmaster.
Die Beziehung zwischen der lokalen Zeitreferenz eines Clients und der globalen Zeit der AVB-Wolke wird über die Channels sichergestellt, womit der Client in der Lage ist, entweder sehr präzise Zeitstempel beim Versenden der Medienpakete zu setzen bzw. einen sehr genauen Sample-Clock beim Empfangen der Ströme zu erzeugen.
Audio-Stream Komponente
Die Audio-Stream-Komponente ist mit dem Software-MAC verbunden und funktioniert bidirektional zum Empfang und Senden von Audio-Samples. Als Audio-Talker übernimmt sie digitalisierte Audioströme über die I2S Schnittstelle, bündelt diese in IEEE1722-konforme Pakete und verschickt sie über Ethernet. Als Audio-Listener übernimmt sie einen Audiostrom vom Netzwerk, dröselt die Pakte auf und schickt die Audio-Samples über die I2S-Schnittstelle an einen Audio-DAC.
Der Talker
Die Talker-Komponente besteht im Kern aus 2 Threads, zum einen ist dies ein Buffer für die Audio-Samples von der I2S-Schnittstelle, zum anderen aus dem Packetizer, der entsprechend dem Standard IEEE1722 aus den einzelnen Samples den Payload, also die Nutzlast der Ethernet Pakete formt. Die Daten werden dann zur MAC-Komponente weitergereicht, die daraus vollständige Ethernet Frames generiert.
Beim Erzeugen der Ethernet-Pakete, „in statu nascendi“ sozusagen, generiert der Talker Zeitstempel aus der globalen Zeitangabe der PTP-Komponente zuzüglich eines Offsets zur Kompensation von Laufzeiten innerhalb der AVB-Wolke. Die Zeitstempel geben folglich die „Presentation Time“ an, also jene Zeitpunkte, an dem die Audio-Samples beim Listener wiedergegeben werden müssen.
 |
 |
Der Listener
Der Listener übernimmt die einlaufenden IEEEP1722 -Pakete vom MAC und wandelt sie in einen Stream von Media-Samples um, die wiederum in einen Buffer-Thread gespeist werden. Da der Audio-Stream auf einem anderen System erzeugt wurde, mithin also auf Basis eines anderen Taktgenerators mit abweichender Frequenz, muss eine Anpassung der Wiedergabe-Taktfrequenz vorgenommen werden.
Dazu gibt es einen Audio Clock Recovery Thread, der einerseits durch unterschiedliche Verfahren den korrekten Takt ermittelt, zum anderen einen internen oder externen Generator entsprechend steuert. Das XMOS Referenzsystem bietet 3 Varianten zur Synchronisation, standardkonform ist natürlich die Methode mit IEEE1722 Zeitstempeln. Dazu bestimmt der Thread aus der Differenz aufeinander folgender Zeitstempel sowie der Anzahl der Audio-Datenworte je Paket den richtigen Takt und gibt Steuerinformationen an den gewählten Generator weiter. Alternativ kann der Wiedergabetakt auf ein externes Signal synchronisiert werden oder lässt sich aus der globalen PTP-Zeit und einigen Zusatzinformationen ableiten. Sobald die Abtastrate angepasst wurde, kann der Listener dann auch die Größe seines Ausgangsbuffers korrekt bestimmen, um damit sicherzustellen, dass der Medienstrom exakt zur Presentation-Time wiedergegeben wird und synchron zu anderen AVBTeilnehmern arbeitet.
 |
Systemdesign
Die Komponenten MAC, PTP und Audio-Interface benötigen in Summe 13 Threads und knapp 80 kByte Speicher. Mit einem Vorrat von 32 Threads und 256 kByte Speicher des XS1-G4-Prozessors bleiben also für Anwendungen mehr als 60% der Chip-Ressourcen, z.B. für Protokollimplementierungen zur Netzwerkkonfiguration, Anwenderschnittstellen oder Audioverarbeitungsroutinen oder einfach für zusätzliche Audio-Stream-Instantierungen.
Die Aufteilung der Komponenten auf die 4 Kerne des Prozessors gibt Abbildung 16 wieder. Einige zeitkritische Threads müssen auf einem gemeinsamen Core laufen, da die hier die kürzesten Link- Verzögerungen existieren.
 |
Demosystem
Mit der Ausstattung des AVB-Referenzsystems von XMOS lässt ich eine AVB-Wolke mit 4 Teilnehmern aufbauen, wobei jede der Boxen als Talker oder Listener fungieren kann. Die notwendige Software ist auf einer SD-Karte in jeder Box enthalten und lässt sich über ein Menü auswählen, zur Auswahl stehen die Programme „AVB_T.XB“ für den Einsatz als Talker und „AVB_L.XB“ für den Listener. Audiosignale werden über die Line-In Klinkenbuchsen in die Boxen eingespeist bzw. können über Line-Out an aktive Boxen ausgegeben werden.
Am zentralen Ethernet Switch lässt sich über einen Repeating-Port der Datenverkehr auf der Ethernet-Ebene verfolgen, z.B. mit einem Packet-Sniffer wie dem bekannten Wireshark.
Die Boxen zeigen im Betrieb eine Frequenzdarstellung des eingespeisten bzw. übertragenen Audiosignals, im Thread-Diagramm als FFT & Buffer Komponente zu finden. Auch damit lässt sich sehr eindrucksvoll zeigen, dass sich Threads auf diesem Prozessor nicht gegenseitig beeinflussen und ihre Echtzeitfähigkeit auch unter Last beibehalten.
 |
 |
