La prueba «Hola, mundo» de Xillybus
Este es el tercer paso para empezar con Xillybus: el flujo de bits (bitstream) que contiene Xillybus ya está cargado en la FPGA, y el controlador está instalado en el ordenador anfitrión. Ahora toca hacer una prueba sencilla. El propósito de esta prueba es comprobar que se han creado los archivos de dispositivo (device files) y que funcionan.
Esta página trata de Xillybus cuando el ordenador anfitrión usa Linux. Hay una página similar para Microsoft Windows.
Aquí me centraré en Xillybus con PCIe, pero con XillyUSB casi todo es igual. Las diferencias se indican al final de esta página. En cuanto a Xillinux, todo funciona de la misma manera, salvo en los temas que tienen que ver directamente con PCIe.
Para más información sobre este tema, consulta Cómo empezar con Xillybus en Linux.
¿Se detecta el dispositivo PCIe?
Lo primero que hay que comprobar es que el ordenador reconoce la FPGA como un dispositivo PCIe. Para ello, usa el comando lspci. Este comando muestra todos los dispositivos que el ordenador ha encontrado en el bus PCIe. A veces la lista es muy larga.
Por ejemplo, con Xillybus en una FPGA de Xilinx / AMD:
$ lspci [ ... several lines ... ] 01:00.0 Class ff00: Xilinx Corporation Device ebeb [ ... several lines ... ]
Y con Altera:
01:00.0 Class ff00: Altera Corporation Unknown device ebeb
La salida puede ser un poco diferente en tu ordenador. Lo importante es ebeb. Se trata del identificador de dispositivo (Device ID), que indica que es un dispositivo Xillybus.
Si no aparece una fila así en la salida de lspci, hay algún problema con la FPGA. A menudo el motivo es una confusión sobre qué flujo de bits se ha cargado en la FPGA.
¿Se ha iniciado el controlador correctamente?
El siguiente paso es comprobar el estado del controlador. La forma más fácil es buscar la palabra «xillybus» en el registro del kernel (kernel log). Por ejemplo:
$ 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.
El formato de la salida varía de un ordenador a otro. La fila que menciona ASPM es normal y no indica un error. Tampoco pasa nada si esa fila no aparece.
La fila que dice «Created 5 device files» confirma que el controlador ha inicializado Xillybus correctamente. Si esa fila no aparece, hubo un problema al inicializar el controlador.
Si hay otras filas en el registro del kernel relacionadas con Xillybus, pueden ayudar a explicar qué ha ido mal. Normalmente se trata de un problema con la lógica de la FPGA. En particular, esto suele ocurrir cuando el bloque PCIe de la FPGA está mal configurado. Por ejemplo, si cambiaste los parámetros del bloque PCIe en el paquete de demostración (demo bundle), puede impedir que el controlador se inicialice correctamente.
¿Y si no hay ninguna fila que contenga la palabra «xillybus» en el registro del kernel, pero en la salida de lspci sí hay una fila con «ebeb»? Eso significa que el controlador no está cargado en el kernel. Compruébalo con lsmod de la siguiente manera:
$ lsmod | grep xillybus xillybus_pcie 16384 0 xillybus_core 28672 1 xillybus_pcie
Este ejemplo muestra la salida correcta cuando el controlador está cargado en el kernel. Los números (16384 y 28672) pueden ser distintos. Es posible que también aparezca xillybus_class en esa lista.
Ten en cuenta que si acabas de instalar este controlador, tendrás que reiniciar el ordenador o cargar el controlador manualmente con insmod.
«Hola, mundo»
El controlador crea cinco archivos de dispositivo: /dev/xillybus_read_8, /dev/xillybus_read_32, /dev/xillybus_write_8, /dev/xillybus_write_32 y /dev/xillybus_mem_8. Ten en cuenta que si creas un núcleo IP personalizado (custom IP core) en la IP Core Factory, puedes elegir cuántos archivos de dispositivo se crean, así como sus nombres y sus propiedades.
Pero, en este momento, la FPGA contiene el paquete de demostración. Probemos con dos de los archivos de dispositivo.
En el paquete de demostración hay un bucle de retorno (loopback) entre read_8 y write_8. Esto significa que, cuando el ordenador escribe datos en write_8, la FPGA devuelve exactamente los mismos datos a través de read_8. Esto está pensado únicamente como demostración; no tiene ningún otro uso práctico.
La prueba es esta: abre dos ventanas de terminal en el ordenador. También puedes utilizar cualquier otra disposición que te dé dos consolas de shell. Por ejemplo, dos conexiones ssh.
Escribe esto en la primera consola:
$ cat /dev/xillybus_read_8
A continuación, escribe esto en la segunda consola:
$ cat > /dev/xillybus_write_8
Ahora escribe cualquier cosa en la segunda terminal y pulsa ENTER. El mismo texto aparecerá en la primera terminal. De este modo se ve cómo el texto se escribió en el primer archivo de dispositivo, llegó después a la FPGA y finalmente volvió al ordenador.
Aunque este ejemplo es sencillo, es importante entender cómo funciona. En particular, conviene entender cómo la lógica de la FPGA hizo posible que esto ocurriera. Ese es el punto de partida para integrar tu propia lógica.
Si estos comandos fallan por un error de permisos (permission denied), repítelos como root. Otra opción es instalar el archivo udev como se sugirió antes.
XillyUSB
Si estás usando XillyUSB, todo lo dicho arriba es aplicable, pero hay algunas diferencias.
XillyUSB incluye una herramienta llamada showdiagnostics para examinar la calidad de la conexión física con la FPGA. Se recomienda encarecidamente utilizar esta herramienta para asegurarse de que el enlace de datos en bruto no tenga errores. Aunque XillyUSB parezca funcionar perfectamente, es importante hacer esta comprobación. La razón es que el protocolo USB 3.0 oculta los errores que se producen en el enlace de datos en bruto, pero esos errores pueden causar problemas poco frecuentes que parecen un bug.
No hay motivo para tolerar errores de este tipo. La solución suele ser sencilla, por ejemplo, usar otro puerto USB del ordenador.
Otras diferencias:
- Usa
lsusben lugar delspci. - Los módulos del controlador son
xillyusby posiblementexillybus_class. - No hace falta reiniciar el ordenador después de instalar el controlador. El controlador se carga automáticamente cuando se conecta el dispositivo a un puerto USB (es decir, cuando se vuelve a conectar después de una desconexión).
- Los nombres de los archivos de dispositivo son un poco diferentes. Por ejemplo, en lugar de
/dev/xillybus_read_8, el nombre es/dev/xillyusb_00_read_8. La parte «00» puede variar.