Implementación Básica de Procesador de Propósito Didáctico para

UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Electrónica
Implementación Básica de Procesador de Propósito Didáctico para
cursos básicos de Organización y Arquitectura del Computador
Por
Luis Ernesto Black Martínez
Sartenejas, Septiembre 2008
UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Electrónica
Implementación Básica de Procesador de Propósito Didáctico para
cursos básicos de Organización y Arquitectura del Computador
Por
Luis Ernesto Black Martínez
Realizado con la Asesoría de
Prof. Osberth de Castro
PROYECTO DE GRADO
Presentado ante la Ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de Ingeniero Electrónico
Sartenejas, Septiembre 2008
UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Electrónica
Implementación Básica de Procesador de Propósito Didáctico para
cursos básicos de Organización y Arquitectura del Computador
PROYECTO DE GRADO presentado por
Luis Ernesto Black Martínez
REALIZADO CON LA ASESORIA DE Prof. Osberth de Castro
RESUMEN
Debido a la necesidad de mejorar la experiencia práctica de los estudiantes en el aprendizaje de la
Organización y Arquitectura de Computadores en las carreras de Ingeniería en Electrónica, se
implementó un procesador de propósito didáctico en hardware, que permite el estudio de su
comportamiento y diseño sin muchas de las desventajas presentes en simuladores por software,
herramienta típica de enseñanza en las carreras de computación, y las de más amplia difusión.
En el desarrollo del proyecto se lograron implementar 2 sistemas de procesador didáctico, por lo
cual se presenta la oportunidad de tener 2 herramientas educativas que pueden ser utilizadas en
diferentes etapas de enseñanza de los temas estudiados en los cursos correspondientes. Estas
herramientas poseen tanto el hardware con el procesador y la lógica de comunicación, control y
monitoreo, junto con una interfaz gráfica de visualización en software, que muestra la información
adquirida al usuario.
Además, el proyecto permitió evaluar la flexibilidad de las plataformas de hardware reconfigurable,
y la potencialidad del desarrollo de plataformas mediante el uso de los recursos disponibles en las
comunidades de desarrollo de código abierto de descripción de hardware.
PALABRAS CLAVE
Procesadores, Didáctico, FPGA, VHDL
Aprobado con mención:__________
Postulado para el premio:____________
Sartenejas, Septiembre 2008
Dedico este libro
A mis abuelos Vernon, América y Ernesto (Q.E.P.D)
Y especialmente mi abuelita Charo
A mis padres, por su incondicional apoyo
A Alifer, por empujarme a dedicarme y no distraerme de lo importante
A Maritza, Mary, Lila, Hernán y la Sra. Dilia (Q.E.P.D.) por el cariño y apoyo que me brindaron
A mi tía Belkys y mi tío Junior, por brindarme un hogar lejos del hogar
A mi familia, por el apoyo que me brindaron
A mis profesores, sobre sus hombros me apoyé para completar mi criterio ingenieril
i
Índice General
CAPITULO 1 INTRODUCCIÓN .............................................................................................................................. 1
CAPITULO 2 PLANTEAMIENTO DEL PROBLEMA .......................................................................................... 3
2.1.
2.2.
2.3.
2.4.
ANTECEDENTES Y JUSTIFICACIÓN.................................................................................................................. 3
OBJETIVOS GENERALES ................................................................................................................................. 4
OBJETIVOS ESPECÍFICOS ................................................................................................................................ 4
ALCANCES Y LIMITACIONES .......................................................................................................................... 5
CAPITULO 3 FUNDAMENTOS TEÓRICOS .......................................................................................................... 7
3.1.
MICRO-ARQUITECTURA Y ORGANIZACIÓN EN LA ENSEÑANZA ...................................................................... 7
3.1.1.
Arquitectura MIPS ............................................................................................................................. 12
3.2.
PLATAFORMA FPGA ................................................................................................................................... 14
3.3.
PROGRAMACIÓN PARA FPGA – LENGUAJES HDL ....................................................................................... 16
3.4.
COMUNICACIÓN MEDIANTE PUERTO SERIAL ............................................................................................... 17
3.5.
FENÓMENO DE REBOTE DE CONTACTOS ...................................................................................................... 18
3.6.
DESARROLLO DE APLICACIONES MEDIANTE NATIONAL INSTRUMENTS LABVIEW...................................... 19
CAPITULO 4 METODOLOGÍA DEL DISEÑO .................................................................................................... 23
CAPITULO 5 SISTEMAS DE PROCESADORES DIDÁCTICOS ...................................................................... 30
5.1.
DESCRIPCIÓN FUNCIONAL ........................................................................................................................... 30
5.2.
ELEMENTOS COMUNES ................................................................................................................................ 32
5.2.1.
Módulo UART .................................................................................................................................... 34
5.2.2.
Lógica Anti-Rebotes ........................................................................................................................... 34
5.2.3.
Lógica de Reloj .................................................................................................................................. 35
5.3.
SISTEMA MIPS-SINGLECYCLE .................................................................................................................... 36
5.3.1.
CPU MIPS .......................................................................................................................................... 36
5.3.2.
Lógica de Control y Monitoreo del CPU ........................................................................................... 42
5.3.3.
Aplicación GUI VI.............................................................................................................................. 45
5.4.
SISTEMA MIPS-PIPELINED .......................................................................................................................... 46
5.4.1.
CPU MIPS Pipelined ......................................................................................................................... 47
5.4.2.
Lógica de Control y Monitoreo del CPU Pipelined ........................................................................... 54
5.4.3.
Aplicación GUI VI.............................................................................................................................. 56
5.5.
HERRAMIENTAS DE DESARROLLO Y DEPURACIÓN....................................................................................... 57
CAPITULO 6 RESULTADOS Y ANÁLISIS DE RESULTADOS ........................................................................ 60
CAPITULO 7 CONCLUSIONES Y RECOMENDACIONES............................................................................... 62
7.1.
7.2.
7.3.
CONCLUSIÓN GENERAL ............................................................................................................................... 62
CONCLUSIONES TÉCNICAS ........................................................................................................................... 62
RECOMENDACIONES .................................................................................................................................... 62
CAPITULO 8 REFERENCIAS BIBLIOGRÁFICAS............................................................................................. 64
CAPITULO 9 BIBLIOGRAFÍA ............................................................................................................................... 66
CAPITULO 10 APÉNDICES .................................................................................................................................... 67
ii
Índice de Tablas y Figuras
FIGURA 1. ESQUEMA DE LA MICRO-ARQUITECTURA DEL PROCESADOR MIC-1................................................................ 8
FIGURA 2. SIMULADOR DEL PROCESADOR MIC-1: MIC1EMU ........................................................................................ 9
FIGURA 3. DIAGRAMA DE BLOQUES DEL MCU M68HC08 ........................................................................................... 10
FIGURA 4. AMBIENTE DE PROGRAMACIÓN WINIDE/IN-CIRCUIT SIMULATOR ............................................................... 11
FIGURA 5. AMBIENTE DE PROGRAMACIÓN CODEWARRIOR FOR HC08/HCS08 ............................................................. 12
FIGURA 6. DIAGRAMA GENERAL DE UN PROCESADOR MIPS ........................................................................................ 14
FIGURA 7. GRÁFICO DE OSCILOSCOPIO OBSERVANDO UN REBOTE DE INTERRUPTOR..................................................... 19
FIGURA 8. PANEL TRASERO DE UN VI ........................................................................................................................... 21
FIGURA 9. PANEL FRONTAL DE UN VI ........................................................................................................................... 21
FIGURA 10. ESQUEMA DE FASES DEL PROYECTO .......................................................................................................... 23
FIGURA 11. SISTEMAS DE PROCESADORES DIDÁCTICOS – ESQUEMA GENERAL ............................................................ 31
FIGURA 12. REPORTE DE IMPLEMENTACIÓN EN EL MODELO DISPONIBLE PARA LOS ESTUDIANTES ................................ 33
FIGURA 13. TRAMAS DE RELOJ UTILIZADAS EN LOS SISTEMAS MIPS ........................................................................... 35
FIGURA 14. ESQUEMA GENERAL DE HARDWARE: SISTEMA MIPS-SINGLECYCLE ......................................................... 36
FIGURA 15. ESQUEMÁTICO: CPU MIPS-SINGLECYCLE ................................................................................................ 37
FIGURA 16. DIAGRAMA DE ESTADOS LÓGICA DE CONTROL Y MONITOREO – SISTEMA MIPS - SINGLECYCLE ............. 43
FIGURA 17. TRAMA DE ENVÍO DE DATOS – SISTEMA MIPS-SINGLECYCLE .................................................................. 44
FIGURA 18. SIMULACIÓN MIPS-SINGLECYCLE: PROCEDIMIENTO DE INICIALIZACIÓN ................................................. 44
FIGURA 19. INTERFAZ GRÁFICA DE USUARIO – MIPS-SINGLECYCLE ........................................................................... 45
FIGURA 20. ESQUEMA GENERAL DE HARDWARE: SISTEMA MIPS-PIPELINED................................................................ 46
FIGURA 21. ESQUEMÁTICO: CPU MIPS - PIPELINED ..................................................................................................... 48
FIGURA 22. DIAGRAMA DE ESTADOS DE LÓGICA DE CONTROL Y MONITOREO – SISTEMA MIPS-PIPELINED................ 54
FIGURA 23. TRAMA DE ENVÍO DE DATOS – SISTEMA MIPS-PIPELINED ........................................................................ 55
FIGURA 24. INTERFAZ GRÁFICA DE USUARIO – SISTEMA MIPS-PIPELINED .................................................................. 56
FIGURA 25. MUESTRA DE RESULTADOS DE SIMULACIÓN: MODELSIM .......................................................................... 57
FIGURA 26. CAPTURA DE REALTERM: SISTEMA MIPS-SINGLECYCLE .......................................................................... 58
FIGURA 27. CAPTURA DE REALTERM: SISTEMA MIPS-PIPELINED ................................................................................ 59
iii
Lista de Símbolos y Abreviaturas
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ALU: Arithmetic-Logic Unit – Unidad Lógico-Aritmética
Bit: Binary Unit - Unidad binária
Byte: Conjunto de 8-bit
CISC: Complex Instruction Set Computing – Computación de Conjunto de Instrucciones
Complejo
CPU: Central Processing Unit – Unidad de Procesamiento Central
DLX: Arquitectura basada en RISC de propósitos académicos
FIFO: First-In, First-Out – Primero en llegar, primero en salir
FP: Floating Point – Punto Flotante
FPGA: Field-Programmable Gate Array – Arreglo de Compuertas Programable en Campo
GUI: Graphical User Interface – Interfaz Gráfica de Usuario
HDL: Hardware Description Language – Lenguaje de Descripción de Hardware
IEEE: Institute of Electrical and Electronics Engineers – Instituto de Ingenieros Eléctricos y
Electrónicos
IJVM: Integrated Java Virtual Machine – Maquina Virtual de Java Integrada
JTAG: Joint Test Action Group – Grupo de Acción de Pruebas en Conjunto
LabVIEW: Laboratory Virtual Instrumentation Engineering Workbench – Mesa de trabajo
de laboratorio de ingeniería de instrumentación virtual
LED: Light-Emitting Diode – Diodo Emisor de Luz
MAL: Micro-Assembly Language – Lenguaje Micro-Ensamblador
MHz: Megahercio - Unidad equivalente a 1000 Hercios.
MIC-#: Arquitectura de propósitos académicos
MIPS: Microprocessor without Interlocked Pipeline Stages – Microprocesador con etapas de
cauce segmentado sin inter-bloqueos
Ns: Nanosegundo – Unidad equivalente a 0,000000001segundos
Pipelined: Cauce Segmentado – Operación em múltiples ciclos.
POWER: Performance Optimization with Enhanced RISC – Optimización de desempeño
con RISC mejorado
RAM: Random Access Memory – Memoria de Acceso Aleatorio
RISC: Reduced Instruction Set Computing – Computación de Conjunto de Instrucciones
Reducido
RS-232: Recommended Standard 232 – Estándar Recomendado 232. Estándar de
comunicación binaria
SingleCycle: Ciclo Sencillo o único.
SPARC: Scalable Processor Architecture – Arquitectura de Procesador Escalable
UART: Universal Asynchronous Receiver/Transmitter – Receptor/Transmisor Universal
Asíncrono
USB: Universal Serial Bus – Bus Serial Universal
Verilog : Verify Logic – Verificación de Lógica
iv
•
•
•
•
•
VGA: Video Graphics Array – Arreglo de Gráficos y Video
VHDL: VHSIC Hardware Description Language – Lenguaje de Descripción de Hardware
VHSIC
VHSIC: Very-High-Speed Integrated Circuits – Circuitos Integrados de Muy Alta Velocidad
VI: Virtual Instrument – Instrumento Virtual
X86: Arquitectura Dominante de Computadores Personales (Intel, AMD)
CAPITULO 1
INTRODUCCIÓN
La implementación de un procesador con propósitos didácticos encierra como proyecto
muchos y variados elementos que controlar, de manera que el producto final sea útil para la
formación de nuevos ingenieros, y permitir potenciar la capacidad de aprendizaje de los
temas cubiertos en los cursos de Organización y Arquitectura del Computador.
Actualmente, los cursos de Organización y Arquitectura del Computador se dictan
principalmente como materias teóricas que cuentan con tiempo de laboratorio incluido como
complemento. Para el trabajo práctico de éstos, se realizan actividades de programación tanto
en simuladores como en dispositivos de hardware como son los micro-controladores, que no
permiten gran estudio a nivel de micro-arquitectura del sus procesadores. Aun así, el contacto
que tienen los estudiantes con procesadores y arquitecturas a nivel de circuitos es únicamente
el provisto por los simuladores, así como las investigaciones superficiales que ellos puedan
realizar sobre éstas.
El principal problema de los simuladores radica en que, a pesar que es posible simular el
comportamiento de una arquitectura mediante software, es difícil modelarla para cubrir todos
los casos posibles, por lo cual éstos incurren en errores que inducen conflictos para
comprender el funcionamiento del dispositivo. Dichos errores no son debido a fallas
estructurales de los simuladores en sí mismos, sino son a raíz del enfoque que se le da a su
uso, que es para el estudio de arquitecturas, más no el estudio de micro-arquitecturas.
El propósito de este proyecto es proveer de una plataforma física, no simulada, con la
implementación de un procesador típico real, que permita experiencia a nivel de circuitos con
el dispositivo, enfocado más al nivel de micro-arquitectura que requieren los cursos de
Organización y Arquitectura del computador de la carrera de Ingeniería Electrónica de la
Universidad Simón Bolívar.
Se busca implementar en hardware un procesador simplificado, así como los elementos
necesarios para su monitoreo y control. De esta manera, este dispositivo puede ser utilizado
como herramienta educativa para el estudio a nivel de micro-arquitectura de un procesador
típico real.
2
Esta herramienta, cuya principal interacción con el usuario es vía un computador con un
programa de interfaz gráfica, comunicándose con el dispositivo implementado en una tarjeta
FPGA. Esta contiene los elementos de hardware, que consisten en el procesador en sí, la
unidad de control y monitoreo, la lógica de comunicación, y la lógica de interacción física
con el usuario.
Con el fin de lograr una herramienta flexible pero sencilla, se trabajó sobre los elementos
compositivos del sistema, de manera que éstos presentaran la mayor cantidad de información
disponible. De esta forma, encontramos que las fuentes que son código se encuentran
comentadas, y el dispositivo está implementado en alto nivel de forma esquemática.
Así, encontramos que se desarrollaron 2 implementaciones de procesador didáctico, donde
una se deriva de la otra. Dichas implementaciones poseen un juego completo de herramientas,
permitiendo el estudio a nivel de micro-arquitectura de dos formas distintas de ejecutar
instrucciones en un procesador típico real, abriendo las puertas al análisis comparativo entre
ellos. Estos procesadores implementan la operación SingleCycle (Ciclo Sencillo) y Pipelined
(Cauce Segmentado Multi-ciclo) de una simplificación de la arquitectura MIPS.
El presente libro se estructura a partir de éste, en los capítulos de Planteamiento del
Problema, que entra en detalle en los antecedentes, objetivos y limitaciones de este proyecto;
Fundamentos Teóricos, que contiene un recorrido somero por los conceptos necesarios para el
desarrollo de este proyecto; Metodología del Diseño, que describe las fases del desarrollo de
este proyecto; Sistemas de Procesadores Didácticos, en el cual se describen los sistemas que
se desarrollaron durante el proyecto; Resultados y Análisis, donde se presentan los resultados
del proyecto, con su respectivo análisis; y las Conclusiones y Recomendaciones, donde se
indican las ideas finales del proyecto, así como sugerencias para la evolución del mismo.
CAPITULO 2
PLANTEAMIENTO DEL PROBLEMA
2.1. Antecedentes y Justificación
Actualmente, en los cursos de Organización y Arquitectura del Computador dictados en la
Universidad Simón Bolívar a estudiantes de Ingeniería Electrónica, se enfocan al estudio de
modelos teóricos desarrollados para de facilitar la comprensión general de los temas, y
posteriormente se estudia el comportamiento de arquitecturas como X86, POWER
(Performance Optimization with Enhanced RISC – Optimización de desempeño con RISC
mejorado), SPARC (Scalable Processor Architecture – Arquitectura de Procesador Escalable)
entre otras. En particular, se emplea la arquitectura MIC, descrita en la literatura de Andrew
Tanenbaum, como objeto de estudio para desarrollar el conocimiento de arquitectura del
computador, y luego se complementa estudiando las arquitecturas antes mencionadas.
Para complementar el aprendizaje en los temas estudiados, se emplean tanto herramientas
de software que permiten observar el comportamiento del MIC, como herramientas que
simulan el comportamiento de otras de las arquitecturas estudiadas, como es SPIM, MIDAS o
DLXide. Además, se entrena a los estudiantes en el uso de micro-controladores, en particular
basado en la familia HC08 de Freescale, lo cual permite realizar prácticas de programación
empleando dispositivos de software cuyo funcionamiento puede ser relacionado con la
arquitectura estudiada en la teoría.
A pesar que esta metodología permite a los estudiantes adquirir conocimientos del
funcionamiento de los procesadores en general, además de proporcionar experiencia práctica
en la programación y manejo de recursos de hardware en un dispositivo, la experiencia con
procesadores de filosofía RISC está limitada al manejo de los simuladores, a la información
que se ofrece en los cursos y las investigaciones superficiales que puedan hacer los
estudiantes. Y aunque la experiencia con los simuladores enriquece el conocimiento, no
permite analizar el comportamiento de los procesadores que representan a nivel de microarquitectura. Esto no se debe a una falla estructural intrínseca de los simuladores, sino a que
el enfoque que los creadores de dichas herramientas le dan a éstas, es para su uso en cursos
dirigidos a estudiantes de carreras de computación, enfoque compartido por la literatura que
4
se emplea en para dictar los cursos, donde el funcionamiento físico tiene menor prioridad que
el nivel de arquitectura global.
En la industria del diseño profesional de arquitecturas y procesadores, se están empleando
herramientas de hardware reconfigurable, como son los FPGA (Field Programmable Gate
Array – Arreglo de Compuertas Programables en Campo) para el diseño y prueba en caliente
de modelos futuros. Esto aplica para las aéreas de procesadores de propósito general, el
desarrollo acelerado de arquitecturas y dispositivos, siendo esto una manera de acortar los
ciclos de diseño y corrección. Para un ejemplo de sistemas de desarrollo, y el sistema final,
véase [1] [2] [3].
Dado que en las clases de Circuitos Digitales ya se hace uso de dichos dispositivos
reconfigurables, y debido a que se percibe la necesidad de herramientas más enfocadas a las
necesidades de la carrera de Ingeniería Electrónica de la Universidad Simón Bolívar, se desea
implementar un sistema didáctico de enseñanza práctica del funcionamiento de un procesador
típico real. De esta manera, es posible un contacto más cercano con procesadores de propósito
general reales y un estudio más enfocado al nivel de micro-arquitectura, empleando una
arquitectura MIPS (Microprocessor without Interlocked Pipeline Stages – Microprocesador
sin etapas bloqueadas entre sí en el cauce segmentado) básica cómo marco.
2.2. Objetivos Generales
Obtener un sistema de procesador didáctico basado en el modelo MIPS simplificado, que
permita la enseñanza básica de micro-arquitectura de computadores mediante el uso de una
implementación en hardware y una interfaz de usuario interactiva.
2.3. Objetivos Específicos
1. Adaptar una implementación
simplificada del
modelo MIPS
para su
funcionamiento en el chip FPGA Spartan-3 de Xilinx, en una tarjeta de desarrollo
preestablecida y disponible
5
2. Implementar controles básicos de operación normal del sistema MIPS en la tarjeta
de desarrollo del Spartan-3
3. Implementación de una interfaz de comunicación entre el sistema desarrollado en
la tarjeta y un computador (interfaz serial)
4. Implementación de una interfaz gráfica de visualización en un computador, que
permita la observación de señales, registros, etapas de ejecución entre otros
5. Estructuración y redacción de una documentación para el uso y modificación de
los componentes del sistema
2.4. Alcances y Limitaciones
Este proyecto abarca la implementación física del modelo MIPS simplificado, junto con los
elementos necesarios para que se pueda observar el comportamiento del mismo mediante una
interfaz, incluyendo lógica de control del procesador y lógica de comunicación de datos del
sistema.
Para el desarrollo del procesador, se contempla la posibilidad de utilizar una
implementación pre-existente, para ser adaptada a las necesidades del presente proyecto.
Junto con la implementación física del proyecto, se incluye la generación de una interfaz de
usuario en un computador, tal que se pueda interpretar la información que se envía desde la
tarjeta que contiene el sistema físico, y se pueda mostrar de manera comprensible y didáctica
a un usuario.
Como complemento a las implementaciones, se encuentra la documentación del sistema en
su totalidad, la documentación de usuario y la documentación técnica para futuras
modificaciones tanto de la implementación reconfigurable como de la interfaz de usuario.
Se tuvo en cuenta, que el propósito final del sistema en su totalidad es su implantación en
las clases de Organización y Arquitectura del Computador, para los estudiantes de Ingeniería
Electrónica de la Universidad Simón Bolívar. Esto implica el enfoque de micro-arquitectura,
así como las necesidades y recursos disponibles en el laboratorio para los estudiantes.
6
Por otra parte, el uso de herramientas de programación o de trabajo debe limitarse a
aquellas que posean un acuerdo de licencia abierta, o de compañías con las cuales la
Universidad posea acuerdos de licencia, de manera que su uso práctico en los laboratorios no
se vea empañado por problemáticas de índole legal.
CAPITULO 3
FUNDAMENTOS TEÓRICOS
Para el desarrollo de este proyecto, se emplearon conocimientos que abarcan varias de las
disciplinas de Ingeniería Electrónica. Primeramente, dado que se buscó realizar una
implementación en hardware de una arquitectura, fue necesario trabajar con dispositivos
reconfigurables y sus herramientas asociadas, de manera que fuese posible contar con una
plataforma de implementación física, pero como ya se indicó, modificable. Además, se
empleó una arquitectura con antecedentes de uso didáctico y bien documentada, de manera
que el proyecto no fuese una arquitectura nueva, sino que fuese un sistema más cercano a un
procesador típico de propósito general, por lo cual se estudió la implementación de un
procesador MIPS simplificado. Como complemento, se revisaron los posibles problemas de
rebotes en el uso de interruptores de botón (push switch), el uso de puerto serial para la
comunicación con un computador y el uso de la herramienta LabVIEW para el desarrollo de
un instrumento virtual que cumpla con la función de interfaz de usuario en un computador.
3.1. Micro-arquitectura y Organización en la Enseñanza
En los cursos de Organización y Arquitectura del Computador dictados a los estudiantes de
Ingeniería Electrónica de la Universidad Simón Bolívar, se observa una progresión en los
conceptos que se le imparten. Para la enseñanza básica del funcionamiento de un procesador,
se estudia una arquitectura CISC (Complex Instruction Set Computing – Computación de
Conjunto
de
Instrucciones
Complejo)
desarrollada
por
Andrew
S.
Tanenbaum
específicamente con el propósito de facilitar la enseñanza del tema, pero ésta está enfocada a
los estudiantes de carreras de computación.
La arquitectura MIC consiste en 3 procesadores, comenzando por un procesador CISC
micro-programado, al cual se le introducen mejoras al nivel de micro-arquitectura para
realizar un análisis comparativo del rendimiento del mismo a medida que se modifica. Está
basado en el conjunto de instrucciones IJVM (Integrated Java Virtual Machine – Máquina
Virtual de Java Integrada), que es compatible con el lenguaje de programación Java, y su
unidad de control es un bloque de memoria que posee rutinas paras las instrucciones IJVM, y
está programado en otro lenguaje, llamado MAL (Micro-Assembly Language – Lenguaje
8
Micro-Ensamblador). Como parte de los objetivos del curso, se estudia tanto el conjunto
IJVM como sus implementaciones internas en MAL, además de tomar como ejercicio para
los estudiantes el escribir instrucciones en MAL que puedan ser agregadas al conjunto preexistente de instrucciones.
Inicialmente, los estudiantes estudian el procesador MIC-1, que consiste en un procesador
sencillo de 32-bit, con las características descritas anteriormente. Un dato interesante es que
para el manejo de memoria de programa, el MIC-1 emplea una pila, por lo cual los
estudiantes deben siempre cuidar el uso de la misma para el funcionamiento correcto del
sistema. Seguidamente, se introduce el MIC-2, que posee una modificación en la microarquitectura de su antecesor en que permite mayor flexibilidad para las entradas de la ALU
(Arithmetic-Logic Unit – Unidad Lógico-Aritmética) del procesador, ya que el MIC-1 posee
1 bus libre de entrada a ésta, y su otro puerto de entrada solo puede ser accedido por un
registro, mientras que el MIC-2 posee 2 buses para acceder a la ALU. Finalmente, se muestra
el MIC-3, que agrega registros de almacenamiento a la entrada y la salida de la ALU,
efectivamente agregando 3 registros al sistema, asociados directamente a la ALU.
Figura 1. Esquema de la micro-arquitectura del procesador MIC-1
9
Durante el estudio de la arquitectura MIC, los estudiantes cuentan con herramientas de
simulación de la misma, dado que estos procesadores son parte de la teoría, y no se cuenta
con dispositivos de hardware que los representen. Estos programas permiten al estudiante
tener una guía para observar el comportamiento de la arquitectura, bien desde la
programación en lenguaje IJVM o en lenguaje MAL, con una interfaz gráfica que presenta la
micro-arquitectura y su comportamiento. Para esta familia de procesadores se hace
relativamente fácil la implementación de esta clase de software, dado que el enfoque de la
arquitectura es precisamente simplificar su simula
simulación.
ción. Para un estudio más profundo de la
familia MIC, véase [4].
Figura 2. Simulador del Procesador MIC-1: MIC1Emu
Una vez los estudiantes tienen un poco de experiencia manejando un procesador, se les
introduce como parte de la experiencia de laboratorio al uso de un micro-controlador, el cual
utilizan durante los cursos antes mencionados, pero que son el corazón de los proyectos que
los estudiantes deben realizar en cursos posteriores, en los cuales deben emplear muchas de
las destrezas adquiridas en el transcurso de su carrera, con énfasis en el manejo de éste
dispositivo.
10
Específicamente, se emplea un MCU M68HC08GP32A, que cuenta con un CPU (Central
Processing Unit – Unidad de Procesamiento Central) de la familia M68HC08 de 8-bit, 2
módulos contadores de 16-bit con capacidad de generar PWM, 1 modulo de conversión
analógico-digital de 8-bit de aproximaciones sucesivas, 1 contador de 8-bit general, un puerto
de 8-bit de teclado entre otros periféricos integrados. Para conocer con mayor detalle los
elementos del MCU, véase [5].
Figura 3. Diagrama de Bloques del MCU M68HC08
Inicialmente, los estudiantes aprenden la programación para este MCU utilizando lenguaje
ensamblador. Esto se hace con la intención que los estudiantes adquieran un conocimiento
integral de los registros de control del MCU, así como el comportamiento del mismo para
ejecutar las diferentes rutinas, interrupciones, y manejo de los periféricos integrados de éste.
Durante esta etapa del aprendizaje, se emplea un ambiente de programación llamado
WinIDE, desarrollado por P&E Micro, en el cual la programación se realiza en ensamblador
de HC08. Además incluye la posibilidad de ejecución de un programa que se quiera escribir
en el MCU, en modo de depuración, monitoreando directamente el dispositivo. Nótese que es
necesario contar con circuitería extra, que para los eestudiantes
studiantes usualmente es una tarjeta
11
básica de HC08 provista por el laboratorio en modo de préstamo, para lograr la funcionalidad
necesaria para el modo de depuración.
Figura 4. Ambiente de Programación WinIDE/In-circuit Simulator
A pesar que el manejo de lenguaje ensamblador descubre mucho del funcionamiento de
bajo nivel del MCU, es muy engorroso el desarrollo de proyectos de cierto nivel de
complejidad, ya que el manejo de los datos y periféricos puede hacerse bastante problemático.
Debido a esto, una vez los estudiantes logran realizar proyectos de cierta magnitud
programados en ensamblador, son introducidos a la herramienta CodeWarrior, desarrollada
en conjunto por Freescale y Metrowerks. Esta herramienta permite la programación de
proyectos en lenguaje C, simplificando la codificación. Además, incluye herramientas para la
configuración de los periféricos, de manera que el estudiante se concentre sólo en la
programación, evitando la manipulación directa de los registros de configuración. Para
proyectos de mayor nivel de complejidad, la herramienta ofrece un modo de programación
avanzado, en el cual no sólo se hace la configuración de los periféricos necesarios, sino que
también se generan rutinas básicas para su manipulación, junto con las interrupciones en caso
que éste cuente con ellas, y que sean así configuradas para su uso en el proyecto.
12
Figura 5. Ambiente de programación CodeWarrior for HC08/HCS08
3.1.1. Arquitectura MIPS
La arquitectura MIPS fue desarrollada a principio de la década de los años ’80 buscando
incrementar el rendimiento y desempeño de los microprocesadores mediante la
implementación de la filosofía de diseño RISC (Reduced Instruction Set Computing –
Computación de Conjunto de Instrucciones Reducido) y de otras ideas para mejorar la
capacidad de procesamiento de este diseño.
Desde entonces, se han hecho muchas evoluciones al diseño de la arquitectura,
encontrando finalmente que MIPS Technologies Inc., la compañía que creó la arquitectura,
logró un éxito importante a través de los años y decidió licenciar la arquitectura MIPS a
otras compañías para el desarrollo de productos. De esta manera encontramos que muchos
dispositivos embebidos, como son decodificadores de televisión, agendas electrónicas,
computadoras de mano y enrutadores de red tienen como motor principal de sus funciones
un núcleo derivado de un MIPS.
Dada esta fuerte presencia de mercado, y debido a que la arquitectura está basada en la
filosofía RISC, encontramos material didáctico que estudia y simula el comportamiento de
procesadores MIPS simplificados, de manera que es fácil observar el comportamiento del
mismo, mediante estas herramientas.
13
A pesar que existen diversas versiones del procesador MIPS, con extensiones específicas
para ciertas necesidades, así como versiones de funcionalidad reducida para cumplir otros
requisitos como alto nivel de integración y muy bajo consumo energético, en general
encontramos que los procesadores basados en la arquitectura MIPS comparten ciertas
características básicas. En primer lugar, encontramos 3 tipos de instrucciones: registro a
registro, registro valor inmediato y salto. Como puede observarse, las operaciones que
ejecuta el procesador son entre registros, y esta es la segunda característica de la
arquitectura. Las instrucciones con valor inmediato, y las instrucciones de salto usualmente
calculan una dirección de memoria para realizar lecturas o escrituras, o saltos en la
continuidad del programa. Una tercera característica es el uso de una página de registros,
donde se pueden direccionar individualmente y todos son iguales entre sí, con ciertas
excepciones como el registro de dirección 0, que usualmente está cableado al valor 0 y no se
puede escribir sobre él. El acceso a memoria, característica particular de ésta arquitectura, se
hace mediante procedimientos de carga o descarga, y usualmente no cuentan con modos de
acceso avanzado, como movimientos de memoria a memoria, o manejo de arreglos de datos,
lo cual le ganó a la arquitectura la fama de ineficiencia en ésta área en particular.
El propósito de la arquitectura en general es simplificar el conjunto de instrucciones lo
más posible, de manera que sea posible la implementación de pipelining tan profundo en el
camino de datos del procesador como sea posible. Así, se busca que cada etapa de
funcionamiento del procesador pueda operar tan rápido como sea posible. A pesar que el
simplificar la ejecución y eliminar instrucciones que pueden ser útiles puede parecer una
desventaja ante otras arquitecturas, junto con el numero de ciclos requerido desde que una
instrucción es leída desde la memoria de instrucciones, hasta que el resultado de dicha
instrucción se escribe nuevamente en su destino correspondiente, en la práctica dicha
desventaja no se presenta como tal.
La combinación de hardware operando a mayor frecuencia, junto con un conjunto de
instrucciones sencillas que se ajustan con mayor facilidad a la mayoría de las cargas de los
programas en general, permite a la arquitectura MIPS gozar de un muy buen rendimiento,
sin necesidad de optimizaciones agresivas por parte de compiladores complejos para extraer
el máximo rendimiento, como ocurre en otras arquitecturas.
14
Figura 6. Diagrama General de un procesador MIPS
La simplificación de la arquitectura de 32-bit del MIPS pasa por la reducción del conjunto
de instrucciones, la simplificación de las ALU y la eliminación del procesamiento de FP
(Floating-Point – Punto Flotante). Encontramos que dicha simplificación conlleva a que el
conjunto de instrucciones disponibles para el desarrollo en cuestión se vea reducido a 7, de
las cuales tenemos 4 operaciones entre registros, 2 operaciones de memoria y 1 operación de
salto.
De esta manera tenemos el MIPS de 32-bit, manejando un conjunto de instrucciones
reducido, en el cual es posible alcanzar un rendimiento de 1 ciclo por instrucción. Para
mayor referencia respecto a la arquitectura MIPS, así ccomo
omo sus desarrollos, y su uso para la
enseñanza, véase [6] [7].
3.2. Plataforma FPGA
El uso de hardware reconfigurable como plataforma para el desarrollo del proyecto se debe
a la premisa de una implementación real, y no un simulador de una arquitectura conocida.
Esto permite que el proyecto pueda trabajar bajo condiciones no necesariamente previstas en
el momento del desarrollo del sistema, y que éste continúe operando de la manera que el
hardware dicta. Así, a diferencia que un simulador, no existe una condición de operación
15
“forzada” mediante correcciones especiales, sino que se puede observar cómo se resuelve
prácticamente cualquier condición que pueda ser ejecutada por el conjunto de instrucciones
implementado en el sistema.
La tecnología de hardware reconfigurable está representada en la actualidad por distintas
propuestas, siendo el de mayor crecimiento y popularidad la de los sistemas de arreglos de
compuertas programables en campo, mejor conocidos como FPGA por sus siglas en inglés.
Como su nombre lo indica, estos dispositivos cuentan con un arreglo interno de compuertas
cuya interconexión puede ser modificada para representar el comportamiento de lógica
electrónica, como pueden ser sistemas muy simples con compuertas digitales como AND u
OR, hasta diseños más complejos con elementos de memoria, flip-flops, multiplexores,
decodificadores o funciones matemáticas. Usualmente, la lógica programable está contenida
dentro de un chip, el cual suele estar montado en una tarjeta de desarrollo que permite hacer
interfaz con las patillas (pines) del FPGA mediante diferentes accesos, como son interfaces
seriales, interfaces de video VGA (Video Graphics Array – Arreglo de Gráficos y Video)
entre otras dependiendo de la tarjeta seleccionada. Aunque lo más usual es el empleo de los
FPGA para el desarrollo de dispositivos, también es posible encontrarlos como parte de un
diseño completo, como se puede observar en [8]. Escapa el enfoque de este proyecto un
estudio profundo del funcionamiento de los FPGA (véase [9]), así como el estado del arte
(véase [10]) de ésta tecnología.
Existen varios fabricantes de sistemas FPGA, tanto de los chips en sí mismos, como tarjetas
de desarrollo de diferentes niveles de integración y complejidad, buscando cubrir desde las
necesidades simples de diseño, a las necesidades profesionales de validación de productos.
Normalmente, los fabricantes de los sistemas proveen un ambiente de programación para sus
soluciones, y en estas se cubren todos los aspectos de la programación de éstas, desde la
creación de las fuentes que pueda manejar, esquemáticas o de código HDL (Hardware
Description Language – Lenguaje de Descripción de Hardware), hasta los pasos subsiguientes
que le correspondan a cada sistema, como son la asignación de contactos, la ubicación y la
asignación de caminos (routing) del diseño en cuestión, y la programación final en el FPGA.
Aunque las capacidades intrínsecas de los FPGA no cambian en términos generales entre los
distintos fabricantes, lo que cambia son las opciones tanto de los sistemas de desarrollo
(integración de sistemas en un chip, interfaces avanzadas, mayor densidad de compuertas por
16
dispositivo, entre otras) como el comportamiento y características del
ambiente de
programación (software).
3.3. Programación para FPGA – Lenguajes HDL
Para el desarrollo de diseños en FPGA, generalmente se pueden tomar 2 enfoques, aunque
esto depende totalmente del ambiente de desarrollo con el cual se cuente: realizar el diseño
mediante esquemáticos, en los cuales los elementos son todos conectados de la misma manera
como se haría en un programa de diseño de circuitos eléctricos o digitales, o se puede diseñar
empleando algún HDL. Aunque las opciones de cada ambiente de diseño para FPGA varían,
es usual encontrar en todos ellos la opción de manejar proyectos cuyas fuentes son híbridas,
es decir, el software es capaz de manejar tanto esquemáticos como fuentes codificadas en
HDL. Todas las fuentes del diseño son luego verificadas, procesadas y, en caso de los
ambientes completos de desarrollo de proyectos, preparados para ser finalmente programados
en el FPGA.
Existen 2 lenguajes
HDL como estándares industriales utilizados para el diseño de
proyectos, que son Verilog (Verify Logic – Verificar Lógica) y VHDL (VHSIC Hardware
Description Language – Lenguaje de Descripción de Hardware VHSIC), y ambos pueden ser
empleados para la creación de fuentes para dispositivos FPGA, siempre que el ambiente de
programación así lo permita. Estos lenguajes no son fundamentalmente disímiles, y muchas
de las características de uno son replicadas en el otro. Aunque la sintaxis de ambos es similar
a la sintaxis de lenguaje C, cada uno implementa una manera distinta de manejar la
descripción de hardware, pero la mayoría de los diseños pueden ser desarrollados tanto en
VHDL como en Verilog. No entra dentro de los alcances de este proyecto el presentar una
comparación de las capacidades de ambos lenguajes [11] o un estudio profundo de la
trayectoria de ambos lenguajes [12] [13]. Es necesario acotar, sin embargo, que la selección
de lenguaje de descripción de hardware dentro de un proyecto tendrá como limitante principal
las capacidades del ambiente de diseño con el cual se cuente para el desarrollo del mismo, ya
que si este no es capaz de manejar alguno de los lenguajes, entonces el desarrollador se verá
forzado a emplear bien el otro lenguaje, o modificar el enfoque de diseño del sistema en
cuestión, en el caso de no ser posible el cambiar el ambiente de programación. Pero no todo
con respecto a los ambientes de programación es negativo, dado que a medida que se ha
popularizado el uso de FPGA para el diseño, se ha extendido la programación en HDL y a
17
crecido la comunidad de desarrolladores, han aparecido librerías de diseño, tanto de fuente
abierta como propietarias y de propiedad intelectual que puede ser usado bajo licencia del
autor, que facilitan el trabajo de los diseñadores al proveerlos con implementaciones de
diversos dispositivos de uso general, como son ALU’s optimizadas, transmisores/receptores
de puerto serial, entre otras, que terminan permitiéndole enfocarse en su diseño más que en
los periféricos de éste. Por otra parte, dado que los lenguajes HDL son controlados por
cuerpos colegiados, que una vez encuentran los puntos a los cuales es necesario actualizar
cualquiera de los lenguajes, los envían a la IEEE (Institute of Electrical and Electronics
Engineers – Instituto de Ingenieros Eléctricos y Electrónicos)para que estos sean discutidos y
convertidos en estándar IEEE oficial, de manera que el desarrollo de los lenguajes sea
uniforme, y además evitar que se desarrollen de manera desordenada variantes similares, pero
de sintaxis diferente, de un mismo lenguaje. Esto ha permitido la existencia de plantillas, un
formato de código que los ambientes de programación siempre reconocen como un tipo
específico de hardware, para simplificar la programación en HDL, y para mejorar el
rendimiento de la etapa de síntesis de los proyectos HDL, bien sea en Verilog o VHDL.
3.4. Comunicación mediante Puerto Serial
La comunicación con un computador mediante el uso de un puerto serial es una de las vías
más sencillas de hacer interfaz con un dispositivo, dado que no es necesario el agregar ningún
software especial para poder ver lo que se está transmitiendo. A pesar que existen buses de
mayor velocidad disponibles para hacer interfaz con un computador, la parte de hardware
muchas veces no se encuentra disponible, o su costo es mucho mayor para los dispositivos de
hardware que usualmente se construyen de forma artesanal, es decir, cuando manualmente se
construye un circuito o dispositivo. Además, las tarjetas de desarrollo que usualmente se
emplean en el laboratorio para el manejo de varios dispositivos cuentan con un puerto serial,
junto con la circuitería necesaria para conectar los dispositivos al puerto, por lo cual el uso de
este bus de comunicación de baja velocidad es una manera sencilla de conectarse a un
computador. Es necesario conocer un poco de las opciones más simples que ofrece el puerto
de comunicaciones serial para entender fácilmente su operación.
Principalmente, es importante destacar que la comunicación serial transmite un bit a la vez,
por lo cual la tasa de datos en bits por segundo es igual a la tasa de símbolos, medida en
baudios. Aun así, es importante destacar que la tasa efectiva de datos está sujeta a la
18
configuración del puerto, ya que la velocidad incluye todos los bits que envía el puerto,
incluidos los de control que estén en uso. Aunque la especificación RS-232-C (Recommended
Standard 232 – Estándar Recomendado 232) especifica que la velocidad máxima de conexión
es de 20000 baudios, o bits por segundo para este puerto en particular, los puertos en la
actualidad pueden ser configurados en velocidades mayores, aunque esta configuración no
siempre significa que la conexión se pueda conseguir. Además, para lograr la comunicación
se deben configurar en el puerto la cantidad de bits, el uso de paridad, control de flujo y el
número de bits de parada del puerto.
Tanto el transmisor como el receptor deben tener una configuración idéntica para lograr
una comunicación correcta. La tasa de datos efectiva del puerto dependerá del uso de paridad
y bits de parada, dado que ambas opciones agregan bits a la transmisión, aumentando el total
de bits enviados por el puerto. Para la visualización de los datos una vez establecida la
conexión, es necesario capturar la información del puerto en cuestión. Es posible ver los datos
del puerto mediante un software de terminal de comunicación que pueda acceder el puerto,
como son HyperTerminal o RealTerm. Estos programas permiten configurar y capturar la
información de un puerto serial, y observar los caracteres que por ellos se reciben, con la
posibilidad de enviar caracteres por éstos. Esta es una manera interesante de verificar la
comunicación por el puerto, y puede emplearse para manejo sencillo de datos.
En caso que se desee manejar el puerto serial fuera de un programa terminal, usualmente se
debe hacer interfaz con los controladores del sistema operativo que manejan el puerto, por lo
cual es necesario emplear un programa que se comunique con el sistema operativo. Para
mayor detalle en el uso de puerto de comunicación serial, véase [14].
3.5. Fenómeno de Rebote de Contactos
En el trabajo con elementos electrónicos discretos, es importante considerar el
comportamiento físico de dicho elemento, de manera que ante un problema en el momento de
la operación, se pueda utilizar la información para rastrear las fuentes del fallo. Un ejemplo
de dispositivo cuyo comportamiento mecánico pudiese interferir en la operación de un
sistema es el Push-Button Switch (interruptor de botón). El principio de funcionamiento de un
interruptor de este tipo, en el caso de un botón de cerrado al accionar, es precisamente ése.
Estos dispositivos se pueden encontrar tanto en modalidad normalmente abierto (NO por sus
19
siglas en inglés) o normalmente cerrados (NC por sus siglas en inglés). El interruptor, al estar
colocado en un circuito, se comporta como un circuito abierto, y al accionarlo (presionarlo
como indica su nombre) se cierra y se comporta como un cable en caso ideal (véase [15]).
Durante la operación de estos dispositivos, es posible que, por las características de los
mismos, no sea posible obtener un flanco limpio a partir de su accionamiento, lo que podría
causar errores de operación en un circuito, en particular en los circuitos digitales que los
empleen como medio de entrada.
Figura 7. Gráfico de Osciloscopio observando un rebote de interruptor
Como se puede observar, es necesario tomar acciones correctivas para que las
características mecánicas del sistema no afecten su operación. Para resolver este problema, se
pueden tomar diferentes medidas, que muchas veces dependen de la naturaleza del trabajo
que se esté realizando. Las soluciones pueden ser desde abrir el circuito y físicamente
modificarlo, que podría modificar sus características ligeramente, como la utilización de
circuitos de filtrado o de accionamiento retardado, o de ser posible, una solución
implementada totalmente en software, al hacer revisión rápida del interruptor para verificar
que no se esté dentro de la condición de rebote [16].
3.6. Desarrollo de aplicaciones mediante National Instruments LabVIEW
Existen muchas herramientas que permiten la programación de software, tanto de la lógica
como de la interfaz de usuario del mismo, en caso de necesitarla. Estas pueden ser desde
herramientas muy sencillas con poco nivel de integración entre sus diferentes elementos,
20
como conjuntos completos de herramientas con gran nivel de integración y sofisticación. Una
de las herramientas que se ha destacado por la posibilidad de manejar tanto la interfaz gráfica
como el comportamiento en sí del programa es LabVIEW (Laboratory Virtual
Instrumentation Engineering Workbench – Mesa de trabajo de laboratorio de ingeniería de
instrumentación virtual), de la compañía National Instruments. El enfoque de esta
herramienta apunta más al trabajo con sistemas de adquisición de señales y del procesamiento
de dichas señales, para su posterior monitoreo, por lo cual se encuentra integrado dentro de
esta herramienta un amplio soporte para el manejo de dispositivos externos al computador. El
uso de LabVIEW se ha popularizado en las áreas de adquisición de datos, control
instrumental y automatización industrial, y National Instruments promueve su uso en
ambientes académicos.
A diferencia del uso de un ambiente de programación, en el cual para poder utilizar
dispositivos del computador muchas veces es necesario tener una rutina de negociación con el
sistema operativo a través del controlador del mismo, lo cual agrega un nivel de complejidad
al proyecto para el manejo de la entrada/salida requerida por éste, LabVIEW integra la
negociación dentro de las funciones del ambiente, por lo cual manejar alguno de los puertos
del computador, así como el manejo de herramientas de adquisición de datos más avanzadas,
se puede realizar de manera fácil, sin necesidad de entrar en las profundidades del manejo de
hardware directamente en el proyecto.
La programación dentro de LabVIEW se maneja de forma esquemática, en la cual mediante
el uso de cajas y líneas conectoras, se elabora el programa, que dentro del ambiente se les
llama VI (Virtual Instrument – Instrumento Virtual). Un VI cuenta con 2 partes principales: el
panel frontal, que es la interfaz con la cual interactúa el usuario, y el panel trasero, que es el
área en la cual se emplea el esquemático para programar la funcionalidad del mismo. Dada la
orientación de instrumentación del ambiente, el panel frontal muchas veces se asemeja a un
panel de instrumentación industrial, debido al uso de controles en forma de perillas,
interruptores, controles deslizantes, indicadores luminosos estilo LED (Light Emitting Diode
– Diodo Emisor de Luz) así como indicadores numéricos y textuales.
21
Figura 8. Panel Trasero de un VI
Figura 9. Panel Frontal de un VI
22
Para la programación de los VI, se sigue un esquema de flujo de datos, en el cual, cada
cajita, o nodo, está conectada con las demás por medio de líneas, que sirven como
transmisores de datos, donde cada uno de estas líneas tiene definido un tipo de dato
especifico, de manera que sea más fácil diferenciar los datos que se están manejando. De esta
forma, el VI realiza las operaciones sobre los datos de manera secuencial, iniciando la
ejecución con los elementos que estén más a la izquierda primero y progresando hacia la
derecha en el orden que estén los nodos. Además, existe un segundo “orden” de ejecución, de
arriba abajo, en caso de no ser posible ejecutar en paralelo las funciones de los nodos que
estén alineados verticalmente, así encontramos maneras de realizar operaciones en paralelo
para conjuntos de datos distintos, y secuenciales para un conjunto de datos, en caso que sea
necesario procesarlos para alcanzar el estado deseado de los mismos. Muchas veces es
necesario procesar los datos de forma tal que su presentación al usuario sea más adecuada.
Aparte de los nodos que incluye el ambiente de programación, tanto para el procesamiento de
datos como para la presentación de los mismos en el panel, es posible usar librerías de
funciones como en otros lenguajes y ambientes de programación, además de tener la
posibilidad de generar subVI, que no son más que una agrupación de una cantidad de nodos
para re-utilizarlos dentro de otro de mayor tamaño, como podría ser necesario al tener varios
conjuntos de datos simultáneos a los cuales se le deba realizar la misma secuencia de
operaciones para presentarlos al usuario. A pesar que es posible preparar los VI de manera
que puedan ser utilizados sin necesidad de instalar el ambiente LabVIEW completo, las
librerías necesarias para que éstos puedan utilizarse por su cuenta no suelen incluirse con los
sistemas operativos soportados por National Instruments (Linux, Windows, OS X), por lo
cual es necesario instalar un paquete de librerías en tiempo de ejecución (run-time) que
soporte la versión del ambiente de programación en el cual fue creado el VI. Para mayor
información sobre LabVIEW, véase [17] [18].
CAPITULO 4
METODOLOGÍA DEL DISEÑO
El desarrollo del proyecto puede ser desglosado en fases, en las cuales el enfoque era
completar parte del trabajo que era necesario para fundamentar el desarrollo de las etapas
subsiguientes.
Figura 10. Esquema de Fases del Proyecto
24
Fase 1: Investigación y Documentación
•
Se realizó una investigación buscando la existencia de proyectos similares en otras
universidades o institutos politécnicos.
•
La investigación se llevó a cabo mediante el uso de internet, principalmente fuera de
la Universidad.
•
El uso de referencias de internet para algunos tópicos, el acceso restringido a la
información de algunas universidades.
•
Para el momento de la investigación, se encontró que los proyectos similares se
encuentra como parte de cursos similares a los dictados en la Universidad, con la
execpcion que se encuentran orientados a estudiantes de carreras de computación.
En particular, en el sitio web del Georgia Institute of Technology se encontró el
código fuente para la implementación simulada de un MIPS simplificado. Dado que
las fuentes son en VHDL, se tomaron como marco para trabajar sobre las mismas.
Fase 2: Selección de herramientas y familiarización con los sistemas
•
Búsqueda, selección y familiarización con los dispositivos de hardware y ambientes
de programación necesarios para el desarrollo del proyecto.
•
Mediante la investigación entre los recursos del Laboratorio de Electrónica, los
recursos a la disposición del Tutor y los recursos disponibles para los estudiantes de
la Universidad Simón Bolívar.
•
La experiencia muy baja para el trabajo con herramientas de codificación HDL,
comportamiento errático del ambiente FPGA, requerimientos no expresados para el
correcto funcionamiento del software, la obtención de licencias necesarias para el
uso de las herramientas hicieron que esta etapa tomase más tiempo del previsto.
•
Se obtuvo la tarjeta de desarrollo Digilent, basada en un chip FPGA Spartan-3 de
Xilinx, que es una versión superior a la empleada por los estudiantes en el
Laboratorio de Circuitos Digitales. Como ambiente de desarrollo del FPGA se
obtuvo el Xilinx ISE Webpack 9.1i, que posee licencia de uso gratuito con
25
registrarse en el sitio de la compañía, ya que este posee soporte para el dispositivo
de hardware seleccionado y, y es capaz de procesar diversas fuentes, entre las que
está el diseño esquemático, fuentes VHDL y fuentes Verilog.
Para la validación de los modelos, así como para la simulación de los sistemas
desarrollados, se seleccionó ModelSim, la versión provista por Xilinx, ya que la
licencia para su uso con el ambiente Xilinx es gratuita y porque es el software que
se emplea en la práctica original de las fuentes seleccionadas. Para el desarrollo de
las interfaces de usuario se seleccionó LabVIEW de National Instruments, debido a
la amplia experiencia desarrollando aplicaciones en éste ambiente, la disponibilidad
del laboratorio de licencias para su uso, y la integración del manejo de puertos
periféricos en un computador, en particular del puerto serial.
Fase 3: Implementación de Fuentes MIPS en el FPGA
•
Implementación de fuentes del procesador MIPS en la tarjeta FPGA. Dichas fuentes
se encontraron en la Práctica de Laboratorio 2, del curso de Arquitectura del
Computador y Sistemas Operativos del Prof. Hsien-Hsin Lee, de Georgia Institute
of Technology.
•
Mediante el uso de las herramientas ModelSim, Xilinx ISE Webpack 9.1i, se
implementaron las fuentes en el FPGA, y se simuló el comportamiento de las
fuentes VHDL
•
Dificultades inicialmente para la simulación de las fuentes, problemas para la
asignación de las salidas del dispositivo FPGA.
•
Se estudió el comportamiento del procesador en ModelSim, luego se llevaron las
fuentes para su implementación dentro del dispositivo FPGA. Sin embargo, se
observó que el procesador no responde favorablemente ante lógica de control
sencilla.
Fase 4: Modificación de Fuentes MIPS a diseño esquemático
•
Se modificaron las fuentes del procesador, de manera que estuviese representado de
forma esquemática.
26
•
Mediante el uso de ISE Webpack 9.1i, se generaron símbolos de cada uno de los
elementos compositivos del procesador. Una vez el modelo esquemático del
procesador está finalizado, se simuló su comportamiento en ModelSim, para
verificar su comportamiento con el diseño original.
•
La conversión del procesador completo a un diseño esquemático requirió la
generación de elementos adicionales, para manejar la separación de las señales
como requieren las unidades compositivas de éste, la necesidad de modificar el
código de las unidades funcionales, para adaptar las porciones netamente de
simulación a código traducible a hardware.
•
Se obtuvo una implementación del procesador en forma esquemática, que se
comporta análogamente a las fuentes originales.
Fase 5:.Implementacion y Desarrollo de Lógica de Comunicaciones, Control y Monitoreo
MIPS – SingleCycle
•
Se desarrolló e implementó una unidad de control y monitoreo para el procesador,
además de implementar un módulo de comunicaciones serial, que se agregó al
sistema.
•
Utilizando ISE Webpack 9.1i, se desarrolló la unidad de control y monitoreo,
modelada empleando una máquina de estados. Además, se agregó un módulo de
comunicación serial utilizando la herramienta antes mencionada.
•
El desarrollo de la unidad de control tomó mayor tiempo del previsto, dado que
inicialmente no se intentó trabajar con una máquina de estados.
•
Se implementó una máquina de estados como lógica de control y monitoreo del
procesador. Ésta opera a una frecuencia superior al procesador, se encarga de los
procedimientos necesarios para la inicialización del mismo, y recibe las señales
monitoreadas de éste, les da formato de trama serial y las envía al módulo de
comunicaciones seriales del sistema, cuidando enviarlos con un retardo entre byte y
byte para no saturarlo. El módulo de comunicaciones serial consiste en una
implementación
disponible
gratuitamente
en
la
red,
que
posee
un
transmisor/receptor UART (Universal Asynchronous Receiver-Transmitter –
27
Receptor-Transmisor Universal Asíncrono) que debe operar a 50MHz y transmite a
115200bps los datos por el puerto serial, por lo cual éste es compatible con el
proyecto y fue integrado a éste.
Fase 6: Desarrollo de la Interfaz Gráfica del Modelo MIPS – SingleCycle
•
Programación de una interfaz gráfica de usuario para la fácil observación del
funcionamiento del sistema.
•
Mediante el entorno LabVIEW para el desarrollo de la aplicación, y RealTerm
como herramienta de depuración de la comunicación.
•
Problemas de operación del envío de los datos, por cuestiones de manejo de
memoria, sincronía de los datos en la Interfaz de Usuario.
•
Se desarrolló una intrfaz en el computador, dependiente del entorno LabVIEW, en
la cual se puede observar el funcionamiento del sistema, así como controlar la
velocidad de operación del procesador, permitiendo la detención y continuación de
la ejecución de instrucciones.
Fase 7: Desarrollo e Implementación del modelo MIPS-Pipelined
•
Extensión del procesador MIPS para implementar una versión de cauce
segmentado.
•
Siguiendo la teoría contenida en el capítulo 6 de [19], empleando ISE Webpack
9.1i como plataforma de desarrollo y ModelSim como herramienta de simulación
y validación de las modificaciones introducidas.
•
Elevado nivel de complejidad del diseño esquemático, necesidad de desarrollar
lógica para el manejo de algunos buses de datos sin formar parte directamente de
las unidades del cauce segmentado, problemas internos de sincronía de señales,
detalles en el proceso de síntesis e implementación de las fuentes en el ambiente
ISE Webpack 9.1i, que requieren atención sobre las opciones activas para estos
procesos.
28
•
Se obtuvo una implementación de un procesador MIPS con cauce segmentado de
datos a partir del primer sistema, bautizando éste desarrollo MIPS-Pipelined.
Fase 8: Desarrollo Sistema de Lógica de Control y Monitoreo MIPS – Pipelined
•
Adecuación de la lógica de control para las necesidades del sistema MIPSPipelined.
•
Se utilizó ISE Webpack 9.1i para las modificaciones a la estructura de la lógica de
control y monitoreo, ModelSim para la simulación del comportamiento.
•
Dificultades en las pruebas funcionales dada la gran cantidad de datos que se
manejan, detalles en la sincronización del envío de los datos al módulo de
comunicación serial UART, número importante de estados internos de la nueva
unidad de control hace engorrosa la corrección de errores en ésta.
•
Se implementó una lógica de control adaptada a las necesidades del procesador
modificado.
Fase 9: Desarrollo de la Interfaz Gráfica del modelo MIPS – Pipelined
•
Desarrollo de una Interfaz Gráfica de usuario para el modelo MIPS – Pipelined,
análoga a la ya existente para el modelo MIPS - Single Cicle.
•
Ambiente LabVIEW para desarrollo, ModelSim para la validación, Xilinx ISE para
la implementación y RealTerm para pruebas de puerto serial.
•
Problemas en la implementación del Transmisor/Receptor en el ambiente
LabVIEW, manejo de datos en el sistema MIPS – Pipelined, problemas en las
convenciones de decodificación de datos por parte de las funciones de conversión.
•
Se obtuvo una Interfaz Gráfica de usuario en la cual se puede ver el comportamiento
del procesador MIPS-Pipelined a medida que ejecuta las instrucciones. Esta puede
cambiar la velocidad de operación, así como detener y reanudar la ejecución de
instrucciones.
Fase 10: Estudio de Optimizaciones al Modelo MIPS – Pipelined
29
•
Exploración de las optimizaciones de rendimiento disponibles para el modelo MIPS
– Pipelined.
•
Documentación de las mejoras, Xilinx ISE, ModelSim y LabVIEW para la
implementación, validación y observación en la Interfaz Gráfica de usuario de las
optimizaciones estudiadas.
•
Niveles de complejidad del modelo MIPS - Pipelined sin optimizar, tiempo de
desarrollo de las optimizaciones individuales.
•
Se logró implementar en su totalidad el forwarding (adelantamiento de información)
en el modelo MIPS - Pipelined, se hicieron estudios y avances en las optimizaciones
a la instrucción de salto (branch) y a una unidad de predicción de saltos (branchprediction). Se modificó la Interfaz Gráfica de usuario para acomodar la
información de la optimización por forwarding.
.
CAPITULO 5
SISTEMAS DE PROCESADORES DIDÁCTICOS
Este proyecto generó 2 sistemas, así como las bases para el desarrollo de otros basados en
los actuales. Se generaron 2 dispositivos que pueden ser empleados como herramientas
didácticas para los cursos de Organización y Arquitectura del Computador, de la carrera de
Ingeniería Electrónica de la Universidad Simón Bolívar.
Debido a que estos sistemas fueron desarrollados de forma concurrente, y que uno de éstos
es la evolución natural del otro, ambos comparten muchos de sus elementos constituyentes,
así como la plataforma sobre la cual trabajan.
Los sistemas implementados se denominan MIPS-SingleCycle y el MIPS-Pipelined,
encontrándose su principal diferenciación en las características del procesador. Los elementos
que son diferentes entre los sistemas son el CPU y la lógica de control y monitoreo de cada
uno de éstos. El procesador se desarrolló a partir de las fuentes del Prof. Lee de GeorgiaTech,
pero se implementó de manera esquemática. Luego, se le agregaron las estructuras necesarias
para alcanzar la operación con un Pipeline (Cauce Segmentado de Datos).
El grueso del trabajo realizado reside en la lógica que acompaña al CPU, que fue necesaria
para lograr el funcionamiento de éste en primera instancia, además de ser el responsable de
ordenar los datos que se extraen de él, de manera que puedan ser enviados y visualizados en
la interfaz gráfica correspondiente. Además, se implementó el transmisor UART, que es
común en ambos sistemas, así como la lógica de reloj y anti-rebotes, que habilitan la
interacción manual con el sistema además de la interacción desde el computador.
5.1. Descripción Funcional
El sistema consiste de un dispositivo de hardware, en la forma de una tarjeta FPGA, a la
cual se le programa uno de los proyectos MIPS y luego se conecta a un computador vía
puerto serial. En éste, se ejecuta la interfaz gráfica correspondiente y se verifica la
configuración del puerto serial de manera que la tarjeta FPGA esté conectada al puerto
seleccionado en la interfaz gráfica.
31
Figura 11. Sistemas de Procesadores Didácticos – Esquema General
Al iniciar el funcionamiento del sistema, se activa la ejecución de instrucciones en la
interfaz gráfica de usuario y comienza la recepción de información, que es presentada en la
ésta. Mediante el uso de los controles en la interfaz gráfica, es posible acelerar y reducir la
velocidad de ejecución, además de poder detener y reanudar la ejecución totalmente. Para
reiniciar desde el principio la operación del sistema, es necesario pulsar un botón en la tarjeta
de desarrollo, mientras el reloj de operación del procesador está en funcionamiento. Esto
ocasiona que todos los registros de funcionamiento, así como la lógica de control del sistema
regresen a un estado inicial de funcionamiento, similar a cuando éste se inicia por primera
vez.
Se debe tomar en consideración que el procedimiento para programar alguno de los
proyectos en la tarjeta FPGA es independiente de la operación del sistema, utiliza la interfaz
JTAG (Joint Test Action Group – Grupo de Acción de Pruebas en Conjunto) que puede usar
la interfaz de puerto paralelo o de puerto USB (Universal Serial Bus – Bus Serial Universal) y
el sistema sale de operación cuando se realiza la programación. Se recomienda que se detenga
la operación previamente, de manera que no se detenga el funcionamiento de la interfaz
gráfica de usuario con errores.
Entre las capacidades de los sistemas tenemos:
•
Monitoreo del funcionamiento del CPU.
•
Variación de la velocidad de ejecución de las instrucciones.
•
Posibilidad de detener y reanudar la ejecución.
•
Restablecimiento del sistema a un estado inicial presionando un botón en la tarjeta
de desarrollo.
32
•
Activación de un (1) ciclo de reloj del procesador mediante accionamiento de un
botón en la tarjeta de desarrollo.
•
Operación asíncrona del CPU y el resto de la lógica del sistema.
Las limitantes de los sistemas son:
•
El código a ejecutar debe ser modificado en la fuente VHDL de la unidad funcional
IFETCH en formato hexadecimal.
•
El sistema no puede ser restablecido desde la interfaz gráfica de usuario.
•
No cuenta con la posibilidad de controlar la ejecución de forma dependiente de las
instrucciones, como ejecutar hasta la instrucción N, o ejecutar sólo N instrucciones.
•
El funcionamiento sin la interfaz gráfica de usuario se limita al monitoreo del puerto
serial mediante programas terminales, como RealTerm o HyperTerminal.
•
La automatización de la ejecución depende de la automatización del envío de las
señales de control correspondientes por puerto serial, no existe automatización sin
su uso.
5.2. Elementos Comunes
En primera aproximación, ambos sistemas requieren de los mismos elementos generales,
que son la tarjeta de desarrollo FPGA basada en un chip Spartan3 y de un computador que
cuente con una interfaz serial RS-232 UART.
El computador debe exceder, como mínimo, las especificaciones mínimas necesarias para
la ejecución del ambiente de desarrollo National Instruments LabVIEW, de manera que sea
posible ejecutar en ella las herramientas VI desarrolladas como GUI (Graphical User
Interface – Interfaz Gráfica de Usuario) para su uso con su sistema correspondiente. El
software GUI en cuestión, es diferente para cada sistema por lo cual será desarrollado en la
sección correspondiente.
La tarjeta de desarrollo Digilent Spartan3-1000 es uno de los modelos de una familia de
tarjetas que comercializa la dicha empresa. Los recursos disponibles en ésta son varios, pero
los que nos interesan debido a su uso dentro del proyecto son: interfaz serial RS-232 UART,
33
oscilador integrado, indicadores LED y switches de botón. El dispositivo FPGA integrado en
esta tarjeta es un Xilinx Spartan-3 modelo XC3S1000-FT256, que cuenta con un millón de
compuertas para la implementación de diseños
diseños.. Aún así, el diseño más complejo no excede el
21% de utilización de las compuertas disponibles para el diseño, lo cual se traduce a 41096
compuertas equivalentes para la implementación del diseño. Dado que las tarjetas de
desarrollo disponibles para los estudiante
estudiantess cuentan con menores recursos, se revisó la
posibilidad de implementar el diseño que más recursos necesita, en uno de los chips
disponibles para los estudiantes, y se encontró que el diseño cabe mediante el uso de
optimizaciones de área al sistema.
Figura 12. Reporte de Implementación en el modelo disponibl
disponiblee para los estudiantes
Los elementos que constituyen el diseño de cada sistema pueden ser enumerados como el
Módulo UART, la Lógica Anti-Rebotes, la Lógica de Reloj, el CPU MIPS y la lógica de
Control y Monitoreo del CPU. Para ambos sistemas, los primeros 3 elementos son comunes,
por lo cual se describen a continuación.
34
5.2.1. Módulo UART
Consiste en un módulo que se encarga de tomar los datos en forma de bytes que recibe
de la lógica del sistema, y los envía vía comunicación serial a cualquier dispositivo que
pueda recibirlos.
El módulo cuenta con 4 entradas y 4 salidas, que podemos enumerar como 2 pines de
transmisión/recepción, dos pines de estado del puerto UART y los puertos de
entrada/salida de datos, que son de tamaño 8-bit. Completan las entradas el pin de entrada
de reloj del módulo y finalmente la señal de control de transmisión de datos, que debe
estar en nivel activo para que éstos se transmitan. Internamente, se cuenta con una
memoria de transmisión (buffer) ordenada 16x8, por lo cual se cuenta con 16 bytes de
almacenamiento para el envío o recepción de información. Este buffer opera bajo la
modalidad FIFO (First-in First-Out – Primero en llegar, primero en salir), también
conocido como cola, por lo cual los datos no pierden su secuencia al entrar o salir del
mismo.
Él opera usando la frecuencia del oscilador de la tarjeta, es decir 50MHz, a partir de la
cual deriva su velocidad de transmisión de 115200bps. Además, la transmisión está
configurada como 8-bit de datos, sin paridad y 1-bit de parada, por lo cual alcanzamos una
tasa efectiva de transmisión de datos de 11520 bytes por segundo, tomando
aproximadamente 86,81µs para enviar 1 byte.
Como herramienta de diagnostico, durante el desarrollo y depuración de los sistemas, se
empleó la señal de estado del UART que indica problemas de transmisión por saturación
de la memoria, en un indicador LED de la tarjeta de desarrollo, de forma que fuese
posible descartar la conexión serial como la fuente de problemas en los mismos. La señal
de estado que indica presencia de datos recibidos por el módulo serial se dejó sin
conectar, ya que no aportaba mayor funcionalidad.
5.2.2. Lógica Anti-Rebotes
Consiste en dos estructuras idénticas, que miden la duración, en ciclos del reloj interno
del sistema, que la señal conectada a su entrada mantiene un nivel lógico determinado, en
este caso nivel alto, para corroborar que no es un rebote sino una transición válida.
35
Dado que existen 2 señales que pueden ser accionadas mediante el uso de un switch de
la tarjeta de desarrollo, cada un
unaa de éstas está conectada a la lógica, de manera que se le
eliminen los rebotes mecánicos.
Dado que el reloj interno tiene un periodo bastante corto, de 20ns, se modificó la lógica
de manera que el periodo de muestreo fuese más cercano al orden de tiempo en el cual
ocurren los rebotes, establecido alrededor de 20µs. Este tiempo se tomó debido a que,
aunque sigue siendo más rápido que los reflejos de los seres humanos, permite corregir el
problema del rebote de los switches.
5.2.3. Lógica de Reloj
El sistema cuenta internamente con dos (2) señales de reloj que alimentan las unidades
que lo componen. Internamente, se cuenta con un oscilador que genera una señal de
50MHz, que se utiliza para toda la lógica excepto el CPU, cuya señal de reloj se genera a
partir de lógica combinatoria.
La señal de reloj del CPU se origina de una compuerta OR, que puede ser activada
desde un switch de la tarjeta FPGA, o desde la interfaz gráfica de usuario mediante una
trama de reloj del CPU.
Para accionar el reloj del CPU desde la GUI, el procedimiento comienza en la tarjeta en
el momento que recibe una trama de control. Este byte se envía a una unidad que lo
decodifica, y en caso que ésta así lo indique, activa o desactiva la señal de reloj del CPU,
que se conecta a la compuerta OR. Las tramas empleadas para ésta operación se presentan
a continuación:
Figura 13. Tramas de Reloj utilizadas en los Sistemas MIPS
36
La generación por switch consiste principalmente de una señal, que se activa al
accionarlo. Esta señal llega a la lógica anti-rebotes, y de ser válida, continúa a la
compuerta OR, para luego activar el CPU.
5.3. Sistema MIPS-SingleCycle
Este sistema implementa el procesador MIPS simplificado, convertido de fuente totalmente
codificada a fuente esquemática, cuya operación está controlada por una máquina de estados
que realiza los procedimientos necesarios para la inicialización del CPU, así como las tareas
de monitoreo de las variables que serán enviadas a la aplicación GUI en el computador vía la
lógica de comunicaciones.
Figura 14. Esquema general de hardware: Sistema MIPS-SingleCycle
Este sistema incluye todos los elementos compartidos ya descritos en el presente capitulo, y
sus elementos diferenciadores, tanto en hardware como en software, son: el CPU, la lógica de
control, y la aplicación VI correspondiente.
5.3.1. CPU MIPS
Es una implementación simplificada de la arquitectura MIPS, en la cual, las unidades
funcionales se encuentran ag
agrupadas
rupadas por las etapas que existen para la ejecución de
instrucciones dentro de la arquitectura. Éste funciona en una modalidad, en la cual las
instrucciones se ejecutan todas en 1 ciclo del reloj, por lo cual se le denomina
SingleCycle. Fue desarrollado een
n el Georgia Institute of Technology como parte del curso
37
de Arquitectura del Computador y Sistemas Operativos dictado por el Prof. Hsien-Hsin
Lee. El enfoque de las asignaciones de laboratorio de este curso es el manejo de la
herramienta ModelSim, para me
mediante
diante programación VHDL realizar simulaciones de la
arquitectura MIPS.
Dado que el enfoque de éste proyecto es la implementación en físico, con énfasis en la
operación de hardware por encima de la simulación, fue necesario realizar modificaciones
en las fuentes originales, y así lograr el desarrollo deseado. La idea fue, convertir las
estructuras del MIPS, tal que el CPU funcionase de forma esquemática. Así, sería posible
manejar más simplemente las unidades funcionales, y permite una representación gráfica
de éste al momento de manejar las fuentes. Además, para los estudiantes es más natural y
accesible el manejo de esquemáticos que el manejo de código para representar hardware.
Primeramente, se tomó el código original y se separó, de manera que pudiese generarse
un esquemático, lo cual conllevó la creación de otras unidades para preservar en lo posible
las unidades funcionales, sin modificar la estructura general de las mismas. El trabajar el
CPU de forma esquemática no es un requisito del proyecto, pero se consideró un valor
agregado al mismo, aportando al objetivo de utilizarlo como herramienta didáctica por las
razones antes expuestas.
Figura 15. Esquemático: CPU MIPS-SingleCycle
En general, el CPU cuenta con 2 entradas y 10 salidas como unidad monolítica, y está
compuesto por 8 unidades funcionales, cuyo esquemático puede ser estudiado con mayor
38
detalle en el Apéndice 1. Este maneja 3 tipos de instrucciones: Lógico-Aritméticas, que
trabajan sobre el contenido de 2 registros y cuyo resultado se escribe nuevamente a un
registro; de Referencia a Memoria, que leen o escriben a la memoria de datos; y las
Ramificaciones consisten en un salto en la continuidad del programa si las condiciones de
igualdad se cumplen. A continuación se describen las unidades funcionales, tanto
originales como agregadas.
5.3.1.1.
IFETCH
La unidad IFETCH encierra la primera etapa de la ejecución de una instrucción en la
arquitectura MIPS, que consiste en buscar una instrucción para que sea ejecutada. Las
instrucciones se almacenan en una memoria de instrucciones, y ésta se direcciona
mediante un contador, que se incrementa para progresar por la secuencia de
instrucciones de un programa.
Esta unidad cuenta con 5 entradas y 3 salidas, de las cuales 2 son salidas también de la
unidad monolítica del CPU. En ésta se engloba la memoria de instrucciones y la lógica
de PC (Program Counter – Contador de Programa) que permite la progresión por el
programa que se encuentra dentro de la memoria de instrucciones, así como el manejo
de saltos o ramificaciones en el mismo.
Durante su operación, el sistema toma el PC para extraer de la memoria la instrucción
correspondiente, lo incrementa y verifica la existencia de las condiciones para una
ramificación o salto en la continuidad del programa. En caso de haber un salto, el
próximo PC a decodificar no será el previamente incrementado, sino uno recibido por
ésta unidad a partir de un cálculo externo.
De esta unidad se monitorean, externas al CPU, tanto la instrucción buscada, que es
una señal de 32-bit (4-byte), y la dirección de PC actual, que es una señal de 10-bit.
Además, esta unidad también envía la dirección del próximo PC, que es la adición de
PC+4 direcciones. De esta manera, esta señal se puede utilizar en la etapa
correspondiente para el cálculo de la dirección de salto.
39
5.3.1.2.
IDECODE
La unidad IDECODE representa la etapa en la cual se toma la instrucción buscada
por IFETCH, y se le decodifica, dependiendo de su tipo, para permitir la lectura y
escritura de los registros indicados, o para generar la extensión de signo necesaria para
calcular una dirección de memoria.
Ésta cuenta con 8 entradas y 3 salidas, de las cuales 2 son monitoreadas fuera del
CPU. En ella encontramos la página de 32 registros del CPU, y se encarga de colocar a
su salida los datos de aquellos que se vean involucrados y la extensión de signo.
Internamente, se maneja la escritura a registro tal que, en caso de haber una lectura de un
dato desde la RAM, o de haber una operación, el resultado se almacene donde
corresponde.
Encontramos en esta unidad un diseño que permite que, durante un ciclo, las
operaciones de escritura a la página de registros tengan precedencia sobre la lectura,
permitiendo trabajar sobre el resultado más actualizado.
Las señales de salida son los datos de los registros que solicite la instrucción, que son
monitoreados externamente al CPU, y la extensión de signo calculada por la unidad,
señales todas de 4-bytes (32-bit). Cabe destacar que el valor inicial de cada registro es su
número de identificación, por lo cual el contenido del registro 1 es 1, del registro 2 es 2,
etc. Es importante recordar que el registro 0 es un 0 forzoso, como lo indica la
arquitectura MIPS, y no puede ser modificado.
5.3.1.3.
EXECUTE
La unidad EXECUTE representa la etapa en la cual se realizan las operaciones del
procesador, así como el cálculo de la dirección de memoria RAM y de la dirección de
PC necesaria en caso de haber un salto en la continuidad de la ejecución del programa,
en la forma de una ramificación.
Esta unidad cuenta con 9 entradas y 3 salidas, de las cuales 2 están monitoreadas
externamente del módulo monolítico del CPU. Dentro de ésta, encontramos 2 unidades
aritméticas, un sumador y una ALU, entre las cuales se manejan las operaciones lógicas
y aritméticas del CPU.
40
El sumador se encarga de las adiciones necesarias para el cálculo de las direcciones
correspondientes a una ramificación, enviando el resultado a la unidad IFETCH donde
se resuelve finalmente la existencia o no del salto de continuidad del programa. La ALU
se encarga de realizar las operaciones de suma, resta, AND lógico y OR lógico sobre los
datos que la instrucción indique. Internamente, dependiendo de la activación o no de
ciertas señales de control, se seleccionan los datos sobre los cuales opera la ALU, bien
sea para generar una dirección de memoria, o para realizar una operación sobre éstos.
A la salida de esta unidad encontramos el resultado del sumador, el resultado de la
operación de la ALU, y una bandera que se activa cuando el resultado de la operación es
cero, siendo estas últimas las señales monitoreadas externamente.
5.3.1.4.
DMEMORY
La unidad DMEMORY cumple la función de la memoria de datos a la cual acede el
CPU. En ella, se almacenan datos con los cuales trabaja el procesador, y representa un
medio de almacenamiento de mayor capacidad, y menor velocidad de acceso, que los
registros. Para nuestro sistema en particular, esta unidad no representa realmente mayor
capacidad con respecto a la que ofrecen los registros, pero si representa un medio de
almacenamiento de menor velocidad de acceso.
Esta unidad cuenta con 6 entradas y 1 salida. Implementa internamente una memoria
RAM (Random Access Memory – Memoria de Acceso Aleatorio) distribuida como
32x8-bit, que implica en 32 bytes de capacidad, permitiendo almacenar 8 palabras de
32-bit (8x4 bytes). Dado que el MIPS no permite maneja direcciones de memoria en las
instrucciones, éste las calcula basado en el contenido de un registro al cual se le suma un
valor inmediato.
Durante su operación, se activan las banderas de lectura o escritura, seguidamente la
unidad, empleando la dirección que recibe, pasa a extraer o escribir la palabra de 4 bytes
correspondientes a la dirección. Cabe destacar, que para la extracción de palabras de la
RAM, existe un retardo desde el ciclo en que se acciona para la lectura y disponibilidad
de los datos a la salida de la unidad, que es aproximadamente el flanco de bajada del
siguiente ciclo del reloj al cual se solicitó.
41
La señal de salida de la unidad son los datos leídos de la RAM. En caso de haber una
escritura, no se modifica la salida de la unidad, por lo cual se mantiene la última señal.
De esta unidad solo se monitorea la información que se le escribe, que procede de la
ALU.
5.3.1.5.
CONTROL
La unidad CONTROL genera las señales que permiten el funcionamiento correcto del
CPU, indicando efectivamente a las unidades funcionales que tareas deben realizar para
que la instrucción presente se ejecute sin problemas.
Esta unidad posee 3 entradas y 8 salidas, de las cuales se monitorean 3 señales
externamente al CPU monolítico. Encontramos que se generan las banderas de control
de las otras unidades, y estas se generan a partir de los 6-bit más significativos de la
instrucción.
Durante su operación, se generan las señales de control de IDECODE, EXECUTE y
MEMORY, junto con la señal de salto, que junto con la señal cero, se utilizan para
determinar si existe o no un salto en la continuidad de la ejecución del programa.
Dependiendo del tipo de instrucción, se activan las lecturas de memoria, la escritura de
registros, los destinos de los datos y controla parte de la operación de EXECUTE.
Las señales de salida son principalmente binarias, y se monitorean las que indican
escritura de registro, escritura de memoria y ramificación de la ejecución de
instrucciones. Las señales no monitoreadas son las que controlan el registro de destino
para la escritura, la fuente de la una de las entradas de la ALU, la bandera que indica una
operación de memoria a registro, la bandera que activa la lectura desde RAM, y el
operando de 2-bit para la ALU.
5.3.1.6.
Decodificador de Instrucción
Esta unidad fue agregada para proveer a las unidades CONTROL y EXECUTE con
las partes de la instrucción que requieren sin necesidad de modificar los puertos de
entrada de las estas. Cuenta con 1 entrada y 2 salidas.
42
Durante su operación, de la entrada que es la instrucción, separa los bits que necesita
cada unidad, que son los 6-bit más significativos para CONTROL, y los 6-bit menos
significativos para EXECUTE.
Esta unidad no tiene monitoreo, ya que fue agregada al diseño para facilitar la
implementación esquemática del CPU con un mínimo de modificaciones a las unidades
principales.
5.3.1.7.
Decodificador de Dirección de RAM
Esta unidad básicamente se encarga de decodificar la dirección a la cual se va a leer o
escribir en la RAM. Ésta se realiza a partir de la señal de salida de la ALU, y fue
necesaria para no modificar las fuentes de las otras unidades funcionales y lograr la
implementación esquemática del CPU. Cuenta con 1 entrada y 1 salida, y sus señales no
se monitorean externamente.
5.3.1.8.
Separador de Bus de Datos a la RAM
Esta unidad cuenta con 1 entrada y 1 salida, y solo cumple la función de separar el bus
de entrada de los datos a ser escritos en la RAM, de manera que pueda ser monitoreado
por separado de su señal de origen, que es la salida de datos del segundo registro de la
unidad IDECODE. Esta unidad se agregó para hacer posible la implementación
esquemática del CPU con las mismas señales de monitoreo que se encuentran en las
fuentes originales.
5.3.2. Lógica de Control y Monitoreo del CPU
Esta unidad consiste en una máquina de estados, que se encarga del monitoreo de las
señales extraídas del CPU, así como de manejar el restablecimiento y la inicialización del
CPU para su operación correcta.
Encontramos 13 entradas y 3 salidas en esta unidad, de las cuales 10 son las señales
monitoreadas del CPU (174-bit) y las otras 3 son el reloj interno del FPGA, el reloj generado
para el CPU y la señal de restablecimiento (reset) del sistema.
43
Figura 16. Diagrama de Estados Lógica de Control y Monitoreo – Sistema MIPS - SingleCycle
El funcionamiento de la máquina de estados, cuyo diagrama puede ser consultado en detalle
en el Apéndice 2, trabaja como un monitor de alta velocidad. La frecuencia de operación es
de 50MHz, y verifica las señales de salida y el reloj del CPU, de manera que los datos que se
lean sean los correspondientes al ciclo monitoreado. Una vez leídos los datos, estos se
estructuran en una trama, que puede verse en la Figura 16, que seguidamente se envía al
módulo UART. Para este envío, se implemento un retardo para cada byte generado por la
unidad de control, que inicialmente se calculó en aproximadamente 70µs. Ante un cálculo
posterior, tomando en cuenta el comportamiento de la unidad UART bajo la configuración
actual, se encontró que por cada byte enviado se envían 10-bit, 1-bit de inicio, 8-bit de datos y
1-bit de parada, por lo cual, el retardo por byt
bytee no puede ser calculado en base a los bits que
componen un dato, sino como los bits que debe enviar el sistema para enviarlo, y se modificó
el retardo para cumplir con este nuevo valor, que es aproximadamente 87µs.
44
Figura 17. Trama de Envío de Datos – Sistema MIPS-SingleCycle
La secuencia de inicialización del procesador comienza tan pronto como se inicia señal del
reloj del CPU. Entonces, la unidad de control envía una señal de reset al CPU, ya que éste
necesita que esta señal se cicle para operar correctamente. En el siguiente ciclo, se desactiva
la señal de reset y comienza el monitoreo de las variables del CPU. Esto puede ser visto en
detalle en las simulaciones de ejecución del sistema.
Figura 18. Simulación MIPS-SingleCycle: Procedimiento de Inicialización
Una vez culmina la inicialización del CPU, esta unidad comienza el procedimiento de
monitoreo de los datos para su posterior envío. En primera instancia, se espera que exista un
nivel lógico alto, momento en el cual la máquina de est
estados
ados cambiará al siguiente. Una vez
comprobado el reloj en alto, la máquina de estados espera al flanco de bajada del reloj, tal que
los datos que estén disponibles a la salida del CPU sean actuales
actuales.. Seguidamente, el sistema
inicia una secuencia de estados en la cual, para todos los bytes que debe enviar, primero
45
verifica que la unidad esta activa, comparando los valores leídos del CPU con los
almacenados, operación que se realiza para enviar una señal que indique la actividad de la
unidad. Una vez verificado esto, se inicia la transmisión de los datos recibidos, byte a byte,
con el retardo especificado anteriormente para cada uno de ellos. Los datos de cada unidad se
envían por separado, y para cada una de ellas deben repetir el procedimiento de verificación
de actividad. Además, todos los estados verifican que la señal de reloj no ha cambiado del
nivel lógico bajo, y en caso contrario regresan al estado de espera por flanco de bajada.
Para controlar el envío de cada dato, se cuenta con una señal que activa o desactiva la
transmisión del módulo UART. De esta manera, es posible dosificar el flujo de datos tal que
se eviten problemas de saturación de la interfaz serial.
5.3.3. Aplicación GUI VI
La aplicación de la interfaz gráfica de usuario para el modelo MIPS-SingleCycle, consiste
en un sistema de transmisión y recepción de datos por puerto serial, desarrollada a partir de
un ejemplo avanzado contenido entre el material de entrenamiento del ambiente de
programación LabVIEW.
Figura 19. Interfaz Gráfica de Usuario – MIPS-SingleCycle
46
En esta, se pueden configurar todos los parámetros del puerto, y es posible controlar el
periodo de operación del CPU, así como detenerlo completamente. La interfaz muestra, de
manera muy simple, el contenido de cada una de las variables monitoreadas del CPU, así
como el estado de actividad o inactividad de las unidades funcionales. Además, se muestra el
número total de bytes recibidos desde el dispositivo, y la trama completa, como medida de
comprobación de los datos observados.
Internamente, el VI recibe los 48 bytes de la trama y los decodifica, de manera que recupera
los datos de ésta y los organiza para ser obser
observados
vados en la GUI. Seguidamente, se encarga de
formatear los datos, de manera que lo que se muestre al usuario sea en formato hexadecimal.
5.4. Sistema MIPS-Pipelined
El desarrollo del sistema Pipelined se origino a partir de la revisión de la literatura de la
arquitectura MIPS. En ésta, se encontró que la implementación del sistema MIPSSingleCycle podía ser desarrollada para obtener un procesador con cauce segmentado así
como con optimizaciones de operación.
Figura 20. Esquema general de hardware: Sistema MIPS-Pipelined
El trabajo sobre el sistema MIPS-SingleCycle se enfocó en la implementación de las
modificaciones contenidas en la literatura (Véase [19]) dentro de la implementación
47
esquemática que se realizó en el primer sistema. Como resultado, fue necesario agregar lógica
al CPU, así como la modificación de las fuentes originales para acomodar las nuevas señales
del modelo Pipelined.
Cabe destacar que las optimizaciones que se le realizaron al sistema, solo incluyen el
forwarding de datos, ya que la operación con cauce segmentado dicta que se incluya una
unidad de detección de problemas en éste, que se encarga de introducir las burbujas entre las
instrucciones para su correcta ejecución. El esquemático de este sistema completo puede ser
consultado en el Apéndice 1.
El enfoque de esta sección serán las modificaciones realizadas al sistema para obtener el
modelo Pipelined con forwarding. Se revisarán las modificaciones realizadas a las unidades
existentes, y se observaran por completo las nuevas unidades añadidas al sistema para lograr
la funcionalidad deseada. Además, se simplificó la Lógica de Control y Monitoreo de Datos,
dado que ésta unidad ya no debe hacer tantas comprobaciones sobre los datos monitoreados, y
se encarga más de la estructuración y codificación de la trama de comunicación con la
aplicación VI.
En el campo de software, la aplicación debió ser modificada acordemente para acomodar
los cambios que se realizaron al par CPU-Lógica de Control, además del incremento en la
cantidad de datos que se envían desde el sistema a la interfaz gráfica de usuario.
5.4.1. CPU MIPS Pipelined
A un procesador se le llama Pipelined cuando sus unidades funcionales son capaces de
trabajar de forma independiente entre sí. De esta manera, es posible implementar otras
optimizaciones al sistema como un todo y permite mejorar el desempeño de éste, así como
permitir la implementación de mejoras internas al mismo desde el punto de vista de sus
capacidades.
La principal característica de un procesador Pipelined es el cauce segmentado, que no es
más que la separación de sus unidades funcionales, reduciendo la cantidad de trabajo que éste
realiza por ciclo, pero buscando que en general el procesador tenga mejor rendimiento debido
a la capacidad de mantener más instrucciones trabajando al mismo tiempo. Al reducir la
48
cantidad trabajo por ciclo del CPU podría argumentarse que se reduce el desempeño del
sistema, pero esto permite aumentar la frecuen
frecuencia
cia de operación del procesador y el flujo de
trabajo por el mismo, por lo cual el rendimiento aumenta.
Figura 21. Esquemático: CPU MIPS - Pipelined
El CPU Pipelined monolítico cuenta con 2 entradas y 33 salidas, totalizando 709-bit de
datos que se envían a la Lógica de Control y Monitoreo. El incremento de la cantidad de
información que se envía tiene por objetivo permitir una observación más detallada del
comportamiento de éste.
Para la evolución a modo Pipelined del sistema MIPS-SingleCycle, fue necesario modificar
las unidades funcionales de manera que pudiesen aceptar las nuevas señales de control.
Además, se agregaron nuevas unidades que son necesarias para la implementación del cauce
segmentado y se eliminó una unidad, ya que los caminos de dato
datoss quedan naturalmente
separados y la función de ésta era separarlos para permitir el monitoreo separado de la
información de tal señal. En total, se agregaron 7 estructura
estructurass al diseño, se modificaron 6 de
las existentes y se eliminó una.
En general, el funcionamiento del procesador como un todo puede describirse como una
secuencia de tareas que realizan 5 estructuras, mientras que las demás se encargan de dirigir
el producto de dichas tareas de manera efectiva entre ellas, tal que no interfieran gravemente
en el desenvolvimiento de las de las otras estructuras. Idealmente, en cada ciclo las
49
estructuras deben hacer disponible el producto de sus tareas, así como tomar los insumos para
llevar a cabo sus tareas en el presente ciclo.
Debido a que los sistemas reales distan del comportamiento ideal, las unidades funcionales
no siempre son capaces de llevar a cabo sus tareas en el transcurso de sólo 1 ciclo del reloj,
por lo cual es necesario que existan estructuras de control que permitan a las primeras
culminar sus operaciones sin interferir en el funcionamiento del CPU como un todo.
Seguidamente, se presentan las unidades que fueron modificadas para la implementación
del sistema Pipelined, seguidas de las unidades nuevas que fueron agregadas para lograr la
funcionalidad deseada. El dibujo esquemático de la implementación de este sistema puede ser
consultado en el Apéndice 1.
5.4.1.1.
IFETCH
Esta unidad fue modificada para permitir el envío de parte de la instrucción ya
decodificada, de manera que la HDU (Hazard Detection Unit – Unidad Detectora de
Atascos) pudiese leer los operandos directamente desde esta unidad. Además, se agrego
una entrada a la unidad para detener el avance del programa como parte del control
necesario para el funcionamiento adecuado del cauce segmentado (pipeline).
Internamente, se modifico la estructura de la unidad para habilitar la funcionalidad
necesaria por parte de las nuevas señales que se manejan. De interés es la señal de
control de avance del PC, ya que internamente se evita que éste se actualice, de manera
que las operaciones de búsqueda de instrucción se realizan sobre la misma dirección, así
como los cálculos subsiguientes que se realizan al PC no se actualizan, obteniendo en la
práctica una “parada” de la unidad, sin restablecerla a su estado inicial.
5.4.1.2.
IDECODE
Sobre esta unidad se realizaron considerables cambios en términos de las entradas y
salidas. En término de entradas se eliminaron 2, se agregó una y se modificó una de las
existentes, llevando el número a 7 en total. Con respecto a las salidas, se agrego una,
debido a que, dada la naturaleza del pipeline, una función que realizaba internamente
ésta unidad pasó a ser manejada de manera externa.
50
Las entradas eliminadas fueron primordialmente las señales de control de la escritura
de manejo de memora, así como las entradas redundantes, ya que por el desarrollo del
pipeline, esta unidad no necesita la señal de manejo de memoria. Por otra parte, se
combinaron las entradas de datos para escritura a registros por 1 sola entrada, además de
agregarse un puerto para recibir la dirección de escritura y la señal de control que la
habilita.
Las modificaciones al comportamiento interno de esta unidad radican principalmente
en la adecuación del manejo de la escritura a la página de registros, así como el envío de
la dirección de escritura. Además, se eliminaron las referencias a la señal de control que
fue removida de esta unidad, junto con la correspondiente modificación de la lógica que
era controlada por ésta, simplificando la escritura a los registros.
5.4.1.3.
EXECUTE
Esta unidad se modificó para acomodar las optimizaciones de desempeño contenidas
en el concepto de forwarding. En general, vio incrementada sus entradas, pasando a ser
13 en total, y sus salidas no sufrieron cambios con respecto al sistema MIPSSingleCycle. Las entradas incluyen tanto nuevas señales de control como entradas de
datos, muchos de los cuales representan la misma ubicación, pero en diferentes etapas de
la ejecución.
Internamente, se modificó el comportamiento de las entradas de la ALU, ya que la
optimización de Forwarding dicta que estas deban ser capaces de recibir datos de
unidades que se encuentren más adelante en la ejecución de las instrucciones, así como
los datos provenientes de las unidades precedentes. En detalle, dependiendo de las
señales que controlan la fuente de los datos de la ALU, generadas en la FU (Forwarding
Unit – Unidad de Forwarding), se seleccionan los datos sobre los cuales se realizarán las
operaciones.
Esta unidad no recibió modificaciones en la operación interna de la ALU o del
sumador, por lo cual su funcionalidad, así como la salida de datos de la unidad completa
no cambia respecto al sistema MIPS-SingleCycle.
51
5.4.1.4.
CONTROL
La unidad de control recibió pequeñas modificaciones para acomodar los elementos
necesarios para un correcto funcionamiento del MIPS-Pipelined. Se le agregó una señal
de entrada nueva, de manera que se adecúe a la introducción de burbujas en la ejecución
de instrucciones. Esta señal es generada por la unidad HDU, y es necesaria para
mantener la sincronía de las instrucciones por todo el pipeline.
Internamente, la señal ocasiona que la unidad de control genere una operación nula,
denominada nop, de manera que no se modifique el contenido de los registros ni el
contenido de la memoria RAM.
La otra modificación importante de la unidad radica en la decisión de monitorear
todas sus señales, desde que se originan y a medida que van avanzando por el camino de
datos del CPU.
5.4.1.5.
Decodificador de Instrucción
Se extendió el trabajo decodificador, ya que hace disponible las direcciones de los
registros de la instrucción que se encuentra en la etapa de decodificación, de manera que
puedan ser monitoreados por la Lógica de Control y Monitoreo.
5.4.1.6.
Decodificador de dirección de RAM
Esta unidad ahora permite también ejecutar la optimización de forwarding a la unidad
DMEMORY sin hacer grandes modificaciones a ésta.
Internamente, dependiendo de la señal de forwarding se decide qué dato es el que se
escribe a la RAM. La función de decodificación de la dirección de memoria no se
modificó.
5.4.1.7.
WRITEBACK
Esta unidad se agregó al sistema de acuerdo con la teoría a pesar que no se le
considera una etapa per sé. Cuenta con 3 entradas y 1 salida, y se encarga de seleccionar
el dato que va a ser escrito en la página de registros en la unidad IDECODE.
52
Internamente, la unidad recibe tanto el resultado de la ALU como el dato leído de la
RAM, y dependiendo de una señal de control, selecciona uno u otro dato y lo hace
disponible a la unidad IDECODE. De esta manera, la selección que antes se realizaba
internamente ahora se realiza sin colisionar con la sincronía de la ejecución de la
instrucción por el pipeline.
5.4.1.8.
Registros del Cauce Segmentado
Representan el grueso del trabajo necesario para la implementación del pipelining, y
son registros que se encargan de mantener la información entre las unidades funcionales
de manera que esté disponible en el siguiente ciclo de reloj para la próxima etapa del
Pipeline.
En el diseño encontramos 4 registros de pipeline, que separan las unidades IFETCH,
IDECODE, EXECUTE, DMEMORY y WRITEBACK. La intención es, dado que cada
unidad toma un ciclo de reloj en realizar su trabajo, mantener el resultado ésta para que
esté disponible para la siguiente. De esta manera, es posible que existan varias
instrucciones al mismo tiempo siendo ejecutadas por el procesador.
Por diseño, se decidió que el contenido entero de los registros del pipeline sea
monitoreado, por lo cual estas unidades cuentan con una salida especial, que se envía
fuera del CPU, por donde los datos salen ya formateados para su envío a la en la trama
al GUI en el computador. Además, se envía la instrucción por todo el pipeline, por lo
cual todos los registros tienen internamente la instrucción que origino las otras señales
que éstos almacenan, como una manera de observar más fácilmente la existencia de más
de una instrucción en ejecución al mismo tiempo dentro del CPU.
5.4.1.9.
Unidad de Detección de Atascos (Hazard Detection Unit)
Esta unidad se encarga de manejar el comportamiento de las estructuras del CPU de
manera que se puedan resolver problemas de sincronía en el Pipeline, dadas las
asimetrías de las unidades funcionales en el tiempo que les pueda tomar el llevar a cabo
sus tareas. Cuenta con 7 entradas y 4 salidas, y maneja principalmente señales de
control.
53
Internamente, se revisa el tipo de instrucción que busca la unidad IFETCH, así como
los valores de las señales de control para el acceso a memoria cuando están por el
registro de Pipeline ID_EX, y las direcciones de los registros que se ven involucrados en
las instrucciones que se encuentran en las primeras etapas de su ejecución. De esta
manera, es posible detener a ciertas unidades del pipeline, y efectivamente congelar la
ejecución del CPU, permitiéndole a las unidades más lentas culminar su labor y a todo el
sistema mantener la sincronía del pipeline.
De no implementarse las burbujas en el pipeline, no sería posible la operación del
CPU Pipelined, dado que los datos no estarían sincronizados entre las unidades
funcionales y las instrucciones serían imposibles de ejecutar correctamente.
5.4.1.10. Unidad de Forwarding (Forwarding Unit)
La unidad de forwarding se encarga de monitorear el comportamiento del Pipeline,
con énfasis en las etapas de ejecución y memoria de datos (EXECUTE y DMEMORY).
Dependiendo del cumplimiento de ciertas condiciones, como son la realización de
operaciones sobre registros que en la instrucción inmediata anterior se les modificó, así
como la modificación de un valor en memoria RAM de forma repetida, permite que las
unidades mencionadas anteriormente utilicen como datos de entrada la información más
reciente disponible, usualmente contenida en uno de los registros del Pipeline.
Esta unidad cuenta con 10 entradas y 3 salidas, su función es implementar una
optimización de rendimiento que permite acelerar ciertas operaciones que utilizan las
unidades EXECUTE y DMEMORY.
Sin la optimización de forwarding, el CPU debe implementar burbujas (stalls), es
decir congelar la operación de las instrucciones durante muchos ciclos tal que, tanto la
ALU como la RAM trabajen sobre el conjunto de datos correcto. Esta optimización
permite que dichas unidades puedan tomar la data correcta de las etapas de ejecución
posteriores, de manera que se evite mantener la ejecución paralizada por un gran número
de ciclos.
Dado que esta unidad también se presenta como una unidad de control, todas sus
salidas se monitorean externamente al CPU monolítico.
54
5.4.2. Lógica de Control y Monitoreo del CPU Pipelined
Las modificaciones que fueron implementadas a esta unidad se fundamentan
principalmente en su adecuación para manejar las modificaciones que se le realizaron al CPU
con su conversión a Pipelined. Para comenzar, el número de entradas se extendió a un total de
36. El número de salidas no requirió modificación, así como la rutina de inicialización del
CPU, ya que la versión Pipelined no cambió los requerimientos de dicho procedimiento.
Figura 22. Diagrama de Estados de Lógica de Control y Monitoreo – Sistema MIPS-Pipelined
En general la unidad se simplificó, dado que se manejan en total 709
709--bit brutos de datos,
que al darles formato y adecuarlos para el envío se convierten en 712-bit de datos
formateados, lo que equivale a 89-bytes de información.
El razonamiento detrás de la simplificación de la unidad reside en reducir el presupuesto de
compuertas dedicadas a este componente, ya que el paso de almacenaje consume un número
considerable de recursos y no aporta ventajas competitivas, dado que en este caso se envían
más datos desde el CPU. Una vez que la unidad prepara la trama, se envían 98-bytes a la
55
aplicación del computador. La trama que se envía a la aplicación se puede observar en la
Figura 23.
Figura 23. Trama de Envío de Datos – Sistema MIPS-Pipelined
Durante la operación de esta unidad, el primer paso que se realiza es la inicialización del
CPU, de la misma manera como fue descrito en la sección del Sistema MIPS-SingleCycle.
Seguidamente, la máquina de estados monitorea el reloj del CP
CPU,
U, de manera que comience el
procedimiento de estructuración y envío de los datos una vez que éstos sean válidos para el
ciclo presente. Cumplida esta condición, se inicia el proceso de estructuración de los datos, de
manera que estos estén adecuados para su envío por el puerto serial. Mucha de esta
adecuación consiste en agrupar las señales de control como bytes, codificando “bytes de
control” que luego son decodificados en la aplicación GUI VI.
Originalmente, se realizaba una verificación de la actividad de una unidad comparando el
dato leído del CPU con los almacenados internamente para el envío. Este paso se obvió, dada
la gran cantidad de señales y datos que se extraen del CPU, y que la interpretación de estos
permite observar el nivel de actividad de las unidades internas del CPU.
Finalmente, durante la etapa de pruebas se encontraron problemas con la velocidad a la cual
se enviaban los datos al modulo UART, indicando inconsistencias con el valor del retardo
introducido para evitar problemas de rebosado del buffer de envío. Para solucionarlo, se
duplico el valor de dicho retardo, ya que se observó que aún bajo dichos parámetros no se
afectaba adversamente el comportamiento del sistema.
56
5.4.3. Aplicación GUI VI
Sobre la aplicación del computador, se debió modificar la cantidad de datos que maneja
para adecuarlo a las necesidades del nuevo sistema. Como primer paso, se preparó el sistema
para recibir los 98 bytes de la trama.
Una vez se comprobó que no habían problemas para la recepción de la trama completa, se
trabajó para la decodificación de los bytes que compactaban la información de las señales de
control, que son los que requirieron un mayor nivel de procesamiento, dado que fue necesario
separarlos a sus bits compositivos.
Seguidamente, se fueron separando los datos por etapa del sistema, y agrupándolos para
presentarlos en conjuntos lógicos para el usuario. A medida que se verificaba que la
información recibida era correcta, se estructuraba la información para semejar el diagrama
esquemático del procesador MIPS-Pipelined. Se puede observar la interfaz gráfica de usuario
en la Figura 24.
Figura 24. Interfaz Gráfica de Usuario – Sistema MIPS-Pipelined
Para presentar los datos, encontramos indicadores binarios, en forma de LED, que se
emplean para observar el estado de las diferentes señales de control que se encuentran dentro
del CPU. Además, se presentan los datos relevantes de todas las unidades funcionales, así
57
como el contenido completo de los registros del pipeline. La información de las unidades
especiales de control del sistema se condensa y presenta en las unidades que hacen uso de
ellas, como son la ALU en la unidad EXECUTE, y la unidad DMEMORY.
Las flechas azules representan el orden del camino que recorren los datos dentro del CPU
Pipelined como ayuda visual. La mayoría de las modificaciones realizadas son netamente
cosméticas, para simplificar el panel frontal y mejorar la visibilidad. Las únicas
modificaciones que afectan el comportamiento del GUI radican en que se fijó el valor de
ciertos parámetros de configuración de la interfaz serial, dado que son valores que en la
presente versión del sistema no requieren manipulación.
5.5. Herramientas de Desarrollo y Depuración
Durante el desarrollo del proyecto, se emplearon diversas herramientas para que a medida
que se avanzaba, se pudiese verificar el funcionamiento del mismo. Dada la gran complejidad
de los diseños emprendidos, no era prudente el avance a ciegas, por lo cual se tomaron
diversas medias para depurar los problemas que pudiesen encontrarse.
Figura 25. Muestra de Resultados de Simulación: ModelSim
Como primer paso, se simulaba el comportamiento de los componentes de funcionamiento
complejo, como el CPU, la lógica de control y hasta el sistema completo. Inclusive, en caso
que las unidades requiriesen entradas para poder observar su funcionamiento, fue posible
simularlas, como una señal de estimulo al diseño, para observar el comportamiento bajo
58
distintas condiciones. Gracias al uso de esta herramienta, se pudo observar el funcionamiento
del CPU, para configurar correctamente la Lógica de Control y Monitoreo para la
inicialización del sistema.
Figura 26. Captura de RealTerm: Sistema MIPS-SingleCycle
A pesar que la simulación permite observar el comportamiento esperado, esto debió ser
validado en la práctica, de manera que la interfaz gráfica pudiese ser programada
correctamente. Como la comunicación se realiza por medio de un puerto serial, se utilizó el
software de captura terminal RealTerm como herramienta de depuración, dado que permitió
observar el funcionamiento del sistema ya implementado, para efectuar correcciones en caso
de no ser consistente la operación con la simulación previa, y facilitar la generación de la
interfaz gráfica en LabVIEW.
La progresión de las herramientas de depuración llegó a la necesidad de generar VI’s de
prueba, para validar el funcionamiento de la comunicación serial con éste. De esta manera, se
realizaron instrumentos de prueba, y eventualmente se desarrolló la interfaz, pero haciendo
uso de indicadores que están ocultos en el panel frontal para en para el usuario, que pueden
ser activados por un desarrollador como variables de depuración. Esto permitiría, junto con
el campo que muestra la trama completa que se envía al computador, observar el
59
comportamiento del GUI para procesar los datos enviados desde el dispositivo, y ayudar en el
proceso de depuración del proyecto ante algún cambio.
Figura 27. Captura de RealTerm: Sistema MIPS-Pipelined
Esta interfaz en el VI se hace particularmente útil para la depuración del sistema MIPSPipelined, dado que la captura de datos directamente desde el puerto serial se hace bastante
engorroso, ya que se debe recurrir a la decodificación de bytes en mayor número de ocasiones
que en el sistema MIPS-SingleCycle, sin contar que el volumen de datos a manejar en sí
mismo hace casi prohibitivo el trabajo eficiente en RealTerm.
Además, se realizaron programas de prueba, tanto en la tarjeta FPGA como en LabVIEW,
para comprobar el funcionamiento del Módulo UART, así como parte de los experimentos de
la funcionalidad de la tarjeta y de los diseños que dentro del FPGA se implementen.
CAPITULO 6
RESULTADOS Y ANÁLISIS DE RESULTADOS
Se obtuvieron 2 sistemas de procesador didáctico como producto de este proyecto, con el
agregado de tener los fundamentos de la implementación de 3 desarrollos aparte, los cuales
fueron parcialmente implementados, más no se realizo un trabajo exhaustivo sobre los
mismos. Dado que los sistemas comparten una plataforma común, es posible realizar una
progresión programática secuencial con ellos, permitiendo observar las diferencias que
existen entre los sistemas de forma empírica.
Para el sistema MIPS-SingleCycle, tenemos la implementación de un CPU junto con una
interfaz gráfica de usuario que permite observar el comportamiento del sistema durante su
operación. La interfaz gráfica de usuario puede ser empleada de manera didáctica, pero su
funcionalidad se orienta mejor para realizar corridas de corrección de errores (debugging) y
como medio para comparar con otros sistemas MIPS disponibles. A pesar que es necesario
modificar la fuente VHDL para cambiar el programa que se desea ejecutar, es posible
incrementar el tamaño de la memoria de instrucciones del sistema, siempre que la tarjeta de
desarrollo del FPGA cuente con los recursos suficientes para manejar dicho incremento. La
posibilidad de controlar la velocidad de ejecución de los programas, y la posibilidad de
monitorear el sistema sin la interfaz gráfica de usuario le añaden flexibilidad al sistema, y
abre las puertas para el desarrollo de interfaces distintas a la provista por medio de este
proyecto.
Para el desarrollo MIPS-Pipelined, encontramos que la plataforma de hardware del sistema
tiene mucho en común con el sistema MIPS-SingleCycle, pero la interfaz gráfica de usuario
cambia considerablemente. Dado que a partir de este sistema se puede derivar una “familia”
de implementaciones diferentes, la interfaz gráfica de usuario se diseñó con la idea de que
fuese común entre todas éstas. De la misma forma De la misma forma que la interfaz gráfica
de usuario del sistema MIPS-SingleCycle, la funcionalidad de ésta se presta más para
actividades de debugging, dada la gran cantidad de información que se le presenta al usuario.
Aunque como el primer sistema, este también es capaz de operar sin la interfaz provista, la
gran cantidad de datos hace que sea ligeramente engorroso el procedimiento de decodificar la
información observada directamente desde el puerto serial empleando software de terminal de
61
comunicaciones, como son RealTerm o HyperTerminal. Este desarrollo comparte igualmente
la posibilidad de expansión de la memoria de instrucciones, con la misma dependencia de la
capacidad del dispositivo FPGA sobre el cual se implemente.
Debido a la disponibilidad de evoluciones para el sistema MIPS-Pipelined, se generaron las
fuentes para la implementación de versiones mejoradas de éste. Pero no se realizó una
implementación completa de todas las mejoras, debido principalmente a la falta de tiempo
para realizar todas las pruebas y validaciones necesarias. Aun así, las fuentes de
implementación de las mejoras se incluyen en el software del proyecto.
CAPITULO 7
CONCLUSIONES Y RECOMENDACIONES
7.1. Conclusión General
Se han desarrollado un par de herramientas didácticas, que permiten complementar el
aprendizaje de los estudiantes de Ingeniería Electrónica de la Universidad Simón Bolívar
en las áreas de Organización y Arquitectura del Computador.
7.2. Conclusiones Técnicas
•
Es posible tener implementaciones físicas de arquitecturas de procesadores reales,
gracias a herramientas reconfigurables, permitiendo la corrección, mejora o
modificación de dicho sistema.
•
El uso de VI’s para el desarrollo de aplicaciones simplifica el ciclo de
programación en caso de ser necesario el uso de periféricos conectados al
computador por medio de puertos, como el puerto serial.
•
El desarrollo de proyectos de implementación de hardware en un FPGA requiere,
cuando éste alcanza cierto nivel de complejidad, de un estudio cuidadoso de las
optimizaciones que el ambiente de programación ofrece.
•
Existe una ventaja competitiva en el desarrollo de proyectos complejos empleando
lenguajes HDL, ya que existe un gran número de fuentes abiertas de dispositivos
de pequeña y mediana complejidad, disponibles para su incorporación como
elementos de otros proyectos
7.3. Recomendaciones
•
Implementar una interfaz nativa, independiente de licencias y de intérpretes como
el LabVIEW.
•
Implementar una interfaz serial ASCII para ser usado como diagnostico sin el uso
de programas instalados en el PC.
63
•
Agregar a la plataforma la capacidad de modificar el programa a ejecutar
libremente, mediante un sistema de conversión lexicográfica y escritura en la
memora de instrucciones de los CPU.
•
El uso de éste proyecto como base para el desarrollo de interfaces más avanzadas.
•
El desarrollo de la implementación FPGA de este proyecto, para añadirle
funcionalidad más avanzada.
•
Estudio de la posibilidad de implementar componentes complejos del sistema,
como la memoria RAM, de forma externa al FPGA, de manera que el presupuesto
de recursos de éste disminuya.
•
Estudio de la conversión de las fuentes del proyecto de lenguaje VHDL a lenguaje
Verilog, verificando los beneficios y desventajas que pudiesen existir como
producto de dicha conversión.
•
Estudio del uso de una plataforma de programación de los dispositivos FPGA
basados en puertos USB (Universal Serial Bus – Bus de Serie Universal), para
mejorar la compatibilidad del sistema con equipos de computación modernos, y
añadir la flexibilidad de uso de computadores portátiles (laptops) al sistema.
CAPITULO 8
REFERENCIAS BIBLIOGRÁFICAS
[1] Shimpi, A. Inside ATI & NVIDIA: How they make frames fly. AnandTech –
http://www.anandtech.com . Publicado 23-Sept-2002. Disponible en la dirección:
http://www.anandtech.com/showdoc.aspx?i=1711&p=3. Consultado: 25 de Julio de 2008.
[2] Valich, T. Intel's microcore future shown in pictures. The Inquirer –
http://www.theinquirer.net. Publicado 26-Sept-2006. Disponible en la dirección:
http://www.theinquirer.net/en/inquirer/news/2006/09/26/intels-microcore-future-shown-inpictures. Consultado: 26 de Septiembre de 2006.
[3] Held, J. et al. White Paper: From a Few Cores to Many: A Tera-scale Computing
Research Overview. Intel Corporation. Junio 2006. Documento disponible desde:
http://techresearch.intel.com/articles/Tera-Scale/1449.htm. Consultado: 28 de Julio de 2008. Más
referencias en: http://www.intel.com/go/terascale.
[4] Tanenbaum, A. Structured Computer Organization. Prentice-Hall. 4ta. Edición. 1998.
[5] Freescale Semiconductor. MC68HC08GP32A Data Sheet. Freescale Semiconductor –
http://www.freescale.com. Revisión 1.0 Marzo 2006.
[6] Sweetman, D. See MIPS Run. Morgan Kaufmann. 1ra. Edición. 15 de Abril de 1999
[7] Lee, H. ECE 3055 Fall 2006 – Programming Assignment 2. Georgia Institute of
Technology - http://www.gatech.edu/. Documento disponible desde:
http://users.ece.gatech.edu/~leehs/ECE3055/. Consultado: 15 de Febrero de 2007
[8] Schmid, P. Can Gigabyte’s i-RAM Replace Existing Hard Drives? Tom’s Hardware –
http://www.tomshardware.com . Publicado 7-Sept-2006. Disponible en la dirección:
http://www.tomshardware.com/reviews/gigabyte,1111.html . Consultado: 12 de Septiembre de
2006.
[9] Brown, S. et al. Field-Programmable Gate Arrays, Kluwer Academic Publishers, Mayo
1992. Documento disponible en la dirección: http://books.google.co.ve/books?id=8s4MqYOWZIC
[10] Freidin, P. FPGA FAQ. Fliptronics - http://www.fliptronics.com/ Documento disponible en
la dirección: http://www.fpga-faq.org. Consultado: 02 de Agosto de 2008
[11] Smith, D.J. VHDL and Verilog compared and contrasted-plus modeled example written
in VHDL, Verilog and C. Design Automation Conference Proceedings 1996, 33rd.Paginas: 771776 Publicado: 06 de Agosto de 2002. Documento disponible en versión digital desde:
http://www.angelfire.com/in/rajesh52/verilogvhdl.html. Consultado: 05 de Agosto de 2008.
[12] Sagdeo, V. The Complete Verilog Book. Springer. 1ra. Edición. 30 de Junio de 1998
65
[13] Yalamanchili, S. VHDL: A Starter’s Guide. Prentice Hall. 2da. Edición. 09 de Junio de
2005
[14] Peacock, C. Interfacing the Serial/RS232 Port V5.0. Interfacing the PC – Beyond Logic –
http://www.beyondlogic.com Documento disponible desde:
http://www.beyondlogic.org/serial/serial1.htm. Consultado: 05 de Agosto de 2008
[15] GlobalSpec – Electric and Electronic Components. About Pushbutton Switches
GlobalSpec – http://www.globalspec.com. Documento disponible desde: http://electroniccomponents.globalspec.com/learnmore/electrical_electronic_components/switches/pushbutton_s
witches. Consultado: 05 de Agosto de 2008.
[16] All About Circuits – Vol. 4 Digital. Contact “bounce”. All About Circuits http://www.allaboutcircuits.com. Documento disponible desde:
http://www.allaboutcircuits.com/vol_4/chpt_4/4.html . Consultado: 05 de Agosto de 2008
[17] National Instruments. What is LabVIEW? National Instruments. Documento disponible
desde: http://www.ni.com/labview/whatis/ . Consultado: 05 de Agosto de 2008.
[18] Travis, J. Kring, J. LabVIEW for Everyone: Graphical Programming Made Easy and
Fun. Prentice Hall PTR. 3ra. Edición. 6 de Agosto de 2006.
[19] Patterson, D. Hennessy, J. Computer Organization and Design: The Hardware/Software
Interface. Morgan Kaufmann. 3ra. Edición, 2005.
CAPITULO 9
BIBLIOGRAFÍA
Patterson, D. Hennessy, J. Computer Organization and Design: The Hardware/Software
Interface. Morgan Kaufmann. 3ra. Edición, 2005.
Stallings, W. Organización y Arquitectura de Computadores. Pearson Prentice Hall. 5ta.
Edición. 2004.
CAPITULO 10
APÉNDICES