JuegoNIM G1



= INTEGRANTES =


 * by
 * by
 * by

= DESCRIPCIÓN GENERAL DEL PROYECTO =


 * ¡Gracias por adquirir Drago NIM!. Estas frente a uno de los mejores juegos de destreza mental. Tu objetivo es fácil: quedarte con la última esfera del dragón, y para ello deberás competir contra la máquina. Ella no permitirá que lo logres. En cada turno, tanto la máquina como tú podrán quitar todas las esferas que quieran desde que estén en la misma fila. La máquina es una FPGA (Field Programmable Gate Array) que ha sido programada para vencerte con una lógica implementada en un DataPath. Podrás usar un mouse ps-2 para quitar las esferas mientras que un monitor VGA te muestra las esferas disponibles en cada fila. No todo es negativo para tí: el DataPath no cuenta con más de ocho registros y la unidad aritmético lógica solo realiza operaciones de suma y resta en complemento A2. ¡Tu tienes todo tu intelecto para vencerla!
 * ¿Qué tiene el DataPath? ¿Qué tiene la máquina para derrotarte? Los ocho registros que tiene, junto con su unidad de procesamiento (ALU) son controladas para ejecutar el algoritmo del profesor Charles Bouton (1901). Cada vez que termines tu jugada, la máquina desarrollará pacientemente este algoritmo. Restará, sumará y pasará la información de los registros para conseguir la preciada última esfera. No lo olvides, la máquina ha sido creada para ejecutar el algoritmo, ¡ha sido creada para quedarse con la última esfera!.
 * La estructura de la máquina es simple: Es un DataPath. Su cuerpo es la FPGA SPARTAN-3 Starter Board de Xilinx. Como base, se ha utilizado el proyecto MOUSE_VGA disponible en la página ttde.uniandes.edu.co desarrollado por Digilent inc y modificado por Jorge Mario Garzón. Además, tres estudiantes han puesto todo su ingenio para convertirla en la máquina invencible. ¿Podrás capturar la última esfera del dragón?

Cronograma de actividades
Planteamiento del macro-algoritmo de solución. Cada integrante consultó información sobre el juego y su solución. Cada uno planteó una solución y se discutió para determinar la mejor. Diseño de la arquitectura del DataPath y su implementación en Xilinx ISE 13.1. Se planteó un sencillo módulo de control para verificar que las operaciones de la ALU y la actualizaciones del registro funcionaran correctamente. Daniel Ardila desarrolló las memorias, Andrea Rozo generó la ALU y los multiplexores de los registros a la ALU y Andrés García reunió los módulos y diseñó el pequeño módulo de control. El diseño fue trabajo de todos. El principal problema estuvo asociado a los registros. Inicialmente se plantearon como módulos combinacionales, luego se modificaron a módulos secuenciales. Planteamiento del módulo de control. Se planteó la máquina de estados de acuerdo al macro algoritmo desarrollado. Se implementó el módulo en Xilinx ISE. Todos hicieron parte de este proceso. Implementación de la interfaz gráfica e integración del módulo de control con el DatPath. En esta semana se presentaron la mayor cantidad de problemas. El módulo de control no estaba bien declarado por lo que se modificó su sintaxis totalmente. Se diseño una interfaz muy sencilla para verificar el correcto funcionamiento del sistema. Todos participaron en el proceso.
 * Semana 1: Julio 30 - Agosto 4
 * Semana 2: Agosto 6 - Agosto 11
 * Semana 3: Agosto 13 - Agosto 18
 * Semana 4: Agosto 20 - Agosto 25

Vídeos y/o fotos de demostración del prototipo final
http://www.youtube.com/watch?v=XBynCnt0VlA&feature=youtu.be  XBynCnt0VlA

Diagrama de Caja Negra
El diagrama de caja negra total que se empleó para la solución incluye los módulos controladores del mouse ps2 y del display de 800x600 pixeles, así como el datapath utilizado. En la siguiente imagen se pueden observar las señales de entrada y de salida del sistema completo.


 * Señales de Entrada del sistema (INPUT)
 * clk_50: Señal de reloj del sistema a 50 MHz.
 * rst: Señal de reset del sistema en activo alto..


 * Señales de Salida del sistema (OUTPUT)
 * ps_c: Señal de reloj a la interfaz PS/2 del mouse (INOUT).
 * ps_d: Señal de datos a la interfaz PS/2 del mouse (INOUT).
 * "red:" Salida al canal Rojo de la interfaz VGA del monitor.
 * "grn:" Salida al canal Verde de la interfaz VGA del monitor.
 * "blue" Salida al canal Azul de la interfaz VGA del monitor
 * "Hs:" Señal de sincronización Horizontal con la interfaz VGA del monitor.
 * "Vs:" Señal de sincronización Vertical con la interfaz VGA del monitor


 * El diagrama de caja negra del datapath se puede observar en la siguiente imagen.


 * El DataPath es uno de los bloques fundamentales del sistema, ya que es el que realiza toda la lógica combinacional y secuencial necesaria para implementar el macro-algoritmo diseñado para dar solución al problema planteado. Debido a la complejidad de los módulos internos de este bloque, los mismos se explican con más detalle en la sección 3.1 Arquitectura del Sistema.


 * Señales de Entrada del sistema (INPUT)
 * "Restart:"Señal que reinicia el estado del DataPath.
 * "clk:"Corresponden a la señal de pulsos que es utilizada para el manejo de los sistemas secuenciales.
 * "QE:"Es la señal que índica al módulo de control si el usuario eligió empezar jugando o le cedió el privilegio a la máquina.
 * " clickFila:"Corresponde a una señal de 3 bits que indica en cual de las 5 filas el usuario efectuó un click.
 * Señales de Salida del sistema (OUTPUT)
 * "Fila5...Fila1:"Cada una de estas señales tiene 7 bits y representa cada una de las esferas en la pantalla. El bit k-ésimo de la fila j, está asociado a la esfera jk en la pantalla
 * "EJ:"Es la salida del registro EstadoJuego. Indica si el usuario o la máquina está jugando. Se utiliza cuando el juego culmina.
 * "FJ:"Indica si el juego terminó.

Macroalgoritmo general de solución
Cuando se inicia el juego, el usuario tiene la posibilidad de escoger quien empieza jugando, si él o la máquina.




 * Juega la máquina. En cada juego que la máquina ejecute, se calculará lo que aquí se llama suma NIM entre las filas. Esta corresponde al XOR bit a bit de los registros correspondientes al número de esferas en cada fila. De acuerdo al resultado anterior, la máquina responde:
 * Si la suma NIM es "0000" entonces la máquina no presenta posibilidad de ganar. Como consecuencia, la máquina quitará una esfera de la primera fila que tenga esferas disponibles. Ese será su juego-
 * En caso de que la suma NIM sea distinta a "0000", la máquina ganará el juego. Su algoritmo será calcular el XOR entre cada fila y la suma NIM. Esto le indicará con cuántas esferas debe quedar la fila correspondiente para llevar la suma NIM a "0000" y que el usuario tenga frente a él una jugada perdedora. Si dicho resultado es menor al número de esferas que presenta la fila en ese momento, entonces se modificará dicha fila y su valor final será el XOR calculado. Una vez hecho esto, le dará paso al jugador a menos que se hayan acabado las esferas y la máquina haya ganado.


 * Juega el usuario. El algoritmo en éste caso dependerá de las acciones que éste realice. Al seleccionar una fila, se restará una esfera a dicha fila. Luego de ésto, solo podrá quitarle más esferas a la misma fila y a ninguna otra. Cuando haya quitado las filas que haya creído necesario podrá terminar su turno y darle paso a la máquina, a menos de que se hayan acabado las esferas y él haya ganado. No podrá terminar su turno sin haber quitado por lo menos una esfera.



= DESCRIPCIÓN ESPECIFICA DEL PROYECTO =

Arquitectura del Sistema

 * El sistema consiste de un datapath básico, su sistema de control, un decodificador y un registro adicional llamado EstadoJuego. Como señales de entrada se encuentran las señales declaras atrás (Restart, clk, QE, clickFila) y como salidas están EJ, FJ y la información de las esferas en cada ficha. Entre las señales internas se encuentran:
 * W7...W0: Corresponden a la habilitación de los registros de las memorias para que lean la información a su entrada.
 * Lectura: Determina el dato que leen los registros. Este puede ser el dato de la ALU o los datos de inicialización (aleatorios o no)
 * Reg7... Reg0: Son las salidas de los ocho registros permitidos. Cada una es de 4 bits.
 * ControlMux1, ControlMux2: Son los controles provenientes del módulo de control para determinar que datos provenientes de las memorias entran a la ALU
 * SalidaMux1, SalidaMux2: Equivalen a las salidas de los MUX que van como entradas a la ALU
 * ResultadoALU: Corresponde a la señal de salida de la ALU y es el resultado de la operación sobre las señales de entrada a la ALU
 * Fila5...Fila1: Cada una de estas señales tiene 7 bits y representa cada una de las esferas en la pantalla. El bit k-ésimo de la fila j, está asociado a la esfera jk en la pantalla
 * EscrituraEstadoJuego: Esta señal de salida del control tiene 2 bits. Uno de habilitación de escritura al registro EstadoJuego y otro con la información a escribir
 * EJ: Es la salida del registro EstadoJuego. Indica si el usuario o la máquina está jugando. Se utiliza cuando el juego culmina.
 * FJ: Indica si el juego terminó.



Bloque Control

 * El módulo de control es el encargado de implementar el macro-algoritmo previamente descrito, apoyándose de otros bloques funcionales. A continuación se presenta el diagrama de caja negra del bloque Control:.


 * Para evitar errores de implementación y formalizar la descripción de este módulo, se decidió utilizar la siguiente estructura para el manejo de las entradas, transiciones y salidas de cada estado:




 * Inicialmente, las señales de los bloques periféricos conectados al control, llegan a un bloque combinacional que se le dio el nombre de Transiciones. Este bloque combinacional, tiene en cuenta tanto las señal externas como el estado anterior en el que se encuentra la máquina, para asignar una nueva salida que corresponde a un nuevo estado a la señal SenalEstados. Una vez la señal SenalEstado es actualizada, lo registros almacenan el estado nuevo con el siguiente flanco de reloj, asignando dicho estado a la señal RegistroEstados. Esta salida del bloque Registros es enviada al bloque combinacional Salidas, donde se determinarán los valores de las diferentes salidas del módulo de control. Para separar el control en estos tres módulos, se crearon procesos internos dentro de la implementación del bloque de control. Nótese que a pesar que la señal SenalEstados se actualiza en el instante que la señal RegistroEstados cambia de valor, el bloque Registros, por su carácter secuencial sólo cambiará su salida con el siguiente flanco de subida de la señal clk.

Para una descripción más detallada de la manera en que se diseño el módulo de control se pueden consultar los archivos fuentes de programación.
 * Debido a la forma del macro-algoritmo que se planteo para dar solución al problema, el módulo de control se dividió en 3 sub-máquinas de estados.
 * La primera corresponde al sistema secuencial que le permite al usuario interactuar con el dispositivo y realizar su jugada. Esta máquina de estados implementa el algoritmo descrito en la sección anterior bajo el nombre de “Inicio Juego Usuario”.
 * La segunda máquina de estados corresponde a aquella encargada de efectuar la suma NIM de las diferentes filas, con el fin de utilizar esa información para tomar decisiones sobre que estrategia de juego se debe seguir.
 * Finalmente la última máquina de estados implementa el algoritmo “Juego Máquina”, en el que se decide a partir del resultado de la suma NIM, si es posible encontrar una jugada que permita mantener el estado de ganador del juego o de lo contrario utilizar la estrategia de retirar una sola ficha de alguna fila para de esta manera tratar de prolongar el juego y aumentar la probabilidad de que el usuario se equivoque y realice una jugada no ganadora.


 * Entradas
 * "Restart": Representa una señal que reinicia el estado del módulo de control de forma asíncrona.
 * "clk": Corresponden a la señal de pulsos que es utilizada para el manejo de los sistemas secuenciales.
 * QE: Es la señal que índica al módulo de control si el usuario eligió empezar jugando o le cedió el privilegio a la máquina.
 * "clickFila: Corresponde a una señal de 3 bits que indica en cual de las 5 filas el usuario efectuó un click.
 * HayFicha: Corresponden a una señal de un bit que indica si quedan fichas en el tablero o no.
 * "Neg": Señal de un bit que indica si el resultado de la operación efectuado por la ALU es negativo.
 * "Cero": Señal de un bit que indica si el resultado de la operación efectuado por la ALU es cero.


 * Salidas
 * "W7...W0": Corresponden a la habilitación de los registros de las memorias para que lean la información a su entrada.
 * "EscrituraEstadoJuego": Esta señal de salida del control tiene 2 bits. Uno de habilitación de escritura al registro EstadoJuego y otro con la información a escribir.
 * "Lectura": Determina el dato que leen los registros. Este puede ser el dato de la ALU o los datos de inicialización (aleatorios o no).
 * "Operacion": Determina la operación que debe efectuar la ALU.
 * "Mux1,Mux2": Representan las señales de control de los multiplexores a la salida de los registros que permiten escoger la información de los resgitros con la     que se va a realizar algún tipo de operación en la ALU.

Bloque Memorias

 * Este bloque consta de los ocho registros permitidos de la ALU.


 * Entradas
 * Lectura: Corresponde a la entrada de dos bits proveniente del control. Indica si el registro lee de la ALU o de algún valor preestablecido
 * ResultadoALU Equivale a la señal de 4 bits que proviene de la ALU.
 * W7...W0: Señales que indican a cada registro si se actualizan o no
 * Salida
 * Reg7... Reg0 Corresponden a cada una de las salidas de los registros. Cada una es de 4 bits debido a que las operaciones se realizarán en complemento A2 y se tendrán como máximo 7 esferas por fila.

Bloques MUX
Los bloques MUX no son más que multiplexores que según sea la señal proveniente del control, selecciona alguno de los registros y transmite su información a la salida. Se utilizan dos: uno para cada entrada de la ALU




 * Entradas
 * ControlMux Corresponde a la palabra de control para determinar cual de los registros pasar
 * Reg7... Reg0 Son los ocho registros provenientes del módulo de memorias que van a ser seleccionados
 * Salida
 * SalidaMux Señal seleccionada que sale hacia la ALU

Bloque ALU
Este bloque, responsable de las operaciones entre los datos de los registros es quizás uno de los más sencillos del proyecto. Realiza cuatro operaciones: Suma, Resta, XOR bit a bit y deja pasar el primer registro. Sus entradas son de 4 bits.



Las entradas corresponden a los registros que se operan en la unidad
 * Entradas
 * SalidaMux1 Es la salida del primer multiplexor.
 * SalidaMux2 Salida del segundo multiplexor.
 * "Operacion" Señal que le impone operación que ejecuta la ALU con sus entradas.
 * Salidas
 * "Cero" Bandera que indica si el resultado de la operación es "0000". Es '1' cuando ésto ocurre.
 * "Neg" Indica si el resultado de la operación es negativo. Observe que por trabajar en complemento A2, esta salida equivale al primer bit de la palabra de salida.
 * ResultadoALU Es el resultado de la operación de las entradas de la ALU de acuerdo a la imposición de la señal"Operacion"

El diagrama de bloques de los siguientes módulos se pueden apreciar en el diagrama de bloques general. No hay una consideración en especial que los haga diferir del allí presentado.

Bloque Decodificador
Para mostrar las esferas en la pantalla es necesario convertir las señales de los registros (4 bits) en palabras de 7 bits al que cada uno corresponda una esfera. Esta operación combinacional se realiza en este módulo.


 * Entradas
 * "Reg7... Reg0" Son las salidas de los ocho registros permitidos. Cada una es de 4 bits.
 * Salidas
 * "Fila5...Fila0" Palabras de 7 bits que indican si la esfera correspondiente se muestra en la pantalla o no

Bloque HayFichas
Para conocer si el juego ha terminado o no, se utiliza este módulo. Determina si hay esferas disponibles y en caso de que sea cierto, su única salida es '1'. Basta realizar un OR entre los últimos bits de las señales Fila5...Fila0, puesto que si una fila tiene esferas, necesariamente tiene una en la primera posición.


 * Entradas
 * "Fila5(0)...Fila0(0)": Últimos bits de las señales que actualizan las esferas en la pantalla
 * Salidas
 * "FJ" Indica si quedan esferas en juego.

Bloque EstadoJuego
Así como es necesario conocer cuándo se termina el juego, es preciso conocer quién lo hace. Este es el objetivo de éste módulo que se actualiza con información del control.
 * Entrada
 * EscrituraEstadoJuego: El bit más significativo de ésta señal habilita la escritura del registro. En el menos significativo se encuentra la información a escribir, que es '0' cuando juega la máquina y '1' en caso contrario.
 * Salida
 * EJ: Indica si la máquina está jugando '0' o si el usuario lo hace '1'.

Simulaciones de respaldo y material de apoyo
Simulación del funcionamiento de la ALU En la imagen anterior, en el marcador de los 10 ns, se puede observar que se le indica a la ALU pasar derecho el bus A, que en este caso corresponde a "0000", por lo cual se activa la bandera de cero. A los 30 ns se cambian tanto la instrucción de operación como las entradas correspondientes de cada bus, ahora se le indica a la ALU que realice la suma del bus A más el bus B, así 1 (0001) + 6 (0110) = 7 (0111). En el marcador correspondiente a 40 ns, se le indica a la ALU llevar a cabo la resta entre el bus A y el bus B, para esta simulación es 2 (0010) - 5 (0101) = -3 (1101). La ALU realiza las operaciones y entrega el resultado en complemento A2. En este marador también se puede observar que la bandera de negativo (neg), se ha activado. En 50 ns, se le indica a la ALU que calcule el xor entre el bus A y el bus B, en este caso es 0011 xor 0100 = 0111. En los siguientes marcadores se vuelven a realizar las operaciones de pasar derecho, sumar y restar.
 * Simulación de la ALU: En la siguiente imagen se puede observar el correcto funcionamiento del bloque de la ALU, al realizar cada una de las distintas operaciones que posee con distintas entradas.

Simulación del funcionamiento de las Memorias Como se puede observar en la imagen anterior, a los 35 ns se activa la señal de escritura de todos los registros (W0...W7), pero la señal de Lectura se encuentra en '0'. Por esta razón, los registros se actualizan con la información predeterminada que se encuentra almacenada en las señales temporales (temp0...temp7). Cuando la señal de Lectura cambia a '1' a los 60 ns, se puede observar cómo todas las señales temporales se actualizan con la señal EntradaALU, así, cuando la señal de escritura (W) vuelva a activarse, los registros se actualizarán con el resultado almacenado en las temporales, correspondientes al resultado de la ALU en el sistema completo. Tal caso se presenta a los 75 ns y a los 105 ns.
 * Simulación de las Memorias: La simulación presentada en la siguiente imagen permite observar y comprobar el funcionamiento del bloque Memorias, el cual incluye todos los registros.

Simulación del funcionamiento de las Memorias En la simulación anterior, se inicia con el juego del usuario que se elije al hacer QE = "01". En el control se representa con los estados que comienzan por Z. El usuario termina su jugada haciendo clickFila = "111", con lo cual inicia el juego de la máquina, representado por los estado que comienzan por S. Una vez que el usuario comienza su juego, no puede retirar fichas de filas distintas de la cual con la que inicia su jugada. Esto se puede observar en la simulación en el momento en el que luego de que clickFila = "001" a los 45 ns indicando que se hizo click en las fichas de la Fila 1, el usuario deja de hacer click y la señal ahora es "000". Inmediatamente después hace click en la Fila 5, clickFila = "101" y luego "000", pero los registros no se actualizan y el control espera hasta que realice un movimiento válido, bien sea volviendo a hacer click en la Fila 1 o en finalizar jugada (clickFila = "111").
 * Simulación del Datapath: A continuación se presenta la simulación correspondiente al funcionamiento del Datapath implementado para dar solución al problema planteado. Se puede observar que esta simulación se inició con valores predeterminados para actualizar los registros al empezar el juego.

Al realizar click en finalizar jugada (clickFila = "111"), inicia el juego de la máquina, la cual realiza la suma NIM para comprobar si se encuentra en una situación ganadora o perdedora y así retirar las fichas adecuadas.

= MEMORIAS DE CÁLCULO (VER MATRIZ SEGÚN PROYECTO) =


 * Se introdujo un proceso pseudoaleatorio para la aparición de las esferas en la pantalla. Desde que el usuario presione el botón izquierdo del "mouse" y de click en iniciar hasta que lo suelte, el sistema permanecerá en un ciclo de tres estados, en los que cada uno de ellos actualiza los registros de las filas de forma diferente. La señal Lectura, de dos bits, se utiliza para lograr lo anterior. Cuando es '11' significa leer de la ALU, y las otras tres combinaciones corresponden justamente a tres configuraciones de las esferas en la pantalla. En la imagen siguiente, la señal dentro de los estados es Lectura, mientras que aquella de la transición es clickFila. Esta última es "000" cuando no se presiona el botón izquierdo y es "110" a la vez que Restart='1' (Obs: Se utiliza clickFila en vez de Restart, pues ésta se utiliza como reset asíncrono; utilizarla aquí introduciría error en la sintaxis)



Como los estados cambian de uno a otro a una frecuencia igual a la frecuencia del clk, es decir a un período mucho menor que la respuesta más rápida del ser humano, se puede considerar el proceso como uno aleatorio donde los estados son igualmente probables. De esta manera, al hacer click y soltarlo, la imagen que aparecería en pantalla tiene la misma probabilidad de ser cualquiera de las tres programadas (p = 1/3). Al hacer algunas pruebas con una interfaz básica, se observa que manteniendo el click presionado en Iniciar, se muestran "borrosamente" algunas esferas. Las esferas que se encuentran en todas las combinaciones aparecen coloreadas totalmente. En cambio, las que aparecen en solo dos de las tres combinaciones aparecen borrosas y mucho más difusas se muestran aquellas que aparecen únicamente en una de las tres combinaciones.

= RESULTADOS =


 * Indicadores de uso y rendimiento de dispositivos.
 * Se realizaron varias pruebas para comprobar el funcionamiento del sistema planteado además de las simulaciones.
 * Primera prueba - Funcionamiento del Datapath: Antes de programar el algoritmo planteado como un espacio de estados, se implementó el DataPath y se realizó un pequeño algoritmo cuyo resultado se manifestaba en los colores de seis segmentos de la pantalla. Se verificaron las operaciones de la ALU y la actualización de los registros.
 * Segunda prueba - Ejecución del algoritmo: Para verificar que el algoritmo funcionara correctamente se implementó una interfaz sencilla con forma de cuadrícula. Cada cuadro correspondía a una esfera y se verificaba el estado de las señales internas a través de colores en la pantalla.
 * Tercera prueba - Funcionamiento de la interfaz: Una vez desarrollados el datapath y el algoritmo y habiendo comprobado su correcto funcionamiento, se diseñó la interfaz gráfica. Se realizaron varias pruebas al respecto debido a la complejidad que la interfaz representa a la hora de sintetizar y compilar. Se realizaron varias modificaciones hasta obtener el resultado final.
 * Cuarta prueba - Introducción de un proceso aleatorio. Finalmente, se introdujo la posibilidad de iniciar el juego con tres ordenamientos equiprobables. Pruebas realizadas sobre la base de la sencilla interfaz de la segunda prueba arrojaron resultados satisfactorios. Sin embargo, a la hora de incluir este proceso en el módulo total, el extenso tiempo de síntesis y la dificultad de disponer de la FPGA al final del proyecto imposibilitó el éxito en este intento. A pesar de lo anterior, es de recalcar que el mismo proyecto montado sobre una interfaz más sencilla incluye perfectamente el proceso aleatorio.

Análisis de resultados

 * Como se mencionó anteriormente las especificaciones básicas del proyecto se satisficieron. Desde la implementación y diseño del DataPath hasta el algoritmo que hacía uso de dicha arquitectura funcionaron adecuadamente y de acuerdo a lo esperado. Así mismo, la interfaz funcionó correctamente. El éxito en lo anterior es consecuencia de la organización del trabajo. El cronograma se cumplió y sirvió como referencia, pues sin haber desarrollado correctamente una parte no se empezaba la siguiente. Así, hasta no verificar el comportamiento del datapath, no se inició la programación del algoritmo.
 * Por otro lado, la falencia en el proceso aleatorio fue causada porque no se tuvo en cuenta desde un inicio. Aunque se pensó en el proceso en sí, no se dispuso de un módulo para ello desde el principio. El proceso se agregó a final dentro de los módulos ya existentes generando incluso problemas en los módulos funcionales existentes.

Trabajos futuros

 * Con base en los resultados obtenidos, se propone continuar con una organización semejante para los siguientes trabajos. La planeación del proyecto, así como la verificación de los módulos en cuanto se originan constituye una buena estrategia con miras a obtener un buen resultado. Así mismo, el proyecto actual también da cuenta de la importancia de contar desde el principio con todos los elementos que se quieren involucrar en el diseño, así sean ambiciosos. No es recomendable dejar algo para el final, sino incluirlo desde un principio.

= MATERIALES =

Dispositivos Hardware

 * Tarjeta de desarrollo SPARTAN-3 Starter Board (User Guide) Descargar
 * Mouse con interfaz PS2/2
 * Monitor LCD con resolución 800x600 e interfaz VGA

Herramientas Software

 * Software de síntesis y análisis de diseños en lenguajes de descripción hardware Xilinx ISE 13.1. (Xilinx)
 * MATLAB R2009a (Mathworks)

= CÓDIGO FUENTE =

([[Media:FuncionamientoParcialAleatorio.bit]])
 * Archivos Programación ([[Media:ArchivoProgramacion.bit]])
 * Archivos Fuente (Descargar...)

Publicidad

 * Archivos LOGO LogoProyecto1Grupo2.jpg
 * Archivos POSTER ([[Media:PosterGrupo2.pub]])

= BIBLIOGRAFIA =


 * Nim, A Game with a Complete Mathematical Theory - Charles L. Bouton  (2008) (Descargar...)
 * Introducción al Lenguaje de Descripción Hardware VHDL - Juan Gonzalez (Descargar...)
 * Tutorial Xilinx - Test Benches + ModelSim - Fernando Adolfo Escobar Juzga (Descargar...)