Sie sind auf Seite 1von 4

DCC/ICEX/UFMG

Nomes: Gustavo Guedes de Azevedo Barbosa, Vitor Gabriel Reis Caitite, Semar
Augusto da Cunha Mello Martins
Cursos: Bacharelado em Engenharia Elétrica (2), bacharelado em Ciência da
Computação
Disciplina: Organização de Computadores / Introdução à Arquitetura de Computadores
2º Semestre de 2017

Trabalho Prático 1
Introdução: O primeiro trabalho prático da disciplina “Organização de
Computadores I” foi muito interessante, mas também desafiador. Construir um
processador (obviamente restrito em suas funções, como foi o do trabalho em questão) é
um projeto que envolve muito compromisso e responsabilidade, pois é necessário saber
muito bem o propósito da máquina que está sendo projetada, uma vez que todos os seus
componentes serão arquitetados tendo em mente sua aplicação.
Apesar de que a construção do processador dessa atividade foi assistida por um
programa com uma interface gráfica interativa e de fácil assimilação, conhecemos os
reais desafios de se projetar uma verdadeira máquina. No entanto, a decisão de utilizar o
simulador “Hades” trouxe grandes benefícios quanto ao aprendizado e à visualização do
funcionamento do caminho de dados e a lógica de controle, tendo em vista a
possibilidade de visualização de todos os sinais em cada ciclo de clock do processador.

Desenvolvimento: Utilizando o simulador Hades e as bibliotecas padrão e


ufv, estruturamos primeiro o caminho de dados com seus subsets (para selecionar sinais
específicos de certos fios), registrador de uso especial (PC e constante 8 decimal),
unidades de memória, instrução e dados (separadas, conforme a arquitetura Harvard),
unidades lógicas e aritméticas (inclui o bloco somador) e os blocos extensores de sinal.
Logo após, adequamos todos os blocos para que pudessem se comunicar sem
problemas, ou seja, as saídas terem os mesmos tamanhos das entradas, e ligamos os
fios.
Então partimos para o desenvolvimento da lógica de controle, instalando no
processador os MUXes (e ajustamos seus sinais de entrada e saída conforme citado
anteriormente), instalamos os botões de clock (que foi ligado ao PC, ao banco de
registradores e à memória de dados, pois esses componentes são voláteis, portanto
devem ser restritamente síncronos) e de reset (ligado somente ao PC, para apontar para
o início do programa se quisermos reiniciá-lo), instalamos a ROM e o expansor de sinal
para destrinchar os sinais vindos da saída da ROM e ligamos os fios dos sinais em seus
respectivos componentes (será descrito melhor posteriormente).
Para rodar os programas que serão posteriormente citados, é necessário iniciar a
ROM com o arquivo “control_data.rom”, zerar os registradores, a memória de dados e o
PC. Então insira na memória de instruções um dentre os seguintes arquivos:
“custom_instructions_data.rom” ou “test_ctl.rom”, cujas finalidades são citadas adiante.
Resultado: Ao final das inserções de blocos, unidades e fios ditas
anteriormente o processador está pronto para ser testado e validado. Fizemos então dois
programas, um sem nenhuma lógica, foi usado para nos certificarmos que os sinais de
controle estavam todos corretos e outro que faz uma subtração, salva o resultado e o
subtraendo. Foi nomeado “test_ctl.rom” o programa de teste que contém instruções, na
ordem: ALU IMM, ALU REG, ALU IMM, LOAD IMM, ALU SRC, LOAD SRC
STORE IMM, STORE SRC, BRANCH IMM, BRANCH REG. Verificamos que todos
os sinais de controle estavam corretos e então partimos para testar o software que
subtrai dois números e guarda na memória de dados o resultado e o subtraendo,
nomeado “custom_instructions_data.rom”.
Para rodar o programa de subração, basta passar por sete bordas de subida de
clock e avaliar os resultados na memória de dados e no banco de registradores. Segue o
resultado esperado ao final do programa:
- Memória de dados: Todos os valores dos endereços devem ser zero, com estas
exceções:
MEM[1] = 0xa (Resultado da subtração)
MEM[2] = 0x6 (Subtraendo)
- Banco de registradores: Todos os valores nos registradores devem ser zero,
com estas exceções:
R1 = 0x6 (Subtraendo)
R2 = 0xa (Resultado da subtração)
R3 = 0x5 (Apontador para a memória de dados, para salvar os resultados)
(Ambos os programas seguem junto à documentação e ao processador no arquivo .zip).
A tabela de sinais tomou essa forma e foi confirmada após os testes:

Os sinais que saem do expansor da ROM geraram essa tabela na qual:


- mem_branch é o sinal que a ROM retorna no caso de um BRANCH. Esse se junta,
em uma porta AND, ao sinal que a ALU retorna caso a condição do BRANCH seja
satisfeita, causando um desvio na execução do programa.
- reg_data é o sinal que entra em um MUX e define qual dado vai ser salvo no banco de
registradores, 0 é o dado retornado pela memória de dados (no caso de um LOAD) e 1 é
o dado retornado da operação da ALU. (Como o sinal reg_write está em 0 para os casos
de STORE e BRANCH, o sinal de reg_data não importa, pois nada será escrito nos
registradores, porém, conforme os testes experimentais, foram constatados os sinais
mostrados na tabela).
- alu_in2 são dois sinais que vem do expansor e se juntam, por meio de um “merge”,
em um fio que transporta dois sinais e são responsáveis por definir, por meio de um
MUX 3x1, qual será um dos operandos da ALU. As opções são: para “00”, o resultado
da extensão de sinal do IMM, presente na palavra da instrução; para “01” o valor no
registrador “src” cujo endereço está na palavra da instrução; para “10”, o resultado da
extensão de sinal do Offset, também presente na palavra da instrução. O sinal “11” não
é utilizado.
- alu_in1 é o sinal que entra em um MUX e é responsável por definir o outro operando
da ALU, as opções são: 0 para o valor do registrador “dst” e 1 para o valor de “src”,
ambos tem endereços definidos na palavra da instrução apontada por PC.
- reg_write é o sinal que entra no bloco do banco de registradores e define se a
informação presente na entrada de dados desse bloco vai ser escrita (sinal 1) ou não
(sinal 0) no registrador apontado pelo endereço de “dst”, na palavra da instrução.
- mem_in é o sinal que entra no bloco da memória de dados e define se a informação
presente na entrada de dados desse bloco, que será escrita no endereço apontado pelo
resultado da ALU, vem dos registradores (sinal 0) ou da extensão de sinal do IMM
(sinal 1).
- mem_rea é o sinal que entra no bloco da memória de dados e define se o valor
existente no endereço apontado pelo resultado da ALU será retornado (sinal 1) ou não
(sinal 0).
- mem_write é o sinal que entra no bloco da memória de dados e define se o valor
presente na entrada de dados desse bloco será escrito no endereço apontado pelo
resultado da ALU (sinal 1) ou não (sinal 0).
Conclusão: A utilização do simulador gráfico Hades foi de suma importância
para nossa visualização e melhor compreensão do funcionamento de um processador
simples. Porém, o conhecimento adquirido durante o desenvolvimento do trabalho será
indispensável na construção de máquinas cada vez mais complexas, além de contribuir
na visualização das linguagens de descrição de hardware presentes hoje no mercado,
que são extremamente verbais e de difícil assimilação para iniciantes. O Trabalho
Prático 1 também foi crucial para entender as lógicas de controle em hardware e a forma
de mapeamento por meio de memória ROM.