Das Ethernet-AVB-Netzwerk muss mehrere Mediaformate mit unterschiedlichen Abtastfrequenzen – d.h. verschiedene Media Clocks – unterstützen. Beispiel: Kameras und Center Display können mit der Media Clock der Videodaten arbeiten, während die im selben Netzwerk angeschlossenen Verstärker und Lautsprecher mit einer Media Clock für Audiodaten arbeiten. Die Wiederherstellung der Media Clock ist nicht Teil der Spezifikation des AVB-Standards.
Wenn ein AVB-Talker Mediadaten an einen AVB-Listener sendet, muss ein Mechanismus vorhanden sein, um sicherzustellen, dass die Media Clock zwischen den Endpunkten desselben Stream die gleiche Frequenz aufweist.
Einsatz von Clock Streams und Cross Time Stamping
1. Jede einzigartige Abtastfrequenz benötigt einen Clock Stream, um Media Clock Timestamps an alle Netzknoten zu verteilen. Alternativ kann der Zeitstempel in das AVBTP-Zeitstempel-Feld innerhalb der Datenpakete eingefügt werden.
2. Durch Einschränkungen der Netzwerk-Bandbreite kann es nicht praktikabel sein, die Zeitstempel mit der Media-Abtastrate zu senden. Stattdessen sind Zeitmarken nur beim n-ten Sample möglich, um die Anforderungen hinsichtlich der Netzwerk-Bandbreite zu minimieren.
3. Der Listener vergleicht die erhaltenen Zeitstempel mit der internen 802.1AS-Wanduhr. Die Rate, mit der die Zeitstempel mit der Wanduhr übereinstimmen, ergibt eine herunterskalierte Media Clock.
4. Listeners nutzen im Allgemeinen eine PLL, um eine Media Clock zu erzeugen. Diese Media Clock triggert die Verarbeitung des Media Sample (SSC, DAC usw.).
5. Die mit der oben genannten herunterskalierten Media Clock erzeugten Zeitstempel werden als Referenz-/Korrektursignal zum Abgleich des PLL-Ausgangs mit dem Talker genutzt.
6. Der Clock Stream sollte Zeitstempel mit einer ausreichenden Frequenz liefern, um eine Interpolation zur Rekonstruktion der Media Clock beim Listener zu erlauben. Das kann verantwortlich sein für verlorene Pakete des Media Clock Stream und Änderungen bei der globalen Taktfrequenz.
Der SAMV7x kann einen Interrupt erzeugen, wenn der interne 802.1AS-Timer-Wert einem programmierbaren Vergleichswert entspricht (Bild 8). Der Media-Clock-Zeitstempel lässt sich in dieses Vergleichsregister schreiben. Dieser Timer-Vergleich-Interrupt kann eine PWM-Timer-Peripherie ohne einen Software-Eingriff über ein Ereignissystem auslösen. Diese PWM-Timer-Peripherie kann einen Ausgangs-Pin bei jedem Vergleichsereignis schalten. Die in einem Stream empfangenen Media-Clock-Zeitstempel werden in einen Rechtecksignal-Ausgang mit gleicher Frequenz umgeformt. Dieser Takt lässt sich dazu nutzen, einen externen PLL-Ausgang zu korrigieren, um die Media Clock wiederherzustellen. Somit stellt der SAMV7x einen Mechanismus zur Verfügung, um die Media Clock mit einem minimalen Software-Eingriff aus Zeitstempeln zu regenerieren.
Zwischenspeicherung in AVB-Netzwerken
Talkers melden die Worst-Case-Latenz, die ein Stream in seinem Pfad vom Talker zum angegebenen Listener haben kann. Die gemeldete Latenz kann während der Dauer der Reservierung nicht erhöht werden. Tritt ein Ereignis ein, das die Latenz über die ursprünglich gewährte Garantie erhöht, dann wird ein Fehler gemeldet. Der Talker erhöht die Präsentationszeit vor dem Senden um einen gewissen Offset, der die Latenz durch das Netzwerk berücksichtigen soll. Die Verzögerung kann für jeden Listener unterschiedlich sein und ist von der Anzahl der Hops im Netzwerkpfad zum Listener abhängig. Die Puffergröße beim Listener ist folglich dynamisch und hängt von der Latenz ab. Der Listener kann diese Information nutzen, um zu entscheiden, ob die Latenz für eine akzeptable Präsentation des Stream zu groß ist.
Berechnung der Puffergröße
Es ist zu bedenken, dass ein Systementwickler die Worst-Case-Verzögerung von einem Talker zu einem Listener „A“ mit 49 ms über 7 Hops berechnet, sodass die Verzögerungszeit mit 50 ms angesetzt wird. Ein anderer Listener „B“ ist jedoch nur 1 Hop entfernt, was einer Verzögerung von 7 ms entspricht. Ein Listener, der Pakete mit einer geringeren Latenz erhält, speichert die Daten, bis der Listener mit der Worst-Case-Latenz die Daten vom gleichen Stream erhalten hat. Folglich speichert Listener „B“ Daten über 43 ms, während Listener „A“ nur Daten über 1 ms zwischenspeichern muss. Wird beispielsweise ein Audio-Stream der Klasse B mit 5 Kanälen, 16-bit-Daten bei einer Frequenz von 48 kHz im oben genannten Netzwerk übertragen, dann gilt für den erforderlichen Zwischenspeicher:
– Listener A (1 ms): 1 ms / 250 µs = 4.
– Listener B (50 ms): 50 ms / 250 µs = 200.
Im Falle von Mono-Audio beträgt die erforderliche Puffergröße bei Listener A: 5 Kanäle × 2 Bytes pro Kanal × 12 Audio-Samples pro Ethernet Frame × 4 Ethernet Frames = 480 Bytes.
Bei Listener B beträgt sie: 5 Kanäle × 2 Bytes × 12 Audio-Samples pro Ethernet Frame × 200 Ethernet Frames = 24.000 Bytes.
Das ist in Automobilnetzwerken kritisch, weil die Endgeräte nur über einen eingeschränkten Puffer verfügen. In der Regel kann ein Automobilsystem mehrere Streams umfassen, wobei jeder Stream mehr als einen Kanal enthalten kann. Die Puffergröße nimmt mit jedem zusätzlichen Kanal innerhalb eines Stream und auch mit jedem zusätzlichen Stream zu. Die Puffergröße ist folglich stark konfigurationsabhängig. Zusätzlich zu den Stream-Daten muss die presentation_time innerhalb jedes AVBTP Frame zwischengespeichert werden. Die Puffergröße für die presentation_time hängt von der Anzahl der unterstützten Streams und der Worst-Case-Latenzzeit des Stream ab.
Automotive-spezifische Anforderungen
Im Automobilbereich werden normalerweise viele Parameter bereits in der Systemdefinitionsphase festgelegt. Folglich lässt sich die AVB-Implementierung in einem gewissen Maß optimieren und vereinfachen, zum Beispiel bei
Automobilnetzwerke sind nicht sehr groß. Es befinden sich nur wenige Knoten zwischen einem Talker und einem Listener. Es ist daher wichtiger, Pakete nicht wegen einer Überlastung zu verlieren.
Referenzen
[1] standards.ieee.org/getieee802/download/802.1Q-2011.pdf
[2] www.embedded.com/design/connectivity/4008284/3/Understanding-IEEE-s-new-audio-video-bridging-standards
[3] www.ieee802.org/1/files/public/docs2009/avb-rboatright-p1722-explained-0903.pdf
Der Autor
Tim Grai |
---|
ist RF & Automotive Application Manager bei Atmel. |