Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Diseño de una arquitectura de computadoras de propósito didáctico Luchetti Mart́ınez-Berná, Sebastián s.luchetti@alumnos.upm.es Bordel Sánchez, Borja borja.bordel@upm.es April 26, 2022 Grado en Ingenieŕıa de Computadores Proyecto de Fin de Grado i Diseño de una Arquitectura Didáctica ETSISI UPM Agradecimientos Agradezco a mi tutor, Borja Bordel Sánchez por brindarme la oportunidad de re- alizar este proyecto y por asesorarme en cuanto a su desarrollo. También agradezco especialmente a la docencia de las asignaturas de todas las asignaturas de computadores: fundamentos, estructura, arquitectura, y tencoloǵıa, por haber fomentado la curiosidad y la pasión hacia la construcción de los sistemas informáticos. Por último me gustaŕıa agradecer a todas las comunidades online dedicadas a solucionar dudas y responder preguntas, y a todas las instituciones educativas que han colgado apuntes y diapositivas, poniéndolas bajo dominio público. ii ETSISI UPM Diseño de una Arquitectura Didáctica Resumen Este proyecto se ha llevado a cabo como una extensión natural de las asignaturas de fundamentos, estructura, y arquitectura de computadores., en las que se explicaba la base teórica y tecnológica de la organización de un computador. Con el proceso educativo en mente, se lleva a cabo el diseño de una arquitectura de computador reducida, tanto como de todos los componentes que la conforman. Esto se realiza a nivel conceptual mediante el diseño de los componentes como una caja negra con entradas y salidas, a nivel estructural viendo el interior de cada componente formado por puertas lógicas, y a nivel de implementación modelándolos en VHDL, un lenguaje de descripción hardware. Detallando cada componente se alcanza un entendimiento de su papel fundamental dentro del computador, y de cómo se interrelaciona con el resto de componentes, sincronizándose en la ejecución para llevar a cabo las operaciones escritas en lenguaje máquina. A diferencia de estudiar una arquitectura ya creada, observar su desarrollo o desarrollar una desde cero aporta la visibilidad necesaria para captar la complejidad y detalle de todas sus partes, ofreciendo al estudiante una perspectiva global muy útil que permita la resolución de numerosas dudas. iii Diseño de una Arquitectura Didáctica ETSISI UPM Abstract This proyect has been carried out as a natural extension of the computer fundamen- tals, computer organization, and computer architecture courses, which explained the theoretical basis and technologies of computer design. With the educative process in mind, both the design of a reduced computer architecture and of its componentes are carried out. This is done at a conceptual level seeing the design of every component as a black box with inputs and outputs, at a structural level seeing every component’s interior as composed by logic gates, and at an implementation level modelling them in VHDL, a hardware description language. Showing the detailed view of every component, an understanding of its fundamental role inside the computer and how it relates with other parts, synchronizing their execution to carry out the instructions written on machine language, can be achieved. A student will gain the visibility needed to grasp the complexity and detail of a computer’s organization by seeing the design and development of an architecture by itself, or even doing it, unlike studying an already complete architecture. This will offer a global perspective that will allow students to solve multiple doubts during the courses mentioned. iv ETSISI UPM Diseño de una Arquitectura Didáctica Índice Agradecimientos ii Resumen iii Abstract iv Índice v Índice de tablas vi Índice de figuras 1 1 Introducción 2 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Objetivos espećıficos . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Estructura de la Memoria . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Marco teórico 6 2.1 Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Ruta de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Estado del arte 14 3.1 Factores de diseño de una arquitectura de computadoras . . . . . . . 14 3.2 Herramientas y tecnoloǵıas utilizadas . . . . . . . . . . . . . . . . . . 18 3.2.1 Primera etapa: diseño . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 Segunda etapa: implementación . . . . . . . . . . . . . . . . . 18 4 Diseño de la arquitectura de computadoras 20 4.1 Juego de instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.1 Elección de las instrucciones que conforman el repertorio . . . 21 4.1.2 Decisiones sobre el repertorio . . . . . . . . . . . . . . . . . . 22 4.1.3 Repertorio de instrucciones . . . . . . . . . . . . . . . . . . . 24 4.1.4 Caracteŕısticas del juego de instrucciones . . . . . . . . . . . . 25 4.2 Ruta de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.1 Especificación de los componentes de la ruta de datos . . . . . 28 ÍNDICE v Diseño de una Arquitectura Didáctica ETSISI UPM 5 Implementación de la arquitectura 37 5.1 Detalle de cada componente . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1 Sumador total . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.2 Cuádruple sumador total . . . . . . . . . . . . . . . . . . . . . 38 5.1.3 Sumador de 8 bits . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1.4 Decodificador de 2 a 4 . . . . . . . . . . . . . . . . . . . . . . 41 5.1.5 Decodificador de 3 a 8 . . . . . . . . . . . . . . . . . . . . . . 43 5.1.6 Decodificador de 4 a 16 . . . . . . . . . . . . . . . . . . . . . . 44 5.1.7 Enabler Genérico y Enabler Genérico Xor . . . . . . . . . . . 46 5.1.8 Multiplexor Genérico de 2 a 1 . . . . . . . . . . . . . . . . . . 48 5.1.9 Multiplexor Genérico de 4 a 2 . . . . . . . . . . . . . . . . . . 49 5.1.10 Multiplexor genérico de 8 a 3 . . . . . . . . . . . . . . . . . . 50 5.1.11 Biestable SR con entrada de activación . . . . . . . . . . . . . 52 5.1.12 Registro genérico . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2 Elaboración de las unidades funcionales . . . . . . . . . . . . . . . . . 54 5.2.1 Unidad Aritmético Lógica . . . . . . . . . . . . . . . . . . . . 54 5.2.2 Unidad de Control . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.3 Memorias de instrucciones y de datos . . . . . . . . . . . . . . 60 5.2.4 Banco de Registros . . . . . . . . . . . . . . . . . . . . . . . . 63 6 Resultados 65 6.1 Integración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.2 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7 Conclusiones y trabajo futuro 70 7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3 Aspectos éticos, sociales, e impacto medioambiental . . . . . . . . . . 71 7.4 Estimación de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 vi ÍNDICE ETSISI UPM Diseño de una Arquitectura Didáctica Índice de tablas 1 Instrucciones aritmético-lógicas. . . . . . . . . . . . . . . . . . . . . . 24 2 Instrucciones de transferencia. . . . . . . . . . . . . . . . . . . . . . . 24 3 Instrucciones de salto. . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Entradas y salidas de la ALU. . . . . . . . . . . . . . . . . . . . . . . 29 5 Entradas y salidas del banco de registros. . . . . . . . . . . . . . . . . 30 6 Entradas y salidas del bloque de memoria. . . . . . . . . . . . . . . . 32 7 Señales de control y su valor en cada instrucción. . . . . . . . . . . . 34 8 Señal PCSrc. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 34 9 Señal RegWrite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10 Señal WDSrcX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11 Señal dinSrc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12 Señal dirSrc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13 Señal MemWrite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14 Señal RR0Src. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 15 Señal ALUOpX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16 Entradas y salidas del sumador total. . . . . . . . . . . . . . . . . . . 37 17 Tabla de verdad del sumador total. . . . . . . . . . . . . . . . . . . . 38 18 Entradas del cuádruple sumador total. . . . . . . . . . . . . . . . . . 39 19 Entradas y salidas del sumador de 8 bits. . . . . . . . . . . . . . . . . 40 20 Entradas y salidas del decodificador de 2 a 4. . . . . . . . . . . . . . . 41 21 Tabla de verdad del decodificador de 2 a 4. . . . . . . . . . . . . . . . 42 22 Entradas y salids del decodificador de 3 a 8. . . . . . . . . . . . . . . 43 23 Entradas y salidas de los enablers. . . . . . . . . . . . . . . . . . . . . 46 24 Funciones lógicas de las salidas de los enablers. . . . . . . . . . . . . . 46 25 Entradas, salidas y tabla de verdad del Multiplexor 2 a 1. . . . . . . . 48 26 Tabla de verdad del multiplexor de 8 a 3. . . . . . . . . . . . . . . . . 51 27 Entradas, salidas, y tabla de verdad del biestable SR. . . . . . . . . . 52 28 Tabla de verdad del registro genérico. . . . . . . . . . . . . . . . . . . 53 29 Señal de control ALUOpX y operaciones que realiza. . . . . . . . . . 54 30 Bateŕıa de pruebas aritméticas. . . . . . . . . . . . . . . . . . . . . . 58 31 Estimación costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 ÍNDICE DE TABLAS vii Diseño de una Arquitectura Didáctica ETSISI UPM Índice de figuras 1 Ejemplo de una simulación en Vivado. . . . . . . . . . . . . . . . . . 19 2 Ejemplo de la śıntesis de un componente en Vivado (banco de registros). 20 3 Ejemplo del esquemático generado por Vivado para un sumador de 8 bits formado a partir de dos sumadores de 4 bits. . . . . . . . . . . . 20 4 Formato de las instrucciones de tipo R. . . . . . . . . . . . . . . . . . 24 5 Formato de las instrucciones de tipo I. . . . . . . . . . . . . . . . . . 25 6 Formato de las instrucciones de tipo J. . . . . . . . . . . . . . . . . . 25 7 Vista de bloque de la ALU. . . . . . . . . . . . . . . . . . . . . . . . 29 8 Vista de bloque del banco de registros. . . . . . . . . . . . . . . . . . 30 9 Diagrama de la memoria. . . . . . . . . . . . . . . . . . . . . . . . . . 32 10 Ruta de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11 Diagrama de Bloque de la Unidad de Control . . . . . . . . . . . . . 33 12 Vista de bloque del sumador total. . . . . . . . . . . . . . . . . . . . 38 13 Función lógica de las salidas del sumador total. . . . . . . . . . . . . 38 14 Simulación del sumador total. . . . . . . . . . . . . . . . . . . . . . . 38 15 Vista de bloque del cuádruple sumador total. . . . . . . . . . . . . . . 39 16 Vista interna del cuádruple sumador total. . . . . . . . . . . . . . . . 39 17 Simulación del cuádruple sumador total. . . . . . . . . . . . . . . . . 40 18 Vista de bloque del sumador de 8 bits. . . . . . . . . . . . . . . . . . 40 19 Vista interna del sumador de 8 bits. . . . . . . . . . . . . . . . . . . . 41 20 Simulación del sumador de 8 bits. . . . . . . . . . . . . . . . . . . . . 41 21 Vista de bloque del decodificador de 2 a 4. . . . . . . . . . . . . . . . 42 22 Función lógica de las salidas del decodificador de 2 a 4. . . . . . . . . 42 23 Simulación del decodificador de 2 a 4. . . . . . . . . . . . . . . . . . . 42 24 Vista de bloque del decodificador de 3 a 8. . . . . . . . . . . . . . . . 43 25 Vista interna del decodificador de 3 a 8. . . . . . . . . . . . . . . . . 43 26 Simulación del decodificador de 3 a 8. . . . . . . . . . . . . . . . . . . 44 27 Vista de bloque del decodificador de 4 a 16. . . . . . . . . . . . . . . 44 28 Vista interna del decodificador de 4 a 16. . . . . . . . . . . . . . . . . 45 29 Vista de bloque de los enablers. . . . . . . . . . . . . . . . . . . . . . 46 30 Simulación del enabler. . . . . . . . . . . . . . . . . . . . . . . . . . . 47 31 Simulación del enabler Xor. . . . . . . . . . . . . . . . . . . . . . . . 47 32 Vista de bloque del multiplexor de 2 a 1. . . . . . . . . . . . . . . . . 48 33 Esquemático del multiplexor de 2 a 1. . . . . . . . . . . . . . . . . . . 48 34 Simulación del multiplexor de 2 a 1. . . . . . . . . . . . . . . . . . . . 49 viii ÍNDICE DE FIGURAS ETSISI UPM Diseño de una Arquitectura Didáctica 35 Esquemático del multiplexor de 4 a 2. . . . . . . . . . . . . . . . . . . 49 36 Tabla de verdad del multiplexor de 4 a 2. . . . . . . . . . . . . . . . . 49 37 Simulación del multiplexor 4 a 2. . . . . . . . . . . . . . . . . . . . . 50 38 Esquemático del multiplexor de 8 a 3. . . . . . . . . . . . . . . . . . . 51 39 Simulación del multiplexor 8 a 3. . . . . . . . . . . . . . . . . . . . . 51 40 Vista de bloque del biestable SR. . . . . . . . . . . . . . . . . . . . . 52 41 Vista interna de un biestable SR NAND. . . . . . . . . . . . . . . . . 52 42 Simulación del biestable SR. . . . . . . . . . . . . . . . . . . . . . . . 53 43 Vista de bloque del registro genérico. . . . . . . . . . . . . . . . . . . 53 44 Simulación del registro genérico. . . . . . . . . . . . . . . . . . . . . . 54 45 Esquemático del registro con n = 4. . . . . . . . . . . . . . . . . . . . 54 46 ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 47 Overflow Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 48 Simulación de las operaciones aritméticas con signo . . . . . . . . . . 57 49 Simulación de las operaciones aritméticas sin signo . . . . . . . . . . 58 50 Unidad de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 51 Señales de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 52 Simulación de la Unidad de Control . . . . . . . . . . . . . . . . . . . 60 53 Vista interna de una memoria de 4 posiciones. Las posiciones son de n bits cada una. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 54 Esquemático generado por Vivado para una memoria realizada con bloques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 55 Esquemático generado por Vivado para una memoria realizada con- ductualmente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 56 Simulación de las memorias. . . . . . . . . . . . . . . . . . . . . . . . 63 57 Simulación de las memorias (conductual). . . . . . . . . . . . . . . . . 63 58 Esquemático del banco de registros. . . . . . . . . . . . . . . . . . . . 64 59 Pruebas del banco de registros. . . . . . . . . . . . . . . . . . . . . . 64 60 Cálculo de la sucesión de Fibonacci. . . . . . . . . . . . . . . . . . . . 67 ÍNDICE DE FIGURAS 1 Diseño de una Arquitectura Didáctica ETSISI UPM 1 Introducción Con el alto nivel de abstracción que se debe mantener desde la perspectiva de inge- niero de sistemas, es frecuente perder la noción de todo lo que sucede en las entrañas de los sistemas utilizados en el ejercicio de la profesión. Sin embargo, mantener una imagen clara de cómo se resuelven las operaciones, cómo se gestionan los datos, o cómo se sincroniza cada componente resulta muy útil y proporciona poderosas herramientas de análisis. Dentro del amplio abanico de ramas profesionales existentes para un ingeniero de computadores o informático, aquellas que requieren un pensamiento más cercano al hardware se beneficiarán inmensamente de conocer los detalles de la arquitectura sobre la cual vana trabajar, y para entender estos detalles es necesario tener un conocimiento base sobre el funcionamiento de los diferentes componentes hardware que formarán una Unidad de Procesamiento. En la actualidad hay una gran de- manda de sistemas empotrados y de tiempo real, sistemas operativos de propósito dedicado, de mejoras por parte de la industria a sistemas operativos convencionales o de propósito general, e incluso una demanda considerable de realizar compiladores para nuevos componentes hardware o para lenguajes de dominio espećıfico. Todas estas áreas de conocimiento necesitarán, en un momento u otro, trabajar a muy bajo nivel, para lo cual será fundamental conocer los aspectos que han motivado decisiones de diseño en los componentes utilizados, entender sus limitaciones y sus fortalezas. Para aquel informático cuya rama de interés no esté a bajo nivel, también será un ejercicio plenamente instructivo el someterse al análisis del diseño de una ar- quicectura de computadora. Para enfrentarse a este ejercicio hace falta desarrollar una visión abstracta que se puede aplicar a cualquier tipo de proceso y que resulta muy útil para la detección y resolución de problemas. Durante el proceso de diseño de la arquitectura se presentarán variadas prob- lemáticas para las que tendremos que proporcionar una solución de entre muchas posibles. El objetivo de este proyecto es realizar una exploración sobre dichas prob- lemáticas, barajar las posibles soluciones, estudiar sus pros y contras, y aprender so- bre cuál podŕıa ser la forma de implementarlo en hardware, basándome en múltiples recursos bibliográficos existentes y en proyectos con principios parecidos. En la mayoŕıa de los casos, las decisiones tomadas responderán a factores de simplicidad, remarcando que el objetivo del diseño es realizar y estudiar el propio diseño, más que obtener una arquitectura rápida o eficiente en cualquiér término. En este contexto, se analizarán las caracteŕısticas de la arquitectura realizada y se 2 1 INTRODUCCIÓN ETSISI UPM Diseño de una Arquitectura Didáctica comparará parcialmente con otras arquitecturas documentadas que han servido de inspiración. 1.1 Objetivos Analizar el proceso de realización de una arquitectura de computadores desde cero, estudiando los diferentes caminos con los que nos podemos topar durante su diseño, y llevar a cabo el diseño y la implementación de sus componentes en un lenguaje de descripción hardware (VHDL) de la manera más cercana a la realidad posible, con sus correspondientes simulaciones. Además, se intentará realizar una simulación de toda la arquitectura en su totalidad una vez todos los componentes estén terminados y la etapa de diseño haya concluido. 1.1.1 Objetivos espećıficos � Diseñar una arquitectura de computadores, especificando sus propiedades gen- erales, la ruta de datos, y su juego de instrucciones. � Hacer un desglose de cada componente y la función que ejerce dentro del sis- tema, explicando la implementación dada y comparando con otras posibles implementaciones. Además, implementarlos, simularlos, y comprobar su cor- recto funcionamiento en VHDL. � Implementar la arquitectura en el lenguaje de diseño hardware VHDL y re- alizar una simulación ejecutando un programa simple. � Analizar a posteriori los problemas encontrados durante toda la etapa de diseño y justificar las soluciones adoptadas. 1.2 Motivación A la hora de buscar profundizar en el diseño de arquitecturas de computadores, un interesado se topará con varios problemas. Aunque bien es cierto que no existe una escasez de información con respecto a este tema en particular, también es digna de mención la dificultad para arrancar desde cero o para interpretar toda esa infor- mación sin acudir a textos que bien podŕıan ser (o son) el recurso bibliográfico de asignatuas semestrales o anuales de cursos universitarios. 1 INTRODUCCIÓN 3 Diseño de una Arquitectura Didáctica ETSISI UPM Otro problema es que una vez se tienen los recursos de referencia, ya sean los juegos de instrucciones de alguna arquitectura o los textos bibliográficos correspon- dientes, nada más veremos el resultado de unas elecciones tomadas por los ingenieros o los autores, sin ver el proceso de creación que se ha seguido en cualquiera de los casos para llegar al producto final (el procesador diseñado) habiendo partido de un lápiz y un papel en blanco. Para poder aportar esa perspectiva del proceso continuo de ingenieŕıa y diseño es necesario realizar dicho proceso y además documentar los pasos que se toman para poder explicarlos posteriormente. Es de esa idea de dónde nace este proyecto, ni mucho menos con la intención de sustiuir la absolutamente necesaria base teórica de los sistemas computacionales, sino para aportar otro recurso complementario al que alumnos y estudiantes puedan acceder si desean visualizar cómo se parte de lápiz y papel y se llega a tener una computadora sin tener que realizar ellos mismos la tarea. 1.3 Estructura de la Memoria Este documento se estructura de la siguiente forma: En la sección 2 se introducen brevemente una serie de definiciones y términos a modo de glosario o base teórica necesaria para comprender con claridad todos los conceptos tratados en este proyecto. Además, se hace una primera aproximación al concepto de ruta de datos, explicando de forma concisa la función de cada unidad funcional o bloque que la compone. En la sección 3 se exploran todos los conceptos utilizados a d́ıa de hoy para describir el diseño de una arquitectura de computadora y se razonará la aproximación tomada en este proyecto respecto a esos conceptos. Seguidamente, se explicarán las herramientas usadas y las etapas en el desarrollo (diseño e implementación), comparándolas con las realizadas en este proyecto. La sección 4 aborda detalladamente cómo se ha realizado esta fase en el proyecto. Se explicará cómo se ha realizado el juego de instrucciones y los factores tenidos en cuenta. Se expondrá el repertorio de instrucciones, sus caracteŕısticas y las decisiones tomadas con respecto a él. Después se explicará la ruta de datos que ha resultado de esta fase, ofreciendo una vista de bloque de las unidades funcionales junto con un desglose de sus entradas y sus salidas y un breve comentario de lo que significan. En la sección 5 se ofrece una vista de bloque de todos los componentes digitales utilizados durante el desarrollo del proyecto. Se ofrecerá también una descripción de sus entradas y sus salidas, y, dependiendo del componente, se mostrará su fun- 4 1 INTRODUCCIÓN ETSISI UPM Diseño de una Arquitectura Didáctica cionamiento interno mediante un esquemático, una tabla de verdad, o con la función lógica que describe. Se expondrá también la simulación de ese componente en el pro- grama Vivado. Se realizará lo mismo para todas las unidades funcionales, entrando en un detalle mayor a la hora de explicar su funcionamiento y cualidades internas. La sección 6 estará dedicada a los resultados del proyecto. En ella se hablará del estado final del proyecto y se hará un análisis del mismo, comentando sobre las principales problemáticas o disyuntivas que se han encontrado a lo largo del desarrollo del proyecto. Finalmente, la sección 7 se centrará en reflexionar sobre el trabajo realizado y el cumplimiento de los objetivos iniciales. Se comentarán posibles ĺıneas futuras de actuación o investigación con respecto a este proyecto y se analizará el impacto del proyecto en diferentes ámbitos. 1 INTRODUCCIÓN 5 Diseño de una Arquitectura Didáctica ETSISI UPM 2 Marco teórico El diseño y la implementación de arquitecturas de computadoras ha seguido un proceso de evolución muy acelerado durante los últimos setenta años. Es importante entender que ninguna persona a d́ıa de hoy es capaz de hacer por sucuenta el diseño e implementación de una arquitectura con caracteŕısticas a la altura del mercado y de las expectativas actuales. En la sección de Estado del Arte se detallarán algunas de las técnicas usadas actualmente para conseguir rendimientos tan altos o especializar procesamiento a vectores o criptograf́ıa. Debido a que la arquitectura creada en este proyecto es extremadamente simple en comparación con las arquitecturas que utilizamos d́ıa a d́ıa en cualquiera de nuestros dispositivos electrónicos, la base teórica necesaria para entender la mayoŕıa de decisiones tomadas no se extenderá en demaśıa y no entrará en conceptos dif́ıciles ni complejos. 2.1 Definiciones Arquitectura de Computadoras: El concepto de Arquitectura de Computado- ras ha sido históricamente dif́ıcil de definir, muchos autores han proporcionado su visión y no siempre ha habido convenio entre ellos. Una definición generalmente aceptada es la dada en la presentación del IBM System/360 en 1964 por Amdahl, Blaauw y Brooks Jr [1]. Según esta definición, el término arquitectura se usa para describir los atributos de un sistema tal y como son vistos por el programador (de ensamblador), es decir, la estructura conceptual y el comportamiento funcional, a diferencia de la organización del flujo de datos y control, el diseño lógico y la imple- mentación f́ısica. Sin embargo, a d́ıa de hoy una arquitectura de computadoras es más dif́ıcil de definir debido a la evolución que han sufrido en múltiples aspectos. Es por ello que con frecuencia se hablará de arquitectura incluyendo factores como el diseño lógico o el hardware utilizado, que no se inclúıan en la definición dada en 1964. Estructura de Computadoras: Aunque este término provoca la misma canti- dad de discusión que el anterior, se puede decir que la estructura u organización de una computadora dan una visión más cercana a la implementación de los compo- nentes que conforman la arquitectura. No sólo se ve qué hace, sino también cómo lo hace. Por ejemplo, dado un componente como un sumador, se pasaŕıa de una visión del componente como una caja negra que recibe unas entradas y produce unas 6 2 MARCO TEÓRICO ETSISI UPM Diseño de una Arquitectura Didáctica salidas siguiendo determinada función lógica, a una visión de cómo el componente suma los bits hasta producir el resultado esperado. Este ejemplo llevado a un com- putador completo lo que permite es pasar de una visión útil para el programador que utilizará la arquitectura para crear programas, a la visión de un diseñador que tendrá conocimiento de cómo se realizan las operaciones en la computadora. Durante el ciclo de vida de una arquitectura existirán diferentes versiones de la organización para esa arquitectura. Por ejemplo, la arquitectura S/360 de IBM ya mencionada, sufrió numerosas extensiones a lo largo de más de 35 años [2]: S/370, S/370 Extended Architecture (XA), extensiones vectoriales a la S/370 y S/370-XA, ESA/370 (Enterprise System Architecture), ESA/390, y la serie S/390 G. Todas estas realizaciones eran versiones concretas de la misma arquitectura con diferentes organizaciones, es decir, que un programador que hab́ıa aprendido y entend́ıa la arquitectura S/360 también iba a entender la arquitectura S/370 y todas las poste- riores, sólo teniendo que estudiar las nuevas funcionalidades incorporadas en cada una de las versiones. Otro ejemplo podŕıa ser la arquitectura x86, que tiene difer- entes variaciones dependiendo del objetivo de aplicación y del fabricante. La versión de Intel de 32 bits es IA-32, mientras que la de 64 bits de AMD es x86 64. También tienen extensiones vectoriales como MMX, extensiones para acelerar algoritmos crip- tográficos como SHA, AES-NI, etc. Tecnoloǵıa de fabricación: Cuando se habla de la tecnoloǵıa de fabricación de un procesador suele ser para hacer referencia a los materiales y los métodos con los que han sido fabricados. La evolución de la tecnoloǵıa de fabricación nos ha permitido pasar de los tubos de vaćıo a los transistores bipolares, luego a los transistores MOSFET, y al final éstos se fueron haciendo cada vez de menor tamaño, permitiendo concentrar un mayor número de ellos en el mismo espacio. En 1971 la tecnoloǵıa comprend́ıa transistores MOSFET de 10 µm. A d́ıa de hoy la tecnoloǵıa de fabricación está en la escala de los 5 nm [3], de camino hacia los 3 nm [4]. Durante este proceso de evolución, la ley de Moore ha sido especialmente relevante. Gordon Moore observó en 1965 que el número de componentes en los circuitos integrados se doblaba cada año [5] (corregido en 1975 a cada dos años [6]). Este efecto ha sido observable en la reducción del tamaño de los componentes electrónicos que se usan cada d́ıa. Esta ley se mantuvo indisputada hasta recientemente, que el ritmo de reducción de tamaño ha ido frenando poco a poco. Arquitectura Von Neumann o Harvard: Una clasificación común que se da a las arquitecturas es según la organización de su memoria principal. Una arquitectura 2 MARCO TEÓRICO 7 Diseño de una Arquitectura Didáctica ETSISI UPM Von Neumann tendrá una sola memoria donde estarán tanto las instrucciones a ejecutar como los datos con los que las instrucciones operarán. En una arquitectura Harvard habrá una memoria para las instrucciones y otra para los datos. La mayoŕıa de soluciones a d́ıa de hoy son soluciones h́ıbridas principalmente en la jerarqúıa de cachés. Lógica combinacional y secuencial: Se denomina lógica combinacional a todo circuito lógico cuya salida depende únicamente del valor de sus entradas presentes, a diferencia de la lógica secuencial, cuyo valor de salida depende tanto del valor de sus entradas como de su valor pasado. La lógica combinacional no tiene memoria, y la secuencial śı la tiene. En la práctica, esta diferencia se ve en diferentes circuitos. Los decodificadores, sumadores, multiplexores, o enablers son circuitos combinacionales, mientras que los registros y las memorias son circuitos secuenciales, porque el valor de su salida depende también de los estados anteriores del circuito. Instrucción: Una instrucción es la orden mı́nima que una computadora será capaz de ejecutar. Las instrucciones suelen clasificarse en tres categoŕıas: � Instrucciones aritmético-lógicas: En este grupo se encuentran instruc- ciones de suma, resta, multiplicación, división, además de instrucciones lógicas como AND, OR o NOT lógico. Estas operaciones se podrán aplicar a uno, dos, o más datos, dependiendo del repertorio de instrucciones. Ejemplos de estas instrucciones son ADD, MUL, XOR, AND. � Instrucciones de transferencia: En este grupo se encuentran instrucciones que permitirán mover datos de un lugar a otro de la computadora. Por ejemplo, mover un dato de un registro a otro, de un registro a memoria, o de memoria a un registro. Ejemplos de estas instrucciones son MOV, LD, ST. � Instrucciones de salto o control de flujo: Estas instrucciones permitirán controlar el flujo con el que se ejecutan las instrucciones en una computadora. Normalmente se ejecutan de manera secuencial, una después de otra, pero con estas operaciones podremos saltar a otros puntos de la cadena de ejecución. Ejemplos de estas instrucciones son JMP, BEQ, BNEQ. Al conjunto de todas las instrucciones que una arquitectura es capaz de ejecutar lo llamaremos repertorio, juego de instrucciones, o ISA, de sus siglas en inglés: Instruc- tion Set Architecture. Además, a cada instrucción del repertorio se la identificará 8 2 MARCO TEÓRICO ETSISI UPM Diseño de una Arquitectura Didáctica por un código de operación u opcode. A partir de este opcode, la computadora podrá actuar de formas diferentes dependiendo de las necesidades de cada instrucción, a saber: activar escritura a registros, activar escritura a memoria, habilitar la modifi- cación del registrocontador de programa, decidir desde qué entrada se escribe a los registros, etc. RISC vs CISC: Se denomina CISC (Complex Instruction Set Architecture) a aquellos repertorios con un gran número de instrucciones complejas, muchos tipos de datos, modos de direccionamiento u operaciones. Los repertorios RISC siguen la filosof́ıa contraria. De sus siglas en inglés, Reduced Instruction Set Architecture, están compuesto por un número reducido de instrucciones básicas y simples, pocos modos de direccionamiento y pocos tipos de datos. Las ventajas de los repertorios CISC es que pueden implementar funciones com- plejas con pocas instrucciones en ensamblador. Esto es beneficioso en algunos es- cenarios en los que el espacio que ocupan las instrucciones es limitado, como en el contexto de las memorias caché, que cualquier disminución en el tamaño del código es ventajoso para el sistema. Los repertorios RISC ganaron popularidad desde los años 80 gracias a múltiples factores. A partir de un repertorio RISC es sencillo diseñar otro repertorio nuevo con algunas modificaciones o extensiones, lo cual es útil para añadir funcionalidad como cálculo vectorial a uno que no incorporaba inicialmente instrucciones de esa naturaleza. Además, el hardware de este tipo de procesadores es más sencillo de diseñar y aceptan una mayor frecuencia de reloj. Otro motivo es que las técnicas de optimización son más sencillas de implementar, tanto en el propio procesador como en el compilador que resultará para la arquitectura creada. Un ejemplo sencillo para visualizar la diferencia entre una arquitectura RISC y una CISC: un caso en el que se tenga que obtener dos valores de memoria, multi- plicarlos, y guardar el resultado de nuevo en memoria. En una arquitectura CISC, esto podŕıa hacerse en una sola instrucción MULT que moviese los dos valores de memoria a registros, realizase la multiplicación, y guardase el resultado en memo- ria. Sin embargo, en una aproximación RISC, se utilizaŕıan dos instrucciones LOAD para cargar los valores de memoria en los dos registros, luego una instrucción MUL para multiplicar esos dos datos, y finalmente una instrucción STORE para guardar el producto en memoria. Es habitual que las arquitecturas RISC sigan un modelo de carga-almacenamiento (load-store en inglés). En estas arquitecturas, las instrucciones pueden dividirse en dos grupos: el grupo de las instrucciones de carga-almacenamiento (aquellas que 2 MARCO TEÓRICO 9 Diseño de una Arquitectura Didáctica ETSISI UPM acceden a memoria para leer o escribir) y el grupo de las instrucciones que acceden a la ALU para realizar operaciones aritmético-lógicas. En las arquitecturas CISC, esta aproximación no se da, ya que conviene que las instrucciones realicen varias tareas. Palabra: Una palabra es la unidad mı́nima de información con la que podrá operar la arquitectura, es decir, la unidad mı́nima de información direccionable. A d́ıa de hoy, por motivos históricos, el significado estricto de lo que significa la palabra de una arquitectura está dilúıdo. Sin embargo, es común aceptar que el tamaño de los registros definen la palabra de una arquitectura. Además, es común que la memoria principal de una arquitectura sea siempre direccionable a byte, es decir, que su palabra sea de 8 bits aunque la palabra de la arquitectura sea de 32 o de 64. Lo que significa esto es que a la hora de mover datos de la memoria, por ejemplo, sólo se podrá hacer con datos cuyo tamaño sea múltiplo de la palabra. Aśı, en una memoria con palabra de 8 bits, se podŕıan mover los datos de 8 bits en 8 bits, o de 16 en 16, pero no de 7 en 7 ni de 21 en 21. Ordenación de la palabra: La ordenación de la palabra, también llamada en- dianness en inglés, es el orden que se utiliza para representar sus bits. Hay dos opciones: � Big Endian: Se coloca el byte menos significativo en la posición menos signi- ficativa de la palabra de memoria. Por ejemplo, para representar en memoria el valor 0x0A1B2C3D en Big Endian, se representaŕıa por la secuencia 0A, 1B, 2C, 3D. � Little Endian: Se coloca el byte menos significativo en la posición más sig- nificativa. Con el mismo ejemplo anterior, la representación en memoria seŕıa la secuencia 3D, 2C, 1B, 0A. A algunas arquitecturas que son capaces de utilizar ambas ordenaciones se las suele denominar Middle Endian. Representación de la información: Cualquier computadora trata toda la in- formación como cadenas de bits. A nivel humano, sin embargo, se dispone de difer- entes tipos de datos: sistemas numerales, sistemas alfabéticos, diferentes śımbolos tipográficos, etc. Para representar cada tipo de datos en la computadora se tendrá que llegar a convenio sobre la codificación de cada dato. Luego, a más alto nivel, se interpretarán las cadenas de bits como pertenecientes a una codificación o a otra. 10 2 MARCO TEÓRICO ETSISI UPM Diseño de una Arquitectura Didáctica Un ejemplo de esta codificación es el estándar ASCII para representar caracteres alfanuméricos. Según ésta codificación, la letra A, seŕıa en binario 0100 0001. Para la representación de numerales enteros, existen tres alternativas posibles: � Signo-magnitud: Según esta representación, se utiliza un bit extra que servirá como signo. El valor 0 indicará que el número es positivo y el valor 1, que es negativo. Por ejemplo, usando cuatro bits y uno de signo: 12 seŕıa 01100 ; y -12 seŕıa 11100. Este sistema es sencillo, pero trae consigo problemas de operabilidad: el cero tendŕıa dos representaciones: una positiva y una negativa, y esto implicaŕıa tener que hacer ajustes en las sumas y las restar si el resultado cambia de signo. � Complemento a uno: Como solución parcial surge el complemento a uno, que consiste en invertir todos los bits de un número para cambiar su signo. Aśı, 12 seguiŕıa siendo 01100, pero -12 seŕıa 10011. En esta representación es más fácil de operar que con signo-magnitud, pero se conserva la doble representación del cero. � Complemento a dos: El complemento a dos se define matemáticamente como CN2 = 2 n −N donde n es el número máximo de bits (5 si continuamos con ejemplo) y N es el número que se desea obtener en complemento a dos. Esta representación es la más usada en arquitecturas de computadoras mod- ernas, ya que elimina la doble representación del cero y facilita mucho la operación aritmética entre números positivos y negativos. 2.2 Ruta de datos La ruta de datos de una arquitectura es un esquema formado por todos los compo- nentes y unidades funcionales que juntos forman el camino que seguirán los datos durante su procesamiento y ejecución. En ella se suelen ver diferentes partes confor- mantes como la unidad aritmético-lógica (o ALU, de sus siglas en inglés), el banco de registros, el contador de programa e incluso la memoria principal. 2 MARCO TEÓRICO 11 Diseño de una Arquitectura Didáctica ETSISI UPM Unidad Aritmético-Lógica (ALU): La ALU es un circuito que realiza opera- ciones aritméticas como sumas o restas, y operaciones lógicas como ANDs, ORs y NOTs. Normalmente tendrá dos entradas de datos por donde se introducirán los operandos, una salida de datos por donde se obtendrá el resultado, y unas entradas de control que permitirán seleccionar la operación a realizar. Banco de Registros: El banco de registros es un conjunto de registros que po- dremos utilizar para almacenar datos de manera temporal. En este banco, podremos seleccionar los registros de los que queremos leer o a los que vamos a escribir, por lo que tendrá unas entradas de datos para escribirlos en los registros seleccionados, unas entradas de selección con las que se elegirá el registro en el que leer o del que leer, y unas salidas de datos por donde se leerán los datos contenidos en los reg- istros seleccionados. También tendrán unas entradas de seleccióndonde elegiremos si queremos leer o escribir en los registros seleccionados. Contador de Programa: Es un registro especial, a veces también llamado reg- istro de instrucción. Este registro contendrá la dirección de memoria donde se en- cuentra la instrucción a ejecutar. Con cada instrucción ejecutada, se incrementará de manera que apunte a la siguiente. Las instrucciones de control de flujo como JMP o BEQ lo modificarán también. Memoria Principal: La memoria principal es un circuito que permitirá guardar datos en mayor cantidad que los registros, que son de tamaño mucho más limitado. En estas memorias se sitúan los programas que ejecutará la computadora y los datos que necesitará para operar. En arquitecturas Harvard habrá memorias separadas para instrucciones y para datos, y en arquitecturas Von Neumann sólo habrá una memoria en la que convivirán datos e instrucciones. Unidad de Control: Es un circuito encargado de organizar cómo se va a ejecutar todo en una arquitectura. Si el resto de unidades funcionales como la ALU se encargan de realizar operaciones, la unidad de control se encarga de controlar qué hacen las otras unidades funcionales, en qué situaciones y bajo qué condiciones. Es por este motivo por el que se suele dividir la organización de una CPU en dos partes: la Unidad de Proceso, formada por todos los elementos anteriores (memorias, contador de programa, ALU, etc.) y la Unidad de Control. Históricamente se hizo de manera cableada, es decir, utilizando únicamente lógica combinacional para realizarla, hasta que en 1951 Maurice Wilkes hizo unos aportes 12 2 MARCO TEÓRICO ETSISI UPM Diseño de una Arquitectura Didáctica teóricos que permitieron utilizar memorias ROM para controlar la ejecución de cada instrucción. A esto se le llamó microprogramación. Aunque la UC no siempre aparece en la ruta de datos, śı que es común incluir las señales de control. 2 MARCO TEÓRICO 13 Diseño de una Arquitectura Didáctica ETSISI UPM 3 Estado del arte En esta sección se verán los factores tenidos en cuenta para realizar el diseño de la arquitectura, aśı como un breve detalle sobre cada factor, posibles decisiones y las implicaciones o usos que tiene cada una de esas decisiones. También se presentarán art́ıculos y proyectos de naturaleza similar a este, y se comentarán sus caracteŕısticas principales, comparándolos entre śı y con la arqui- tectura generada en este PFG. 3.1 Factores de diseño de una arquitectura de computadoras ¿RISC o CISC? Primeramente, es útil considerar si la arquitectura a diseñar será de tipo RISC o CISC. Aunque el número de operaciones pueda ser pequeño en cualquiera de los dos casos, una arquitectura CISC tendŕıa operaciones complejas que dificultaŕıan el diseño de la unidad de control y de la ruta de datos. En el ejemplo dado en la sección anterior, la instrucción CISC MULT léıa de memoria, multiplicaba y luego escrib́ıa en memoria el resultado, a comparación de una arquitectura RISC que eje- cutaba cuatro instrucciones para realizar lo mismo. A d́ıa de hoy, el 99% [7] de las computadoras utilizan arquitecturas RISC, debido a las ventajas expuestas an- teriormente. Aunque algunas se declaren CISC, como x86, o sean claramente CISC a ojos del programador, internamente a veces utilizan conversiones a microcódigo RISC [8]. Realizar el diseño de una arquitectura RISC simplificará la realización de muchas de sus partes y facilitará la comprensión, además de hacer la solución más sencilla de comprender visualmente. Codificación del repertorio de instrucciones: Según cómo se codifiquen las instrucciones de un repertorio, el tamaño de los progra- mas será mayor o menor. Además, esta codificación afectará directamente a cómo se realiza la implementación. Existen tres alternativas: � Longitud variable: Las instrucciones podrán tener longitudes diferentes. � Longitud fija: Todas las instrucciones tendrán la misma longitud. Es habitual que los repertorios RISC tengan instrucciones de longitud fija, ya que facilita el diseño y esto hace que se puedan optimizar mejor. Repertorios como x86 de estilo CISC es habitual que contengan instrucciones de longitud diferentes. 14 3 ESTADO DEL ARTE ETSISI UPM Diseño de una Arquitectura Didáctica Tipo de almacenamiento de operandos El tipo de almacenamiento de los operandos se refiere a dónde vamos a mantener los operandos con los que vamos a operar, es decir, sobre los cuales ejecutaremos las instrucciones. Respecto a esta cuestión, existen tres aproximaciones principales: � Pila: Los operandos son impĺıcitos, se encuentran en la parte superior de una pila que el sistema deberá proporcionar. Las instrucciones que utilicen este tipo de almacenamiento no necesitarán indicar dónde se encuentran los datos sobre los que va a operar. Para operar la pila se utilizarán instrucciones como POP o PUSH, y se tendrán registros especiales que señalarán la posición actual de la pila y la base. En la arquitectura x86, estos registros se denominan ESP y EBP, aunque en realidad está operando sobre una sección de la memoria principal a la que considera la pila, no sobre un componente hardware aislado e independiente. � Acumulador: Consiste en tener un registro particular al que se denomina acumulador, y que almacenará los operandos de forma impĺıcita, es decir, en las instrucciones que utilicen este tipo de almacenamiento no necesitarán indicar dónde se encuentra uno de los datos, porque estará en el acumulador. Siguiendo con el ejemplo de x86, aunque no utiliza un acumulador como tal, en algunas instrucciones como MUL o DIV, śı que utiliza los registros EAX y EDX de manera impĺıcita, a modo de acumulador primario y secundario. � Registros de propósito general: La arquitectura cuenta con varios reg- istros en los que se pueden almacenar datos a petición. Los operandos se encuentran alojados en alguno de los registros disponibles, y para operar con ellos se indica el registro en el que se encuentra. Pueden ser dos operandos o tres, dependiendo de si se especifican tanto los operandos como el registro que almacenará el resultado, o si simplemente se indican los operandos y el resul- tado se guarda en alguno de los registros que también guardaba un operando. Tanto x86 como x86 64 cuentan con registros de propósito general: 8 en el caso de x86 y 16 en caso de x86 64. Usando este tipo de almacenamiento podemos elegir otros factores: – Registro-Registro: Todos los operandos deben estar en registros del procesador antes de operar con ellos. Una instrucción de la forma add eax, eax entraŕıa dentro de esta categoŕıa. – Registro-Memoria: Un operando debe estar en registro y el otro está 3 ESTADO DEL ARTE 15 Diseño de una Arquitectura Didáctica ETSISI UPM en memoria. Por ejemplo: mul eax, [0x10] que multiplicará lo que haya en el registro EAX con lo que haya en la posición 0x10 de la memoria. – Memoria-Memoria: Todos los operandos se encuentran en memoria. Por ejemplo: add [eax], [edx], que suma lo que haya en memoria en la posición señalada por el contenido del registro EAX, con lo que haya en memoria en la posición señalada por el contenido del registro EDX. La utilización de arquitecturas basadas en registros de propósito general está muy extendida, tanto en arquitecturas de computadoras personales como x86 y x86 64 como para arquitecturas de microcontroladores como AVR o la familia Cortex-M de ARM. Modos de direccionamiento: El modo de direccionamiento es la manera de especificar los operandos dentro de las instrucciones. Independientemente del tipo de almacenamiento usado, podemos utilizar varias formas para referirnos a la forma en la que vamos a especificar los operandos. Hay varias opciones: � Inmediato: El operando se codifica dentro de la instrucción, de manera di- recta. Aśı, una instrucción seŕıa PUSH 0x10 para introducir elvalor 0x10 en la pila, o ADD 0x10, 0x20 para sumar 0x10 con 0x20. � Registro: Se indica el registro en el que está almacenado el dato con el que queremos operar. Ejemplos de instrucciones seŕıan PUSH EAX o XOR EAX, EAX. � Directo o absoluto: Se indica la dirección de memoria en la que está al- macenado el dato con el que queremos operar. PUSH [0xABC], o bien SUB [0xFF], [0x20]. � Indirecto: Se indica el registro en el que está almacenada la dirección de memoria en la que está el dato con el que queremos operar. La sintaxis es similar a la del modo por registro, solo que el registro no contiene el dato directamente, sino la dirección de memoria en la que se encuentra el dato. � Indirecto con desplazamiento: Similar al modo anterior, pero además se incluye un operando inmediato: el desplazamiento u offset. Al sumar este desplazamiento a la dirección contenida en el registro indicado, obtendremos la dirección de memoria en la que se encuentra el dato con el que queremos operar. 16 3 ESTADO DEL ARTE ETSISI UPM Diseño de una Arquitectura Didáctica Puede considerarse el modo indirecto como que tiene un desplazamiento con valor 0. Hay mucha variedad tanto en los diferentes modos de direccionamiento como en los nombres con los que se nombra a cada uno. Hay arquitecturas como MIPS-X que tienen un solo modo de direccionamiento [9], mientras otras como la AVR soporta hasta 15 modos diferentes [10]. Implementar modos de direccionamiento complejos puede aumentar la complejidad del hardware. Es interesante el concepto de ortog- onalidad en el juego de instrucciones. Este concepto hace referencia a la capacidad de que cada instrucción pueda utilizar cualquiera de los modos de direccionamiento implementados en la arquitectura. Aunque los juegos de instrucciones a d́ıa de hoy no se diseñan teniendo la ortogonalidad en mente, śı que traen algunos beneficios como poder definir aspectos suyos de manera aislada, sin afectar a los demás [11]. Fases de ejecución de una instrucción: Es habitual dividir la ejecución de las instrucciones en fases o etapas. Tanto las arquitecturas RISC como las CISC utilizan técnicas de segmentado de la ejecución, también llamado pipeline. En las arquitecturas RISC la implementación del seg- mentado es más directa y sencilla, siendo cinco el número de fases en una imple- mentación clásica: Obtención de la instrucción, decodificación, ejecución, acceso a memoria y escritura (Fetch, decode, execution, memory access, writeback, en inglés). La elección del número de etapas es muy dependiente del contexto de la arquitec- tura. Muchas arquitecturas siguen respondiendo al modelo clásico de cinco etapas, o haciendo modificaciones que añaden algunas. Un ejemplo que sobresale es la ar- quitectura Prescott de Intel que llegó a tener un 31 [12]. Sin embargo, otras, como algunas de AVR, funcionan con un pipeline de 3 etapas [13]. Monociclo vs. Multiciclo: Una arquitectura monociclo ejecutará una instrucción en cada ciclo, mientras que una multiciclo tardará varios ciclos en ejecutarlas (se pueden dar dos casos: que todas las instrucciones tarden los mismos ciclos en ejecutarse, o que haya instrucciones que tarden más ciclos que otras). Esta clasificación está relacionada con la anterior en el sentido de que originalmente el segmentado se hizo con la intención de que cada fase tardase un ciclo en ejecutarse. De esta manera, en un pipeline de n fases, cada instrucción tardaŕıa n ciclos en ejecutarse. A d́ıa de hoy la inmensa mayoŕıa de arquitecturas son multiciclo segmentadas. Esto se debe entre otras cosas a que implementan instrucciones cuyos tiempos y 3 ESTADO DEL ARTE 17 Diseño de una Arquitectura Didáctica ETSISI UPM complejidades de ejecución son muy dispares. Hay instrucciones cuya ejecución es casi inmediata, como por ejemplo la instrucción MOV, y también hay instrucciones cuya ejecución es larga y tediosa, como DIV. Para que ambas instrucciones se eje- cuten en un solo ciclo, ese ciclo tendŕıa que tener la duración de la instrucción más larga, y se perdeŕıa mucho tiempo en las instrucciones más sencillas. Este es uno de los motivos por los que se segmenta la ejecución. 3.2 Herramientas y tecnoloǵıas utilizadas Durante la realización de este proyecto se utilizaron diferentes herramientas y tec- noloǵıas que se describirán a continuación. 3.2.1 Primera etapa: diseño Para el desarrollo de cada componente, la primera etapa consist́ıa en diseñar el bloque lógico para ese componente, establecer sus entradas y sus salidas, al igual que la función lógica que desempeñará. Para esto es conveniente utilizar tablas de verdad si el número de entradas y salidas no es demasiado alto. En el caso de serlo, lo más adecuado seŕıa especificar la función lógica en su forma canónica. Para el desarrollo de esta etapa no hace falta utilizar ningún softare en espećıfico, siempre y cuando el componente a diseñar no sea extermadamente complejo. Como este ha sido el caso de todos los componentes que forman la arquitectura de este proyecto, no se ha utilizado software para esta fase sino que se ha hecho a mano. Se ha realizado el diseño a mano y luego se ha digitalizado o bien con herramientas de diseño online como draw.io 1 o mediante la herramienta de creación de esquemáticos que aporta la suite de diseño Vivado de la que hablaré en la siguiente sección. 3.2.2 Segunda etapa: implementación La implementación se hizo mediante el lenguaje de descripción hardware (HDL, de sus siglas en inglés: Hardware Description Language) VHDL. Este lenguaje nos permitiŕıa crear componentes y definir su funcionamiento de manera programática. Para utilizarlo hay diferentes opciones, pero la alternativa utilizada durante el de- sarrollo de este proyecto fue la suite de diseño Vivado, del fabricante Xilinx 2. Esta suite de diseño ofrece varias funcionalidades: 1https://draw.io 2https://www.xilinx.com/products/design-tools/vivado.html 18 3 ESTADO DEL ARTE ETSISI UPM Diseño de una Arquitectura Didáctica � Simulación: Con la simulación se describe el comportamiento del circuito o componente en términos de sus entradas, sus salidas, sus señales intermedias, los retardos, etc. Esto resulta útil para comprobar que el diseño realizado reacciona correctamente ante las entradas. Figure 1: Ejemplo de una simulación en Vivado. � Śıntesis: La sintetización de un circuito o componente es el proceso por el cual, según la descripción dada, se infiere el hardware que dará lugar a ese componente o circuito. No todas las descripciones que se hacen con un HDL son sintetizables, es decir, implementables en hardware. Aunque la imple- mentación en FPGA quedaba fuera de los objetivos de este proyecto, cada componente diseñado se hizo de forma que fuera sintetizable, para aśı dar una mejor visión de la estructura hardware subyacente a cada una de las partes de la arquitectura. Lo que esto aporta es una mayor cercańıa a cómo están compuestos y estructurados cada uno de los componentes hardware de la arquitectura. Durante el desarrollo de este proyecto, no sólo se intentará desarrollar cada componente de forma que sea sintetizable, sino que además se partirá de puertas o funciones lógicas y se crearán los componentes más complejos a partir de aquellos más sencillos. � Creación de esquemáticos: Esta funcionalidad de Vivado no era estricta- mente necesaria para el desarrollo del proyecto, sin embargo es muy útil para encontrar errores en los diseños más rápidamente. Al representar el compo- nente de forma gráfica con las conexiones numeradas, es sencillo detectar un fallo en la organización del componente que de otro modo se habŕıa escondido bien en el código. 3 ESTADO DEL ARTE 19 Diseño de una Arquitectura Didáctica ETSISI UPM Figure 2: Ejemplo de la śıntesis de un componente en Vivado (banco de registros). Figure3: Ejemplo del esquemático generado por Vivado para un sumador de 8 bits formado a partir de dos sumadores de 4 bits. 4 Diseño de la arquitectura de computadoras El objetivo de este proyecto es partir de lápiz y papel y conseguir realizar el diseño de una arquitectura de computadores simple pero funcional. Luego, además, com- pletarlo con la implementación del diseño en VHDL. Durante todo el desarrollo de esta arquitectura se han priorizado las soluciones fáciles de entender a las que apor- taŕıan alguna clase de eficiencia, debido a que, como ya se ha explicado, el propósito de este proyecto era obtener una arquitectura sencilla de entender que pudiera servir como refuerzo a estudiantes, mientras se documenta el proceso de desarrollo y se justifican las decisiones tomadas sobre cada problema surgido. 20 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS ETSISI UPM Diseño de una Arquitectura Didáctica 4.1 Juego de instrucciones Lo primero a realizar durante el desarrollo de una arquitectura de computadoras es el juego o repertorio de instrucciones. Determinar el número de instrucciones, la longitud, los modos de direccionamiento, el tipo de almacenamiento, etc., ya que todos estos factores condicionarán el diseño del resto de componentes. Aśı, si se desconoce el modo de direccionamiento de las instrucciones, no se podrá determinar cómo se env́ıan los operandos a memoria, o cómo se accede al banco de registros, independientemente de la estructura de éstos otros componentes. Para hacer esto, primeramente se decidirán las instrucciones que queremos que conformen el reper- torio, teniendo en cuenta que cuanto mayor sea el número de instrucciones, mayor será la complejidad del hardware. 4.1.1 Elección de las instrucciones que conforman el repertorio Es importante recordar la clasificación de instrucciones en tres grupos: instrucciones aritmético-lógicas, instrucciones de transferencia e instrucciones de control de flujo, aśı se deberán incorporar instrucciones de cada grupo y tener un repertorio variado. Como nota aparte, no entra dentro de los objetivos de este proyecto probar la com- pletitud de Turing del repertorio, sino que la daremos por garantizada basándonos en que tenemos instrucciones de lectura y escritura de memoria, de salto condicional y de operaciones aritmético-lógicas[14] [15]. Aśı, las instrucciones del repertorio serán: � Instrucciones aritmético-lógicas: ADD, SUB, CMP, AND, OR, XOR. Lo primero que se puede observar es la ausencia de instrucción NOT. La ausen- cia de esta instrucción obedece a motivos de simplicidad: como operación lógica no tiene mayor complejidad, e implementarla en hardware añadiŕıa com- plicaciones en la codificación de las instrucciones y en la ALU. Además, es fácil invertir los bits sin utilizar la instrucción NOT : En complemento a dos, la op- eración para invertir una cadena x seŕıa NOTx = −x− 1. � Instrucciones de transferencia de datos: LD, LDI, ST, STI, MOV. Son especialmente relevantes las instrucciones LDI y STI, que cargan en reg- istro o en memoria un valor inmediato, respectivamente. Más adelante, cuando se detalle el formato de las instrucciones, quedará claro por qué sin estas in- strucciones no se podŕıan inicializar valores ni en registros ni en memoria, debido al formato del resto de las instrucciones. 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS 21 Diseño de una Arquitectura Didáctica ETSISI UPM � Instrucciones de salto: JMP, BEQ. Una instrucción de salto incondicional y otra de salto condicional. Incluyendo estas instrucciones garantizamos el mı́nimo control de flujo necesario para implementar lógica variada. 4.1.2 Decisiones sobre el repertorio Antes de diseñar el juego de instrucciones puede resultar útil determinar algunos factores sobre la arquitectura que afectarán al diseño del repertorio. Longitud de la codificación de las instrucciones Es importante preguntarse, antes de todo lo demás, cuál será el tamaño de las instrucciones de nuestro repertorio, ya que este factor será determinante en otras decisiones, como en el número de registros de nuestro sistema o la cantidad de celdas de memoria direccionables. Para simplificar el diseño y mantener una coherencia respecto al número reducido de instrucciones en nuestro repertorio, se utilizará una codificación de longitud fija. En este punto hay dos alternativas principales: instrucciones de 8 o de 16 bits. Con cualquiera de las dos longitudes, 4 bits se dedicarán a la codificación de las 13 instrucciones. Con instrucciones de 8 bits sólo quedaŕıan otros 4 para codificar inmediatos e ı́ndices de registros. Como se verá en la siguiente sección, se utilizarán dos registros fuente y un registro destino en muchas instrucciones, por lo que contar con sólo 4 bits para codificar tres registros resulta insuficiente. Aunque se utilizase un registro fuente y uno destino, esta opción obligaŕıa a contar con sólo dos bits para cada ı́ndice, reduciendo el número de registros direccionables en nuestro sistema a 4. Queda claro que la única opción viable es la de utilizar instrucciones de más de 8 bits de longitud. La opciónde 16 bits es la más sencilla, dejando 12 bits para indicar ı́ndices a registros, inmediatos o direcciones. Tipo de almacenamiento de los operandos Manteniendo siempre la intención de que esta arquitectura pueda servir como re- fuerzo o referencia para estudiantes, el foco del diseño debe estar en que sea sencillo de entender, lo más cercano posible a las estructuras que usamos los seres humanos en el d́ıa a d́ıa. Por esto, el almacenamiento de operandos se realizó con registros de propósito general. Inicialmente las instrucciones aceptaŕıan dos operandos (uno de los operandos fuente seŕıa sobreescrito con el resultado de la operación), pero 22 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS ETSISI UPM Diseño de una Arquitectura Didáctica finalmente se usaron tres operandos fuente para que la sintaxis de las instrucciones fuera más parecida al lenguaje natural. Aparte de esto, la arquitectura mantendrá un enfoque de carga-almacenamiento, siendo sus instrucciones de tipo registro- registro, es decir, para operar con datos éstos tendrán que encontrarse en registros. No se podrá operar con datos ubicados en la memoria sin antes llevarlos a registros con alguna instrucción de carga como LD o LDI. Tipo y tamaño de los operandos Al ser una arquitectura de 8 bits, los datos con los que se opere principalmente serán de 8 bits. Siendo el objetivo el aprendizaje, el tratamiento de números en coma flotante o datos vectoriales se salen del alcance. Por esto, las instrucciones operarán sobre datos de tipo entero de 8 bits en complemento a dos. Número de registros Muchas arquitecturas cuentan con un número limitado de registros. Por ejemplo, x86 cuenta sólamente con 8 registros de propósito general, incluyendo EBP y ESP, que son rara vez utilizados por el programador. MIPS32 cuenta con 32 registros, y otras arquitecturas más reducidas como AVR de 8 bits también cuentan con 32 registros de propósito general, además de los de propósito especial [16]. La arquitectura descrita contará con 8 registros de propósito general, R0-R7, por lo que se necesitarán 3 bits para referenciarlos. Tratamiento de las instrucciones de control de flujo El problema principal sobre estas instrucciones es su modo de direccionamiento, pensando sobretodo en cómo conseguir que direccionasen al mayor número de cel- das de memoria posible. Sin embargo, debido a la naturaleza minimalista de la arquitectura, ninguna de sus memorias será excesivamente amplia. Por ello, las instrucciones de salto no se complicarán y su modo de direccionamiento será in- mediato. Como se puede ver en la figura 6, las instrucciones de salto tendrán 12 bits de direccionamiento, lo que significa que podrán direccionar a 212 = 4096posiciones de memoria. En una memoria con posiciones de 8 bits, ésto seŕıan 2048 instruc- ciones, mientras que en una memoria con posiciones de 16 bits como la que se usará en este proyecto, seŕıan 4096 instrucciones. Aunque la arquitectura permite este direccionamiento, en la implementación final las memorias seŕan mucho más reducidas y no utilizarán todos los bits de éste tipo de instrucción. 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS 23 Diseño de una Arquitectura Didáctica ETSISI UPM 4.1.3 Repertorio de instrucciones El repertorio de instrucciones final cuenta con 13 instrucciones: Leyenda Rd: Registro destino Rr, Rs: Registro fuente dir: dirección de memoria inm: inmediato (dir): Contenido de la dirección de memoria dir. Instrucciones aritmético-lógicas Tipo Mnemónico Operandos Operación Modos de direccionamiento R ADD Rd, Rr, Rs Rd ← Rr + Rs Registro R SUB Rd, Rr, Rs Rd ← Rr - Rs Registro R CMP Rr, Rs Rr - Rs Registro R AND Rd, Rr, Rs Rd ← Rr ∧ Rs Registro R OR Rd, Rr, Rs Rd ← Rr ∨ Rs Registro R XOR Rd, Rr, Rs Rd ← Rr ⊕ Rs Registro Table 1: Instrucciones aritmético-lógicas. Figure 4: Formato de las instrucciones de tipo R. Instrucciones de transferencia de datos Tipo Mnemónico Operandos Operación Modos de direccionamiento I LD Rd, dir Rd ← (dir) Registro, directo I LDI Rd, inm Rd ← inm[7:0] Registro, inmediato I ST Rd, dir dir ← Rd Inmediato, registro I STI Rd, inm (Rd) ← inm[7:0] Indirecto, inmediato R MOV Rd, Rr Rd ← Rr Registro 24 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS ETSISI UPM Diseño de una Arquitectura Didáctica Table 2: Instrucciones de transferencia. Figure 5: Formato de las instrucciones de tipo I. El motivo por el que las instrucciones LDI y STI aceptan como segundo operando inm[7:0] es porque los registros son de 8 bits, y en el campo inmediato se escriben 9 bits. Por eso se trunca el valor introducido en el campo inmediato para que quepa en el registro destino. Instrucciones de salto Tipo Mnemónico Operandos Operación Modos de direccionamiento J JMP dir PC ← dir inmediato J BEQ dir Si FZ=1 PC ← dir inmediato Table 3: Instrucciones de salto. Figure 6: Formato de las instrucciones de tipo J. 4.1.4 Caracteŕısticas del juego de instrucciones Las 13 instrucciones que forman parte del repertorio condicionarán aspectos de diseño de la arquitectura tanto como el formato de las mismas. En primer lugar, se resumirán los modos de direccionamiento utilizados. Luego se expondrán algunas consideraciones. Modos de direccionamiento soportados Los modos de direccionamiento utilizados son: 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS 25 Diseño de una Arquitectura Didáctica ETSISI UPM � Inmediato En muchas instrucciones, los operandos se codificarán directa- mente en la instrucción. Este modo es sencillo de entender y de implementar pero tiene limitaciones y no es lo más interesante para los compiladores, ya que obliga que el campo inmediato esté calculado en tiempo de compilación y esto no siempre es posible. En muchas ocasiones resultaŕıa más útil que el operando se encontrase en un registro fijo (que śı se puede saber en tiempo de compi- lación), y cuando se averigüe el valor del inmediato en tiempo de ejecución, guardarlo en el registro correspondiente. Es una solución más versátil. � Registro Este modo es muy práctico y suele utilizarse en la mayoŕıa de reper- torios debido a su naturalidad y sencillez de implementación. � Directo Este modo se utiliza en dos instrucciones de transferencia de datos, por su utilidad y facilidad de implementación. � Indirecto Es utilizado en la instrucción STI. Resulta práctico y su imple- mentación no se complica demasiado. Este repertorio no se ha diseñado con la ortogonalidad como objetivo ni ha entrado en consideración durante ninguna etapa de diseño. Memoria direccionable Para analizar esto podemos dividir en dos tipos las instrucciones con acceso a memo- ria: las que acceden a memoria de instrucciones, y la que lo hacen a la de datos. � Instrucciones que acceden a memoria de datos: En esta categoŕıa se encuentran LD, ST y STI. En el caso de LD y ST, se utiliza el campo de inmediato/dirección para acceder a memoria, lo que nos da 9 bits de direc- cionamiento, es decir, 29 = 512 direcciones accesibles. En el caso de STI, accedemos a memoria por el contenido del registro Rd, de 8 bits, por lo que podemos acceder a 28 = 256 posiciones de memoria. � Instrucciones que acceden a memoria de instrucciones: En esta cat- egoŕıa entran JMP y BCE. Ya que ambas modifican el registro Contador de Programa de la misma forma, esto es, con el valor del campo inmediato de 12 bits, podrán direccionar directamente 212 = 4096 posiciones de la memoria de instrucciones. 26 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS ETSISI UPM Diseño de una Arquitectura Didáctica Instrucciones LDI y STI La importancia de estas instrucciones es crucial, ya que sin ellas no podŕıamos de ninguna forma introducir datos en registro o en memoria. Las instrucciones LD y ST permiten cargar en un registro un dato que se encuentra en memoria, o guardar en memoria un dato que se encuentra en un registro, pero inicialmente tanto la memoria como los registros carecen de contenido. Es por ello que para poder operar con datos, se necesita la forma de introducir datos de manera expĺıcita, y esto se logra con inmediatos. En otras arquitecturas también se pueden inicializar los valores de los registros o de la memoria mediante operaciones aritmético-lógicas. Por ejemplo, podŕıamos realizar la operación ADD EAX 0 1 para inicializar el valor del registro EAX a 1, pero las operaciones aritmético-lógicas de esta arquitectura no aceptan tampoco inmediatos, por lo que no sirve esta aproximación. Efectos a nivel de compilación El diseño de una arquitectura de computadores tendrá un inmenso efecto sobre el compilador encargado de traducir código de alto nivel al ensamblador propio de dicha arquitectura. Es por eso que determinadas estructuras y funcionalidades en el repertorio de instrucciones facilitarán o dificultarán el trabajo al compilador. � Registros de propósito general Los registros de propósito general son, por lo general, más eficientes y preferidos que sus alternativas, ya sean por acumulador o por stack. Debido en gran parte a que permiten un mayor manejo que las otras dos alternativas, sobretodo que el stack, que no permite accesos aleatorios. Pero principalmente debido a que los registros son varios órdenes de magnitud más rápidos que la memoria[17] [18]. � Instrucciones de salto Ambas instrucciones de salto utilizan un inmediato como modo de direccionamiento. Esta condición impone serias limitaciones al diseño del compilador, ya que necesitará saber la dirección destino del salto en tiempo de compilación. 4.2 Ruta de datos Una vez se ha realizado el repertorio de instrucciones y han quedado especifica- dos todos sus aspectos, es posible diseñar la ruta de datos. Para ello, primero se repasarán los componentes que necesitamos y se determinarán sus caracteŕısticas con un nivel mayor de detalle, ya que ahora se tiene posesión de un conocimiento que no se teńıa antes de especificar el juego de instrucciones. 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS 27 Diseño de una Arquitectura Didáctica ETSISI UPM 4.2.1 Especificación de los componentes de la ruta de datos Se mostrará una visión de bloque para cada componente que toma un papel funda- mental en la ruta de datos. La implementación y la visión interna de cada bloque se mostrará en secciones posteriores, entrando a valorar las caracteŕısticas que sean pertinentes. Unidad Aritmético Lógica (ALU) Aunque para realizar el diagrama de bloque de la ALU no era estrictamente necesario haber desarrollado el juego de instrucciones, śı se han especificado determinadas caracteŕısticas que permitirán detallar más el diagrama,como por ejemplo saber cuántas entradas de control serán necesarias. La Unidad Aritmético-Lógica podrá realizar en total cinco operaciones: ADD, SUB, AND, OR y XOR. La instrucción CMP también utiliza la ALU, pero en esencia es una operación SUB cuyo resultado no se escribe a registro (es descartado). Al realizar cinco acciones, necesitaremos tres bits para indicar qué acción queremos realizar, por lo que habrá tres señales de control. Además, es de interés que la ALU, además del resultado, genere como salida unas banderillas o indicadores (flags, en inglés) que aporten información extra al programador sobre el resultado. Es común que un procesador dedique un registro a contener todos los indicadores, normalmente llamado registro de estado. Las banderillas incluidas con más frecuencia son: � Zero Flag (ZF): Esta flag se pone a 1 cuando el resultado de la ALU es cero, y se pone a 0 en otro caso. � Overfow Flag (OF): El flag de Overflow o desbordamiento se activa en dos situaciones: – Cuando la suma de dos positivos da como resultado un negativo. – Cuando la suma de dos negativos da como resultado un positivo. Por lo que responde a la fórmula: (ResAB)∨(ResAB). El flag de Overflow o desbordamiento es sólo relevante en operaciones con signo. Se encarga de avisar de que ha habido un desbordamiento en el resultado y que por ello el resultado que se está dando es érroneo, ya que hace cumplir una de las dos situaciones descritas, que son imposibles de satisfacer a menos que haya un error. Este es además el motivo por el que no tiene relevancia en operaciones sin signo. 28 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS ETSISI UPM Diseño de una Arquitectura Didáctica � Parity Flag (PF): Esta flag indica si el resultado es par con un 0, o impar, con un 1. � Sign Flag (SF): Indica si el resultado es positivo con un 0, o negativo, con un 1. � Carry Flag (CF): Indica si la operación realizada necesita un bit más en la parte más significativa. Puede ocurrir en dos situaciones: – La suma de dos números produce acarreo en el bit más significativo: 1111 + 0001 = [1]0000. – La resta de dos números produce acarreo en el bit más significativo: 0000− 0001 = [1]1111. Figure 7: Vista de bloque de la ALU. Nombre Tipo Ancho Descripción A in 8 bits Entrada del primer operando, Rr. B in 8 bits Entrada del segundo operando, Rs. ALUOpX in 1 bit c/u Entrada de las señales de control que permiten. seleccionar la operación a realizar. Res out 8 bits Resultado de la operación. ZF out 1 bit Zero Flag OF out 1 bit Overflow Flag PF out 1 bit Parity Flag SF out 1 bit Sign Flag CF out 1 bit Carry Flag Table 4: Entradas y salidas de la ALU. 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS 29 Diseño de una Arquitectura Didáctica ETSISI UPM Banco de registros Con la información actual es posible hacer un mejor diseño del banco de registros. Sabiendo que tendremos ocho registros de propósito general, la continuación para hacer el diagrama de bloque es sencilla. Al igual que la ALU, el banco de registros aceptará señales de control para determinar si se va a escribir a registro o no. Figure 8: Vista de bloque del banco de registros. Nombre Tipo Ancho Descripción ReadR1 in 3 bits Selección del primer registro, Rr ReadR2 in 3 bits Selección del segundo registro, Rs RegSel in 3 bits Selección del registro resultado, Rd WriteData in 8 bits Entrada de datos para escribir en Rd WriteEn int 1 bit Entrada de la señal de control que activa la escritura en el registro seleccionado por WriteReg de los datos recibidos por WriteData. RData1 out 8 bits Salida de los datos contenidos en el registro seleccionado por ReadR1 RData2 out 8 bits Salida de los datos contenidos en el registro seleccionado por ReadR2 Table 5: Entradas y salidas del banco de registros. Contador de Programa El contador de programa será un registro que se encargará de actuar como puntero 30 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS ETSISI UPM Diseño de una Arquitectura Didáctica a la posición de la siguiente instrucción que ejecutar en la memoria de instrucciones. Dado el formato de las instrucciones de salto, se podŕıan direccionar directamente 212 = 4096 posiciones. Tradicionalmente, las memorias son direccionables a byte, es decir, que para guardar instrucciones de dos bytes como las propuestas, se utilizaŕıan dos posiciones de memoria. En arquitecturas donde la longitud de la instrucción es fija (sobretodo en arquitecturas RISC), se utiliza un desplazamiento a la izquierda sobre el campo dir de las instrucciones de slato. Aprovechando estas dos carac- teŕısticas (direccionalidad a byte e instrucciones de longitud fija), y sabiendo que para apuntar a una instrucción, siempre se apuntará a su primer byte, se puede observar que con instrucciones de, por ejemplo, 16 bits, el contador de programa siempre apuntará a instrucciones múltiplo de 2 porque apuntará al primer byte de cada dos. Esto resulta en que el programador pierde un bit de direccionamiento, ya que el bit menos significativo es siempre un cero expĺıcito. La solución consiste en hacer este cero (o ceros) impĺıcitos: el programador verá la memoria de instrucciones como formada por posiciones de 16 bits, en lugar de 8. La primera instrucción estará en la posición 0, la segunda en la posición 1 (en lugar de en la 2), la tercera en la posición 2 (en lugar de en la 4), etc., y se desplazará el campo inmediato un bit a la izquierda para recuperar esos dos d́ıgitos perdidos, convirtiendo la posición 1 en la 2, la posición 2 en la 4, y aśı. 0 0000 2 0010 4 0100 6 0110 8 1000 Ilustración simplificado a cuatro bits Esta técnica es muy interesante y se utiliza en la mayoŕıa de arquitecturas RISC, pero en la nuestra no será necesario, ya que las posiciones de la memoria de instruc- ciones serán directamente de 16 bits para que se presenten al programador tal y como son en la realidad, por facilidad y visión. Memorias Ambas memorias tendrán un diagrama de bloques muy parecido: Siendo n un número tal que 2n sea igual al número de posiciones de esa memoria. Tanto la memoria de datos como la de instrucciones tendrán 256 posiciones, es decir, 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS 31 Diseño de una Arquitectura Didáctica ETSISI UPM Figure 9: Diagrama de la memoria. Nombre Tipo Ancho Descripción din in m bits Datos que se quieran guardar en la posición apuntada por dir. dir in n bits Dirección de la que se quieren leer o guardar los datos de dir we in 1 bit Señal de control que permite la escritura en Memoria cuando está activada (cuando vale 1) clk in 1 bit Entrada de reloj. dout out m bits Datos contenidos en la dirección indicada por dir Table 6: Entradas y salidas del bloque de memoria. n = 8. En la memoria de instrucciones, el ancho de cada posición será de 16 bits (m = 16), y en la de datos será de 8 bits (m = 8). Los datos en ambas memorias seguirán la ordenación Big Endian, por ser la más intuitiva y no tener ningún otro motivo por el que . Ruta de datos La ruta de datos, después de incluir todos los componentes ya descritos tendŕıa la siguiente forma: Este diagrama incluye, en rojo, las señales de control que usaremos para controlar el funcionamiento de la arquitectura con cada instrucción concreta. Como se puede observar, sus componentes principales son el CP, las memorias de instrucciones y datos, el banco de registros y la ALU. Además de eso habrá también una Unidad de Control cuyo papel sea activar y desactivar determinadas señales de control en función de la decodificación de la instrucción que se está ejecutando en cada momento. Unidad de Control Aunque en la ruta de datos no aparezca la Unidad de Control, śı lo hacen las señales que ésta genera. Para el correcto funcionamiento de la arquitectura, es im- 32 4 DISEÑO DE LA ARQUITECTURA DE COMPUTADORAS ETSISI UPM Diseño de
Compartir