En este momento estás viendo Cómo adaptar códigos VHDL o Verilog y prácticas externas al laboratorio LabsLand FPGA

Cómo adaptar códigos VHDL o Verilog y prácticas externas al laboratorio LabsLand FPGA

El laboratorio LabsLand FPGA permite experimentar con lenguajes de descripción de hardware, como VHDL o Verilog, de forma muy sencilla. Es posible aplicarlo al momento a hardware real, y puede empezarse muy rápidamente, sin necesidad de ningún equipamiento ni instalación más allá de un navegador común de Internet.

Muchas veces, para comenzar, el profesor o el estudiante querrá adaptar prácticas VHDL que ya tiene diseñadas para tarjetas FPGA específicas, o procedentes de fuentes diversas. Esto en general resulta muy sencillo, siempre que los componentes hardware o periféricos involucrados en la práctica original estén soportados por LabsLand, y siempre que se tengan unas pocas cosas en cuenta. En este artículo explicamos cómo hacerlo.

El proceso clásico para aprender VHDL o Verilog

Para aprender lenguajes de descripción de hardware, como VHDL o Verilog, normalmente el estudiante tendrá que comprar o tener acceso a una placa FPGA educativa de algún fabricante. Por ejemplo, las placas Altera DE2-115 de Terasic, Altera DE1-SoC (con FPGAs de Altera), o la Digilent Basys-3 Artix-7 (con FPGA de Xilinx). Después, si quiere ser capaz de utilizarla con su propio ordenador, tendrá que instalar las diversas herramientas del fabricante. En el caso de las placas Altera, por ejemplo, normalmente instalaría versiones de Quartus, mientras que en el caso de Basys-3 por ejemplo, instalaría Vivado de Xilinx. Estas herramientas son muy completas, pero al mismo tiempo muy complejas. En ocasiones requieren licencias, y casi invariablemente tienen notables requsitos de hardware. No es raro que sobrepasen los 15-20 gigabytes de disco, ni que no estén disponibles en ciertos sistemas operativos.

Algunas ventajas del laboratorio LabsLand FPGA

El laboratorio remoto de LabsLand FPGA aporta varias ventajas. La más evidente, por supuesto, es que el alumno no tendrá restricciones de lugar ni de momento. No tendrá ya que acudir a un laboratorio sólo abierto a ciertas horas, ni requerirá a alguien que supervise dicho laboratorio. Podrá practicar con FPGAs reales cuando y dónde quiera. Muchas veces no sustituirá de esta forma al laboratorio presencial tradicional, sino que simplemente lo complementará, usando ambas herramientas para obtener una educación práctica de calidad de forma más efectiva.

Otra de las grandes ventajas es que el proceso de aprendizaje de FPGAs y VHDL o Verilog pasa a ser potencialmente mucho más sencillo. El estudiante no necesita adquirir ya una FPGA, o esperar a que su universidad le preste una. No tiene que esperar a recibirlo. No necesitará instalar un software de fabricante complicado, que muchas veces su ordenador personal no podrá soportar; o para el que no dispondrá de licencias. En vez de eso, podrá diseñar su lógica y probarla en una FPGA real en cuestión de minutos. Utilizando simplemente una plataforma web, sin ninguna instalación, y siendo el hardware remoto, pero absolutamente real.

Utilizando un archivo de restricciones (e.g. QSF) prefijado

Una de las peculiaridades del laboratorio LabsLand FPGA es que en vez de forzar al estudiante a definir un archivo de restricciones (tal como los QSF de Altera), utiliza un archivo de restricciones prefijado. El laboratorio LabsLand FPGA cuenta con diversos periféricos de entrada / salida, y no está pensado para que el hardware en sí se modifique. Por eso, este enfoque tiene sentido. Esto implica, sin embargo, que el estudiante deberá tener en cuenta en sus diseños qué hardware está disponible y cómo se llaman y declaran en el archivo de restricciones las diferentes señales.

En las diversas configuraciones del laboratorio, el archivo de restricciones a utilizar está siempre disponible en el apartado de Documentación, en la esquina inferior izquierda, accesible desde el propio IDE. Lo mostramos en la imagen siguiente.

Este archivo de restricciones, al igual que siempre, define las correspondencias entre las señales (y sus nombres) con los pines físicos de la placa FPGA. Aquí se definen, por ejemplo, qué nombres reciben los LEDs o los interruptores, y a qué pines físicos están conectados.

La mayor parte de placas FPGA educativas, como la Altera DE2-115 o la DE1-SoC o la Basys 3, por ejemplo, disponen de LEDs. Típicamente, un nombre con el que en nuestro archivo de restricciones se declaran las señales correspondientes a los LEDs, por ejemplo, será el vector G_LED de tipo std_logic_vector. La «G» proviene de «genérico», ya que tendemos a utilizar el mismo nombre para diversas placas diferentes que incluyan LED, por uniformidad.

Otro ejemplo son los interruptores, que normalmente serán V_SW de tipo std_logic_vector. En este caso la V proviene de «virtual», para enfatizar el hecho de que no se trata normalmente de los interruptores físicos de los que varias placas disponen, sino de una abstracción: interruptores virtuales controlables mediante la interfaz web, pero que se reciben por las entradas GPIO reales de la placa como si fueran interruptores normales.

Adaptando las prácticas y códigos pre-existentes

Los códigos VHDL o Verilog que puedan encontrarse en diferentes sitios, tales como en los diferentes manuales de los fabricantes, o en repositorios de código abierto, tendrán normalmente una entidad principal que utilizará un nombres no particularmente estándar. Por ejemplo, una práctica sobre una Máquina de Estados Finitos probablemente tenga como entrada un reloj y un interruptor de reset, y quien desarrolle el código original probablemente haya declarado esas entradas con cualquier tipo de nombre. Por ejemplo, «clk» para el reloj, o «rst» para el reset. Pero lo mismo puede haber utilizado «clk50mhz», o «reset». Si se tratase de una práctica presencial tradicional con el software estándar de los fabricantes, se esperaría que la persona que quisiese probar este código crease un archivo de restricciones adecuado a estas entradas y con estos nombres para que el código funcionase.

En el caso de LabsLand el archivo de restricciones es fijo. Tiene la ventaja de que por tanto, no será necesario crearlo. Tiene la desventaja de que los nombres tendrán que corresponderse. Por tanto, para que el código externo funcione, se deberán cambiar los nombres, o los tipos en su caso, de las señales de la entidad principal para que se correspondan con las de LabsLand. Esto no suele resultar complicado, ya que sólo es necesario para la entidad principal, y suele ser sencillo incluso utilizando el «buscar y remplazar» automático utilizando CTRL+F en el editor web online. Normalmente, el tiempo que lleva adaptar el código es menor al tiempo que llevaría crear un archivo de restricciones adecuado. Pero sí que es necesario tener cierto cuidado.

En la imagen siguiente se muestra como ejemplo el diagrama de una de las FPGA genéricas disponibles en LabsLand, y los nombres de las entradas y salidas que están definidas en el archivo de restricciones más frecuente. El archivo completo y específico está también disponible en cada laboratorio.

Diagrama de la FPGA genérica tipo LL_STD_1

Ejemplo con máquina de estados finitos

Vamos a ilustrar esto con un ejemplo relativo a una máquina de estados finitos. Imaginemos que hemos encontrado en un manual cualquiera de un fabricante un ejemplo interesante de FSM, y que queremos probarlo en la placa Altera DE-1 utilizando LabsLand FPGA.

Observamos, por ejemplo, que en la entidad principal del código inicial existen las siguientes señales de entrada:

  • clk (std_logic)
  • reset (std_logic)
  • start (std_logic)

Como hemos mencionado, normalmente tendríamos que crear un archivo de restricciones QSF que se correspondiese. En el caso de LabsLand FPGA el archivo de restricciones es fijo, por lo que simplemente tendremos que adaptar los nombres de las señales, y en ocasiones su tipo.

Para ello en este caso, cambiaremos los nombres y señales por las siguientes:

  • Cambiaremos el nombre de la señal de «clk» por «G_CLOCK_50». En reloj en el laboratorio Altera DE-1 de LabsLand (y en la mayoría de laboratorios semejantes) se llama así; y está conectado a un reloj de 50 MHz.
  • Para las señales de reset y de start queremos utilizar el primer y segundo interruptor de la placa, respectivamente. Así que cambiaremos esas señales por V_SW, que se corresponde con las entradas de LabsLand FPGA. Es un std_logic_vector, con lo que en vez de utilizar «reset», sustituiremos por «V_SW(0)», y en vez de «start», utilizaremos «V_SW(1)». De este modo, cuando probemos el código, sólo tendremos que utilizar el interruptor primero y segundo de la interfaz para que funcione todo de la forma esperada.

Conclusiones

Como puede verse, es relativamente sencillo adaptar cualquier código VHDL o Verilog, siempre, claro, que el hardware soportado por los laboratorios sea el suficiente. Basta con adaptar las señales de la entidad principal a las señales predefinidas. En cualquier caso, si estás leyendo estas instrucciones y tuvieses cualquier duda o dificultad adaptando tu código o tus prácticas, ¡no dudes en contactar con nosotros!

Luis

Luis Rodríguez Gil es CTO de LabsLand y uno de sus cofundadores. Lleva más de 8 años en el ámbito de la investigación en laboratorios remotos. Ahora trabaja, desde LabsLand, para conseguir que esta tecnología tan novedosa alcance todo su potencial para la educación.