Der „Hello, world“-Test von Xillybus
Das ist der dritte Schritt beim Einstieg in Xillybus: Der Bitstrom (bitstream), der Xillybus enthält, ist bereits in das FPGA geladen, und der Treiber ist auf dem Host installiert. Jetzt wird es Zeit für einen einfachen Test. Dieser Test soll prüfen, ob die Gerätedateien (device files) angelegt wurden und funktionieren.
Diese Seite behandelt Xillybus auf einem Linux-Host. Für Microsoft Windows gibt es eine ähnliche Seite.
Ich konzentriere mich hier auf Xillybus mit PCIe, aber bei XillyUSB läuft fast alles genauso ab. Die Unterschiede sind am Ende dieser Seite aufgelistet. Was Xillinux betrifft, funktioniert alles auf dieselbe Weise, abgesehen von den Themen, die direkt mit PCIe zu tun haben.
Weitere Informationen zu diesem Thema finden Sie unter Erste Schritte mit Xillybus unter Linux.
Wird das PCIe-Gerät erkannt?
Zuerst sollten Sie prüfen, ob der Rechner das FPGA als PCIe-Gerät erkennt. Verwenden Sie dazu den Befehl „lspci“. Dieser Befehl zeigt alle Geräte, die der Rechner am PCIe-Bus gefunden hat. Mitunter ist das eine sehr lange Liste.
Zum Beispiel mit Xillybus auf einem Xilinx-/AMD-FPGA:
$ lspci [ ... several lines ... ] 01:00.0 Class ff00: Xilinx Corporation Device ebeb [ ... several lines ... ]
Und mit Altera:
01:00.0 Class ff00: Altera Corporation Unknown device ebeb
Die Ausgabe kann auf Ihrem Rechner etwas anders aussehen. Wichtig ist die Zeichenfolge „ebeb“. Das ist die Device-ID, die anzeigt, dass es sich um ein Xillybus-Gerät handelt.
Wenn in der lspci-Ausgabe keine solche Zeile vorkommt, gibt es ein Problem mit dem FPGA. Oft ist die Ursache ein Durcheinander dabei, welcher Bitstrom (bitstream) ins FPGA geladen wurde.
Wurde der Treiber ordnungsgemäß gestartet?
Der nächste Schritt ist, den Status des Treibers zu prüfen. Der einfachste Weg ist, im Kernel-Log nach dem Wort „xillybus“ zu suchen. Zum Beispiel:
$ dmesg | grep xillybus
xillybus_pcie 0000:01:00.0: can't disable ASPM; OS doesn't have ASPM control
xillybus_pcie 0000:01:00.0: Created 5 device files.
Das Format der Ausgabe unterscheidet sich von Rechner zu Rechner. Die Zeile mit ASPM ist normal und weist nicht auf einen Fehler hin. Es ist aber auch in Ordnung, wenn diese Zeile fehlt.
Die Zeile mit dem Inhalt „Created 5 device files“ bestätigt, dass der Treiber Xillybus erfolgreich initialisiert hat. Wenn diese Zeile fehlt, gab es ein Problem beim Initialisieren des Treibers.
Falls weitere Zeilen im Kernel-Log zu Xillybus stehen, können sie helfen zu erklären, was schiefgegangen ist. Das ist in der Regel ein Problem mit der FPGA-Logik. Das passiert insbesondere dann, wenn der PCIe-Block im FPGA falsch konfiguriert ist. Wenn Sie zum Beispiel die Parameter des PCIe-Blocks im Demopaket verändert haben, kann das verhindern, dass der Treiber ordnungsgemäß initialisiert.
Was nun, wenn im Kernel-Log keine Zeile mit dem Wort „xillybus“ vorkommt, die lspci-Ausgabe aber eine Zeile mit „ebeb“ enthält? Das bedeutet, dass der Treiber nicht in den Kernel geladen ist. Prüfen Sie das mit lsmod, zum Beispiel so:
$ lsmod | grep xillybus xillybus_pcie 16384 0 xillybus_core 28672 1 xillybus_pcie
Dieses Beispiel zeigt die richtige Ausgabe, wenn der Treiber in den Kernel geladen ist. Die Zahlen (16384 und 28672) können anders lauten. Es ist möglich, dass auch xillybus_class in dieser Liste erscheint.
Beachten Sie, dass Sie den Rechner neu starten oder den Treiber manuell mit insmod laden müssen, wenn Sie den Treiber gerade eben installiert haben.
„Hello, world“
Der Treiber legt fünf Gerätedateien an: /dev/xillybus_read_8, /dev/xillybus_read_32, /dev/xillybus_write_8, /dev/xillybus_write_32 und /dev/xillybus_mem_8. Beachten Sie, dass Sie, wenn Sie in der IP Core Factory einen eigenen IP-Core (custom IP core) erzeugen, selbst festlegen können, wie viele Gerätedateien angelegt werden und wie sie heißen und welche Eigenschaften sie haben.
Im Moment enthält das FPGA aber das Demopaket. Probieren wir zwei der Gerätedateien aus.
Im Demopaket existiert zwischen read_8 und write_8 ein Loopback. Das heißt: Wenn der Rechner Daten an write_8 schreibt, gibt das FPGA über read_8 genau dieselben Daten zurück. Das ist nur als Demonstration gedacht. Für diesen Loopback gibt es keinen anderen praktischen Nutzen.
Der Test läuft so ab: Öffnen Sie zwei Terminalfenster auf dem Rechner. Sie können auch jede andere Anordnung verwenden, die Ihnen zwei Shell-Eingabeaufforderungen bietet, zum Beispiel zwei ssh-Verbindungen.
Geben Sie an der ersten Shell-Eingabeaufforderung Folgendes ein:
$ cat /dev/xillybus_read_8
Geben Sie dann an der zweiten Shell-Eingabeaufforderung Folgendes ein:
$ cat > /dev/xillybus_write_8
Tippen Sie nun im zweiten Terminal einen beliebigen Text und drücken Sie die Eingabetaste. Derselbe Text erscheint im ersten Terminal. Das veranschaulicht, wie der Text in die erste Gerätedatei geschrieben wurde, dann ins FPGA gelangte und schließlich zum Rechner zurückkehrte.
Auch wenn dieses Beispiel einfach ist, ist es wichtig zu verstehen, wie es funktioniert. Insbesondere ist es wichtig zu verstehen, wie die Logik im FPGA das zustande gebracht hat. Genau hier ist der Ausgangspunkt, um Ihre eigene Logik einzubinden.
Falls diese Befehle mit der Meldung „Permission denied“ scheitern, wiederholen Sie den Vorgang als root. Alternativ installieren Sie die udev-Datei, wie bereits empfohlen.
XillyUSB
Wenn Sie XillyUSB verwenden, gilt alles, was oben gesagt wurde, allerdings mit einigen Unterschieden.
Zu XillyUSB gehört ein Werkzeug namens showdiagnostics, mit dem Sie die Qualität der physischen Verbindung zum FPGA untersuchen können. Es wird dringend empfohlen, mit diesem Werkzeug sicherzustellen, dass die Rohdatenverbindung (raw data link) fehlerfrei ist. Selbst wenn XillyUSB auf den ersten Blick einwandfrei funktioniert, ist diese Prüfung wichtig. Der Grund ist, dass das USB-3.0-Protokoll Fehler auf der Rohdatenverbindung verbirgt, diese Fehler aber trotzdem seltene Probleme verursachen können, die wie ein Bug aussehen.
Es gibt keinen Grund, Fehler dieser Art zu tolerieren. Oft ist die Lösung einfach, z. B. einen anderen USB-Port des Rechners zu verwenden.
Andere Unterschiede:
- Verwenden Sie lsusb statt lspci.
- Die Module des Treibers heißen xillyusb und möglicherweise xillybus_class.
- Ein Neustart des Rechners ist nach der Installation des Treibers nicht nötig. Der Treiber wird automatisch geladen, wenn das Gerät an den USB-Port angeschlossen wird (nachdem es zuvor abgesteckt war).
- Die Namen der Gerätedateien sind etwas anders. Anstelle von /dev/xillybus_read_8 lautet der Name zum Beispiel /dev/xillyusb_00_read_8. Der Teil „00“ kann variieren.