Camera Link HS (HS steht für High-Speed) ist eine technisch bewährte Schnittstelle für die Entwicklung von 25G- und 50G-Bildverarbeitungskomponenten. Ein How-to für ein Bildverarbeitungssystem mit CLHS 25G und 950 fps zeigt die Möglichkeiten dieser Schnittstelle.

In der Bildverarbeitung existieren mit Camera Link, CoaXPress, den Ethernet-basierten GigE-Interfaces, HS-Link, CLHS und USB seit Jahren diverse Schnittstellen für die Datenübertragung zwischen Kamera und PC beziehungsweise Bilderfassungskarte. Jede dieser Schnittstellen hat ihre individuellen Stärken und Schwächen, die sich je nach Aufgabenstellung mehr oder weniger deutlich auswirken. Welche Technologie für den jeweiligen Anwendungsfall die optimale ist, entscheiden Experten in der Regel nach den vorliegenden Anforderungen und häufig auch nach den Präferenzen des Anwenders.

Zukunftsfähigkeit einer Kameraschnittstelle 

Ein weiteres wichtiges Argument für oder gegen eine Schnittstelle ist zudem ihre Zukunftsfähigkeit. Inspektionsprozesse werden immer schneller, die Auflösungen von Kameras und damit die anfallenden Datenmengen immer größer, sodass ein Upgrade auf Interfaces mit mehr maximalem Datenvolumen für Anwender so einfach wie möglich umsetzbar sein sollte. Aus dieser Sicht hat Camera Link HS (CLHS) gute Chancen für eine weitere Verbreitung, da sein IP-Kern einfach benutzt werden kann, bei 10 G und 25 G funktioniert und eine Roadmap für 50G hat. 

Der IP-Kern des CLHS-X-Protokolls mit 25 Gbit/s ist derselbe, der auch in allen 10-Gbit/s-CLHS-Produkten auf dem Markt zu finden ist und seit der ursprünglichen Veröffentlichung der CLHS-Spezifikation im Jahr 2012 von der Association for Advancing Automation (A3) angeboten wird. Dieser bewährte Kern bietet benutzerfreundliche parallele Schnittstellen für Video, bidirektionale Trigger, Kamerabefehle, bidirektionale GPIOs und die CLHS-Revisionsmeldung. Der Kern erfüllt alle in der CLHS-Spezifikation aufgeführten Anforderungen an die Prioritätscodierung und vereinfacht die Entwicklung von CLHS-Produkten. Das zugehörige PCS-Modul führt eine 64/66b-Kodierung mit Forward 
Error Correction durch, was fehlerfreie Übertragungen sicherstellt und der Core mit FPGA-Transceivern verwendet werden kann, die einfache 64-zu-1-Serialisierer/Deserialisierer bieten. Es wird keine weitere IP benötigt.

Camera Link HS mit 10, 25 oder 50 Gbit/s

Mit der CLHS-Spezifikation 1.2 wurde kürzlich die Geschwindigkeit von 25 Gbit/s zusammen mit den QSFP28-, SFP28- und MPO-Anschlüssen eingeführt. Die gute Nachricht ist, dass optische Engines mit 25 Gbit/s abwärtskompatibel zu optischen Engines mit 10 Gbit/s sind, bei denen die CLHS-Erkennung stattfindet. CLHS verwendet einen ausfallsicheren Prozess, um auf 25 Gbit/s umzuschalten.

Mehrere Entwickler haben bereits 25-Gbit/s-Systeme entwickelt und dabei bewährte 10-Gbit/s-Hardware verwendet, um das 25-Gbit/s-Produkt zu testen. Das Komitee hat den Nachweis erbracht, dass mit demselben IP-Kern auch 50 Gbit/s erreicht werden können, wodurch ein einfacher Übergang zu künftigen, noch höheren Geschwindigkeiten gewährleistet ist.

Praxisbeispiel: CLHS 25G mit 950 fps

Dieser Artikel beschreibt die Schritte zur Erstellung einer CLHS-Lösung mit 25 Gbit/s in einem FPGA für eine Kamera mit einem monochromen Bildsensor mit 2.048 x 1.024 Pixeln und einer 12-Bit-Ausgabe, die mit 950 Bildern pro Sekunde läuft. Ziel ist es, diese Daten mit 2,99 GByte/s zur Verarbeitung an den Host zu senden. 2,99 GByte/s liegen innerhalb der maximalen 3 GByte/s-Leistung einer einzelnen CLHS-Lane bei 25 G. Zum Einsatz kommt eine SFP28-Lösung.

Der offene VHDL-Kern, der von der A3 für 1.000 US-Dollar erworben wurde, umfasst die CLHS-Kamera- und Framegrabber-Module sowie das CLHS PCS und bildet ein komplettes System, wie unten dargestellt.

Der Kern ist nicht an einen bestimmten Hersteller gebunden und wurde bereits auf FPGAs von AMD (Xilinx), Intel (Altera) und Microchip (Polarfire) implementiert. Der Entwickler muss die Transceiver-Funktion, die Taktverteilung und die Logik konfigurieren, die Nachrichten zum/vom Kern sendet/empfängt. 
Die virtuellen Nachrichtenkanäle des IP-Cores sind: Pulse (Trigger), GPIO, Video Data, Command und Revision. Die Transceiver-Konfiguration und die Taktverteilung werden von den Benutzern des Kerns konfiguriert. Die gesamte Paketbildung, Kodierung und Prioritätsregeln werden vom CLHS-Kern gehandhabt. Während der Erkennung liest der Framegrabber die obligatorischen Register in der Kamera und beschließt, den Übergang zum 25-Gbit/s-Betrieb einzuleiten, wofür die Transceiver neu konfiguriert und alle zugehörigen PLLs zurückgesetzt werden müssen.

Verwendung des Kerns

Der Kern bietet einfach zu bedienende parallele Schnittstellen. So wird zum Beispiel die Impulsnachricht gesendet, indem der gewünschte Impulsmodus und die zugehörigen Bytes in der parallelen Schnittstelle eingestellt werden. Die Impulsnachricht wird dann über die Verbindung übertragen, wo der CLHS-Empfänger den Nachrichtentyp dekodiert und die Verfügbarkeit der parallelen Daten an das System des Anwenders mit einem ein Takt breiten Impuls „PulseMsgValidStrobe“ signalisiert. GPIO- und Revisionsmeldungen verwenden identische Methoden.

Die Video- und Befehlspakete können bis zu 8 KB beziehungsweise 1 KB groß sein. Der Benutzer schreibt die 64-Bit- beziehungsweise 32-Bit-Daten mit einem Schreibfreigabe-Impuls in den CLHS-Puffer und gibt nach dem Schreiben der Paketdaten und dem Einstellen des Inhalts des parallelen Header-Bytes eine 1-Takt-weite Sendeanforderung an den Nachrichten-Port aus, die den IP-Core veranlasst, die Nachricht über die Verbindung zu senden. Beim Empfänger wird das eingehende Paket dekodiert und korrekt im Video- oder Befehlsempfangs-Buffer gespeichert und ein eintaktiger Impuls, zum Beispiel „VidMsgValidStrobe“, signalisiert, dass der Buffer zum Lesen bereit ist.

Beispiel für die Festlegung der Header-Informationen

Betrachten wir die Videonachricht als Beispiel für die Festlegung der Header-Informationen. CLHS ist ein ferngesteuertes DMA-ähnliches Paket, das RowID und ColumID verwendet, um die Pixelposition des ersten Pixels im Paket zu definieren. Der betrachtete Sensor ist 2k Pixel breit, und die 12-Bit-Daten werden verkettet, was zu 3 KB für eine einzelne Datenzeile führt. Dies passt problemlos in die 8-KB-Obergrenze. Wäre die Datenrate des Sensors höher, könnte man eine zweite Spur hinzufügen und die Daten der geraden Zeilen auf Spur 0 und die Daten der ungeraden Zeilen auf Spur 1 oder die Pixel 0 bis 1.023 auf Spur 0 und die Pixel 1.024 bis 2.047 auf Spur 1 senden. Die Entscheidung liegt beim Benutzer und der Art und Weise, wie er die CLHS-Daten-Buffer füllen möchte. In diesem Beispiel wird nur eine Spur benötigt, und das erste Pixel jeder Zeile ist die Spalte 0.

Üblicherweise ist die erste Zeile eines Bildes die Zeile 0 und jede weitere von der Kamera ausgegebene Zeile erhöht die Zeilennummer. Wenn der Sensor von oben/unten ausgelesen wird, ist Zeile 0 die erste Zeile des Bildes und Zeile 1.023 die zweite Zeile von der Kamera, wobei die Zeilen-ID auf 0 und dann 1.023 als Eingabe für den CLHS-Kern gesetzt wird.

CLHS ist ein Daten-Push-Modell, sodass die Kameras keine Bilddaten puffern müssen. Der Entwickler entscheidet sich für die Unterstützung älterer Framegrabber mit 10G-Fähigkeit und entwirft zwei Glasfaserverbindungen, wodurch eine Bandbreite von 2,8 GByte/s erreicht wird und die Möglichkeit besteht, die Kamera so zu konfigurieren, dass eine einzelne 25G-Lane für die volle Bildrate verwendet wird. Die Konfigurationen, die der Entwickler in der Kamera unterstützen möchte, sind vielseitig und in den obligatorischen CLHS-Registern dokumentiert, sodass der Framegrabber das Setup automatisch durchführen kann.

Die auf den Video-IP-Kern der CLHS-Kamera angewandten Werte sind in der folgenden Tabelle aufgeführt. Das kleine Präfix „v“ in den Portnamen zeigt an, dass der für diese Schnittstelle verwendete Takt ein vom Kunden bereitgestellter Videotakt ist und alle Signale zu diesem Takt synchron sind. Der Framegrabber-Kern hat entsprechende Signale, außer wenn die umgekehrte Funktion benötigt wird, zum Beispiel vRdEn input und vVidDataAvailable, vVidMsgValidStrb und vVidDataValid.

Zusammenfassung

CLHS verwendet einen bewährten Kern, der einfach benutzt werden kann, bei 10G und 25G funktioniert und eine Roadmap für 50G hat. Produkte können mit 10G und bewährten Partnerprodukten entwickelt und nach einem Debugging auf 25G umgestellt werden. Kunden, die die Geschwindigkeit von 25G nicht benötigen, können optische 10G-Engines verwenden, die kostengünstiger sind und weniger Strom verbrauchen, wenn sie an 10G-Framegrabber angeschlossen werden, die voraussichtlich kostengünstiger sein werden als leistungsstärkere 25G-Modelle.

Autor
Mike Miethig, Technical Manager bei Teledyne Dalsa