TFG_SEBASTIAN_LUCHETTI_MARTINEZ_BERNA

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