Metodologia para adaptação de microarquiteturas ... · III UFRN / Biblioteca Central Zila Mamede....
123
II Leonardo Augusto Casillo Metodologia para adaptação de microarquiteturas microprogramadas soft-core à uma ISA padrão: Estudo do Impacto sobre a complexidade de hardware para o padrão MIPS Natal, RN, julho de 2013 Tese de doutorado apresentada ao Programa de Pós- graduação em Engenharia Elétrica e de Computação da Universidade Federal do Rio Grande do Norte, como parte dos requisitos necessários para obtenção do grau de Doutor em Ciências.
Transcript of Metodologia para adaptação de microarquiteturas ... · III UFRN / Biblioteca Central Zila Mamede....
II
Leonardo Augusto Casillo
Metodologia para adaptação de microarquiteturas
microprogramadas soft-core à uma ISA padrão:
Estudo do Impacto sobre a complexidade de hardware
para o padrão MIPS
Natal, RN, julho de 2013
Tese de doutorado apresentada ao Programa de Pós-
graduação em Engenharia Elétrica e de Computação da
Universidade Federal do Rio Grande do Norte, como
parte dos requisitos necessários para obtenção do grau
de Doutor em Ciências.
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE- UFRN
CENTRO DE TECNOLOGIA – CT
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
E DE COMPUTAÇÃO
Metodologia para adaptação de microarquiteturas
microprogramadas soft-core à uma ISA padrão:
Estudo do Impacto sobre a complexidade de hardware
para o padrão MIPS
Leonardo Augusto Casillo
Orientador: Prof. Dr. Ivan Saraiva Silva
Natal, RN, julho de 2013
III
UFRN / Biblioteca Central Zila Mamede.
Catalogação da Publicação na Fonte.
Casillo, Leonardo Augusto.
Metodologia para adaptação de microarquiteturas microprogramadas
soft-core à uma ISA padrão: estudo do impacto sobre a complexidade de
hardware para o padrão MIPS. / Leonardo Augusto Casillo. – Natal, RN,
2013.
122 f.: il.
Orientador: Prof. Dr. Ivan Saraiva Silva.
Tese (Doutorado) – Universidade Federal do Rio Grande do Norte.
Centro de Tecnologia. Programa de Pós-Graduação em Engenharia
Elétrica e de Computação.
1. RISP - Processadores - Tese. 2. MIPS - Tese. 3. ISA - Tese. 4.
Engenharia Elétrica e de Computação - Tese. I. Silva, Ivan Saraiva. II.
Universidade Federal do Rio Grande do Norte. III. Título.
RN/UF/BCZM CDU 004.23
IV
V
Agradecimentos
Este não é apenas o texto final após um doutorado de 5 anos, mas um capítulo
que se encerra de um sonho e parte de um projeto de vida que se iniciou em 1998, após
a primeira aula do curso de engenharia de computação e ao final do discurso de
motivação do saudoso coordenador Prof. Marcelo Mariano, quando tive a certeza de que
queria seguir a vida acadêmica. Sou grato a todos os que me ajudaram, incentivaram e
torceram por mim, e a todos os professores e profissionais que contribuíram com minha
educação desde o ensino fundamental no Colégio Maristela, ensino médio no Inst.
Maria Auxiliadora, graduação na UnP-Natal, mestrado e doutorado na UFRN. Não
poderei listar aqui o nome de todos, mas de igual modo não posso deixar de manter
impresso os meus profundos agradecimentos a algumas pessoas especiais que
contribuíram diretamente para que este momento fosse possível.
Agradeço a Deus pelo dom da vida, por ter me dado força, paciência, saúde e
motivação quando foi necessário. Por mais que tenha tido algumas faltas, a religião e
religiosidade foram extremamente importantes nesta caminhada. Um agradecimento
especial ao Padre Lucas, que me acompanha desde minha primeira comunhão.
Imagino que o sonho de quase todo pai era ter um filho doutor. Esta até era uma
meta, mas a descoberta de não suportar ver sangue me fez procurar outros caminhos.
Mas, desculpem a sinceridade, doutor é quem tem doutorado. Então, a meus pais
Francisco e Cristina Casillo, que dedicaram sua vida para me dar a melhor saúde e
educação possível, ofereço este título, todo o meu amor, carinho e gratidão, embora
palavras não sejam suficientes para agradecer por tudo.
Aproveito para agradecer a todos os meus familiares próximos por terem
aguentado 60 meses de mau-humor em um nível ainda maior do que o habitual. A má
notícia é que o stress continuou, apenas os motivos é que são de natureza diferente.
Portanto, para minha irmã Lígia, meu cunhado Tarcísio, meus sobrinhos Yasmim e
Rafael, meus sogros Danilo e Cícera, minha cunhada Danise e seu marido Emanuel,
obrigado pela paciência.
VI
Estudei muito na minha graduação, me esforcei ao máximo, mas sempre exigi
que esta dedicação fosse uma via de mão dupla. Admito também que não a pessoa mais
fácil para se conviver. Talvez por isso tenha discutido com quase todos os meus
professores. Minhas desculpas e agradecimentos aos professores Aarão, Alan, Antônio,
Oscar e demais por todos os ensinamentos e conselhos durante minha jornada
acadêmica. E foi em uma destas brigas que ganhei uma orientadora e amiga. Professora
Nádja Santiago, muito deste título eu devo a você. Muito obrigado por tudo.
Nádja também me apresentou a seu orientador após o término de meu TCC. E
sem nunca ter me visto anteriormente, me aceitou como aluno de mestrado. E mesmo
após algumas dificuldades e tribulações, novamente me aceitou como aluno de
doutorado. Novas dificuldades, afastamento de ambos para cidades diferentes, mas
ainda assim assumiu os riscos de continuar sendo meu orientador. Portanto, divido esta
conquista e agradeço ao Prof. Ivan Saraiva por confiar em mim e por permitir e me
ajudar na concretização deste objetivo.
Agradeço também a todos os coordenadores e colegas das instituições de ensino
em que estive como professor: UFRN, FAL, FATERN e UERN, onde a troca de
experiências e convivência profissional reforçou ainda mais minha paixão pela sala de
aula. Em 2009 ingressei como professor efetivo da UFERSA / Mossoró, e encarei o
desafio de conciliar as pesquisas com atividades de ensino. Agradeço aos coordenadores
do curso durante este período, professores Judson e Danniel, e ao corpo docente que
compreendeu minha situação, dando suporte e apoio para concluir meu trabalho.
Neste período tive muitos alunos. Pela carga de trabalho pesada, nem sempre
pude corresponder em sala de aula às expectativas dos alunos e ministrar as disciplinas
da melhor maneira possível. O meu agradecimento especial aos meus orientandos de
TCC e iniciação científica Álamo, Dênis, Julyana, Cadu, Wilka e Valter. O lado
gratificante é constatar que alunos podem se tornar amigos.
Deixo para o final meu agradecimento para a maior incentivadora de meu
trabalho. A pessoa que me deu forças, sofreu ao meu lado em todos os momentos
difíceis, aguentou todas as cargas de stress, não me deixou desistir nas várias vezes em
que fraquejei. Foi minha esposa, protetora, professora, revisora, companheira e melhor
amiga. Para o meu amor Danielle Simone, também não cabem palavras para agradecer
tudo o que você fez por mim. Esta vitória é nossa. Este mérito também é seu. Agora
somos um casal de doutores e que sejamos sempre uma família feliz. Te amo e obrigado
por tudo.
VII
Resumo
No meio acadêmico, é comum a criação de processadores denominados
didáticos, voltados para práticas de disciplinas de hardware na área de Computação e
que podem ser utilizados como plataformas em disciplinas de softwares, sistemas
operacionais e compiladores. Muitas vezes, tais processadores são descritos sem uma
ISA padrão, o que exige a criação de compiladores e outros softwares básicos para
prover a interface hardware/software dificultando sua integração com outros
processadores e demais dispositivos. Utilizar dispositivos reconfiguráveis descritos em
uma linguagem do tipo HDL permitem a criação ou modificação de qualquer
componente da microarquitetura, ocasionando a alteração das unidades funcionais do
caminho de dados que representa a parte operativa de um processador, bem como da
máquina de estados que implementa a unidade de controle do mesmo conforme surgem
novas necessidades.
Em particular, os processadores RISP possibilitam a alteração das instruções da
máquina, permitindo inserir ou modificar instruções, podendo até mesmo se adaptar a
uma nova arquitetura. Este trabalho aborda como objeto de estudo dois processadores
didáticos soft-core descritos em VHDL com diferentes níveis de complexidade de
hardware adaptados a uma ISA padrão a partir de uma metodologia proposta sem
provocar aumento no nível de complexidade do hardware, ou seja, sem o acréscimo
significativo da área em chip, ao mesmo tempo em que o seu nível de desempenho na
execução de aplicações permanece inalterado ou é aprimorado. As modificações
também permitem afirmar que, além de ser possível substituir a arquitetura de um
processador sem alterar sua organização, um processador RISP pode alternar entre
diferentes conjuntos de instrução, o que pode ser expandido para alternância entre
diferentes ISAs, permitindo a um mesmo processador se tornar uma arquitetura híbrida
adaptativa, passível de ser utilizada em sistemas embarcados e ambientes
multiprocessados heterogêneos.
Palavras-chave: RISP, MIPS, reconfiguração de instruções, adaptação de ISA
VIII
Abstract
In academia, it is common to create didactic processors, facing practical
disciplines in the area of Hardware Computer and can be used as subjects in software
platforms, operating systems and compilers. Often, these processors are described
without ISA standard, which requires the creation of compilers and other basic software
to provide the hardware / software interface and hinder their integration with other
processors and devices. Using reconfigurable devices described in a HDL language
allows the creation or modification of any microarchitecture component, leading to
alteration of the functional units of data path processor as well as the state machine that
implements the control unit even as new needs arise.
In particular, processors RISP enable modification of machine instructions,
allowing entering or modifying instructions, and may even adapt to a new architecture.
This work, as the object of study addressing educational soft-core processors described
in VHDL, from a proposed methodology and its application on two processors with
different complexity levels, shows that it’s possible to tailor processors for a standard
ISA without causing an increase in the level hardware complexity, ie without significant
increase in chip area, while its level of performance in the application execution remains
unchanged or is enhanced. The implementations also allow us to say that besides being
possible to replace the architecture of a processor without changing its organization,
RISP processor can switch between different instruction sets, which can be expanded to
toggle between different ISAs, allowing a single processor become adaptive hybrid
architecture, which can be used in embedded systems and heterogeneous multiprocessor
environments.
Keywords: RISP, MIPS, instruction set configurations, ISA adaptation
IX
Sumário
Capítulo 1 – Introdução .................................................................................................... 1
1.1. Motivação .......................................................................................................... 3
1.2. Objetivos ............................................................................................................ 6
1.3. Estrutura do documento ..................................................................................... 7
Capítulo 2 – Fundamentação Teórica ............................................................................... 8
2.1. Processadores Acadêmicos ................................................................................ 8
2.2. Processadores Reconfiguráveis ........................................................................ 13
2.3. Processadores RISP ......................................................................................... 17
2.4. Processadores soft-core .................................................................................... 18
2.5. Processadores microprogramados .................................................................... 19
2.6. Arquitetura MIPS ............................................................................................. 20
2.7. Processadores MIPS ........................................................................................ 27
2.8. Considerações .................................................................................................. 30
Capítulo 3 – Estado da arte ............................................................................................. 32
3.1. Tradução Binária .............................................................................................. 33
3.2. Considerações .................................................................................................. 39
Capítulo 4 – Microarquiteturas microprogramadas propostas ........................................ 40
4.1 Processador CABARE ..................................................................................... 40
4.1.1. Reconfiguração de instruções .............................................................................. 45
4.1.2. Exemplo de funcionamento ................................................................................. 49
4.2. Processador CRASIS ....................................................................................... 51
4.2.1. Modos de funcionamento .................................................................................... 54
4.2.2. Exemplo de funcionamento ................................................................................. 58
4.2.3. Unidade de Reconfiguração ................................................................................ 61
4.2.4. Exemplo de reconfiguração ................................................................................. 63
4.3. Interface com a placa DE2 ............................................................................... 63
Capítulo 5 – Metodologia para adaptação a uma ISA padrão ........................................ 65
5.1. Registradores ................................................................................................... 67
5.2. Unidade Lógica e Aritmética ........................................................................... 68
5.3. Instruções de Branch ....................................................................................... 71
X
5.4. Comunicação com a memória .......................................................................... 72
5.5. Instruções load/store ........................................................................................ 73
5.6. Considerações .................................................................................................. 73
Capítulo 6 – Aplicações e Resultados ............................................................................ 74
6.1. Adaptação 1: Processador DIMBA .................................................................. 74
6.1.1. Registradores ....................................................................................................... 75
6.1.2. ULA ..................................................................................................................... 75
6.1.3. Instruções de Branch ........................................................................................... 76
6.1.4. Comunicação com a memória ............................................................................. 77
6.1.5. Instruções de Load/Store ..................................................................................... 77
6.1.6. Reconfiguração .................................................................................................... 78
6.1.7. Análise Comparativa ........................................................................................... 83
6.2. Adaptação 2: Processador CRASIS II ............................................................. 85
6.2.1. Registradores ....................................................................................................... 85
6.2.2. ULA ..................................................................................................................... 86
6.2.3. Instruções de Branch ........................................................................................... 86
6.2.4. Comunicação com a memória ............................................................................. 87
6.2.5. Instruções de Load/Store ..................................................................................... 87
6.2.6. Reconfiguração .................................................................................................... 87
6.2.7. Análise Comparativa ........................................................................................... 89
6.3. Exemplo de uma aplicação .............................................................................. 92
6.4. Considerações .................................................................................................. 95
Capítulo 7 – Conclusões e Perspectivas ......................................................................... 97
7.1. Trabalhos Futuros ............................................................................................ 99
Referências Bibliográficas ............................................................................................ 101
Apêndice A - Codificação dos formatos de Instruções no MIPS-I .............................. 105
Apêndice B - Codificação dos formatos de Operações no CRASIS ............................ 107
XI
Lista de Figuras
Figura 2.1 – Modelo de máquinas multinível ................................................................... 9
Figura 2.2 – Arquitetura MIC-1 ..................................................................................... 11
Figura 2.3 – Configuração básica de um FPGA ............................................................. 14
Figura 2.4 – Exemplo de um modelo de arquitetura RISP ............................................. 17
Figura 2.5 – processador PLASMA ............................................................................... 19
Figura 2.6 – Diagrama de blocos de um pipeline MIPS ................................................. 27
Figura 2.7 –MIPS monociclo ......................................................................................... 27
Figura 2.8 –MIPS multiciclo .......................................................................................... 28
Figura 2.9 –MIPS pipeline.............................................................................................. 29
Figura 3.1 – Mecanismo de tradução binária em dois níve ............................................ 34
Figura 3.2 – Unidades do mecanismo de tradução binária ............................................. 35
Figura 3.3 – Configuração de uma unidade reconfigurável da arquitetura DIM ........... 38
Figura 4.1 - Arquitetura do processador CABARE ........................................................ 41
Figura 4.2 – Distribuição de memória no CABARE ...................................................... 46
Figura 4.3 – Sequência de execução de instruções reconfiguradas no CABARE .......... 48
Figura 4.4 – Diagrama de blocos do processador CRASIS ............................................ 51
Figura 4.5 – Formatos de instrução do CRASIS ............................................................ 52
Figura 4.6 – Arquitetura do processador CRASIS ......................................................... 53
Figura 4.7 – Diagrama de estados simplificado do CRASIS ......................................... 54
Figura 4.8 – Diagrama de estados de um super-estado .................................................. 56
Figura 4.9 – Exemplo de execução de instrução no CRASIS ........................................ 58
Figura 4.10 – Unidade de Reconfiguração do CRASIS ................................................. 61
Figura 4.11 – diagrama de estados de reconfiguração no CRASIS................................ 62
Figura 5.1 - Fluxograma de multiplicação por algoritmo de Booth ............................... 69
Figura 5.2 – Fluxograma de uma divisão por algoritmo de Booth ................................. 70
Figura 6.1 – Visão geral do processador DIMBA .......................................................... 74
Figura 6.2 – Áreas de memória do processador DIMBA ............................................... 79
Figura 6.3 – Codificação da instrução MFHI ................................................................. 81
XII
Figura 6.4 – Codificação da instrução ADD .................................................................. 82
Figura 6.5 – Comparação do caminho de dados (a) CABARE x (b) DIMBA ............... 83
Figura 6.6 – Visão geral do CRASIS II .......................................................................... 85
Figura 6.7 – Comparação do caminho de dados (a) CRASIS I x (b) CRASIS II........... 90
Figura 6.8 – Processo de simulação de um algoritmo no CABARE .............................. 94
Figura 6.9 – Processo de simulação de um algoritmo no DIMBA ................................. 95
XIII
Lista de Tabelas
Tabela 2.1 Formato de instruções MIPS ........................................................................ 22
Tabela 2.2 Descrição das convenções de uso dos registradores do MIPS ..................... 24
Tabela 2.3 Conjunto de instruções MIPS-1 .................................................................... 26
Tabela 4.1 – Registradores de uso geral no CABARE ................................................... 42
Tabela 4.2 – Operações da ULA do CABARE .............................................................. 42
Tabela 4.3 – Operações realizadas pelo processador CABARE .................................... 43
Tabela 4.4 – Sinais do controle do CABARE em cada instrução/tempo ....................... 44
Tabela 4.5 - Configuração de uma microinstrução no CABARE .................................. 47
Tabela 4.6 – Formatos de microinstruções do CABARE ............................................... 48
Tabela 4.7 – Código objeto para o exemplo 1 ................................................................ 50
Tabela 4.8 – Operações realizadas pelo processador CRASIS ...................................... 55
Tabela 4.9 – Palavra de uma microinstrução no CRASIS .............................................. 59
Tabela 4.10 – Bits de controle do CRASIS .................................................................... 59
Tabela 4.11 – Chaves para seleção dos displays de 7 segmentos na DE2 ..................... 64
Tabela 6.1 – Operações da ULA do DIMBA ................................................................. 75
Tabela 6.2 – Formatos de microinstruções do DIMBA.................................................. 79
Tabela 6.3 – Formato de uma microinstrução no DIMBA ............................................. 80
Tabela 6.4 – Síntese dos processadores CABARE e DIMBA ....................................... 84
Tabela 6.5 – Palavra de uma microinstrução no CRASIS II .......................................... 88
Tabela 6.6 – Síntese do processador variando conjuntos de instruções ......................... 91
XIV
Lista de Abreviaturas
ALU – Arithmetic Logic Unit
ASIC – Application Specific Integrated Circuit
ASIP – Application Specific Instruction set Processor
CABARE – Computador Acadêmico Básico com Reconfiguração
CISC – Complex Instruction Set Computer
CLB – Configurable Logic Blocks
CodOp – Código da Instrução
CRASIS – Computer with Reconfigurable And Selectable Instruction Set
CRIS – Computer with Reconfigurable Instruction Set
CRISP – Configurable and Reconfigurable Instruction Set Processor
DCM - Digital Clock Manager
DIMBA – Didactic MIPS Basic Architecture
EEPROM –Electrically-Erasable Programmable Read-Only Memory
FFUs – Fixed Functional Units
FPGAS – Field Programmable Gate Arrays
FSM – Finite State Machine
HDL – Linguagens de Descrição de Hardware
IOB – Input/Output Blocks
IP – Propriedade Intelectual
ISA – Instruction Set Architectures
IJVM - Integer Java Virtual Machine
JTAG - Joint Test Action Group
LPM_RAM – Library of Parameterized Modules RAM
LUI – Load Upper Immediate
MAC – Multiplicador e Acumulador
MAR – Memory Address Register
MBR – Memory Buffer Register
MFHI – Move From HI Register
XV
MIF – Memory Initialization File
MIPS (ISA) – Microprocessor without Interlocked Pipeline Stages
MIPS (Métrica) – Milhões de Instruções Por Segundo
MPSoC – Multiprocessor System On Chip
MSB – Most Significative Bit
OCP – Open Core Protocol
PBL – Problem-Based Learning
PC – Personal Computer
PRISC – PRogrammable Instruction Set Computer
PRISM – Processor Reconfigurable through Instruction-Set Metamorphosis
RFU – Reconfigurable Functional Unit
RISC – Reduced Instruction Set Computer
RISP – Reconfigurable Instruction Set Processor
RTL – Register Transfer Level
SoC – System on Chip
SP – Stack Pointer
SPARC - Scalable Processor ARChitectures
SRC – Shift Right with Carry
TIPI – Tiny Instruction Processors and Interconnect
ULA – Unidade Lógica e Aritmética
US – Microssegundos (unidade)
VISC – Variable Instruction Set Communications Architecture
VLIW – Very Long Instruction Word
1
Capítulo 1 – Introdução
Desde a década de 2000 até os dias atuais, a tecnologia aplicada aos
processadores está relacionada à era dos multicores [Knight, 2005]. De fato, nos últimos
anos a justificativa para se adquirir um novo computador pessoal era o aumento da sua
frequência de operação ou uma nova placa-mãe que suportasse maiores quantidades de
memória. Com o limite de velocidade de operações praticamente estagnado em virtude
das limitações físicas dos equipamentos, por exemplo, quanto à sua dissipação de calor,
buscou-se a inserção de diversos núcleos para continuar com o progresso em relação ao
desempenho e também continuar a movimentar o mercado financeiro quanto à venda de
computadores.
Atualmente, é notório que os computadores pessoais do tipo PC (Personal
Computer) estão sendo substituídos por versões portáteis como netbooks, ultrabooks,
tablets, smartphones e demais dispositivos móveis, que suprem as necessidades de
pessoas que querem utilizar recursos simples como aplicativos para escritório e redes
sociais, restando aos PCs e notebooks multicores para o nicho de mercado composto por
engenheiros, cientistas e demais profissionais que requerem aplicativos que demandem
maior desempenho computacional como ferramentas de desenho técnico, computação
gráfica e programação.
Entretanto, os computadores não são utilizados apenas nos meios industriais e
comerciais. A área acadêmica é fundamental para a pesquisa por novas formas de
tecnologias e estudos para aprimoramento dos hardwares e softwares necessários para
sua utilização. Em cursos como Ciência e Engenharia da Computação ou demais cursos
em áreas afins de tecnologia, é fundamental que professores e estudantes conheçam o
funcionamento de cada componente eletrônico que compõe a arquitetura de um
computador, suas linguagens de programação em vários níveis de abstração e os
softwares básicos que proveem sua utilização, tais como compiladores e sistemas
operacionais, além de ferramentas para simulação e prototipagem de tais dispositivos
2
para a realização de testes quanto à sua funcionalidade. Nesse sentido, muitas
universidades estão propondo a seus alunos a criação de arquiteturas próprias,
denominadas arquiteturas didáticas ou processadores acadêmicos.
Tais processadores são, em sua maioria, do tipo RISC (Reduced Instruction Set
Computer), e são úteis para algumas disciplinas nos cursos de graduação da área de
computação, como sistemas digitais, arquitetura de computadores, sistemas
operacionais, softwares básicos, compiladores, entre outras disciplinas de hardware e
software que envolvam o projeto e construção de circuitos digitais e o suporte para o
desenvolvimento de suas aplicações.
Atualmente, estas arquiteturas podem ser facilmente descritas devido ao uso de
dispositivos reconfiguráveis como FPGAS (Field Programmable Gate Arrays), que
surgiram na década de 1980 [Carter et al., 1986] e hoje já está consolidada no meio
acadêmico. Tais dispositivos, entre outras vantagens, permitem a descrição, simulação e
síntese de circuitos digitais de qualquer nível de complexidade de hardware – desde que
respeitando os limites físicos de cada dispositivo – em campo, podendo ser modificado
a qualquer momento, sem a necessidade da fabricação do chip como um processador de
uso geral ou um processador ASIC (Application Specific Integrated Circuit) [Compton
& Hauck, 2002].
Explorar as capacidades de dispositivos reconfiguráveis impulsiona o uso de
processadores implementados apenas por meio de Linguagens de Descrição de
Hardware (HDL), geralmente chamados de Soft-core. Este modelo permite a projetistas
e estudantes criarem novas unidades funcionais e alterar arquiteturas anteriormente
criadas [Tong et al., 2006].
A liberdade quanto à descrição dos componentes do caminho de dados de um
processador acadêmico, sem a necessidade de seguir determinado padrão, provem a
cada processador características próprias que o fazem único. Tais características podem
suprir a falta de alguma funcionalidade em um sistema embarcado ou ainda um
processador pode ser útil para o desenvolvimento de alguma aplicação ou para a
execução de programas específicos atuando no modo stand alone. Mas a falta de
padronização de sua arquitetura ou conjunto de instruções pode inviabilizar o uso deste
processador em um sistema multiprocessador heterogêneo ou se tornar incompatível
com demais sistemas físicos ou ainda outros experimentos microarquiteturais
acadêmicos desenvolvidos por outros alunos ou universidades. Com relação ao
desenvolvimento e execução de programas, deverão ser desenvolvidos compiladores
3
para permitir a tradução de programas desenvolvidos em linguagens de alto nível como
C ou Java para a linguagem assembly adotada por cada microarquitetura e simuladores
para verificar o correto funcionamento da execução de suas instruções.
Estes problemas de compatibilidade podem ser resolvidos utilizando padrões
conhecidos de Arquiteturas de Conjunto de Instruções (ISA – Instruction Set
Architectures). Com a adoção de uma ISA, é possível utilizar compiladores já
desenvolvidos e inserir o processador em um ambiente MPSoC (Multiprocessor System
On Chip) [Kumar, 2005] heterogêneo de ISA única. As modificações para um
processador se adaptar ao padrão de uma ISA estão relacionadas à utilização de um
conjunto de instruções específico e algumas restrições em seu caminho de dados, como
a quantidade mínima de registradores e do tamanho da palavra de dados.
1.1. Motivação
No meio acadêmico, processadores sem uma ISA padrão dificultam a sua
utilização em aulas práticas, exigindo a criação de compiladores e outros softwares
básicos como assemblers, loaders e linkers para prover a interface hardware/software,
sendo necessária também a disseminação de tais programas para permitir a outros
usuários a utilização da arquitetura. Caso contrário, será necessário escrever programas
para tais arquiteturas utilizando a linguagem assembly, com os formatos e instruções
específicas criadas para esta arquitetura, sem a opção de reutilização de código em
outros processadores. A Computação Reconfigurável, ao propiciar a criação ou
modificação de qualquer processador descrito em uma linguagem do tipo HDL, permite
que o caminho de dados ou a máquina de estados que implementa a unidade de controle
possam ser reescritos e alterados conforme surgem novas necessidades.
A Computação Reconfigurável é um paradigma de computação que combina a
flexibilidade do software com o alto desempenho do hardware [Compton, 2002]. Por
causa de suas duas principais características (desempenho e flexibilidade), dispositivos
reconfiguráveis são utilizados para projetar desde um simples circuito lógico contendo
apenas alguns elementos lógicos até sistemas complexos como arquiteturas SoC
(System on Chip), processadores ASIC, Sistemas Embarcados ou demais arquiteturas
adaptativas, não convencionais e acadêmicas.
Esses sistemas computacionais podem ser utilizados em uma vasta gama de
aplicações, incluindo sistemas embarcados, industriais, pessoais e computação móvel
4
[Ferlin & Pilla, 2006]. Além destas, o uso de FPGAs está em crescimento no suporte às
ferramentas de ensino em disciplinas de graduação em Computação. A possibilidade de
explorar o desenvolvimento de sistemas digitais em diferentes níveis de complexidade,
da especificação à prototipagem, permite aos alunos uma melhor compreensão de
requisitos de hardware e software.
O processo de criação de uma nova microarquitetura não precisa seguir uma
metodologia específica ou conter uma ISA padrão. No entanto, embora permita uma
maior liberdade de criação ao projetista de hardware, possibilitando o desenvolvimento
de novos circuitos digitais ou mesmo arquiteturas não convencionais, isto dificulta a
utilização destes sistemas digitais em MPSoCs ou sistemas embarcados, devido a
limitações da sua compatibilidade com outros sistemas de arquiteturas.
Já em relação ao meio acadêmico, experimentos genéricos de microarquiteturas
sem um padrão de instruções torna o processador um modelo isolado, necessitando de
diversas adaptações de hardware e software para que tal modelo possa se comunicar
com outros processadores, co-processadores ou demais componentes físicos e executar
programas, além de restringir o uso de compiladores e simuladores disponíveis para
arquiteturas já fundamentadas como MIPS, SPARC, ARM e x86. Dependendo da
quantidade de alterações em seu caminho de dados, este pode se tornar até mesmo um
novo processador e perder suas características próprias.
Duas técnicas podem ser utilizadas para minimizar este problema. A primeira é a
utilização de microprogramas para a descrição de um processador Soft-Core. As
arquiteturas microprogramadas fazem com que todo o ciclo de funcionamento de um
processador esteja descrito em VHDL como se fosse a sequência de um programa
descrito de forma estrutural. Com isso, todas as etapas de busca, decodificação,
execução, salvamento e interrupção estão presentes dentro da unidade de controle do
processador, que por um lado aumenta sua complexidade em hardware, mas por outro
lado torna o caminho de dados do processador - unidade operativa ou Datapath - com
sua estrutura preservada ou com poucas modificações caso sejam necessários incluir,
remover ou alterar suas funcionalidades.
A segunda técnica é um complemento da anterior, que pode tornar o processador
ainda mais independente quanto à complexidade de seu caminho de dados, sendo
possível aumentar sua capacidade operacional quanto à execução de instruções. Tal
técnica se refere à inclusão de uma lógica de reconfiguração, fazendo com que a
arquitetura didática se torne um processador do tipo RISP (Reconfigurable Instruction
5
Set Processor). Processadores RISP podem criar ou combinar novas instruções em
tempo de execução para serem utilizadas juntamente com o conjunto de instruções de
uma ISA padrão [Barat & Lauwereins, 2000]. Uma vez que os processadores didáticos
foram descritos utilizando-se HDL’s, tais modificações em sua estrutura física podem
ser realizadas a partir do reuso de componentes e estruturas previamente
implementadas.
Este estudo propõe uma metodologia para adaptação de arquiteturas
microprogramadas Soft-Core descritas em VHDL sem um padrão para uma
determinada ISA, na qual são identificadas quais as alterações necessárias em suas
unidades operativas para que seja possível executar as instruções pertencentes ao seu
novo conjunto de instruções, sem perder suas características originais ou aumentar seu
nível de complexidade de hardware. Para aplicação desta metodologia, foram utilizadas
duas microarquiteturas microprogramadas descritas na linguagem VHDL, com
diferentes caminhos de dados, sendo ambas adaptadas à arquitetura MIPS
(Microprocessor without Interlocked Pipeline Stages) [MIPS, 2008], e utilizando o
conjunto de instruções MIPS-I.
O padrão MIPS foi escolhido em virtude de sua vasta utilização acadêmica,
sendo sua arquitetura RISC e suas alternativas de implementação com modos
monociclo, multiciclo e pipeline utilizadas adotadas como plataformas de ensino em
livros de arquitetura de computadores, como em [Patterson, 2008], que permitem
transmitir as noções básicas de como um processador é projetado e implementado. Sua
arquitetura possui vários níveis ascendentes de conjuntos de instruções, de acordo com
o aumento de sua complexidade de hardware, incluindo as versões MIPS I a MIPS V,
com versões em 32 e 64 bits [Sweetman, 2006]. Além de sua simplicidade e clareza, a
arquitetura base para construção de vários simuladores, como ProcSIM [ProcSIM,
2013], MARS [MARS, 2013], WebSimple [WebSimple, 2013], SPIM [Larus, 2013],
entre outros, e influenciou outras ISAs como a SPARC (Scalable Processor
ARChitectures), desenvolvida pela Sun Microsystems® [Oracle, 2013].
Em adição, será provado que é possível que uma microarquitetura se torne um
processador RISP, possibilitando a utilização de instruções não presentes ao seu
conjunto original, ou seja, prover instruções MIPS que não estejam incluídas no
conjunto de instruções do processador, aumentando sua gama de aplicações, desde que
o caminho de dados do processador possua os componentes e a estrutura necessária para
executar corretamente as novas instruções. Por serem arquiteturas microprogramáveis,
6
ao incluir novas unidades de execução como comparadores, multiplicadores ou
operações na ULA (Unidade Lógica e Aritmética), são necessárias poucas adaptações
no código de descrição de suas unidades de controle, como a inclusão de novos sinais
de controle ou a criação de microprogramas que proveem o funcionamento de novas
instruções com base nas unidades funcionais anexadas ou a partir da lógica de
reconfiguração incorporada ao processador.
É importante ressaltar que a metodologia proposta neste trabalho não busca
substituir a metodologia de ensino de arquitetura de computadores ou disciplinas
correlatas, mas sim apresentar uma forma de adaptar processadores pré-existentes com
estrutura genérica ou com uma determinada arquitetura a um novo padrão, preservando
as características físicas originais da microarquitetura, propiciando a estudantes e
pesquisadores uma nova ferramenta de auxílio durante suas práticas de ensino, além de
aumentar a gama de aplicações e exploração de projetos em seus experimentos
arquiteturais acadêmicos. Até o momento da finalização deste documento, não foram
encontrados na literatura outros trabalhos que tenham por objetivo a adaptação de
arquiteturas ou de conjuntos de instruções a uma ISA padrão utilizando dispositivos
reconfiguráveis microprogramados.
1.2. Objetivos
Esta tese consiste em apresentar uma metodologia para adaptação de
processadores microprogramados para o padrão MIPS. Para tanto, foram utilizados dois
processadores acadêmicos RISC genéricos microprogramados como estudos de caso
para a aplicação dos passos necessários, a fim de que o novo padrão de arquitetura e o
conjunto de instruções MIPS-I possam ser executados nas novas versões de suas
microarquiteturas. A obtenção de tal objetivo decorre das seguintes etapas:
A partir do processador CABARE (Computador Acadêmico Básico com
Reconfiguração), criar o processador DIMBA (Didactic MIPS Basic
Architecture);
A partir do processador CRASIS (Computer with Reconfigurable And
Selectable Instruction Set), criar o processador CRASIS II;
Comparar cada versão original com sua versão adaptada MIPS,
apresentando as modificações quanto a área em chip e alterações na
7
execução de uma aplicação sequencial com relação a quantidade de
ciclos de relógio;
Mostrar como os processadores DIMBA e CRASIS II podem incorporar
e executar instruções MIPS além das que foram previamente inseridas no
conjunto de instruções de suas arquiteturas.
1.3. Estrutura do documento
Os capítulos foram dispostos da seguinte forma:
Capítulo 1: este primeiro capítulo introduziu o assunto, abordou a motivação
para a realização do presente trabalho bem como os objetivos deste estudo e apresentou
a organização do texto.
Capítulo 2: neste capítulo é realizada uma fundamentação teórica abordando
conceitos gerais sobre processadores reconfiguráveis, em especial processadores RISP,
o que são arquiteturas microprogramadas e uma abordagem sobre o padrão MIPS e o
conjunto de instruções MIPS-I.
Capítulo 3: será descrito o estado da arte sobre adaptação, conversão ou
tradução entre diferentes ISA’s em hardware e software.
Capítulo 4: serão apresentadas as características básicas de dois processadores
soft-core, RISP sem uma ISA padrão.
Capítulo 5: será apresentada a metodologia utilizada para adaptar os
processadores anteriormente descritos para uma Arquitetura de Conjunto de Instruções
padrão, utilizando como base a arquitetura MIPS.
Capítulo 6: apresenta os estudos de caso após as modificações propostas,
detalhando o funcionamento das novas arquiteturas e comparando as versões adaptadas
com as versões originais.
Capítulo 7: são expostas as conclusões e perspectivas futuras sobre as
afirmações, processadores e metodologias abordadas.
8
Capítulo 2 – Fundamentação Teórica
2.
Neste capítulo são descritos alguns conceitos acerca de processadores
reconfiguráveis, soft-core, microprogramados e RISP, além de abordar com mais
detalhes o padrão de arquitetura MIPS e seu conjunto de instruções MIPS-I.
2.1. Processadores Acadêmicos
Os processadores acadêmicos, também denominados processadores didáticos,
são comumente desenvolvidos por alunos e professores da área de hardware de cursos
de ciências e engenharia de computação, como exercícios práticos envolvendo os
aspectos de arquitetura e organização de computadores ou plataformas de ensino para a
execução de programas em linguagens de baixo nível e desenvolvimento de softwares
básicos e simuladores. A popularização e redução dos custos de kits de
desenvolvimentos em FPGAs propiciam um maior estímulo de estudantes e
pesquisadores no projeto e implementação destes experimentos microarquiteturais, por
meio da descrição de módulos dos processadores utilizando alguma linguagem de
descrição de hardware e simulação e síntese de tais arquivos em dispositivos
reconfiguráveis por meio de softwares específicos de acordo com seu fabricante, como
por exemplo, o Quartus II da Altera®
[Altera, 2013].
A primeira etapa de qualquer curso de arquitetura e organização de
computadores é estabelecer a diferença entre os dois conceitos. Por arquitetura,
[Stallings, 2010] afirma que são os atributos visíveis para o programador, podendo citar
como exemplos o conjunto de instruções da máquina, o conjunto de registradores, as
técnicas de endereçamento á memória, mecanismos de Entrada e Saída (E/S) e
representação dos dados. A organização de um computador especifica as unidades
funcionais e suas formas de interconexão para a implementação de uma determinada
arquitetura, ou seja, a organização refere-se à implementação de uma arquitetura. Dentre
as características que compõem a organização de um computador estão a estrutura
9
interna do processador, barramentos internos, sinais de controle disponíveis, tecnologias
de memória e interface com o sistema de E/S. Portanto, arquiteturas de uma mesma
família, como Intel®
ou IBM®
podem conter diferentes recursos de organização, mas
manter uma compatibilidade no que tange aos conjuntos de instruções das máquinas.
Na literatura, duas abordagens se destacam quanto ao desenvolvimento de uma
microarquitetura. A primeira é apresentada por [Tanenbaum, 2007], na qual um modelo
de abstração em camadas ou níveis é definido para o projeto e implementação de
arquiteturas de computadores. Em cada uma destes níveis, o computador pode ser
programado utilizando os recursos desse nível, que pode ser compreendido como uma
máquina virtual para execução de programas descritos no seu nível superior. A Figura
2.1 apresenta um modelo de máquinas multinível proposto pelo autor composto por seis
níveis.
Figura 2.1 – Modelo de máquinas multinível
Fonte: [Tanenbaum, 2007]
10
Cada nível é responsável por interpretar as instruções do nível imediatamente
superior. O nível 0 é composto por circuitos lógicos que executam os programas em
linguagem de máquina por meio da execução de funções lógicas simples (AND, OR,
XOR, NOT, etc). No nível 1, os circuitos lógicos são agrupados a fim de formar
elementos mais complexos, como a Unidade Lógica e Aritmética (ULA) e registradores,
que formam uma memória local. Estes elementos são conectados formando o caminho
de dados do processador (data path).
As operações podem ser controladas por um microprograma ou diretamente por
hardware, sendo o microprograma um interpretador para as instruções do nível 2, de
modo que o microprograma busca, decodifica e executa as instruções provenientes do
nível 2 utilizando o caminho de dados como estrutura para realização desta tarefa. Caso
seja utilizado um controle via hardware, o ciclo de funcionamento de uma instrução é
realizado sem a necessidade de um programa armazenado para interpretar as funções.
O nível 2 define a interface entre o hardware e o software. Cada fabricante
define uma linguagem própria, conhecida como linguagem Assembly ou linguagem de
montagem, para sua estrutura de hardware construída. Esta linguagem determina o
conjunto de instruções da máquina executáveis pelo processador, que deve ser
documentado em manuais específicos pelo fabricante. Além dos formatos e tipos de
instruções, também são definidos os tipos de dados, modelos de memória e tipos de
endereçamento. Portanto, este nível define a Arquitetura do Conjunto de Instruções
(ISA – Instruction Set Architecture).
O nível 3 suporta novas instruções e fornece serviços básicos para as camadas
superiores, como escalonamento de processos, gerenciamento de memória, acionamento
de dispositivos de E/S, interface com o usuário, etc. A partir deste nível, as camadas
superiores são destinadas a programadores de sistema, enquanto as camadas inferiores
destinadas a programadores de aplicação. O nível 4 tem o intuito de fornecer uma
ferramenta para programadores de aplicativos de uso geral, e os programas
desenvolvidos neste nível recebem o nome de montadores ou Assemblers.
Uma linguagem de montagem é uma forma simbólica de representar linguagens
de mais baixo nível, de modo que os programas nessa linguagem são traduzidos para as
linguagens dos níveis 1, 2 e 3 e depois interpretados por uma máquina virtual ou real.
No último nível estão os programas desenvolvidos em linguagens de alto nível, voltados
para a criação de aplicativos. Estes programas precisam ser traduzidos para os níveis 3
11
e/ou 4 por meio de um tradutor denominado compilador ou por algum interpretador
como no caso de linguagens como Java ou Python.
Os níveis 0 a 2 são os níveis mais abordados durante a disciplina de arquitetura e
organização de computadores, sendo que o nível 0, por ser formado por circuitos
lógicos, é visto com mais detalhes em disciplinas de circuitos lógicos / lógica digital. O
nível 3 pode ser melhor abordado em disciplinas específicas de Sistemas Operacionais,
enquanto que os níveis 4 e 5 são discutidos em disciplinas de Software Básico e
Compiladores. Dependendo do projeto de arquitetura, a quantidade e os níveis podem
variar, assim como podem ser realizadas outras abordagens para o desenvolvimento de
um computador.
Para exemplificar sua abordagem, Tanenbaum utilizou uma máquina fictícia
chamada MAC para ilustrar o conceito de microprogramação e criou a arquitetura
didática multiciclo MIC, implementada em quatro versões (MIC-1, MIC-2, MIC-3 e
MIC-4), dedicada a executar um subconjunto das instruções da Máquina Virtual Java
chamado IJVM (Integer Java Virtual Machine). A arquitetura MIC-1 pode ser
visualizada na Figura 2.2
Figura 2.2 – Arquitetura MIC-1
Fonte: [Tanenbaum, 2007]
12
A metodologia aplicada por [Patterson, 2008] constrói um computador a partir
do seu conjunto de instruções. O autor cita que a arquitetura de um computador é
formado pela junção dos aspectos de organização de computadores e arquitetura do
conjunto de instruções (ISA). Segundo o autor, a ISA de um computador é um nível de
abstração que oferece a interface entre o nível de hardware e o software de baixo nível,
responsável pela padronização dos tipos e formatos de instrução, quantidade e
disposição dos bits que compõem uma instrução, tipos de operandos, quantidade de
registradores necessários, modos de endereçamento e de acesso às palavras ou bytes,
organização da memória, etc. O conjunto de instruções da arquitetura forma a
linguagem de máquina do computador, que é a base para a construção das unidades
operativa e de controle do processador.
Inicialmente são definidas quais as instruções aritméticas, lógicas, de desvio,
transferência de dados, controle e de Entrada/Saída que serão utilizadas pelo
computador. Adicionalmente, podem ser inseridas instruções de gerenciamento de
memória, ponto flutuante e outras especiais. Após a escolha da quantidade e tipos de
instruções, os componentes físicos necessários para a execução das instruções são
projetados, inseridos e conectados, como por exemplo, desenvolver uma Unidade
Lógica e Aritmética (ULA) para prover as instruções aritméticas presentes no seu
conjunto de instruções.
Patterson utiliza como base para os conceitos de arquitetura e organização a
arquitetura MIPS e o conjunto de instruções MIPS-I. Essa forma de abordagem visa
explorar a interface hardware-software de modo a unir os conceitos de programação e
circuitos digitais. A metodologia de Patterson sugere que, de acordo com a arquitetura
do conjunto de instruções, deva ser definida uma estrutura organizacional macro,
composta pelo número de unidades funcionais, sendo esta estrutura refinada para definir
os componentes do caminho de dados, sua interconexão e sua unidade de controle. A
arquitetura MIPS é apresentada sob três variações: monociclo, multiciclo e pipeline, que
serão detalhadas adiante.
Existem outras abordagens na literatura, como por exemplo, a metodologia
proposta por [Stallings, 2010], a qual utiliza estudos de caso com arquiteturas reais,
como Pentium e PowerPC, para tratar os aspectos de arquitetura e organização de
computadores, fazendo uma distinção entre estes.
Dentre as propostas experimentais existentes, uma abordagem de ensino que está
sendo utilizada em algumas universidades utiliza a metodologia de aprendizagem
13
baseada em problemas (PBL – Problem-Based Learning) [Martinez-Mones et al, 2005],
[Dos Santos, 2007]. Na fase inicial desta abordagem, denominada etapa de situação, o
aluno é apresentado a um determinado problema real, e apresentando fenômenos e
objetos que o motive a adquirir novos conhecimentos técnicos para a resolução do
problema. Na segunda etapa, ocorre a fundamentação teórica necessária para a
resolução do problema identificado na etapa de situação, iniciando uma reflexão crítica
sobre o problema aplicado. Na fase final deste ciclo, denominada etapa de realização, o
aluno deve utilizar os conceitos teóricos estudados para a produção de um produto final,
aproximando a teoria aprendida com a prática, e permitindo ao aluno a compreensão da
realidade apresentada.
2.2. Processadores Reconfiguráveis
Apesar desta metodologia de adaptação não necessitar de nenhuma
reconfiguração no hardware do dispositivo, as microarquiteturas utilizadas neste
trabalho são processadores RISP, descritos na linguagem VHDL e sintetizados em
dispositivos reconfiguráveis FPGAs (Field Programmable Gate Arrays), fato este que
justifica uma breve explanação sobre os conceitos e características gerais de tais
processadores.
Um FPGA é um dispositivo semicondutor utilizado para o processamento de
informações digitais. Foi criado pela Xilinx Inc.® [Xilinx, 2013] em 1985 como um
dispositivo que programado de acordo com as aplicações de um usuário programador.
Um FPGA é composto basicamente por três tipos de componentes de lógica
programável: blocos de entrada e saída (IOB – Input/Output Blocks), blocos lógicos
configuráveis (CLB – Configurable Logic Blocks) e chaves de interconexão (Switch
Matrix) [Brown, 1992]. Os blocos lógicos são dispostos de forma bidimensional, e as
chaves de interconexão são dispostas em formas de trilhas verticais e horizontais entre
as linhas e as colunas dos blocos lógicos. Cada um desses blocos pode servir como
entrada, saída ou acesso bidirecional a outros pinos de I/O e podem ser programados
para efetuar operações lógicas básicas ou combinatórias complexas e podem ser
configurados pelo projetista após a fabricação do dispositivo para implementar qualquer
função lógica ou circuito complexo em campo [Rose et AL., 1992]. A Figura 2.3
apresenta a configuração básica de um FPGA.
14
Figura 2.3 – Configuração básica de um FPGA
Fonte: [Brown, 1992]
Para configurar uma FPGA deve ser especificado um diagrama esquemático do
circuito ou um código-fonte em uma linguagem HDL (Hardware Description
Language) que descreve a lógica com que o dispositivo irá funcionar. Para converter
diagramas/HDL para configurações físicas em um FPGA, é necessário enviar o código-
fonte por um software disponibilizado pelo fabricante. Este arquivo é transferido para o
FPGA por uma interface serial JTAG (Joint Test Action Group) ou para memória
externa como uma EEPROM.
Além dos recursos padrões (slices), um FPGA pode disponibilizar em seu
arranjo bidimensional recursos adicionais como multiplicadores dedicados, MACs
(Multiplicador e Acumulador) programáveis, blocos de memória, DCM (Digital Clock
Manager), utilizados para multiplicar ou dividir a frequência de um sinal de relógio,
microcontroladores (IBM PowerPC), e outras bibliotecas. A utilização de tais recursos
embarcados possibilita otimizar a área do dispositivo e desenvolver projetos mais
complexos e eficientes [Anderson, 2006]
As arquiteturas reconfiguráveis foram sendo desenvolvidas e aprimoradas de
acordo com a disponibilidade de tecnologia e visando a resolução de novos problemas e
desafios. De acordo com [Mesquita, 2002], a partir do amadurecimento da tecnologia de
FPGAs, as arquiteturas reconfiguráveis foram criadas com o intuito principal de
aumentar o desempenho de algoritmos que até então eram executados em software. A
15
diferença entre processadores reconfiguráveis é dada por características como: grau de
acoplamento entre o processador e a lógica reconfigurável, tipo de instruções a serem
executadas pela lógica reconfigurável, formato de codificação e passagem de
parâmetros das instruções reconfiguráveis, acesso à memória por parte da lógica
reconfigurável entre outras características relevantes para o desempenho de
processadores reconfiguráveis [Mooler et al., 2005].
Os processadores reconfiguráveis estendem a capacidade de um processador,
otimizando seu conjunto de instruções para uma tarefa específica. Com isto é obtido um
aumento de desempenho e flexibilidade, ao mesmo tempo em que a área do núcleo do
processador permanece inalterada [Mooler et Al., 2005]. Para fazer uma avaliação a
respeito de processadores reconfiguráveis, algumas medidas básicas de avaliação são
necessárias, tais como desempenho, custo e tamanho.
A medida de desempenho geralmente é associada à velocidade de execução das
instruções básicas (MIPS – Milhões de Instruções Por Segundo) ou o tempo gasto em
ciclos de relógio para a execução de aplicações como, por exemplo, benchmarks. O
custo é geralmente analisado em termos de parâmetros como: número de pinos, área em
chip, número de chips por sistema, entre outros. Com relação ao tamanho de programas
e dados, este pode ser expresso através da capacidade máxima e a eficiência de
ocupação do código gerado. Outras restrições como, peso, volume e consumo de
potência podem ser consideradas de acordo com a aplicação.
De acordo com [Adário et al., 1997], uma arquitetura reconfigurável possui
como principais metas: acréscimo de velocidade e da capacidade de prototipagem,
representado pelo número de portas lógicas equivalentes, proporcionando aumento de
desempenho; reconfiguração dinâmica; baixo consumo na reconfiguração;
granularidade adequada ao problema, entre outros. A melhoria de desempenho de
sistemas é uma das principais utilizações das arquiteturas reconfiguráveis devido a
possibilidade da implementação de algoritmos complexos nos atuais processadores
diretamente no hardware.
O primeiro processador de propósito geral acoplado a um FPGA foi denominado
PRISM (Processor Reconfigurable through Instruction-Set Metamorphosis), em 1993
por (ATHANAS; SILVERMAN, 1993). Devido à limitação da tecnologia dos FPGAs
da época, somente era possível desenvolver um sistema fracamente acoplado, no qual
um FPGA comunicava-se com um processador por meio de um barramento.
16
O primeiro processador dito reconfigurável foi denominado PRISC
(PRogrammable Instruction Set Computer), em 1994 por [Razdan & Smith, 1994].
PRISC foi o primeiro a explorar na pratica a existência de uma RFU (Reconfigurable
Functional Unit) contida em um caminho de dados de um processador MIPS. Neste
processador, assim como para os demais representantes da primeira geração de
processadores reconfiguráveis, verificou-se a eficiência da utilização de FPGAs para
aplicações específicas, aumentando o desempenho com relação a soluções
implementadas em software. O problema principal era o gargalo de comunicação entre
o processador e os FPGAs e o alto tempo de reconfiguração. O fato da reconfiguração
ser estática impunha a interrupção da execução para que o sistema possa ser
reconfigurado.
Com a evolução da tecnologia de integração, surgiu a segunda geração de
processadores reconfiguráveis, tornando possível o desenvolvimento de um sistema
composto pelo processador, FPGAs e memória em um único chip, resultando no
embrião do que hoje se identifica por SoC. Também foi possível o desenvolvimento de
processadores utilizando-se reconfiguração dinâmica.
O processador CRISP (Configurable and Reconfigurable Instruction Set
Processor), proposto originalmente por [Barat, 2002] possui a característica de ser
configurável em tempo de desenvolvimento e reconfigurável em tempo de execução.
Consiste em um processador VLIW (Very Long Instruction Word), que executa
instruções compostas por operações paralelas, executadas em unidades funcionais fixas
(FFUs - Fixed Functional Units) e uma unidade funcional reconfigurável.
Em 2003 surgiu a arquitetura VISC (Variable Instruction Set Communications
Architecture), apresentado por [Liu et al., 2003]. A característica que diferencia o
conjunto de instruções deste processador dos demais é a utilização de um dicionário que
define o tipo de cada instrução e permite ao compilador configurar o melhor conjunto de
instruções para a execução de um determinado programa.
Desde então, diversas versões de FPGAS comerciais e acadêmicos foram e estão
sendo desenvolvidos. Alguns destes processadores receberam características
específicas, como a possibilidade de modificar ou inserir novas instruções na máquina.
Estes processadores são denominados RISP (Reconfigurable Instruction Set Processors
– Processador com conjunto de instruções reconfigurável).
17
2.3. Processadores RISP
Um processador com conjunto de instruções reconfigurável consiste em um
núcleo microprocessado estendido com uma lógica reconfigurável. Este é similar a um
ASIP (Application Specific Instruction set Processor), mas em vez de unidades
funcionais especializadas, que contém as unidades funcionais reconfiguráveis, esta
proporciona a adaptação do processador para a aplicação, enquanto o núcleo do
processador fornece programabilidade em software [Barat, 2002].
[Lodi et al., 2003] classificou os Processadores com Conjunto de Instruções
Reconfiguráveis RISP como um subconjunto dos processadores reconfiguráveis. Estes
processadores não apresentam um custo de hardware para cada nova instrução em
hardware, mas sim um custo pré-definido em área onde a lógica reconfigurável pode ser
programada em tempo de execução [Mooler et al., 2005].
A Figura 2.4 apresenta um modelo hipotético de uma arquitetura RISP. O
processador RISP executa instruções, assim como processadores comuns e ASIPs,
embora a principal diferença esteja no conjunto de instruções, o qual é implementado
em hardware fixo, e um conjunto de instruções reconfiguráveis implementado na lógica
reconfigurável e que pode sofrer alterações durante a execução do processador [Barat
2002]. Este conjunto de instrução reconfigurável é equivalente ao conjunto de instrução
especializado de um ASIP, mas com a possibilidade de modificação após o processador
ter sido projetado.
Figura 2.4 – Exemplo de um modelo de arquitetura RISP
Fonte: [Barat 2002]
18
O custo de projeto de um microprocessador com núcleo é reduzido devido à
reutilização em diversas aplicações. Em ASIPs o custo de cada nova geração vem da
remodelação das unidades funcionais especializadas, que podem ser bastante elevados.
Técnicas de prototipagem rápidas são essenciais para reduzir o custo e o tempo
necessário para a remodelagem [Barat 2002].
2.4. Processadores soft-core
Um processador soft-core é um microprocessador que pode ser implementado
utilizando síntese lógica como, por exemplo, utilizando a linguagem de descrição de
hardware VHDL. [Tong, 2006] afirma que tais modelos de processadores possuem
diversas vantagens sobre processadores de propósito geral como redução de custos,
flexibilidade, plataformas independentes e capacidade de renovação.
Diversos fabricantes de FPGAS disponibilizam seus produtos para uso comercial
e acadêmico. Dentre estes, destacam-se os processadores Nios II, MicroBlaze,
PicoBlaze e Xtensa, dos fabricantes Altera®, Xilinx
® e Tensilica
®, respectivamente.
Além destas arquiteturas, comunidades científicas costumam disponibilizar
processadores Open-Cores [Opencores, 2013], que são componentes IP (Propriedade
Intelectual) que podem ser utilizadas livremente pela comunidade, para fins não
lucrativos. Destacam-se os processadores OpenSPARC [OpenSPARC, 2013], LEON
[Leon, 2013] e Plasma [Rhoads, 2013].
Dentre os processadores soft-core MIPS mais utilizados, o PLASMA [Rhoads,
2013] é um dos mais completos. Trata-se de um processador de código fonte aberto,
desenvolvido em VHDL, possui os cinco estágios de pipeline e implementa o mesmo
conjunto de instruções do MIPS R3000. A Figura 2.5 mostra a topologia lógica da
organização do PLASMA.
19
Figura 2.5 – processador PLASMA
Fonte: [Opencores, 2013]
O PLASMA, assim como o LEON e as versões do processador MIPS original,
por possuírem seu código-fonte aberto, estão disponíveis para a comunidade científica
para fins acadêmicos.
2.5. Processadores microprogramados
Em um processador microprogramado, toda a sua lógica de sua unidade de
controle é especificada através de um microprograma. Um microprograma, por sua vez
é composto por uma sequência de instruções de uma linguagem de microoperação. A
uma sequência de instruções em uma linguagem de microprogramação dá-se o nome de
microprograma. [Tanenbaum, 2007].
A ideia de um controle microprogramado surgiu na década de 1950 [Wilkes,
1951], para evitar a complexidade da implementação em hardware em um dispositivo e
começou a ser adotada na família i360 da IBM®. O circuito lógico destas unidades é
formado por uma sequência de microinstruções, contendo os sinais de controle para
executar cada etapa do microprograma e uma lógica de sequenciamento para decisão da
próxima microinstrução. Estes sinais de controle são enviados para a unidade operativa
(caminho de dados) do dispositivo, indicando o comportamento de cada unidade
20
funcional, como a operação da ULA, a codificação da seleção de multiplexadores ou a
habilitação de escrita em registradores.
A vantagem de um controle microprogramado sobre uma implementação em
hardware, além da redução da complexidade, é o fato de torná-la mais simples,
compreensível e menos sujeita a erros. Em contrapartida, sua execução é mais lenta e o
consumo de potência gerada pelo dispositivo é maior.
O projeto de processadores microprogramados depende da ISA que esta
implementada, bem como das metas de custo e desempenho. Das implementações de
processadores microprogramados, um trabalho de destaque é o de [Mihal et al., 2006],
no qual foi projetado um processador sub-RISC. Este processador é uma classe de um
processador ASIP, com arquitetura programável. Além disso, os autores criaram uma
ferramenta para gerar um processador sub-RISC de expressões regulares. Para isso foi
utilizado um framework denominado TIPI (Tiny Instruction Processors and
Interconnect), que auxilia na criação de um circuito sem a necessidade de programar
em uma linguagem HDL. Através da interpretação de autômatos, o framework gera o
código HDL do circuito e o mesmo é carregado em um FPGA.
2.6. Arquitetura MIPS
A arquitetura MIPS foi desenvolvida inicialmente como um projeto acadêmico
na Universidade de Stanford em 1981 por uma equipe de doutorandos e de mestrandos
chefiada por John Hennessy [Patterson & Hennessy, 2008]. Este projeto se tornou um
dos principais precursores da tecnologia RISC. A arquitetura do conjunto de instruções
MIPS-1 é regular, todas as instruções possuem o mesmo tamanho. Conforme
[Sweetman, 2006], esta característica permitiu que seus conceitos fossem assimilados
mais facilmente se comparado a arquiteturas irregulares.
Em 1984, foi fundada a empresa MIPS Computer Systems Inc. cujo objetivo foi
comercializar a tecnologia desenvolvida no meio acadêmico. As versões iniciais de
processadores MIPS usavam arquitetura de 32 bits, como o R2000 e o R3000. Versões
posteriores passaram a empregar arquitetura de 64 bits com a introdução do R4000.
Durante a evolução da família de processadores diversas revisões do conjunto de
instruções (ISA) MIPS foram realizadas, incluindo MIPS-I, MIPS-II, MIPSIII, MIPS-
IV, MIPS-V, MIPS32 e MIPS64. As duas últimas revisões são as especificações
atualmente disponíveis para 32 e 64 bits respectivamente. Em 1992, a MIPS Computer
21
Systems foi adquirida pela Silicon Graphics Computer Systems. Todas as revisões são
retroativamente compatíveis [Kane & Heinrich, 1991].
A arquitetura MIPS segue os princípios básicos de um projeto de hardware, para
que o processador criado seja simples, eficiente, livre de falhas e de baixo custo. A
representação de instruções MIPS segue um formato regular de campos, cada um com
uma função específica, seguindo o princípio de que “a simplicidade é favorecida pela
regularidade”. Cada instrução possui 32 bits, o mesmo tamanho de uma palavra de
memória ou uma palavra de dados. Apesar de possuir um tamanho fixo, são utilizados
diferentes formatos para tipos distintos de instruções.
Para alcançar o princípio de “quanto menor, mais rápido”, não são utilizadas
variáveis em linguagem de montagem, prática presente em linguagens de alto nível. O
MIPS utiliza 32 registradores, cada um representando uma palavra da arquitetura. Um
número maior de registradores acarreta um aumento na duração do ciclo de relógio, que
tornaria o sistema mais lento.
Outro princípio de projeto adotado pelo padrão MIPS é “tornar o caso comum
mais rápido”, pois a utilização de operandos imediatos ocorre com tal frequência em
linguagens de montagem que é preferível tratá-los como um caso comum ao invés de
instruções especiais.
Os conceitos básicos relacionados à arquitetura MIPS podem ser resumidos
pelas seguintes características:
execução implementada sobre um pipeline com cinco estágios;
conjunto de instruções regular, onde todas as instruções possuem
comprimento fixo (32 bits);
instruções lógicas e aritméticas compostas de três operandos: fonte, alvo e
destino;
32 registradores de propósito geral, cada um com 32 bits;
nenhuma instrução complexa, como gerenciamento de pilha ou operações
sobre cadeias de caracteres;
possibilidade de dar suporte nativo a até quatro co-processadores opcionais,
destinados ao gerenciamento do sistema, operações com ponto flutuante e
funcionalidades específicas;
22
instruções de acesso à memória exclusivas: load e store, tanto para memória
principal como para dispositivos periféricos, o que força o uso do conceito
de entrada e saída mapeada em memória;
espaço de endereçamento contínuo de 4GB para acesso à memória, alinhado
à palavra de 32 bits, com possibilidade de acesso à palavra (32 bits), meia
palavra (16 bits) ou byte (8 bits);
mapeamento de endereços virtuais para endereços reais;
código em linguagem de montagem otimizado pelo compilador, em
substituição à intervenção manual ou otimização via hardware;
A estrutura de hardware não verifica dependências de instruções.
O conjunto de registradores da arquitetura MIPS é constituído por três grupos de
registradores de 32 bits distintos: 32 para propósito geral, numerados de 0 a 31, dois
para operações de multiplicação e divisão (HI e LO) e um contador de programa (PC).
Todos os registradores de propósito geral podem ser usados como fonte ou destino de
dados para instruções lógico-aritméticas, acesso à memória e controle de fluxo. A única
exceção é o registrador 0 (zero), não alterável, que possui seu valor fixado em zero pelo
hardware, e utilizado como constante em operações aritméticas e de transferência de
dados. Portanto, operações de leitura deste registrador sempre retornam valor zero e as
de escrita são ignoradas, sendo o valor escrito descartado. O conjunto de instruções
MIPS-1 divide-se em três formatos básicos, conforme descrito na Tabela 2.1:
Tabela 2.1 Formato de instruções MIPS
em que:
opc: código de operação;
rs: endereço do registrador origem;
rt: endereço do registrador alvo (origem ou destino, conforme instrução
específica);
rd: endereço do registrador destino;
shamt: quantidade de deslocamento;
23
funct: função;
imm-16: constante imediata de 16 bits;
addr-26: endereço parcial de 26 bits.
As características de cada formato podem ser resumidas como segue.
Instruções com formato R (register): inclui instruções lógicas e aritméticas
com três registradores, inclusive multiplicação e divisão, instruções de
deslocamento de bits, desvio baseados em registrador e instruções de
exceções syscall e break. O campo funct atua como um campo adicional de
6 bits para identificação da instrução. O campo shamt é usado para indicar a
quantidade de bits a ser deslocada em instruções de deslocamento de bits.
Os registradores rs e rt são usados como origem de dados e rd como destino
do resultado da operação;
Instruções com formato I (immediate): incluem instruções de acesso à
memória (alinhado ou não), instruções lógicas e aritméticas que fazem uso
de constantes imediatas e instruções de desvio condicional (branches). O
registrador rs é usado como origem de dados e o rt como destino do
resultado da operação. O campo imm-16 contém um valor imediato de 16
bits usado de uma de duas formas: como valor literal (positivo ou negativo)
em instruções lógicas e aritméticas ou como um inteiro com sinal (entre -
32678 a +32467) indicando o deslocamento relativo a um registrador (modo
de endereçamento base-deslocamento);
Instruções com formato J (jump): inclui instruções de salto que usam modo
de endereçamento pseudo-direto. O campo addr-26 contém uma constante
(imediata) de 26 bits usada no cálculo do endereço absoluto alvo do desvio.
Este valor é acrescentado de 2 bits à esquerda, equivalente a uma
multiplicação por 4 devido ao uso de alinhamento de todo programa em
endereço múltiplo de quatro. Isto gera um endereço de 28 bits, que é então
concatenado com os 4 bits superiores do PC, ou seja, addr-26 indica o
deslocamento em quantidade de palavras não de bytes dentro da página de
memória (de 256 Mbytes) onde se encontra a instrução seguinte à instrução
de desvio.
24
Além da classificação das instruções MIPS-I quanto ao formato, também se
pode dividir o conjunto de instruções quanto à funcionalidade das instruções. Existem
três classes de instruções, conforme este critério:
Classe Padrão (Standard): caracterizada pelas instruções que possuem o
campo opc diferente de 0 ou 1 (zero ou um). Nesta classe enquadram-se as
instruções de acesso à memória (alinhado ou não), instruções lógicas e
aritméticas que fazem uso de constantes (imediatas), instruções de salto que
usam modo de endereçamento pseudo-direto e instruções de desvio
condicional que usam dois registradores;
Classe Especial (Special): caracterizada pelas instruções que possuem o
valor 0 (zero) no campo opc. Inclui instruções lógicas e aritméticas com três
registradores inclusive multiplicação e divisão, instruções de deslocamento
de bits, instruções de salto baseadas em registrador e as instruções para
tratamento de exceções syscall e break. O campo funct atua como campo
complementar ao opc, permitindo selecionar a operação desejada;
Classe Registrador-imediato (RegImm): caracterizada pelas instruções que
possuem o valor 1 (um) no campo opc. Inclui instruções de desvios
condicionais (branches) que comparam valores em relação a 0 (zero),
exceto as instruções blez e bgtz. O campo rt define qual o tipo de
comparação a ser realizada, portanto é usado em conjunto com o campo opc
para decodificar a instrução.
Embora os 32 registradores de propósito geral possam ser usados
indistintamente para qualquer objetivo (com exceção de $0), existe uma convenção para
o uso destes registradores em programação, com o objetivo de padronizar o
desenvolvimento de software básico, como montadores, compiladores e carregadores,
conforme a sequência exibida na Tabela 2.2. Estas convenções não implicam a
existência de qualquer estrutura no hardware que as dê suporte a elas.
Tabela 2.2 Descrição das convenções de uso dos registradores do MIPS
Número Nome Descrição do uso
0 Zero Valor zero
1 At Reservado para uso do montador (assembler temporary)
2-3 v0-v1 Valores retornados por sub-rotinas (returned value)
4-7 a0-a3 Primeiros 4 argumentos passados às sub-rotinas (arguments)
8-15 t0-t7 Uso livre para sub-rotinas (temporaries)
25
16-23 s0-s7 Valores preservados entre chamadas de sub-rotina, devem ser
restaurados após o retorno (saved)
24-25 t8-t9 Uso livre para sub-rotinas (temporaries)
26-27 k0-k1 Reservados para rotina de interrupção, usados pelo sistema operacional
(kernel)
28 gp Acesso às variáveis estáticas ou externs (global pointer)
29 SP Ponteiro para área de pilha (stack pointer)
30 Fp Ponteiro para área de frame (frame pointer)
31 Ra Endereço de retorno de sub-rotina (return address)
A arquitetura pipeline de cinco estágios pressuposta como natural para a
implementação do hardware de um processador MIPS inclui:
IF – estágio de busca (instruction fetch): busca a próxima instrução a ser
executada;
ID – estágio de decodificação (instruction decode): realiza a decodificação
da instrução e a leitura dos operandos fonte do banco de registradores;
EX – estágio de execução (execution): realiza a execução da instrução ou o
cálculo de endereço quando aplicável;
MEM – estágio de acesso à memória (memory access): realiza o acesso à
memória externa;
WB – estágio de escrita do resultado (write back): escrita do resultado no
banco de registradores.
A Tabela 2.3 apresenta o conjunto de instruções MIPS-I contendo a sintaxe e o
código de cada instrução. As instruções de tipo R possuem o mesmo CodOp 0x00,
sendo sua operação determinada pelo campo Func. Mais informações detalhadas sobre
o conjunto MIPS-1 encontram-se no Apêndice A.
26
Tabela 2.3 Conjunto de instruções MIPS-1
A Figura 2.6 apresenta um diagrama esquemático simplificado de um pipeline
típico do MIPS, conforme empregado para dispositivos com os MIPS R2000 e R3000.
Grupo Sintaxe Tipo Op Func Significado
lb Rdest, Imm16 (Rsrc) I 0x20 leitura de byte da memória
lw Rdest, Imm16 (Rsrc) I 0x23 leitura de palavra da memória
lbu Rdest, Imm16 (Rsrc) I 0x24 leitura de byte sem sinal da memória
sb Rsrc2, Imm16 (Rsrc1) I 0x28 escreve byte na memória
sw Rsrc2, Imm16 (Rsrc1) I 0x2b escreve palavra na memória
lui Rdest, Imm16 I 0x0f lad upper immediate
mfhi Rdest R 0 0x10 move de HI
mflo Rdest R 0 0x12 move de LO
mthi Rdest R 0 0x11 move para HI
mtlo Rdest R 0 0x13 move para LO
add Rdest, Rsrc1, Rsrc2 R 0 0x20 adiciona com overflow
addi Rdest, Rsrc1, Imm16 I 8 adiciona Imm com overflow
addu Rdest, Rsrc1, Rsrc2 R 0 0x21 adiciona sem overflow
addiu Rdest, Rsrc1, Imm16 I 9 adiciona Imm sem overflow
sub Rdest, Rsrc1, Rsrc2 R 0 0x22 subtrai com overflow
subu Rdest, Rsrc1, Rsrc2 R 0 0x23 subtrai sem overflow
mult Rdest, Rsrc1, Rsrc2 R 0 0x18 multiplica
multu Rdest, Rsrc1, Rsrc2 R 0 0x19 multiplica sem sinal
div Rdest, Rsrc1, Rsrc2 R 0 0x1a divide
divu Rdest, Rsrc1, Rsrc2 R 0 0x1b divide sem sinal
and Rdest, Rsrc1, Rsrc2 R 0 0x24 and
andi Rdest, Rsrc1, Imm16 R 0x0c and com imediato
or Rdest, Rsrc1, Rsrc2 R 0 0x25 or
ori Rdest, Rsrc1, Imm16 I 0x0d or com imediato
xor Rdest, Rsrc1, Rsrc2 R 0 0x26 xor
xori Rdest, Rsrc1, Imm16 I 0x0e xor com imediato
nor Rdest, Rsrc1, Rsrc2 R 0 0x27 nor
slt Rdest, Rsrc1, Rsrc2 R 0 0x2a set if less than
slti Rdest, Rsrc1, Imm16 I 0x0a set if less than Imm
sltu Rdest, Rsrc1, Rsrc2 R 0 0x2b set if less than sem sinal
sltiu Rdest, Rsrc1, Imm16 I 0x0b set if less than Imm sem sinal
sll Rdest, Rsrc1, Shamt5 R 0 0 desl. Lógico à esquerda
srl Rdest, Rsrc1, Shamt5 R 0 2 desl. Lógico à direita
sra Rdest, Rsrc1, Shamt5 R 0 3 desl. aritmético à direita
j address28 J 2 desvio incondicional
jr Rsrc R 0 8 desvio usando registrador
beq Rsrc1, Rsrc2, address18 I 4 desvia se igual (relativo)
bne Rsrc1, Rsrc2, address18 I 5 desvia se diferente (relativo)
bgez Rsrc, address18 I 1 1 desvia se maior ou igual a zero (rel)
bgtz Rsrc, address18 I 7 desvia se maior que zero (rel)
blez Rsrc, address18 I 6 desvia se menor ou igual a zero (rel)
bltz Rsrc, address18 I 1 0 desvia se menor que zero (rel)
jal address18 J 3 desvia e link de retorno
jalr Rsrc R 0 9 desvia e link de retorno c/ reg
rfe R 0x10 0x20 retorno de exceção
syscall R 0 0x0c chamada de sistema
break R 0 0x0d break
Transferência
de informação
Operações
Aritméticas
Operações
lógicas e de
comparação
Operações de
deslocamento
Instruções de
salto
Exceção
27
Figura 2.6 – Diagrama de blocos de um pipeline MIPS
Fonte: [Patterson, 2007]
2.7. Processadores MIPS
MIPS é acrônimo para Microprocessor without Interlocked Pipeline Stages, ou
microprocessador sem estágios de pipeline bloqueados. Tipicamente, arquiteturas
MIPS-I empregam um pipeline de 5 estágios: busca, decodificação, execução, acesso à
memória e escrita no banco de registradores. Nesta implementação de pipeline,se não
houver conflitos entre diferentes instruções executando simultaneamente, a cada ciclo
de relógio é realizada a execução de uma destas instruções.
Utilizando um conjunto de instruções como ponto de partida, inicialmente é
projetada uma implementação simples de caminhos de dados e de controle para prover a
execução destas instruções, formando uma arquitetura monociclo, como pode ser
visualizado na Figura 2.7.
Figura 2.7 –MIPS monociclo
Fonte: [Patterson, 2007]
28
Na implementação monociclo, um ciclo de relógio possui mesmo tamanho para
todas as instruções implementadas em seu conjunto. Este ciclo é definido pela instrução
de maior duração, no caso MIPS-I pela instrução Load Word. Como cada unidade
funcional somente pode ser utilizada uma vez por ciclo de relógio, a duplicação de
unidades funcionais acarreta em um maior custo de hardware.
A segunda alternativa de implementação é a versão MIPS multiciclo. A
execução de cada instrução é dividida em etapas, sendo que cada etapa necessita de um
ciclo de relógio. Assim, cada unidade funcional da arquitetura pode ser utilizada mais
de uma vez por instrução. Nesta versão, são inseridos os conceitos de
microprogramação e máquinas de estados finitos. A Figura 2.8 apresenta a versão do
MIPS multiciclo.
Figura 2.8 –MIPS multiciclo
Fonte: [Patterson, 2007]
As instruções do MIPS são executadas em ate 5 etapas:
1. Busca da instrução na memória;
2. Leitura dos registradores enquanto uma instrução é decodificada, (o
formato das instruções do MIPS permite que a leitura e a codificação
ocorram simultaneamente);
3. Execução de uma operação ou cálculo de um endereço;
4. Acesso a um operando de memória;
5. Escrita do resultado em um registrador;
29
Na versão MIPS pipeline, cada uma destas etapas é executada em um estágio do
pipeline. Cada estágio é geralmente denominado como:
1. BI ou IF Busca instrução
2. DI ou ID Decodificação da instrução
3. EX Execução ou cálculo de endereço
4. MEM Acesso à memória de dados
5. ER ou WB Escrita no banco de registradores
A versão MIPS pipeline contendo os 5 estágios de execução pode ser visualizada
na Figura 2.9.
Figura 2.9 –MIPS pipeline
Fonte: [Patterson, 2007]
Pela sua simplicidade, processadores MIPS são muito utilizados em
universidades para uso e desenvolvimento de processadores didáticos. muitos projetos
MIPS são utilizados em sistemas embarcados como gravadores de DVDs, modems,
roteadores Cisco e videogames como o Nintendo 64 e Playstation da Sony e
dispositivos móveis com Windows CE.
30
2.8. Considerações
Com relação às metodologias acadêmicas para projeto de arquiteturas de
computadores, é importante citar que este trabalho não apresenta uma nova metodologia
para o desenvolvimento de processadores nem propõe a substituição de qualquer
abordagem, visto que o objetivo é realizar uma adaptação de processadores já
previamente projetados para uma nova ISA. Contudo, por se tratar de uma metodologia
que toma por base o conjunto de instruções do processador para identificar as
modificações necessárias para a integração das unidades funcionais de um processador
para um novo padrão de instruções, a abordagem proposta por [Patterson, 2008] se
apresenta como a mais semelhante e adequada para o projeto e implementação de
microarquiteturas, o que não exclui qualquer outra abordagem de desenvolvimento de
processadores como procedimento inicial para aplicação desta metodologia de
adaptação.
Os processadores utilizados como exemplo de aplicação da metodologia
proposta foram descritos em VHDL e suas unidades de controle implementadas sob a
forma de um microprograma por opção dos autores, que entendem ser a melhor opção
para que as modificações necessárias ao processador com relação a alteração de sua ISA
sejam efetuadas, assim como a criação das técnicas de modificação de instruções para
que o processador possa ser classificado um RISP.
A maioria das arquiteturas reconfiguráveis realizam modificações no caminho de
dados para adequar-se à lógica reconfigurável, ou seja, a reconfiguração está na
modificação de seus blocos lógicos e funções lógicas para adaptar-se a uma nova
funcionalidade. No caso destes processadores, não existe uma reconfiguração de blocos
lógicos, mas sim uma nova alternativa de inserir, combinar ou modificar instruções
durante a execução de uma aplicação, utilizando diferentes técnicas como a áreas de
microinstruções em memória RAM ou unidades funcionais dedicadas, as quais serão
explicadas posteriormente. Portanto, termos como adaptação, programação ou mesmo
configuração de instruções seriam melhor adequados para este trabalho, contudo optou-
se por utilizar o termo “reconfiguração de instruções”, visto que as arquiteturas
projetadas seguem as características de processadores RISP.
A arquitetura MIPS é frequentemente lecionada em universidades por permitir
aos docentes a escolha do nível de envolvimento frente às restrições de tempo de
ensino. Assim, a arquitetura MIPS pode ser apresentada aos alunos desde uma versão
31
simplificada que permita transmitir noções básicas de como um processador é
implementado, a uma abordagem mais complexa que permita a demonstração de como
atingir melhores desempenhos e maior capacidades de processamento utilizando
técnicas como pipeline, coprocessadores de ponto flutuante ou caching. Por se tratar de
uma abordagem acadêmica, esta ISA foi utilizada como base para a adaptação dos
processadores. Não é o intuito deste trabalho projetar um processador MIPS ou
substituir o processador atual por um processador MIPS já existente, visto que já
existem versões MIPS descritas em VHDL completamente funcionais. O objetivo
principal é adaptar um processador, com sua organização de hardware já definida, para
que este possa executar as instruções de uma nova arquitetura de conjunto de instruções,
utilizando como aplicação o conjunto MIPS-I.
32
Capítulo 3 – Estado da arte
4. A adaptação entre arquiteturas de conjuntos de instruções significa, em termos
de software, diminuir a dificuldade quanto a problemas de compatibilidade binária entre
códigos de aplicativos. Já em termos de hardware, significa fornecer uma técnica que
contribua para o aproveitamento de softwares básicos como Assemblers e compiladores,
e códigos já desenvolvidos e compilados para diferentes microarquiteturas.
Algumas técnicas em hardware e software foram propostas para diminuir a
dependência entre fabricantes ou arquiteturas a partir de uma adaptação ou
compatibilidade entre diferentes ISAs. A solução mais simples e utilizada é a
interpretação por software. Esta técnica permite a execução de um código previamente
compilado em diferentes conjuntos de instruções em apenas um único processador. O
código executado pelo aplicativo é analisado em tempo real pelo interpretador, sendo
posteriormente realizada uma conversão entre o conjunto de instruções original do
aplicativo e o novo conjunto desejado.
Esta técnica permite a execução de um mesmo código binário em diferentes
arquiteturas. Porém, o sistema de interpretação por software necessita de uma camada
extra de software entre o aplicativo e o processador, tornando sua execução mais lenta
comparada com a execução do código nativo. Também é necessário um interpretador
implementado no mesmo conjunto de instruções do processador alvo.
Outra solução proposta é o emulador por microcódigo, presente em diversas
arquiteturas comerciais, desenvolvidas por fabricantes como Intel, IBM e Motorola,
para garantir compatibilidade de softwares entre máquinas distintas. Ao contrário do
interpretador, o emulador pode ser implementado em hardware, responsável pela
decodificação do código original do aplicativo para um novo conjunto de instruções. O
mecanismo interno de funcionamento é formado por uma memória ROM para
armazenamento do microcódigo e uma máquina de estados para realizar o controle
interno do sistema. Existem emuladores que permitem a adição de microcódigo através
de uma memória flash ou SRAM (Static Random Access Memory). Esta técnica também
33
permite que instruções CISC sejam executadas em processadores RISC, adicionando
uma camada extra de hardware e mantendo assim a compatibilidade binária, e
simulando outras dependências específicas de plataforma que façam distinção entre as
duas máquinas.
3.1. Tradução Binária
Uma técnica em hardware que utiliza dispositivos reconfiguráveis consiste em
uma tradução binária, que possui a característica de armazenar as traduções para reuso
futuro, e pode ser implementado como uma camada de software ou hardware. O
método de tradução binária consiste em converter um código já compilado para um
determinado conjunto de instruções apontado pelo processador, no qual o código será
realmente executado. Esta tradução permite executar um aplicativo dependente de um
hardware proprietário em outro sistema que utiliza um conjunto de instruções diferente.
Para o usuário do sistema, esta tradução é abstraída e o aplicativo é executado da mesma
forma como se o programa estivesse sendo utilizado no processador nativo.
Um tradutor binário pode ser classificado em três tipos diferentes, segundo
[Altman, Kaeli e Sheffer, 2000]: emulador, Tradutor Estático e Tradutor Dinâmico. O
emulador realiza a interpretação do código em tempo de execução, baseada em acessos
a tabelas que contêm as possíveis configurações da arquitetura para qual a instrução será
traduzida. Sua tradução não é salva em memória para reutilização futura. O Tradutor
Estático realiza a tradução em tempo de compilação, sendo possível utilizar informações
extraídas em tempo de execução do aplicativo. Já o Tradutor Dinâmico realiza a
tradução do código em tempo de execução (run-time), com a possibilidade de
armazenar em memória partes do código para uso futuro, dispensando um conhecimento
profundo da arquitetura pelo programador ou usuário.
O trabalho de [Fajardo Jr, 2011] propõe um sistema dinâmico de tradução
binária de dois níveis, que executa um código compilado para o conjunto de instruções
x86 em uma arquitetura reconfigurável, onde este sistema será capaz de executar o
conjunto de instruções MIPS.
O primeiro nível deste tradutor binário é responsável por traduzir o código
nativo para um código genérico, da mesma forma que um tradutor binário convencional.
Para tanto, foi desenvolvido um novo mecanismo dinâmico implementado em hardware
que funciona como interface entre o processador e a memória de instruções. O segundo
34
nível de tradução é responsável por otimizar ou acelerar sequências de instruções deste
código comum já traduzidas para a arquitetura alvo. Este código é, por sua vez,
traduzido para ser executado em uma arquitetura reconfigurável, a qual é composta por
um processador MIPS fortemente acoplado com um segundo nível de tradução binária e
uma unidade reconfigurável fortemente acoplada de granularidade grossa [BECK et al.,
2008]. Os trechos traduzidos são chamados agora de “configurações”, e são alocados na
TCache para serem executados novamente de acordo com o fluxo do programa, porém
agora na unidade de reconfigurável. A Figura 3.1 ilustra uma visão geral de sua
proposta.
Figura 4.1 – Mecanismo de tradução binária em dois níve
Fonte: [Fajardo Jr, 2011]
Ainda segundo [Fajardo Jr, 2011], o funcionamento deste mecanismo ocorre da
seguinte forma: o primeiro nível do tradutor busca as instruções CISC na memória,
como um processador comum. As instruções são traduzidas gerando uma ou mais
35
instruções MIPS equivalentes. A cada envio de uma instrução traduzida para o
processador, o tradutor calcula o novo endereço da memória de instruções.
O componente de hardware do primeiro nível do tradutor binário é composto
por quatro diferentes unidades: Tradução, Montagem, PC (Program Counter) e uma
unidade de Controle, formando dois estágios de pipeline, para que seja possível a
tradução e o cálculo do novo endereço ao mesmo tempo. Na Figura 3.2 é proposta uma
visão geral do mecanismo de tradução.
Figura 4.2 – Unidades do mecanismo de tradução binária
Fonte: [Fajardo Jr, 2011]
A Unidade de Tradução é responsável por buscar as instruções x86 da memória
(uma instrução por vez), analisar o seu formato, quantidade de bytes que a compõe e
classificá-la de acordo com a operação, operadores e modo de endereçamento, gerando
então instruções equivalentes MIPS. Nesta unidade é realizado principalmente
operações de acesso a tabelas. Além de realizar a tradução, esta unidade deve fornecer
informações para as unidades auxiliares como: a quantidade total de bytes no qual a
instrução x86 é formada (importante para o cálculo do endereço da próxima instrução),
o número de instruções MIPS geradas para verificar a disponibilidade na fila de
instruções da unidade de montagem, e ainda informar o tipo de instrução (operação
36
lógica, saltos condicionais ou incondicionais, flags de estado que poderão ser
modificadas pela instrução, etc).
Esta unidade possui 4 diferentes tabelas e um hardware especial para manipular
valores imediatos. Em cada uma destas tabelas e hardware de imediatos, as saídas são
bits de configuração para serem enviadas ao componente de hardware responsável por
descartar bits de configuração que não serão utilizados e os colocar em ordem correta.
Neste instante são conhecidos a operação da instrução e os operadores que compõem
determinada instrução x86. Na sequência, os bits de configuração são enviados para a
unidade que decodifica esta informação e a partir dela monta a instrução no formado do
conjunto MIPS. As instruções MIPS são geradas dependendo da sua operação: nos
formatos R, I ou J.
O processador MIPS utilizado busca novas instruções vindas do tradutor binário
de forma sequencial, da mesma forma que o processador original busca suas instruções
de uma memória regular. A Unidade de Montagem disponibiliza as instruções
equivalentes MIPS de forma sequencial como se fosse uma memória comum, e é
formada por um banco de registradores de 32 bits, nos quais as instruções provenientes
da Unidade de Tradução são alocadas. A cada ciclo é enviado para a Unidade de
Controle a quantidade de instruções que estão ocupando os registradores, de forma a
garantir que não existirá descontinuidade no processo de fornecimento de instruções
MIPS para o processador, reduzindo eventuais bolhas ou paradas na execução do código
que possam surgir.
A instruções x86 possuem tamanhos variáveis, impossibilitado o
reaproveitamento do hardware do processador MIPS para o cálculo do próximo
endereço na busca de novas instruções. Desta forma, foi implementada uma Unidade de
PC, que calcula o próximo endereço da nova instrução a ser buscada na memória,
baseando-se na quantidade de bytes em que é composta a instrução x86 corrente, e
somando esse número ao endereço atual, ou calculando o endereço através de um valor
imediato contido em uma instrução de salto incondicional.
A Unidade de Controle permite que seja mantida a sincronia e a consistência da
informação entre as unidades de Tradução, Montagem e de PC. A unidade de controle
pode repassar informações como o momento em que a Unidade de Tradução pode
buscar uma nova instrução na memória ou como deve ser calculado o endereço de PC.
Esta unidade é baseada em uma máquina de estados finitos.
37
A segunda etapa da tradução contém uma arquitetura reconfigurável denominada
DIM (Dynamic Instruction Merge), desenvolvida por [Beck e Carro, 2005] [Beck et al.,
2008]. A arquitetura DIM é composta por um sistema de tradução binária, uma TCache
onde são alocadas as configurações geradas pelo tradutor e uma unidade reconfigurável
responsável pela execução das configurações.
A unidade reconfigurável é formada por uma matriz dinâmica de grão grosso
fortemente acoplada ao processador, o que propicia que a reconfiguração ocorra em
unidades funcionais completas. Na fase de execução do código, a unidade
reconfigurável funciona como uma extensão do estágio de execução do processador,
atuando de forma totalmente independente e sem a necessidade de acesso externo.
A matriz de unidades funcionais possui duas dimensões, onde cada instrução é
alocada na interseção entre uma linha e uma coluna. As unidades funcionais alocadas
lado a lado podem executar operações em paralelo, já as unidades alocadas na mesma
coluna se caracterizam por executar as operações de forma combinacional, uma após a
outra. Desta forma, se duas instruções não possuem nenhum tipo de dependência de
dados entre si, existe a possibilidade de serem alocadas na mesma linha, ou seja, com
execução paralela. Caso contrário, serão obrigatoriamente alocadas em linhas diferentes.
Cada coluna possui um número pré-determinado de unidades funcionais,
podendo ser ULAs, multiplicadores, unidades de load/store, entre outras. Dependendo
do tempo de execução de cada unidade funcional, o processador pode executar mais de
uma operação por ciclo de relógio.
No exemplo da Figura 4.3, o primeiro grupo de unidades funcionais suporta a
execução de até 4 operações em paralelo por meio de suas ULAs, o segundo grupo
suporta duas unidades de leitura/escrita (load/store) em paralelo e o terceiro grupo
oferece uma unidade multiplicadora dedicada.
38
Figura 4.3 – Configuração de uma unidade reconfigurável da arquitetura DIM
Fonte: [BECK. e CARRO, 2005]
O processo de reconfiguração ocorre da seguinte forma: os valores contidos em
um banco de registradores são enviados por um barramento de operadores, de modo que
cada linha do barramento é conectada a todas as unidades funcionais por meio de
multiplexadores – Fig. 4.3(a). Na sequencia de cada unidade funcional é acoplado um
multiplexador de saída – Fig. 4.3(b), que seleciona em qual linha do barramento será
destinado o resultado da operação. A partir do quadro da Fig. 4.3(c), a primeira
instrução é alocada na primeira unidade lógica (visualizada de baixo para cima),
armazenando o resultado da adição.
A Figura mostra a sequência de armazenamento de dados das instruções nas
linhas e colunas das unidades lógicas de acordo com a dependência verdadeira de dados
entre as instruções, definindo a ordem de execução em série ou em paralelo. As
instruções 6 e 7 possuem dependência com as instruções 1, 2 e 3, devendo ser
executadas no próximo ciclo de relógio e alocadas nas unidades de load/store
correspondentes. Já a instrução 8 possui dependência direta com a instrução 7, o que
também impossibilita o uso da unidade multiplicadora no mesmo ciclo, ocasionando um
terceiro ciclo de relógio.
Os blocos básicos desta unidade são sequências de código situadas entre desvios
ou chamadas de função. A execução do tradutor se inicia após uma instrução de desvio
e finaliza ao encontra outra instrução não suportada ou uma nova instrução de desvio. A
implementação do tradutor possui 4 estágios: decodificação, análise de dependências,
atualização de tabelas e montagem de configuração. A instrução é decodificada no
39
primeiro estágio, fornecendo para o segundo estágio informações como tipo de operação
e operadores. O segundo estágio verifica as dependências para manter a coerência dos
dados durante a execução. O terceiro estágio atualiza as tabelas de configurações e o
último estágio organiza as tabelas e monta uma nova configuração quando houver uma
quebra de configuração ocasionada por uma instrução de desvio ou não suportada.
Um conjunto de tabelas é utilizado para manter as informações sobre a
sequência de instruções processadas, responsáveis por armazenar dados como
configuração dos multiplexadores, operação das ULAs, mapa binário da alocação de
cada instrução na matriz, tabela de dados a serem buscados no banco de registradores,
entre outros. O processo de tradução ocorre de forma paralela ao processador.
Ao finalizar o processo de tradução, é montada uma configuração indexada ao
endereço da primeira instrução da sequência do código traduzido, armazenada na
TCache para um futuro reuso. Caso uma mesma sequência de código for encontrada
pela segunda vez, será encontrada na TCache a configuração com o mesmo endereço e
com o código já traduzido e otimizado. Desta forma, ocorre uma execução direta do
código na unidade reconfigurável, dispensado o uso do processador MIPS e da tradução
binária.
3.2. Considerações
A técnica apresentada neste trabalho se diferencia das demais, e até a conclusão
deste texto não foram encontrados na literatura trabalhos semelhantes, que utilizem
técnicas de reconfiguração de instruções para adaptação de processadores a uma ISA
padrão, sem a necessidade de técnicas como interpretação, compilação ou tradução.
Apesar da técnica de tradução binária apresentada utilizar dispositivos reconfiguráveis e
configurações de instruções, sempre faz-se necessária uma primeira leitura do código e
modificação de sua estrutura para prover o novo conjunto de instruções na arquitetura-
alvo. Nos capítulos seguintes, será mostrado que esta metodologia possibilita criar
novas instruções diretamente na arquitetura por meio de uma unidade de reconfiguração
externa ou de um acréscimo no código-fonte no programa armazenado em uma
memória RAM, permitindo a execução direta de suas novas instruções como se fossem
instruções do conjunto nativo da arquitetura.
40
Capítulo 4 – Microarquiteturas
microprogramadas propostas
5. Neste capítulo são apresentados os dois processadores microprogramados
genéricos utilizados para adaptação à ISA MIPS. Os processadores foram descritos
utilizando a linguagem VHDL e projetados para funcionarem como um processador de
propósito geral com possibilidade de reconfiguração de instruções, sendo que cada um
destes executa a reconfiguração de modos distintos.
4.1 Processador CABARE
O CABARE (Computador Acadêmico BAsico com REconfiguração),
desenvolvido por [Silva, 2011], foi projetado para ser um processador RISC de
propósito geral de baixa complexidade de hardware, composto por um pequeno
conjunto de instruções sem padrão específico e uma lógica reconfigurável capaz de
receber e executar instruções que não estão presentes no conjunto de instruções original,
sendo tais instruções previamente armazenadas em posições definidas na memória.
A arquitetura do CABARE foi baseada em [Altera, 2013] como um exercício
didático da fabricante de FPGA’s Altera® para demonstrar o funcionamento do Modelo
de Von Neumann [Stallings, 2010] em um processador single-tasking1. Tal estrutura foi
modificada para incluir novas instruções, operações, funcionalidades e a lógica de
reconfiguração.
A organização física de 32 bits do CABARE é formada por um conjunto de 12
registradores de propósito geral (R0 a R11) e um registrador (R12) utilizado como
contador de programa (PC), um multiplexador (MUX) de 16 canais de entrada, um
registrador de instrução (IR), uma ULA com a primeira entrada ligada exclusivamente a
um registrador acumulador (A) e a segunda entrada ligada ao barramento de dados, com
1 Processadores que executam uma única instrução por ciclo de relógio.
41
a saída conectada a um registrador de resultado (G), além de registradores para interface
com a memória (DOUT e ADDR). Uma visão geral do CABARE está ilustrada na
Figura 4.1.
Figura 5.1 - Arquitetura do processador CABARE
Fonte: autoria própria
A entrada de dados no processador é realizada por meio de um barramento de
entrada de 32 bits (DIN), que recebe os dados provenientes da memória externa e os
envia para uma das entradas do multiplexador. A saída do multiplexador é chamada de
barramento de dados (BUS), e está conectado a quase todos os demais registradores do
processador (R0 a R12, A, DOUT, ADDR e a ULA).
Todas as instruções lógicas e aritméticas necessitam de, no mínimo, três ciclos
de relógio para sua execução, visto que existe apenas um barramento de dados que
conecta os registradores à ULA, e um dos operandos de entrada deve ser
obrigatoriamente armazenado no registrador acumulador A. Esta configuração
demonstra a simplicidade do CABARE. A ordem dos canais de entrada do
multiplexador para envio ao barramento de dados está disposta na Tabela 4.1.
42
Tabela 5.1 – Registradores de uso geral no CABARE
Entrada do MUX Endereço (bin)
R0 0000
R1 0001
R2 0010
R3 0011
R4 0100
R5 0101
R6 0110
R7 0111
R8 1000
R9 1001
R10 1010
R11 1011
R12 (PC) 1100
Mask 1101
G 1110
DIN 1111
A ULA é responsável pelas operações lógicas e/ou aritméticas de soma,
subtração, E lógico, OU lógico, NÃO lógico, transparência (throughput) e
deslocamento de 1 bit à esquerda ou à direita. Também possui alguns flags que indicam
se a operação resultou em zero (Z), um número negativo (S) ou se houve uma
propagação de carry (Cy) a partir do seu MSB (Most Significative Bit). A relação de
operações da ULA está descrita na Tabela 4.2.
Tabela 5.2 – Operações da ULA do CABARE
Código Operação
000 Soma
001 Subtração
010 And
011 Or
100 not A
101 Transparência
110 deslocamento para direita
111 deslocamento para esquerda
O CABARE possui um conjunto composto por 20 instruções de 32 bits de
palavra, de modo que cada instrução possua um único formato válido, na forma:
IIIIIIIIXXXXYYYYZZZZZZZZZZZZZZZZ, onde IIIIIIII (8 bits) representa o código
da operação (CodOp), XXXX (4 bits) o registrador RX, YYYY (4 bits) o registrador
RY e ZZZZZZZZZZZZZZZZ (16 bits) um valor constante de 16 bits. Caso a instrução
43
utilize apenas dois registradores como operandos, então os 16 bits restantes não são
considerados, podendo receber qualquer valor (Don’t Care). Quando a instrução utiliza
apenas um registrador, os bits YYYY não são considerados, mas não podem fazer parte
do valor constante, ou seja, a constante #D ocupa apenas os 16 bits reservados na
palavra da instrução.
A cada busca na memória externa, a instrução atual é enviada para o registrador
de instrução (IR), que o encaminha à unidade de controle para decodificação. A
constante de 16 bits presente na instrução é enviada da unidade de controle para o
barramento por meio da entrada Mask, cujo valor de 32 bits contém o valor
0x0000DDDD, obtido após uma operação AND cuja finalidade é eliminar os primeiros
16 bits da instrução contendo o código da operação e o endereço dos registradores,
cujos valores não devem fazer parte da constante #D.
Este sistema executa as instruções apresentadas na Tabela 4.3. As 2 primeiras
colunas mostram o código da operação (CodOp), em binário e em hexadecimal
respectivamente, a terceira coluna mostra o nome da instrução e seus operandos e a
última coluna o significado. A sintaxe Rx ← [Ry] significa que o conteúdo do
registrador Ry é carregado no registrador Rx, enquanto que a expressão Rx ← #D
indica que um valor constante #D de 32 bits é carregado no registrador Rx.
Tabela 5.3 – Operações realizadas pelo processador CABARE
Código da
Operação (Bin)
Código da
Operação (Hexa)
Operação Função Executada
00000000 00 mv Rx, Ry Rx ← [Ry]
00000001 01 mvi Rx, #D Rx ← #D
00000010 02 mvnz Rx, Ry IF G != 0, Rx ← Ry
00000011 03 add Rx, Ry Rx ← [Rx] + [Ry]
00000100 04 sub Rx, Ry Rx ← [Rx] – [Ry]
00000101 05 and Rx, Ry Rx ← [Rx] and [Ry]
00000110 06 or Rx, Ry Rx ← [Rx] or [Ry]
00000111 07 not Rx Rx ← not[Rx]
00001000 08 ld Rx, [Ry] Rx ← [[Ry]]
00001001 09 st Rx, [Ry] [Ry] ← [Rx]
00001010 0A ldi Rx G ← Rx
00001011 0B jmp #D PC ← #D
00001100 0C jnz #D IF G != 0, PC ← #D
00001101 0D shl Rx, Ry Rx ← [Ry] << 1
00001110 0E shr Rx, Ry Rx ← [Ry] >> 1
00001111 0F jnc #D IF Cy != 0, PC ← #D
44
00010000 10 jns #D IF S != 0, PC ← #D
00010001 11 jz #D IF Z = 0, PC ← #D
00010010 12 jc #D IF Cy = 0, PC ← #D
00010011 13 js #D IF S = 0, PC ← #D
00010100
a
00011110
14 a 1E Reservado ---
00011111 1F Halt PC ← PC (fim)
1111xxxx --- Configuráveis ---
A arquitetura pode executar diferentes operações a cada ciclo, controladas pela
unidade de controle (control unit). Essa unidade determina quando um dado em
particular é enviado ao barramento e qual registrador deve carregá-lo. Por exemplo, se a
unidade de controle determinar MUX em 0x0000 e ativar o bit AIn, então o
multiplexador transmitirá o conteúdo de R0 para o barramento e esse dado será
carregado no acumulador A na próxima subida de relógio. A Tabela 4.4 indica os sinais
de controle que devem ser ativados em cada pulso de relógio para cada instrução.
Tabela 5.4 – Sinais do controle do CABARE em cada instrução/tempo
T0 T1 T2 T3
(mv): IRIn MUX=Ry, RxIn, Done
(mvi): IRIn MUX=Mask, RxIn,
Done
(mvnz): IRIn Se !Z=> MUX=Ry, Gin
Senão => Done
MUX=G, RxIn, Done
(add): IRIn MUX=Rx, AIn MUX=Ry, ULA=add,
GIn
MUX=G,
RxIn, Done
(sub): IRIn MUX=Rx, AIn MUX=Ry, ULA=sub,
GIn
MUX=G,
RxIn, Done
(and): IRIn MUX=Rx, AIn MUX=Ry, ULA=and,
GIn
MUX=G,
RxIn, Done
(or): IRIn MUX=Rx, AIn MUX=Ry, ULA=or,
GIn
MUX=G,
RxIn, Done
(not): IRIn MUX=Rx, ULA=not,
GIn
MUX=G, RxIn, Done
(ld): IRIn MUX=Ry, ADDRIn,
R_D
MUX=DIN, RxIn,
Done
(st): IRIn MUX=Rx, DOUTIn MUX=Ry, ADDRIn,
W_D, Done
(ldi): IRIn MUX=Rx,
ULA=transp, GIn, Done
(jmp): IRIn MUX=Mask, R12In,
Done
45
(jnz): IRIn Se !Z=> MUX=Mask,
R12In, Done
Senão => Done
(shl): IRIn MUX=Ry, ULA=shl,
GIn
MUX=G, RxIn, Done
(shr): IRIn MUX=Ry, ULA=shr,
GIn
MUX=G, RxIn, Done
(jnc): IRIn Se !Cy=> MUX=Mask,
R12In, Done
Senão => Done
(jns): IRIn Se !S=> MUX=Mask,
R12In, Done
Senão => Done
(jz): IRIn Se Z=> MUX=Mask,
R12In, Done
Senão => Done
(jc): IRIn Se Cy=> MUX=Mask,
R12In, Done
Senão => Done
(js): IRIn Se S=> MUX=Mask,
R12In, Done
Senão => Done
(halt): IRIn -
4.1.1. Reconfiguração de instruções
O CABARE usa uma arquitetura RISC com 20 instruções “fixas” (já presentes
no processador durante sua concepção), 10 códigos de operações não utilizados,
reservados para uso futuro, e 16 códigos de operações livres para novas instruções. Este
tipo especial de código de operação não é definido previamente na unidade de controle,
sendo necessária a criação de um conjunto de microinstruções pelo usuário, os quais
devem ser armazenados na memória externa juntamente com o restante do programa
armazenado (dados e instruções).
A fim de simplificar a definição da quantidade de instruções reconfiguradas e
sua faixa de representação, todos os códigos de operação (CodOp’s) com os 4 bits
iniciais iguais a ‘1’ foram reservados para instruções reconfiguradas (códigos 0xFF00 a
0xFFFF). Ao decodificar o CodOp de uma instrução reconfigurada, a unidade de
controle deverá buscá-la na memória em uma região de memória previamente
delimitada para armazenar os dados de cada instrução.
A memória externa deve ser logicamente dividida em quatro áreas bem
definidas: área de instruções, área de dados, armazenamento de microinstruções e área
46
de ponteiros, sendo esta última contendo o endereço de cada primeira microinstrução
reconfigurada inicial, conforme mostra a Figura 4.2. A área de ponteiros reserva as
últimas 16 células da memória para cada uma das 16 instruções reconfiguradas,
independente do tamanho da memória utilizada. Dessa forma, o CodOp 0xF0 deverá ser
associado ao endereço de memória 0xFF...F0, o CodOp 0xF1 associado ao endereço
0xFF...F1, e assim sucessivamente. Para inicializar os dados e instruções na memória, é
utilizada uma MIF (Memory Initialization File) contendo todas estas áreas em intervalos
definidos pelo programador.
Figura 5.2 – Distribuição de memória no CABARE
Fonte: autoria própria
Uma instrução reconfigurável é um conjunto de n palavras de 32 bits, de modo
que cada palavra refere-se a uma microinstrução. Os campos desta palavra são os bits de
controle de todas as unidades funcionais do caminho de dados do processador, como os
bits de escrita dos registradores, os bits de operação da ULA, seleção do multiplexador,
dentre outros. Para poder modificar o comportamento do caminho de dados, é preciso
que todos os bits de controle do caminho de dados possam ser alterados por meio de
uma microinstrução, exigindo total compreensão sobre o funcionamento da organização
e arquitetura do processador por parte do programador, incluindo detalhes sobre
quantidade e função de cada registrador, a ordem das entradas do multiplexador e o
índice de operações da ULA. Como explicado no Cap. 2, o caminho de dados dos
processadores RISP não é reconfigurado fisicamente; suas unidades funcionais se
comportam conforme especificado em cada nova microinstrução, definindo a cada etapa
47
qual registrador será enviado como operando da ULA, que operação aritmética ou
lógica será realizada e o registrador que receberá o resultado da operação.
Para criar uma microinstrução, é necessário definir os bits de controle do
processador e selecionar um dos formatos de microinstrução, presentes na Tabela 4.5. O
formato (a) envia todos os bits de controle para as unidades funcionais correspondentes
na unidade operativa, de acordo com a ordem estabelecida. O formato (b) é utilizado
para operações de desvio condicional e incondicional dentre as microinstruções
reconfiguradas de um mesmo CodOp, por meio do envio do endereço de memória para
um registrador de índice de estados reconfiguráveis. O formato (c) envia apenas os
sinais de controle de escrita nos registradores, utilizando os 16 bits menos significativos
para endereçamento ou operações com valores imediatos.
Tabela 5.5 - Configuração de uma microinstrução no CABARE
Formato R0In...12In ULA MUX IR A G DOUT ADDR WD RD END
4 13 3 4 1 1 1 1 1 1 1 1
(a)
Formato JMP Z Z’ S S’ CY CY’ - END
4 1 1 1 1 1 1 1 6 15
(b)
Formato R0In...R12In END
4 13 15
(c)
Os primeiros 4 bits de cada microinstrução alteram o formato da palavra. Com
apenas uma configuração, não seria possível realizar uma integração entre os bits que
compõem o código da instrução e suas respectivas microinstruções. Como exemplo,
caso fosse utilizada uma instrução 0xF067000A, os bits referentes aos campos de
registradores X = R6, Y = R7 e endereço ADDR = 0x000A só poderiam ser utilizados
em uma única ordem na execução da instrução, já que não haveria como alterar estas
informações em diferentes microinstruções. Variando a quantidade de formatos, é
possível prover esta alteração de ordem dos dados em diferentes microinstruções,
aumentando a gama de possibilidades de reconfiguração. A Tabela 4.6 apresenta os
formatos de instrução definidos para este processador.
48
Tabela 5.6 – Formatos de microinstruções do CABARE
Formato Utilização da microinstrução
0000 microinstrução tipo (a)
0001 microinstrução tipo (c)
0010 R_In = Rx
0011 R_In = Ry
0100 MUX = Rx
0101 MUX = Ry
0110 R_In = Rx se Z = 0
0111 R_In = Ry se Z = 1
1000 R_In = Rx se S = 0
1001 R_In = Ry se S = 1
1010 R_In = Rx se Cy = 0
1011 R_In = Ry se Cy = 1
1100 MUX = Rx se Z = 1
1101 MUX = Rx se S = 1
1110 MUX = Rx se Cy = 1
1111 MUX = ‘-‘
Não foi definido um limite mínimo ou máximo de palavras para cada instrução
reconfigurável, sendo este trabalho realizado pelo programador. A única
obrigatoriedade está no fato de que a última microinstrução de cada instrução
reconfigurada deve ter o valor do seu bit_end setado (‘1’), o que indica para a unidade
de controle voltar ao modo de execução normal. A Figura 4.3 apresenta um quadro
detalhando as etapas para a execução de uma instrução reconfigurada.
Figura 5.3 – Sequência de execução de instruções reconfiguradas no CABARE
49
É possível que uma instrução reconfigurada seja exatamente igual a uma
instrução já existente no conjunto de instruções do processador, com exceção das
instruções de desvio. Isto permite a uma instrução reconfigurada criar um bloco de
instruções ou uma combinação de duas ou mais instruções a partir de um único CodOp,
com funcionamento análogo a uma sub-rotina. Embora uma instrução reconfigurada
possa substituir uma instrução fixa, tal procedimento não é recomendado para
reconfigurar apenas uma única instrução, visto que a quantidade de ciclos de relógio
para executar uma instrução reconfigurada é maior do que a quantidade de ciclos para
uma instrução existente no conjunto de instruções.
A execução de instruções reconfiguradas ocorre de maneira semelhante às
instruções fixas, com a inclusão de alguns ciclos adicionais para o endereçamento
indireto da primeira microinstrução customizada. O valor de PC somente será atualizado
após o término do microprograma da instrução reconfigurada.
4.1.2. Exemplo de funcionamento
No momento da compilação do código VHDL, um arquivo no formato .mif
inicializa a memória do processador com o programa que será executado. Desse modo,
a cada novo programa o projeto deve ser recompilado junto com o novo programa. O
exemplo do quadro a seguir carrega um valor do endereço #9 da memória e faz um laço
de repetição até atingir o valor que foi carregado.
Seguindo o formato de instrução já apresentado, a primeira instrução (mvi r5,#9)
possui CodOp (IIIIIIII) como 0x01 e o registrador R5 (XXXX) possui o código 0x5.
Como essa instrução não utiliza o segundo registrador, então o valor YYYY foi
codificado como 0x0. O valor da constante de 16 bits (ZZZZZZZZZZZZZZZZ) recebe
o valor 0x0009. Esta e as demais instruções do exemplo são detalhadas na Tabela 4.7.
(1) mvi r5,#9 //armazena #9 em R5 (será endereço de memória)
(2) mvi r4,#1 //armazena #1 em R4
(3) ld r6,r5 //carrega da memória o valor do endereço em R5 e armazena em R6
(4) sub r6,r4 //subtrai valor de R6 por R4 e armazena em R6
(5) jnz #4 //se o resultado da subtração não for zero pula para endereço 4
(6) halt //fim de programa
50
Tabela 5.7 – Código objeto para o exemplo 1
Instrução
mnemônica
CodOp
(IIIIIIII)
Rx
(XXXX)
Ry
(YYYY)
#D Código objeto
mvi r5,#9 01 5 0 0009 01500009
mvi r4,#1 01 4 0 0001 01400001
ld r6,r5 08 6 5 0000 08650000
sub r6,r4 04 6 4 0000 04640000
jnz #4 0C - - 000004 0C000004
Halt 1F 0 0 0000 1F000000
O próximo exemplo mostra como inserir uma instrução reconfigurada ADDI X,
Y, D (X Y + D), que não consta no conjunto de instruções original do CABARE. A
instrução 0xF0670005 tem como objetivo fazer com que o registrador R6 (registrador
na posição X da instrução) receba o resultado da adição do registrador R7 (registrador
na posição Y da instrução) com o valor imediato D = 0x0005. Estas microinstruções
devem ser descritas pelo usuário, definindo os sinais de controle de acordo com o
comportamento desejado em cada etapa da instrução, e inseridas nas posições
correspondentes na memória seguindo configuração de áreas da MIF. Ao decodificar o
código de operação desta instrução, os bits 0xF0 informam que a instrução é do tipo
reconfigurada, ocasionando uma busca no endereço de memória 0xF...F0, que aponta
para o início da sequência das seguintes microinstruções:
(1) ACC R7 (Y)
Formato R0In ... R12In ULA MUX IR A G DOUT ADDR WD RD END
0101 0000000000000 101 POS2 0 1 0 0 0 0 0 0
(2) MUX END (D), ULA = ADD (G = A + 0x0D)
Formato R0In ... R12In ULA MUX IR A G DOUT ADDR WD RD END
0001 0000000000000 000 MASK 0 0 1 0 0 0 0 0
(3) R6 (X) G, fim de procedimento
Formato R0In ... R12In ULA MUX IR A G DOUT ADR WD RD END
0010 POS1 101 MUX_G 0 0 0 0 0 0 0 1
Após o final da sequência de microinstruções, o valor do PC é atualizado,
continuando a sequência de execução do processador. As instruções reconfiguradas
podem ser utilizadas dentro de um programa da mesma forma que uma instrução fixa.
51
4.2. Processador CRASIS
O processador CRASIS (Computer with Reconfiguration And Selection of
Instruction Set) foi desenvolvido por [Casillo, 2005]. A organização do processador foi
inspirada na arquitetura MIC-1, descrito por [Tanembaum, 2007] e sua versão final
apresentada em [Casillo, 2005a]. Trata-se de uma arquitetura RISC de 32 bits de palavra
desenvolvida como uma prova de conceito de uma microarquitetura genérica que possa
conter vários conjuntos de instruções, alternados a qualquer momento em tempo de
execução, ajustando o conjunto de instruções que melhor se adapte ou que contenha as
melhores instruções para executar um determinado programa, além de prover a criação
de novas instruções por meio de uma unidade de reconfiguração dedicada.
Sua unidade operativa é composta por um banco de 32 registradores, sendo
quatro destinados a funcionalidades específicas, como acumulador e apontador de pilha
e o restante para uso geral, um deslocador de 32 bits para a esquerda ou direita, e uma
ULA com capacidade para 8 operações distintas: transparência do primeiro operando,
AND e OR lógicos, negação do primeiro operando, negação do segundo operando e
operações aritméticas de adição, subtração e multiplicação de dois operandos. Para a
comunicação com a memória, são utilizados dois registradores de interface, sendo um
para endereços (MAR) e um para dados (MBR). A Figura 4.4 ilustra o caminho de
dados.
Figura 5.4 – Diagrama de blocos do processador CRASIS
Fonte: autoria própria
52
Todas as instruções possuem 32 bits de palavra. Existem 5 formatos diferentes
de instruções, que utilizam de 0 a 4 operandos. Em todos os formatos de instrução, o
primeiro byte é destinado ao CodOp, sendo os demais utilizados para endereçamento ou
para determinação do(s) registrador(es) selecionado(s) para a operação. Cada novo
formato exclui 5 bits do campo de operando para a seleção de um registrador. Dessa
forma, o campo de operando possui 24 bits no primeiro formato, 19 bits no segundo
formato, e assim sucessivamente. A Figura 4.5 mostra a disposição de bits para cada
formato de instrução.
Figura 5.5 – Formatos de instrução do CRASIS
Fonte: autoria própria
A característica de reconfiguração do CRASIS não está na modificação de sua
parte operativa, e sim na possibilidade de criar e reconfigurar instruções em sua unidade
de controle, utilizando uma RFU (Reconfiguration Functional Unit) externa. Assim
como no CABARE, para efetuar qualquer reconfiguração é necessário o conhecimento
de todas as unidades funcionais do processador e seu funcionamento, visto que a RFU
terá como funcionalidade armazenar os códigos de operação das novas instruções e os
seus respectivos microprogramas, formados por uma sequência de sinais de controle
que definem o comportamento de cada uma das unidades funcionais de sua unidade
operativa. A Figura 4.6 apresenta uma visão geral do CRASIS contendo todas as suas
unidades funcionais.
53
Figura 5.6 – Arquitetura do processador CRASIS
Fonte: autoria própria
54
4.2.1. Modos de funcionamento
O CRASIS pode atuar sob dois modos de funcionamento: modo de
reconfiguração e modo de execução, sendo que o modo de execução pode ser
subdividido em execução de instruções fixas (instruções contidas nos conjuntos de
instruções) e execução de instruções reconfiguradas (instruções criadas ou combinadas a
partir da unidade de reconfiguração). A Figura 4.7 mostra um diagrama simplificado
contendo a máquina de estados (FSM – Finite State Machine) destes modos de
funcionamento.
Figura 5.7 – Diagrama de estados simplificado do CRASIS
Fonte: autoria própria
A determinação de qual modo de funcionamento será realizado é feita através do
estado denominado Verifica_Reconfiguração. Este estado é responsável por verificar se
houve um pedido de reconfiguração de uma instrução através do sinal de requisição
externo. Caso este sinal contenha um pedido externo de reconfiguração, será iniciada a
sequência de reconfiguração de instruções; caso contrário será iniciado o processo de
execução normal.
Ao iniciar a execução de uma instrução, é verificado se a instrução atual é fixa
ou customizada. Caso já seja existente no conjunto de instruções, a unidade de controle
envia os comandos correspondentes aos estados que compõe a instrução, tal qual se
encontra no conjunto de instruções selecionado. Caso contrário, a unidade de controle
55
busca os estados correspondentes à instrução customizada armazenados na unidade de
reconfiguração.
Com o intuito de validar a proposta do processador de conter diversos conjuntos
de instruções e poder alterná-los durante o seu funcionamento, foram implementados
três conjuntos de instruções simples compostos por 32 instruções cada, sendo 30 de
propósito geral específicas de cada conjunto, e 2 instruções privilegiadas comuns a
todos os conjuntos, para possibilitar a alternância entre os conjuntos.
O conjunto de instrução 1 é similar ao conjunto apresentado em [Tanembaum,
2007] para o MIC-1, com o acréscimo de instruções de tratamento de interrupção e
Entrada/Saída. Neste conjunto apenas o acumulador e o apontador de pilha (Stack
Pointer - SP) são acessíveis ao usuário. O segundo conjunto possui instruções em que
todos os 32 registradores são acessíveis ao usuário e o terceiro conjunto é baseado em
instruções que utilizam operações envolvendo a pilha. Cada conjunto possui uma
quantidade própria de estados necessários para implementar suas instruções, sem
interferir em outros conjuntos. A Tabela 4.8 contém as instruções presentes em cada um
dos 3 conjuntos implementados.
Tabela 5.8 – Operações realizadas pelo processador CRASIS
Código da
Operação (Bin)
Conjunto 1 Conjunto 2 Conjunto 3
00000000 LODD X LODD X LODDp X
00000001 STOD X STOD X STODp X
00000010 LOCO X LOCO X LOCO X
00000011 LODL X LODL Rx, Y LODLp X
00000100 STOL X STOL Y, Rx STOLp X
00000101 ADDL X LODR Ra, Rx, Ry LODIp X
00000110 SUBL X STOR Ra, Rx, Ry STOIp X
00000111 CALL X CALL X CALL X
00001000 JUMP X JUMP X JUMP X
00001001 JNEG X JNEG X JNEG X
00001010 JPOS X JPOS X JPOS X
00001011 JNZE X JNZE X JNZE X
00001100 JZER X JZER X JZER X
00001101 ADDD X ADDR Ra, Rx, Ry ADDp X
00001110 SUB DX SUBR Ra, Rx, Ry SUBp X
00001111 MULL X MULL Ra, Rx, Ry MULp X
11110000 RETN RETN RETN
11110001 PSHI SHL SHLp
56
11110010 POPI SHR SHRp
11110011 PUSH PUSH PUSH
11110100 POP POP POP
11110101 SWAP SWAP SWAP
11110110 SETI SETI SETI
11110111 RETI RETI RETI
11111000 INSP INSP INSP
11111001 DESP DESP DESP
11111010 LDIO LDIO LDIO
11111011 STIO STIO STIO
11111100 - - -
11111101 - - -
11111110 muda_conj
11111111 muda_modo
A criação de um CodOp compartilhado exigiu a criação do conceito de “super-
estados”. Dessa forma, cada uma das 27 instruções presentes no CRASIS pode ser
subdividida em até 3 subconjuntos distintos. Por exemplo, o CodOp “00000101”
(OP_5) corresponde às instruções ADDL X para o conjunto 1, LODR Ra, Rx, Ry para o
conjunto 2 e LODI para o conjunto 3. A instrução ADDL necessita de apenas um
operando, a instrução LODR necessita de 3 operandos para identificação dos
registradores, e a instrução LODI não requer nenhum operando adicional. A Figura 4.8
ilustra o diagrama de estados desta operação.
Figura 5.8 – Diagrama de estados de um super-estado
Fonte: autoria própria
57
O primeiro super_estado da instrução OP5 (OP5_1) contém a microinstrução
referente ao início da instrução ADDL X do conjunto 1, a microinstrução referente ao
início da instrução LODR Ra, Rx, Ry do conjunto 2 e a microinstrução referente ao
início da instrução LODI do conjunto 3. O segundo super_estado (OP5_2) contém as
microinstruções pertencentes aos conjuntos 2 e 3, enquanto que o terceiro super_estado
(OP5_3) contém apenas a microinstrução referente ao conjunto 3.
A implementação de super-estados é realizada utilizando estruturas de decisão
dentro da unidade de controle, após a decodificação de uma instrução. Como exemplo, a
instrução de CodOp 00001101 possui a seguinte implementação:
Isto mostra que um mesmo CodOp podem estar relacionado a diferentes
instruções, cada uma cotendo uma quantidade de microinstruções distintas, bem como
existe a possibilidade de unir instruções de diferentes conjuntos de instruções em um
mesmo estado, compensando a quantidade de linhas de código a mais utilizadas nas
estruturas de decisão para a seleção do conjunto.
Para que o usuário possa alternar entre os conjuntos de instruções, foram criadas
duas instruções, denominadas muda_conj e muda_modo. A função da instrução
muda_conj consiste em alterar o conjunto de instruções atualmente utilizado. Foi
utilizado um registrador de 8 bits denominado registrador de estado dentro da unidade
de controle. Este registrador é responsável por armazenar os bits que informam qual
conjunto está selecionado atualmente.
Se conjunto = 1 então instrução = ADD X
Estado 13.1: MAR := IR; RD;
Próximo estado = 13.2
Senão
Se conjunto = 2 então instrução = ADDD Ra, Rx, Ry
Estado 13.1: Ra := Rx + Ry; GOTO INT;
Próximo estado = verificação de interrupção
Senão
Se conjunto = 3 então instrução =ADDp
Estado 13.1: MAR := SP; RD
Próximo estado = 13.2
fimse
fimse
fimse
58
A codificação dos dois últimos bits presentes na instrução define qual conjunto
será selecionado. O valor “00” seleciona o conjunto 1, o valor “01” seleciona o conjunto
2 e o valor “10” seleciona o conjunto 3. Ao executar a instrução muda_conj, estes bits
são enviados ao registrador de estado, indicando qual conjunto deve ser selecionado. O
registrador de estado é alterado somente mediante esta instrução, portanto não é
possível alternar entre os conjuntos durante a execução de uma instrução. Por definição,
a cada reinício do processador, o conjunto de instruções 1 é selecionado.
A instrução muda_modo altera o modo de funcionamento do processador. Ao
executar esta instrução, os bits 7 e 6 da instrução são enviados ao registrador de estado,
codificados da seguinte forma: o valor “00” representa o modo usuário e o valor “01”
representa o modo supervisor. Somente é possível utilizar a instrução muda_conj se o
processador estiver em modo supervisor.
4.2.2. Exemplo de funcionamento
O exemplo apresentado na Figura 4.9 mostra o comportamento dos blocos
funcionais da unidade operativa durante a execução da instrução de CodOp “0000010”
(0X02). Este CodOp representa a instrução LOCO X (Load Constant X), presente em
todos os conjuntos implementados, a qual possui apenas uma microinstrução: Acc :=
BAND(AMASK, IR); GOTO INT.
Figura 5.9 – Exemplo de execução de instrução no CRASIS
Fonte: autoria própria
59
O significado desta microinstrução consiste no acumulador (registrador
“00001”) receber o resultado de uma operação AND binária entre o valor do registrador
de instrução (IR) e da máscara de endereços (AMASK = 0x00FFFFFF). Como
resultado, o acumulador receberá uma constante de 32 bits, formada pelos 24 bits menos
significativos de IR, ou seja, 0x00XXXXXX.
Durante a decodificação, se os quatro primeiros bits do CodOp forem “0000” ou
“1111”, significa que a instrução pertence a algum dos conjuntos fixos, dando sequência
ao processo. Caso contrário, se a instrução a ser executada for reconfigurável, será
iniciado processo de execução de instruções reconfiguradas.
Uma instrução reconfigurada é composta por uma ou mais microinstruções que
formam um microprograma que modela sua execução, formada por 28 bits de controle,
dispostos na Tabela 4.9.
Tabela 5.9 – Palavra de uma microinstrução no CRASIS
Form AMUX BMUX ULA SH MBR MAR ENC MUX
MAR
MUX
MBR
WR RD BIT_
END
6 bits 2 bits 2 bits 3 bits 6 bits 1 bit 1 bit 1 bit 2 bits 1 bit 1 bit 1 bit 1 bit
As instruções podem conter 1 a 4 registradores como operandos de entrada ou
saída, podendo assumir os formatos “OP A” a “OP A,B,C,D”. Dependendo do formato
utilizado e da quantidade de operações que compõe a instrução, um registrador utilizado
como destino na microinstrução ‘1’ pode ser utilizado como entrada na microinstrução
’2’, permitindo uma maior integração entre diferentes etapas de uma mesma instrução,
como uma realimentação de dados. As possibilidades de cada um dos demais bits de
controle são apresentadas na Tabela 4.10:
Tabela 5.10 – Bits de controle do CRASIS
Nome Função Valores
Form Define formato da instrução Vide Apêndice B
AMUX Operando esquerdo da ULA 00 – Barramento A
01 – Barramento C
10 – AMASK
11 – MBR
BMUX Operando direito da ULA 00 – Barramento B
60
01 – Constante ‘1’
10 – IR
11 – 0x00 & IR(18-0)
ULA Operação lógica/aritmética 000 – A
001 – A AND B
010 – NOT(A)
011 – NOT(B)
100 – A + B
101 – A - B
110 – A * B
111 – A OR B
SH Tipo/Quant. de deslocamentos Bit 1 – Direção (esq/dir)
Bits 2-6 – quantidade
MBR Carrega buffer de dados 0 – desativado
1 - ativado
MAR Carrega buffer de endereço 0 – desativado
1 – ativado
ENC Habilita escrita no banco de
registradores
0 – desativado
1 – ativado
MUX_MAR Seleciona entrada de MAR 00 – PC
01 – IR
10 – Latch B
11 – Barramento C
MUX_MBR Seleciona entrada de MBR 0 – PC
1 – Barramento C
WR Escrita na memória 0 – desativado
1 – ativado
RD Leitura na memória 0 – desativado
1 – ativado
BIT_END Fim de instrução 0 – não finalizada
1 – finalizada
O Apêndice B apresenta todos os formatos possíveis da palavra de configuração.
61
4.2.3. Unidade de Reconfiguração
A unidade de reconfiguração foi projetada para o tratamento de instruções
customizadas. A Figura 4.10 ilustra, de um modo geral, os blocos funcionais
constituintes desta unidade. Esta unidade possibilita criar uma instrução que não se
encontra nos conjuntos de instruções já existentes ou combinar duas ou mais instruções
reconfiguradas.
Figura 5.10 – Unidade de Reconfiguração do CRASIS
Fonte: autoria própria
A reconfiguração de uma instrução ocorre quando o processador recebe um sinal
externo, indicando um pedido de configuração. Neste processo, o processador deve
receber um CodOp identificando a instrução customizada e as microinstruções para a
configuração da instrução. Durante o processo de reconfiguração, o valor do Contador
de Programa (PC) permanece com seu valor atual.
Ao ser confirmado o pedido de reconfiguração, deve ser confirmado se a
instrução recebida é válida, ou seja, se o CodOp recebido pode ser utilizado por uma
instrução customizada. Ao ser confirmado se tratar de um CodOp válido, o processador
deverá armazenar este CodOp, associando-o com os valores das palavras de
configuração da instrução customizada, que devem ser armazenadas sequencialmente
até que seja indicado o final da instrução. O diagrama de estados da Figura 4.11
representa os estados correspondentes ao processo de reconfiguração de uma instrução.
62
Figura 5.11 – diagrama de estados de reconfiguração no CRASIS
Fonte: autoria própria
A verificação do CodOp recebido é realizada da seguinte forma: os quatro
primeiros bits do CodOp são comparados com os valores “0000__ e “1111__. Caso o
resultado dessa comparação seja positiva, o CodOp não será considerado válido, e
consequentemente a instrução não poderá ser configurada. Como resultado, é gerado um
sinal de erro indicando que não é possível realizar esta operação. Caso o resultado da
comparação seja negativo, o CodOp recebido encontra-se na faixa de valores reservados
para instruções reconfiguráveis, ou seja, entre “0001__ e “1110__, continuando a
sequência de execução.
Em seguida, o valor do CodOp é armazenado em um módulo de memória RAM
(Library of Parameterized Modules RAM), juntamente com um endereço que marca a
posição inicial da instrução. Após a gravação do CodOp, em se tratando de uma nova
instrução, a primeira microinstrução é armazenada em um novo módulo de memória
RAM, no endereço que foi especificado na gravação do CodOp.
O processo de armazenamento de microinstruções na memória RAM de dados é
realizado até que seja verificado o bit de finalização, indicando o término do processo
de gravação da instrução. Como única exceção, o CRASIS não reconfigura instruções
de desvio condicional.
63
4.2.4. Exemplo de reconfiguração
O exemplo a seguir ilustra uma instrução reconfigurável MAC D, A, B, C
(Multiplica e Acumula), em que D = A + (B*C). Esta instrução segue o formato (OP
5, 5, 5, 5, 4) e é composta por 2 microinstruções:
(1) 0xA830040 / D = B * C / Bar C = Bar B op Aux
Formato AMUX BMUX ULA SH MBR MAR ENC MUX_
MAR
MUX_
MBR
WR RD BIT_
END
101010 00 00 110 000000 0 0 1 00 0 0 0 0
(2) 0x4C20041 / D = D + A / Bar C = Bar C op Bar A
Formato AMUX BMUX ULA SH MBR MAR ENC MUX_
MAR
MUX_
MBR
WR RD BIT_
END
010011 00 00 100 000000 0 0 1 00 0 0 0 1
Caso o processador receba da memória uma instrução com valor 0x11390A60, a
consulta ao valor de CodOp 0x11 resulta em um código não utilizado pelos conjuntos
de instruções existentes, o que resultará em um estado de busca de instrução
reconfigurável. Verificando a tabela de CodOp nesta posição, será encontrado o
endereço da primeira microinstrução armazenada. Ajustando a instrução ao formato OP
5, 5, 5, 5, 4, tem-se o valor “00010001 00111 00100 00101 00110 0000”, o que resulta
em (MAC R7, R4, R5, R6, 0000), com significado R7 R4 + (R5 * R6).
4.3. Interface com a placa DE2
Ambos os processadores foram descritos em duas versões: a primeira versão
contém os códigos necessários para seu funcionamento em nível de simulação,
enquanto a segunda versão foi adaptada para funcionar como uma arquitetura didática
utilizando a plataforma de prototipagem DE2 da Altera®. Foi criado um sistema de
funcionamento no qual é executada uma instrução por vez, por meio do acionamento de
um botão denominado RUN. A cada acionamento, utilizando as chaves SW0 a SW4,
pode ser visualizado nos 8 displays de 7 segmentos o valor (em hexadecimal) de cada
um dos registradores do processador. Também foram utilizados leds para indicar fim de
programa, erro e flags da ULA e um botão de RESET. A Tabela 4.11 exibe as chaves de
seleção do multiplexador CABARE.
64
Tabela 5.11 – Chaves para seleção dos displays de 7 segmentos na DE2
Chave Valor Exibido
00000 R0
00001 R1
00010 R2
00011 R3
00100 R4
00101 R5
00110 R6
00111 R7
01000 R8
01001 R9
01010 R10
01011 R11
01100 R12
01101 Barramento
01111 A
10000 G
10101 Saída do MUX
10110 Saída da ULA
Outros X"FFFFFFFF"
Com o uso da DE2, é possível o acompanhamento de parte do funcionamento do
processador, como verificar valores dos registradores, PC, registrador de instrução,
valores lidos da memória e flags da ULA. Mas o fato de serem arquiteturas diferentes
exige que as instruções sejam escritas manualmente, bit-a-bit, ou então sejam criados
montadores e/ou compiladores, além de ter que adaptar um mesmo programa em
diferentes algoritmos e formas de implementação.
65
Capítulo 5 – Metodologia para
adaptação a uma ISA padrão
5. Este capítulo apresenta a metodologia que descreve os passos envolvidos no
processo de migração de processadores 32 bits sem uma ISA específica para uma ISA
padrão, sendo utilizada para estes estudos de caso a arquitetura MIPS. Para a unidade de
controle, em se tratando de processadores soft-core descritos em VHDL, é necessário
substituir os estados de decodificação e execução das instruções, de forma que o estado
de decodificação contenha a seleção das instruções implementadas, de acordo com o
Código de Operação de cada instrução MIPS. Para os estados de execução, cada uma
destas conterá o microprograma contendo o comportamento de cada unidade funcional
do caminho de dados do processador por ciclo de relógio.
O primeiro passo para o projeto de uma adaptação é conhecer os detalhes da
arquitetura, quanto ao formato de instruções, tipos de dados e endereçamento, tamanho
da palavra de dados e demais características próprias. A unidade de controle do
processador adaptado deverá receber as instruções nos formatos MIPS, e enviar os bits
de controle correspondentes às unidades funcionais do processador, de acordo com as
informações contidas no código da operação.
Qualquer modificação no processador poderá afetar a área em chip do
dispositivo, o consumo de potência ou seu nível de desempenho na execução de
instruções. Por isso, a fim de preservar as características originais de cada processador,
mantendo seu nível de complexidade de hardware, cabe ao projetista de hardware
realizar apenas as modificações necessárias para que a arquitetura possa executar
instruções MIPS. Esta metodologia, por ser acadêmica, não fará privilégio por área ou
desempenho, sendo a maior preocupação o correto funcionamento das microarquiteturas
na execução das instruções de sua nova ISA. No entanto, as sugestões propostas nos
caminhos de dados dos processadores terão informações sobre o possível impacto
66
quanto ao aumento da quantidade de elementos lógicos do dispositivo ou o aumento do
número de ciclos de relógio necessários para executar as operações.
Apesar de o padrão MIPS ser desenvolvido como uma arquitetura do tipo RISC,
atualmente é difícil classificar uma arquitetura como RISC ou CISC (Complex
Instruction Set Computer). Conceitualmente, uma arquitetura CISC possui um conjunto
de instruções mais complexo, tornando o computador mais versátil na execução de
aplicações, contém poucos registradores, utiliza diversos modos de endereçamento e sua
complexidade está no microprograma. Já uma arquitetura RISC possui um menor
conjunto de instruções, com poucos formatos fixos de instrução e modos de
endereçamento, o que torna sua execução mais rápida e os chips mais simples e baratos
[Tanembaum, 2007]. Atualmente, muitas arquiteturas são consideradas híbridas, pois
possuem processadores CISC com núcleos RISC. Assim, a parte CISC do processador
pode cuidar das instruções mais complexas, enquanto que o núcleo RISC pode cuidar
das instruções mais simples, nas quais é mais rápido [Calazans, 2008].
Pelo menos uma das características do modelo RISC deve ser seguido por
qualquer processador MIPS, que é a de conter vários registradores, visto que o padrão
MIPS exige pelo menos 32 registradores.. Não é objetivo desta metodologia seguir
todos os parâmetros necessários para que uma arquitetura continue sendo classificado
como RISC, como a restrição de executar as instruções do conjunto MIPS em mais de
um ciclo de relógio. No entanto, mesmo os processadores MIPS padrão serem
considerados arquiteturas RISC e as microarquiteturas adaptadas não possuírem todos
os requisitos básicos para esta classificação, os processadores adaptados a esta nova ISA
são capazes de compreender e executar as instruções presentes no conjunto de
instruções MIPS-I2, podendo ser considerados processadores MIPS.
Nas sessões seguintes serão apresentados os passos mínimos necessários para
um processador se tornar uma arquitetura MIPS. Esta metodologia não modela um
processador para ser a melhor opção para o padrão MIPS, mas sim torna possível a
execução de seu conjunto de instruções, de modo a manter seu nível de complexidade
de hardware e sua organização original, de modo a processadores acadêmicos criados
como experimentos arquiteturais genéricos continuem com suas características básicas
preservadas, mas capazes de executar instruções de uma nova ISA.
2 Exceto a instrução syscall, utilizado para chamadas ao sistema operacional.
67
5.1. Registradores
Um processador MIPS requer no mínimo 32 registradores de trabalho com 32
bits de palavra cada. Uma descrição VHDL simples é suficiente para realizar esta etapa
de adaptação, criando um arquivo registrador e o utilizando-o como um componente,
instanciado ao menos 32 vezes. Um registrador simples de 32 bits possui exatos 32
elementos lógicos em dispositivos FPGAs da Altera, e como a arquitetura original já
possui uma quantidade mínima de registradores internos, o custo desse acréscimo em
área será incluir a quantidade restante de registradores necessários, caso esta não possua
32 registradores. O custo total em área para 32 registradores significa utilizar 1024
elementos lógicos do dispositivo.
É necessário seguir uma ordem específica convencionada para os registradores
na arquitetura MIPS, como visto no Capítulo 2. Os registradores podem ser alocados
nas entradas de um multiplexador de 32 canais de entrada seguindo a convenção MIPS,
ou seja, o valor ‘0’ na entrada de seleção do multiplexador é relacionado ao registrador
$0, o valor ‘1’ na entrada de seleção é relacionado ao registrador $1, e assim por diante.
Caso o processador contenha mais do que 32 registradores utilizados em operações na
ULA, será necessário atualizar o multiplexador para 64 canas de entrada ou omitir
alguns registradores MIPS.
Como alguns registradores possuem sua função específica, como contador de
quadro ou apontador de pilha, e caso o processador não disponha de tais
funcionalidades, pode-se optar por substituir estes canais de entrada pelos registradores
adicionais do processador, com a penalidade de comprometer o funcionamento de
algumas instruções.
Registradores adicionais são necessários para prover algumas funções ou
operações. Para executar corretamente as operações de multiplicação e divisão, cujo
resultado é um valor de 64 bits, faz-se necessário incluir dois registradores específicos,
HI e LO, para armazenar respectivamente as partes mais e menos significativas do
resultado destas operações. Além disso, devem existir registradores que forneçam a
comunicação externa entre processador e memória, responsáveis pelo envio e
recebimento de dados e endereços.
68
5.2. Unidade Lógica e Aritmética
A ULA de um processador adaptado ao padrão MIPS deve conter as operações
lógicas e aritméticas necessárias para executar as instruções de mesmo tipo presentes no
MIPS-I. A inclusão de mais operações reflete no aumento da quantidade de área em
chip, mas também resulta em uma diminuição do número de ciclos de relógio
necessários para a sua execução. Portanto, deve ser uma decisão de projeto Área x
Desempenho.
Para executar as operações lógicas, recomenda-se que todas as funções lógicas
básicas e complementares (and, or, nand, nor, xor, xnor, not) estejam disponíveis. Uma
operação and de 32 bits utilizará 32 portas lógicas and de duas entradas, sendo a mesma
configuração para as demais funções lógicas. Portanto, em virtude da sua simplicidade,
tais funções não causam um impacto significativo em área sobre a quantidade de
elementos lógicos.
As instruções aritméticas MIPS-I são: adição, adição com operando imediato,
subtração (todos com ou sem detecção de overflow), multiplicação e divisão (com sinal
e sem sinal). É fundamental que a ULA contenha ao menos um circuito somador. Para
as demais operações fundamentais, a decisão de projeto é utilizar circuitos específicos
para cada operação ou na forma de algoritmos utilizando apenas somadores.
A melhor forma de efetuar a subtração é utilizar a técnica de Complemento a 2,
pois esta utiliza apenas somas e complementos (utilizando uma porta lógica not) e não
necessita de um circuito subtrator, o que reduz a área do dispositivo. Para as instruções
de multiplicação e divisão em MIPS, é importante saber que estas exigem a utilização
dois registradores HI e LO, e que poderá ser necessário trabalhar com a transferência de
dados entre estes registradores dependendo da forma escolhida para sua execução.
A operação de multiplicação com sinal pode ser feita por meio de um circuito
multiplicador, um algoritmo de sequência de somas, ou seguir a estratégia do algoritmo
de Booth, em que apenas as adições e deslocamentos são realizados. Esta última é a que
apresenta a melhor vantagem em termos de economia em área, pois ao invés de usar um
elemento multiplicador, apenas a ULA é utilizada para estas funções. Por outro lado,
toda a lógica de multiplicação é realizada pela unidade de controle através de um
algoritmo inserido no microprograma, o que demanda muito mais ciclos de relógio para
sua execução, prejudicando o seu desempenho. A Figura 5.1 apresenta um fluxograma
de execução do algoritmo de Booth para uma multiplicação com sinal.
69
Figura 5.1 - Fluxograma de multiplicação por algoritmo de Booth
Fonte: [Patterson, 2007]
Para implementar o algoritmo, são necessários registradores para armazenar o
multiplicador (Q) e o multiplicando (M), um somador/subtrator, uma lógica de
deslocamento, uma estrutura de decisão e alguns registradores e bits de controle para
armazenar as variáveis Q-1 (bit posicionado logicamente à direita do bit menos
significativo do multiplicador) e Qin (que concatena os valores de Q0 e Q-1). Como é
necessário efetuar um deslocamento no valor do quociente, e este é distribuído entre HI
e LO, também é necessário criar um mecanismo de transferência de dados entre os
registradores para manter o significado correto do valor resultante. Sugere-se a criação
da instrução SRC (Shift Right with Carry), para setar o MSB de um registrador ao
deslocar um valor para a direita, necessário para implementar a correta relação entre HI
e LO.
A operação de divisão, apesar de ser mais complexa, também pode ser realizada
usando apenas adições, subtrações e deslocamentos, evitando a adição de um bloco
funcional divisor. Esta opção também reduz a complexidade do caminho de dados e
70
aumenta a complexidade do controle. Como procedimentos adicionais, faz-se necessário
implementar uma lógica de extensão de sinal (para divisão com sinal) e extensão de
zeros à esquerda (para divisão sem sinal) e, se desejado, flags de erros de divisão por
zero. A Figura 5.2 detalha o processo de divisão com sinal pela estratégia de Booth.
Figura 5.2 – Fluxograma de uma divisão por algoritmo de Booth
Fonte: [Patterson, 2007]
Em ambos os casos, podem ocorrer iterações em que não são realizadas
operações de somas/subtrações, sendo efetuados apenas os deslocamentos. Dependendo
de como esta lógica foi projetada no dispositivo, significa que podem ocorrer interações
com somas + deslocamentos, necessitando de dois ciclos de relógio, e interações com
apenas um ciclo. Isto faz com que não seja possível definir uma quantidade fixa de
ciclos de relógio para sua execução, podendo-se se apenas afirmar que são necessários
no mínimo 32 ciclos para tais operações.
Um circuito multiplicador ou divisor interno na ULA geralmente necessita de 32
ciclos de relógio por operação, enquanto um componente multiplicador ou divisor
71
dedicados pode realizar tais procedimentos em um único ciclo de relógio, o ideal para
instruções em máquinas RISC. No entanto, a inclusão de multiplicadores e divisores
pode provocar uma alteração na frequência de relógio do processador. Em testes com
dispositivos da família Cyclone II Altera®, a frequência de operação de um processador
a 50 MHz regrediu para 7 MHz após a inclusão de uma megafunção multiplicador.
Também é necessário algum método de deslocamento para esquerda ou direita,
para instruções específicas de deslocamento ou como parte de outras instruções. Este
deslocamento pode ser realizado usando um componente deslocador específico ou
internamente pela ULA. O deslocamento de apenas um bit por ciclo não implica em
praticamente nenhum custo adicional em área, mas, consequentemente, um
deslocamento de 32 bits precisa de 32 ciclos de relógio. Já um componente deslocador
pode deslocar até 32 bits em um único ciclo, mas são necessários mais elementos
lógicos, além de bits adicionais para seleção da direção e da quantidade de bits, o que
também implica em uma diminuição da frequência de operação, já que aumenta o
caminho percorrido por uma palavra de 32 bits no caminho de dados do processador,
acarretando também em um tempo maior para que a instrução seja efetuada.
5.3. Instruções de Branch
A base para o cálculo de endereço alvo do branch é o endereço da próxima
instrução em relação à instrução que ocasionou o branch. Este endereço deve ser
ajustado a um valor de offset para calcular o endereço relativo, sendo que o offset deve
ser deslocado 2 bits para aumentar o alcance do desvio, o que implica em uma
multiplicação por 4. Além do cálculo do endereço do branch, deve-se determinar qual
será o endereço utilizado, dependendo do resultado da operação.
Para executar estas instruções especiais de desvio relativas ao valor de PC é
necessária uma comparação entre registradores – geralmente por meio de operadores
relacionais (maior que, menor que, igual, diferente) e em seguida uma lógica de desvio
com base no resultado obtido. A primeira etapa pode ser realizada usando circuitos
lógicos específicos como comparadores, tornando mais rápido o processamento, mas
também mais complexo em área, ou então por meio da operação de subtração da ULA,
com o envio de sinalizadores (flags) para a unidade de controle. Esta segunda opção
quase não provoca impacto na arquitetura do caminho de dados, mas exige alguns ciclos
de relógio adicionais para envio dos operadores para a ULA e obtenção do resultado.
72
5.4. Comunicação com a memória
Embora o MIPS possua 32 bits de palavra, o endereçamento de memória no
MIPS é orientado a byte. Cada endereço de memória é relacionado a um identificador
de uma posição de memória de 1 byte (8 bits). Desta forma, uma palavra do processador
armazenada em memória ocupa 4 posições de um byte em endereços consecutivos. Esta
configuração provoca um impacto no funcionamento de instruções de leitura da
memória (load), em que um valor de base é multiplicado por quatro, ou na atualização
do valor do contador de programa (PC), que deverá ser ajustado na forma PC: = PC + 4.
Assim, a decisão de projeto sobre a comunicação entre a memória e o
processador implica em pelo menos duas possibilidades: definir a quantidade de bits
utilizados para o conteúdo da memória, o que provoca alteração na quantidade de
registradores e no barramento, e definir a forma como o valor de PC deve ser
atualizado, uma vez que o incremento do PC pode ser dado em 1 ou 4.
Na primeira opção, a memória pode ser implementada utilizando dados de 8 bits,
o que exige que cada operação de leitura em memória seja realizada em quatro buscas
de 1 byte cada um, utilizando 4 registradores temporários de 8 bits, e posteriormente
concatenar os quatro valores obtidos em um registrador de 32 bits. Na segunda opção,
podem ser utilizadas memórias com palavras de 32 bits, o que implica em apenas uma
busca na memória para cada dado ou instrução. Esta segunda opção é a que provoca a
menor alteração na complexidade da arquitetura, além de poder utilizar um valor padrão
de configuração de memória com 32 bits de palavra.
Para utilizar a configuração de 32 bits na atualização do contador de programa,
deve ser adotado o seguinte procedimento: para cada busca de uma instrução, o valor de
PC correspondente a quatro unidades é adicionado, da forma como se encontra no
padrão MIPS, mas os dois últimos bits do valor de PC devem ser ignorados na próxima
leitura. Por exemplo, considerando PC = 0x000000 (PC = 0) para a instrução 1, ao fazer
PC = PC + 4 o valor resultante será PC = 0x000100 (PC = 4) para a instrução 2, PC =
0x001000 (PC = 8) para a instrução 3, e assim sucessivamente. Fazendo com que o
barramento de dados que conecta PC aos demais blocos funcionais não considere os
últimos dois bits, os valores seriam considerados como PC = 0000 (PC = 0) para a
primeira instrução, PC = 0001 (PC = 1) na segunda instrução e PC = 0010 (PC = 2) para
a terceira instrução.
73
5.5. Instruções load/store
O tratamento de números com e sem sinal (representação em ponto fixo) afeta as
operações aritméticas e instruções de leitura / escrita. Uma instrução de carregamento
de um byte com sinal (load byte) replica o bit de sinal para os demais espaços de um
registrador de 32 bits, enquanto a mesma operação envolvendo um byte sem sinal (load
byte unsigned) preenche os demais campos do registrador com zeros à esquerda. Esta
funcionalidade requer duas máscaras para realizar uma função lógica com os valores
imediatos: uma máscara de inserção dos 32 primeiros bits com '0 'e a outra com '1'.
5.6. Considerações
Todas as instruções MIPS possuem um formato regular com palavras 32 bits,
ocupando 1 palavra em memória (32 bits), o equivalente a 4 endereços consecutivos em
memória. Cada instrução contém o código da operação e o(s) operando(s), caso
exista(m), especificando a quantidade de registradores que serão utilizados, de acordo
com a categoria em que a instrução se encontre (tipos R, J e I). Estas definições de
formato e tipo das instruções são tarefas da unidade de controle de cada processador,
onde são inseridos os comportamentos e características de cada instrução de seu
conjunto. A forma como as instruções são executadas é dada pela unidade operativa da
máquina, através de seu caminho de dados (data path).
Para qualquer processador (de 32 bits) que necessite utilizar o formato MIPS,
serão necessários obrigatoriamente os registradores PC, IR e mais 32 registradores já
especificados, além de uma ULA com operações lógicas e ao menos um somador. Os
demais aspectos, como a comunicação com a memória e a forma de execução das etapas
do ciclo de vida de uma instrução (busca, decodificação, execução, armazenamento),
poderão ser realizadas de diferentes maneiras, desde que possam implementar
corretamente todas as instruções existentes.
Como alternativa para aprimorar seu desempenho e adicionar novas instruções e
funcionalidades, é possível acrescentar uma lógica de reconfiguração quanto à sua
unidade de controle, tornando o processador um RISP. No capítulo seguinte, os
processadores apresentados como estudos de caso serão adaptados ao formato MIPS
seguindo a metodologia aqui apresentada, assim como exemplos de reconfiguração para
inserir novas instruções.
74
Capítulo 6 – Aplicações e Resultados
6.
Neste capítulo, os processadores utilizados como estudos de caso no Capítulo 4
são adaptados para a arquitetura MIPS, modificando suas unidades de controle para
conter o conjunto de instruções MIPS-I e suas unidades operativas para permitir a
execução destas novas instruções.
6.1. Adaptação 1: Processador DIMBA
Para o processador CABARE, optou-se pela menor quantidade de modificações
possíveis em sua unidade operativa, alterando apenas o necessário para que o
processador possa executar as instruções MIPS-I. Como a arquitetura já era de 32 bits,
não foi necessário alterar tamanho do barramento ou dos registradores. Com as novas
adaptações e sua nova arquitetura, o processador foi renomeado para DIMBA (DIdactic
MIPS Basic Architecture), cuja visão geral é apresentada na Figura 6.1.
Figura 6.1 – Visão geral do processador DIMBA
Fonte: autoria própria
75
Nas sessões a seguir serão apresentadas as mudanças efetuadas na arquitetura,
segundo a ordem da metodologia descrita no Capítulo 5.
6.1.1. Registradores
A arquitetura MIPS necessita de 32 registradores de trabalho, portanto a
primeira modificação obrigatória do processador consistiu em aumentar de 13 para 32
registradores. Além dos 32 registradores de trabalho, para manter a organização do
processador, os registradores PC, G, Mask e DIN também devem permanecer como
entradas do componente MUX. Ao invés de aumentar a quantidade de entradas do
MUX de 32 para 64 entradas por 3 registradores, optou-se por substituir o registrador
apontador global pelo valor de PC e os registradores reservados para tratamento de
interrupção K0 e K1 e o apontador de quadro pelos registradores necessários.
6.1.2. ULA
As operações presentes na unidade lógica e aritmética do DIMBA estão
dispostas na tabela 6.1. A codificação das operações segue o formato do operando funct
presente nas instruções MIPS do tipo R.
Tabela 6.1 – Operações da ULA do DIMBA
Código Operação Função
000000 SLL (shift left logic) C = B << 1 (LSB = 0)
000001 SLA (shift letf arithmetic) C = B << 1 (LSB = 1)
000010 SRL (shift right logic) C = B >> 1 (MSB = 0)
000011 SRA (shift right arithmetic) C = B >> 1 (MSB = 1)
011000 MULT C = A * B
011010 DIV C = A / B
100000 ADD C = A + B
100010 SUB C = A – B
100100 AND C = A and B
100101 OR C = A or B
100110 XOR C = A xor B
100111 NOR C = A nor B
101010 SLT (Set Less Than) C = 1 when A > B
101011 SLTU (SLT Unsigned) C = 1 when A > B
101110 NOT C = NOT(A)
110001 DEC C = A – 1
110011 INC C = A + 1
76
Para a multiplicação e divisão, foi adotada a estratégia de Booth para manter sua
simplicidade. Desta forma, todas as operações aritméticas são realizadas pela ULA. A
organização do CABARE/DIMBA permite a movimentação de apenas um dado por
ciclo, além de não ser possível realizar uma soma e um deslocamento ao mesmo tempo.
Como os resultados temporários estão divididos nos registradores HI e LO, sendo
necessário efetuar 2 deslocamentos. Desta forma, a implementação da técnica de Booth
no DIMBA utiliza 32 interações contendo 10 passos, além da etapa inicial de
carregamento dos registradores e de uma etapa de verificação de índice, que resulta em
aproximadamente 360 ciclos para sua completa execução. A divisão utiliza alguns
ciclos devido à necessidade de extensão de zeros ou extensão de sinais. O quadro a
seguir apresenta o microprograma utilizado para a multiplicação.
6.1.3. Instruções de Branch
Assim como para as demais funcionalidades adicionais, não foi criada uma
estrutura específica para a lógica de Branch. Para cada comparação entre registradores,
são necessários 3 ciclos para que os valores sejam enviados à ULA e se obtenha o
resultado. Em seguida, os flags da ULA são utilizados dentro do microprograma para as
I = 0, LO = RS (Q), Q-1 = 0
A = ZERO, HI = ZERO
WHILE I <= 31
(START)
IF Q0 & Q-1 = 00 OR 11 THEN GOTO DESL0
ELSE IF Q0 & Q-1 = 01 THEN GOTO ADD
ELSE IF Q0 & Q-1 = 10 THEN GOTO SUB
END IF; I = I + 1
(ADD)
G = A + RT (M); HI = G; GOTO DESL1
(SUB)
G = A + RT (M); HI = G; GOTO DESL1
(DESL0)
G = A or ZERO; GOTO DESL1 (update A)
(DESL1)
G = G >> 1 (c/ logic right shift)
A = G
G = LO
LO = G >> 1 (update LO31)
G = A OR ZERO
HI = G; GOTO START
77
estruturas de decisão de acordo com a instrução requerida. Como existem algumas
instruções que requerem algum comportamento adicional, como salvar um link de
retorno, as instruções de desvio condicional necessitam de 3 ou 9 ciclos antes de iniciar
a sequência de Branch.
Para implementar a lógica das instruções relativas ao PC, o contador de
programa é enviado para o registrador Acumulador, que por sua vez é deslocado duas
vezes seguidas para o ajuste de offset (PC = PC + 4), e por último realizar uma soma
final para o resultado final.
6.1.4. Comunicação com a memória
A memória utilizada possui 32 bits de palavra. Dessa forma, é possível realizar
apenas uma busca na memória para buscar dados e instruções no DIMBA. Entretanto,
para continuar se adequando ao padrão de organização de memória em bytes no MIPS,
na descrição do código do mapeamento de bits entre o processador e a memória, o valor
do endereço é enviado sob a forma “endereço (XX downto 2)”, ou seja, excluindo os
dois últimos bits de endereço.
6.1.5. Instruções de Load/Store
As instruções de escrita devem ser ajustadas no processador antes de serem
enviados à memória. Entre as modificações, podem ser citados valores com extensão de
sinais (para números inteiros), valores com extensão de zeros (para valores sem sinal),
valores em que é necessário excluir os bits referentes ao código da operação e, por
último, instruções que requerem apenas um byte de dados.
A solução foi criar máscaras de bits. As máscaras para extensão do MSB foram
incluídas dentro do microprograma na unidade de controle. Já para instruções que
trabalham apenas com bytes, foi criado um registrador especial nomeado mask_pc,
situado na saída da ULA, cuja função é considerar apenas o último byte do valor de
entrada, alterando o valor dos demais 24 bits para zero.
Como exemplo de simplicidade do processador na execução de instruções, a
instrução LUI (Load Upper Immediate) determina que um valor de 16 bits seja
armazenado nas posições 31-16, completando as demais posições com zero. Como não
existe um deslocador no DIMBA, a única forma de efetuar tal operação é utilizar as
78
instruções de deslocamento na ULA, e como esta só efetua o deslocamento de 1 bit por
vez, são necessários 16 deslocamentos à esquerda para concluir a instrução.
6.1.6. Reconfiguração
Para reconfigurar uma instrução MIPS, é necessário conhecer por completo o
caminho de dados do processador para que seja possível escrever o microprograma de
cada nova instrução definindo os sinais de controle das unidades funcionais do
processador, além da técnica utilizada para possibilitar a inclusão de novas instruções. A
diferença neste caso está no fato de que no CABARE é possível utilizar qualquer código
de operação que tenha seus 4 primeiros bits iguais a ‘1’, enquanto que no DIMBA os
códigos válidos devem ser referentes às instruções presentes na arquitetura MIPS. No
DIMBA, as instruções e as microinstruções contendo os bits de controle já vêm
inseridas na memória externa, juntamente com as demais instruções do programa, assim
como era realizado no CABARE.
Outra modificação na reconfiguração diz respeito aos formatos de instrução. O
MIPS possui três formatos definidos (tipos R, I e J), sendo que cada formato distribui os
bits da instrução de forma particular e não existe uma codificação na instrução que
identifique o formato utilizado. A única característica que define as instruções do tipo R
é o seu código de operação conter todos os 6 bits iguais a 0, e a operação
lógica/aritmética definida pelos últimos 6 bits, que identificam a operação da ULA.
Como o código de operação é idêntico para várias instruções, não é possível
fazer uma relação do CodOp com uma posição de memória para realizar o
endereçamento indireto das microinstruções. A solução adotada foi reservar 128
posições de memória para conter os ponteiros de instruções MIPS. A primeiras 64
posições devem estar no intervalo 0xFF...80 a 0xFF...BF, sendo os 6 últimos bits
provenientes dos valores da operação da ULA indicados na instrução se o código da
operação for 0. As 64 posições restantes (0xFF...C0 a 0xFF...FF) recebem os 6 últimos
bits pelo código da operação das demais instruções MIPS. A Figura 6.2 apresenta um
exemplo de divisão de áreas de uma memória RAM para armazenamento de dados,
instruções e microprograma no DIMBA.
79
Figura 6.2 – Áreas de memória do processador DIMBA
Fonte: autoria própria
A tabela de formatos das microinstruções também foi alterada, visto que os
registradores podem receber ou salvar o conteúdo indicado pelos registradores rs, rt ou
rd. Para tanto, foram criadas variáveis internas na unidade de controle que armazenam
os valores de cada registrador provenientes da instrução recebida. A Tabela 6.2
apresenta os formatos suportados pela arquitetura.
Tabela 6.2 – Formatos de microinstruções do DIMBA
Formato Utilização da microinstrução
0000 microinstrução tipo (a)
0001 microinstrução tipo (c)
0010 R_In = Rs
0011 R_In = Rt
0100 R_In = Rd
0101 Mux = Rs
0110 Mux = Rt
0111 Mux = Rd
1000 Mux = mux_mask(8)
1001 Mux = mux_mask(8) ES
1010 Mux = mux_mask(16)
1011 Mux = mux_mask(16) ES
1100 Mux = mux_mask(26)
1101 Mux = mux_mask(26) ES
1110 Não usado
1111 Não usado
80
Como a quantidade de unidades funcionais foi modificada, então a quantidade
de bits de controle que formam uma microinstrução reconfigurada também deve ser
ajustada à nova arquitetura. O campo referente aos registradores agora contém um
decodificador na unidade de controle, reduzindo a quantidade de bits de 13 na versão
original para 5 na versão MIPS. O multiplexador aumentou a quantidade de canais de
entrada, utilizando agora 5 bits de seleção. A ULA aumentou sua quantidade de
operações e também utiliza um bit a mais na versão adaptada. Foram incluídos os bits
de controle dos registradores HI e LO e 2 bits de seleção do multiplexador de saída da
ULA. Ao todo, são utilizados 32 bits de controle, podendo ser armazenada cada
microinstrução em apenas uma posição de uma memória de 32 bits. A Tabela 6.3
contém a configuração final de bits do DIMBA.
Tabela 6.3 – Formato de uma microinstrução no DIMBA
Formato Regs MUX MUX_ULA ULA IR A G DOUT HI LO ADDR WD RD END
4 5 5 2 6 1 1 1 1 1 1 1 1 1 1
Ao receber uma instrução não pertencente ao conjunto original do processador,
será efetuada uma busca na memória no endereço especificado pelo código da operação
ou pelos bits de função. Esta posição de memória contém o endereço da primeira
microinstrução que implementa o comportamento da nova instrução. As
microinstruções são executadas até que seja recebido um valor de bit_end igual a ‘1’.
As novas instruções são buscadas após o estágio de decodificação de uma
instrução, como um estágio de exceção. Por este motivo, não é possível substituir uma
instrução já existente por uma de um mesmo CodOp, já que se tal código for existente, a
máquina de estados do processador seguirá para os estágios de execução da instrução
fixa do processador.
Devido à limitação do CABARE/DIMBA, algumas instruções MIPS não podem
ser reconfiguradas ou apenas parcialmente reconfiguradas, como por exemplo as
instruções de deslocamento. Como a unidade não possui um deslocador, não é possível
receber os bits referentes à quantidade de deslocamentos provenientes da instrução sem
aumentar a complexidade da unidade de controle. Ainda que fosse possível receber tais
valores, convertê-los para o tipo de dado inteiro, utilizá-los como índices de uma
estrutura de repetição e fazer com que a ULA deslocasse 1 bit por vez para a esquerda
ou direita até atingir a quantidade informada, este procedimento causaria um impacto
31 0
81
significativo em área, número da máquina de estados e desempenho em sua execução, o
que foge ao escopo do objetivo de simplicidade do processador. Portanto, caso seja
desejado reconfigurar uma operação de deslocamento no DIMBA atual, este será de
apenas 1 bit.
Para todas as instruções, é necessário conhecer o código da instrução, seu
formato, modo de funcionamento e configuração de bits. Serão utilizadas como
exemplo duas instruções MIPS: MFHI e ADD. De acordo com [MIPS 2008], a
instrução MFHI rd (Move From HI Register) copia o valor do registrador HI para o
registrador rd, possuindo a configuração de bits apresentada na Figura 6.3.
Figura 6.3 – Codificação da instrução MFHI
Fonte: [MIPS, 2008]
Para MFHI $t0, os 32 bits de código desta instrução são
00000000000000000100000000010000, ou em hexadecimal 0x00004010. Como a
instrução não requer uma operação aritmética ou deslocamento, os bits de controle da
ULA devem permanecer em ‘0’ ou ‘–’ (don’t care). Como as instruções MIPS possuem
posições fixas de registradores, a unidade de controle já previamente copia os bits das
posições correspondentes e as reenvia como bits de controle para os barramentos ou
multiplexadores de acordo com o formato de cada microinstrução.
A instrução MFHI necessita de duas microinstruções, em virtude do tempo
necessário para que ocorra a sincronização de dados no nível RTL (Register Transfer
Level) do processador. A primeira microinstrução deve fazer com que o valor de HI seja
enviado pelo multiplexador de saída da ULA para ser armazenado em G, já que os
registradores HI e LO não são entradas de seleção do MUX de 32 canais. A segunda
microinstrução deve utilizar o valor de G como saída para o barramento de dados, e
posteriormente salvo no registrador indicado na instrução. A configuração final das
microinstruções é dada por:
82
(1) G HI
Formato Regs MUX MUX_ULA ULA IR A G DOUT HI LO ADDR WD RD END
0 - - HI - 0 0 1 0 0 0 0 0 0 0
(2) R8 G, BIT_END
Formato Regs MUX MUX_ULA ULA IR A G DOUT HI LO ADDR WD RD END
4 Rd G - - 0 0 0 0 0 0 0 0 0 1
A instrução ADD rd, rs, rt possui sua codificação apresentada na Figura 6.4.
Apesar de ser uma instrução praticamente obrigatória em qualquer processador, será
utilizada como exemplo para ilustrar a reconfiguração de qualquer instrução lógica ou
aritmética, já que apenas o código da ULA é alterado conforme a operação.
Figura 6.4 – Codificação da instrução ADD
Fonte: [MIPS, 2008]
Esta instrução trabalha com os três registradores enviados pela instrução, sendo
cada um deles utilizado em uma microinstrução diferente, o que exige diferentes
formatos de microinstruções. A primeira microinstrução deve fazer com que o
acumulador A receba o valor de rs, a segunda microinstrução envia para a segunda
entrada da ULA o valor identificado por rt, e a última deve armazenar o resultado da
operação em rd. A configuração final das microinstruções é dada por:
(1) A rs
Formato Regs MUX MUX_ULA ULA IR A G DOUT HI LO ADDR WD RD END
5 - rs 0 - 0 1 0 0 0 0 0 0 0 0
(2) G A + rt, ULA = operação
Formato Regs MUX MUX_ULA ULA IR A G DOUT HI LO ADDR WD RD END
6 - rt 0 Func 0 0 1 0 0 0 0 0 0 1
(3) rd G, BIT_END
Formato Regs MUX MUX_ULA ULA IR A G DOUT HI LO ADDR WD RD END
4 Rd G - - 0 0 0 0 0 0 0 0 0 1
83
6.1.7. Análise Comparativa
A Figura 6.5 mostra os dois processadores apresentados nas Figuras 3.1 e 6.1,
dispostos lado a lado, a fim de facilitar a visualização das modificações efetuadas no
caminho de dados da nova arquitetura.
Figura 6.5 – Comparação do caminho de dados (a) CABARE x (b) DIMBA
Fonte: autoria própria
84
A Tabela 6.4 apresenta os dados de compilação de cada um dos processadores
deste estudo de caso. Os dados foram compilados para o dispositivo EP2C35F672C6 da
família de FPGAs Cyclone II da Altera® presente no kit de desenvolvimento DE2 do
mesmo fabricante o qual contém 33216 elementos lógicos e 475 pinos. Para a simulação
e síntese, foi utilizado o software Quartus II®.
Tabela 6.4 – Síntese dos processadores CABARE e DIMBA
Elementos Lógicos Combinacionais / Registradores CABARE DIMBA
Processador 1487 / 638 (5%) 2841 / 1658 (9%)
|botao 2 / 2 2 / 2
|control_unit:unidade_controle| 291 / 68 1006 / 474
|men_manager:men_manager1| 5 / 5 5 / 5
|parte_operativa:operacoes| 1155 / 561 1794 / 1175
|convBCD32:conversor7Seg| 56 / 0 56 / 0
|latch_byte:mask_pc| -- 0 / 8
|multiplexador:multiplexador1| 367 / 0 648 / 0
|mux4:multiplexador_ula| -- 16 / 0
|registradorComum: registradores 0 / 384 0 / 832
|registradorComum:registradorADDR| 0 / 13 0 / 13
|registradorComum:registradorA| 0 / 32 0 / 32
|registradorComum:registradorDIN| -- 0 / 32
|registradorComum:registradorDOUT| 0 / 32 0 / 32
|registradorComum:registradorG| 0 / 32 25 / 32
|registradorComum:registradorIR| 0 / 32 0 / 32
|registradorComum:registrador_MEM| -- 0 / 32
|registradorHI:registrador_HI| -- 1 / 32
|registradorLO:registrador_LO| -- 1 / 32
|registradorPC| 39 / 32 32 / 32
|registradorSP:registrador29| -- 11 / 32
|registradorR:registradorR1| 0 / 1 0 / 1
|registradorW:registradorW1| 0 / 1 0 / 1
|ula:Ula1| 217 / 3 360 / 0
Clock_SETUP 29.46MHz 41.09MHz
Considerando que foi preciso adicionar 20 registradores no DIMBA
(adicionando 640 elementos lógicos), substituir o formato e o conjunto e de instruções
de 21 para 46 instruções, expandir a quantidade de operações da ULA e a capacidade da
lógica reconfigurável, houve um acréscimo total de 4% de área em chip no dispositivo
utilizado.
85
6.2. Adaptação 2: Processador CRASIS II
A adaptação do CRASIS ocorreu sob duas formas: para a primeira versão, não
foi considerada a característica de alternância entre conjuntos de instruções. A segunda
versão contém o conjunto MIPS-I e um dos conjuntos de instruções originais do MIPS,
para possibilitar a seleção entre diferentes arquiteturas. O processador, nomeado
CRASIS II, contém o caminho de dados ilustrado na Figura 6.6.
Figura 6.6 – Visão geral do CRIS/CRASIS II
Fonte: autoria própria
6.2.1. Registradores
A organização original do CRASIS já utilizava 32 registradores de trabalho,
sendo necessária para esta adaptação somente seguir a ordem convencionada para os
registradores $0 a $31. O registrador PC foi alocado no registrador da posição $28,
substituindo a função do apontador global. Também foram criados os registradores HI e
LO para as operações de multiplicação e divisão, e alguns registradores para serem
utilizados como máscaras, explicados posteriormente.
86
6.2.2. ULA
Da mesma forma que no CABARE, a ULA de um processador MIPS deve
conter no mínimo as operações aritméticas e lógicas descritas na Tabela 5.1. Portanto,
utilizou-se o mesmo componente em VHDL em ambos os processadores. Este fato
evidencia mais uma característica de componentes descritos em HDLs como
Propriedades Intelectuais em processadores soft-core: a possibilidade do reuso de
código, funções, componentes ou mesmo unidades funcionais completas entre
diferentes arquiteturas.
Para as operações de multiplicação e divisão, poderiam ser incluídos circuitos
específicos para a realização destas operações, mas para efeitos de comparação de
desempenho entre o CRASIS II e o DIMBA, optou-se por seguir a mesma estratégia de
Booth, de acordo com os fluxogramas das Figuras 5.1 e 5.2, com algumas modificações
na sua implementação. Criou-se uma função em VHDL dentro da ULA denominada
mult_div, chamada sempre que a ULA receber o código de operação de uma
multiplicação ou divisão. Como a unidade contém um deslocador situado na saída da
ULA, são necessários menos ciclos do que para a execução no DIMBA. A
multiplicação com sinal necessita de 138 ciclos e a multiplicação sem sinal utiliza 2
ciclos a mais. Já a divisão requer 200 ciclos para a execução completa.
Apesar da ULA conter instruções de deslocamento, foi criado um componente
deslocador, com capacidade para deslocar até 32 bits por ciclo para esquerda ou direita.
O uso desse componente reduz ciclos de execução da máquina, mas requer o envio de
mais bits de controle para a unidade operativa, já que são necessários 5 bits para
informar a quantidade de deslocamentos e um bit adicional para informar a direção do
deslocamento.
6.2.3. Instruções de Branch
Foi projetada uma unidade de Branch contendo um comparador e flags para
identificar se o operando de entrada e o resultado da operação possuem valores iguais a
zero ou um número inteiro negativo. Estes flags são enviados para a unidade de controle
decidir pelo valor seguinte do contador de programa (PC).
87
6.2.4. Comunicação com a memória
A estratégia para a comunicação com a memória é a mesma adotada
anteriormente, alterando-se o valor da sequência de bits de endereços enviada do
registrador MAR para a memória, excluindo os dois bits menos significativos, o que
garante a lógica MIPS de multiplicação por 4, mas mantém a estrutura de posições
consecutivas de 32 bits na memória.
6.2.5. Instruções de Load/Store
Foram criados registradores de máscaras para esta adaptação. Os registradores
AMAS, OMASK, MBR_MASK e JMASK alteram o conteúdo de determinados bits de
um valor de entrada para 0 ou 1, dependendo da necessidade. Dentre estas, podem ser
citadas a exclusão dos bits do CodCop, utilizar apenas um byte ou uma palavra do
operando e extensão de zeros ou bits de sinal.
A instrução LUI pode ser executada em apenas um ciclo devido a presença do
componente deslocador, assim como todas as operações de leitura/escrita podem ser
realizadas em um ciclo em virtude da utilização das unidades tratadoras de
registradores.
6.2.6. Reconfiguração
Para reconfigurar uma instrução MIPS no CRASIS, os dados referentes às
instruções reconfiguráveis devem ser enviadas ao processador pelo programador via
barramento externo de dados e endereços, juntamente com um pedido de
reconfiguração. Este envio pode ser realizado através de algum wrapper ou uma
entidade externa por hardware ou ainda por software, sendo esta última possibilidade
uma sugestão para implementações futuras.
As alterações na unidade de reconfiguração no CRASIS para executar uma
instrução MIPS foram poucas, visto que a arquitetura anterior já estava preparada para
receber instruções em qualquer formato de configuração de bits com até 4 operandos e
possui instruções no formato de 3 registradores C = A op B. O CRASIS já continha 32
registradores de uso geral, por isso sua tabela de formatos já foi projetada com 5 bits de
código para cada registrador.
88
A unidade denominada tabela_codop, que valida ou não um endereço de
instrução, foi pré-configurada setando as posições da tabela relacionadas aos códigos de
operação já implementados. Isto resulta em duas características: não é possível
substituir instruções pré-existentes no conjunto MIPS e as instruções lógicas e
aritméticas não podem ser reconfiguradas, em razão de todas compartilharem o mesmo
código de operação com valor 000000.
Os bits de controle do CRASIS também precisaram ser adaptados para sua nova
versão. Assim como no DIMBA, a ULA precisa de 6 bits para seleção da operação
lógica ou aritmética. Como existe um componente deslocador, este pode receber a
configuração de shamt da instrução MIPS contendo a direção e a quantidade de
deslocamentos, permitindo a reconfiguração deste tipo de instruções. O multiplexador
de entrada do buffer de endereços foi substituído pelo multiplexador de saída do
barramento C. A unidade de branch não possui nenhum bit de controle, assim como as
máscaras de dados, que sempre realizarão a conversão de dados provenientes do
registrador IR. Considerando tais alterações, foram incluídos os bits de controle dos
registradores HI e LO e um bit para a ULA, o que resulta em uma palavra de
reconfiguração com exatos 32 bits, como mostra a Tabela 6.5.
Tabela 6.5 – Palavra de uma microinstrução no CRASIS II
Form A
MUX
B
MUX
ULA SH MBR MAR ENC MUX
C
MUX
MBR
HI LO W
R
BIT
END
6 bits 2 2 6 6 1 1 1 4 1 1 1 1 1
Para exemplificar a reconfiguração MIPS, serão utilizadas as mesmas
microinstruções da sessão anterior (MFHI e ADD). A instrução MFHI rd necessita de
apenas uma palavra de reconfiguração, no qual o multiplexador do barramento C recebe
como entrada o valor de HI, que por sua vez é enviado ao conjunto de registradores. A
codificação final da microinstrução é:
(1) rd HI
Form A
MUX
B
MUX
ULA SH MBR MAR ENC MUX
C
MUX
MBR
HI LO W
R
END
POS2 00 00 111111 000000 0 0 1 01 0 0 0 0 1
89
A instrução ADD rd, rs, rt, pode ser criada caso não existissem operações
anteriores com código 000000 ou então fosse desejado criar uma instrução com um
código diferente, mas com a mesma funcionalidade. Assim como as demais instruções,
esta é executada com apenas uma microinstrução. É necessário consultar a tabela de
formatos do CRASIS para verificar as posições corretas de rs (C), rd (A) e rt (B), bem
como a operação da ULA (funct). Sua codificação final é:
(1) rd rs + rt
Form A
MUX
B
MUX
ULA SH MBR MAR ENC MUX
C
MUX
MBR
HI LO W
R
END
POS2 00 00 100000 000000 0 0 1 01 0 0 0 0 1
Como o CRASIS II possui uma unidade de reconfiguração dedicada, é possível
aumentar o tamanho das memórias de dados e endereços conforme a expansão do
processador, o que não irá alterar o padrão de palavras de 32 bits para dados e
instruções.
A vantagem de uma unidade de reconfiguração específica frente a uma lógica
utilizando somente a memória de programa está no fato de que as novas instruções
podem ser enviadas a qualquer momento, em tempo de execução do processador, como
se fosse realizado um pedido de interrupção por hardware. As novas instruções não
precisam estar codificadas juntamente com as demais instruções dentro de um
programa, sendo inseridas no processador conforme a necessidade.
Em contrapartida, o uso de uma unidade física externa de reconfiguração
demanda mais elementos computacionais, influenciando na área em chip e velocidade
do processador, e necessita de um wrapper, uso de um barramento padrão tipo OCP ou
modificações em sua configuração de Entrada/Saída para se adaptar a diferentes
processadores e arquiteturas. Caso seja feita a opção de utilizar diferentes conjuntos de
instruções, cada arquitetura deverá ter suas próprias restrições de formatos, para impedir
que um formato com 4 registradores seja lido enquanto estiver no modo de operação
MIPS.
6.2.7. Análise Comparativa
Da mesma forma que na sessão anterior, a Figura 6.7 apresenta os caminhos de
dados das duas versões do processador CRASIS.
90
Figura 6.7 – Comparação do caminho de dados (a) CRASIS I x (b) CRASIS II
Fonte: autoria própria
91
A Tabela 6.6 mostra a comparação da síntese entre as versões do processador
CRASIS original contendo 3 conjuntos de instruções e apenas o segundo conjunto de
instruções implementado. Para a compilação e síntese, utilizou-se o dispositivo
EP2C35F672C6 da família de FPGAs Cyclone II da Altera®, com 33216 elementos
lógicos disponíveis e 475 pinos.
Tabela 6.6 – Síntese do processador variando conjuntos de instruções
Elementos Lógicos Combinacionais / Registradores
CRASIS I com 3 conjuntos (11%)
CRASIS I com 1 conjunto (9%)
CRASIS II com 1 conjunto (8%)
Processador 3387 / 1642 2968 / 1547 2366 / 192
|control_unit:unidade_controle| 1249/ 480 838 / 410 195 / 104
|parte_operativa:operacoes| 2128/ 1120 2120 / 1120 2139 / 1186
|deslocador32:unit_shift| 331 / 0 332 / 0 200 / 0
|latch32:unit_latch_a| 5 / 32 5 / 32 0 / 32
|latch32:unit_latch_b| 5 / 32 5 / 32 0 / 32
|latch32:unit_latch_c| -- -- 0 / 32
|mux32_4_to_1:unit_amux| 720 / 0 714 / 0 677 / 0
|mux32_4_to_1:unit_bmux| 659 / 0 659 / 0 679 / 0
|mux32_4_to_1:unit_mux_mar| 64 / 0 64 / 0 177 / 0
|registrador_32bits:unit_mar| 0 / 32 0 / 32 0 / 32
|registrador_mbr:unit_mbr| 35 / 32 32 / 32 0 / 32
|reg_file32:unit_regs| 40 / 992 40 / 992 49 / 992
|ula32:unit_ula| 269 / 0 269 / 0 224 / 0
|registrador_32bits:reg_ir| -- -- 0 / 32
|mbrmask:unit_mask_mbr| -- -- 47 / 0
|branch_full:unit_branch| -- -- 50 / 0
|registradorR:registradorR1| -- -- 0 / 1
|registradorW:registradorW1| -- -- 0 / 1
|cpu_rec:reconfiguracao| 9 / 17 9 / 17 -
Clock_SETUP 65.40MHz 65.40MHz 40MHz
Os resultados mostram um aumento da quantidade de elementos lógicos da
unidade de controle, o que era esperado não apenas pelo aumento do número de
instruções, mas também pela estrutura de decisão para definição do conjunto de
instruções utilizado. A utilização dos super-estados apresentados no Capítulo 3 pode
diminuir a quantidade de estados da FSM do dispositivo, mas por outro lado aumenta a
dificuldade da descrição na linguagem VHDL em encontrar as interseções relativas aos
bits de controle, ao mesmo tempo em que a compreensão e sequenciamento do código é
prejudicada. No entanto, considerando o total de área em chip, o aumento de 1 para 3
92
conjuntos de instruções acarretou uma diferença de pouco mais de 1% da área do
dispositivo.
No conjunto de instruções do CRASIS I, algumas instruções necessitam de
vários ciclos de relógio para sua execução completa. Utilizando o conjunto MIPS-I,
com exceção das instruções de multiplicação e divisão e das instruções de comunicação
com a memória, as demais instruções utilizam apenas um ciclo de execução (cada ciclo
contendo quatro subciclos de relógio), o que reduziu o tamanho da unidade de controle.
A ULA da versão original utilizava funções da biblioteca std_logic da linguagem
VHDL para implementar a operação de multiplicação, removida na versão MIPS.
Com o acréscimo de algumas unidades funcionais em sua unidade operativa a
exclusão dos estados e sinais que fornecem a comunicação com a unidade de
reconfiguração em sua unidade de controle (que representam cerca de 1% de aumento
de elementos lógicos), o valor total da área em chip reduziu em 3%, além do ganho de
desempenho com o aumento da velocidade de execução das aplicações.
6.3. Exemplo de uma aplicação
Para validar o funcionamento dos processadores, foi utilizado um exemplo
simples que obtém o fatorial de um número, visto que o mesmo contém instruções
aritméticas, de desvio condicional e incondicional e de Entrada/Saída. A execução da
aplicação foi realizada com base em um algoritmo contendo 11 instruções, definidas
conforme o quadro a seguir:
Algoritmo Fatorial:
Início: Leia Acc; (01)
A <= 1; (02)
B <= 1; (03)
C <= 1; (04)
Acc <= Acc - C; (05)
Se Acc = 0 então (06)
vá para Fim;
Fim Se;
Loop: B <= B + C; (07)
A <= A * B; (08)
Acc <= Acc - C; (09)
Se Acc != 0 então (10)
vá para Loop;
Fim Se;
Fim: Acc <= A; (11)
93
Para adaptar o algoritmo para a linguagem assembly do CABARE, deve ser
criado um arquivo .mif ou .hex para ser armazenado em sua memória. Como o
CABARE não possui instruções de multiplicação e divisão, foi utilizado um
microprograma contendo uma sub-rotina de multiplicação, análoga a uma função em
software, sendo desenvolvida como uma instrução reconfigurável com Código de
Operação 0xF0, do tipo MUL Rx, Ry.
Esta instrução reconfigurável recebe os valores de Rx e Ry na instrução e utiliza
obrigatoriamente em R6 e R7 como registradores temporários, armazenando o resultado
em Rx. O programa adaptado ao processador possui as instruções do quadro a seguir:
0000 : 01B00020; -- carrega em R11 o endereço de FAT
0001 : 080B0020; -- mv R0, R11 (armazena FAT em R0)
0002 : 01100001; -- mvi R1, #1
0003 : 01200001; -- mvi R2, #1
0004 : 01300001; -- mvi R3, #1
0005 : 01400001; -- mvi R4, #1
0006 : 01500000; -- mvi R5, #0
0007 : 04030000; -- sub R0, R3 (Acc = Acc – 1)
0008 : 1100000C; -- jz, #12 (Se Acc = 0 goto 000C)
0009 : 03230000; -- add R2, R3 (B = B + C)
000A : F0120000; -- mul R1, R2 (A = X * Y – inst. reconfiguravel)
000B : 04030000; -- sub R0, R3 (Acc = Acc – 1)
000C : 0C000009; -- jnz PC, #7 (Se Acc != 0 goto 0009)
000D : 00010000; -- mv R0, R1 (Acc = A)
000E : 1F000000; -- halt
[000F..001F] : 00000000;
0020 : 00000005; -- FAT
[0021..002F] : 00000000;
0030 : 40205000; -- (mul) R6 = X (R1)
0031 : 50105000; -- R7 = Y (R2)
0032 : 10040001; -- A = 1
0033 : 00005740; -- G = A
0034 : 00001920; -- G = G _ R7
0035 : F200003B; -- Se Z = 0, goto 3B
0036 : 00185E00; -- R7 = G
0037 : 00005640; -- A = R6
0038 : 40000020; -- G = R1 + R6
0039 : 00205E00; -- R6 = G
003A : F8000033; --jmp 33
003B : 24005601;
[003C..1FEF] : 00000000;
1FF0 : 00000030; -- endereço de mul
[1FF1..1FFF] : 00000000;
END;
94
Como o algoritmo de multiplicação depende dos valores de Rx e Ry, não é
possível determinar quantos ciclos de relógio são necessários para sua execução, visto
que a multiplicação de X por Y causa a execução da rotina de multiplicação Y vezes. A
simulação com FAT = 4 resulta em aproximadamente 20 us para sua execução. Para
FAT = 7, a execução completa do programa ocorre em torno de 52 us. A Figura 6.8
mostra que a cada multiplicação (Código de Operação 0x0010), o tempo para sua
execução se torna maior.
Figura 6.8 – Processo de simulação de um algoritmo no CABARE
Fonte: Captura de tela do software Quartus II
O quadro a seguir apresenta o código na linguagem assembly MIPS para o
fatorial, que pode ser utilizado no CRASIS II e no DIMBA. No caso do CRASIS,
devem ser excluídos do arquivo mif as microinstruções reconfiguráveis e os ponteiros
de endereços, já que o CRASIS contém uma unidade de reconfiguração externa.
95
Ao utilizar o DIMBA e a estratégia de Booth para a multiplicação, mesmo que
este algoritmo também não represente uma boa solução quanto ao desempenho de sua
aplicação devido à quantidade de ciclos necessários para o procedimento, existe um
limite de passos para sua execução, podendo ser melhor estimado o tempo total para
executar o programa. Foram necessários aproximadamente 100 us para a execução dos
exemplos de fatorial. A Figura 6.9 mostra um detalhe da tela de simulação contendo o
resultado da execução de FAT = 4.
Figura 6.9 – Processo de simulação de um algoritmo no DIMBA
Fonte: Captura de tela do software Quartus II
O programa MIPS utilizou 18 instruções, e a execução do algoritmo foi realizada
corretamente em todas as versões. Para este caso, não foi necessário o uso de instruções
reconfiguradas. Como o algoritmo de Booth foi utilizado somente para manter o nível
de complexidade de hardware do processador, ou seja, sem incluir nenhum elemento
funcional, este exemplo apenas valida o correto funcionamento do algoritmo no
processador utilizando instruções MIPS e mostra que a aplicação da metodologia para
adaptar processador a uma ISA padrão funciona adequadamente.
6.4. Considerações
No modo de reconfiguração apresentado no DIMBA, a técnica de
reconfiguração de instruções utilizando um microprograma armazenado em memória
RAM pode ser utilizada em qualquer processador, sem a necessidade de criar unidades
específicas de reconfiguração, sendo necessário apenas incluir mais estados na máquina
96
de estados do processador (desde que a unidade operativa da máquina possa executar as
novas operações descritas). A quantidade de microinstruções reconfiguráveis é similar
às utilizadas para executar as instruções fixas do processador. A penalidade está em
utilizar mais ciclos de relógio para os estágios adicionais de busca e decodificação e
mais leituras da memória em virtude do endereçamento indireto.
Já o acoplamento de uma Unidade de Reconfiguração Externa (RFU), com
funcionamento análogo a um co-processador dedicado, torna o processo de
reconfiguração de instruções independente do arquivo contendo o programa
armazenado, e o funcionamento desta unidade apresentou o mesmo resultado
satisfatório no que tange ao correto funcionamento do armazenamento e execução de
instruções MIPS, com a penalidade do aumento da área do dispositivo e expansão de
sinais de controle e mapeamento de bits entre as unidades operativa, de controle e de
reconfiguração.
A inclusão de unidades funcionais como deslocadores, multiplicadores, unidades
de ponto flutuante ou demais melhorias em sua estrutura física permite que um
processador MIPS-I possa executar instruções de seu conjunto original que não foram
implementadas em sua fase de desenvolvimento ou mesmo utilizar instruções MIPS-II
ou mais recentes, aumentando a compatibilidade entre dispositivos e de programas
executados, sem alterações em compiladores, montadores ou demais softwares básicos.
Os resultados também mostram que é possível cada processador executar
instruções da arquitetura MIPS apenas alterando o microprograma da unidade de
controle, como também executar instruções MIPS mantendo sua estrutura original por
meio das técnicas de reconfiguração apresentadas, também sendo possível manter o
processador em sua forma original e alternar entre conjuntos de instruções para suportar
diferentes arquiteturas, desde que suas unidades operativas possam compreender e
executar em todos os formatos desejados.
97
Capítulo 7 – Conclusões e Perspectivas
7. D
Considerando que o avanço e a redução de preço da tecnologia de FPGAs
permite uma grande disseminação de seu uso no meio acadêmico, o que propicia o
surgimento de diversos processadores de diferentes arquiteturas e níveis de
complexidade, é interessante que possa haver alguma forma de interação ou
comunicação entre tais dispositivos.
Apesar de haver uma compatibilidade entre dispositivos de uma mesma família
de arquiteturas ISA, como no caso dos processadores MIPS, e do fato de que a maioria
das instruções costuma ser de mesmo tipo e classe, tais instruções internas variam de
processador para processador e geralmente são incompatíveis entre arquiteturas
diferentes. Possibilitar que um processador possa executar instruções de outro
dispositivo de sua família, ou mesmo de outra arquitetura, é uma das principais
vantagens do uso de processadores com conjunto de instruções reconfiguráveis.
As arquiteturas MIPS permitem aos estudantes não apenas realizar práticas de
projetos envolvendo arquitetura de computadores e sistemas digitais, mas também o
desenvolvimento de IP’s, plug-ins, softwares básicos e técnicas de redução de potência
e incremento de desempenho. Também é possível escrever programas utilizando
linguagens de programação em alto nível como C/C++ e utilizar compiladores como o
Collection GNU Compiler (GCC) e simuladores como o MARS [Mars, 2013] ou SPIM
[Larus, 2013] para a geração de arquivos no formato hexadecimal (.hex) contendo o
código objeto do programa fonte, e os enviando para a memória dos processadores
didáticos. Esta interdisciplinaridade em disciplinas de hardware/software é um dos
maiores benefícios no que tange o projeto, desenvolvimento e implementação de
processadores didáticos.
Para o caso de processadores soft-core descritos em uma linguagem HDL, esta
tarefa se torna mais simples, pois os códigos-fontes das unidades operativa e de controle
de um processador estão descritas em linguagem de descrição de hardware, sendo
suficiente alterar ou acrescentar novos componentes aos arquivos HDL.
98
A partir dos estudos de caso abordados nesta tese, pode-se afirmar que é possível
adaptar processadores sem uma ISA definida ou contendo apenas uma parte de uma
arquitetura padrão a qualquer arquitetura de conjunto de instruções, com poucas
alterações em sua estrutura e organização original, mantendo seu nível de complexidade
de hardware.
Por estarem inseridos em um universo de dispositivos FPGA, no qual a
quantidade de elementos lógicos é fixa para cada processador, em termos de área não
importa se uma arquitetura utilize 2% ou 90% da sua capacidade. Investir em
processadores simples, com baixo nível de complexidade em hardware, mas que
possam executar aplicações da mesma forma que processadores mais robustos, sem
perdas significativas de desempenho, mostram que os processadores RISC e FPGAS do
tipo RISP podem continuar a ser tema de pesquisas científicas e acadêmicas.
Desta forma, é possível alterar a arquitetura de um processador
microprogramado mantendo seu nível de organização apenas substituindo o código de
sua unidade de controle, analogamente como se o computador sofresse uma atualização
no seu firmware. E, adicionalmente, caso o processador seja do tipo RISP, é possível
inserir ou atualizar instruções de sua arquitetura em tempo de execução do processador,
como se as novas instruções fizessem parte do conjunto original de instruções da
máquina. Por último, como prova de conceito, a possibilidade de um processador ser
capaz de selecionar diferentes arquiteturas de instruções dentro de um mesmo
dispositivo abre uma possibilidade de pesquisas em arquiteturas híbridas adaptativas,
contendo dentro de uma mesma estrutura diferentes ISA’s, como MIPS, SPARC e x86.
Além disso, tal projeto deve permitir um modo de programar a arquitetura para
executar atividades determinadas. Dessa forma, a arquitetura pode ser definida como
um conjunto de atributos da máquina que um programador deve compreender para que
consiga programar o computador específico com sucesso, ou seja, para que consiga
compreender o que o programa irá fazer quando a máquina executar.
O estudo sobre organização e arquitetura de computadores faz parte do currículo
da maioria dos cursos de computação e a compreensão e aplicação dos conceitos
representa um desafio para os discentes, uma vez que as atuais arquiteturas de
computadores pessoais são complexas e muitas vezes contêm restrições no que tange ao
consumo de energia e espaço em chip. Portanto, a utilização de uma arquitetura simples
constituída pelos principais recursos necessários para uma máquina programável, pode
servir como uma ferramenta extremamente útil para fins didáticos.
99
A forma como os diversos componentes de um computador são organizados
define o conceito de arquitetura de um computador, determinando aspectos relacionados
à qualidade, ao desempenho e à aplicação para a qual o computador vai ser orientado. O
projeto de uma arquitetura de computador vai além do desenho da estrutura física de um
processador, devendo levar em consideração a organização interna dos componentes do
processador como registradores, unidades lógica e aritmética, barramentos; o conjunto
de instruções; organização e modos de endereçamento da memória; suporte a periféricos
ou dispositivos de entrada e saída para comunicação do processador com o mundo
externo.
7.1. Trabalhos Futuros
Até a finalização deste texto, os temas abordados nesta tese resultaram nas
seguintes publicações: (Silva, 2011), (Costa, 2012), (Casillo, 2012) e (Casillo, 2012a),
além de um capítulo do livro “Workshop Técnico-Científico de Computação”,
abordando o tema “Metodologia para projeto de processadores RISP”, a ser publicado
em 2013 pela editora EDUFERSA. Os processadores didáticos projetados foram alvo de
estudo ou ferramenta para diversos trabalhos de iniciação científica e artigos em
congressos regionais e nacionais.
Dentre os trabalhos que exploram as características dos processadores, (Nunes,
2012) propôs uma técnica de implementação de um pipeline para processadores soft-
core, utilizando como estudo de caso o processador CRASIS I, a partir da replicação de
máquinas de estados (FSM). É possível criar várias linhas de execução, possibilitando que
mais de uma instrução esteja em execução ao mesmo tempo. As FSMs são sobrepostas de
modo similar a um pipeline, sem que o mesmo estado em estados de diferentes unidades
fique ativo ao mesmo tempo. A grande maioria das instruções do CRASIS são executadas
em um ciclo de relógio. Porém, instruções de acesso à memória e desvios, que são bastante
recorrentes em programas comuns, são executadas em mais de um ciclo. No CRASIS, estas
instruções podem durar até três ciclos de clock. No entanto, esta proposta não foi
implementada neste trabalho para que fosse mantida a simplicidade do processador e
sua comparação com o processador DIMBA, visto que este último não contém nenhuma
técnica de aumento de desempenho em sua estrutura, sendo indicada a implementação
das técnicas de pipeline nos processadores como trabalhos futuros.
100
As versões adaptadas dos processadores não contém operações de suporte ao
sistema operacional, interrupção e exceção. Devido a estas limitações, as instruções
syscall e break, presentes no conjunto de instruções MIPS-I, não foram implementadas,
sendo ideias para futuras modificações em suas estruturas.
Este trabalho não considerou o consumo de potência de FPGAs como fator
relevante na implementação das técnicas propostas. Segundo [Anderson & Najm, 2006],
por carregarem o estigma de consumirem muita energia, os FPGAs geralmente são
preteridos por processadores ASIC e de propósito gerais em razão de suas
características de alto desempenho energético sem perdas de capacidade de
processamento ou velocidade. Por consequência, os FPGAS hoje são utilizados como
plataformas de simulação de sistemas digitais e como kits de desenvolvimento de
trabalhos acadêmicos. Diversos trabalhos já foram temas de pesquisa acerca de técnicas
de redução de potência em processadores reconfiguráveis, para poder expandir sua
capacidade de processamento além de seu uso acadêmico.
Ao se obter um baixo consumo de potência de um FPGA, juntamente com a
característica de alteração ou atualização de uma ISA em um processador
reconfigurável, poderá ser possível o desenvolvimento de uma nova gama de utilizações
de processadores RISP. Assim como são comumente realizadas atualizações do
software via rede, e mais recentemente atualizações de firmware e BIOS de
computadores, poderá ser viável atualizar uma unidade de controle como se fosse
efetuada a substituição do “kernel” da máquina, atualizando conjuntos de instruções de
uma mesma família (como MIPS-I e MIPS-II) ou mesmo adicionando instruções ao
inserir novas funcionalidades como uma unidade de ponto flutuante.
101
Referências Bibliográficas
Adário, A. M. S.; Bampi, S.; Jacobi, R. P. (1997) Reconfigurable architectures. In:
UFRGS MICROELECTRONICS SEMINAR. Porto Alegre, RS, Brasil: UFRGS
MICROELECTRONICS SEMINAR, 1997. p. 133–136. ISBN T.I. - 650 – CPGCC.
Altera (2013) website. Disponível em: http://www.altera.com
Altman, E. R., Kaeli, D., Sheefer, Y. Welcome to the opportunities of binary
translation. Computer, v. 33. n. 3. p. 40-45. 2000.
Anderson, Jason H.; Najm, Farid N. (2006) Active Leakage Power Optimization for
FPGA. IEEE Transactions on Computer-Aided Design of Integrated Circuits and
Systems. [S.l], p. 423-437.
Athanas, P. M., Silverman, H. F. (1993) Processor Reconfiguration Through
Instruction-Set Metamorphosis. IEEE Computer, Vol. 26, no. 3 pp.11-18. 1993.
Barat, F., Lauwereins, P. (2000) Reconfigurable Instruction Set Processors: A Survey,
in: RSP ’00: Proceedings of the 11th IEEE International Workshop on Rapid System
Prototyping (RSP 2000). Washington, DC, USA: IEEE Computer Society, 2000. p. 168.
ISBN 0-7695-0668-2.
Barat, Francisco (2002) Reconfigurable Instruction Set Processors from a
Hardware/Software Perspective, IEEE Transactions on Software Engineering, Vol. 28,
Nº 9.
Beck, A. C. S., Carro, L. Dynamic reconfiguration with binary translation: breaking the
ILP barrier with software compatibility. [S.1]:[s.n]. 2005. p. 732-737.
Beck, A. C. S., et al (2008) Transparent Reconfigurable Acceleration for
Heterogeneous Embedded Applications. [S.1]:[s.n]. 2008. p. 1208-1213.
Brown, S., Francis, R., Rose, J., Vranesic, Z. (1992) Field-Programmable Gate Arrays,
Kluwer Academic Publishers, Maio, 1992
Calazans, N.(2008) Organização de Computadores. UFRGS. Rio Grande do Sul. 2008.
Carter, W., Duong, K., Freeman, R. H. Hsieh, H., Ja, J. Y., Mahoney, J. E., Ngo, L. T.,
Sze, S. L. (1986) A user programmable reconfiguration gate array, in Proceedings of
the IEEE Custom Integrated Circuits Conference, pp. 233–235, May 1986.
102
Casillo, Leonardo A. (2005) Projeto e implementação em FPGA de um processador
com conjunto de instrução reconfigurável utilizando VHDL. 126 p. Dissertação
(Mestrado). Programa de Pós-Graduação em Sistemas e Computação, Universidade
Federal do Rio Grande do Norte, Natal, Maio, 2005.
Casillo, L. A., Lima, L. M. P., Souza, G. B., Silva, I. S. (2005a) Projeto e
Implementação em FPGA de um Processador com Conjunto de Instrução
Reconfigurável Utilizando VHDL. XI Workshop Iberchip. 2005, Salvador, Brasil.
Casillo, L. A., Silva, I. S. (2012) Adapting a low complexity datapath to MIPS-1.
Programmable Logic (SPL), 2012 VIII Southern Conference on, p. 1 – 6.
Casillo, L. A., Silva, I. S. (2012a) A Methodology to Adapt Data Path Architectures to a
MIPS-1 Model. Computing System Engineering (SBESC), 2012 Brazilian Symposium
on, 2012, p. 172-177.
Compton, K., Hauck, S., (2002) “Reconfigurable Computing: A Survey of Systems and
Software”, ACM Computing Surveys, v. 34, n. 2, p. 171-210, June 2002.
Corporation, Altera (2013) Altera Tutorials and Lab Exercises. Disponível em:
ftp://ftp.altera.com/up/pub/Altera_Material/11.0/Laboratory_Exercises/Digital_Logic/D
E2/verilog/lab9_Verilog.pdf. Acessado em maio, 2013.
Costa, R. V., Fernandes, S. R., Casillo, L. A., Soares, A. Freire, D. (2012) SICXE:
Improving Experience with Didactic Processors. Computing System Engineering
(SBESC), 2012 Brazilian Symposium on, 2012, pages 83-86.
Dos Santos, D. M. B., Pinto, G. R. P. R., Sena, C. P. P., Bertoni, F. C., & Bittencourt, R.
A. (2007) Aplicação do método de Aprendizagem Baseada em Problemas no curso de
Engenharia da Computação da Universidade Estadual de Feira de Santana. In:
Congresso Brasileiro de Educação em Engenharia - COBENGE
Fajardo Jr., J. (2011) Sistema de Tradução Binária de Dois Níveis para Execução Multi-
ISA. Dissertação de Mestrado. Porto Alegre. Agosto de 2011.
Ferlin, E., Pilla Jr, V., (2006) The Learning of Reconfigurable Computing in the
Computer Engineering Program, in: FIE 2006, San Diego, USA
Gorder, P. F., (2007) Multicore Processors for Science and Engineering, IEEE CS,
March/April 2007.
Kane, G.; Heinrich, J. (1991) MIPS RISC Architecture - 2nd Edition. Prentice-Hall, 544
p., 1991.
Knight W. (2005) Two Heads Are Better Than One, IEEE Review, September 2005.
Kumar, R. et al. (2005) Heterogeneous Chip Multiprocessor, IEEE Computer, Vol. 38,
Issue 11, pp. 32-38, 2005.
Larus, J. (2013) SPIM MIPS Simulator. Disponível em:
http://www.cs.wisc.edu/~larus/spim.html Acessado em: Maio/2013.
103
Leon (2013) LEON2 Processor User’s Manual XST Edition, Gaisler Research. 2013.
Liu, J., Chow, F., Kong. T,. Roy, R. (2003) Variable Instruction Set Architecture and Its
Compiler Support. IEEE Trans. Comput., IEEE Computer Society, Washington, DC,
USA, v. 52, n. 7, p. 881–895, 2003. ISSN 0018-9340.
Lodi, A., Toma, M., Campi, F., Cappelli, A., Guerrieri, R (2003) A VLIW Processor
Whit Reconfigurable Instruction Set for Embedded Applications. IEEE Journal of solid-
state circuits, IEEE Computer Society, Washington, DC, USA, v. 538, n. 11, 2003.
Martinez-Mones, A., Gomez-Sanchez, E., Dimitriadis, Y. A., Jorrin-Abellan, I. M.,
Rubia-Avi, B., & Vega-Gorgojo, G. (2005) Multiple Case Studies to Enhance Project-
Based Learning in a Computer Architecture Course. IEEE Transactions on Education,
48, 482–489.
MARS (2013) MIPS Assembly and Runtime Simulator. Disponível em:
http://courses.missouristate.edu/KenVollmar/MARS Acessado em: Junho/2013.
Mesquita, D. G. (2002) Contribuições para reconfiguração parcial, remota e dinâmica
de FPGAs. Dissertação (Tese de Mestrado) — Pontifícia Universidade Católica do Rio
Grande do Sul, Porto Alegre, RS, Brasil, Março 2002.
Mihal, A. Weber, S., Keutzer K. (2006) Sub-RISC processors. In P. Ienne and R.
Leupers, editors, Customizable Embedded Processors: Design Technologies and
Applications, chapter 13. Elsevier, 2006
MIPS Technologies (2008) MIPS32 Architecture For Programmers. Vol. II: The
MIPS32 Instruction Set, 2008.
Mooler, L. H., Moraes, F. G. e Calazans, N. L. V. (2005) Processadores
Reconfiguráveis: Estado da Arte, In. XI Workshop Iberchip, 2005, Salvador, Brasil.
Nunes, D. F., (2012) Proposta de implementação de um pipeline em um processador
reconfigurável baseado em MIPS. Monografia. Mossoró-RN. 70 p. 2012.
OpenCores (2013) website. Disponível em: http://www.open-cores.org.
OpenSPARC (2013) website. Disponível em: http://www.opensparc.org.
Oracle (2013) website. Disponível em: http://www.oracle.com/us/sun/
Patterson, D., Hennessy, J., (2007) Computer Architecture – A quantitative Approach.
4ª. Ed. Morgan-Kaufmann. 2007.
Patterson, D., Hennessy, J., (2008) Computer Organization and Design: The
Hardware/Software Interface. 4ª. Ed. 2008.
PROCSIM (2013), website. Disponível em: http://jamesgart.com/procsim/
104
Razdan, R.; Smith, M. D. (1994) A high-performance microarchitecture with hardware
programmable functional units. In: MICRO 27: Proceedings of the 27th annual
international symposium on Microarchitecture. New York, NY, USA: ACM Press,
1994. p. 172–180. ISBN 0-89791-707-3.
Rhoads, S. (2013) Plasma CPU Core. website. Disponível em http://www.open-
cores.org.
Rose, J., Gamal, A. El, Sangiovanni-Vincentelli, A. (1993) Architecture of Field-
Programmable Gate Arrays, in Proceedings of the IEEE, Vol. 81, No. 7, July 1993, pp.
1013-1029
Silva, I. S, Fernandes, S. R. , Casillo, L. A. (2011) ZONA -- An adaptable NoCbased
multiprocessor addressed to education on system-on-chip design. In MSE '11:
Proceedings of the 2011 IEEE International Conference on Microelectronic Systems
Education. 2011. Pages 108-111.
Stallings, W. (2010) Arquitetura e Organização de Computadores. 8ª ed. 640 p. Editora
Prentice-Hall. RJ, Brasil. 2010.
Sweetman, D. (2006) See MIPS Run. Morgan Kaufmann Publishers, 513 p., 2006.
Tanenbaum, A. S. (2007) Organização Estruturada de Computadores, 5ª Edição,
Pearson Prentice Hall, São Paulo, Brasil.
Tong, Jason G., Anderson, Ian D. L., Khalid, Mohammed A. S., (2006) Soft-Core
Processors for Embedded Systems. 18th International Conference on Microelectronics
(ICM). 2006.
Websimple – MIPS(2013) Simulador web-based do pipeline do MIPS. Disponível em:
http://matheus.ath.cx/simple/
Wilkes, Maurice V. (1951) The preparation of programs for an electronic digital
computer. Ed. Addison-Wesley Press. Universidade do Wisconsin – Madison. 1951.
Xilinx, Inc (2013) website. Disponível em: http://www.xilinx.com
105
Apêndice A - Codificação dos formatos
de Instruções no MIPS-I
Nome Form. Instrução
SLL -- Shift left logical R 0000 00-- ---t tttt dddd dhhh hh00 0000 SRL -- Shift right logical R 0000 00-- ---t tttt dddd dhhh hh00 0010 SRA -- Shift right arithmetic R 0000 00-- ---t tttt dddd dhhh hh00 0011
SLLV -- Shift left logical variable R 0000 00ss ssst tttt dddd d--- --00 0100
SRLV -- Shift right logical variable R 0000 00ss ssst tttt dddd d--- --00 0110
MFHI -- Move from HI R 0000 0000 0000 0000 dddd d000 0001 0000
MFLO -- Move from LO R 0000 0000 0000 0000 dddd d000 0001 0010
MULT -- Multiply R 0000 00ss ssst tttt 0000 0000 0001 1000 MULTU -- Multiply unsigned R 0000 00ss ssst tttt 0000 0000 0001 1001
DIV -- Divide R 0000 00ss ssst tttt 0000 0000 0001 1010
DIVU -- Divide unsigned R 0000 00ss ssst tttt 0000 0000 0001 1011
ADD – Add (with overflow) R 0000 00ss ssst tttt dddd d000 0010 0000 ADDU -- Add unsigned (no overflow) R 0000 00ss ssst tttt dddd d000 0010 0001
SUB -- Subtract R 0000 00ss ssst tttt dddd d000 0010 0010
SUBU -- Subtract unsigned R 0000 00ss ssst tttt dddd d000 0010 0011
AND -- Bitwise and R 0000 00ss ssst tttt dddd d000 0010 0100
OR -- Bitwise or R 0000 00ss ssst tttt dddd d000 0010 0101 XOR -- Bitwise exclusive or R 0000 00ss ssst tttt dddd d--- --10 0110
NOR -- Bitwise nor R 0000 00ss ssst tttt dddd d000 0010 0111
NOOP -- No Operation R 0000 0000 0000 0000 0000 0000 0000 0000
JR -- Jump register R 0000 00ss sss0 0000 0000 0000 0000 1000 SLT -- Set on less than (signed) R 0000 00ss ssst tttt dddd d000 0010 1010 SLTU -- Set on less than unsigned R 0000 00ss ssst tttt dddd d000 0010 1011
BGEZ -- Branch on greater than or equal to zero I 0000 01ss sss0 0001 iiii iiii iiii iiii
BGEZAL -- Branch on grt. or equ to zero and link I 0000 01ss sss1 0001 iiii iiii iiii iiii
106
BLTZ -- Branch on less than zero I 0000 01ss sss0 0000 iiii iiii iiii iiii
BLTZAL -- Branch on less. or eq to zero and link I 0000 01ss sss1 0000 iiii iiii iiii iiii
J -- Jump J 0000 10ii iiii iiii iiii iiii iiii iiii
JAL -- Jump and link J 0000 11ii iiii iiii iiii iiii iiii iiii
BEQ -- Branch on equal I 0001 00ss ssst tttt iiii iiii iiii iiii BNE -- Branch on not equal I 0001 01ss ssst tttt iiii iiii iiii iiii
BLEZ -- Branch on less than or equal to zero I 0001 10ss sss0 0000 iiii iiii iiii iiii
BGTZ -- Branch on greater than zero I 0001 11ss sss0 0000 iiii iiii iiii iiii
ADDI -- Add immediate (with overflow) I 0010 00ss ssst tttt iiii iiii iiii iiii
ADDIU -- Add immediate unsigned (no overflow) I 0010 01ss ssst tttt iiii iiii iiii iiii
SLTI -- Set on less than immediate (signed) I 0010 10ss ssst tttt iiii iiii iiii iiii
SLTIU -- Set on less than immediate unsigned I 0010 11ss ssst tttt iiii iiii iiii iiii ANDI -- Bitwise and immediate I 0011 00ss ssst tttt iiii iiii iiii iiii ORI -- Bitwise or immediate I 0011 01ss ssst tttt iiii iiii iiii iiii
XORI -- Bitwise exclusive or immediate I 0011 10ss ssst tttt iiii iiii iiii iiii LUI -- Load upper immediate I 0011 11-- ---t tttt iiii iiii iiii iiii
LB -- Load byte I 1000 00ss ssst tttt iiii iiii iiii iiii
LW -- Load word I 1000 11ss ssst tttt iiii iiii iiii iiii
SB -- Store byte I 1010 00ss ssst tttt iiii iiii iiii iiii
SW -- Store word I 1010 11ss ssst tttt iiii iiii iiii iiii
107
Apêndice B - Codificação dos formatos
de Operações no CRASIS
Esta codificação foi descrita para operações do tipo Op C, A, B, D. Os bits da
palavra de reconfiguração seguem a sequência Bar C (5 bits), Bar A (5 bits), Bar B (5
bits), Aux (5 bits).
Formato B_C B_ A B_ B Significado
000000 A A A A = A op A
000001 A A B A = A op A
000010 A B A A = A op B
000011 A B B A = B op B
000100 A A C A = A op C
000101 A C A A = C opA
000110 A C C A = C op C
000111 A C B A = C op B
001000 A B C A = B op C
001001 B B B B = B op B
001010 B B A B = B opA
001011 B A B B = A op B
001100 B A A B = A opA
001101 B B C B = B op C
001110 B C B B = C op B
001111 B C C B = C op C
010000 B A C B = A op C
010001 B C A B = C opA
010010 C C C C = C op C
010011 C C A C = C opA
010100 C A C C = A op C
010101 C A A C = A opA
010110 C B C C = B op C
010111 C C B C = C op B
011000 C B B C = B op B
011001 C A B C = A op B
011010 C B A C = B opA
011011 A A D A = A op D
011000 A B D A = B opD
011101 A C D A = C opD
011110 A D A A = D op A
011111 D B A A = D op B
100000 D C A A = D op C
100001 D D A A = D op D
100010 A D B B = A op D
108
100011 B D B B = B opD
100100 B C D B = C opD
100101 B D A B = D opA
100110 B D B B = D op B
100111 B D C B = D op C
101000 B D D B = D opD
101001 C A D C = A opD
101010 C B D C = B opD
101011 C C D C = C opD
101100 C D A C = D opA
101101 C D B C = D op B
101110 C D C C = D op C
101111 C D D C = D opD
110000 D A D D = A op D
110001 D D A D = D op A
110010 D B D D = B opD
110011 D D B D = D op A
110100 D C D D = C opD
110101 D D C D = X op C
110110 D D D D = D op D
110111 D A B D = A op B
111000 D B A D = B opA
111001 D A C D = A op C
111010 D C A D = C opA
111011 D B C D = B op C
111100 D C B D = C op B
111101 D A A D = A op A
111110 D B B D = B op B
111111 D C C D = C op C
*No CRIS/CRASIS 2 os formatos com 4 operandos não são suportados.
