Le test « Hello, world » de Xillybus
C’est la troisième étape pour démarrer avec Xillybus : le bitstream qui contient Xillybus a déjà été chargé dans le FPGA, et le pilote est installé sur l’hôte. Il est maintenant temps de faire un test simple. Le but de ce test est de vérifier que les fichiers de périphérique ont bien été créés et qu’ils fonctionnent.
Cette page traite de Xillybus sur un hôte Linux. Il existe une page similaire pour Microsoft Windows.
Je vais me concentrer ici sur Xillybus avec PCIe, mais tout se passe presque de la même manière avec XillyUSB. Les différences sont indiquées en bas de cette page. En ce qui concerne Xillinux, tout fonctionne de la même façon, sauf pour ce qui touche directement au PCIe.
Pour plus d’informations sur ce sujet, reportez-vous au document Getting started with Xillybus on Linux.
Le périphérique PCIe est-il détecté ?
La première chose à vérifier est que l’ordinateur reconnaît le FPGA comme un périphérique PCIe. Utilisez la commande « lspci » pour cela. Cette commande affiche tous les périphériques que l’ordinateur a trouvés sur le bus PCIe. Parfois, la liste est très longue.
Par exemple, avec Xillybus sur un FPGA Xilinx / AMD :
$ lspci [ ... several lines ... ] 01:00.0 Class ff00: Xilinx Corporation Device ebeb [ ... several lines ... ]
Et avec Altera :
01:00.0 Class ff00: Altera Corporation Unknown device ebeb
La sortie peut être légèrement différente sur votre ordinateur. L’important, c’est « ebeb ». Il s’agit de l’identifiant de périphérique (Device ID), qui indique qu’on a affaire à un périphérique Xillybus.
Si aucune ligne de ce type n’apparaît dans la sortie de lspci, il y a un problème avec le FPGA. La raison est souvent une confusion sur le bitstream chargé dans le FPGA.
Le pilote a-t-il démarré correctement ?
L’étape suivante consiste à vérifier l’état du pilote. Le plus simple est de chercher le mot « xillybus » dans le journal du noyau. Par exemple :
$ 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.
Le format de la sortie varie d’un ordinateur à l’autre. La ligne qui mentionne ASPM est normale et n’indique pas une erreur. Mais il est aussi acceptable qu’elle n’apparaisse pas.
La ligne « Created 5 device files » confirme que le pilote a initialisé Xillybus avec succès. Si cette ligne est absente, un problème est survenu lors de l’initialisation du pilote.
S’il y a d’autres lignes relatives à Xillybus dans le journal du noyau, elles peuvent aider à comprendre ce qui n’a pas fonctionné. Il s’agit en général d’un problème dans la logique du FPGA. Cela arrive notamment lorsque le bloc PCIe du FPGA est configuré de manière incorrecte. Par exemple, si vous avez modifié les paramètres du bloc PCIe dans le pack de démonstration, cela peut empêcher le pilote de s’initialiser correctement.
Et s’il n’y a aucune ligne contenant le mot « xillybus » dans le journal du noyau, alors qu’une ligne avec « ebeb » apparaît dans la sortie de lspci ? Cela signifie que le pilote n’est pas chargé dans le noyau. Vérifiez cela avec lsmod comme suit :
$ lsmod | grep xillybus xillybus_pcie 16384 0 xillybus_core 28672 1 xillybus_pcie
Cet exemple montre la sortie correcte lorsque le pilote est chargé dans le noyau. Les nombres (16384 et 28672) peuvent être différents. Il est possible que xillybus_class apparaisse également dans cette liste.
Notez que si vous venez d’installer ce pilote, vous devez redémarrer l’ordinateur ou charger le pilote manuellement avec insmod.
« Hello, world »
Le pilote crée cinq fichiers de périphérique : /dev/xillybus_read_8, /dev/xillybus_read_32, /dev/xillybus_write_8, /dev/xillybus_write_32 et /dev/xillybus_mem_8. Notez que si vous créez un cœur IP personnalisé (custom IP core) sur l’IP Core Factory, vous pouvez choisir le nombre de fichiers de périphérique créés, ainsi que leurs noms et leurs propriétés.
Mais pour l’instant, le FPGA contient le pack de démonstration. Essayons donc deux de ces fichiers de périphérique.
Il y a une boucle de retour (loopback) dans le pack de démonstration entre read_8 et write_8. Cela signifie que lorsque l’ordinateur écrit des données vers write_8, le FPGA renvoie exactement les mêmes données via read_8. Cela ne sert que de démonstration. Cette boucle n’a aucune autre utilité pratique.
Voici le test : ouvrez deux fenêtres de terminal sur l’ordinateur. Vous pouvez aussi utiliser toute autre disposition qui vous donne deux invites shell. Par exemple, deux connexions SSH.
Tapez ceci sur la première invite shell :
$ cat /dev/xillybus_read_8
Puis tapez ceci sur la deuxième invite shell :
$ cat > /dev/xillybus_write_8
Tapez maintenant n’importe quoi dans le deuxième terminal et appuyez sur Entrée. Le même texte apparaîtra dans le premier terminal. Cela montre comment le texte a été écrit dans le fichier de périphérique d’écriture, a atteint le FPGA, puis est revenu vers l’ordinateur.
Même si cet exemple est simple, il est important de comprendre comment cela fonctionne. En particulier, il est important de comprendre comment la logique du FPGA a rendu cela possible. C’est le point de départ pour intégrer votre propre logique.
Si ces commandes échouent à cause d’une erreur de permission (permission denied), réessayez en tant que root. Vous pouvez aussi installer le fichier udev, comme suggéré précédemment.
XillyUSB
Si vous utilisez XillyUSB, tout ce qui a été dit ci-dessus s’applique, mais avec quelques différences.
XillyUSB dispose d’un outil appelé showdiagnostics qui permet d’examiner la qualité de la connexion physique avec le FPGA. Il est vivement recommandé d’utiliser cet outil afin de vous assurer que la liaison de données brute est exempte d’erreurs. Même si XillyUSB semble fonctionner parfaitement, il est important de procéder à cette vérification. En effet, le protocole USB 3.0 masque les erreurs de la liaison de données brute, mais ces erreurs peuvent quand même provoquer de rares problèmes qui ressemblent à un bug.
Il n’y a aucune raison de tolérer ce genre d’erreurs. La solution est souvent simple, par exemple utiliser un autre port USB de l’ordinateur.
Autres différences :
- Utilisez lsusb au lieu de lspci.
- Les modules du pilote sont xillyusb et éventuellement xillybus_class.
- Il n’est pas nécessaire de redémarrer l’ordinateur après l’installation du pilote. Le pilote est chargé automatiquement lorsque le périphérique est connecté au port USB (après avoir été déconnecté).
- Les noms des fichiers de périphérique sont légèrement différents. Par exemple, au lieu de /dev/xillybus_read_8, le nom est /dev/xillyusb_00_read_8. La partie « 00 » peut varier.