EUITI - MADRID DEPARTAMENTO ELAI · Diseño de la máquina de estados finitos ... En este...

EUITI - MADRID DEPARTAMENTO ELAI

Prácticas de Microelectrónica

Luis Castedo


Índice

PRÁCTICA Nº 1: .................................................................................................................................................. 1

INTRODUCCIÓN AL ENTORNO ISE DE XILINX........................................................................................ 1

INTRODUCCIÓN ................................................................................................................................................... 1 EL ENTORNO DE DESARROLLO............................................................................................................................. 2

Project navigator........................................................................................................................................... 3 Creación de un nuevo proyecto ..................................................................................................................... 5 Uso el editor de esquemáticos ....................................................................................................................... 8 Verificación de la sintaxis y simulación ...................................................................................................... 10

PRÁCTICA Nº 2: ................................................................................................................................................ 13

DECODIFICADOR BCD A 7 SEGMENTOS.................................................................................................. 13

OBJETIVOS DE LA PRÁCTICA.............................................................................................................................. 13 INTRODUCCIÓN ................................................................................................................................................. 13

La tarjeta Spartan-3 Starter kit ................................................................................................................... 13 El bus JTAG................................................................................................................................................. 15 Control del proceso de síntesis.................................................................................................................... 16 Programas de prueba .................................................................................................................................. 17 La entidad de nivel superior ........................................................................................................................ 17

REALIZACIÓN DE LA PRÁCTICA ......................................................................................................................... 18 El decodificador .......................................................................................................................................... 18 Tarea 1......................................................................................................................................................... 21 Tarea 2......................................................................................................................................................... 22

PRÁCTICA Nº 3: ................................................................................................................................................ 25

DISEÑO DE UNA UNIDAD LÓGICO ARITMÉTICA.................................................................................. 25

OBJETIVOS DE LA PRÁCTICA.................................................................................................................... 25 INTRODUCCIÓN ................................................................................................................................................. 25 REALIZACIÓN DE LA PRÁCTICA ......................................................................................................................... 27 EJERCICIOS........................................................................................................................................................ 29

Tarea 1......................................................................................................................................................... 29 Tarea 2......................................................................................................................................................... 29

PRÁCTICA Nº 4: ................................................................................................................................................ 31

DISEÑO DE UNA UNIDAD LÓGICO ARITMÉTICA (Y II) ....................................................................... 31

OBJETIVOS DE LA PRÁCTICA.................................................................................................................... 31 INTRODUCCIÓN ................................................................................................................................................. 31

Diseño de la máquina de estados finitos...................................................................................................... 34 REALIZACIÓN DE LA PRÁCTICA ......................................................................................................................... 36

Tarea 1......................................................................................................................................................... 36 Tarea 2......................................................................................................................................................... 36 Tarea 3......................................................................................................................................................... 36

1


Prácticas de Electrónica de Microelectrónica

Práctica nº 1:Práctica nº 1:Práctica nº 1:Práctica nº 1: INTRODUCCIÓN AL ENTORNO ISE INTRODUCCIÓN AL ENTORNO ISE INTRODUCCIÓN AL ENTORNO ISE INTRODUCCIÓN AL ENTORNO ISE

DE XILINXDE XILINXDE XILINXDE XILINX

INTRODUCCIÓN

La evolución de los sistemas digitales ha hecho necesario el empleo de lenguajes de descripción de circuitos. En efecto, cuando se pretende diseñar un sistema complejo con miles de elementos, tratar de describirlo a través de esquemas resulta inviable.

En la actualidad existen muchos lenguajes de descripción hardware, pero uno de los más extendido es el VHDL (Very high speed Hardware Description Language). Se desarrolló con la idea de que sirviera como un lenguaje estándar de descripción de circuitos. Esto significa que el código creado en VHDL puede ser utilizado con independencia del fabricante o la tecnología que elijamos.

Fue en 1984 cuando el IEEE propuso su estándar. Se diseñaron varias versiones con la colaboración de la industria y las universidades, pero fue finalmente en Diciembre de 1987 cuando el IEEE publicó el estándar IEEE Std 1076-1987 que más adelante sería conocido como VHDL`87.

2

DEPARTAMENTO ELAI EUITI - MADRID


Esta primera versión pronto mostró algunas carencias, debido fundamentalmente a la rápida evolución de las herramientas que utilizaban VHDL. Por eso, en 1993 el IEEE, en base a las experiencias recogidas del uso del VHDL´87 planteó un segundo estándar, el IEEE Std 1076-1993, más comúnmente conocido como VHDL´93.

Conviene resaltar que VHDL y otros lenguajes HDL tienen capacidad de expresar más cosas de las que las herramientas actuales son capaces de sintetizar. Incluso existen construcciones que tienen sentido para la verificación de un diseño o su descripción a muy alto nivel, pero que no tienen sentido en un chip, como el acceso a ficheros en disco o los bucles for. Por tanto, el hecho de que un diseño pueda simularse no significa que pueda sintetizarse. De hecho, según se avanza en el diseño y éste se va refinando, hay que restringirse a un subconjunto del lenguaje y a unas ciertas reglas de codificación que la herramienta de síntesis pueda comprender. Es lo que se denomina código sintetizable.

En este laboratorio se trabajará fundamentalmente en VHDL, si bien en algunas ocasiones emplearemos otras herramientas de captura como las de captura de esquemáticos, formas de onda o diagramas de estado. Como herramientas de trabajo emplearemos en el entorno de desarrollo de Xilinx ISE WebPack, ya que emplearemos dispositivos programables de este fabricante, y el simulador ModelSim XE II de Model Technology. Ambas herramientas (al menos en sus versiones más básicas) pueden descargarse de la página web de Xilinx. Hacer notar aquí que, aunque casi todos los fabricantes ofrecen su propio paquete de herramientas, que suelen subvencionar de algún modo, y que, como era de esperar, sólo es válido para sus productos, también existen paquetes independientes del fabricante, desarrollados por empresas de software de CAD/CAE como Mentor, Cadence o Synopsys.

EL ENTORNO DE DESARROLLO

El entorno de desarrollo está compuesto por un conjunto de herramientas que nos van a permitir:

• Capturar diseños a través de esquemáticos, diagramas de estados, en VHDL y en Verilog.

• Capturar testbenches (código de verificación) en forma de diagramas de formas de onda, VHDL o Verilog e incluso generarlos de forma semiautomática.

• Simular nuestro diseño a través de los testbenches generados.

• Sintetizar (generar la netlist) a partir del diseño capturado.

• Optimizar el diseño.

• Implementar el diseño en un dispositivo programable concreto (asignando bloques del dispositivo a los elementos de la netlist e interconectándolos entre sí) atendiendo a las restricciones de tiempo y espacio que podamos imponer.

• Programar el dispositivo programable elegido a través de un bus JTAG o generar el fichero de programación necesario.

La mayor parte de las herramientas son de Xilinx y se hallan integradas en el paquete Xilinx ISE WebPack. Sin embargo, este paquete no incluye el simulador, que debe obtenerse como una herramienta independiente.

3



Las dos herramientas más visibles del entorno son:

• Project Navigator: se trata de un entorno integrado de desarrollo (IDE) desde el que es posible acceder a todas las operaciones y herramientas necesarias para realizar nuestro diseño.

• ModelSim: nos permite simular el circuito realizado en el Project Navigator y verificar si se cumplen o no las especificaciones de diseño.

PROJECT NAVIGATOR

La ventana principal por defecto del Project Navigator consta de tres ventanas “atracables”, dos a la izquierda y una abajo, que rodean el área de trabajo. Es en el área de trabajo donde se editan los ficheros de VHDL y aparece la interfaz de varias de las herramientas. Por defecto, en el área de trabajo las ventanas se apilan en forma de cuaderno con separadores, de forma que en cada momento sólo se ve una ventana. Pinchando el separador de la ventana de nuestro interés, ésta pasa a primer plano. Otras herramientas, notablemente el simulador, abren sus propias ventanas independientes.

Figura 1: Vista general del entorno del Project Navigator.

En la parte superior izquierda está la ventana de Fuentes del Proyecto (Sources in Proyect), que muestra los elementos incluidos en el proyecto. Justo debajo de la ventana de Fuentes se encuentra la ventana de Procesos (Processes for Current Source) para la fuente actual, que muestra los procesos permitidos. La tercera ventana es la consola y ocupa la parte inferior de

4



la pantalla, visualiza los resultados de las operaciones que vamos realizando como los errores de compilación o los resultados del proceso de síntesis.

Sources in Proyect

Se compone a su vez de tres pestañas que ofrecen diversa información al usuario:

• Module View: Muestra el nombre del proyecto, el tipo de dispositivo sobre el que vamos a trabajar así como todos los elementos del proyecto (archivos VHDL, esquemáticos, diagramas de estados, bancos de pruebas…). Si un elemento en cuestión posee niveles inferiores de jerarquía veremos que a la izquierda del nombre aparece un +, si hacemos clic sobre él podremos visualizar los niveles de jerarquía. Para editar un archivo simplemente hay que hacer doble clic sobre el nombre del mismo.

• Snapshot view: Muestra todos los snapshots. Un snapshot es una copia de solo lectura del proyecto actual. Se usan para guardar el proyecto antes de emprender nuevas modificaciones con el fin de recuperarlo si los cambios no dan el resultado adecuado, o bien, para tener diferentes versiones del proyecto.

• Library view: Muestra todas las librerías asociadas al proyecto.

Processes for Current Source

Contiene la pestaña de la vista de procesos. Desde aquí se pueden lanzar las acciones posibles para cada tipo de fuente del proyecto y también comprobar el estado de las ya realizadas. En general cada acción de la lista requiere la ejecución de las que la preceden, no obstante, si fuese necesario, el programa lanzaría de forma automática las acciones previas pertinentes.

Para los ficheros que forman parte de la jerarquía del diseño las acciones posibles son:

• Desing Entry Utilities: nos sirve de comienzo para verificar y simular nuestro diseño.

• User Constraints: nos permite editar las restricciones temporales y de área.

• Synthesis: una vez que los archivos del diseño han sido creados podemos sintetizar el diseño. Al hacerlo se revisará la sintaxis y la jerarquía del diseño con el fin de optimizarlo para la arquitectura de diseño que hemos escogido.

• Implement Design: nos permite convertir nuestro diseño lógico a un formato físico que puede ser implementado en el dispositivo sobre el que vamos a trabajar ya sea una CPLD o una FPGA.

• Generate Programming File: permite generar el código binario que se cargará en el dispositivo.

Para los ficheros de test (testbenches) aparecen las opciones de simulación:

• Simulate Behavioral Model: Permite simular el código sin tener que sintetizarlo antes. Por tanto, no incluye retardos. Útil para verificar el comportamiento lógico (funcional) del diseño.

5



• Simulate Post…: Simula el diseño después de completar una determinada fase de síntesis. Al conocer los bloques implicados y su interconexión ya es posible hacer una estimación precisa de los retardos.

Consola

La consola nos muestra mensajes de información, avisos y errores. Los avisos se resaltan con una caja amarilla junto al mensaje, mientras que los errores se indican con una caja roja. En cualquiera de los dos casos si queremos ir a la parte del código en la que se ha producido el aviso o el error bastará con seleccionar el mensaje y hacer doble clic sobre él.

CREACIÓN DE UN NUEVO PROYECTO

A la hora de crear un nuevo proyecto se debe elegir el modo de representación para el nivel más alto de la jerarquía del diseño: esquemático o HDL. A continuación se detallan los pasos a seguir en cada caso:

Utilizando esquemáticos

1. Seleccionar New Proyect en el menú File.

2. Aparecerá la ventana New Proyect, en Proyect Location indicamos la ubicación del directorio en el que se guardarán los archivos del proyecto, en Proyect Name escribimos el nombre del proyecto y en Top Level Module-Type debemos seleccionar Schematic. Finalmente pulsamos Siguiente.

3. En la siguiente ventana podemos definir el dispositivo sobre el que vamos a implementar el diseño.

4. Al pulsar siguiente nos aparece un diálogo que nos pregunta si queremos añadir una fuente nueva al proyecto o bien una ya existente. Seleccionamos Add New Source.

5. Nos aparecerá un diálogo que nos muestra una lista de los diversos tipos de fuente con los que se puede trabajar. Seleccionamos Schematic. Escribimos el nombre del diseño en File Name y hacemos click en Siguiente.

6. Para concluir presionamos Finalizar.

Automáticamente se abrirá el editor de esquemáticos, Xilinx ECS (Engineering Schematic Capture).

6



Figura 2: Ventana de creación de un nuevo proyecto.

Utilizando código VHDL

1. Seleccionar New Proyect en el menú File.

2. Aparecerá la ventana New Proyect, en Proyect Location indicamos la ubicación del directorio en el que se guardarán los archivos del proyecto, en Proyect Name escribimos el nombre del proyecto y en Top Level Module-Type debemos seleccionar HDL. Finalmente pulsamos Siguiente.

3. En la siguiente ventana podemos definir el dispositivo sobre el que vamos a implementar el diseño.

4. Al pulsar siguiente nos aparece un diálogo que nos pregunta si queremos añadir una fuente nueva al proyecto o bien una ya existente. Seleccionamos Add New Source.

5. Nos aparecerá un diálogo que nos muestra una lista de los diversos tipos de fuente con los que se puede trabajar. Seleccionamos VHDL Module. Escribimos el nombre del diseño en File Name y hacemos click en Siguiente.

7



Figura 3: Definimos las entradas y salidas que tendrá el módulo.

6. La siguiente ventana nos permite definir las entradas y salidas que tendrá nuestro módulo así como el número de bits de que constarán. En Port Name se escribe el nombre de la entrada ó salida, en Direction indicamos si va a ser una entrada, una salida o una entrada-salida, y finalmente en MSB y LSB indicamos el número de bits. Una vez definidas todas las entradas/salidas pulsamos Siguiente.

7. Para terminar pulsamos Finalizar.

Al hacerlo se generará automáticamente el código básico en VHDL para definir las entradas y salidas que tendrá nuestro diseño y que hemos indicado en el paso 6. En este caso vamos a crear una sencilla puerta and. Debido a su sencillez la única línea que es necesario añadir al código VHDL pregenerado es S<=A and B; como se puede apreciar en la siguiente figura.

8



Figura 4: Definición de una puerta and en VHDL.

USO EL EDITOR DE ESQUEMÁTICOS

Cuando se abre el editor de esquemáticos veremos una ventana principal en blanco que es donde podremos dibujar el esquemático. A su izquierda hay dos pestañas llamadas Options y Symbols.

En Options aparecen varias opciones que nos ofrecen la posibilidad de indicar como queremos que se comporte la interfaz del programa al usar una herramienta en concreto que hayamos seleccionado, es decir la pestaña Options cambia dependiendo de la herramienta seleccionada.

En Symbols hay varios campos:

• Categories: nos permite elegir el tipo de componentes que queremos que aparezcan en el siguiente campo (symbols) si seleccionamos all symbols en symbols aparecerán todos los componentes.

• Symbols: aquí elegimos los componentes que deseamos introducir en nuestro esquemático.

• Symbol Name Filter: en symbols sólo aparecerán los componentes que empiecen por las letras que aquí escribamos, así por ejemplo, si tenemos seleccionado all symbols en

9



Categories y en Symbol Name Filter escribimos en Symbols sólo aparecerán las puertas and.

• Orientation: se usa para rotar el componente que vamos a colocar en la ventana principal.

Una vez seleccionado el componente solo resta llevar el cursor al lugar de la ventana principal donde queremos colocarlo y hacer click.

Figura 5: Ventana principal del editor de esquemáticos.

Para unir los componentes entre sí deberemos usar la herramienta wire, esto se puede seleccionando Add->Wire en el menú principal.

Una vez colocados los componentes y conectados correctamente entre sí, es imprescindible definir bien las entradas y salidas del esquema, esto se hace mediante la herramienta marcador de entrada/salida (I/O Marker) que se encuentra en el menú Add. Para definir el marcador debemos unirlo mediante una línea (Wire) al componente en cuestión y hacer doble click sobre el marcador; nos aparecerá una ventana en la que podremos definir la entrada-salida escribiendo el nombre en la celda Name-Value y el tipo de puerto (entrada, salida o bidireccional) en PortPolarity-Value.

Si queremos dar nombres a los cables, para facilitar su identificación, hay que seleccionar Add->Net_Name en el menú principal. Para dar nombre al cable debemos escribirlo en la edit box que aparece en la pestaña Options y seguidamente hacer click sube el cable en cuestión.

10



Terminado el diseño, el siguiente paso es revisarlo para asegurarse de que todas las conexiones esta bien hechas. Esto se puede hacer fácilmente seleccionando en el menú principal Tools->Check_Schematic. Aparecerá una ventana que nos indicará si hay algún error en el circuito. Si todo está correctamente, el último paso es guardar el diseño y volver al Project Navigator.

VERIFICACIÓN DE LA SINTAXIS Y SIMULACIÓN

Para verificar la sintaxis debemos ir a la ventana Processes for Source y hacer doble click en el icono Synthetisize-XTS, automáticamente se revisará la sintaxis y aparecerá una marca verde junto al icono si no han aparecido errores o warnings; si hay algún warning aparecerá una exclamación amarilla y si por contra hay errores veremos una "x" roja. De todos modos una forma más rápida y sencilla de ver si hemos cometido algún error en la sintaxis es hacer doble click en Create Schematic Symbol el cual se encuentra en Design Entry Utilities. Una vez que la sintaxis es correcta podemos pasar a la simulación.

Tanto si hemos diseñado un circuito programando directamente en VHDL o utilizando esquemáticos, la simulación resulta un paso imprescindible para saber si los resultados son los esperados o por el contrario debemos revisar el diseño.

Para simular lo más cómodo es comenzar creando un banco de pruebas donde introduciremos los valores que se les aplicarán a las entradas y en función de los cuales se obtendrá la salida.

Figura 6: Verificar la sintaxis.

11



Los pasos a seguir son:

1. Hacer click con el botón derecho en la pestaña Module View en Sources in Proyect y seleccinar New Source.

2. En la ventana New Source escogemos Test Bench Waveform, damos nombre al archivo y pulsamos Siguiente.

3. Seleccionamos el archivo sobre el que queremos realizar la simulación. Para terminar hacemos click en Siguiente y Finalizar.

En la ventana Initialize Timing hay que especificar los parámetros de tiempos que se usarán en la simulación. Si el diseño que vamos a simular es secuencial, y en consecuencia usa una señal de reloj, deberemos seleccionar Single Clock y fijar sus condiciones de funcionamiento.

Figura 7: Generación del testbench

Al hacer click en Ok nos aparecerá el banco de pruebas donde podremos ver que la entradas tienen marcas azules y las salidas marcas amarillas y todas están inicializadas a 0. Ahora debemos definir los valores de las entradas y salidas para poder probar el diseño, para ello si hacemos click en la zona coloreada de cada celda (azul para las entradas, amarillo para las salidas) podremos cambiar el valor. En el caso de que la entrada o salida sea un vector veremos que al hacer click nos aparece un botón en el que pone pattern (en el caso de que la entrada o salida sea de un bit deberemos hacer doble clic para que salga el botón pattern) y una caja donde escribir un valor; el botón pattern sirve para definir un patrón en esa entrada, de forma que, por ejemplo, podríamos hacer que se asignaran valores a partir de uno dado y se

12



fueran incrementando en uno en cada ciclo de tiempo; por contra si sólo queremos dar un valor a esa celda escribiremos el número y presionaremos enter.

Cuando hayamos terminado de definir los valores de las entradas y salidas deberemos guardar el diseño haciendo click en el icono del diskete en la ventana del banco de pruebas. Al hacer esto veremos que en la ventana Sources in Project se nos añade un nuevo archivo, si lo seleccionamos aparecerán en Processes for Source los procesos o funciones para ese archivo que como veremos están todos relacionados con la simulación. Si hacemos doble click sobre Simulate Behavioral Model se abrirá el Model Sim y se procederá a la simulación.

Figura 8: Simulación con ModelSim XE de una puerta and.

La ventana principal nos da información de los eventos que ocurren en la simulación y nos informará al final si la simulación ha sido correcta siempre y cuando así lo definamos en el código VHDL para la simulación.

En la ventana wave podremos ver como varían las entradas y salidas del sistema en el tiempo.

En el caso de que simulemos un diseño sin utilizar ningún banco de pruebas la ventana signals nos será útil para dar valores a las señales.

13



Práctica nº 2:Práctica nº 2:Práctica nº 2:Práctica nº 2: Decodificador BCD a 7 segmentosDecodificador BCD a 7 segmentosDecodificador BCD a 7 segmentosDecodificador BCD a 7 segmentos

OBJETIVOS DE LA PRÁCTICA

Con la realización de esta práctica se persiguen los siguientes objetivos:

• Familiarizarse a través de ejemplos sencillos con los tres tipos de descripción en VHDL: flujo de datos, comportamental y estructural.

• Ejercitarse en la creación de programas de pruebas o testbenches.

• Familiarizase con el uso de restricciones, en particular con las de asignación de patillas.

• Familiarizarse con el uso de los recursos de la placa de prácticas.

INTRODUCCIÓN

LA TARJETA SPARTAN-3 STARTER KIT

La tarjeta que se va a usar en las prácticas está fabricada por Digilent bajo el patrocinio de Xilinx y se ha diseñado para facilitar la iniciación en el uso de las FPGA Spartan-3 de Xilinx y como un entorno de bajo coste para la evaluación de diseños realizados con estos dispositivos.

14



Las características más importantes de esta tarjeta son:

• Una FPGA XC3S200FT256 de 200.000 puertas con encapsulado BGA de 256 patillas:

• Equivalente a 4.230 celdas lógicas.

• Doce bloques de RAM de 18 kbit (216 kbit en total).

• Doce multiplicadores hardware de 18 × 18 bits.

• Cuatro gestores de reloj digitales (DCM).

• Hasta 173 patillas de entrada salida definidas por el usario.

• 2 Mbit de memoria flash XCF02S para configuración. Programable en el propio circuito a través del bus JTAG:

• 1 Mbit está reservado para la configuración de la FPGA.

• El resto está disponible para almacenar variables no volátiles del usuario.

• 1 Mbyte de memoria RAM estática asíncrona rápida:

• Dos memorias ISSI IS61LV25616AL-10T seleccionables de forma individual con posibilidad de acceso a bytes individuales.

• Posibilidad de organizarla en un bloque de 256 kword de 32 bits o dos bloques de 256 kword de 16 bits.

• Tiempo de acceso de 10 ns.

• Puerto VGA de 8 colores (3 bits).

• Puerto serie RS-232 de nueve patillas (existe un segundo puerto accesible sólo a través de los puntos de prueba de la tarjeta).

• Puerto PS/2 para teclado o ratón.

• Visualizador con cuatro dígitos de siete segmentos .

• Ocho interruptores deslizantes.

• Ocho LED.

• Cuatro pulsadores.

• Un reloj de 50 MHz (es posible usar también un reloj externo).

• Tres conectores de expansión de 40 patillas.

• Un puerto JTAG.

Con estos recursos resulta posible implementar desde las más sencillas máquinas de estados hasta un sistema de procesamiento digital de señal en tiempo real (FFT, filtros, MP3…), pasando por un sistema microprocesador con su controlador de vídeo (SoC).

Los detalles sobre la tarjeta, necesarios para la realización de las prácticas, se encuentran en el manual que la acompaña.

15



EL BUS JTAG

Aunque los encapsulados actuales pueden tener varios cientos de patillas, el número de patillas no puede crecer indefinidamente. Al mismo tiempo, los dispositivos lógicos actuales albergan en su interior varios millones de puertas a las que únicamente se puede acceder a través de esas patillas y que en muchos casos ni siquiera tienen conexión funcional con el exterior. Dada la cantidad limitada de patillas disponibles, resulta inviable dedicar muchas de ellas a monitorizar el funcionamiento del circuito. Así pues, se llega a un callejón sin salida a la hora de comprobar el funcionamiento correcto del dispositivo y/o del diseño.

Una de las soluciones adoptadas ha sido el Boundary-Scan, una técnica que emplea un registro de desplazamiento especializado con tantos bits como nodos lógicos interese explorar y que puede leer o modificar su valor. Los datos obtenidos o que se desea introducir se transmiten en serie, por lo que el número de patillas necesarias es muy reducido y no depende del tamaño del dispositivo. Los registros de desplazamiento de varios dispositivos se pueden enlazar formando una “cadena de Boundary-Scan”, de modo que es posible monitorizar el estado de una tarjeta completa a través de unos pocos terminales (por supuesto, también es posible enlazar varias tarjetas y así sucesivamente).

Con el tiempo, se le ha añadido nueva funcionalidad, p.ej.:

• Identificación de dispositivos: modelo, versión, fabricante. Esto permite que una tarjeta se reconfigure automáticamente en función de los dispositivos presentes en un momento dado.

• Detección de componentes averiados.

• Configuración de lógica programable “in situ”.

• Visualización y modificación del estado interno del dispositivo: existen programas de depuración “semejantes” a los empleados en el desarrollo de software.

Figura 9: Bus JTAG

16



El bus JTAG es un bus serie síncrono que normaliza el acceso a la cadena para todos los dispositivos sean lógica fija, programable, memorias, microprocesadores o circuitos especializados. Consta de cuatro líneas: dos de datos (TDI y TDO), una de modo (TMS) y otra de reloj (TCK). Una implementación habitual en los sistemas de desarrollo más económicos emplea líneas del puerto paralelo de un PC como líneas del bus JTAG. En estas prácticas emplearemos un conector de este tipo.

CONTROL DEL PROCESO DE SÍNTESIS

Una vez descrito nuestro sistema en VHDL sintetizable el resto del proceso hasta obtener el fichero o la máscara de programación es automático. Sin embargo, existen formas de dirigir ese proceso. La primera forma tiene que ver con la posibilidad de elegir el tipo de optimizaciones a emplear y la segunda con la aplicación de “restricciones”.

Optimizaciones

Normalmente, velocidad y área son características antagónicas. Por ello las aplicaciones de síntesis permiten optimizar un diseño para hacerlo lo más rápido posible (a costa de ocupar más espacio) o lo más pequeño posible (a costa de su velocidad). En la actualidad, con la proliferación de dispositivos portátiles la potencia consumida también es un parámetro a optimizar.

Otro área donde es posible la optimización es en la partición del diseño. La aplicación de síntesis, por defecto, conservará nuestra partición, es decir, los componentes que hayamos definido, nuestras interfaces y señales. Esto es útil en las primeras fases de la verificación del diseño puesto que en el simulador veremos nuestros objetos, con los que estamos familiarizados. Sin embargo, esto limita en muchas ocasiones una mayor optimización: supongamos un componente con una salida invertida conectada a una entrada invertida de otro componente; si se respeta la partición se crearán dos inversores cuando realmente no era necesario ninguno. Es posible indicarle a la aplicación que realice este tipo de optimización, aunque puede que las señales y componentes finales nos resulten irreconocibles.

Restricciones

La descripción en VHDL sintetizable contiene la funcionalidad de nuestro diseño, pero esto no es suficiente para garantizar el cumplimiento de los requisitos de la especificación. En efecto, normalmente será necesario garantizar una frecuencia mínima de funcionamiento, que determinadas señales vayan a determinadas patillas o que el diseño quepa en un dispositivo concreto. Mediante las restricciones es posible forzar a la aplicación de síntesis a que cumpla con ciertos criterios. Es importante ser consciente de que cuantas más restricciones se impongan, más difícil será conseguir el objetivo final, por lo que sólo deben imponerse aquellas realmente necesarias. Es perfectamente posible que la herramienta aborte la síntesis al no poder cumplir unas restricciones poco realistas.

Las restricciones más típicas en el caso de los dispositivos lógicos programables son las de los retardos máximos en ciertas líneas (camino crítico) y la asignación de determinadas señales a determinadas patillas o bloques funcionales.

17



PROGRAMAS DE PRUEBA

Una simulación no es nada más que un experimento virtual realizado para verificar el comportamiento de un circuito ante unos estímulos de entrada. Puesto que sólo nosotros comprendemos el funcionamiento de nuestro diseño y sólo nosotros podemos analizarlo no podemos esperar que baste con pulsar un botón y que la máquina lo haga todo. Es nuestra responsabilidad escribir un programa de pruebas o testbench que alimente nuestro diseño con un número de entradas suficiente como para verificar su funcionamiento.

Para ser estrictos, se debería empezar siempre por escribir el testbench de un componente y luego el propio componente. En efecto, todo diseño debe superar dos pruebas: su validación y su verificación. La validación supone comprobar si la especificación de un determinado diseño resuelve realmente el problema que motivó el diseño y, por tanto, sólo puede hacerla el cliente y/o el analista de sistemas. La verificación consiste en comprobar que un diseño concreto cumple la especificación. Este último proceso sí que puede automatizarse.

Es ahí donde entra el testbench. Una vez validada la especificación se debe escribir un programa que compruebe de forma exhaustiva que un componente dado la cumple. Cada vez que se refine el diseño o se realice un cambio se ejecutará el tesbench para comprobar su validez.

La creación de un programa de pruebas no es trivial y en muchas ocasiones lleva más tiempo y esfuerzo que la creación de un componente, pero resulta fundamental.

Un programa de pruebas puede consistir en la aplicación de una tabla de vectores de test almacenada en el propio programa o en un archivo en disco, o en una descripción algorítmica de las pruebas.

La comprobación de los resultados puede hacerse por inspección visual de las formas de onda, pero cuando el circuito es complejo este método se vuelve inviable. Lo mejor es emplear la instrucción ASSERT. Esta instrucción verifica que se cumple una condición y si no es así imprime un mensaje y, dependiendo de la gravedad del error, puede llegar a detener la simulación. Su sintaxis es:

ASSERT condición

[REPORT mensaje]

[SEVERITY gravedad];

Cada componente creado debería tener uno o más tesbench para su verificación.

LA ENTIDAD DE NIVEL SUPERIOR

Normalmente, el objetivo último de nuestro diseño será convertir nuestro dispositivo lógico programable en un componente a medida. La entidad de nivel superior se corresponde con este componente y define la interfaz de nuestro diseño con el exterior. Lo habitual es que consista en una descripción estructural en la que se describe la interconexión entre los componentes de nivel jerárquico inferior de nuestro diseño.

18



Es a esta entidad a la que se le aplican las restricciones de asignación de señales a patillas concretas.

REALIZACIÓN DE LA PRÁCTICA

En esta práctica vamos a utilizar los cuatro dígitos de la placa para visualizar un número introducido a través de los interruptores deslizantes.

Se empezará por controlar un solo dígito y se irá progresando hasta controlar los cuatro disponibles.

EL DECODIFICADOR

El principal componente de este diseño será un decodificador de BCD a siete segmentos. Un decodificador es un circuito combinacional que realiza la operación inversa a la de un codificador de datos, por eso también se puede definir un decodificador como circuito que convierte un código binario concreto en una forma sin codificar.

Los dígitos de la tarjeta son de tipo LED. Cada segmento es un LED uno de cuyos terminales es común para todos los segmentos: existen versiones de cátodo común y de ánodo común. En nuestro caso se trata de un ánodo común, por lo que para que luzca un segmento debemos aplicar al terminal no común un ‘0’. Los cuatro dígitos comparten las mismas señales de control de los segmentos. La forma de mostrar números distintos en cada dígito consiste en irlos encendiendo en secuencia haciendo que las líneas de control de los segmentos reflejen el número correspondiente al dígito activo en ese momento. Si está secuencia se ejecuta a suficiente velocidad el ojo resulta engañado y percibe todos los dígitos iluminados a la vez. Para iluminar un dígito concreto en esta tarjeta es necesario aplicar un ‘0’ a la línea de control pertinente.

Figura 10: Visualizador de 4 dígitos y líneas correspondientes de la FPGA.

19



Figura 11: Secuencia de encendido de los dígitos.

Teniendo esto en cuenta podemos obtener fácilmente la tabla de verdad de este decodificador:

A B C D a b c d e f g

0 0 0 0 0 0 0 0 0 0 1

0 0 0 1 1 0 0 1 1 1 1

0 0 1 0 0 0 1 0 0 1 0

0 0 1 1 0 0 0 0 1 1 0

0 1 0 0 1 0 0 1 1 0 0

0 1 0 1 0 1 0 0 1 0 0

0 1 1 0 0 1 0 0 0 0 0

0 1 1 1 0 0 0 1 1 1 1

1 0 0 0 0 0 0 0 0 0 0

1 0 0 1 0 0 0 0 1 0 0

Ahora estamos en condiciones de crear el tesbench:

LIBRARY ieee; USE ieee.std_logic_1164.ALL; ENTITY decoder_decoder_tb_vhd_tb IS END decoder_decoder_tb_vhd_tb; ARCHITECTURE behavior OF decoder_decoder_tb_vhd_tb IS COMPONENT decoder PORT( code : IN std_logic_vector(3 downto 0); led : OUT std_logic_vector(6 downto 0) ); END COMPONENT; SIGNAL code : std_logic_vector(3 downto 0); SIGNAL led : std_logic_vector(6 downto 0); TYPE vtest is record code : std_logic_vector(3 downto 0);

20



led : std_logic_vector(6 downto 0); END RECORD; type vtest_vector is array (natural range <>) of v test; constant test: vtest_vector := ( (code => "0000", led => "0000001"), (code => "0001", led => "1001111"), (code => "0010", led => "0010010"), (code => "0011", led => "0000110"), (code => "0100", led => "1001100"), (code => "0101", led => "0100100"), (code => "0110", led => "0100000"), (code => "0111", led => "0001111"), (code => "1000", led => "0000000"), (code => "1001", led => "0000100"), (code => "1010", led => "1111110"), (code => "1011", led => "1111110"), (code => "1100", led => "1111110"), (code => "1101", led => "1111110"), (code => "1110", led => "1111110"), (code => "1111", led => "1111110") ); BEGIN uut: decoder PORT MAP( code => code, led => led ); tb: PROCESS begin for i in 0 to test'high loop code <= test(i).code; wait for 20 ns; assert led = test(i).led report "Salida incorrecta." severity failure; end loop; assert false report "Simulación finalizada. Test superado." severity failure; end process; END;

Y nuestro decodificador:

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

21



entity decoder is port ( code : in std_logic_vector(3 downto 0); led : out std_logic_vector(6 downto 0) ); end entity decoder; architecture dataflow of decoder is begin with code select led <= "0000001" when "0000", "1001111" when "0001", "0010010" when "0010", "0000110" when "0011", "1001100" when "0100", "0100100" when "0101", "0100000" when "0110", "0001111" when "0111", "0000000" when "1000", "0000100" when "1001", "1111110" when others; end architecture dataflow;

TAREA 1

Ejecutar el tesbench y comprobar que no hay errores.

Crear una arquitectura de tipo estructural que incluya el decodificador para la siguiente entidad de nivel superior:

entity top is port ( code : in std_logic_vector(3 downto 0); digsel : in std_logic_vector(3 downto 0); digctrl : out std_logic_vector(3 downto 0); segment : out std_logic_vector(7 downto 0)); end top;

El código BCD se debe poder introducir por los cuatro interruptores deslizantes de menor peso y el dígito activo, a través de los cuatro de más peso.

Estos interruptores ponen a ‘0’ su línea asociada cuando están abajo (hacia el exterior de la tarjeta) y a ‘1’ cuando están arriba (hacia el interior).

SW7 SW6 SW5 SW4 SW3 SW2 SW1 SW0

K13 K14 J13 J14 H13 H14 G12 F12

Figura 12: Conexión de los interruptores a la FPGA

22



Una vez creada la arquitectura procederemos a asociar la señales con las patillas adecuadas de la FPGA. Para ello crearemos un fichero de restricciones (figura 13 y figura 14):

1. Seleccionar la entidad de nivel superior (top).

2. Seleccionar User Constraints -> Assign package pins.

3. Seleccionar Package View.

4. Arrastrar las señales hasta las patillas seleccionadas o escribir el nombre de la patilla en la columna LOC de la señal.

5. Salvar el fichero.

A continuación generaremos el fichero de programación haciendo doble clic sobre la entrada del árbol Generate Programming File.

Cuando termine el proceso descargaremos el fichero sobre la FPGA haciendo doble clic sobre Configure Device (iMPACT) y seleccionado en el diálogo que se abre a continuación Boundary-Scan Mode (figura 15). Deben detectarse dos dispositivos en la cadena: la FPGA y la memoria flash. La aplicación de configuración abre justo después dos diálogos para introducir el nombre de los ficheros de programación: se debe elegir top.blt para la FPGA y pulsar el botón Bypass para la memoria (no la vamos a programar en esta práctica). Para ejecutar la programación seleccionaremos la FPGA y, a través del menú de contexto, Program.

TAREA 2

Crear un nuevo componente: un contador Jonhson o de anillo de 4 bits utilizando para ello una descripción comportamental. Usar como reloj la señal interna de 50 MHz (T9) y como reset el pulsador BTN3 (L14).

Usar este componente para encender secuencialmente todos los dígitos. Para ello añadirlo a top, eliminar la entrada digsel y conectar digctrl a la salida del contador.

23



Figura 13: Asignación de patillas (I).

Figura 14: Asignación de patillas (y II).

24



Figura 15: Programación del dispositivo.

25



Práctica nº 3:Práctica nº 3:Práctica nº 3:Práctica nº 3: Diseño de una Unidad Lógico Diseño de una Unidad Lógico Diseño de una Unidad Lógico Diseño de una Unidad Lógico

AritméticaAritméticaAritméticaAritmética



• Profundizar en el uso de la descripción comportamental y sus construcciones sintácticas para describir y sintetizar dispositivos complejos.

• Uso de genéricos para mejorar la reusabilidad del código.

• Introducción del concepto de datapath y programación de un ejemplo típico.

• Introducirse en la programación temporal de las señales de control.

INTRODUCCIÓN

El corazón de cualquier sistema de procesamiento es la Unidad Central de Proceso (CPU). Ésta, en su versión más clásica, está compuesta a su vez por tres elementos: la Unidad de Control, el Banco de Registros y la Unidad Lógico-Aritmética (ALU). El Banco de Registros se emplea para almacenar el contador de programa, los registros de índice y los operandos y resultados de las operaciones efectuadas. La ALU efectúa todas las operaciones lógicas

26



(operadores lógicos, desplazamientos, etc.) y aritméticas (sumas, restas, negación, etc.). Por último, la Unidad de Control interpreta las instrucciones del programa y genera la secuencia de señales de control necesarias para ejecutarlas.

Esta partición es típica de un sistema orientado a datos o lo que es lo mismo, en el que lo importante es de dónde vienen lo datos, qué se hace con ellos y a dónde van después. En estos casos el diseño se suele dividir en dos partes: por un lado tenemos la “ruta de datos” o datapath que contiene los buses, registros y operadores que deben atravesar los datos, y, por otra, una máquina de estados finitos (la Unidad de Control) que genera las señales necesarias para el control del datapath. En está práctica nos ocuparemos de la programación en VHDL de parte del datapath descrito: una ALU y sus registros auxiliares.

Figura 16:Representación esquemática de una ALU.

Normalmente, para su operación la ALU se auxilia de dos registros: uno es el acumulador, visible para el programador, y el otro es un registro auxiliar, que no suele ser visible nada más que para el diseñador del procesador, cuya misión es mantener el valor del operando estable mientras se ejecuta la operación. Los operandos sobre los que se opera deben almacenarse en estos registros para que la operación pueda efectuarse. Finalmente, el resultado de la operación suele almacenarse en el acumulador, sobrescribiendo el operando original.

A parte del resultado de la operación, la ALU suele informar de ciertas propiedades del éste como, por ejemplo, si es cero, o negativo, o si se ha producido algún tipo de error o acarreo. Esta información es fundamental pues permite variar el curso del programa en función del resultado o de si se ha producido algún error y también permite encadenar operaciones para operar sobre operandos con un número de bits mayor que el de la ALU. Esta información está disponible a través de un conjunto de marcas o flags que se almacenan en un registro específico: el Registro de Condición de Estado o CCR. Flags típicos del registro de estado son:

• Cero (Z): toma el valor 1 si el resultado de una operación es cero.

• Signo (N): toma el valor 1 si el resultado de una operación es negativo (MSB = 1).

27



• Acarreo (C): se ve afectado por las instrucciones de desplazamiento (se pone a 1 ó 0 según el valor del bit desplazado) y por las operaciones aritméticas.

• Desbordamiento (V): se pone en 1 si ocurre un desbordamiento en una operación aritmética, es decir, si el tamaño del resultado es mayor que el tamaño del registro en el que ha de almacenarse y hay, por tanto, pérdida de información.

La operación concreta a realizar por la ALU se selecciona a través de un bus de control que opera la Unidad de Control. En nuestro caso las operaciones dependerán del siguiente código:

Valor del bus Operación

0000 Suma

0001 Resta

0010 Negación

0011 Inversión binaria del valor del registro auxiliar

0100 OR binaria del valor del registro auxiliar

0101 AND binaria del valor del registro auxiliar

0110 XOR binaria del valor del registro auxiliar

0111 Desplazamiento lógico/aritmético a la izquierda

1000 Desplazamiento lógico a la derecha

1001 Desplazamiento aritmético a la derecha

1010 Rotación a la izquierda

1011 Rotación a la derecha

1011 Rotación a la derecha

OTHERS Se pone a cero el acumulador


En primer lugar partiremos del siguiente código (ula.vhd) que describe una ALU con funcionalidad limitada:

LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.STD_LOGIC_ARITH.ALL; USE IEEE.STD_LOGIC_UNSIGNED.ALL; ENTITY ULA IS GENERIC ( nbits : integer := 4 ); PORT ( a : IN std_logic_vector(nbits - 1 DOWNTO 0) ; b : IN std_logic_vector(nbits - 1 DOWNTO 0) ; opcode: IN std_logic_vector(3 DOWNTO 0); carry : OUT std_logic; zero : OUT std_logic; neg : OUT std_logic; result: OUT std_logic_vector(nbits - 1 DOWNTO 0) ); END ENTITY ULA;

28



ARCHITECTURE Behavioral OF ULA IS CONSTANT zeroval : std_logic_vector(nbits - 1 D OWNTO 0) := (OTHERS => '0'); SIGNAL result_int: std_logic_vector(nbits - 1 D OWNTO 0); BEGIN ula: PROCESS(a, b, opcode) BEGIN carry <= '0'; CASE opcode IS WHEN "0000" => result_int <= a + b; WHEN "0001" => result_int <= a - b; WHEN "0010" => -- NEG result_int <= zeroval - a; WHEN "0011" => -- NOT result_int <= NOT a; WHEN "0100" => -- OR result_int <= a OR b; WHEN "0101" => -- AND result_int <= a AND b; WHEN "0110" => -- XOR result_int <= a XOR b; WHEN "0111" => -- LSL, ASL result_int <= a(2 DOWNTO 0) & '0'; carry <= a(3); WHEN "1000" => -- LSR result_int <= '0' & a(3 DOWNTO 1); carry <= a(0); WHEN "1011" => -- ROR result_int <= a(0) & a(3 DOWNTO 1); carry <= a(0); WHEN OTHERS => result_int <= (OTHERS => '0'); END CASE; END PROCESS ula; zero <= '1' WHEN result_int = zeroval ELSE '0'; result <= result_int; END ARCHITECTURE Behavioral;

De esta descripción cabe destacar:

• El uso de genéricos (nbits ) para determinar el ancho de palabra de la ALU: el mismo código puede usarse para ALUs de 4, 8 o n bits.

• No se genera el bit de negativo (N) ni el de desbordamiento (V).

29



• No se implementan las operaciones ROL ni ASR.

La primera parte de esta práctica consistirá enañadir parte de la funcionalidad perdida y escribir un testbech para comprobar su correcto funcionamiento.

La segunda parte consistirá en completar un datapath elemental para poder implementar la ALU en la tarjeta de desarrollo y ejecutar operaciones sencillas.

EJERCICIOS

TAREA 1

Para una ALU de 4 bits:

• Completar el código suministrado de forma que implemente correctamente el bit de negativo (N) y las operaciones ROL y ASR.

• Escribir un testbench que compruebe el funcionamiento de las dos nuevas operaciones y del bit N con los números 516 y A16.

TAREA 2

Para completar el datapath:

• Crear un multiplexor 2 a 1 de un ancho de bits arbitrario, por defecto de 4 bits.

• Crear un registro tipo D con reset asíncrono de un ancho de bits arbitrario, por defecto 4 bits.

Con estos elementos y la ALU crear una nueva entidad (datapath) con una arquitectura estructural que responda al siguiente esquema:

El CCR debe almacenar las marcas de acarreo (C), cero (Z) y negativo (N).

Comprobar que el código es correcto y que puede implementarse en la tarjeta de prácticas.

LOAD1

RESET

RESET RESET ACC1 ACC2

ULA

DIN

DOUT

CCR

SEL1

SEL2

LOAD2

LOAD3

31



Práctica nº 4:Práctica nº 4:Práctica nº 4:Práctica nº 4: Diseño de una Unidad Lógico Diseño de una Unidad Lógico Diseño de una Unidad Lógico Diseño de una Unidad Lógico

Aritmética (y II)Aritmética (y II)Aritmética (y II)Aritmética (y II)



• Practicar con el diseño de una máquina de estados finitos de Moore.

• Introducción a la problemática de la planificación de la secuencia de operaciones.

• Familiarizarse con el uso de la herramienta StateCAD de Xilinx para la captura de máquinas de estados finitos (FSM).

INTRODUCCIÓN

En la práctica anterior se desarrolló una ULA que luego se incorporó a un datapath muy parecido al de los microprocesador reales más sencillos. Por sí sólo este datapath no puede realizar ninguna operación: necesita de una lógica de control que active las señales adecuadas en los momentos precisos. Esta lógica de control consiste habitualmente en una máquina de estados.

32



El diseño de esta máquina de estados se realiza en dos pasos:

1. Establecimiento de la secuencia de operaciones.

2. Establecimiento de los estados necesarios y de los valores de las señales en cada uno de esos estados.

En efecto, en un datapath se dispone de unos recursos limitados y es necesario aprovecharlos al máximo. En muchas ocasiones las operaciones no se ejecutan de una vez, sino que es necesario dividirlas en operaciones más pequeñas. En cada suboperación pueden usarse todos los recursos o no por lo que cabe la posibilidad de que, eligiendo el orden correcto en la ejecución de las mismas, se puedan ejecutar varias al mismo tiempo o que se necesite menos hardware para hacerlo. Por eso es necesario establecer la secuencia de operaciones tras un análisis cuidadoso de todas las posibilidades. Existen dos aproximaciones fundamentales: búsqueda de la secuencia que máximiza el número de operaciones por unidad de tiempo (pero penaliza el área) y búsqueda de la secuencia que minimiza el hardware (área) necesario (pero que penaliza la velocidad). También puede buscarse la secuencia que minimiza el consumo de energía.

Una vez establecida la secuencia cada paso se traduce a uno o más estados de una máquina de estados para los que es necesario determinar que valores han de tomar las señales de control del datapath.

En esta práctica se va a desarrollar la FSM necesaria para operar el datapath desarrollado en la práctica anterior y también se van a incorporar al diseño los elementos necesarios para poder descargarla sobre la tarjeta de desarrollo y usarla como una sencilla calculadora. Estos elementos van a ser el decodificador de 7 segmentos que se desarrollo en la segunda práctica, un circuito antirrobote que obtendremos de las plantillas de VHDL que viene con el entorno de desarrollo ISE de Xilinx y la adición de las restricciones necesarias (asignación de pines) para adecuar el diseño a la tarjeta. El interfaz externo del circuito completo puede verse en la siguiente figura:

Figura 17: Interfaz externa del circuito de la práctica.

33



En la figura siguiente se muestra el esquema interno del circuito:

Figura 18: Esquema interno.

Las señales están conectadas a los dispositivos físicos de la tarjeta de la siguiente manera:

• din: conectado a los interruptores SW3 a SW0.

• opcode: conectado a los interruptores SW7 a SW4.

• clk: conectado al reloj interno de 50 MHz.

• confirm: conectada al pulsador BTN0.

• reset: conectada al pulsador BTN3.

• digit: conectado a los ánodos AN3 a AN0.

• segment: conectado a las líneas de segmentos dp, a, b, c, d, e, f y g.

• status: conectado a los LED LD2 (N), LD1 (Z) y LD0 (C ).

La forma de operar el circuito será la siguiente:

1. Reiniciar el circuito.

2. Introducir el código de la operación a ejecutar.

3. Introducir el primer operando.

4. Confirmar la introducción del primer operando (BTN0).

5. Introducir el segundo operando.

34



6. Confirmar la introducción del segundo operando.

7. Pulsar de nuevo BTN0 para volver a 2.

El único display activo será el correspondiente a AN0, el resto permanecerá apagado. Durante la mayor parte del tiempo este display deberá reflejar el número introducido a través del bus din, únicamente mostrará el resultado de la operación en los pasos 6 y 7.

DISEÑO DE LA MÁQUINA DE ESTADOS FINITOS

En la figura 3 se vuelve a mostrar el datapath desarrollado en la práctica anterior:

Figura 19: Datapath.

El primer multiplexor permite cargar ACC1 con el valor introducido por el bus de entrada din (sel1 = 0) o con el resultado de la operación actual (sel1 = 1). El segundo multiplexor permite seleccionar que valor sale al exterior para su visualización: el valor actual del bus de entrada din (sel2 = 0) o el contenido de ACC1 (sel2 = 0). El registro ACC1 guarda el primer (y, en ocasiones, único) operando de la próxima operación y el resultado de la operación anterior. El registro ACC2 guarda el segundo operando (si lo hubiere). Por último el registro CCR guarda el Código de Condición de la última operación realizada.

Para la ejecución de operaciones binarias se ha desarrollado el siguiente diagrama de estados:

LOAD1

RESET

RESET RESET ACC1 ACC2

ULA

DIN

DOUT

CCR

SEL1

SEL2

LOAD2

LOAD3

CC

35



RESET

confirm = '1'

confirm = '1'

confirm = '1'

STATE5

sel1 = '0';

sel2 = '1';

load1 = '0';

load2 = '0';

load3 = '0';

STATE4

sel1 = '1';

sel2 = '1';

load1 = '1';

load2 = '0';

load3 = '1';STATE3

sel1 = '1';

sel2 = '0';

load1 = '0';

load2 = '1';

load3 = '0';

STATE2

sel1 = '1';

sel2 = '0';

load1 = '0';

load2 = '0';

load3 = '0';

STATE1

sel1 = '0';

sel2 = '0';

load1 = '1';

load2 = '0';

load3 = '0';

STATE0

sel1 = '0';

sel2 = '0';

load1 = '0';

load2 = '0';

load3 = '0';

Figura 20: diagrama de estado para operaciones binarias.

STATE0 es el estado inicial al que se llega después de un reset o de completarse un ciclo completo.

STATE1 y STATE2 generan un pulso sobre load1 para cargar ACC1 con el primer operando.

STATE3 y STATE4 generan un pulso sobre load2 para cargar ACC2 con el segundo operando. STATE4 inicia además el pulso sobre load1 y load3 para cargar ACC1 con el resultado de la operación y CCR con el Código de Condición.

STATE5 termina los pulsos sobre load1 y load3 y presenta el resultado en el exterior.

Las máquinas de estados que genera StateCAD son síncronas, por lo que el cambio de estado se produce al ritmo marcado por el reloj del sistema. Aquellas transiciones en las que no se indica condición alguna se producen en el ciclo de reloj siguiente. Aquellas otras en las que se indica una condición sólo se producen cuando la condición es cierta.

36




En esta práctica se entrega directamente al alumno todos los ficheros necesarios para el diseño de la calculadora con operaciones binarias salvo los correspondientes al diagrama de estados, el fichero VHDL generado a partir de éste y el fichero de restricciones.

TAREA 1

La primera tarea consistirá en la introducción del diagrama de estados, la generación del fichero VHDL con el código fuente de la máquina de estados y su inclusión en el diseño propuesto.

TAREA 2

Crear un tesbench para comprobar el funcionamiento del diseño con el simulador. Comprobar la operación XOR con los números A16 y F16 .

Tener en cuenta que, debido al mecanismo de funcionamiento de los circuitos antirrobote, los pulsos de la señal confirm deben durar al menos tres ciclos de reloj y que se deben dejar pasar otros tantos después del pulso para que el circuito vuelva al estado inicial.

TAREA 3

Modificar la máquina de estados para permitir la realización de operaciones unarias. Se trata de evitar el estado STATE3 cuando se detecte un operador unario como NOT o NEG.

EUITI - MADRID DEPARTAMENTO ELAI · Diseño de la máquina de estados finitos ... En este...

Documents

Transcript of EUITI - MADRID DEPARTAMENTO ELAI · Diseño de la máquina de estados finitos ... En este...