1 points par GN⁺ 2025-10-05 | 1 commentaires | Partager sur WhatsApp
  • Présentation d’une expérimentation consistant à acheter une carte FPGA Kintex UltraScale+ à 200 dollars et à l’utiliser comme plateforme de développement
  • Cette carte est vendue sans documentation officielle ni garantie, ce qui pose des défis pour le débogage JTAG et la configuration initiale
  • Exploration de la possibilité de mettre en place de manière autonome un environnement de configuration et de débogage FPGA à l’aide d’OpenOCD et de Segger JLink
  • Les objectifs de l’expérimentation incluent la vérification des interfaces PCIe/Ethernet, la validation du pinout et la surveillance système d’un FPGA d’occasion
  • L’article récapitule les procédures étape par étape et les retours d’expérience pour l’initialisation, la connexion JTAG, l’identification de la scan chain et la surveillance de la température/de la tension

Introduction

  • L’auteur souhaitait un FPGA puissant pour le prototypage de projets de grande ampleur, en particulier un UltraScale+ de la gamme Xilinx Virtex, mais à cause du coût et du poids de la licence Vivado Enterprise, il a restreint son choix aux puces Kintex UltraScale+ prises en charge par WebPack (XCKU3P, XCKU5P)
  • Même ces puces offrent des caractéristiques élevées, bien au-delà d’un usage amateur, avec de nombreux LUT et des transceivers GTY
  • Il lui fallait une carte de développement répondant au minimum aux critères suivants : 2 ports SFP+ ou 1 port QSFP, JTAG et PCIe x8 ou plus ; après avoir envisagé une conception maison, l’achat d’un produit Alinx et l’exploration du marché de l’occasion, il a acheté sur Ebay une carte FPGA d’accélération Alibaba Cloud pour 200 dollars
  • La carte achetée ne bénéficiait d’aucun support documentaire et son état de fonctionnement était inconnu, mais l’idée de bricoler une carte Kintex UltraScale+ à bas prix l’a séduit

Défis liés au débogueur

  • D’après le document UG908 de Xilinx, il est habituel de configurer et déboguer le FPGA avec une sonde JTAG recommandée, mais ici l’auteur a tenté une alternative open source (OpenOCD, etc.) au lieu d’une sonde officielle coûteuse
  • En renonçant à la toolchain officielle de Xilinx (ILA, etc.), il reste possible de développer sa propre logique de débogage fondée sur les registres JTAG USER
  • OpenOCD est surtout utilisé pour ARM/RISC-V, mais il peut aussi servir avec les FPGA grâce à la prise en charge d’un large éventail de sondes, au contrôle fin des opérations JTAG et au support du format SVF
  • La documentation sur la prise en charge de la série UltraScale+ est rare, mais les standards JTAG et SVF ainsi que la structure de scan restent valides

Plan global

  • Il s’agit d’un plan d’expérimentation par étapes pour transformer une carte FPGA d’occasion achetée à bas prix sur Ebay en plateforme de développement, au moyen de sondes open source/non officielles sans support constructeur (OpenOCD, JLink, etc.)
  • Les étapes suivent la progression suivante : vérification du fonctionnement des composants de la carte → connexion d’un débogueur JTAG → identification du pinout → transfert du bitstream

Étape 1 - Vérifier que la carte fonctionne correctement

  • Si la mémoire Flash n’a pas été effacée, on peut effectuer une première vérification de fonctionnement via le bitstream du précédent utilisateur, en identifiant l’endpoint PCIe ou en observant la présence d’un signal Ethernet sur le PHY SFP

Étape 2 - Connecter un débogueur JTAG

  • Il faut identifier l’emplacement des broches de l’interface JTAG, le nombre de périphériques connectés et l’état de la daisy chain
  • Il est aussi possible d’exploiter les registres système JTAG du FPGA, notamment SYSMON, pour surveiller en temps réel température et tension ; l’auteur espère également une extension du support dans openOCD

Étape 3 - Identifier le pinout

  • Il faut analyser le circuit réel pour déterminer le type de source d’horloge externe, sa fréquence, les broches connectées, ainsi que les informations sur les transceivers reliés au SFP et au PCIe

Étape 4 - Écrire le bitstream

  • Le plan consiste à utiliser soit une configuration temporaire via JTAG (en contournant la Flash), soit le pilote virtex2 + pld d’openOCD, soit la relecture d’un SVF généré depuis Vivado
  • L’automatisation complète du flux Vivado → SVF est également prévue

Réception de la carte et tests initiaux

  • Réception d’une carte FPGA Kintex UltraScale+ (XCKU3P-FFVB676) issue d’un accélérateur Alibaba Cloud, ainsi que d’un transceiver Huawei SFP28 25G et d’un câble patch OS2, entre autres accessoires fournis
  • La carte montre quelques traces d’usage, mais les accessoires ainsi que l’état du PCIe/SFP sont corrects

Vérification de l’alimentation en mode autonome

  • Une première vérification de l’alimentation a été effectuée simplement en injectant du courant via un adaptateur PCIe-USB, puis en observant les LED et l’échauffement du matériel

Expérience sur l’interface PCIe

  • En utilisant l’interface externe PCIe Gen2.0 x1 d’un Raspberry Pi 5 pour tester le FPGA (compatible Gen3.0, x8), on pouvait s’attendre à une détection correcte grâce à la rétrocompatibilité
  • Dans les logs dmesg de Linux, la carte apparaît comme un bridge PCIe et un endpoint (de type Ethernet) ; l’attribution d’un couple vendor/device id non standard évite les conflits côté OS
  • La commande lspci -vvv permet de vérifier l’état complet des périphériques PCIe : bien que la carte annonce des capacités Gen3.0 x8, la bande passante et la vitesse sont en pratique rétrogradées à Gen2.0 x1 lorsqu’elle est reliée au Pi, en raison des limites du bridge et de la connexion physique réelle
  • Cela a permis de confirmer le bon fonctionnement de l’interface PCIe de la carte FPGA

Interface JTAG

  • Les FPGA Xilinx peuvent mettre à jour/charger en mode SRAM le CMOS Configuration Latch (CCL) interne via JTAG
  • Sur la carte physique, l’interface JTAG se compose des 4 signaux standard (TCK/TMS/TDI/TDO) ainsi que de l’alimentation et de la masse ; le reset peut être implémenté via la FSM Xilinx
  • Le brochage réel diffère toutefois du standard, ce qui nécessite un câblage spécifique

Utilisation de Segger JLink

  • En l’absence d’un programmateur JTAG officiel AMD, l’auteur a utilisé un Segger JLink avec OpenOCD
  • Comme le JTAG peut être mis en place avec seulement 4 GPIO, cette approche se prête bien aux expérimentations improvisées
  • Un schéma de câblage entre le JLink et la carte FPGA est fourni ; compte tenu de l’usage de jumpers pour breadboard et des délais de signal sur une grande longueur, la vitesse d’horloge TCK a été limitée entre 1 et 10 MHz

Environnement OpenOCD

  • OpenOCD est un débogueur open source on-chip prenant en charge diverses sondes et cartes
  • Il prend en charge le format SVF standard (interopérable avec Vivado) et, comme son circuit logiciel est open source, il est plus facile d’analyser ou corriger directement les problèmes si nécessaire
  • Une version récente d’OpenOCD (0.12.0+dev) ainsi que la bibliothèque JLink ont été compilées manuellement pour l’expérience

Vérification de la JTAG Scan Chain et contrôle de l’IDCODE

  • Sans schéma de la carte, l’auteur a utilisé la fonction de scan automatique d’OpenOCD pour découvrir les périphériques et les IDCODE présents dans la chaîne JTAG
  • Il a été confirmé que cette carte correspond à l’IDCODE du Xilinx KU3P (0x04a63093)
  • La détection correcte a également nécessité de spécifier manuellement la longueur d’IR (registre d’instruction sur 6 bits)
  • Au final, la JTAG scan chain de la carte a pu être établie clairement

Moniteur système SYSMON

  • Les anciennes générations Xilinx utilisent XADC, tandis que la famille UltraScale+ intègre SYSMON4 pour les mesures de température et de tension
  • openOCD ne prend pas en charge par défaut l’intégration JTAG de SYSMON, ce qui a nécessité un ajout manuel
  • Il est possible, au moyen de scripts bricolés, d’aller jusqu’à l’envoi de commandes SYSMON (DRP) et à la consultation en temps réel de la température et de la tension via les registres de statut

À travers ce processus, l’auteur documente son expérience consistant à acquérir à faible coût une ancienne carte d’accélération FPGA Alibaba Cloud sans support officiel, puis à établir, uniquement avec des outils open source, une base exploitable de débogage et d’utilisation (interfaces PCIe/JTAG, surveillance système).

1 commentaires

 
GN⁺ 2025-10-05
Avis Hacker News
  • J’ai testé l’interface PCIe de la carte Lattice Certus-Pro NX « Versa » avec un Raspberry Pi V, et c’était vraiment pratique Le Raspberry Pi V est assez rapide pour faire tourner des logiciels de bureau récents, jusqu’à Microsoft Teams ! J’ai pu faire une démo en direct d’un design FPGA et partager l’écran du bureau pendant une conférence téléphonique Le seul regret, c’est le manque de documentation sur les SoC de Broadcom Intel, lui, fournit toute la documentation des puces sous NDA, ce qui m’a permis de mettre en place un bel environnement FPGA PCIe sur un Xeon Ivy Bridge En sauvegardant les registres de configuration PCI, puis en reconfigurant le FPGA et en reprogrammant les registres, la puce réapparaissait sur le bus sans redémarrer le serveur ni relancer une re-énumération, ce qui était très pratique Le secret consistait à définir temporairement le bit root complex pendant la reconfiguration pour désactiver la détection d’erreurs PCIe (J’utilisais alors un Altera Stratix-IIgx) Il y a sans doute d’autres méthodes, donc je laisse cette référence : lien Stack Overflow Globalement, quand la documentation est bonne, le reporting d’erreurs est très utile pendant la séquence d’initialisation PCIe

    • Je trouve que c’est une astuce vraiment élégante Dans mon cas, j’ai rencontré plusieurs problèmes en bricolant la configuration PCIe sous Linux Au final, on a résolu ça avec la Partial Reconfiguration, en laissant intacte la partie PCIe et en ne rechargeant que le reste Il y avait clairement des compromis en termes de layout et de réservation d’espace
  • Si vous avez un adaptateur FT2232H (ou sinon je vous conseille d’en acheter un), on peut facilement le flasher pour qu’il soit compatible avec Vivado Référence : guide Vivado FTDI Device Programming

    • Dans notre entreprise, on garde toujours 20 à 30 FT2232H en stock C’est vraiment utile grâce à la prise en charge de nombreux protocoles comme GPIO, I2C, SPI, parallel FIFO, etc. Et la bibliothèque Python pyFTDI est excellente

    • J’ai cet adaptateur qui me reste d’un autre projet, mais je n’ai jamais fait de travail sur FPGA Je me demande ce que signifie concrètement le fait qu’il soit compatible avec Vivado Est-ce que ça permet de configurer des FPGA AMD, ou est-ce que cela signifie autre chose ?

  • Cela me rappelle un cas très innovant où Alibaba traitait la compaction LSM en base de données avec un cluster de FPGA via un moteur de stockage MySQL personnalisé Référence : PDF de l’article Le débit et la latence étaient fortement améliorés par rapport à RocksDB, et sur certaines charges cela allait encore plus loin Ils ont même proposé cette technologie comme service, avant de finalement l’abandonner Je ne sais toujours pas s’ils l’utilisent encore en interne, mais j’étais surpris de voir si peu d’acteurs utiliser l’accélération matérielle pour des tâches de base de données répétitives

    • AWS utilisait aussi il y a quelques années son propre accélérateur matériel de requêtes pour Redshift Référence : présentation de Redshift AQUA Plus récemment, AWS semble davantage se concentrer sur le P&L, donc je ne sais pas trop ce qu’il en est de la visibilité ou des gains de performance
  • Si les FPGA PCIe ou les cartes PCI vous intéressent, on trouve aussi pas mal de cartes Gidel d’occasion Il existe différentes séries, comme ProcSpark/ProcStar Le logiciel officiel est propriétaire, et comme il y a plusieurs FPGA, il faut retrouver le pinout pour les utiliser directement dans Quartus J’ai réussi à récupérer une carte équipée d’un énorme Stratix IV Les cartes Kintex UltraScale+ sont vraiment très désirables, donc cet article m’a beaucoup marqué

    • J’ai obtenu le module Verilog top-level et le fichier Vivado .xdc (pin map, contraintes de timing, etc.) pour la Gidel HawkEye 20G-48 Je n’avais pas le SDK de Gidel J’ai comme projet de long terme d’en connecter deux en 10 GbE pour en faire un sniffer / homme-du-milieu / émulateur de périphérique PCIe TLP Les ports 10 GbE restants serviraient à transmettre les TLP sniffés et injectés vers le PC hôte Le hard IP PCIe de l’Aria 10 FPGA peut fonctionner en mode root comme en mode endpoint, donc il faudrait faire ça de manière totalement transparente, sans module IP Quartus Je ne sais pas trop ce que ça donnera de faire passer les PCIe TLP d’un périphérique rapide sur un lien 10 gigabits, mais fail0verflow a même réussi un proxy TLP sur une liaison UART à 115200 bauds lien de référence Gidel HawkEye 20G-48 slides fail0verflow
  • Si vous êtes en Chine, le même produit est vendu 480 yuans (environ 68 dollars) sur idlefish C’est presque incroyablement bon marché, donc je vais probablement tenter le coup moi-même

  • Je ne sais pas si quelqu’un a déjà trouvé les informations de pinout du connecteur SFP à l’arrière Si cette partie est documentée et que les lignes PCI-e sont aussi confirmées, je me dis que ce serait amusant d’en faire un équipement réseau optique personnalisé Les émetteurs-récepteurs SFP restituent simplement ce qu’on leur injecte, donc il serait possible de fabriquer un dispositif optique personnalisé intéressant, que ce soit sur un backplane PCIe ou en autonome

    • Les informations de pinout du connecteur SFP figurent déjà dans la section pinout
  • Est-ce que quelqu’un connaît des exemples de mise en œuvre de réseaux de neurones, ou d’autres architectures connexionnistes, sur FPGA ? Ce qui m’intéresse le plus avec les FPGA, c’est que des puces « personnalisées » restent à la portée des universités ou même des particuliers À un moment où l’IA est très centrée sur les LLM, je pense que de petits groupes ou des individus ont une opportunité d’expérimenter avec les FPGA sur des approches d’intelligence artificielle bottom-up plus inspirées des animaux

    • Au FNAL, on utilise des réseaux de neurones sur FPGA pour l’inférence des résultats expérimentaux de physique des hautes énergies du LHC/CMS Il existe aussi des cas de contrôle de systèmes dynamiques à l’échelle de la microseconde Quelques références : HLS4ML PDF de présentation CERN IRIS-HEP Deploying tinyML on FPGAs Whitepaper PDF cas NeurIPS ML4PhysicalSciences

    • Je me demande si, par « mise en œuvre de réseaux de neurones sur FPGA », vous parlez d’inférence via accélération matérielle, ou de synthétiser directement l’ensemble du réseau, poids compris, dans l’architecture FPGA Dans tous les cas, un FPGA ne met pas en œuvre une logique totalement arbitraire : on exploite des blocs limités à partir du résultat de la synthèse logicielle Pour des cas comme les LLM, qui nécessitent beaucoup de mémoire à haute capacité et haute bande passante, ce n’est pas très adapté On peut certes connecter de la mémoire rapide à un FPGA, mais aujourd’hui les GPU sont nettement meilleurs pour cet usage

    • Les differentiable logic gate networks valent le détour

    • Référence : arXiv:2404.10076

    • Je me demande pourquoi il y a autant de downvotes Si j’ai bien compris, l’IA a besoin de beaucoup de RAM, et de RAM rapide, donc les FPGA ne sont pas adaptés Les FPGA ont des broches pour connecter de la RAM rapide, mais la conception de la carte et le routage des couches deviennent très complexes C’est pour cela qu’une carte graphique est bien plus appropriée

  • Avec tout cet engouement autour de l’IA, j’ai personnellement cette impression

    • à long terme, le matériel d’inférence n’aura probablement pas de grosses barrières à l’entrée (je ne sais pas trop pour l’entraînement)
    • les modèles eux-mêmes sont des commodités facilement remplaçables
    • la mise sur le marché des produits est plus lente que prévu : cela fait déjà 3 ans depuis la sortie de ChatGPT, et je n’ai toujours pas trouvé le service que je veux (téléverser des documents puis poser des questions)
    • Je me demande ce que vous entendez exactement par la possibilité de poser des questions après téléversement de documents J’ai l’impression que des services comme NotebookLM ou Gem de Gemini prennent déjà en charge cette fonction (je connais moins bien les alternatives chez d’autres fournisseurs)
  • Il y a encore beaucoup de stock sur eBay lien eBay Il ne semble pas y avoir de GPIO exposés via des headers ou autre ; si vous avez de bonnes idées de projets adaptés à cette carte, je suis preneur

    • Excellente nouvelle Pendant la période Covid, ce genre de matériel bon marché avait complètement disparu, et on peut maintenant à nouveau obtenir un Kintex pour 200 dollars Quand j’étais plus jeune, j’étais fasciné par ce type de carte, et avec 2x SFP et PCIe, cela me fait penser au projet NetFPGA Cette carte est parfaite pour ce genre d’usage
  • Le fait que « la carte est livrée avec une mallette de voyage » m’a marqué Je me demande pourquoi : est-ce que ce type de carte est souvent retiré et déplacé dans les datacenters ? Ou bien est-ce simplement le vendeur eBay qui l’a ajoutée pour la protéger ?

    • C’est pour l’emmener sur le terrain Parce que Field Programmable Gate Array, autrement dit programmable sur le terrain (blague)