Implementación de un procesador RISC-V en una FPGA
Autor: Gerard Candón Arenas Centro: Facultad de Informática de Barcelona Director: José María Llaberia Griñó Codirector: Josep-Llorenç Cruz Díaz Especialidad: Ingeniería de Computadores Junio de 2020
Índice
Introducción...3
Capítulo 1: Gestión del proyecto...5
1. Contexto del proyecto...5
2. Motivación... 6
3. Alcance y objetivos... 6
4. Metodología de trabajo...9
5. Planificación temporal...10
6. Análisis económico...13
7. Informe de sostenibilidad...14
Capítulo 2: Procesador multiciclo: Camino de datos y control...17
1. Camino de datos y unidad de control...17
2. Descripción de elementos usados en el camino de datos...17
3. Descripción del camino de datos...18
4. Instrucción de cálculo...20
5. Instrucción store... 22
6. Instrucción load... 23
7. Instrucción branch... 25
8. Descripción de la unidad de control...27
Capítulo 3: Gestión de interrupciones y excepciones...29
1. Eventos no esperados...29
2. Excepciones... 29
3. Interrupciones... 33
4. Concurrencia entre interrupción y excepción...35
5. Instrucciones de sistema...36
Capítulo 4: Modos y flujo de ejecución de programas...39
1. Cambio de modo... 39
2. Restricción de recursos...40
3. Organización del espacio lógico...40
4. Flujo de ejecución de programas...41
Capítulo 5: Componentes externos al procesador...42
1. Descripción del sistema...42
2. Memoria SDRAM...43
3. Salida de vídeo VGA...45
4. Teclado PS/2... 48
5. Temporizador...49
6. JTAG... 50
7. Red de interconexión Avalon...50
Capítulo 6: Programas de prueba...51
1. Estructura de ficheros...51
2. Compilación... 51
3. Acceso a la memoria SDRAM...51
4. Carga de programas en memoria...52
5. Núcleo sin gestión de eventos...53
6. Núcleo con gestión de eventos...54
7. Núcleo multihilo...57
Capítulo 7: Procesador segmentado: Camino de datos y control...60
1. Descripción de la segmentación...60
2. Etapa CP... 61
3. Etapa B... 61
4. Etapa DL... 62
5. Etapa A... 62
6. Etapa M... 63
7. Etapas F y ES...63
8. Decodificación y propagación de las señales de control...64
9. Control de flujo... 65
10. Acceso a memoria...68
11. Riesgos de datos...72
12. Riesgos de secuenciamiento...73
1. Múltiples peticiones a memoria en curso...76
2. Etapa DL bloqueada...77
3. Funcionamiento de un buffer circular...77
4. Funcionamiento del buffer de búsquedas...78
5. Vaciado de la segmentación...79
Capítulo 9: Resumen...82
1. Trabajo realizado... 82
2. Objetivos alcanzados...83
3. Futuras líneas de trabajo...83
Apéndice 1: Formato de instrucciones y registros CSR...85
1. Formato de instrucciones...85
2. Inmediatos... 85
3. Codificación de las instrucciones...85
4. Especificación semántica de instrucciones...87
5. Registros CSR...90
Apéndice 2: Tablas de retardos del camino de datos...91
Apéndice 3: Implementación del sistema en Qsys...93
1. Añadir componentes propios...93
2. Instanciación e interconexión de los componentes...95
3. Generación del sistema...101
Apéndice 4: Organización de ficheros...102
1. Directorio raíz...102
2. Directorio ip_pruebas...102
3. Directorio sistema... 103
4. Directorio ip... 103
5. Árbol de ficheros de código del procesador multiciclo...105
6. Árbol de ficheros de código del procesador segmentado...106
Apéndice 5: Simulación...108
1. Simulación del procesador...108
2. Simulación del sistema...109
3. Errores en la simulación del sistema...110
Apéndice 6: Scritps...114
1. Script para el montador...114
2. Script de compilación...115
3. Script de generación de binarios...116
4. Script de inicialización de memoria...117
Apéndice 7: Diseño para PEC...118
Referencias...119
Introducción
Castellano
El marco del diseño hardware ha visto un gran crecimiento durante las últimas décadas, tanto en la cantidad de transistores utilizados para realizar diseños cada vez más complejos, como en la reducción del tamaño de éstos, permitiendo agruparlos en circuitos integrados cada vez más pequeños.
Uno de los avances que ha acercado el diseño de circuitos integrados a un público más general ha sido la aparición en 1984 de las FPGA: dispositivos programables en los que, hoy en día, se pueden implementar circuitos con millones de puertas lógicas. Ésta tecnología permite diseñar soluciones flexibles y fáciles de mantener para problemas concretos en la industria, y ayuda en el desarrollo profesional de estudiantes y aficionados.
En éste proyecto se ha utilizado ésta tecnología para implementar un procesador. Su desarrollo ha requerido el uso de gran parte de las técnicas y conceptos impartidos en las asignaturas de hardware del grado de ingeniería informática de Barcelona, así como de otros que se han adquirido durante la elaboración del proyecto.
En concreto se han realizado dos diseños: Un procesador multiciclo, y un procesador segmentado. En ambos se ha implementado una arquitectura RISC-V, debido a que es uno de los principales referentes del hardware libre. Se ha utilizado la placa DE2-115 de Terasic, que contiene una FPGA y distintos componentes conectados a ésta (Memorias, LEDs, puertos de vídeo y teclado, etc), para implementar los diseños.
Todo el código utilizado para desarrollar éste proyecto es público, y está disponible en la plataforma GitHub, concretamente en el siguiente enlace:
https://github.com/gerardcandon/implementacion-procesador-riscv-fpga Català
El marc del disseny hardware ha vist un gran creixement a les últimes dècades, tant en la quantitat de transistors utilitzats per a realitzar dissenys cada cop més complexes, com en la reducció de la mida d'aquests, permetent agrupar-los en circuits integrats cada cop més petits.
Un dels avanços que ha apropat el disseny de circuits integrats a un públic més general ha estat l'aparició l'any 1984 de les FPGA: dispositius programables en els quals, avui en dia, es poden implementar circuits amb milions de portes lògiques. Aquesta tecnologia permet dissenyar solucions flexibles i fàcils de mantenir per a problemes concrets a la indústria, i ajuda en el desenvolupament professional d'estudiants i aficionats.
En aquest projecte s'ha utilitzat aquesta tecnologia per a implementar un processador. El seu desenvolupament ha requerit l'ús de gran part de les tècniques i conceptes impartits a les assignatures de hardware del grau d'enginyeria informàtica, així com d'altres que s'han adquirit durant l'elaboració del projecte.
En concret s'han realitzat dos dissenys: Un processador multicicle, i un processador segmentat.
En ambdós s'ha implementat una arquitectura RISC-V, ja que és un dels principals referents del hardware lliure. S'ha utilitzat la placa DE2-115 de Terasic, que conté una FPGA i diferents components connectats a aquesta (Memòries, LEDs, ports de vídeo i teclat, etc), per a realitzar les comprovacions del disseny.
plataforma GitHub, concretament al següent enllaç:
https://github.com/gerardcandon/implementacion-procesador-riscv-fpga English
The hardware design field has seen a big growth in the last decades, not only in the quantity of transistors used to develop designs of increasing complexity, but also in the reduction in size of said transistors, enabling their aggregation in integrated circuits that are increasingly smaller.
One of the advances that has brought the design of integrated circuits closer to a more general public has been the emergence of FPGA on 1984: programmable devices that can contain relatively large circuits. This technology makes it possible to design flexible and easy to maintain solutions for problems on the industry, and it helps students and amateurs on their professional development.
This technology has been used in this project to implement a processor. The development of said processor required the use of most of the techniques and concepts imparted on the hardware subjects of the informatics engineering degree, as well as others that were acquired during the elaboration of the project.
Specifically, two designs have been developed: A multicycle processor, and a pipelined processor. A RISC-V architecture was implemented in both cases, given that it is one of the main representatives of free hardware. To verify the design, the DE2-115 Terasic board was used. This board has an FPGA and different components connected to it (Memories, LEDs, video and keyboard ports, etc).
All the code used to develop this project is public, and is available on the GitHub platform, specifically in the following link:
https://github.com/gerardcandon/implementacion-procesador-riscv-fpga
Capítulo 1: Gestión del proyecto
1. Contexto del proyecto
Desde su invención en 1984, la industria ha visto un crecimiento considerable en la producción de FPGAs (Field Programmable Gate Array)[1]. Estos componentes son dispositivos programables que permiten implementar diseños hardware tanto combinacionales (elementos que se constituyen de puertas lógicas) como secuenciales (elementos de memorización).
Hoy en día las FPGA pueden contener cientos de miles, o incluso millones de puertas lógicas, permitiendo implementar todos los módulos que componen un procesador. Estos sistemas se denominan SoC (System on a Chip). Hoy en día, empresas como Amazon[2] o Microsoft[3] ya utilizan ésta tecnología para la implementación de algunos de sus proyectos. Sin embargo, las FPGAs también han proliferado por su utilidad para la docencia y el desarrollo técnico individual.
Terasic ha comercializado placas[4] destinadas a la enseñanza y al aprendizaje individual que contienen como elemento y atracción principal una FPGA capaz de contener un SoC. Estas placas disponen de distintos componentes capaces de comunicarse con la FPGA como memorias, LEDs, pantallas LCD, puertos de entrada y salida para teclado o VGA, entre otros, para ofrecer a los usuarios la capacidad de diseñar sistemas complejos y completos.
El proyecto que se ha desarrollado trata sobre la implementación de un procesador con arquitectura RISC-V[5] en la FPGA de una de estas placas, concretamente la DE2-115[6]. En la Figura 1.1 se muestra un esquema de todos los elementos que componen esta placa.
Figura 1.1: Esquema de bloques de los elementos de la placa DE2-115 de Terasic.
Para implementar los diseños se ha escogido utilizar el lenguaje de especificación hardware VHDL1, un lenguaje con el que los alumnos de la rama de Ingeniería de Computadores están familiarizados por su uso en las asignaturas PEC2, AC23 y MP4. La circuitería que se programa en la FPGA se genera a partir del código VHDL utilizando la versión gratuita del programa Quartus6[7].
Se ha escogido una arquitectura RISC-V puesto que es una de las principales referentes del hardware libre. En otras palabras, su especificación es pública, y es legal y gratuito fabricar y distribuir chips que usen esta arquitectura. La arquitectura RISC-V, desarrollada en 2010 en la universidad de Berkeley, está siendo impulsada sobretodo a nivel europeo[8] con el objetivo de ganar independencia tecnológica, reduciendo los riesgos de monopolio y facilitando el desarrollo de nuevas aplicaciones.
1. Very high speed integrated circuit Hardware Description Language.
5
2. Proyecto de Ingeniería de Computadores.
3. Arquitectura de Computadores 2.
4. Multiprocesadores.
5. En concreto, la extensión RV32I, que describe un conjunto de instrucciones de 32 bits.
6. Se utiliza la versión 19.1 de Quartus Prime Lite Edition. Muchas de las funcionalidades del programa están
En concreto, destaca el proyecto DRAC[9], centrado en el desarrollo de aceleradores basados en arquitectura RISC-V, y el Laboratorio Europeo para la Arquitectura Abierta[10], orientado al desarrollo de chips y procesadores para el cómputo de altas prestaciones basados en arquitecturas abiertas, como RISC-V, OpenPOWER o MIPS. Ambos proyectos están liderados por el Barcelona SuperComputing Center (BSC).
Destaca también la compañía SiFive[11]. Fundada por tres investigadores de la universidad de Berkeley en 2015, fue la primera en comercializar un chip con arquitectura RISC-V. Hoy en día comercializa productos basados en RISC-V, como núcleos, SoC y placas de desarrollo.
Centrado en ofrecer procesadores basados en arquitectura RISC-V y de especificación abierta, encontramos también PULP7 Platform[12], un proyecto cuya principal motivación es la de diseñar procesadores con alta eficiencia energética.
La facilidad para acceder a la especificación, la libertad legal que aporta esta arquitectura, y el gran soporte e impulso que está recibiendo actualmente por parte de una multitud de empresas y proyectos, la hacen una opción perfecta para este trabajo.
2. Motivación
Son dos las razones por las que se ha decidido desarrollar este proyecto. En primer lugar, se enmarca dentro del desarrollo técnico personal; es decir, el objetivo principal es el aprendizaje y la adquisición de habilidades por parte del autor en el ámbito del diseño y especificación hardware. La implementación de una arquitectura RISC-V es de particular interés debido al impulso y soporte que está recibiendo, como se ha discutido en el anterior apartado, y el desarrollo de éste proyecto puede suponer un punto de partida para futuras líneas de trabajo.
La segunda razón reside en el contexto universitario. Por una parte, el diseño de un procesador requiere hacer acopio de gran parte de los conocimientos adquiridos a lo largo del grado de ingeniería informática y, en concreto, de la especialidad de Ingeniería de Computadores, por lo que resulta un buen trabajo en el que demostrar los conceptos aprendidos durante la estancia en el grado.
Además, la realización del trabajo proporcionará beneficios a la rama de Ingeniería de Computadores, puesto que la documentación del trabajo se usará para la asignatura PEC, en la que se pretende optar por la implementación de un procesador RISC-V como temario principal de la asignatura. Son, por lo tanto, el autor y los futuros alumnos de la asignatura PEC los principales actores que van a obtener beneficios del desarrollo del proyecto.
3. Alcance y objetivos
Los objetivos del proyecto se han dividido en distintas fases. Seguidamente se describen cada una de estas fases y se exponen, si existen, las desviaciones que se han producido en relación con el objetivo planteado al inicio del desarrollo del proyecto.
Fase 1 - Procesador multiciclo. La primera fase supone el esqueleto principal del proyecto, y consiste en la implementación de un procesador RISC-V multiciclo. La principal característica de un procesador multiciclo es la división de la interpretación de instrucciones del procesador en varios ciclos de reloj.
Los objetivos de esta fase son la familiarización con el conjunto de instrucciones RISC-V de usuario y el planteamiento de un diseño del camino de datos y de la unidad de control. Tanto para ésta como para subsiguientes fases del proyecto, son esenciales los conocimientos adquiridos a lo largo del grado en asignaturas de hardware, especialmente IC8, AC9, SO10 y AC2.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Fase 2 – Uso de la memoria SDRAM. El objetivo de esta fase es el uso de la memoria SDRAM de la placa. El procesador debe utilizar esta memoria para realizar la búsqueda de las instrucciones, y la lectura o escritura de datos al interpretar instrucciones de acceso a memoria. Para ello se ha dividido esta fase en dos sub-fases.
- Fase 2.1 – Bus Avalon. Al diseño se le añade una red de interconexión llamada Avalon Bus[13]. Avalon es una red configurable que soporta varios protocolos de comunicación con control de flujo. Se utiliza la red Avalon para comunicar el procesador con varios dispositivos como controladores de SDRAM, de vídeo o de teclado. El objetivo de esta sub-fase es comprender el funcionamiento y la configuración de la red Avalon.
- Fase 2.2 – SDRAM. En esta sub-fase se estudia el funcionamiento del controlador de SDRAM, elemento que se comunica con la memoria SDRAM de la placa. El controlador y otros componentes ajenos al procesador son proporcionados durante la instalación del software Quartus. Se añade al diseño del procesador el control necesario para efectuar peticiones de lectura y escritura al controlador de SDRAM, utilizando uno de los protocolos de comunicación de la red Avalon.
Fase 3 - VGA. El objetivo de esta fase es interconectar los componentes necesarios mediante la red Avalon para disponer de salida de vídeo VGA. Esto se consigue haciendo uso de la memoria SRAM de la placa como frame buffer, y usando un controlador de DMA para transmitir los datos al controlador de VGA.
Fase 4 - Interrupciones y excepciones. El objetivo principal de esta fase es la implementación de instrucciones y componentes que permitan la gestión de interrupciones y excepciones. En concreto, se pretende añadir un componente temporizador que emita una interrupción de reloj, y un controlador de teclado PS/2 que emita una interrupción de teclado.
Se utiliza uno de los protocolos de comunicación de la red Avalon para transmitir las señales de interrupción entre los componentes que las generan y el procesador.
Fase 5 - Modos de ejecución. En esta fase se implementan dos modos de ejecución: Modo máquina, en el que el procesador se ejecutaba hasta ahora implícitamente, y modo usuario.
La distinción de distintos modos permite protección contra el uso inadecuado o malicioso del procesador, ya que se puede impedir la interpretación de ciertas instrucciones o el acceso a ciertas regiones de memoria cuando se ejecuta código en modo usuario.
Fase 6 - Segmentación. Esta es la última fase del trabajo, y consiste en la segmentación del procesador. En un diseño segmentado, la interpretación de una instrucción se divide en fases, y se determina un secuenciamiento temporal del flujo de información de dichas fases. Cada fase se aisla del resto mediante elementos de desacoplo11, y la denominamos etapa. Cuando una etapa está desocupada, se puede utilizar para la interpretación de otra instrucción. En éstas condiciones, al segmentar un procesador se pueden interpretar concurrentemente varias instrucciones.
En la Figura 1.2 se muestra un ejemplo de ejecución segmentada con una ráfaga de 6 instrucciones. La interpretación de las instrucciones se ha dividido en tres etapas, y la latencia de inicio de la interpretación de una instrucción es de 1 ciclo.
11. Registros.
1. Gestión del proyecto
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Figura 1.2: Ejemplo de segmentación en un sistema en que la interpretación de una instrucción dura 3 ciclos de reloj.
En el ejemplo, salvo al inicio y al final de la ejecución, siempre hay 3 instrucciones interpretándose concurrentemente en el procesador, con lo que el tiempo de ejecución se reduce en casi el triple respecto a una ejecución secuencial.
En una ejecución segmentada, es posible que se altere el orden de lecturas y escrituras respecto a una ejecución en serie. Es necesario por lo tanto detectar riesgos de datos ocasionados por dependencias entre instrucciones que se ejecutan concurrentemente y gestionarlos emulando un comportamiento secuencial. También es necesario detectar riesgos de secuenciamiento ocasionados por instrucciones que pueden modificar el flujo de interpretación de instrucciones, y gestionarlos emulando un comportamiento secuencial.
Documentación. Es necesario documentar todos los aspectos del desarrollo del proyecto.
Ésta documentación conforma una memoria en la que se detallan los aspectos relativos al desarrollo de las fases descritas anteriormente.
Documentación para PEC. Se pretende utilizar el diseño del procesador multiciclo como material para la asignatura PEC. Esto implica redactar una documentación adicional en la que se detallan de los pasos seguidos para implementar los diseños propios de las fases 1 a la 5, así como la creación de casos de prueba exhaustivos que demuestren el correcto funcionamiento de los diseños. El diseño para PEC ha de ser adaptado para utilizarse en la placa DE1, usada en la asignatura, en lugar de la placa DE2-115, usada en el proyecto. Se han de realizar algunos cambios en el diseño para acomodarlo a la placa DE1, detallados en el Apéndice 7.
Éste aspecto del proyecto se ha visto comprometido debido a agentes externos. Por razón del estado de alarma ocasionado por la pandemia del virus COVID-19, ha resultado imposible disponer de la placa DE1 usada en la asignatura PEC, por lo que se ha tenido que plantear una alternativa.
Se han mantenido las diferencias respecto al diseño planteado en el proyecto, pero sólo se ha podido comprobar su funcionamiento en la placa DE2-115. Aunque aún no se ha podido comprobar que el diseño funcione en la placa DE1, se ha generado toda la documentación y código necesario para la asignatura.
reloj
Instr 1 Etapa 1 Etapa 2 Etapa 3
Instr 2 Etapa 1 Etapa 2 Etapa 3
Instr 3 Etapa 1 Etapa 2 Etapa 3
Instr 4 Etapa 1 Etapa 2 Etapa 3
Instr 5 Etapa 1 Etapa 2 Etapa 3
Instr 6 Etapa 1 Etapa 2 Etapa 3
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
4. Metodología de trabajo
Se ha optado por utilizar una metodología de trabajo incremental. Tal y como se muestra en la Figura 1.3, el desarrollo de cada fase está dividido en distintas secciones que se realizan en serie. Empezando por el diseño de una solución al problema planteado, seguido de dibujos y esquemas cuyas ideas son traducidas a código VHDL, y finalmente realizando una comprobación del diseño implementado.
Figura 1.3: Flujo de trabajo a seguir en cada fase
Búsqueda de información. En primer lugar es imprescindible buscar información y referencias sobre el diseño que se va a tratar de implementar en cada fase. Mucha información se encuentra en los manuales de RISC-V [14][15] y en la documentación de la placa DE2-115 [6], pero también se consulta material en el que se implementan otras arquitecturas [16].
Comprobación de una fase. La comprobación se realiza mediante programas de prueba con los que se inicializa la memoria, utilizando primero la herramienta Modelsim12 para simular el diseño, y finalmente programando el diseño en la FPGA y realizando la comprobación en la placa. Como se muestra en la Figura 1.3, si en cualquiera de estas secciones se detecta un error, es necesario volver a la sección anterior para corregirlo cuanto antes.
El flujo de trabajo planteado ha demostrado ser altamente efectivo, puesto que ha permitido separar el desarrollo de cada fase de forma ordenada y eficiente. Han sido muchas las ocasiones en las que se han detectado errores y ha sido necesario retroceder a secciones anteriores, pero debido a que éstas se han realizado de forma ordenada, la corrección de un error ha resultado eficaz, precoz, y no ha comprometido partes grandes del proyecto.
Como se ha mencionado anteriormente, gran parte del desarrollo del proyecto ha sucedido durante la pandemia mundial ocasionada por el virus COVID-19. Por motivo de la cuarentena, ha sido imposible acceder al recinto universitario. La planificación planteada inicialmente presupone reuniones presenciales semanales entre el autor, el director y, en ocasiones, el co- director del proyecto. Éstas reuniones, sin embargo, no se han visto comprometidas, puesto que se han seguido llevando a cabo mediante plataformas de comunicación en línea alternativas a las reuniones presenciales. Aunque la efectividad y eficacia de la comunicación en línea es mucho menor que la de una reunión presencial, ha demostrado ser suficiente para llevar un seguimiento adecuado del proyecto.
12. En concreto, la versión 10.5b de Modelsim FPGA Starter Edition. Muchas de las funcionalidades del programa están bloqueadas, al no disponer de una licencia de pago.
1. Gestión del proyecto
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
5. Planificación temporal
En éste apartado se exponen, para cada una de las distintas tareas en las que se ha dividido el desarrollo del proyecto, la estimación temporal que se estableció al inicio del desarrollo del poryecto, y los cambios acontecidos respecto a ésta estimación.
Como ya se ha mencionado, el estado de cuarentena ha comprometido y obligado a cambiar algunos aspectos del proyecto. En el contexto de la planificación temporal, sin embargo, ha resultado un agente positivo, puesto que se han podido dedicar horas de trabajo al proyecto con más calma y márgen de maniobra, debido al tiempo ahorrado en transporte entre el lugar de desarrollo del proyecto y el recinto universitario.
Inicialmente se estimaron 126 días de desarrollo (del 10 de febrero al 15 de junio). Se supuso un máximo de 5 horas de trabajo diario, resultando en un total de 630 horas de trabajo planificables. Si bien es cierto que las horas dedicadas al proyecto han entrado dentro de éste supuesto, a continuación se explican las desviaciones temporales que han sufrido cada una de las tareas.
T1 - Gestión del proyecto. Esta tarea compone la creación de una base sobre la cual fundamentar el desarrollo del proyecto. El total de horas estimadas fueron 60, y se descompone en distintas sub-tareas descritas de la siguiente forma:
• Alcance del proyecto y contextualización: 25 horas.
• Planificación temporal: 8 horas.
• Gestión económica y sostenibilidad: 9 horas.
• Presentación oral y documento final: 18 horas.
Las estimación de horas invertidas en ésta tarea se ha cumplido con exactitud.
T2 - Procesador multiciclo. La implementación del procesador multiciclo supone el esqueleto principal del proyecto, y por ello se estimaron unas 50 horas de trabajo. Sin embargo, y como también se expone en el resto de tareas, la cantidad de horas estimadas ha resultado ser menor que la cantidad final de horas invertidas. En ésta tarea en particular, ha habido una drástica diferencia, puesto que se han invertido alrededor de 100 horas.
La configuración de las herramientas necesarias para realizar el proyecto y la implementación y comprobación de ésta tarea han resultado ser más difíciles de lo que se anticipó en un principio. Una vez realizada la familiarización con la dinámica de trabajo, la desviación en la planificación del resto de tareas ha resultado mucho menos pronunciada que en ésta.
T3 – Uso de la memoria SDRAM. Ésta tarea requiere la búsqueda, estudio y comprensión de la documentación relativa al funcionamiento de la red Avalon y del controlador de SDRAM. Ésta documentación es notoria por estar muy descentralizada y ser bastante obtusa de comprender.
Sumando esto al tiempo de implementación del diseño, se estimaron unas 40 horas de trabajo.
Finalmente, se han dedicado unas 60 horas a ésta tarea. La desviación ha sido ocasionada principalmente por la dificultad que ha supuesto comprender algunos detalles de la configuración de la red Avalon, y la familiarización con su uso.
T4 – VGA. La implementación de la salida de vídeo VGA se estimó que podía resultar sencilla, ocupando unas 25 horas. Ésta predicción resultó ser correcta, y la cantidad de horas dedicadas a ésta tarea fueron bastante exactas con la predicción.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
T5 - Interrupciones y excepciones. Ésta tarea supone un añadido grande en cuanto a diseño en el procesador. Por lo tanto, se supusieron bastantes horas de planificación, diseño, implementación y, sobretodo, comprobación del diseño.
Se estimaron unas 40 horas de trabajo, que finalmente resultaron ascender a 70. El planteamiento del diseño resultó más complicado de lo esperado, resultando en una desviación de 30 horas respecto a la estimación inicial.
T6 - Modos de ejecución. Se estimaron unas 30 horas de desarrollo para ésta tarea. La desviación en ésta ocasión fue leve y atribuida principalmente al planteamiento del diseño, que resultó necesitar más tiempo de lo planeado, resultando en 40 horas de trabajo.
T7 - Segmentación. En un principio se pensó que la dificultad de ésta tarea iba a radicar en el planteamiento del diseño, por lo que se estimaron unas 40 horas de desarrollo. Sin embargo, ha resultado que la mayor parte del desarrollo se ha destinado a la descripción VHDL del diseño. Finalmente se han invertido aproximadamente unas 70 horas de trabajo.
TR - Reuniones semanales. Cada semana se ha concertado una reunión con el director del TFG. Se estimó que la duración de una reunión supondría, aproximadamente, 2 horas, conformando un total de 36. Ésta predicción ha resultado ser bastante exacta.
TD - Documentación. De forma concurrente al resto de tareas, se han dedicado unas 5 horas semanales a la documentación del proyecto, tanto en lo que respecta a la documentación para la asignatura PEC, como la destinada a la memoria final del proyecto. Se estimaron, por lo tanto, un total de 90 horas destinadas a ésta tarea. La predicción temporal de ésta tarea ha resultado ser aproximadamente correcta.
En la Figura 1.4 se muestra una tabla que recoge, para cada tarea, el tiempo de desarrollo que se estimó inicialmente y el tiempo que se ha terminado invirtiendo.
Identificador Descripción Tiempo estimado
(horas) Tiempo invertido
(horas)
T1 Gestión del proyecto 60 60
T2 Procesador multiciclo 50 100
T3 Uso de la memoria SDRAM 40 60
T4 VGA 25 25
T5 Interrupciones y excepciones 40 70
T6 Modos de ejecución 30 40
T7 Segmentación 40 70
TR Reuniones semanales 36 36
TD Documentación 90 90
Total 411 551
Figura 1.4: Tabla de planificación de las tareas del proyecto. Se especifica la estimación temporal inicial y la inversión de tiempo que se ha dedicado para cada tarea.
1. Gestión del proyecto
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
En la predicción inicial se estimó una inversión de 411 horas de trabajo. Sin embargo, la inversión de tiempo final ha resultado ascender a 551. Si bien es cierto que ha habido un aumento significativo, ha entrado dentro del margen 630 horas de tiempo planificable que se asumieron al asignar 5 horas de trabajo diarias.
Los imprevistos y la dificultad de las tareas planteadas han resultado tener un impacto mayor del anticipado, y en futuros proyectos se concluye que se ha de realizar una predicción más conservadora teniendo mucho más presente los distintos factores que pueden contribuir a la demora del desarrollo de una tarea.
Seguidamente se muestran, en las figuras 1.5 y 1.6, los diagramas de Gantt correspondientes a la planificación temporal inicial del desarrollo del proyecto, y al tiempo final invertido respectivamente.
Figura 1.5: Diagrama de Gantt correspondiente a la planifiación temporal inicial del proyecto.
Figura 1.6: Diagrama de Gantt correspondiente al tiempo final de desarrollo del proyecto.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
6. Análisis económico
A continuación se ha realizado un análisis económico en relación con el coste del desarrollo del proyecto. Como se muestra en la Figura 1.7, se han clasificado las distintas partidas presupuestarias en “Costes por actividad” y “Costes genéricos”, que agrupan los costes propios de cada una de las fases del desarrollo del proyecto, y aquellos relativos a todo el desarrollo, respectivamente.
En la tabla se muestra la estimación inicial del presupuesto, calculado utilizando la planificación temporal estimada al inicio del desarrollo, y el presupuesto final teniendo en cuenta la desviación temporal respecto a dicha estimación.
Figura 1.7: Tabla de presupuesto.
Justificación de los costes. Tal y como se muestra en la Figura 1.7, en la gran mayoría de secciones se cuenta con un ingeniero informático dedicado al desarrollo del proyecto. Las horas dedicadas a cada tarea se han expuesto en el apartado 5 de éste capítulo, y el sueldo por hora del trabajador se ha estimado usando los sueldos listados en ofertas de trabajo de ingeniero hardware [17]. Partiendo de un sueldo estimado de 25.000€ al año por una jornada completa con 250 días laborables, se obtiene un sueldo de 12.5€ la hora. Si a esto se le suma el coste de la seguridad social, obtenemos la cifra mostrada en la Figura 1.7 de 16.25€ la hora.
Costes Horas estimadas Horas finales Precio/unidad Vida útil (años) Amortización (€) Precio Precio
o Unidades o Unidades estimado(€) final(€)
Costes por actividad Tarea 1 – Gestión del Proyecto
Ingeniero informático 60 60 16.25 975 975
Ordenador de trabajo 1 1 435 6 2.38 2.38 2.38
Tarea 2– Procesador Multiciclo
Ingeniero informático 50 100 16.25 812.5 1625
Ordenador de trabajo 1 1 435 6 1.9 1.9 1.9
Placa Intel DE2-115 1 1 595 10 1.63 1.63 1.63
Tarea 3– Avalon Bus
Ingeniero informático 40 60 16.25 650 975
Ordenador de trabajo 1 1 435 6 1.52 1.52 1.52
Placa Intel DE2-115 1 1 595 10 1.3 1.3 1.3
Tarea 4– VGA
Ingeniero informático 25 25 16.25 406.25 406.25
Ordenador de trabajo 1 1 435 6 0.95 0.95 0.95
Placa Intel DE2-115 1 1 595 10 0.82 0.82 0.82
Tarea 5– Interrupciones y excepciones
Ingeniero informático 40 70 16.25 975 1137.5
Ordenador de trabajo 1 1 435 6 1.52 1.52 1.52
Placa Intel DE2-115 1 1 595 10 1.3 1.3 1.3
Tarea 6– Modos de ejecución
Ingeniero informático 30 36 16.25 487.5 585
Ordenador de trabajo 1 1 435 6 1.14 1.14 1.14
Placa Intel DE2-115 1 1 595 10 0.98 0.98 0.98
Tarea 7 – Segmentación
Ingeniero informático 40 90 16.25 650 1462.5
Ordenador de trabajo 1 1 435 6 1.52 1.52 1.52
Placa Intel DE2-115 1 1 595 10 1.3 1.3 1.3
TOTAL costes por actividad 4974.51 7184.51
Costes genéricos Reuniones semanales
Ingeniero informático 36 36 16.25 585 585
Ordenador de trabajo 1 1 435 6 1.37 1.37 1.37
Documentación
Ingeniero informático 90 90 16.25 1462.5 1462.5
Ordenador de trabajo 1 1 435 6 3.42 3.42 3.42
Lugar de trabajo
Electricidad 1 1 340 340 340
Agua 1 1 60 60 60
Internet 1 1 160 160 160
Alquiler 1 1 75 75 75
TOTAL costes por actividad + costes genéricos 7661.8 9871.8
TOTAL costes por actividad + costes imprevistos + 10% imprevistos 8427.98
1. Gestión del proyecto
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
En cuanto a las herramientas hardware que aparecen en la tabla; un ordenador de trabajo [18]
y una placa Intel DE2-115 [4], se ha calculado su amortización para establecer el precio que tienen en el marco temporal del proyecto. Para ello se han estimado unos 6 años de vida útil para el ordenador de trabajo y, basándonos en el estado de las placas de las que dispone el grado de ingeniería informática de Barcelona, unos 10 años de vida útil para la placa Intel DE2- 115. Las versión de las herramientas software utilizadas son completamente gratuitas, por lo que no se han listado en las partidas de presupuesto.
En cuanto a los costes asociados al lugar de trabajo, se han estimado tomando como referente el precio de la conexión a internet, el agua y la electricidad del lugar en el que se va a desarrollar el proyecto. Como referencia para el alquiler del lugar de trabajo, se han buscado los precios del alquiler de lugares de trabajo similares y en la misma zona que aquél en el que se realiza el proyecto [19].
Control de gestión. Como se muestra en la última fila de la tabla de la Figura 1.7, se añadió al presupuesto inicial estimado un 10% del mismo (734€), para tratar de cubrir cualquier imprevisto que pudiera suceder. Debido a una predicción errónea del tiempo destinado al desarrollo del proyecto, el presupuesto inicial estimado (7661.8€) y el coste final (9871.8€) difieren en 2210€, superando por 1476€ los 734€ destinados para imprevistos.
Se concluye, por lo tanto, que es necesario realizar predicciones más conservadoras, tanto en la planificación temporal de futuros proyectos, como en las partidas económicas destinadas a imprevistos y desviaciones.
7. Informe de sostenibilidad
Marco previo - Encuesta. Antes de realizar el informe de sostenibilidad, se ha realizado una encuesta a modo de autoevaluación y reflexión, que trata temas de identificación y aplicación de asuntos relativos a la sostenibilidad en proyectos de ingeniería.
Concretamente, se plantean preguntas relacionadas con el conocimiento, detección, planificación y aplicación de técnicas y conceptos que tienen en cuenta la sostenibilidad en las TIC. La falta hasta el momento tanto de interés como de experiencia en este tipo de cuestiones por parte del autor del proyecto, hace que las respuestas efectuadas reflejen una falta conocimientos en éste campo.
Al margen de situaciones puntuales, tampoco se ha recibido una formación en éste tema durante los estudios del grado, por lo que también se considera que las respuestas que se han proporcionado entran dentro de lo normal o razonable.
A continuación se realizan unas reflexiones sobre cómo se enmarca el proyecto en las dimensiones económicas, ambientales y sociales de la sostenibilidad. Esto se lleva a cabo respondiendo una serie de preguntas clave relativas a cada dimensión.
7.1. Dimensión ambiental
¿Qué recursos se han usado durante la vida útil del proyecto? ¿Cuál es el impacto ambiental de estos recursos?
Principalmente se ha utilizado un ordenador de trabajo y la placa DE2-115. El principal impacto ambiental se encuentra en el consumo eléctrico de dichos recursos.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
¿Se ha cuantificado el impacto ambiental de la realización del proyecto? ¿Qué medidas se han tomado para reducir el impacto? ¿Se ha cuantificado ésta reducción?
No se ha cuantificado el impacto de los recursos utilizados, ni se han tomado medidas concretas para minimizarlo.
Si se realizase el proyecto de nuevo, ¿se podría realizar con menos recursos?
Aunque el ordenador y la placa de desarrollo son herramientas esenciales para el desarrollo del proyecto, la gran mayoría de funcionalidades de la placa DE2-115 no se han utilizado. Por lo tanto sería conveniente utilizar una placa con menos prestaciones, con el objetivo de reducir el consumo eléctrico.
¿El proyecto permitirá reducir el uso de otros recursos? ¿Globalmente, el uso del proyecto mejorará o empeorará la huella ecológica?
No se considera que el proyecto aporte una reducción de otros recursos, o que juegue un papel global en mejorar o empeorar la huella ecológica.
¿Podrían producirse escenarios que hiciesen aumentar la huella ecológica del proyecto?
La avería y sustitución de los recursos utilizados, o la necesidad de utilizar un ordenador o una placa que presenten un consumo eléctrico mayor, implicarían un impacto negativo en la huella ecológica del proyecto.
7.2. Dimensión económica
¿Se ha cuantificado el coste (recursos humanos y materiales) de la realización del proyecto? ¿Qué decisiones se han tomado para reducir el coste? ¿Se ha cuantificado este ahorro?
En el apartado 6 de este capítulo se ha realizado un análisis económico en relación a los recursos utilizados. Debido a que únicamente se plantea el uso de un trabajador y que los materiales analizados son completamente necesarios para realizar el proyecto, no se han tomado decisiones orientadas a la reducción del coste del proyecto.
¿Se ha ajustado el coste previsto al coste final? ¿Se han justificado las diferencias?
Como se menciona en el análisis económico realizado en este capítulo, el coste final ha resultado sustancialmente mayor al coste previsto, principalmente debido a una predicción temporal del desarrollo del proyecto errónea.
Se ha concluido que, al estimar una partida económica para el coste de un proyecto, es necesario ser más conservador y sopesar todos los riesgos y desviaciones posibles, destinando una parte sustancial del presupuesto a la gestión de estas situaciones inesperadas.
¿Qué coste tiene el proyecto durante su vida útil? ¿Se podría reducir este coste para hacerlo más viable?
El coste del proyecto ha resultado ser de 9871.8€, aunque se puede disminuir o bien reduciendo el sueldo asignado al desarrollador, o bien logrando acortar la duración del mismo, aunque esto último es un aspecto poco controlable. También es posible realizar un estudio de mercado y adquirir un ordenador y una placa de menor precio y con menos prestaciones, procurando que mantengan los aspectos necesarios para la elaboración del proyecto.
1. Gestión del proyecto
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
¿Se ha tenido en cuenta el coste de los ajustes/actualizaciones/reparaciones durante la vida útil del proyecto?
Una parte del presupuesto del proyecto se destinó a imprevistos como la reparación de los recursos utilizados. En retrospectiva, sin embargo, se concluye que ésta partida fue bastante modesta, teniendo en cuenta que existen también otros riesgos más probables como la necesidad de alargar la duración del proyecto.
¿Podrían producirse escenarios que perjudicasen la viabilidad del proyecto?
Como se ha mencionado, la extensión del tiempo previsto para el desarrollo del proyecto, o la avería de los recursos utilizados podrían suponer la inviabilidad económica del proyecto.
7.3. Dimensión social
¿La realización de este proyecto ha implicado reflexiones significativas a nivel personal, profesional o ético de las personas que han intervenido?
A nivel personal y profesional, éste proyecto ha supuesto reflexiones importantes para el autor.
Concretamente, se considera que ha sido un punto de entrada en el ámbito laboral de la especificación hardware, y se ha comprendido la complejidad y dificultad de dicho ámbito.
Si bien es cierto que el desarrollo del proyecto ha requerido de una gran inversión de tiempo y esfuerzo, se concluye que la experiencia ha sido positiva, y se considera que el autor ha obtenido recursos y técnicas de vital importancia para su entrada en el mundo laboral.
¿Quién se beneficiará del uso del proyecto? ¿Hay algún colectivo que puede verse perjudicado por el proyecto? ¿En qué medida?
Como se ha mencionado, el principal agente beneficiado del desarrollo del proyecto es el autor del mismo. Sin embargo, hay dos agentes más que obtienen beneficios. En primer lugar, los diseños realizados en el proyecto se pretenden utilizar como base para remodelar el temario de la asignatura PEC del grado de ingeniería informática, por lo que futuros alumnos que reciban dicho temario son un agente beneficiado por el desarrollo del proyecto.
En segundo lugar, la memoria de éste proyecto puede resultar un referente útil y un punto de partida para el futuro desarrollo de proyectos similares por parte de otras personas.
¿En qué medida soluciona el proyecto el problema planteado inicialmente?
Se considera que los diseños realizados durante el desarrollo satisfacen con creces todos los objetivos planteados durante la concepción del proyecto
¿Podrían producirse escenarios que hiciesen que el proyecto fuese perjudicial para algún segmento particular de la población? ¿Podría crear el proyecto algún tipo de dependencia que dejase a los usuarios en posición de debilidad?
No se cree que ninguna de estas dos situaciones se produzcan.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Capítulo 2: Procesador multiciclo: Camino de datos y control
1. Camino de datos y unidad de control
El diseño del procesador se puede describir en términos de un camino de datos que incluye elementos combinacionales y secuenciales1 interconectados entre sí mediante elementos de encaminamiento, y una unidad de control encargada de indicar al camino de datos cómo ha de encaminar la información. En la Figura 2.1 se muestra un diagrama de este sistema.
Figura 2.1: Sistema secuencial.
El control es un circuito secuencial representado como un autómata de estados. La unidad de control envía señales de control al camino de datos para que éste pueda encaminar la información correctamente y efectuar una operación concreta.
El camino de datos envía señales de estado a la unidad de control para informar sobre eventos que suceden en éste, y se utilizan para determinar el próximo estado y algunas señales de control.
2. Descripción de elementos usados en el camino de datos
En el camino de datos distinguimos el uso de elementos combinacionales y elementos secuenciales. En el grupo de los elementos combinacionales, cuyo dibujo se muestra en la Figura 2.2, distinguimos:
• Multiplexores.
• Unidad aritmético-lógica (ALU).
• Formateadores.
• Fuerza bit 0: Elemento que inhibe el bit de menor peso del dato de entrada.
Figura 2.2: Elementos combinacionales del camino de datos
1. Elementos de memorización.
En el grupo de los elementos secuenciales, dibujados en la Figura 2.3, distinguimos:
• Registros: Síncronos en la escritura y combinacionales en la lectura
• Memoria SDRAM: Un camino de lectura y un camino de escritura. Síncrona en ambos.
• Banco de registros: Dos caminos de lectura y un camino de escritura. Síncrono en la escritura y combinacional en la lectura. Dispone de 32 registros.
Figura 2.3: Elementos secuenciales del camino de datos 3. Descripción del camino de datos
En la Figura 2.4 se muestra el diagrama del camino de datos y la unidad de control. En el diagrama el flujo de información es de izquierda a derecha excepto en la parte inferior del diagrama, en la que la información fluye de derecha a izquierda. No está representada la señal de reloj ni la señal de puesta a cero, para simplificar el diagrama.
Figura 2.4: Diagrama del camino de datos y la unidad de control.
En cuanto a las señales transmitidas por la unidad de control, distinguimos cuatro tipos:
permisos de escritura, señales de selección de multiplexores (encaminamiento), señales de formateo y una señal de operación de la ALU.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
La utilización del camino de datos y el control para la interpretación de las instrucciones se describe para un subconjunto seleccionado de instrucciones del ACI2 en los siguientes apartados de éste capítulo. Para cada una de las instrucciones se describen las fases de interpretación, las evaluaciones que se realizan en cada fase y los elementos que se actualizan. Adicionalmente, en el diagrama del camino de datos, se resaltan los elementos utilizados en cada fase.
En la Figura 2.5 se muestran las fases de interpretación del subconjunto de instrucciones que se describe. Los acrónimos usados en la Figura 2.5 se explican en la Figura 2.6. Todas las instrucciones disponen de una fase de Búsqueda y de una fase de Decodificación y Lectura de operandos fuente. La fase de escritura suele solaparse con la fase de búsqueda de la siguiente instrucción a interpretar, representado por el acrónimo BUS/ES en la Figura 2.5.
Figura 2.5: Fases de interpretación de un subconjunto de instrucciones del ACI.
Acrónimo Descripción
BUS Búsqueda de la instrucción en memoria.
DL Decodificación de la instrucción y lectura de operandos fuente.
CAL Cálculo de una operación aritmético-lógica.
LD_DIR Cálculo de la dirección efectiva de acceso a memoria en instrucciones de lectura.
LD_M Lectura de memoria.
LD_FMT Formateo del dato leído de memoria en una instrucción de lectura.
EVAL Evaluación de una condición en instrucciones de secuenciamiento condicional.
ST_DIR Cálculo de la dirección efectiva de acceso a memoria en instrucciones de escritura.
ST_M Escritura en memoria.
ES Escritura en el banco de registros.
Figura 2.6: Descripción de los acrónimos utilizados para nombrar las fases de interpretación de un subconjunto de instrucciones del ACI.
2. Arquitectura del Conjunto de Instrucciones.
2. Procesador multiciclo: Camino de datos y control
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
4. Instrucción de cálculo
Una instrucción de cálculo puede tener dos formatos, tal y como se muestra en la Figura 2.7. Si se trata del tipo “OP”, se realiza un cálculo con el contenido de los registros con identificadores rs1 y rs2, y se almacena en el registro rd. Si se trata del formato “OP_IMM”, el cálculo se realiza con el contenido del registro rs1 y el inmediato especificado en la instrucción.
El cálculo que se realiza se determina a partir del campo funct3 y, en el caso de una instrucción
"OP", por el campo funct7. El formato, la codificación y la especificación semántica de las instrucciones se detallan en el Apéndice 1.
Figura 2.7: Formato de las instrucciones de cálculo OP y OP_IMM.
4.1. Fase de búsqueda
La fase de búsqueda es común para todas las instrucciones. En esta fase se accede a memoria para leer la instrucción utilizando la dirección almacenada en el registro CP3. Una explicación más detallada del funcionamiento del protocolo de flujo de control entre la memoria y el camino de datos se proporciona en el Capítulo 5. La duración de un acceso a memoria está determinado por la latencia del acceso a la memoria SDRAM, y en este caso se trata de un número variable de ciclos de procesador.
Concurrentemente al acceso a memoria, como se muestra en la Figura 2.8, se calcula en la ALU la dirección de la siguiente instrucción en secuencia (CP + 4), seleccionando la salida del registro CP en mLa, y el literal #4 en mLb4.
Figura 2.8: Componentes utilizados en la fase de búsqueda de una instrucción
31 20 19 15 14 12 11 7 6 0
Imm[11:0] rs1 funct3 rd 0010011 OP_IMM
31 25 24 20 19 15 14 12 11 7 6 0
funct7 rs2 rs1 funct3 rd 0110011 OP
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
4.2. Fase de decodificación y lectura de operandos fuente
La fase de decodificación y lectura, al igual que la fase de búsqueda, también es común para todas las instrucciones. En esta fase se actualizan los registros CP, CPinst y RI5, resaltados en la Figura 2.9, y se leen los operandos fuente rs1 y rs2 del banco de registros. Adicionalmente, se formatea el inmediato de la instrucción en FMTI6.
Figura 2.9: Componentes utilizados en la fase de decodificación y lectura de operandos fuente de una instrucción.
4.3. Fase de cálculo
En esta fase se efectúa el cálculo en la ALU. Los registros L1R y L2R7 almacenan los valores leídos del BR el ciclo anterior. En el multiplexor mLb se selecciona entre el contenido de L2R y la salida de FMTI en función de si la instrucción que se está interpretando es de tipo "OP" u
"OP_IMM".
En la Figura 2.10 se muestra como, concurrentemente al cálculo, se selecciona la salida del registro CP en los multiplexores mdir_sec y mdir para iniciar la búsqueda de la siguiente instrucción en secuencia en el siguiente ciclo. En la figura 2.10 se muestra el diagrama del camino de datos resaltando los elementos usados durante la fase de cálculo.
21
5. Registro de Instrucción.
6. Formateador de Inmediato.
2. Procesador multiciclo: Camino de datos y control
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Figura 2.10: Componentes utilizados en la fase de cálculo una instrucción OP y OP_IMM.
4.4. Fase de escritura
En la fase de escritura se actualiza el contenido del registro rd con el cálculo de la fase anterior.
Ésta fase se solapa con la fase de búsqueda de la siguiente instrucción en secuencia. En la Figura 2.11 se muestra un diagrama temporal de las fases de interpretación de las instrucciones “OP” y “OP_IMM”. Como se explica en anteriores apartados, el cálculo de la dirección de la siguiente instrucción en secuencia (CP_DIR en el diagrama) se lleva a cabo durante la búsqueda de la instrucción, y la actualización del registro CP con dicha dirección (CP_ES en el diagrama) sucede durante el ciclo de decodificación y lectura de operandos fuente.
Figura 2.11: Diagrama temporal de las fases de interpretación de una instrucción de cálculo.
5. Instrucción store
La instrucción store almacena en la dirección de memoria determinada por la suma del contenido del registro rs1 y el inmediato especificado en la instrucción, el contenido del registro rs2. La granularidad del dato almacenado se determina a partir del campo funct3. En la figura 2.12 se muestra el formato de la instrucción.
Figura 2.12: Formato de las instrucciones store.
La descripción de la fase de búsqueda y de la fase de decodificación y lectura de operandos fuente es idéntica a la proporcionada en la instrucción de cálculo. Se describen, por tanto, únicamente las fases posteriores a estas.
31 25 24 20 19 15 14 12 11 7 6 0
Imm[11:5] rs2 rs1 funct3 Imm[4:0] 0100011 STORE
Instr i BUS … BUS DL CAL ES
Instr i+1 CP_DIR CP_ES BUS …
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
5.1. Fase de cálculo de la dirección destino
En la ALU se calcula la dirección de memoria donde se ha de almacenar el dato, sumando el contenido de L1R y la salida de FMTI. Ésta dirección se selecciona en mdir, como se muestra en la Figura 2.13, para acceder a memoria al ciclo siguiente. Concurrentemente al cálculo de la dirección, el contenido de L2R se formatea en FMTE8 en función de la granularidad del dato a almacenar.
Figura 2.13: Componentes utilizados en la fase de cálculo de la dirección destino de una instrucción store.
5.2. Fase de escritura en memoria
En esta fase se inicia la escritura del dato en memoria. La latencia de un acceso a memoria es de varios ciclos de procesador, pero debido a que en una escritura no se espera una respuesta de memoria, se trata de iniciar la búsqueda de la siguiente instrucción al ciclo siguiente. Éste hecho se muestra en la Figura 2.14, en la que la fase ST_M únicamente dura un ciclo, y al siguiente se inicia la fase BUS de la siguiente instrucción.
Figura 2.14: Diagrama temporal de las fases de ejecución de una instrucción store.
6. Instrucción load
La instrucción load almacena en el registro rd el contenido de una posición de memoria. En la figura 2.15 se muestra el formato de la instrucción. La dirección de lectura se calcula a partir de la suma del contenido del registro rs1 con el inmediato especificado en la instrucción. La granularidad de la lectura se determina a partir del campo funct3.
Figura 2.15: Formato de las instrucciones load.
La descripción de la fase de búsqueda y de la fase de decodificación y lectura de operandos fuente es idéntica a la proporcionada en la instrucción de cálculo. Se describen, por tanto, únicamente las fases posteriores a estas.
8. Formateador del dato de escritura en memoria.
31 20 19 15 14 12 11 7 6 0
Imm[11:0] rs1 funct3 rd 0000011 LOAD
Instr i BUS … BUS DL ST_DIR ST_M
Instr i+1 CP_DIR CP_ES BUS …
2. Procesador multiciclo: Camino de datos y control
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
6.1. Fase de cálculo de la dirección de lectura
En la ALU se calcula la dirección de memoria en la que se ha de efectuar la lectura, sumando el contenido de L1R y la salida de FMTI, como se muestra en la Figura 2.16.
Figura 2.16: Componentes utilizados en la fase de cálculo de la dirección de lectura de una instrucción load.
6.2. Fase de lectura
Durante esta fase se realiza la lectura del dato en memoria. La memoria tarda varios ciclos de procesador en servir la lectura.
6.3. Fase de Formateo
En esta fase se actualiza el registro RLDM9, y su salida se formatea en FMTL10 en función de la granularidad de la lectura. Concurrentemente al formateo, se selecciona la salida del registro CP en los multiplexores mdir_sec y mdir para iniciar la búsqueda de la siguiente instrucción en secuencia en el siguiente ciclo, como se muestra en la Figura 2.17
Figura 2.17: Componentes utilizados en la fase de formateo de una instrucción load.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
