XULA-200

=Que es la tarjeta Xula 200=

El tarjeta Xula es una plataforma de bajo costo que permite a estudiantes interesados en el desarrollo de aplicaciones sobre lógica programable diseñar y probar de manera rápida sus aplicaciones.

La Xula es producida por Xess como una tarjeta una tarjeta muy flexible, cuyas fuentes tanto del hardware como del software son de código abierto para que los usuarios puedan modificarlos y generar aplicaciones a la medida de sus necesidades.

La tarjeta cuenta con una FPGA Xilinx Spartan-3A, 64MB de memoria RAM para aplicaciones, una memoria SPI-Flash donde se guardan los binarios de auto-programación y un microcontrolador que actúa como puente para la programación de la FPGA y la depuración de las aplicaciones.

= Especificaciones=

Diagrama de Bloques
A continuación encontrará el diagrama de bloques de la Xula-200:

FPGA
El chip FPGA de la XuLa es un Xilinx Spartan-3A de 200K compuertas en un empaque VQFP-100. Hay 68 pines libres para ser usados como puertos de entrada y o salida.

Microcontrolador
La XuLa usa un microcontrolador PIC 18F14K50 de microchip para realizar las siguientes funciones:
 * Inicialización y Reset: Al prender la tarjeta, el microcontrolador inicia la configuración de la FPGA desde la memoria Flash, si este procedimiento falla la FPGA se mantiene en un estado inicial limpio. Además en este punto el micro identifica a la tarjeta como periférico USB.
 * Generación del Reloj: Es el encargado de generar el reloj global de la FPGA de 12MHz a través de modulación PWM. Para muchas aplicaciones este reloj es suficiente, sin embargo para las que requieren relojes más rápidos, se puede multiplicar este reloj hasta unos 200MHz (por consideraciones de potencia si se usa el puerto USB como alimentación) haciendo uso de los bloques DCM(Digital Clock Manager) presentes en la FPGA.
 * Comunicación USB-Jtag: El microcontrolador actúa como puente entre la interfaz USB y el puerto Jtag de la FPGA para realizar su configuración con un bitstream o bien como puerto de depuración.

Memoria SDRAM
La XuLa cuenta con una memoria SDRAM Winbond W9812G6JH de 4 bancos de 2M de palabras de 16bits, es decir 128Mbit o 16MB de información, sin embargo por cuestiones de disponibilidad de pines de la FPGA el fabricante hizo las siguientes configuraciones a tener en cuenta:


 * El pin de selección de chip (CS#) está siempre en bajo, por lo que la SDRAM siempre estará activa.
 * El pin habilitador del reloj de la memoria (CKE) siempre está en alto por lo que la memoria requiere un reloj constante para que se mantenga el refresco de los datos.
 * Los habilitadores de byte alto y bajo (DQMH y DQML) están en bajo por lo que siempre se debe acceder a los datos como palabras de 16bits.
 * Un solo pin de la FPGA controla ambos pines de selección de banco (BS0 y BS1) por lo que solo se puede acceder a 2 bancos, lo que reduce la memoria disponible a la mitad, es decir 64Mbit o 8MB.
 * El reloj hacia la memoria (SDRAM-CLK) se realimenta a una entrada global de reloj para que la FPGA se pueda sincronizar con la SDRAM, compensando posibles retrasos.

Memoria Flash
La XuLa cuenta con una memoria Flash SPI Winbond W25X20BV de 2Mbit de capacidad que se usa en la programación automática de la tarjeta. Dado que la SDRAM siempre está activa y comparte con la flash algunas líneas, como se ve en la figura anterior, las dos no pueden estar activas al mismo tiempo, además en el encendido se realizan los siguiente eventos:


 * El microcontrolador pone la señal FLASH-DISABLE en alta impedancia y activa la señal #PROG de la FPGA con lo que se inicia el proceso de configuración de la FPGA desde la Flash.
 * La FPGA pone en bajo CSO_B con lo que activa la Flash y usa CCLK, MOSI y MISO (Interfaz SPI) para leer el bitstream que se aloja en la Flash. Dado que SDRAM-CLK esta inactivo, la SDRAM está igualmente inactiva y no importa que estén cambiando sus señales de control y dirección.
 * Una vez se usa el bitstream que aloja la Flash, la FPGA lo indica al microcontrolador con la señal DONE, con lo cual el microcontrolador pone en alto FLASH-DISABLE desactivando la Flash. En este punto la FPGA ya no puede acceder a la Flash, pero si a la SDRAM sin problemas.

Es posible dejar activa la Flash enviando una configuración especial al microcontrolador, sin embargo la SDRAM no se puede usar ya que los cambios en la dirección y el control que se producen al comunicarse con la Flash hacen que los datos que se hallan guardado se corrompan.

Descripción de los pines
Como se menciono la FPGA en XuLa no puede manejar directamente tensiones de entrada más altas que 3.3V. Sin embargo si su diseño requiere entradas por ejemplo de 5V se puede usar un esquema como el siguiente:
 * Tolerancia al niveles más altos que 3.3V



Como se ve en la figura se debe activar el diodo de protección a la entrada de la FPGA y poner una resistencia en serie con la entrada de 5V; esto hará que si la tension en la entrada de la FPGA supera los (3.3+0.7)V=4V el diodo conduce y la resistencia el exceso de tensión cae sobre la resistencia por lo que nunca se superarán 4V a la entrada de la FPGA. La resistencia se debe calcular para que no se exceda una corriente máxima de 10mA sobre el diodo de protección.

Los diodos de protección está desactivados por defecto al generar bitstreams, para activarlos debe incluir el tipo de entrada en el archivo de configuración de pines (.ucf ) como en el siguiente ejemplo:

NET "" LOC = <# identificación del pin en la FPGA> | IOSTANDARD = PCI66_3;

USB
La fuente por defecto de la Xula es el puerto USB, que a su vez permite la comunicación. Puede proveer hasta 500mA de corriente, lo cual es suficiente para diseños medianos que corran con relojes de menos de 200MHz. Cuando la Xula se encuentra conectada por el puerto USB, puede usar los pines 5V, 3.3V y 1.2V como fuentes para otros componentes de su sistema, por ejemplo si requiere de botones como entradas del sistema, es recomendable usar la fuente de 3.3V. NO CONECTE FUENTES DE PODER A LOS PINES 5V, 3.3V o 1.2V CUANDO ESTÉ CONECTADO EL PUERTO USB.

Pines Especiales de Alimentación

 * Para proyectos que requieren una alimentación de mas de 500mA de corriente se puede conectar al pin de 5V una fuente externa de entre 5 y 18V, en este caso NO CONECTE EL PUERTO USB ya que entraría en corto con la fuente. Si es necesaria la conexión tanto de la fuente externa como del puerto USB se debe eliminar un camino en la PCB que conecta la alimentación del USB con el regulador de 5V tal como se muestra en la figura a continuación.



=Recursos =

Repositorios y Documentación

 * Para acceder a las herramientas y ejemplos de la XuLa puede usar el repositorio ttde-xula-board. Para clonar el repositorio en su computador corra el siguiente script en el terminal (deberá tener instalado git en Linux):

git clone git clone git://git.code.sf.net/p/ttde-xula-board/code ttde-xula-board-code


 * (OPCIONAL) Si desea modificar la tarjeta y crear su propio PCB o modificar el firmware del microcontrolador para extender la funcionalidad del mismo, puede clonar el repositorio que Xess ha destinado para la XuLa:

git clone https://github.com/xesscorp/XuLA.git


 * Documentos distribuidos por Xess:
 * XuLa Manual
 * XuLa - FPGAs? Now What?


 * Datasheets:
 * Xilinx Spartan-3A
 * SDRAM - Winbond W9812G6JH
 * SPI Flash - Winbond W25X20BV

Síntesis de Hardware en FPGA
Siga las instrucciones en FPGA Toolchain para instalar y configurar Xilinx en su equipo, puede ignorar la sección "Configuración de BOARDs EN UBUNTU 12.04" para la XuLa.

Programación de Archivos
Para poder programar la tarjeta debe primero instalar los siguientes paquetes desde un terminal:

sudo apt-get install python2.7 python-dev python-usb libusb-dev gcc

Ahora clone el repositorio de ttde-xula-board tal como se explica en la sección anterior y copie las herramientas en "/tools/XTOOLS" a la carpeta "/opt" para ello ejecute el siguiente script:

sudo cp -r /tools/XTOOLS /opt/XTOOLS sudo chmod 777 -R /opt/XTOOLS

Y tal como se realizó en FPGA Toolchain debe agregar la ruta de estas herramientas al PATH del sistema en el archivo ".bashrc", para ello debe editar de nuevo el archivo ".bashrc" modificando la línea del PATH, además vamos crear la variable "XILINX", el final del archivo ".bashrc" debe quedar similar a:

export PATH=$PATH:/opt/Xilinx/12.4/ISE_DS/ISE/bin/lin/:/opt/XTOOLS export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/Xilinx/12.4/ISE_DS/ISE/bin/lin export XILINX=/opt/Xilinx/12.4/ISE_DS/ISE

Debe ejecutar la siguiente linea en el terminal para hacer efectivo el cambio en el ".bashrc":

source ~/.bashrc

=Ejemplos de Desarrollo=

Blinking Led
En este espacio se realizará un ejemplo sencillo de síntesis, simulación y programación de la FPGA. En ejemplo se realizará un sencillo blinking led que puede encontrar en la carpeta projects/Blinking_led_200k_Xula del repositorio.

El proyecto está compuesto por los siguientes archivos:

El archivo Blinker.v contiene la descripcion del hardware el cual se sintetizara. Aca podra programar y realizar todo el codigo que necesite

El archivo Blinker_TB.v configura y da los parametros de simulacion.

El archivo Makefile es un script que ayuda a automatizar los procesos que generan los archivos de síntesis, de simulación y de programación.

El Archivo Blinker.ucf define las conexiones entre los las señales definidas en los archivos de descripción de hardware (Verilog/VHDL) y los pines físicos de la FPGA. además de las posibles opciones especiales de configuración de los mismos.

Makefile
El Makefile como se mencionó tiene la tarea de automatizar los procesos que generan los archivos de síntesis, programación y simulación del proyecto. Este será el primer archivo que vamos a editar al crear un nuevo módulo y en el debemos establecer el nombre del diseño y los archivos a incluir en el diseño.


 * En la variable DESIGN debe poner el nombre deseado de su modulo principal, este sera la base del nombre de los demás archivos del proyecto, en este caso Blinker.
 * Las variables SRC y SIM_SRC contienen los archivos de descripción de hardware y simulación respectivamente, observe que se emplea el macro $(DESIGN), esto simplemente significa que los archivos deben tener el nombre definido en DESIGN. En esta variable si es necesario se agregan los demás archivos del diseño, en este caso por la simpleza del ejemplo no es necesario, aunque se verá en una ejemplo posterior.
 * No debe incluir más comandos debato de la linea include ../Makefile, de lo contrario puede que el Makefile general de los proyectos que se encuentra en la carpeta projects puede no funcionar.

El Makefile, como archivo constructor, nos permite realizar las siguientes tareas: (Para realizarlas debe abrir una terminal en la carpeta donde tiene guardado el proyecto)


 * make clean  ; Limpia el proyecto de los objetos y archivos temporales
 * make syn    ; Realiza la síntesis del proyecto
 * make sim    ; Genera el archivo de simulation
 * make view   ; Abre el visualizador de ondas con la simulación
 * make install ; Realiza la programación directa de la FPGA del dispositivo
 * make flash ; Realiza la programación de la Flash del dispositivo

Blinker.v
Este archivo contiene el módulo principal del proyecto Blinker, en el caso de este ejemplo simplemente implementa un contador de 23 bits del cual el bit 23 alimenta una salida que hace parpadear un led aproximadamente cada 0.7s.

Blinker_TB.v
Este archivo contiene el archivo de simulación del módulo. Como se observa en el siguiente código el TestBench crea un modulo especial que instancia al modulo principal del proyecto. Se define el reloj de la simulación con los parámetros tck y cll_freq que en este caso es de aproximadamente 12MHz; en el bloque "initial begin" observe las lineas 54 y 55, en estas se define el archivo en el que se guardarán los datos de la simulación y las variables que queremos mostrar por defecto, en la línea 56 se define el tiempo deseado de simulación.

Blinker.ucf
En este archivo se definen las conexiones de las señales del diseño con los pines físicos de la FPGA y la configuración para activar los diodos de protección de la FPGA:

Síntesis
Cuando los archivos de desarrollo están listo puede proceder a la síntesis del proyecto, para ello en la carpeta del proyecto desde un terminal ejecute el comando:

make syn

Verá el proceso de sintonización y si todo sale bien no habrán errores y habrán aparecido tres nuevas carpetas dentro de la carpetas del proyecto:


 * build: Contiene archivos internos de la sintetización, en general el usuario no los modifica o usa directamente a excepción del archivo  que puede usar desde el software ISE para visualizar el RTL del sistema.
 * output: Contiene los bitstream de salida, uno que se usa en la programación directa y el otro en la programación de la Flash, en este caso Blinker.bit y Blinker_FLASH.bit respectivamente. Además se encuentra el archivo de texto Blinker.log que resume los resultados de la sintetización.
 * syn_install_scripts: Reúne algunos archivos de simulación y sintonización, usualmente no se modifican directamente.

Simulación
Para realizar la simulación se usa el software icarus junto con GTKWave, ejecute el siguiente comando en la terminal:

make sim view

Debe aparecer la ventana de GTKWave donde puede elegir las señales que quiere observar como se ve en la imagen:

Programación
La primera opción de programación de la tarjeta es directamente la FPGA lo cual se realiza con el comando:

make install

Esto programa la tarjeta de manera rápida, sin embargo si esta se reincida hay que reprogramar manualmente. Para que el programa quede en la flash se usa el comando:

make flash

En este caso el programa se carga automáticamente cuando reinicia la tarjeta, sin embargo la desventaja es que la programación de la flash toma bastante tiempo, alrededor de 4 o 5 minutos, o mas dependiendo de la complejidad del diseño.

Nota1: Este último comando le pedira la clave de super-usuario.

Nota2: Si usa maquina virtual para correr linux es posible que la programación no funcione, especialmente la directa a la FPGA. Si le ocurre pruebe con otro software de maquinas virtuales o use las herramientas de Windows que provee Xess.

VGA Colors
En este espacio se realizará un ejemplo sencillo de síntesis, simulación y programación de la FPGA. En ejemplo se realizará una sencilla aplicación que controla un display VGA mostrando colores que cambian al oprimir un pulsador, este proyecto lo puede encontrar en la carpeta projects/VGA_Colors del repositorio.

El proyecto está compuesto por los siguientes archivos:


 * El archivo VGA_Colors.v contiene la descripcion del hardware el cual se sintetizará. En este archivo podrá programar y realizar todo el código que necesite.


 * El archivo rtl/pixel_gen.v que es el circuito encargado de general los pixeles a enviar al monitor VGA es otro de los archivos importantes.


 * Los bloques genéricos vga_driver que provee el circuito de sincronización de las señales del monitor VGA, debounce.v que aplica un algoritmo anti-rebote a la entrada del pulsador y DCM_CLK_FX.v que permite generar frecuencias especiales del reloj de la Xula.


 * El archivo VGA_Colors_TB.v configura y da los parámetros de simulación.


 * El archivo Makefile es un script que ayuda a automatizar los procesos que generan los archivos de síntesis, de simulación y de programación.


 * El Archivo VGA_Colors.ucf define las conexiones entre los las señales definidas en los archivos de descripción de hardware (Verilog/VHDL) y los pines físicos de la FPGA. además de las posibles opciones especiales de configuración de los mismos.

Funcionamiento
La siguiente figura muestra el diagrama de bloques de este sistema, cuya finalidad es producir una salida que alimenta un display VGA y al oprimir un botón se cambia el color que se ve en la pantalla.



En el archivo VGA_Colors.v puede encontrar la descripción de hardware que implementa este diagrama de bloques; en el se instancias los diferentes módulos que componen el diseño.

Modulo DCM_CLK_FX
Este modulo utiliza un componente hardware especial presente en las FPGAs de Xilinx llamado Digital Clock Manager o DCM que emplea PLLs para sintetizar frecuencias especiales a partir de una frecuencia base (también tiene otros usos muy importantes como la sincronización de relojes entre sistemas). En este ejemplo el reloj de la Xula es de 12MHz pero no es suficientemente rápido para los requerimientos de tiempo de las señales de sincronización del modulo vga_sync, que requiere de un reloj de 50MHz, por lo que empleamos el DCM para obtener 50MHz multiplicando la señal de 12MHz por 25 y diviéndola entre 6. Este módulo es paramétrico, de tal forma que el diseñador pueda fijar la frecuencia sintetizada a la que requiera su diseño. En el código siguiente se muestra como se instanció (en VGA_Colors.v) para producir los 50MHz que requerimos en el diseño:

El código dentro del archivo DCM_CLK_FX.v contiene los macros que emplea el sintetizador de Xilinx para usar el hardware especializado del DCM, este archivo de genera con ayuda de la herramienta Core Generator de ISE. Puede usar simplemente un instanciamiento similar al visto anteriormente para usar el módulo, sin embargo si requiere de otras funciones del DCM o opciones especiales deberá remitirse al Core Generator y la documentación del DCM.

Módulo Debounce
Este modulo se encarga de hacer anti-rebote al pulsador encargado de cambiar los colores en pantalla. Implementa una maquina de estados que cuenta el tiempo en que la señal del botón es fija sin tener en cuenta los rebotes, decidiendo cuando efectivamente el botón ha sido oprimido. Puede implementación del módulo en el repositorio y remitirse al libro FPGA Prototyping by Verilog Examples - Pong P. Chu en el cual está basado.

Modulo vga_sync
Este modulo genera las señales de sincronización necesarias para el funcionamiento de la pantalla VGA, esta es su única función, no genera los pixeles que se van a desplegar en pantalla. Las pantallas VGA se ajustan a un estándar que define como se debe realizar la sincronización, ésta se encuentra ilustrado en la siguiente imagen:



Por cada línea horizontal del display, este espera un pulso se sincronismo horizontal y por cada 601 pulsos horizontales, es decir, por cada 601 lineas se espera un pulso vertical que hace que volvamos al principio de la pantalla para desplegar una nueva imagen. Hay espacios en blanco que el display escanea pero que no reciben datos de píxeles, se les suele llamar Front Portch, y Back Portch que deben ser tenidos en cuenta para la sincronización.



Las salidas del modulo son la sincronización horizontal y vertical, h_sync y v_sync respectivamente, video_on que indica cuando entramos al área que se va a mostrar del display y, pixel_x y pixel_y que indican el pixel en el que nos encontramos actualmente.

Para conectar la tarjeta al display debe usar un conector DB15, como el que se muestra en la imagen:



Debe conectar las salidas de la FPGA como se muestra en la siguiente imagen:



Las resistencias que se conectan a las lineas de rojo, verde y azul definen que tan brillante es el color, entre más bajas mas intenso es, esto es debido a que el display usa ADCs para obtener el valor analógico de la señal y proyecta la intensidad del valor.

Módulo pixel_gen
Este módulo es el directamente encargado de generar los pixeles que se van a enviar a la pantalla, en este ejemplo sencillo solo se envía uno de 8 colores que corresponden a las distintas combinaciones de 1 bit para cada color, rojo, verde o azul. Cuando se presiona el botón el modulo incrementa un contador que cambia el valor del color de salida y cuando la señal video_on proveniente del modulo de sincronismo vga esta activa, pone el valor de cada pixel en la salida, esto es necesario para evitar enviar pixeles en las áreas inactivas de la pantalla.

A continuación se muestra la implementación en el archivo pixel_gen.v:

Definición de Pines
La definición de pines se realiza de en el archivo VGA_Colors.ucf tal como se muestra a continuación:

Para la conexión del circuito puede guiarse del siguiente esquemático:



Es importante que las entradas de los botones no superen los 4V, puede usar la fuente de 3.3V que provee la Xula en el pin 3.3V.

Makefile
El Makefile como se mencionó tiene la tarea de automatizar los procesos que generan los archivos de síntesis, programación y simulación del proyecto. Este será el primer archivo que vamos a editar al crear un nuevo módulo y en el debemos establecer el nombre del diseño y los archivos a incluir en el diseño.


 * En la variable DESIGN debe poner el nombre deseado de su modulo principal, este sera la base del nombre de los demás archivos del proyecto, en este caso VGA_Colors.
 * Las variables SRC y SIM_SRC contienen los archivos de descripción de hardware y simulación respectivamente, observe que se emplea el macro $(DESIGN), esto simplemente significa que los archivos deben tener el nombre definido en DESIGN. En esta variable si es necesario se agregan los demás archivos del diseño, en este caso por la simpleza del ejemplo no es necesario, aunque se verá en una ejemplo posterior. Observe como en este diseño se utilizan bloques genéricos de la carpeta rtl_generic y módulos auxiliares en la carpeta rtl que se encuentra dentro de la carpeta del proyecto.
 * No debe incluir más comandos debajo de la línea include ../Makefile, de lo contrario puede que el Makefile general de los proyectos que se encuentra en la carpeta projects no funcione.

El Makefile, como archivo constructor, nos permite realizar las siguientes tareas: (Para realizarlas debe abrir una terminal en la carpeta donde tiene guardado el proyecto)


 * make clean  ; Limpia el proyecto de los objetos y archivos temporales
 * make syn    ; Realiza la síntesis del proyecto
 * make sim    ; Genera el archivo de simulation
 * make view   ; Abre el visualizador de ondas con la simulación
 * make install ; Realiza la programación directa de la FPGA del dispositivo
 * make flash ; Realiza la programación de la Flash del dispositivo

Síntesis
Cuando los archivos de desarrollo están listos puede proceder a la síntesis del proyecto, para ello en la carpeta del proyecto desde un terminal ejecute el comando:

make syn

Verá el proceso de sintetización y si todo sale bien no habrán errores y habrán aparecido tres nuevas carpetas dentro de la carpetas del proyecto:


 * build: Contiene archivos internos de la sintetización, en general el usuario no los modifica o usa directamente a excepción del archivo  que puede usar desde el software ISE para visualizar el RTL del sistema.
 * output: Contiene los bitstream de salida, uno que se usa en la programación directa y el otro en la programación de la Flash, en este caso VGA_Colors.bit y VGA_Colors_FLASH.bit respectivamente. Además se encuentra el archivo de texto VGA_Colors.log que resume los resultados de la sintetización.
 * syn_install_scripts: Reúne algunos archivos de simulación y sintonización, usualmente no se modifican directamente.

Al observar los datos del archivo VGA_Colors.log podrá observar los resultados de la síntesis, particularmente interesantes son los datos de utilización de recursos de la FPGA que muestran que tan eficiente es su diseño y cuantos recursos tiene disponibles para agregar más funcionalidad:

Simulación
Se simula el circuito del proyecto con el archivo VGA_Colors_TB.v, para ello como podrá observar en el código más adelante, se crean inicialmente el reloj de 12MHz del sistema que corresponde al generado por el microcontrolador en la Xula, de instancia el la unidad a probar (UUT - unir under test en inglés) que corresponde al modulo principal del diseño, en este caso el modulo VGA_Colors, posteriormente se crean las señales de estimulo que en este caso corresponden a:


 * Señal de reset que se activa por 10ns y se desactiva de nuevo de tal forma que el sistema entre a un estado conocido.
 * Señal del botón de cambio de color button_in, se se va a hacer variar varias veces en el lapso de 10ms y posteriormente permanece activa por 40ms simulando el comportamiento de un botón que debe ser filtrado por el modulo debounce produciendo una señal limpia a partir del botón con rebote.

El siguiente código corresponde a la implementación de la simulación anteriormente mencionada:

Observe que para que las señales simuladas sean visibles en el archivo de simulación, deben estar después de las lineas 69, donde se empiezan a guardar los datos del archivo.

La simulación se ejecuta desde consola tal como se mencionó en el proyecto Blinker.

El primer resultado de simulación es la verificación que el reloj simulado de 12MHz que se resalta entre los marcadores A y B, y el generado por el DCM, que se resalta entre los marcadores A y C siendo alrededor de 4.1 veces más rápido que el reloj de 12MHz, son correctos como se muestra en la imagen a continuación:



A continuación se observa el resultado del anti-rebote del botón de cambio de color. En la imagen siguiente se observa que después de 20ms de estar activa la señal button_in se activa la señal sin rebote button_debounced y esta a su vez genera el cambio de color, en este caso de 7 a 0, que corresponde al registro de 3 bits que contiene los valores RGB, es decir estamos pasando de 0b111 a 0b000 o también de blanco a negro.



Finalmente se comprueba el funcionamiento de la sincronización de las señales que se generan para el sincronismo del VGA: h_sync, v_sync y video_on. Observe que en los marcadores A y B se producen pulsos de sincronismo vertical, entre estos se encuentran los pulsos de sincronismo horizontal por cada línea y además se puede observar que la señal video_on efectivamente marca los espacios donde hay pixeles activos:



Programación
La primera opción de programación de la tarjeta es directamente la FPGA lo cual se realiza con el comando:

make install

Esto programa la tarjeta de manera rápida, sin embargo si esta se reincida hay que reprogramar manualmente. Para que el programa quede en la flash se usa el comando:

make flash

En este caso el programa se carga automáticamente cuando reinicia la tarjeta, sin embargo la desventaja es que la programación de la flash toma bastante tiempo, alrededor de 4 o 5 minutos, o mas dependiendo de la complejidad del diseño.

Nota1: Este último comando le pedira la clave de super-usuario.

Nota2: Si usa maquina virtual para correr linux es posible que la programación no funcione, especialmente la directa a la FPGA. Si le ocurre pruebe con otro software de maquinas virtuales o use las herramientas de Windows que provee Xess.