Alibaba-Cloud-FPGA: Kintex UltraScale+ für 200 Dollar

• Vorstellung eines Experiments, bei dem ein Kintex UltraScale+ FPGA-Board für 200 Dollar gekauft und als Entwicklungsplattform genutzt wird
• Das Board wird ohne offizielle Dokumentation oder Garantie verkauft, was JTAG-Debugging und die Ersteinrichtung zu Herausforderungen macht
• Mit OpenOCD und Segger JLink wird die Möglichkeit untersucht, eigenständig eine FPGA-Konfigurations- und Debugging-Umgebung aufzubauen
• Ziele des Experiments sind die Überprüfung der PCIe-/Ethernet-Schnittstellen und des Pinouts sowie das System-Monitoring des gebrauchten FPGA
• Es werden die schrittweisen Verfahren und Erfahrungen bei der Fehlersuche von Initialisierung und JTAG-Verbindung über die Analyse der Scan-Chain bis hin zu Temperatur-/Spannungs-Monitoring zusammengefasst

---

Einleitung

• Der Autor wollte für das Prototyping eines größeren Projekts ein leistungsfähiges FPGA, insbesondere ein UltraScale+ aus der Xilinx-Virtex-Reihe, grenzte die Auswahl aber wegen der Kosten und der teuren Vivado-Enterprise-Lizenz auf WebPack-unterstützte Kintex-UltraScale+-Chips (XCKU3P, XCKU5P) ein
• Auch diese Chips bieten weit mehr als Hobby-Niveau, darunter viele LUTs und GTY-Transceiver mit hoher Ausstattung
• Benötigt wurde ein Entwicklungsboard mit mindestens 2x SFP+ oder 1x QSFP, JTAG und PCIe x8 oder mehr; nach Überlegungen zu Eigenentwicklung, dem Kauf eines Alinx-Produkts und der Suche auf dem Gebrauchtmarkt wurde schließlich auf Ebay ein Alibaba-Cloud-Beschleuniger-FPGA-Board für 200 Dollar gekauft
• Das gekaufte Board kam ohne jede Dokumentation, und ob es überhaupt funktioniert, war unklar; dennoch war der Reiz groß, ein günstiges Kintex-UltraScale+-Board zu hacken

Herausforderungen beim Debugger

• Laut Xilinx-Dokument UG908 ist es üblich, ein FPGA mit empfohlenen JTAG-Probes zu konfigurieren und zu debuggen; hier wird jedoch statt eines teuren offiziellen Probes eine Open-Source-Alternative wie OpenOCD ausprobiert
• Im Gegenzug für den Verzicht auf den offiziellen Xilinx-Toolchain-Support (etwa ILA) lässt sich eigene Debug-Logik auf Basis von JTAG-USER-Registern entwickeln
• OpenOCD wird zwar hauptsächlich für ARM/RISC-V genutzt, eignet sich aber mit seiner breiten Probe-Unterstützung, der feinen Kontrolle über JTAG-Operationen und dem SVF-Format-Support auch für FPGA-Anwendungen
• Zwar gibt es nur wenige Unterlagen zur Unterstützung der UltraScale+-Serie, doch JTAG- und SVF-Standards sowie die Scan-Struktur bleiben gültig

Gesamtplan

• Beschrieben wird ein schrittweiser Versuchsplan, um ein günstig bei Ebay gekauftes gebrauchtes FPGA-Board ohne offiziellen Support mithilfe von Open-Source-/inoffiziellen Probes wie OpenOCD und JLink als Entwicklungsplattform nutzbar zu machen
• Die einzelnen Schritte verlaufen von der Prüfung, ob das Board grundsätzlich funktioniert, über das Anschließen eines JTAG-Debuggers und das Ermitteln des Pinouts bis zum Übertragen eines Bitstreams

Schritt 1 – Prüfen, ob das Board funktioniert

• Falls der Flash-Speicher nicht gelöscht wurde, kann über den Bitstream des Vorbesitzers zunächst geprüft werden, ob sich ein PCIe-Endpoint identifizieren lässt oder ob über den SFP-PHY Ethernet-Signale anliegen

Schritt 2 – JTAG-Debugger anschließen

• Ermittelt werden müssen die Position der JTAG-Interface-Pins, die Anzahl angeschlossener Geräte und der Zustand der Daisy Chain
• Über die JTAG-Systemregister des FPGA, insbesondere SYSMON, ist auch ein Echtzeit-Monitoring von Temperatur und Spannung möglich; zudem wird auf eine erweiterte Unterstützung in OpenOCD gehofft

Schritt 3 – Pinbelegung ermitteln

• Erforderlich ist eine Analyse der realen Schaltung, etwa zu Typ, Frequenz und Anschluss-Pins externer Taktquellen sowie zu den mit SFP und PCIe verbundenen Transceivern

Schritt 4 – Bitstream schreiben

• Geplant ist eine temporäre Konfiguration über JTAG (unter Umgehung des Flash), entweder mit dem openOCD-virtex2- und pld-Treiber oder durch das Abspielen eines in Vivado erzeugten SVF
• Der komplette Flow von Vivado nach SVF soll automatisiert werden

Erhalt des Boards und erste Tests

• Eingetroffen sind ein Kintex-UltraScale+-FPGA-Board (XCKU3P-FFVB676) aus einem Alibaba-Cloud-Beschleuniger, ein Huawei-SFP28-25G-Transceiver sowie ein OS2-Patchkabel und weiteres Zubehör
• Das Board zeigt zwar gewisse Gebrauchsspuren, Zustand von Komponenten sowie PCIe und SFP ist jedoch gut

Standalone-Stromversorgung prüfen

• Über einen PCIe-USB-Adapter wurde zunächst einfach Spannung eingespeist, um anhand von LEDs und Erwärmung der Hardware das Vorhandensein der Stromversorgung grob zu prüfen

Experiment mit der PCIe-Schnittstelle

• Mithilfe der externen PCIe-Gen2.0-x1-Schnittstelle eines Raspberry Pi 5 wurde das FPGA getestet; obwohl das FPGA Gen3.0 und x8 unterstützt, wurde wegen der Abwärtskompatibilität eine korrekte Erkennung erwartet
• In den Linux-dmesg-Logs wurde das Board als PCIe-Bridge und Endpoint vom Ethernet-Typ erkannt; durch die Vergabe spezieller Vendor-/Device-IDs werden Konflikte mit dem Betriebssystem vermieden
• Mit dem Befehl lspci -vvv wurde der Zustand aller PCIe-Geräte geprüft: Das Board weist zwar Eigenschaften für Gen3.0 x8 aus, bei der tatsächlichen Verbindung mit dem Pi werden Bandbreite und Geschwindigkeit jedoch auf Gen2.0 x1 heruntergestuft, bedingt durch die Grenzen der Bridge und der physischen Anbindung
• Damit wurde bestätigt, dass die PCIe-Schnittstelle des FPGA-Boards grundsätzlich funktioniert

JTAG-Schnittstelle

• Xilinx-FPGAs können über JTAG ihre interne CMOS Configuration Latch (CCL) SRAM-basiert aktualisieren bzw. laden
• Die JTAG-Schnittstelle des realen Boards besteht aus den standardmäßigen vier Leitungen (TCK/TMS/TDI/TDO) sowie Stromversorgungs- und Masse-Signalen; ein Reset kann über die Xilinx-FSM umgesetzt werden
• Die tatsächliche Pin-Anordnung weicht vom Standard ab, daher ist eine gesonderte Verdrahtung erforderlich

Einsatz von Segger JLink

• Da kein offizieller JTAG-Programmer von AMD vorhanden war, wurde ein Segger JLink zusammen mit OpenOCD verwendet
• JTAG lässt sich bereits mit vier GPIOs aufbauen und eignet sich daher gut für improvisierte Experimente
• Es wird ein Verdrahtungsschema zwischen JLink und FPGA-Board gezeigt; wegen Steckbrücken für Breadboards und möglicher Verzögerungen auf langen Signalleitungen wurde die TCK-(Takt-)Geschwindigkeit auf 1–10 MHz begrenzt

OpenOCD-Umgebung

• OpenOCD ist ein Open-Source-On-Chip-Debugger mit Unterstützung für verschiedenste Probes und Boards
• Durch die Unterstützung des standardisierten SVF-Formats ist eine Anbindung an Vivado möglich; weil die Schaltung Open Source ist, lassen sich Probleme zudem leichter selbst analysieren und patchen
• Verwendet wurde eine selbst gebaute aktuelle OpenOCD-Version (0.12.0+dev) zusammen mit der JLink-Bibliothek

JTAG-Scan-Chain prüfen und IDCODE kontrollieren

• Da kein Schaltplan des Boards vorlag, wurden mit der Auto-Scan-Funktion von OpenOCD Geräte und IDCODEs in der JTAG-Chain gesucht
• Es wurde bestätigt, dass das Board dem IDCODE des Xilinx KU3P (0x04a63093) entspricht
• Auch die IR-Länge (Befehlsregisterlänge von 6 Bit) wurde manuell vorgegeben und korrekt erkannt
• Damit konnte die JTAG-Scan-Chain des Boards letztlich vollständig bestimmt werden

SYSMON-Systemmonitor

• Bei älteren Xilinx-Generationen heißt die Funktion XADC, in der UltraScale+-Familie ist eine SYSMON4-Funktion zur Temperatur-/Spannungsmessung integriert
• OpenOCD unterstützt standardmäßig keine SYSMON-Anbindung über JTAG, daher ist eine eigene Erweiterung nötig
• Per Skript lässt sich das System so hacken, dass sogar das Senden von SYSMON-(DRP-)Befehlen und die Echtzeit-Auslesung von Temperatur und Spannung über Statusregister möglich wird

---

Durch diesen Prozess wird die Erfahrung dokumentiert, ein altes FPGA-Beschleuniger-Board von Alibaba Cloud ohne offiziellen Support günstig zu beschaffen und allein mit Open-Source-Tools eine Grundlage für Debugging und Nutzung aufzubauen, einschließlich PCIe-/JTAG-Schnittstellen und System-Monitoring.

[GN⁺]

Hacker-News-Kommentare

• Ich habe versucht, die PCIe-Schnittstelle des Lattice-Certus-Pro-NX-"Versa"-Boards mit einem Raspberry Pi V zu testen, und fand das wirklich praktisch. Der Raspberry Pi V ist schnell genug, um aktuelle Desktop-Software auszuführen (sogar Microsoft Teams!). Ich konnte FPGA-Designs live demonstrieren und während eines Konferenzgesprächs meinen Desktop-Bildschirm teilen. Schade ist nur die mangelhafte Dokumentation des SoC von Broadcom. Intel stellte nach einem NDA alle Chip-Dokumente bereit, sodass ich auf einem Xeon Ivy Bridge eine großartige FPGA-PCIe-Umgebung umsetzen konnte. Nachdem ich die PCI-Konfigurationsregister gespeichert hatte, konnte ich das FPGA neu konfigurieren und die Register erneut programmieren, woraufhin der Chip ohne Server-Neustart oder erneute Erkennung (re-enumerate) am Bus erschien, was sehr praktisch war. Der Trick bestand darin, während der Neukonfiguration vorübergehend das Root-Complex-Bit zu setzen, um die PCIe-Fehlererkennung zu deaktivieren. (Damals habe ich ein Altera Stratix-IIgx verwendet.) Es scheint auch noch andere Wege zu geben, daher hier als Referenz: Stack-Overflow-Link Insgesamt ist die Fehlerberichterstattung beim PCIe-Start sehr nützlich, wenn die Dokumentation gut ist.

  • Ein wirklich cooler Trick. In meinem Fall hatte ich unter Linux mehrfach Probleme, als ich an der PCIe-Konfiguration herumgespielt habe. Wir haben das am Ende mit Partial Reconfiguration gelöst, sodass der PCIe-Teil unverändert blieb und nur andere Teile neu geladen wurden. Beim Layout und bei der Platzreservierung gab es dabei natürlich Trade-offs.

• Wenn man einen FT2232H-Adapter hat (oder keinen hat, dann lohnt sich der Kauf), kann man ihn so flashen, dass er leicht mit Vivado kompatibel ist. Siehe: Vivado FTDI Device Programming Guide

  • In unserer Firma haben wir immer 20 bis 30 FT2232H auf Lager. Sie sind wirklich nützlich, weil sie viele Protokolle unterstützen, darunter GPIO, I2C, SPI und parallel FIFO. Und die Python-Bibliothek pyFTDI ist hervorragend.

  • Ich habe noch so einen Adapter aus einem anderen Projekt herumliegen, habe aber noch nie mit FPGA gearbeitet. Ich frage mich, was es in der Praxis bedeutet, dass er mit Vivado kompatibel ist. Heißt das, man kann AMD-FPGAs konfigurieren, oder ist etwas anderes gemeint?

• Das erinnert mich an Alibabas innovativen Einsatz von FPGA-Clustern im Datenbankbereich, bei dem LSM-Compaction in einer angepassten MySQL-Storage-Engine verarbeitet wurde. Siehe: zugehöriges Paper als PDF Gegenüber RocksDB wurden Durchsatz und Latenz stark verbessert, bei manchen Workloads sogar um eine Größenordnung. Sie haben diese Technik auch als Service angeboten, sie aber schließlich wieder eingestellt. Ich weiß nicht, ob sie sie intern noch nutzen, aber es hat mich überrascht, wie wenige Orte Hardwarebeschleunigung für wiederkehrende Datenbankaufgaben einsetzen.

  • AWS hat vor einigen Jahren ebenfalls einen eigenen Hardware-Query-Beschleuniger in Redshift verwendet. Siehe: Redshift AQUA vorgestellt In letzter Zeit scheint AWS sich stärker auf P&L zu konzentrieren, daher weiß ich nicht, wie viel Aufmerksamkeit oder Performance-Gewinn das noch bringt.

• Wer sich für FPGA-PCIe- oder PCI-Karten interessiert: Es gibt auch ziemlich viele gebrauchte Gidel-Boards. Es gibt verschiedene Serien wie ProcSpark und ProcStar. Die offizielle Software ist proprietär, und weil mehrere FPGAs verbaut sind, muss man für die direkte Nutzung in Quartus erst die Pinbelegung herausfinden. Ich habe ein Board mit einem riesigen Stratix IV bekommen. Ein Kintex-UltraScale+-Board ist wirklich extrem begehrenswert, daher hat mich dieser Beitrag sehr beeindruckt.

  • Ich habe das Top-Level-Verilog-Modul und die Vivado-.xdc-Datei (Pinmap, Timing-Constraints usw.) für das Gidel HawkEye 20G-48 bekommen. Das SDK von Gidel hatte ich nicht. Als Langzeitprojekt möchte ich zwei davon über 10 GbE verbinden und daraus einen PCIe-TLP-Sniffer/Middleman/Device-Emulator bauen. Die verbleibenden 10-GbE-Ports sollen genutzt werden, um gesniffte und injizierte TLPs an einen Host-PC zu senden. Das PCIe-hard-IP des Aria-10-FPGA kann sowohl im Root- als auch im Endpoint-Modus arbeiten, daher muss das ohne Quartus-IP-Modul vollständig transparent umgesetzt werden. Ich weiß nicht, wie gut es sich anfühlen wird, PCIe-TLPs schneller Geräte über einen 10-Gigabit-Link zu transportieren, aber fail0verflow hat sogar einen TLP-Proxy über UART mit 115200 Baud erfolgreich hinbekommen. Gidel HawkEye 20G-48 Referenzlink fail0verflow-Präsentationsfolien

• Wenn man in China ist, wird dasselbe Produkt auf idlefish für 480 Yuan (etwa 68 Dollar) verkauft. Es ist kaum zu glauben, wie billig das ist, deshalb werde ich es selbst ausprobieren.

• Ich weiß nicht, ob jemand inzwischen die Pinout-Informationen des rückseitigen SFP-Anschlusses herausgefunden hat. Wenn das dokumentiert wäre und auch die PCIe-Lanes bestätigt wären, könnte es Spaß machen, daraus eigene optische Netzwerkhardware zu bauen. Ein SFP-Transceiver gibt das Eingangssignal einfach wieder aus, daher könnte man damit interessante eigene optische Signalgeräte bauen, entweder mit einem PCIe-Backplane oder auch alleinstehend.

  • Die Pinout-Informationen für den SFP-Anschluss stehen schon im Pinout-Abschnitt.

• Kennt jemand Beispiele dafür, dass mit FPGAs neuronale Netze oder andere connectionistische Architekturen umgesetzt wurden? Das Interessanteste an FPGAs ist, dass sich auch Universitäten oder Einzelpersonen "Custom"-Chips leisten können. In einer Zeit, in der sich AI stark auf LLMs konzentriert, denke ich, dass kleine Gruppen oder Einzelpersonen mit FPGAs tierorientierte Bottom-up-Ansätze für künstliche Intelligenz ausprobieren könnten.

  • Bei FNAL werden FPGA-basierte neuronale Netze für Inferenz bei den Ergebnissen der LHC/CMS-Hochenergiephysikexperimente verwendet. Es gibt auch Fälle, in denen dynamische Systeme im Mikrosekundenbereich gesteuert werden. Referenzen: HLS4ML CERN-IRIS-HEP-Präsentation als PDF Deploying tinyML on FPGAs Whitepaper NeurIPS-ML4PhysicalSciences-Beispiel als PDF

  • Ich frage mich, ob mit "neuronale Netze auf FPGAs umsetzen" gemeint ist, sie als Hardwarebeschleuniger für Inferenz zu verwenden, oder ob das gesamte Netz einschließlich der Gewichte direkt in eine FPGA-Architektur synthetisiert werden soll. In jedem Fall kann ein FPGA keine völlig beliebige Logik umsetzen, sondern nutzt begrenzte Blöcke als Ergebnis der Softwaresynthese. Für Dinge wie LLMs, die viel Speicher mit hoher Bandbreite brauchen, ist das nicht geeignet. Man kann zwar Hochgeschwindigkeitsspeicher an ein FPGA anbinden, aber GPUs sind dafür heute deutlich besser geeignet.

  • Differentiable logic gate networks sind in diesem Zusammenhang interessant.

  • Referenzpapier: arXiv:2404.10076

  • Ich frage mich, warum das so viele Downvotes bekommen hat. So wie ich es verstehe, braucht AI viel RAM und schnelles RAM für die Modelle, daher sind FPGAs dafür nicht geeignet. FPGAs haben zwar Pins, an die man schnellen RAM anschließen kann, aber das Boarddesign und die Leiterbahnführung über die Layer werden dadurch sehr kompliziert. Deshalb sind Grafikkarten deutlich besser geeignet.

• Wenn ich diesen AI-Hype sehe, denke ich persönlich Folgendes:

  • Langfristig scheint mir die Einstiegshürde bei Inferenz-Hardware nicht besonders hoch zu sein (beim Training bin ich mir nicht sicher).
  • Das Modell selbst ist eine leicht austauschbare Commodity.
  • Die Markteinführung von Produkten verläuft langsamer als erwartet; drei Jahre nach dem Start von ChatGPT habe ich den gewünschten Dienst immer noch nicht gefunden (Dokumente hochladen und danach Fragen dazu stellen).
  • Ich frage mich, was genau mit dem Hochladen von Dokumenten und anschließendem Fragen gemeint ist. Unterstützen Dienste wie NotebookLM oder Gem von Gemini diese Funktion nicht bereits? (Alternativen anderer Anbieter kenne ich nicht so gut.)

• Es sind immer noch viele auf eBay verfügbar eBay-Link Es sieht nicht so aus, als wären GPIOs über Header oder Ähnliches herausgeführt; falls jemand gute Projektideen hat, die sich damit sinnvoll umsetzen lassen, würde ich mich über Vorschläge freuen.

  • Wirklich gute Nachrichten. Während der Covid-Zeit war diese Art günstiger Hardware komplett verschwunden, und jetzt kann man wieder einen Kintex für 200 Dollar bekommen. Als ich jünger war, fand ich solche Karten immer faszinierend, und bei 2x SFP und PCIe muss ich an das NetFPGA-Projekt denken. Diese Karte ist dafür perfekt.

• Ich fand den Hinweis bemerkenswert, dass "ein Reisekoffer für das Board mitgeliefert wird". Ich frage mich, warum das so ist. Werden diese Boards im Rechenzentrum oft ausgebaut und transportiert? Oder hat der eBay-Verkäufer sie einfach zum Schutz hineingelegt?

  • Das ist dafür gedacht, sie ins Field mitzunehmen. Denn Field Programmable Gate Array heißt schließlich, dass es im Feld programmierbar ist. (Scherz)