UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Maicon Carlos...
161
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO μBIP: MICROCONTROLADOR BÁSICO PARA O ENSINO DE SISTEMAS EMBARCADOS Área de Arquitetura e Organização de Computadores por Maicon Carlos Pereira Cesar Albenes Zeferino, Dr. Orientador Itajaí (SC), julho de 2008
Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Maicon Carlos...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
µBIP: MICROCONTROLADOR BÁSICO PARA O ENSINO DE SIST EMAS EMBARCADOS
Área de Arquitetura e Organização de Computadores
por
Maicon Carlos Pereira
Cesar Albenes Zeferino, Dr. Orientador
Itajaí (SC), julho de 2008
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
µBIP: MICROCONTROLADOR BÁSICO PARA O ENSINO DE SIST EMAS EMBARCADOS
Área de Arquitetura e Organização de Computadores
por
Maicon Carlos Pereira Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Cesar Albenes Zeferino, Dr.
Itajaí (SC), julho de 2008
ii
DEDICATÓRIA
A Deus.
Aos meus pais (Alvino e Lourdes) por toda a educação, carinho e amor que sempre me deram,
aos meus irmãos (Arnaldo e Alex) pelo incentivo, e a minha namorada (Leonella) pela compreensão e motivação.
iii
AGRADECIMENTOS
A Deus pela minha existência e por tudo que tenho; Ao meu pai Alvino, que mesmo do seu jeito calado e preservado, sempre me demonstrou o
apoio e a confiança que eu precisava; A minha mãe Lourdes, que sempre reza e torce por mim. A minha família que sempre me apoiou e me incentivou muito e por ser a minha maior fonte
de referência; A minha namorada Leonella, por me apoiar, motivar e por sempre estar ao meu lado em
horas difíceis dessa etapa da minha vida; Aos meus padrinhos que me acolheram durante este último ano; Aos meus amigos de faculdade e do LSED que me acompanharam todo esse tempo com
muita alegria e prestígio; Ao meu orientador e professor Cesar, pelo conhecimento passado, pelas horas dispostas e
pelo imenso incentivo e confiança; Ao professor Rafael L. Cancian, por me inserir na área de pesquisa em sistemas embarcados
e pelos ensinamentos; Ao meu amigo Zé Pequeno que acompanhou de perto meu trabalho e sempre me ajudou; Ao meu amigo e chefe Ivan, pelas dicas, pela força e horas de trabalho liberadas para
realização desse trabalho.
iv
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................vii
LISTA DE FIGURAS................................................................................ ix
LISTA DE TABELAS................................................................................x
RESUMO....................................................................................................xi ABSTRACT...............................................................................................xii 1 INTRODUÇÃO......................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 2 1.1.1 Formulação do Problema................................................................................. 2 1.1.2 Solução Proposta............................................................................................... 2 1.2 OBJETIVOS ........................................................................................................ 3 1.2.1 Objetivo Geral ................................................................................................... 3 1.2.2 Objetivos Específicos ........................................................................................ 3 1.3 METODOLOGIA................................................................................................ 3 1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA........................................................6 2.1 SISTEMAS EMBARCADOS............................................................................. 6 2.1.1 Características de Sistemas Embarcados ....................................................... 7 2.1.2 Projeto de Sistemas Embarcados .................................................................... 7 2.1.3 Tecnologias de Processadores Embarcados ................................................... 9 2.1.4 Tecnologias de Circuito Integrado (CI) ........................................................ 11 2.1.5 Tecnologias de Projeto.................................................................................... 15 2.1.6 Linguagem de descrição de hardware e VHDL........................................... 17 2.2 ARQUITETURA E ORGANIZAÇÃO DE COMPUTADORES .......... ....... 18 2.2.1 Arquitetura ...................................................................................................... 18 2.2.2 Organização..................................................................................................... 22 2.3 PROCESSADOR BIP II ................................................................................... 25 2.3.1 Arquitetura do BIP II ..................................................................................... 26 2.3.2 Organização do BIP II.................................................................................... 29 2.4 MICROCONTROLADORES.......................................................................... 31 2.4.1 Características de Microcontroladores......................................................... 31 2.5 ARCHC............................................................................................................... 38 2.5.1 Recursos da Arquitetura (AC_ARCH)......................................................... 39 2.5.2 Arquitetura do Conjunto de Instruções (AC_ISA) ..................................... 40
3 DESENVOLVIMENTO ......................................................................45 3.1 ANÁLISE DE REQUISITOS........................................................................... 45 3.2 ESPECIFICAÇÃO DA ARQUITETURA...................................................... 47 3.2.1 Tamanho da Palavra e Tipo de Dados.......................................................... 47
v
3.2.2 Espaços de Endereçamento............................................................................ 47 3.2.3 Registradores................................................................................................... 49 3.2.4 Formatos de Instrução.................................................................................... 50 3.2.5 Modos de Endereçamento .............................................................................. 50 3.2.6 Conjunto de Instruções................................................................................... 51 3.2.7 Resumo da Arquitetura µBIP........................................................................ 53 3.3 ESPECIFICAÇÃO DA ORGANIZAÇÃO ..................................................... 54 3.4 IMPLEMENTAÇÃO DO µBIP NO ARCHC ................................................ 62 3.4.1 Recursos da arquitetura ................................................................................. 62 3.4.2 Arquitetura do conjunto de instruções ......................................................... 62 3.4.3 Testes e Validações.......................................................................................... 68 3.4.4 Limitações ........................................................................................................ 70 3.4.5 Considerações sobre o uso do ArchC como ferramenta de projeto arquitetural ................................................................................................................ 71 3.5 IMPLEMENTAÇÃO DO MODELO VHDL ....................... .......................... 71 3.5.1 Testes e Validação ........................................................................................... 73 3.5.2 Prototipação Física.......................................................................................... 81
4 CONCLUSÕES ....................................................................................83 4.1 TRABALHOS FUTUROS................................................................................ 84
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................85 A DESCRIÇÃO DO PROCESSADOR BIP-II EM ARCHC..............89 A.1 RECURSOS DA ARQUITETURA ................................................................. 89 A.2 CONJUNTO DE INSTRUÇÕES..................................................................... 89 A.3 COMPORTAMENTO DAS INSTRUÇÕES.................................................. 90
B QUESTIONÁRIO ................................................................................94 B.1. CARTA DE APRESENTAÇÃO ...................................................................... 94 B.2. TABULAÇÃO DOS RESULTADOS .............................................................. 98
C CONJUNTO DE INSTRUÇÕES DO µBIP ......................................99 C.1. CLASSE: CONTROLE .................................................................................... 99 C.2. CLASSE: ARMAZENAMENTO .................................................................... 99 C.3. CLASSE: CARGA........................................................................................... 100 C.4. CLASSE: ARITMÉTICA............................................................................... 101 C.5. CLASSE: LÓGICA BOOLEANA................................................................. 103 C.6. CLASSE: DESVIO.......................................................................................... 106 C.7. CLASSE: DESLOCAMENTO LÓGICO ..................................................... 110 C.8. CLASSE: MANIPULAÇÃO DE VETOR .................................................... 111 C.9. CLASSE: SUPORTE A PROCEDIMENTOS ............................................. 112
D INSTALAÇÃO DO ARCHC ............................................................114 D.1. OBTENDO OS ARQUIVOS DE INSTALAÇÃO........................................ 114 D.2. INSTALAR O SYSTEMC.............................................................................. 115
vi
D.3. INSTALAR O ARCHC................................................................................... 116 D.4. GERANDO O MONTADOR ......................................................................... 116 D.5. UTILIZANDO O MONTADOR.................................................................... 117 D.6. GERANDO O SIMULADOR......................................................................... 117 D.7. UTILIZANDO O SIMULADOR ................................................................... 118 D.8. UTILIZANDO O LIGADOR......................................................................... 118
E PLANO DE TESTE UNITÁRIO......................................................119
F TESTBENCH (DALTON-PROJECT) ............................................125 G BLOCOS VHDL.................................................................................135
H REGISTRADORES...........................................................................145
vii
LISTA DE ABREVIATURAS
µBIP microBIP A/D Analógico-Digital ABEL Advanced Boolean Expression Language ABS Anti-Blocking System ACC Acumulador ADL Architecture Description Language AHDL Altera Hardware Description Languages ALU Arithmetic-Logic Unit ASIC Application-Specific Integrated Circuit ASIP Application-Specific Instruction-set Processor BIP Basic Instruction-set Processor CI Circuito Integrado CISC Complex Instruction Set Computers CPU Central Processing Unit DIP Dual-in-line Package DSP Digital Signal Processor E/S Entrada/Saída EEPROM Electrically EPROM EPROM Erasable PROM FPGA Field Programmable Gate Arrays FSM Finite State Machine HDL Hardware Description Languages I2C Inter-Integrated Circuit IC Interrupt Controller IC-UNICAMP Instituto de Computação da Universidade de Campinas INDR Index Register IP Intellectual Property IPR Interrupt Pending Register ISA Instruction Set Architecture LIFO Last In First Out LSED Laboratório de Sistemas Embarcados e Distribuídos MIPS Microprocessor without Interlocked Pipeline Stages MHz Mega Hertz MP3 Moving Picture Experts Group -1/2 Audio Layer 3 NRE Non-Recurring Engineering Cost PC Program Counter PC Personal Computer PDA Personal Digital Assistant PIC Programmable Intelligent Computer PLCC Plastic Leadless Chip Carrier PLD Programmable Logic Device PROM Programmable ROM PWM Pulse Width Modulator RAM Random Access Memory RI Registrador de Instrução RISC Reduced Instruction Set Computer
viii
ROM Read Only Memory RF Requisito Funcional RNF Requisito Não Funcional RT Register-Transfer RX Receptor SFR Special Function Register SMD Surface Mounted Devices SOP Small Outline Package SPI Serial Peripheral Interface TCC Trabalho de Conclusão de Curso TOS Top of Stack TX Transmissor UF Unidade Funcional ULA Unidade Lógica Aritmética UNIVALI Universidade do Vale do Itajaí VHDL VHSIC Hardware Description Language VHSIC Very High-Speed Integrated Circuits VLSI Very Large Scale Integration
ix
LISTA DE FIGURAS
Figura 1. Lançamento do produto x retorno financeiro .......................................................................9 Figura 2. Tecnologias de processadores para a implementação de uma funcionalidade .....................9 Figura 3. Visão abstrata da organização de uma FPGA.....................................................................14 Figura 4. Comparativo entre as Tecnologias de CI............................................................................14 Figura 5. Fonte dos operando nas diferentes classes de conjunto de instruções................................19 Figura 6. Arquitetura de Memória......................................................................................................24 Figura 7. Métricas da hierarquia de memória ....................................................................................25 Figura 8. Organização do Processador BIP II ....................................................................................29 Figura 9. Sistemas de Interligação Digitais. TX (Transmissor) e RX (Receptor) .............................34 Figura 10. Descrição dos Recursos para o processador BIP-II ..........................................................39 Figura 11. Descrição parcial do conjunto de instrução para o processador BIP-II............................42 Figura 12. Descrição parcial do comportamento do conjunto de instrução do processador BIP-II...44 Figura 13. Espaçamento de Memória no µBIP ..................................................................................48 Figura 14. Organização da Memória de E/S ......................................................................................49 Figura 15. Formato de instrução no µBIP..........................................................................................50 Figura 16. Modo de endereçamento Indireto .....................................................................................51 Figura 17. Visão abstrata da organização do µBIP ............................................................................54 Figura 18. Visão detalhada da organização da CPU do µBIP............................................................55 Figura 19. Organização da Unidade Funcional do µBIP...................................................................56 Figura 20. Organização da Pilha ........................................................................................................57 Figura 21. Organização do módulo de manipulação de vetores ........................................................58 Figura 22. Fluxo do Controle de Interrupção.....................................................................................60 Figura 23. Integração da CPU com os periféricos e Memórias. ........................................................61 Figura 24. Implementação do µBIP no ArchC – Recursos da Arquitetura........................................62 Figura 25. Implementação do µBIP no ArchC – ubip_isa.ac ............................................................63 Figura 26. Implementação do µBIP no ArchC – Funções Auxiliares (ubip_isa.cpp)........................65 Figura 27. Implementação do µBIP no ArchC – Comportamento (ubip_isa.cpp).............................66 Figura 28. Implementação do µBIP no ArchC – Arquivo de Simulação (ubip_isa.cpp)...................67 Figura 29. Implementação do µBIP no ArchC – Processo de Simulação..........................................68 Figura 30. Utilização das instruções nos testbenchs..........................................................................70 Figura 31. Visão top-down do µBIP ..................................................................................................72 Figura 32. Hierarquia de arquivos VHDL..........................................................................................73 Figura 33. Diagrama de formas de onda da simulação da execução da aplicação cast.....................74 Figura 34. Diagrama de formas de onda da simulação da execução da aplicação fib .......................75 Figura 35. Diagrama de formas de onda da simulação da execução da aplicação Exemplo 5 Parte-1
....................................................................................................................................................76 Figura 36. Diagrama de formas de onda da simulação da execução da aplicação Exemplo 5 Parte-2
....................................................................................................................................................77 Figura 37. Custo por bloco da aplicação Exemplo 5..........................................................................79 Figura 38. Kit de prototipação Altera® UP-2 ....................................................................................81
x
LISTA DE TABELAS
Tabela 1. Arquitetura do BIP II..........................................................................................................27 Tabela 2. Conjunto de instruções do BIP II .......................................................................................28 Tabela 3. Tabela de decodificação de instrução.................................................................................30 Tabela 4. Características de Microcontroladores comerciais.............................................................37 Tabela 5. Conjunto de instruções do µBIP.........................................................................................52 Tabela 6. Arquitetura do µBIP ...........................................................................................................53 Tabela 7. Código de operação da Unidade Funcional........................................................................56 Tabela 8. Configuração do prescaler no registrador tmr0_config ...............................................59 Tabela 9. Descrição do testbench.......................................................................................................69 Tabela 10. Custo das Aplicações na FPGA FLEX10K-EPF10K70RC240-4...................................78 Tabela 11. Análise de tempo na FPGA FLEX10K-EPF10K70RC240-4 .........................................80 Tabela 12. Configuração de pinagem para prototipação no kit UP-2 ...............................................82 Tabela 13. Tabulação dos Dados Coletados.......................................................................................98
xi
RESUMO
PEREIRA, Maicon C. µBIP: Microcontrolador básico para o ensino de Sistemas Embarcados. Itajaí, 2008. 161f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2008. O ensino de conceitos introdutórios em disciplinas-base para a formação de profissionais aptos ao desenvolvimento de sistemas embarcados requer inicialmente a utilização de arquiteturas simples o suficiente para que o aluno possa relacionar os conceitos de arquitetura e organização de computadores com conceitos de programação. Nesse contexto, uma família de processadores, denominada BIP – Basic Instruction-set Processor, foi desenvolvida por pesquisadores do Laboratório de Sistemas Embarcados e Distribuídos da Universidade do Vale do Itajaí para apoio no ensino em disciplinas de fases iniciais do curso de Ciência da Computação. Duas versões foram especificadas oferecendo suporte à conceitos tratados nessas disciplinas. No entanto, os recursos desses processadores são limitados para sua aplicação em disciplinas mais avançadas como, por exemplo, as que abordem a aplicação de processadores em tarefas de controle. Neste sentido, este Trabalho de Conclusão de Curso (TCC) apresenta o desenvolvimento de um microcontrolador denominado µBIP, que estende as características presentes no projeto BIP, agregando periféricos e funcionalidades típicas de microcontroladores. Este trabalho disponibiliza uma especificação de processador e ferramentas de apoio ao ensino de várias disciplinas como Arquitetura e Organização de Computadores, Sistemas Embarcados, Circuitos Digitais, Compiladores e Programação em cursos de graduação em Ciência da Computação e em Engenharia de Computação. Neste texto, é apresentada uma revisão de conceitos-base associados ao desenvolvimento de sistemas embarcados e de processadores, assim como o projeto e implementação do microcontrolador µBIP e suas ferramentas. Palavras-chave: Sistemas Embarcados. Arquitetura e Organização de Computadores. Microcontroladores.
xii
ABSTRACT
The teaching of introductory concepts in base disciplines for the formation of professionals that are capable of developing embedded systems initially requires the utilization of simple enough architectures so that the student can relate the concepts of computer architecture and organization with programming concepts. In this context, a family of processors, called BIP - Basic Instruction-set Processor, was developed by researchers of Embedded and Distributed Systems Laboratory of University of Vale do Itajaí – UNIVALI for learning support in initial phases of the Computer Science major. Two versions were specified, offering support to concepts that are taught in this major. However, these processors resources are limited for their application in more advanced disciplines like, for example, those which approach the application of processors in control tasks. In this sense, this final work presents the development of a microcontroller named µBIP, which extends the features of BIP architecture, adding peripherals and functionalities typically found in commercial microcontrollers. This work makes possible to apply the processor specification, and related tools, to support the teaching of various disciplines such as Computer Architecture and Organization, Embedded Systems, Digital Circuits, Compilers, and Programming in Computer Science and Computer Engineer courses. In this text, it is presented a study on concepts needed for the development of embedded systems and processors, such as the design and implementation of µBIP microcontroller and its tools. Keywords: Embedded Systems. Computer Architecture and Organization. Microcontrollers.
1 INTRODUÇÃO
Sistemas embarcados estão a cada dia mais presentes no cotidiano das pessoas, executando
atividades de processamento e/ou de controle nos mais diversos tipos de produtos e equipamentos,
como em automóveis, aparelhos televisores, tocadores de MP3 (Moving Picture Experts Group -1/2
Audio Layer 3), câmeras digitais e telefones celulares, entre outros. O aumento da demanda por
produtos baseados em sistemas embarcados tem levado à necessidade de profissionais capazes de
atuar nas diferentes fases do projeto desses sistemas. Porém, os cursos de graduação na área da
Computação não estão atendendo à essa necessidade e precisam suprir uma base maior de conceitos
dirigidos a esse domínio de aplicação que possui restrições e requisitos diferentes de computadores
de uso geral como os PCs (Personal Computer) (HENZINGER; SIFAKIS, 2007).
As disciplinas da área de Arquitetura e Organização de Computadores são fundamentais na
formação de alunos nos cursos de graduação em Ciência da Computação e em Engenharia de
Computação, especialmente para aqueles que seguirão uma linha dirigida ao desenvolvimento de
sistemas embarcados. Entretanto muitos alunos apresentam grandes dificuldades no entendimento
de conceitos apresentados nas primeiras aulas dessas disciplinas. Por esse motivo, professores estão
em constante busca por métodos que auxiliem o aluno a compreender os conceitos de arquitetura e
organização de computadores fazendo uma ligação com os conceitos apresentados em disciplinas
como de programação, compiladores e outras.
Neste sentido, professores utilizam de diversos modelos de processadores para servir de
referência ao estudo da arquitetura e da organização de processadores, os quais vão desde
arquiteturas básicas como o Neander, o Cesar e o Ramses (WEBER, 2004), a arquiteturas mais
complexas como o MIPS (Microprocessor without Interlocked Pipeline Stages) (PATTERSON;
HANESSY, 2000).
Uma iniciativa nesse sentido é o BIP (Basic Instruction-set Processor), um processador cuja
arquitetura foi projetada visando atender aos seguintes objetivos:
• Facilitar o aprendizado de conceitos introdutórios de arquitetura e de organização de
computadores em fases iniciais de cursos de graduação na área de Computação; e
• Facilitar a aplicação do BIP em disciplinas relacionadas a área de Sistemas de
Computação e promover a integração interdisciplinar.
2
O BIP foi desenvolvido por pesquisadores do Laboratório de Sistemas Embarcados e
Distribuídos do Curso de Ciência da Computação da Universidade do Vale do Itajaí – Univali,
sendo que duas versões já foram implementadas. O BIP I (MORANDI et al., 2006) possui um
conjunto de instruções limitado a operações aritméticas básicas (soma e subtração) e de
transferência de dados entre o processador e a memória. O BIP II (MORANDI; RAABE;
ZEFERINO, 2006) estendeu essa arquitetura incluindo instruções de desvio condicional e
incondicional para a implementação de estruturas de controle, como laços de repetição.
O BIP já foi aplicado em diferentes disciplinas dos seguintes cursos de graduação e de pós-
graduação da Univali:
• Curso de Graduação em Ciência da Computação (Itajaí): Computação Básica, Circuitos
Digitais, Arquitetura e Organização de Computadores e Compiladores;
• Curso de Graduação em Engenharia de Computação (São José): Tópicos Especiais em
Engenharia de Computação: Sistemas Embarcados; e
• Curso de Mestrado em Computação Aplicada (São José): Arquitetura de Computadores
e Projeto de Sistemas Digitais.
Sua utilização nesses cursos permitiu confirmar a efetividade da abordagem utilizada, pois
os objetivos desejados foram atingidos.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
A aplicabilidade do BIP em disciplinas mais avançadas, com foco no projeto de
componentes para sistemas embarcados, mostrou-se muito limitada, pois a versão atual da
arquitetura (BIP II) não contempla características de processadores reais, especialmente aqueles
utilizados em sistemas embarcados. Por exemplo, o BIP não possui interface de entrada-e-saída, e
nenhum tipo de periférico comumente encontrado em processadores para tais sistemas.
1.1.2 Solução Proposta
A solução proposta neste projeto consiste em estender a arquitetura do BIP, de modo a
especificar um conjunto de instruções mais completo compatível com o de arquiteturas usadas no
3
ensino de sistemas embarcados, e disponibilizar uma implementação física desse processador com
periféricos básicos utilizados em microcontroladores, como portas de entrada-e-saída, controlador
de interrupções e um temporizador. Por isso, essa nova versão será denominada µBIP (lê-se micro
BIP).
Embora o desenvolvimento deste projeto se justifique na sua futura aplicação no ensino,
considerando as limitações de tempo, o presente trabalho não avaliará o impacto do uso µBIP em
cursos de graduação e/ou de pós-graduação.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é desenvolver um modelo de microcontrolador com
arquitetura simplificada visando sua aplicação no ensino de graduação e de pós-graduação.
1.2.2 Objetivos Específicos
Os objetivos específicos deste projeto são:
• Consolidar conceitos sobre sistemas embarcados;
• Consolidar conceitos de arquitetura e organização de computadores;
• Analisar arquiteturas de microcontroladores para identificar características comuns que
devam ser incluídas no µBIP;
• Compreender as tecnologias a serem utilizadas no desenvolvimento do µBIP;
• Disponibilizar modelos de simulação e de síntese do µBIP;
• Disponibilizar montador e ligador para µBIP;
• Testar e validar a implementação do modelo por simulação e em protótipo físico; e
• Documentar e divulgar o projeto.
1.3 METODOLOGIA
A metodologia adotada nesse Trabalho de Conclusão de Curso (TCC) é dividida em seis
partes:
4
• Estudo: Nessa etapa foram realizados estudos e práticas a fim de adquirir os
conhecimentos necessários para a realização desse trabalho. Para o estudo foram
utilizados livros, manuais e datasheets. Também foram realizadas atividades práticas
com o ArchC com o objetivo de entender melhor o ambiente e seus recursos.
• Modelagem: Nessa etapa foram realizadas as especificações e o projeto da arquitetura e
organização do µBIP, além de uma pesquisa realizada para ajudar a definir os requisitos
do projeto.
• Revisão do projeto: nesta etapa foi realizada a revisão desse trabalho levando em
consideração as questões levantas pelos membros avaliadores da banca.
• Desenvolvimento: Nessa etapa foram realizadas as implementações das especificações
levantadas na etapa de modelagem, sendo:
1. Modelagem da Arquitetura do conjunto de instrução (ISA) no ArchC;
2. Geração do simulador do ISA;
3. Geração do Montador do ISA;
4. Refinamento do projeto da organização do µBIP;
5. Modelagem VHDL do µBIP; e
6. Síntese e prototipação do modelo em FPGA.
• Validação: Nessa etapa foram realizados testes e experimentação nos modelos
desenvolvidos. Ela se sobrepôs à etapa de implementação, durante os testes dos
componentes, e se estendeu até o teste de integração. Algumas das atividades
desenvolvidas nessa etapa foram:
1. Implementação de aplicações de teste para a validação da arquitetura;
2. Validação por simulação;
3. Validação física em Kit de desenvolvimento para FPGA da Altera® (disponível no
LSED);
• Documentação: Nessa etapa foi realizada a documentação de todo o processo existente
no trabalho, desde a descrição do problema, a proposta de uma solução, a
implementação da solução, os testes, validações e os resultados finais. Essa etapa incluiu
5
também a produção e publicação de um artigo científico para divulgação da pesquisa
realizada.
1.4 ESTRUTURA DO TRABALHO
Este documento está dividido em quatro capítulos. O Capítulo 1, Introdução, apresentou
uma visão inicial sobre o tema abordado no trabalho bem como seus objetivos. O Capítulo 2,
Fundamentação Teórica, apresenta o resultado da etapa de estudo, com uma revisão bibliográfica
dos temas envolvidos no trabalho. O Capítulo 3, Desenvolvimento, apresenta o projeto e a
implementação do projeto em questão. O último capítulo apresenta as conclusões sobre o trabalho.
O documento também inclui oito apêndices que complementam o conteúdo deste trabalho.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo é apresentada a revisão bibliográfica sobre os temas envolvidos no projeto. A
Seção 2.1 apresenta uma visão sobre sistemas embarcados, expondo suas características e
tecnologias. Na Seção 2.2 é apresentada uma breve revisão sobre Arquitetura e Organização de
Computadores, já que este tema é discutido durante o curso. A Seção 2.3 apresenta informações
sobre a arquitetura e organização do processador BIP II. Na Seção 2.4 é apresentado um
levantamento das características de microcontroladores. Finalizando este capítulo, a Seção 2.5
apresenta informações sobre o ArchC, uma das tecnologias utilizadas neste projeto.
2.1 Sistemas Embarcados
Vahid e Givargis (2002, p. 1) definem um sistema computacional embarcado, ou apenas
sistema embarcado, como qualquer sistema computacional exceto pelos desktops, laptops ou
mainframes. Já Wolf (2002) define sistema embarcado como “qualquer computador que é um
componente de um sistema maior”.
Sistemas embarcados são construídos há décadas. Porém, os microprocessadores mais
antigos se limitavam a executar a função básica no controle de dispositivos de entrada e saída
(WOLF, 2002).
Sistemas computacionais embarcados estão em toda parte e tendem a aumentar sua presença
ainda mais, devido ao baixo custo tecnológico atual (CARRO; WAGNER, 2003). Vahid e Givargis
(2002, p. 1-2) apresentam uma variedade de dispositivos eletrônicos comuns que possuem sistemas
embarcados:
1. Eletrônicos pessoais: celulares, pagers, câmeras digitais, câmeras de vídeo,
videocassetes, video-games portáteis, calculadoras, e PDAs (Personal Digital Assistant –
Assistente Digital Pessoal);
2. Eletrodomésticos: forno de microondas, secretária eletrônica, termostato, segurança
residencial, máquinas de lavar e sistemas de iluminação;
3. Escritório: fax, copiadoras, impressoras e scanners;
7
4. Equipamentos comerciais: caixa registradora, controle de estacionamento, sistemas de
alarme, leitores de cartão, leitores de código de barras; e
5. Automóveis: controle de transmissão, controle de trajeto, injeção eletrônica, freios ABS
(Anti-Blocking System) e suspensão ativa.
2.1.1 Características de Sistemas Embarcados
Segundo Vahid e Givargis (2002, p. 2-3), sistemas embarcados apresentam algumas
características especificas que os diferem de outros sistemas computacionais:
1. Monofuncional: usualmente, sistemas embarcados são projetados para executar
repetidamente apenas um programa. Entretanto existem algumas exceções como, por
exemplo, telefones celulares que permitem a execução de diversos aplicativos, além da
inclusão de outros;
2. Restrições de Projeto: o projeto de sistemas embarcados, assim como o projeto de
sistemas computacionais, possui uma série de limitações. Porém, no projeto de sistemas
embarcados, essas limitações são maiores. Sistemas embarcados normalmente possuem
baixo custo, tamanho reduzido, desempenho para processamento em tempo-real e baixo
consumo de energia; e
3. Reativos em Tempo-Real: Muitos dos sistemas embarcados devem reagir às mudanças
do ambiente e processar dados em tempo-real sem atraso.
2.1.2 Projeto de Sistemas Embarcados
Projetar um sistema embarcado que cumpra as suas funcionalidades e que otimize
simultaneamente várias métricas de projeto é considerado um desafio (CARRO; WAGNER, 2003;
VAHID; GIVARGIS, 2002). Algumas métricas de projeto são apresentadas por Vahid e Givargis
(2002, p. 5):
1. Custo NRE (Non-Recurring Engineering Cost - custo de engenharia não-recorrente):
custo monetário de projetar o sistema. Segundo Carro e Wagner (2003) o projeto de um
sistema embarcado complexo resulta em um custo alto devido à necessidade de equipes
multidisciplinares (hardware digital, hardware analógico, software, teste), além da
utilização de ferramentas computacionais caras;
8
2. Custo Unitário: custo monetário de produção para cada cópia do sistema, exceto pelo
custo NRE;
3. Tamanho: Espaço físico requerido pelo sistema. Freqüentemente, medido em bytes ou
bits para software e portas ou transistores para hardware;
4. Desempenho: Tempo de execução ou vazão do sistema;
5. Energia: Quantidade de energia consumida pelo sistema;
6. Flexibilidade: refere-se à habilidade de mudanças nas funcionalidades do sistema sem
acarretar em novos custos de NRE;
7. Time-to-market (tempo para mercado): Quantidade de tempo requerido para projetar,
produzir e lançar o sistema no mercado;
8. Tempo de prototipação: Quantidade de tempo para a construção de uma versão de
trabalho do sistema;
9. Corretude ou correção: Garantia de que a funcionalidade do sistema foi implementada
corretamente; e
10. Segurança: refere-se à probabilidade de que o sistema não causará danos; entre outras.
Segundo esses autores, essas métricas competem entre si, e a melhoria em uma delas pode
acarretar em prejuízos a outras métricas.
Carro e Wagner (2003) e Vahid e Givargis (2002, p. 5-6) afirmam que uma otimização da
métrica time-to-market tem sido exigida cada vez mais. Isso implica no projeto de novos sistemas
embarcados com janelas de tempo cada vez menores. Como mostra a Figura 1, o atraso no
lançamento de um produto compromete o seu retorno financeiro esperado. Na figura, a área
sombreada representa os rendimentos perdidos pela entrada em atraso no mercado.
9
Figura 1. Lançamento do produto x retorno financeiro
Fonte: Carro e Wagner (2003).
2.1.3 Tecnologias de Processadores Embarcados
“A tecnologia de processadores envolve a arquitetura do mecanismo computacional usada
para implementar uma funcionalidade desejada do sistema” (VAHID; GIVARGIS, 2002, p. 9).
Figura 2. Tecnologias de processadores para a implementação de uma funcionalidade
Fonte: Adaptado de Vahid e Givargis (2002, p. 10).
10
As subseções a seguir descrevem três tecnologias de processadores: (a) processador de
propósito geral; (b) processador de propósito único; e (c) processador de aplicação específica. A
Figura 2 (a) apresenta a funcionalidade desejada de um sistema que será analisada e comparada com
as diferentes tecnologias de processadores. A funcionalidade consiste em somar os itens de um
vetor e armazenar o total.
2.1.3.1 Processador de Propósito Geral
“O projetista de um processador de propósito geral constrói um dispositivo apropriado para
uma variedade de aplicações, para maximizar o número de dispositivos vendidos” (VAHID;
GIVARGIS, 2002, p. 9).
Processadores de propósito geral, também conhecidos como microprocessadores e CPU
(Central Processing Unit – Unidade Central de Processamento), possuem características comuns
como: (a) presença de uma memória de programa em que é armazenada um programa com
funcionalidade desejada; (b) caminho de dados (datapath) genérico o bastante para manipular uma
variedade de computação; e (c) possuem um banco de registrador grande e uma ou mais ALU
(Arithmetic-Logic Unit - Unidade Lógica Aritmética - ULA) de propósito geral.
Ao utilizar-se desta tecnologia, o projetista se beneficia em algumas métricas de projeto
como: (a) flexibilidade alta, já que alterações nas funcionalidades são realizadas apenas no código
do programa; (b) custo NRE e time-to-market são baixos, pois o projetista deve apenas escrever o
código do programa; (c) custo unitário pode ser relativamente baixo para pequenas quantidades; e
(d) desempenho alto para aplicações de computação-intensiva. Em contrapartida, há desvantagens,
como: (i) custo unitário pode ser alto em grande escala; e (ii) tamanho grande e consumo de energia
é alto (VAHID; GIVARGIS, 2002, p.10)
Considerando a representação apresentada previamente na Figura 2, um microprocessador
possui mais recursos do que o necessário para realizar a funcionalidade desejada (Figura 2 (b)).
Logo, um microprocessador pode executar a função, mas não necessariamente de forma eficiente.
2.1.3.2 Processador de Propósito Único
“Um processador de propósito único é um circuito digital projetado para executar
exatamente um programa” (VAHID; GIVARGIS, 2002, p. 10). A funcionalidade nesse tipo de
11
processador é implementada diretamente no hardware, e é também conhecido como processador
dedicado, co-processador ou acelerador.
Em processadores dedicados alcançam-se benefícios em métricas de projetos como tamanho
reduzido, baixo consumo de energia, custo unitário baixo para grandes quantidades e alto
desempenho na grande maioria dos projetos. Por outro lado, o custo NRE e o tempo de projeto são
altos, a flexibilidade é baixa e o custo unitário é alto para poucas quantidades.
Dada a funcionalidade apresentada na Figura 2 (a), o uso de processadores dedicados nesta
funcionalidade representa exatamente a funcionalidade desejada (Figura 2 (d)).
2.1.3.3 Processador de Aplicação Específica
Segundo Vahid e Givargis (2002, p. 12), um processador de aplicação específica (ASIP -
Application-Specific Instruction-set Processor) é um meio termo entre os dois processadores
anteriores. O projeto de um ASIP segue uma classe de aplicações com características comuns, tais
como DSPs (Digital Signal Processor, Processador de Sinal Digital), em telecomunicações e outros.
No projeto de um ASIP, o projetista acrescenta algumas unidades funcionais para operações
comuns e elimina outras unidades que normalmente não são utilizadas.
As vantagens desta tecnologia referente às métricas de projeto são a flexibilidade e o
desempenho satisfatório, além do tamanho reduzido e do baixo consumo de energia. A
desvantagem é o alto custo NRE para construir o próprio processador e o compilador, se estes não
existirem.
Dada a funcionalidade apresentada na Figura 2 (a), o uso de processadores de aplicação
específica (Figura 2 (c)) se aproxima mais da funcionalidade desejada do que o de propósito geral.
2.1.4 Tecnologias de Circuito Integrado (CI)
Segundo Vahid e Givargis (2002, p. 13), Circuito Integrado, também conhecido como
“chip” ou simplesmente CI, é um dispositivo semicondutor composto por vários transistores
conectados e outros componentes que realizam uma função. O autor afirma que “Todo o
processador deve ser implementado em um circuito integrado”. A implementação de um
processador é independente da tecnologia de CI. Logo, qualquer tecnologia de processador pode ser
mapeada em qualquer tipo de tecnologia de CI.
12
Segundo Vahid e Givargis (2002, p. 13), para compreender as diferenças entre as diversas
tecnologias de CIs, é necessário primeiramente reconhecer as camadas que compõe um CI, sendo:
(i) camadas inferiores, compostas de transistores; (ii) camadas centrais, compostas de portas
lógicas; e (iii) camadas superiores, que conectam as portas lógicas com os contatos. Reconhecer as
camadas se faz necessário, pois a diferença entre as tecnologias está na forma como estas camadas
são disponibilizadas pelo fabricante.
2.1.4.1 Full-Custom/VLSI
Na tecnologia Full-Custom, também referenciada por VLSI (Very Large Scale Integration,
Integração em Larga Escala), todas as camadas devem ser otimizadas para a aplicação específica
com a construção das máscaras necessárias para a fabricação do dispositivo real. Algumas das
otimizações possíveis incluem o posicionamento e dimensionamento dos transistores, assim como o
roteamento dos fios (VAHID; GIVARGIS, 2002, p. 13). Segundo Güntzel (2002, p.78), o termo
Full-Custom está para “Sob-medida”, ou seja, todos os elementos são definidos.
A utilização da tecnologia Full-Custom resulta em vantagens como (a) desempenho
excelente; (b) tamanho reduzido e (c) baixo consumo. Porém resulta em desvantagens como: (a)
alto custo NRE; e (b) longo time-to-market. (GÜNTZEL, 2002, p. 78; VAHID; GIVARGIS, 2002,
p. 13).
Güntzel (2002, p.78) apresenta como exemplo de CIs baseados na tecnologia Full-Custom
microprocessadores, microcontroladores comerciais, circuitos para equipamentos portáteis como
celulares e circuitos para aviões e satélites. Segundo Vahid e Givargis (2002, p.13), a tecnologia
Full-Custom é normalmente aplicada em situações de grande volume e/ou onde o desempenho é
crítico.
2.1.4.2 Semi-Custom/ASIC
Segundo Güntzel (2002, p.78) e Vahid e Givargis (2002, p.13), na tecnologia Semi-Custom,
tipicamente referenciada por ASIC (Application-Specific Integrated Circuit – Circuito Integrado de
Aplicação Específica), as camadas inferiores são completamente ou parcialmente construídas
13
previamente, e o projetista deve apenas posicionar alguns blocos e realizar o roteamento das
interconexões. Exemplos de tecnologia ASIC incluem os Gate Arrays1 e as Standard Cells2.
Esta tecnologia possui a vantagem de ter um custo NRE menor que na tecnologia Full-
Custom e ainda apresentar boas métricas de desempenho e tamanho (GÜNTZEL, 2002, p. 78;
VAHID; GIVARGIS, 2002, p. 14).
2.1.4.3 Lógica programável/PLD
Segundo Brown e Vranesic (2000, p. 81), PLD (Programmable Logic Device, Dispositivo
de Lógica Programável) é um chip de propósito geral que possui um conjunto de circuitos lógicos
que permite o usuário personalizar o hardware.
Com respeito às camadas de circuito, de acordo com Vahid e Givargis (2002, p. 14) na
tecnologia PLD, todas as camadas já estão construídas, bastando apenas configurar as conexões
entre as portas lógicas para implementar a funcionalidade desejada. Segundo Güntzel (2002, p.80),
PLD são exemplos de componentes personalizáveis após o encapsulamento.
Existem vários tipos de PLDs, os mais populares são os FPGAs (Field Programmable Gate
Arrays), que oferecem mais conectividade entre os blocos lógicos, além de permitirem a
implementação de projetos mais complexos. (BROWN; VRANESIC, 2000, p. 92; MENDONÇA;
ZELENOVSKY, 2004, p. 265-266; VAHID; GIVARGIS, 2002, p. 14).
A Figura 3 apresenta uma visão abstrata da organização de uma FPGA que conforme Brown
e Vranesic possuem três elementos básicos: (i) blocos lógicos que possuem os circuitos lógicos; (ii)
blocos de E/S; e (iii) barramento de interconexão e seletores.
Segundo Vahid e Givargis (2002, p. 14) esta tecnologia tem um custo NRE muito baixo,
porém tem um tamanho grande, desempenho inferior a ASICs e VLSIs, alto consumo de energia,
além de custo unitário maior em relação aos anteriores.
1 Todas portas lógicas do CI já foram definidos com o seu posicionamento sobre um CI já conhecidos, deixando para o projetista com a tarefa de ligar as portas da maneira desejada. (VAHID; GIVARGIS, 2002, p. 276). 2 Arranjo de blocos lógicos padronizados disponibilizados em forma de bibliotecas de células lógicas (MELO; RIOS; GUTIERREZ, 2001, p. 11).
14
A Figura 4 compara as tecnologias de CI por métricas projeto como (a) densidade lógica,
quantidade de lógica que pode ser colocada em um circuito, (b) desempenho, (c) custo unitário e (d)
tempo de prototipação. Na figura, cada seta aponta na direção do aumento da métrica.
Figura 4. Comparativo entre as Tecnologias de CI.
Fonte: Adaptado de Güntzel (2002, p.81)
Figura 3. Visão abstrata da organização de uma FPGA
Fonte: Adaptado de Brown e Vranesic (2000, p. 93)
Desempenho
Custo Unitário
Tempo de Prototipação
Densidade Lógica
Full -Custom Semi -Custom PLD
15
2.1.5 Tecnologias de Projeto
Conforme Vahid e Givargis (2002, p. 16), “a tecnologia de projeto envolve a maneira na
qual nós convertemos nosso conceito de uma funcionalidade desejada em uma implementação”.
Devem-se otimizar as métricas de projeto, principalmente reduzindo o tempo para sua realização.
Os autores explicam que uma forma de melhorar o processo de projeto está em entender
como ele funciona e uma maneira para este objetivo é através da técnica de projeto top-down, no
qual o sistema é visto em diversos níveis de abstração. Em um nível mais superior, nível de sistema,
o projetista descreve a funcionalidade em uma linguagem, preferencialmente em uma linguagem
executável. Este processo é chamado de “especificação do sistema”. Após esse processo, o
projetista distribui partes desta especificação entre os processadores escolhidos (de propósito geral
ou único), resultando em uma “especificação de comportamento” para cada processador. O
projetista então refina estas especificações em “especificações no nível RT” (Register-Transfer -
transferência entre registradores), realizando a conversão do comportamento do processador de
propósito geral em código assembly e o comportamento do processador de propósito único em
conexões de componentes RT3 e máquinas de estado. O projetista então refina as especificações RT
em “especificações lógicas”, compostas de equações booleanas. Por fim, são refinadas as
especificações restantes, resultando em código de máquina para processadores de propósito geral e
em uma “rede de ligações” (netlist) para o processador de propósito único.
Dentre os diversos modos de se otimizar o processo de projeto, destacam-se três: (a)
compilação/síntese, (b) biblioteca/IP (Intellectual Property – Propriedade Intelectual) e (c)
teste/verificação.
2.1.5.1 Compilação / Síntese
Segundo Vahid e Givargis (2002, p. 17), a etapa de compilação/síntese permite ao projetista
especificar a funcionalidade em uma forma mais abstrata, gerando os detalhes automaticamente, e
pode ser aplicada aos diversos níveis de abstração. Alguns exemplos de síntese incluem: (a) síntese
de sistema, que converte uma especificação do sistema em um programa seqüencial; (b) síntese
comportamental, que transforma um programa seqüencial em máquinas de estados e operações de
transferência entre registradores; (c) síntese RT, que transforma máquinas de estados e
3 Mutiplexadores, registradores, unidades funcionais e outros.
16
transferências entre registradores em controlador implementado por equações booleanas e um
caminho de dados com componentes RT; e (d) síntese lógica, que converte expressões booleanas
em interconexões de um conjunto de portas lógicas primitivas (REIS, 2002, p. 119; VAHID;
GIVARGIS, 2002, p. 17).
2.1.5.2 Bibliotecas / IP
Segundo Vahid e Givargis (2002, p.18), o uso de bibliotecas permite a re-usabilidade de
implementações existentes, assim, melhorando a produtividade. Conforme apresentado pelos
autores, bibliotecas ou IPs podem ser aplicados aos diversos níveis de abstração com os seguintes
objetivos: (a) nível de sistema: disponibilizar sistemas completos para solução de problemas
particulares ou apenas parte do sistema; (b) nível comportamental: disponibilizar componentes
como multiplexadores, registradores e até processadores; (c) nível RT: disponibilizar layouts de
componentes RTs; e (a) nível lógico: disponibilizar layouts de blocos lógicos.
Houve uma mudança muito importante no conceito de bibliotecas. Ao invés disponibilizar
componentes apenas na forma de CIs, passou-se disponibilizá-los também em forma do que é
chamado de core ou IP. Segundo Gupta e Zorian (1997, p. 2), os cores podem ser disponibilizados
nas seguintes formas:
• Soft: consiste em uma descrição HDL(Hardware Description Languages);
• Hard: consiste em layouts de blocos lógicos; e
• Firm: consiste em um netlist de portas lógicas.
Segundo Vahid e Givargis (2001), o projetista integra vários cores para construir um
sistema. Os autores ressaltam que encontrar um core com a funcionalidade desejada pode ser
considerada uma tarefa difícil.
2.1.5.3 Teste e Verificação
Teste e verificação são processos que visam assegurar que: (a) a implementação de uma
funcionalidade esteja correta; (b) determinadas situações simultâneas nunca ocorram; e (c) o
sistema não ficará em algum laço infinito (VAHID; GIVARGIS, 2002, p. 18). Durante o
desenvolvimento esses processos são feitos utilizando-se simuladores nos diversos níveis de
17
abstração. Após a implementação, são aplicados tanto nos protótipos, quanto nos produtos
fabricados.
2.1.6 Linguagem de descrição de hardware e VHDL
Uma linguagem de descrição de hardware (HDL – Hardware Description Languages)
permite o projeto de circuitos lógicos digitais através de uma linguagem semelhante às linguagens
de programação de alto nível. Com a HDL, é possível descrever detalhes do sistema lógico, como
funções individuais, propriedade dos sinais e a conexão entre os blocos (UYEMURA, 2002, p.
127). Segundo Mendonça e Zelenovsky (2004, p. 469), existem diversas linguagens com este
propósito, entre elas: (a) Verilog; (b) AHDL (Altera HDL); (c) ABEL (Advanced Boolean
Expression Language); e (d) VHDL (VHSIC4 HDL).
Dentre as linguagens de descrição de hardware mencionadas, em universidades brasileiras, a
mais popular é a VHDL. Para Mendonça e Zelenovsky (2004, p. 470) o uso de VHDL em projetos
apresenta as seguintes vantagens:
1. Portabilidade: Ferramentas de desenvolvimento para FPGA e a confecção de VLSI
utilizam VHDL;
2. Flexibilidade: Alterações no projeto podem ser facilmente realizadas com alterações no
código fonte; e
3. Interface de alto nível com a eletrônica: O uso da linguagem VHDL abstrai informações
do nível de eletrônica, pois a linguagem VHDL não está em contato direto com
elementos da eletrônica digital, como flip-flops e contadores.
Segundo D’Amore (2005, p. 1) e Mendonça e Zelenovsky (2004, p. 469), a linguagem
VHDL é resultado de um projeto patrocinado pelo Departamento de Defesa dos Estados Unidos da
América com empresas como IBM, Texas Instruments e Intermetrics. Conforme D’Amore (2005, p.
1), a linguagem foi concebida com a finalidade de documentar padrões de projeto. Por isso, algumas
instruções presentes na linguagem não são sintetizáveis em hardware, porém essas instruções são
utilizadas para a simulação de projetos.
4 Abreviação dada pelo Departamento de Defesa dos Estados Unidos para um projeto chamado Very High-Speed Integrated Circuits.
18
2.2 Arquitetura e Organização de Computadores
O desenvolvimento e o estudo do processador envolvem conceitos da arquitetura e da
organização do mesmo. O estudo da arquitetura do computador refere-se principalmente à parte do
computador visível ao programador como: (a) o conjunto de instruções; (b) os modos de
endereçamento; (c) a memória de programa e dados; (d) os registradores; (e) as portas de
entrada/saída; e (f) as interrupções. Já o estudo da organização, também conhecida como
microarquitetura de processadores (CARTER, 2003, p. 87-89), trata de aspectos não visíveis ao
programador, ou seja, trata de como o processador é implementado, abordando blocos básicos como
(i) caminho de dados e (ii) unidade de controle. Nesse contexto, o objetivo desta seção é apresentar
os conceitos básicos e necessários sobre arquitetura e organização de computadores para o presente
projeto.
2.2.1 Arquitetura
2.2.1.1 Conjunto de Instruções
Para o processador uma instrução é um arranjo de bits que indica uma seqüência de micro-
operações que deverá ser executada. As instruções podem ser classificadas de acordo com o seu
propósito e formato como (a) instruções de transferência de dados5 (também denominadas de carga
e de armazenamento); (b) instruções lógicas6 e aritméticas7; (c) instruções de teste (ou de
comparação); e instruções de desvio (condicional ou incondicional). As denominações dessas
classes variam de autor para autor. O conjunto de todas as instruções reconhecidas por um
computador é chamado de conjunto de instruções (WEBER, 2004, p. 35-36)
Em linguagem de montagem, a instrução é representada por um identificador (o código da
operação ou opcode) e normalmente seguido por um ou mais operandos. Na instrução, o operando
pode ser um valor, um endereço de um registrador ou um endereço para uma posição na memória
de programa (utilizado nas instruções de desvio). Essas variações de posição e quantidade de
operandos são denominadas de modos de endereçamento, ou seja, que podem ser definidos como
um conjunto de sintaxe que especificam constantes, registradores e posições de memória
(CARTER, 2003, p. 82; HENNESSY; PATTERSON, 2003, p. 72; WEBER, 2004, p. 35-36). 5 Instruções para copiar dados entre memória, entre registradores e entre registradores e memórias. 6 Instruções de lógica E, OU e outras, além de instruções de deslocamento de bits 7 Instruções de soma e de subtração.
19
Segundo Hennessy e Patterson (2003, p. 67-68), a forma do armazenamento interno do
processador influencia no conjunto de instruções, já que os operandos das instruções variam de
acordo com o tipo de armazenamento. Assim, têm-se os seguintes tipos de arquitetura:
• Arquitetura de pilha: Armazenamento baseado em pilha. Os operandos estão
implicitamente no topo da pilha. Conforme a Figura 5 (a), a arquitetura possui um
registrador TOS (Top of Stack) que armazena o topo da pilha. Os dois operandos são
retirados do topo da pilha, processados e o resultado armazenado no topo da pilha;
• Arquitetura de acumulador: Armazenamento baseado em um registrador chamado de
acumulador. Um dos operandos de uma instrução é implicitamente o acumulador.
Conforme a Figura 5 (b), após o cálculo na ULA, o resultado é armazenado no
acumulador e assim o acumulador é um operando de entrada e de resultado; e
• Arquitetura de registradores de uso real: Armazenamento baseado em banco de
registradores. Os operandos são explícitos como registradores ou posições de memória.
Duas alternativas são ilustradas na Figura 5: (i) um dos operandos fonte da ULA pode
ser uma variável armazenada na memória – Figura 5 (c); e (ii) apenas registradores
podem servir de operandos fonte para a ULA, sendo que as variáveis são carregadas e
atualizadas por meio de instruções de transferência (load-store) – Figura 5 (d).
Figura 5. Fonte dos operando nas diferentes classes de conjunto de instruções.
Fonte: Adaptado de Hennessy e Patterson (2003, p. 68)
20
Na Figura 5, as setas indicam se um operando é uma entrada e/ou saída da ULA. Os
sombreados claros representam entradas, e os escuros resultados.
A forma mais comum de se classificar os computadores em relação ao conjunto de
instruções é quanto à quantidade e tipo de instrução suportada. Duas classes são utilizadas:
máquinas CISC (Complex Instruction Set Computers) e máquinas RISC (Reduced Instruction Set
Computer) (ver Seção 2.2.1.2).
Segundo Carter (2003, p.81), a arquitetura do conjunto de instruções segue perdendo
significância dentro do projeto de processadores por dois motivos: (i) a programação é normalmente
realizada em uma linguagem de alto nível e toda a codificação para a linguagem de máquina é
realizada por compiladores; e (ii) os consumidores esperam compatibilidade entre as versões de um
mesmo processador. Logo, o lançamento de um novo processador deverá conter, no mínimo, as
mesmas instruções da versão anterior. Já para Stallings (2002, p. 347), o projeto do conjunto de
instruções é um ponto fundamental e mais analisado dentro do projeto de computadores, pois este
determina vários aspectos sobre sua organização.
2.2.1.2 CISC e RISC
Durante a década de 70, uma tendência impulsionada pelo avanço da tecnologia de hardware
foi a aproximação da linguagem de máquina a uma linguagem alto nível com o incremento de
instruções, modos de endereçamento, registradores e outros visando o aumento do desempenho, já
que o número de instruções de máquina necessário para implementar um programa seria menor.
Essa tendência resultou em máquinas denominadas máquinas CISC, as quais continham um
conjunto de instruções bastante diversificado. Porém com a evolução dos compiladores, começou a
ser questionado o desempenho das máquinas CISC, o que levou ao desenvolvimento das máquinas
com um conjunto de instruções reduzido, RISC. (CARTER, 2003, p. 81; STALLINGS, 2002, p.
519-520; UYEMURA, 2002, p. 383).
Patterson e Hennessy (2000) apresentam o resultado de um teste com um conjunto de
aplicações em processador CISC Intel® 80x86 na qual resultou em que 10 instruções simples8
(freqüentemente encontradas em arquiteturas RISC) eram responsáveis por 96% das instruções
8 load, conditional branch, compare, store, add, and, sub, move register-register, call, return
21
executadas, reforçando a idéia da máquina RISC, ou seja, máquina com hardware mínimo para
implementar as instruções mais freqüentes com desempenho esperado.
Apesar da controvérsia em determinar qual das duas opções era a melhor, houve uma
convergência entre as duas máquinas da seguinte forma: (i) máquinas RISC agregaram algumas
instruções complexas das máquinas CISC; e (ii) máquinas CISC excluíram do seu conjunto
instruções complexas que não eram utilizadas com freqüência (CARTER, 2003, p. 81;
STALLINGS, 2002, p. 520).
Segundo Carter (2003, p.81-82), uma diferença clara entre as duas é que máquinas RISC são
arquiteturas de load-store – Figura 5 (c), já em máquinas CISC, instruções como, por exemplo,
aritméticas, podem ler ou gravar seu resultado diretamente na memória – Figura 5 (d).
2.2.1.3 Registradores
Em um processador existem diversos registradores, sendo que vários destes devem ser de
conhecimento do programador, denominados de registradores especiais. Weber (2004, p. 34-35)
relaciona alguns dos registradores especiais comumente encontrados em arquiteturas de
computadores como:
• Apontador de Instrução: normalmente referenciado como PC (Program Counter), este
registrador contém o endereço da próxima instrução a ser executada;
• Registrador de Instrução (RI): armazena a instrução que está sendo executada; e
• Registrador de Estado (STATUS): armazena informações sobre os resultados da ULA.
2.2.1.4 Portas de Entrada/Saída
As portas de Entrada/Saída (E/S) são os meios físicos que permitem o processador se
comunicar com o mundo externo, seja para trocar informações com o usuário do sistema, seja para
acessar outros dispositivos. Uma classe de dispositivos normalmente associados a portas de
entrada/saída são dispositivos de armazenamento (por exemplo, memórias e disco rígido). Embora
muitas vezes ignorada, a entrada/saída influencia o desempenho do sistema (CARTER, 2003, p.
201-202; PATTERSON; HENNESSY, 2000, p. 375; WEBER, 2004, p. 249-254).
22
2.2.1.5 Interrupções
Interrupção é o mecanismo oferecido pelo processador para: (a) permitir que dispositivos
externos interrompam o programa atual do processador para atender sua necessidade; (b) evitar que
o processador tenha que pesquisar todos os dispositivos verificando se algum necessita de
atendimento, este procedimento é conhecido como polling; e (c) permitir que o processador execute
operações de outro programa enquanto o programa atual aguarda por uma resposta de um
dispositivo assíncrono, e volte a processar o mesmo programa quando o dispositivo ativa a
interrupção informando que já concluiu a tarefa. (CARTER, 2003, p. 204-206; MENDONÇA;
ZELENOVSKY, 2004, p. 449-451; WEBER, 2004, p. 253).
2.2.2 Organização
2.2.2.1 Caminho de Dados
O caminho de dados é formado pela unidade de execução e pelo banco de registradores, ou
seja, o hardware necessário para a execução de uma instrução.
A unidade de execução é composta por uma ou mais ULAs, registradores de uso geral e
específico (ver Subseção 2.2.1.3), além de um barramento interligando esses componentes. A
execução de uma instrução na unidade de execução segue um ciclo chamado de ciclo de instrução,
que é normalmente composto por uma variação das seguintes etapas (CARTER, 2003, p. 87-88;
PATTERSON; HENNESSY, 2000, p. 200-204; WEBER, 2004, p. 36):
• Busca de Instrução: O registrador de instrução (RI) recebe a instrução da memória de
instrução apontada pelo registrador PC. O registrador PC é atualizado para o endereço da
próxima instrução;
• Decodificação da Instrução: Nesta etapa, a instrução armazenada no registrador RI é
decodificada pela unidade de controle a fim de definir quais operações serão realizadas
nas etapas posteriores;
• Leitura dos Registradores: Os operandos envolvidos na instrução, identificados na etapa
anterior, são carregados do banco de registradores;
• Execução: Nesta etapa, é realizado o cálculo na ULA de acordo com a operação
identificada na etapa de decodificação; e
23
• Escrita: O resultado da operação da ULA é armazenado no banco de registradores.
Segundo Patterson e Hennessy (2000, p. 200), banco de registradores é conjunto de
registradores com propriedade de leitura e escrita. O acesso a registradores é mais rápido que em
memórias, além de permitir acesso simultâneo aos registradores. Os processadores que possuem
instruções de ponto flutuante normalmente implementam um banco de registrador para tratar esse
tipo de dado e outro para dados tipo inteiro. O mesmo acontece com a ULA. (CARTER, 2003, p.
87-88; WEBER, 2004, p. 36).
2.2.2.2 Unidade de Controle
A unidade de controle é responsável por gerenciar o caminho de dados, memórias e
dispositivos de E/S de acordo com a instrução armazenada no registrador de instrução (IR). Para tal,
existem vários sinais de controles ligando os componentes do processador a um componente com a
lógica de controle. Cada sinal de controle gerencia uma microoperação como, por exemplo, seleção
de uma operação da ULA e ativação da memória (MENDONÇA; ZELENOVSKY, 2004, p. 412;
WEBER, 2004, p. 33-34). Shiva (2000) considera a unidade de controle o bloco mais complexo do
hardware do processador no ponto de vista do projetista, pois este bloco deve gerar sinais de
controle para todos os outros blocos determinando a ação de cada bloco conforme a instrução atual.
Segundo Weber (2004, p. 34), as unidades de controle são máquinas de estados finitos
(Finite State Machine - FSM) obtidas por lógica seqüencial9 e podem ser implementadas de várias
formas. Usualmente as implementações se caracterizam como: (i) Organização convencional, onde
a unidade de controle é composta de diversos componentes digitais que geram os sinais de controles
seqüencialmente e no tempo adequado para cada bloco; e (ii) Organização microprogramada, na
qual os sinais de controles são armazenados em uma pequena memória reservada para este fim,
chamada memória de controle.
2.2.2.3 Memórias
O sistema de memória serve como um local para armazenamento de dados e programa. A
memória é dividida em “palavras”, na qual cada uma é identificada por um endereço. Existem dois
tipos básicos de memória: (i) ROM (Read Only Memory – Memória Apenas de Leitura), que
9 A saída é resultado dos sinais de entrada e do valor armazenado internamente.
24
permite acesso apenas para leitura dos dados e nos computadores em geral é utilizada para
armazenar o programa de inicialização; e (ii) RAM (Random Access Memory – Memória de
Acesso Aleatório), que permite tanto a escrita quanto a leitura de dados e é utilizada para armazenar
programas, sistemas operacionais e dados (CARTER, 2003, p. 50-51; WEBER, 2004, p. 31-32).
Os computadores também se diferenciam quanto à organização da memória de dados e da
memória de instruções, podendo estas estarem juntas em um mesmo espaço de endereçamento ou
separadas. Quando a memória de dados utiliza um espaço diferente da memória de instrução é
referenciado como arquitetura de Harvard (Figura 6 (a)). Quando as memórias utilizam o mesmo
espaço de memória é referenciado como arquitetura de Princeton (ou de von Neumann) conforme
Figura 6 (b). A arquitetura de Princeton pode resultar em hardware mais simples, porém a
arquitetura de Harvard pode resultar em um desempenho melhor, já que pode haver acesso
simultâneo nas duas memórias. (PREDKO, 1998, p. 8)
Processador
Memória
Programa
Memória
Dados
Processador
Memória
(Dados e Programa)
(a) Arquitetura Harvard (b) Arquitetura Princeton
Figura 6. Arquitetura de Memória
Fonte: Adaptado de Vahid e Givargis (2002)
Outro aspecto importante no sistema de memória refere-se à hierarquia de memória. Existem
vários níveis de hierarquia de memória composta principalmente de memória cache, memória
principal e memória secundária. Como mostra a Figura 7, quanto mais próxima do processador, a
memória possui (a) um melhor desempenho; (b) menor tamanho; e (c) maior custo (HENNESSY;
PATTERSON, 2003, p. 284; PATTERSON; HENNESSY, 2000, p. 318-319).
25
Figura 7. Métricas da hierarquia de memória
Fonte: Adaptado de Hennessy e Patterson (2003, p. 284); Patterson e Hennessy (2000, p. 319)
2.3 Processador BIP II
A família de processadores BIP (Basic Instruction-set Processor) foi desenvolvida por
pesquisadores do Laboratório de Sistemas Embarcados e Distribuídos – LSED do Curso de Ciência
da Computação da Universidade do Vale do Itajaí – UNIVALI com o objetivo de estabelecer uma
arquitetura de processador simplificada com recursos incrementais que favoreça o ensino de
Arquitetura e Organização de Computadores para alunos de séries iniciais do curso de Computação,
no intuito de relacionar os conteúdos de programação com as suas representações em hardware
como: (a) declaração de variável e alocação de memória; (b) constantes e operandos imediatos; (c)
atribuição de variáveis e operações de acesso a memória; e (d) operações aritméticas e a execução
no hardware. (MORANDI et al., 2006).
Conforme Morandi et al (2006), no desenvolvimento do BIP, foram estabelecidas três
diretrizes de projeto:
• A arquitetura deveria ser simples o suficiente para facilitar o entendimento de seu
funcionamento e a sua implementação em disciplinas de circuitos digitais;
• A arquitetura deveria ser extensível; e
• Todas as ferramentas de apoio desenvolvidas deveriam priorizar o uso de estrutura de
linguagens compreendida por alunos de séries iniciais.
Baseado nestas diretrizes foram definidos dois modelos iniciais de processador
(MORANDI; RAABE; ZEFERINO, 2006):
26
• BIP I: com foco no suporte ao entendimento de conceitos como níveis de linguagem,
constantes, variáveis, representação de dados e de instruções, conjuntos de instruções,
programação em linguagem de montagem e geração de código na linguagem da
máquina; e
• BIP II: uma extensão do BIP I, com foco na inclusão de suporte aos conceitos de
estruturas de controle para desvios (condicionais e incondicionais) e laços de repetição.
Como o BIP II é uma extensão do BIP I, as subseções a seguir apresentam características da
versão mais completa.
2.3.1 Arquitetura do BIP II
Segundo Morandi et al (2006), o BIP II possui uma arquitetura RISC baseada nos
microcontroladores PIC® (Programmable Intelligent Computer) da Microchip®. Ela é uma
arquitetura baseada em acumulador, semelhante àquela apresentada previamente na Figura 5 (b), em
que todas as operações envolvem o acumulador e algumas operações utilizam operandos da
memória. Segundo os autores, essa duas especialidades do BIP II descaracterizam-no como uma
máquina RISC pura. Porém, outras características RISC prevalecem como a regularidade das
instruções, o número reduzido de instruções, modos de endereçamento e formatos de instrução.
Conforme mostra a Tabela 1, o formato de instrução está divido em dois campos: 5 bits para
o código da operação, o que permite a implementação de até 32 instruções; e 11 bits para o
operando, o que permite representar endereços em uma faixa de até 2048 posições, ou constantes
com sinal em uma faixa de valores de -1024 a 1023. Uma das mudanças realizadas na extensão do
BIP I para o BIP II foi a inclusão da classe de instruções de desvio visando a implementação de
desvios condicionais, incondicionais e laços de repetição.
27
Tabela 1. Arquitetura do BIP II
Tamanho da palavra de dados 16 bits Tipos de dados Inteiro de 16 bits com sinal –32768 a +32767 Tamanho da palavra de instrução 16 bits
Formato de instrução 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Cód. Operação Operando Modos de endereçamento Direto: o operando é um endereço da memória
Imediato: o operando é uma constante Registradores ACC: acumulador
PC: contador de programa STATUS: registrador de Status IR: registrador de instruções (depende da implementação)
Classes de instrução Armazenamento: STO Carga: LD e LDI Aritmética: ADD, ADDI, SUB e SUBI Controle: HLT Desvio: BEQ, BNE, BGT, BGE, BLT, BLE e JMP
Fonte: Adaptado de Morandi, Raabe e Zeferino (2006)
Com relação aos registradores, o BIP II possui de três a quatro: PC, ACC, STATUS e IR. O
registrador STATUS possui dois flags: (i) Z, que indica se o resultado da última operação da ULA
foi igual a zero ou não; e (ii) N, que indica se o último resultado da ULA foi um número negativo
ou não (MORANDI et al, 2006). Dependendo da implementação do processador, ele pode incluir
ou não um registrador para armazenar a instrução em execução (IR – Instruction Register). Na sua
implementação mais simples (organização monociclo), esse registrador não é utilizado.
A Tabela 2 apresenta o conjunto de instruções do processador BIP II. Na tabela, é possível
observar as alterações nos registradores ACC (terceira coluna) e PC (quarta coluna) em cada
instrução. Na tabela, o termo Memory[operand] representa uma variável alocada em memória
na posição operand .
28
Tabela 2. Conjunto de instruções do BIP II
Opcode Instrução Operação e atualização do PC 00000 HLT Desabilita atualização do PC PC ← PC 00001 STO operand Memory[operand] ← ACC PC ← PC + 1
00010 LD operand ACC ← Memory[operand] PC ← PC + 1
00011 LDI operand ACC ← operand PC ← PC + 1
00100 ADD operand ACC ← ACC + Memory[operand] PC ← PC + 1
00101 ADDI operand ACC ← ACC + operand PC ← PC + 1
00110 SUB operand ACC ← ACC – Memory[operand] PC ← PC + 1
00111 SUBI operand ACC ← ACC – operand PC ← PC + 1
01000 BEQ operand
Se (STATUS.Z=1) então PC ← endereço Senão PC ← PC + 1
01001 BNE operand
Se (STATUS.Z=0) então PC ← endereço Senão PC ← PC + 1
01010 BGT operand
Se (STATUS.Z=0) e (STATUS.N=0) então PC ← endereço Senão PC ← PC + 1
01011 BGE operand
Se (STATUS.N=0) então PC ← endereço Senão PC ← PC + 1
01100 BLT operand
Se (STATUS.N=1) então PC ← endereço Senão PC ← PC + 1
01101 BLE operand
Se (STATUS.Z=1) ou (STATUS.N=1) então PC ← endereço Senão PC ← PC + 1
01110 JMP operand PC ← endereço
01111-11111
Reservado para as futuras gerações
Fonte: Adaptado de Zeferino (2007)
29
2.3.2 Organização do BIP II
Segundo Morandi et al (2006), a organização utiliza a estrutura Harvard, com memórias
separadas para dados e instruções, como mostra a Figura 8. Conforme a figura, o processador é
dividido em dois blocos: (i) Controle, responsável por gerar sinais de controle para o caminho de
dados e atualização do PC; e (ii) Caminho de Dados, que inclui os circuitos necessários para
executar a instrução.
CPU
DatapathControl
Decoder
+
1
Extensão de
Sinal
Data MemoryProgram Memory
WrAccOp
SelASelB
WrPC
Addr Data Addr In_Data Out_Data
WrRam
Wr
Opcode N Z
Operand
Instruction
012
ACCenaWrAcc
SelA
SelB01
+/–Op
Branch
01
PCena
Z N
Figura 8. Organização do Processador BIP II
Fonte: Adaptado de Zeferino (2007)
30
A Tabela 3 apresenta a tabela-verdade de especificação do decodificador de instruções.
Conforme pode ser observado, apenas a instrução HLT não atualiza o PC e os valores de Z e N só
são relevantes nas instruções de desvio.
Tabela 3. Tabela de decodificação de instrução
Entradas Saídas Mnemônico Opcode Z N Op SelA SelB WrACC WrRAM WrPC Branch
HLT 00000 X X X XX X 0 0 0 X STO 00001 X X X XX X 0 1 1 0 LD 00010 X X X 00 X 1 0 1 0 LDI 00011 X X X 01 X 1 0 1 0 ADD 00100 X X 0 10 0 1 0 1 0 ADDI 00101 X X 0 10 1 1 0 1 0 SUB 00110 X X 1 10 0 1 0 1 0 SUBI 00111 X X 1 10 1 1 0 1 0 BEQ 01000 1 X X XX X 0 0 1 1 BNE 01001 0 X X XX X 0 0 1 1 BGT 01010 0 0 X XX X 0 0 1 1 BGE 01011 X 0 X XX X 0 0 1 1 BLT 01100 0 1 X XX X 0 0 1 1 BLE 01101 0
0 1 1
0 1 0 1
X X X X
XX XX XX XX
X X X X
0 0 0 0
0 0 0 0
1 1 1 1
0 1 1 1
JMP 01110 X X X XX X 0 0 1 1
Reservado 01111-11111 X X X X X 0 0 0 X
Fonte: Zeferino (2007)
31
2.4 Microcontroladores
Para Marinho e Marinho (2001) e Predko (1998), microcontroladores são sistemas
computacionais composto de processador, memórias; entradas e saídas e vários outros componentes
(temporizador, interface de comunicação serial, conversores analógico/digital, e outros), que em
sistemas computacionais tradicionais são independentes, e em microcontroladores são integrados
em um único chip.
Predko (1998, p. 4) classifica os diferentes tipos de microcontroladores em três grupos:
• Microcontroladores Embarcados: nessa classe de microcontrolador, todos os recursos
necessários estão disponíveis no chip, precisando apenas de energia e do sinal de relógio
(clock). Outras características dessa classe incluem: baixo custo, uso de uma lógica de
controle programável e disponibilidade de interface para dispositivos externos. O
caminho de dados normalmente possui 8 bits e a freqüência de operação é inferior a
10MHz;
• Microcontroladores com memória externa: essa classe é composta por
microcontroladores que dependem completamente de memória externa (memória de
programa e memória RAM). Esses microcontroladores são utilizados em aplicações
como cache/buffer de discos rígidos e distribuidores de grande quantidade de dados; e
• Processadores de Sinal Digital (DSP – Digital Signal Processor): possuem as
características de um processador de aplicação específica apresentado na Seção 2.1.3.3.
2.4.1 Características de Microcontroladores
As subseções a seguir têm a finalidade de explorar e conhecer os componentes internos e
características normalmente encontradas em um microcontrolador.
2.4.1.1 Processador
Segundo Marinho e Marinho (2001), os microcontroladores possuem internamente uma
CPU interligada com os outros blocos do microcontrolador, que tem a responsabilidade de gerenciar
os blocos restantes bem como executar as instruções do programa. Uma métrica de
32
microcontrolador relacionada ao processador é a freqüência máxima de operação, normalmente
medida em MHz (Megahertz) e a presença ou não de um oscilador10 interno.
2.4.1.2 Memórias
A memória é um recurso indispensável para o funcionamento do microcontrolador. Marinho
e Marinho (2001) apresentam alguns dos tipos mais comuns de memórias em microcontroladores
disponíveis no mercado:
• RAM (Random Access Memory): memória volátil11 com acesso aleatório e com
propriedade de leitura e escrita. Normalmente utilizada para armazenar dados e
variáveis;
• ROM (Read Only Memory): memória não volátil apenas de leitura cujo conteúdo é
configurado no momento da fabricação do chip. É Utilizada para armazenar o programa
do microcontrolador;
• PROM (Programmable ROM): memória apenas de leitura que pode ser configurada após
a sua fabricação, mas apenas uma única vez;
• EPROM (Erasable PROM): memória apenas de leitura que é gravada por um dispositivo
específico e apagada por raio ultravioleta diversas vezes;
• EEPROM (Electrically EPROM): similar à memória EPROM, porém é apagada
eletricamente; e
• Memória Flash: memória não volátil com boa relação custo/benefício e pode ser gravada
quando aplicado uma tensão elétrica de 5 ou 12 volts, dependendo do microcontrolador.
É muito similar à memória EEPROM, porém permite apagar um “bloco” de conteúdo, já
nas EEPROM é realizado bit a bit.
Predko (1998, p. 11) classifica as memórias em três grupos:
• Memória de Programa: Memória não volátil (ROM, PROM, EPROM, EEPROM e
Flash) que contém uma tabela de dados e o programa executado pelo microcontrolador;
10 Componente responsável por gerar os pulsos de clock ao microcontrolador constantemente em intervalos fixos. 11 Dispositivo de memória cujo conteúdo se perde na ausência de tensão elétrica de alimentação.
33
• Área Variável: Memória volátil (RAM) que contêm variáveis e parâmetros temporários
do sistema; e
• Pilha (stack): Memória volátil (RAM) baseada na estrutura de dados LIFO (Last In First
Out –Último a Entrar, Primeiro a Sair), utilizada, por exemplo, em chamada de sub-
rotina pelo sistema.
Outras características relevantes, e também métricas de microcontroladores ao tratar de
memórias, referem-se à capacidade de armazenamento e o tamanho da palavra. A memória de
dados normalmente possui uma capacidade muito inferior à memória de programa.
2.4.1.3 Portas de E/S
Segundo Predko (1998, p. 16), para interagir com o mundo exterior, o microcontrolador
utiliza-se de portas de E/S. Portas de E/S são registradores ligados a pinos do microcontrolador, e
podem ser programadas para serem apenas entrada, apenas saídas ou ambos (bidirecional) (MATIC,
2000). Comumente, os microcontroladores oferecem recursos extras ligados a portas de E/S, como
comunicação serial, comunicação paralela, conversor analógico/digital e outros.
Deve-se destacar que a quantidade de portas e os recursos ligados a estas são algumas das
métricas de microcontroladores referente a portas de E/S.
2.4.1.4 Comunicação Serial
Conforme Matic (2000) e Marinho e Marinho (2001), a comunicação serial é maneira de
economizar a quantidade de portas de E/S necessárias para transmitir dados, além de favorecer
transmissões de longa distância. A comunicação visa o envio e recebimento de dados bit-a-bit em
série. Segundo os autores, a comunicação serial deve obedecer a um conjunto de regras que definem
como será realizada a transmissão e a receptação dos dados, este conjunto chama-se protocolo. Os
protocolos mais comuns são o I2C(Inter-Integrated Circuit) e SPI (Serial Peripheral Interface).
Segundo Marinho e Marinho (2001), para realizar a comunicação existem três tipos de sistemas de
interligação digitais:
• simplex: existe apenas uma porta de comunicação e funciona de forma unilateral, na qual
um transmite e outro recebe, Figura 9 (a);
34
• half-duplex: possui dois caminhos de comunicação, um para envio e outro para
recebimento, porém não há transmissão e recebimento simultâneos, Figura 9 (b); e
• full-duplex: igual ao half-duplex, porém permite enviar e receber dados
simultaneamente, Figura 9 (c).
Figura 9. Sistemas de Interligação Digitais. TX (Transmissor) e RX (Receptor)
Fonte: Marinho e Marinho (2001)
2.4.1.5 Temporizador
Segundo Matic (2000) e Souza e Noveletto (2007) o temporizador (timer) é muito
importante dentro do contexto de microcontroladores e requer uma atenção especial. Ele é
composto basicamente por um contador, cujo valor é incrementado em intervalos fixos e podendo
gerar uma interrupção no estouro12 desse contador. Conforme Souza (2004) o sistema de
temporização normalmente disponibiliza um função denominada prescaler que permite configurar a
quantidade pulsos de clock necessários para incrementar o contador do timer.
Segundo Souza e Noveletto (2007), através desta unidade é possível realizar medição de
tempo e freqüência e gerar pulsos. Como métricas de microcontroladores destacam-se a quantidade
de temporizadores e a quantidade de bits de cada contador.
2.4.1.6 Sistema de Rearme Automático (Watchdog)
Muitos dos sistemas microcontrolados encontram-se em lugares isolados ou de difícil
acesso, como no interior de um equipamento, e muitas vezes impossibilitando que o usuário reinicie
o microcontrolador na ocorrência de algum erro de software ou hardware. Para evitar esse
problema, os microcontroladores geralmente incluem um tipo especial de temporizador denominado
12 Quando se ultrapassa o valor máximo suportado por um registrador.
35
watchdog. Quando o contador desse temporizador estoura o seu limite de contagem, ele provoca a
reinicialização do microcontrolador.
2.4.1.7 Interrupções
Conforme já apresentado em seções anteriores e apresentado por Marinho; Marinho (2001),
interrupção é o mecanismo que permite interromper um programa para a execução de uma rotina
com a função desejada relacionada à fonte de interrupção. Em microcontroladores, as interrupções
estão presentes, por exemplo, nas portas de E/S (com interrupção ativada na mudança de estado da
porta), na unidade de temporização (é gerada uma interrupção sempre que o contador alcança um
determinado valor) e na interface de comunicação serial (é gerada uma interrupção quando um dado
é recebido).
Segundo Marinho e Marinho (2001), quando duas ou mais interrupções são ativas no mesmo
instante de tempo, é atendida pelo processador a interrupção que tiver maior prioridade. Algumas
interrupções podem ser habilitadas ou desabilitadas via software, configurando-se bits em um
registrador.
Como métricas de microcontroladores, deve-se levar em conta a quantidade e as fontes de
interrupções do microcontrolador.
2.4.1.8 Conversores Analógico-Digital e Digital-Analógico
Os sinais elétricos manipulados pelos microcontroladores são sinais digitais. Porém, muitos
periféricos utilizam sinais analógicos incompreendidos pelos microcontroladores. Segundo Matic
(2000) e Souza e Noveletto (2007), o conversor Analógico-Digital (conversor A/D) transforma
dados analógicos em dados digitais, ou seja, bits. Esse conversor possui uma propriedade
denominado precisão que é medida em bits, na qual, quanto maior o número de bits de um
conversor, maior será sua precisão e vice-versa. Assim, alguns exemplos de conversores A/D são
A/D de 8 bits, A/D de 10 bits, A/D de 12 bits e assim por diante. A função do conversor Digital-
Analógico é justamente o contrário. A precisão e a quantidade de portas de E/S com suporte a esses
conversores podem ser consideradas métricas de microcontroladores.
36
2.4.1.9 Comparadores Analógicos
Comparador Analógico é um recurso que permite realizar a comparação entre duas tensões
de entrada no microcontrolador. Segundo Souza e Noveletto (2007), este recurso permite detectar a
ocorrência de um curto-circuito na aplicação, realizar a conversão analógico-digital com auxílio de
hardware auxiliar, efetuar a detecção de limiar de mudança de nível, entre outras. Como métrica de
microcontroladores, tem-se a quantidade de comparadores disponível.
2.4.1.10 PWM
Segundo Souza e Noveletto (2007) e Souza (2004), o recurso de PWM (Pulse Width
Modulator) permite gerar uma seqüência de pulsos com largura variável, regulados por um filtro
passa-baixa que tem como resultado a tensão proporcional ao duty cycle dessa seqüência. Como
métricas de microcontroladores pode-se destacar a precisão em bits de tal recurso e a quantidade de
comparadores disponível.
2.4.1.11 Modo Sleep
Também conhecido como modo de baixo consumo, o modo Sleep é um recurso
disponibilizado pelo microcontrolador e acionado por software que paralisa o oscilador e
conseqüentemente o processamento, até que um evento especial ocorra fazendo que o
microcontrolador volte à atividade. Esse recurso é fundamental para aplicações alimentadas por
pilhas e baterias, já que no tempo em que o microcontrolador está em modo sleep, o consumo de
energia é menor (SOUZA, 2004, p. 162; SOUZA; NOVELETTO,2007).
2.4.1.12 Microcontroladores Comerciais
O objetivo desta subseção é apresentar um estudo comparativo de alguns modelos de
microcontroladores comerciais, com foco naqueles mais utilizados no LSED13, laboratório ao qual
este trabalho está vinculado. Esse estudo visa levantar as características presentes em cada
microcontrolador: Conforme a Tabela 4, as colunas apresentam os modelos de microcontroladores
comerciais, e as linhas apresentam as características desses microcontroladores.
13 Laboratório de Sistemas Embarcados e Distribuídos da UNIVALI (Universidade do Vale do Itajaí)
Tabela 4. Características de Microcontroladores comerciais
Modelo PIC 16F628 PIC 16F877 PIC 18F452 8051 Rabbit 3000 MC68HC908QY4 Fabricante Microchip ® Microchip ® Microchip ® Intel ® Rabbit Semiconductor ® Motorola ® Freqüência Max. de Operação (MHz) 20 20 40 12 54 32 Palavra de Dados (bits) 8 8 8 8 8 8 Palavra de Instrução (bits) 14 14 16 Variável (8, 16) 20 16 Memória de Dados RAM (bytes) 224 368 1536 128 + Até 64K externa Externa 128 Memória de Dados EEPROM (bytes) 128 256 256 - Externa - Memória de Instrução (palavra) FLASH
2K FLASH
8K FLASH 16384
ROM 4K + até 64K externa
Externa FLASH 4K
I/O Ports (Qtd) 16 33 33 32 56 13 Comunicação Serial USART MSSP
USART MSSP, USART
UART UART, HDLC
Timers (Qtd) 2/8-bit 1/16-bit
2/8-bit 1/16-bit
1/8-bits 2/16-bits
2/16-bit 10/8-bit 1/16-bit
2/16-bit
Watchdog Sim Sim Sim Sim Sim Sim PWM (Qtd) 1/10-bit 1/10-bit Max. 10-bit 0 4/10-bit 2/8-bit Interrupções (Qtd) 10 14 18 5 16 6 Conversor A/D (Qtd/Bits) 0 8/10-bit 8/10-bit 0 0 4/8-bit Comparador (Qtd) 2 0 0 0 0 0 Pinos (Qtd) / Encapsulamento 18-pin DIP,SOIC
20-pin SSOP 40-pin DIP/SOIC 44-PLCC/QTF
40-pin DIP 44-pin PLCC 44-pin TQFP
40-pin DIP 44-pin PLCC
128-pin LQFP/TFBGA 16-pin DIP/ SOIC/SSOP
Conjunto de Instruções (Qtd) 35 35 75 111 258 262 Arquitetura Interna Harvard
RISC Harvard RISC
Harvard RISC
Von Neumann CISC
Von Neumann CISC
Von Neumann CISC
Fonte: Adaptado de Freescale (2004); Intel (1991); Microchip (2001); Microchip (2002); Microchip (2003); Rabbit Semiconductor (2007)
Os microcontroladores listados na Tabela 4 possuem características bastante homogêneas,
exceto pelo periférico comparador, presente em apenas um dos microcontroladores apresentados.
Os periféricos Watchdog, Timer e Fontes de Interrupções estão presentes em todos os
microcontroladores listados. Já os periféricos de Comunicação Serial e PWM só não estão presente
em um dos microcontroladores.
A freqüência das características apresentadas na Tabela 4 foi utilizada neste trabalho na
elaboração de um Questionário (Apêndice B ) que será tratado mais adiante na Seção 3 .
2.5 ArchC
O ArchC é uma Linguagem de Descrição de Arquitetura (Architecture Description
Language, ADL) baseada no SystemC14, desenvolvido pelo Instituto de Computação da
Universidade de Campinas (IC-UNICAMP) (THE ARCHC TEAM, 2007a). Segundo Baldassin
(2005), uma ADL permite gerar automaticamente ferramentas de software (simulador, compilador,
montador, ligador e depurador) com base em uma descrição da arquitetura de processador. Em sua
versão atual (2.0), o ArchC permite descrever além da arquitetura, a hierarquia de memória do
processador, gerando automaticamente ferramentas como simulador, montador, ligador e
depurador.
Segundo The ArchC Team (2007b), a descrição de uma arquitetura utilizando o ArchC é
divida em dois blocos principais: (a) Recursos da Arquitetura (Architecture Resources - designada
por AC_ARCH), a qual contém a descrição da quantidade e tipo de memória, da quantidade de
registradores e do pipeline15; e (b) Arquitetura do Conjunto de Instruções (Instruction Set
Architecture - designada por AC_ISA), a qual contém detalhes sobre o conjunto de instruções
como: (i) formato; (ii) tamanho; (iii) identificador; (iv) decodificação; e (v) comportamento.
As subseções a seguir apresentam mais informações sobre a descrição de uma arquitetura
utilizando o ArchC, tomando como exemplo a descrição funcional do processador BIP-II (descrito
14 HDL baseada na linguagem de programação C/C++ 15 Técnica de hardware que permite aumentar o desempenho do processador executando mais de uma instrução por vez.
39
previamente na Seção 2.3)16. A solução completa dessa implementação pode ser encontrada no
Apêndice A .
Mais informações sobre como obter, instalar e utilizar os pacotes do ArchC e ferramentas
auxiliares pode ser encontradas em The ArchC Team (2007a); The ArchC Team (2007b) e
Apêndice D .
2.5.1 Recursos da Arquitetura (AC_ARCH)
Para a geração das ferramentas de software através do ArchC é preciso informar dados
referentes à sua arquitetura. Conforme The ArchC Team (2007b), o ArchC permite gerar
ferramentas em diferentes níveis de detalhamento, como o modelo funcional, em que com pouca
informação é possível gerar ferramentas que, por exemplo, analisem apenas o conjunto de
instruções, ignorando aspectos de temporização ou pipeline, e o modelo com precisão de ciclos, no
qual é possível construir ferramentas que considerem aspectos de temporização, pipeline e outras
características estruturais que tornem o modelo mais realístico.
01. AC_ARCH(bip2){ 02. ac_mem memRAM:2K; 03. ac_mem memROM:64K; 04. ac_reg ACC; 05. ac_reg Z, N; 06. ac_wordsize 16; 07. 08. ARCH_CTOR(bip2) { 09. ac_isa("bip2_isa.ac"); 10. set_endian("big"); 11. };
12. };
Figura 10. Descrição dos Recursos para o processador BIP-II
A Figura 10 apresenta um exemplo de declaração dos recursos da arquitetura para o
processador BIP-II em modelo funcional. Nesse exemplo, utilizou-se de algumas palavras-chaves
da linguagem ArchC como:
16 O exemplo apresentado demonstra estudos já realizados nesta fase do TCC no sentido de se obter capacitação no uso do ArchC para a descrição do BIP, requisito para os trabalhos a serem desenvolvidos.
40
• AC_ARCH: inicia a declaração dos recursos da arquitetura seguida pelo nome do projeto
entre parênteses;
• ac_wordsize : declara o tamanho da palavra, no exemplo, 16 bits;
• ac_mem: declara um dispositivo de armazenamento com capacidade em K(kilobyte),
M(megabyte), G(gigabyte) ou byte quando não houver identificação. No exemplo, o
dispositivo possui o nome de MEM e capacidade de 2 kilobyte;
• ac_reg : declara um registrador, no exemplo, o registrador declarado é o ACC
(acumulador);
• ARCH_CTOR: indica o inicio do construtor do AC_ARCH, seguido pelo nome do
projeto;
• ac_isa : informa o nome do arquivo que possui a declaração do conjunto de instruções,
AC_ISA. No exemplo, o arquivo é bip2_isa.ac; e
• set_endian : informa o endianness17 da arquitetura, podendo ser big ou little, no
exemplo, o BIP-II utiliza o big.
O ArchC suporta diversas outras palavras-chaves, bem como suporte à hierarquia de
memória. No entanto, está além do escopo do trabalho apresentar detalhes de tal linguagem.
2.5.2 Arquitetura do Conjunto de Instruções (AC_ISA)
Conforme The ArchC Team (2007b), a arquitetura do conjunto de instruções é realizada
através de dois arquivos: (i) arquivo contendo informações sobre o conjunto de instruções como
formato, tamanho, as declarações, a seqüência de decodificação e o formato na linguagem assembly
(utilizado para gerar o montador) – esse arquivo é escrito na própria linhagem ArchC; e (ii) arquivo
contendo o comportamento das instruções – esse arquivo é escrito em C++/SystemC.
17 Refere-se à forma de ordenação dos bytes quanto à magnitude. No big-endian a ordenação do byte mais significativo para o menos significativo é feita da esquerda para direita, já no litte-endian da direita para esquerda (HENNESSY;PATTERSON,2003, P. 70).
41
2.5.2.1 Descrição do ISA
Como mencionado, em um arquivo com extensão “.ac ” são definidos dados referentes à
arquitetura do conjunto de instrução (ISA). Esse arquivo deve conter dados referentes ao formato de
instrução, conjunto de instruções, opcode, formatos de representação da instrução na linguagem de
montagem, entre outros. Assim como o arquivo de Recursos da Arquitetura, este arquivo também é
escrito em linguagem ArchC.
A Figura 11 apresenta parte da descrição do conjunto de instruções do processador BIP-II.
Essa descrição apresenta algumas palavras-chaves que são relacionadas abaixo (THE ARCHC
TEAM, 2007b):
• AC_ISA: indica o início de uma descrição de conjunto de instruções seguido pelo nome
do projeto entre parênteses;
• ac_format : declara o formato de uma instrução. A definição do formato inicia-se com
a palavra-chave ac_format seguido pelo nome do formato (ex: Type_I) e os campos
que compõem o formato. No exemplo, o formato Type_I possui dois campos “op” com
5 bits e “operand” com 11. Assim, a declaração de um campo segue o formato:
%campo:Numero_Bits;
• ac_instr <fmt>: utilizado para declarar uma ou mais instruções baseadas em um
mesmo formato . A declaração inicia com a palavra-chave ac_instr , seguida pelo
formato de instrução declarado previamente e por uma ou mais instruções (separadas por
vírgulas). No exemplo, todas as instruções são baseadas no mesmo formato, mas são
declaradas em linhas diferentes para organizá-las em função da classe a que pertencem
(aritméticas, carga e armazenamento, controle, desvio condicional e desvio
incondicional);
• ISA_CTOR: indica o inicio da declaração do construtor;
• set_asm : define uma declaração assembly para a instrução. Entre aspas duplas, deve
conter os campos na linguagem assembly seguido pelos campos declarados no formato,
por exemplo, na linha 10, a sintaxe set_asm(“hlt %imm”, operand) informa que o
imediato (%imm) apresentado na sintaxe é referente ao campo “operand” definido no
formato da instrução; e
42
• set_decoder : determina a seqüência de decodificação de uma instrução. No exemplo
(linha 11), o set_decoder é utilizado para atribuir o valor do opcode da instrução ao
campo “op”, definido no formato da instrução.
01. AC_ISA(bip2){ 02. ac_format Type_I = "%op:5 %operand:11"; 03. ac_instr<Type_I> add, sub, addi, subi; 04. ac_instr<Type_I> sto,ld,ldi; 05. ac_instr<Type_I> hlt; 06. ac_instr<Type_I> beq, bne, bgt, bge, blt, ble; 07. ac_instr<Type_I> jmp; 08. 09. ISA_CTOR(bip2){ 10. hlt. set_asm("hlt % imm", operand); 11. hlt. set_decoder(op=0x00); 12. 13. sto. set_asm("sto % imm", operand); 14. sto. set_decoder(op=0x01); 15. 16. ... 17. ... 18. };
19. };
Figura 11. Descrição parcial do conjunto de instrução para o processador BIP-II
Outras informações referentes à definição do conjunto de instrução utilizando o ArchC,
podem ser encontrada em The ArchC Team (2007a) e The ArhcC Team (2007b).
2.5.2.2 Descrição dos Comportamentos
Segundo The ArchC Team (2007b), a definição do comportamento de uma instrução é
descrita em linguagem SystemC/C++ e pode ser realizada em três níveis:
• Genérico: descreve o comportamento executado por todas as instruções;
• Formato: descreve o comportamento executado por todas as instruções do formato de
instrução especificado; e
• Instrução: descreve o comportamento executado apenas pela instrução especificada.
Assim, o comportamento de uma instrução é definido por uma hierarquia de
comportamentos, sendo feito primeiramente pelo comportamento genérico associado, seguido pelo
comportamento do formato e pelo comportamento específico da instrução.
43
Na Figura 12, é possível verificar os três níveis de hierarquia de comportamento para
execução da instrução add . O comportamento genérico é indicado pelo parâmetro de função
instruction . No exemplo, a cada instrução executada, o valor da variável global do ArchC
ac_pc é incrementado em 2 18. O comportamento do formato de instrução é indicado pelo
parâmetro com o nome do formato, definido previamente. No exemplo, o formato em parâmetro é o
Type_I e na função, a cada instrução deste formato, são atualizados os valores dos registradores
Z e N. O comportamento exclusivo da instrução add é definido pelo parâmetro com o nome da
instrução. No exemplo, a instrução acessa o valor do registrador ACC através do método read e
grava um valor através do método write . O exemplo também utiliza instruções exclusivas da
linguagem como printf para imprimir resultados na tela durante a simulação.
Outras informações referentes ao comportamento do conjunto de instruções utilizando o
ArchC, podem ser encontradas em The ArchC Team (2007a) e The ArhcC Team (2007b). O código
fonte completo da descrição comportamental do BIP-II está disponível no Apêndice A.3.
18 isso porque o ArchC trata os dispositivos de armazenamento em endereçamento byte-a-byte, assim são necessário o incremento de 2 ao PC para equivaler ao tamanho da palavra no BIP II (16 bits)
44
//!Generic instruction behavior method. void ac_behavior( instruction ){ ac_pc = ac_pc + 2; }; //----------------------------- //! Instruction Format behavior methods. void ac_behavior( Type_I ){ //Atualiza o Status //----------------------------- if (ACC.read()==0) Z.write(1); else Z.write(0); if (ACC.read()<0) N.write(1); else N.write(0); } //----------------------------- //!Instruction add behavior method. void ac_behavior( add ){ printf( "ADD 0x%x + 0x%x\n" , ACC.read(), memRAM.read(operand) ); ACC.write(ACC.read()+(memRAM.read(operand)&0xFFFF )); } //-----------------------------
Figura 12. Descrição parcial do comportamento do conjunto de instrução do
processador BIP-II
3 DESENVOLVIMENTO
Esta seção tem por objetivo apresentar o projeto e o desenvolvimento da solução proposta
conforme discutido na seção 1.1. A Seção 3.1 apresenta de maneira abstrata os requisitos definidos
no projeto do µBIP. A Seção 3.2 apresenta a especificação da arquitetura, já a Seção 3.3 apresenta a
especificação da organização do µBIP e dos periféricos. Na Seção 3.4 é apresentada a
implementação do modelo no ArchC e na Seção 3.5 a implementação do modelo em VHDL.
3.1 Análise de Requisitos
Para definir os requisitos do microcontrolador proposto, foi feita uma consulta a professores,
técnicos e engenheiros da área de sistemas embarcados, questionando-os sobre as características
fundamentais para um microcontrolador visando sua aplicação no âmbito educacional. Foram
recebidas respostas de nove pessoas que opinaram sobre os requisitos listados abaixo (em
parênteses, o percentual de respostas positivas):
• Inclusão de novas instruções:
1. Instruções de lógica booleana (100% sim)
2. Instruções de deslocamento lógico (78% sim)
3. Instruções de deslocamento aritmético (33% sim)
4. Instruções de manipulação de bit (78% sim)
5. Instrução de ativação do modo sleep (11% sim)
6. Suporte a chamadas de procedimentos (67% sim)
• Periféricos básicos a serem integrados:
1. Pinos de E/S unidirecionais (56% sim)
2. Pinos de E/S bidirecionais (78% sim)
3. Pino de interrupção sensível à borda (78% sim)
4. Pino de interrupção sensível ao nível (56% sim)
5. Temporizador programável (100% sim)
6. Contador de pulsos (33% sim)
46
7. Temporizador watchdog (33% sim)
8. Prescaler para temporizadores (56 % sim)
9. Conversor A/D (56% sim)
10. Interface de comunicação serial (78%)
Além da indicação de periféricos, os consultados também retornaram com as características
e/ou tipo desejável desses periféricos. A pesquisa completa está disponível no Apêndice B .
Com base nessa pesquisa e nos princípios de projeto da família de processadores BIP, foram
identificados os requisitos que definiram as diretrizes a serem seguidas durante o projeto e
desenvolvimento do µBIP. Também foi levada em consideração a complexidade da inclusão das
características consultadas na pesquisa frente ao tempo disponível para a implementação deste
projeto dentro do contexto de um Trabalho de Conclusão de Curso. Algumas características foram
definidas como opcionais, podendo ser incluídas posteriormente.
Requisitos Funcionais (RF)
• RF01: O µBIP deverá ter suporte para as seguintes classes de instrução: (a) transferência
de dados; (b) aritmética; (c) lógica booleana; (d) desvios; (e) deslocamento lógico; (f)
manipulação e teste de bits; (g) suporte a procedimentos; e (h) controle.
• RF02: O µBIP deverá ter pelo menos os seguintes periféricos: (a) pinos de E/S
bidirecionais com interrupção sensível à borda; e (b) temporizador programável com
prescaler, podendo ser estendido para incluir (pela ordem): (i) porta de comunicação
serial; (ii) conversor A/D; (iii) contador de pulsos; e (iv) temporizador watchdog.
Requisitos Não-Funcionais (RNF)
• RNF01: O µBIP deverá estender a arquitetura da família de processadores BIP, assim
deverá ser baseado nas diretrizes dessa família.
• RNF02: O µBIP deverá ter uma arquitetura simples o suficiente para facilitar o
aprendizado de seu funcionamento pelos usuários.
• RNF03: O µBIP deverá ter uma arquitetura extensível.
47
• RNF04: O simulador de conjunto de instruções deverá ser implementado no ArchC19.
• RNF05: O modelo sintetizável do µBIP deverá ser implementado em VHDL20.
3.2 Especificação da Arquitetura
O objetivo desta seção é especificar os atributos arquiteturais presentes no microcontrolador
µBIP. Por ser uma extensão da família de processadores BIP, o µBIP herda diversas características
e incrementa outras. As subseções a seguir descrevem tais atributos arquiteturais e finaliza com um
resumo da arquitetura do µBIP.
3.2.1 Tamanho da Palavra e Tipo de Dados
O tamanho da palavra de dados e palavra de instrução no µBIP é de 16 bits. O tipo dado
suportado é o tipo Inteiro com sinal de 16 bits que comporta valores entre -32768 e +32767 21.
Portanto, quanto aos aspectos de tamanho de palavra e tipo de dados, o µBIP conserva aqueles
utilizados no BIP II, apresentado anteriormente.
3.2.2 Espaços de Endereçamento
O espaço de endereçamento de memória de instrução no µBIP é limitado pelas instruções de
desvio, que utilizam um operando de 11 bits para informar um endereço absoluto do salto. Com
isso, é possível endereçar até 2K (211) de instruções. 22
O espaço de endereçamento da memória de dados também é de 11 bits, o que permite
endereçar até 2K endereços. Porém, este espaço é divido com o espaço de endereçamento dos
periféricos (ver Figura 13). Isso porque o método utilizado é o de E/S mapeada em memória.
Segundo Vahid e Givargis (2002, p. 144-146), o método de E/S mapeada em memória
utiliza uma parte de um espaço de endereçamento já existente e não há a necessidade da inclusão de
19 No projeto do µBIP, optou-se pela ADL ArchC, pois esta é baseada na linguagem de modelagem de sistemas SystemC utilizada no LSED, laboratório a qual esse trabalho está vinculado. 20 Durante a fase de projeto do µBIP, optou-se pelo VHDL, pois é a HDL utilizada na universidade a qual esse trabalho está vinculado tanto no ensino quanto no LSED. 21 Para versões posteriores, é considerada a possibilidade de incluir suporte a inteiros de 32 bits, o que não será feito neste momento para limitar a complexidade desta versão. 22 Durante a fase de projeto do µBIP, foi cogitada a utilização de instruções de saltos com desvios relativos ao PC, o que permitiria desviar para posições mais distantes por meio de uma seqüência de salto. Porém, isso implicaria em aumentar a complexidade da arquitetura (mais modos de endereçamento) e da organização.
48
instruções para comunicar com os periféricos. Também foi cogitado o método de E/S padrão
(também conhecido como E/S mapeada em E/S), o qual segundo Vahid e Givargis (2002, p.144-
146) requer um fio adicional no barramento para indicar se o acesso é ao periférico ou à memória de
dados, além de instruções exclusivas para manipular os periféricos (normalmente a instrução IN
para leitura e OUT para escrita). Durante a fase de projeto optou-se pela E/S mapeada em memória
por dois motivos: (i) simplicidade, pois usa as mesmas instruções para manipular variáveis de
memória e periféricos, além exigir poucas alterações em nível de hardware; e (ii ) economia de
instruções, já que no método E/S padrão utiliza instruções específicas.
Portanto, em relação ao espaço de endereçamento dos dados, o µBIP possui 1K-palavra
destinados a memória de dados e 1K-palavras para registradores de E/S. A vantagem dessa divisão
ao meio deve-se principalmente ao fato de utilizar apenas um bit do endereço para identificar se o
acesso refere-se à memória ou à E/S, como mostra a Figura 13.
Figura 13. Espaçamento de Memória no µBIP
Conforme mostra a Figura 14, a parte destinada à E/S mapeia os registradores dos
periféricos do µBIP que estão visíveis ao programador. Esses registradores mantêm informações
tais como: (i) configuração da direção dos pinos de E/S; (ii ) estados dos pinos de E/S; (iii ) valor de
contagem do temporizador; e (iv) configuração do prescaler. Esses registradores serão discutidos
mais adiante neste texto.
49
Figura 14. Organização da Memória de E/S
3.2.3 Registradores
A CPU do µBIP possui os seguintes registradores especiais: (i) PC (Program Counter), que
contém o endereço da instrução corrente; (ii ) ACC (Accumulator), que contém o resultado da
Unidade Funcional23 (ou UF); (iii ) STATUS, que contém informações sobre o resultado da
operação da ULA; (iv) INDR (Index Register), que contém o índice do vetor, utilizado em
instruções de manipulação de vetores; e (v) SP (Stack Pointer), que aponta para o topo da pilha de
suporte à chamada de procedimentos. O fato do PC apontar para instrução corrente e não para a
próxima instrução é devido à ausência de um registrador de instrução, já que sua implementação é
baseada em uma abordagem monocíclica, semelhante à implementação MIPS monociclo descrita
por Patterson e Hennessy (2000) e já adotada no BIP II.
O registrador de STATUS do µBIP possui os seguintes flags: (i) Z, que indica se o resultado
da operação na ULA é zero; e (ii ) N, que indica se o resultado da operação na ULA é um número
negativo; e (iii ) C, que indica se ocorreu um carry-out ou borrow em instruções aritméticas.
Maiores informações sobre os registradores estão disponibilizadas no Apêndice H .
23 A Unidade Funcional no µBIP é composta de uma ULA e dois barrel shifters para realizar o deslocamento associado às instruções SLL e SRL.
50
3.2.4 Formatos de Instrução
O µBIP possui um único formato de instrução composto de 5 bits para o código da operação
e 11 bits para o operando, conforme mostra a Figura 15. Com esse operando, é possível endereçar
até 2K posições de memória, para instruções que utilizam o operando como endereço de memória; e
representar constantes com valores no intervalo de –1024 a +1023, para instruções que utilizam o
operando imediato como já mencionado antes.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Cód. Operação Operando
Figura 15. Formato de instrução no µBIP
Esse formato de instrução considera um operando implícito que é o registrador ACC e outro
operando explícito dado pelos 11 bits da instrução. Há instruções baseadas no formato que não
utilizam o operando explícito, como, por exemplo, a instrução de controle HLT.
Na fase de projeto do µBIP, foi cogitada a presença de instruções para teste e manipulação
de bits como Bit-Set, Bit-Clear e Bit-Test. Para suprir a necessidade desses tipos de instrução seria
necessário o acréscimo de mais um formato de instruções com dois campos, um para o valor do bit
e outro para endereço do bit. Porém, após análise, foi constatado que essas instruções geravam uma
complexidade maior ao modelo e que, na ausência desse tipo de instrução, as instruções da classe
lógica booleana poderiam ser utilizadas para produzir a mesma funcionalidade.
3.2.5 Modos de Endereçamento
A arquitetura do processador possui três modos de endereçamentos: (i) Direto, no qual o
operando refere-se a um endereço efetivo da memória de dados; e (ii ) Imediato, no qual o operando
é uma constante de dados; e (iii ) Indireto, no qual o operando é um endereço base de um vetor que
será somado com o registrador INDR para determinar um endereço efetivo da memória de dados,
como representado na Figura 16. Destaca-se que muitas das instruções possuem um segundo
operando implícito que é o ACC (ex. instruções aritméticas).
51
Figura 16. Modo de endereçamento Indireto
3.2.6 Conjunto de Instruções
O conjunto de instruções do µBIP é uma extensão do conjunto de instruções do BIP II,
apresentado previamente na Tabela 2, acrescido de instruções das seguintes classes: (i) lógica
booleana; (ii ) deslocamento lógico; (iii ) manipulação de vetores; e (iv) suporte a procedimentos.
Um resumo do conjunto de instruções é apresentado na Tabela 5, a seguir, nas quais é possível
verificar como as instruções interferem no valor dos registradores ACC, STATUS e PC. Uma
descrição mais completa do conjunto de instruções do µBIP é apresentado no Apêndice C .
O conjunto de instruções do µBIP preserva os mnemônicos adotados no BIP II. Esses
mnemônicos são semelhantes aos utilizados pelo processador MIPS (PATTERSON; HENNESSY,
2000).
Outra característica que visa à simplicidade está nos opcodes das instruções. Como pode ser
observado na Tabela 5, as instruções que executam a mesma operação, mas usando modos de
endereçamento diferentes, como LD e LDI , ADD e ADDI, SUB e SUBI, AND e ANDI, OR e ORI e
XOR e XORI possuem uma variação no opcode apenas no bit 0, sendo 0 para operando de memória
(modo de endereçamento direto) e 1 operando imediato (modo de endereçamento imediato, como
por exemplo: LD=00010 e LDI =0001124.
O conjunto de instruções do µBIP possui 29 instruções separadas em 9 classes. O opcode
presente nos formatos de instruções é de 5 bits, o que permite codificar até 32 instruções (25), ou
seja, restam ainda 3 opcodes não utilizados para novas instruções.
24 A escolha por essa relação foi feita já na especificação da arquitetura do BIP I e apoiou-se no fato de que 0 possui formato que remete ao D (Direto), enquanto que o 1 remete ao I (imediato). Entende-se que essa escolha facilita o aprendizado dos opcodes pelos alunos.
52
A classe de instrução suporte a procedimentos é baseada na solução utilizada na arquitetura
PIC16 da Microchip (2001). Nela, quando ocorre uma chamada de procedimentos (ou uma
interrupção), o endereço da próxima instrução a ser executada após o retorno do procedimento é
armazenado no topo de uma estrutura de pilha (Top of Stack, ou ToS) dedicada exclusivamente
para este fim. Essa pilha não é mapeada no espaço de memória, pois é implementada como uma
estrutura de hardware tipo LIFO (Last-In, First-Out) baseada em registradores com uma
profundidade limitada definida por um parâmetro de projeto no processo de síntese do processador.
Tabela 5. Conjunto de instruções do µBIP
Opcode Instrução Flags Operação e atualização do PC 00000 HLT Desabilita atualização do PC PC ← PC 00001 STO operand Memory[operand] ← ACC PC ← PC + 1
00010 LD operand ACC ← Memory[operand] PC ← PC + 1
00011 LDI operand ACC ← operand PC ← PC + 1
00100 ADD operand Z,N,C ACC ← ACC + Memory[operand] PC ← PC + 1
00101 ADDI operand Z,N,C ACC ← ACC + operand PC ← PC + 1
00110 SUB operand Z,N,C ACC ← ACC – Memory[operand] PC ← PC + 1
00111 SUBI operand Z,N,C ACC ← ACC – operand PC ← PC + 1
01000 BEQ operand
Se (STATUS.Z=1) então PC ← endereço Se não PC ← PC + 1
01001 BNE operand
Se (STATUS.Z=0) então PC ← endereço Se não PC ← PC + 1
01010 BGT operand
Se (STATUS.Z=0) e (STATUS.N=0) então PC ← endereço Se não PC ← PC + 1
01011 BGE operand
Se (STATUS.N=0) então PC ← endereço Se não PC ← PC + 1
01100 BLT operand
Se (STATUS.N=1) então PC ← endereço Se não PC ← PC + 1
01101 BLE operand
Se (STATUS.Z=1) ou (STATUS.N=1) então PC ← endereço Se não PC ← PC + 1
53
Tabela 5. Conjunto de instruções do µBIP (continuação)
Opcode Instrução Flags Operação e atualização do PC 01110 JMP operand PC ← endereço
01111 NOT Z,N ACC ← NOT(ACC) PC ← PC + 1
10000 AND operand Z,N ACC ← ACC AND Memory[operand] PC ← PC + 1
10001 ANDI operand Z,N ACC ← ACC AND operand PC ← PC + 1
10010 OR operand Z,N ACC ← ACC OR Memory[operand] PC ← PC + 1
10011 ORI operand Z,N ACC ← ACC OR operand PC ← PC + 1
10100 XOR operand Z,N ACC ← ACC XOR Memory[operand] PC ← PC + 1
10101 XORI operand Z,N ACC ← ACC XOR operand PC ← PC + 1
10110 SLL operand Z,N ACC ← ACC << operand PC ← PC + 1
10111 SRL operand Z,N ACC ← ACC >> operand PC ← PC + 1
11000 STOV operand Memory[operand + INDR] ← ACC PC ← PC + 1
11001 LDV operand ACC ← Memory[operand + INDR] PC ← PC + 1
11010 RETURN PC ← ToS
11011 RETINT PC ← ToS
11100 CALL operand PC ← operand ToS ← PC+1
3.2.7 Resumo da Arquitetura µBIP Tabela 6. Arquitetura do µBIP
Tamanho da palavra de dados 16 bits Tipos de dados Inteiro de 16 bits com sinal –32768 a +32767 Tamanho da palavra de instrução 16 bits Formato de instrução
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Cód. Operação Operando Modos de endereçamento Direto: o campo Operando é um endereço efetivo da memória de dados
Imediato: o campo Operando é uma constante de dado Indireto: o campo Operando é um endereço base de um vetor que é somado ao INDR para o cálculo de um endereço efetivo da memória de dados
Registradores ACC: acumulador PC: contador de programa STATUS: registrador de Status INDR: registrador de índice SP: apontador do topo da pilha
Classes de instrução Armazenamento: STO Carga: LD e LDI Aritmética: ADD, ADDI, SUB e SUBI Lógica booleana: AND, OR, XOR, ANDI, ORI, XORI e NOT Controle: HLT Desvio: BEQ, BNE, BGT, BGE, BLT, BLE e JMP Deslocamento Lógico: SLL e SRL Manipulação de vetor: LDV e STOV Suporte a procedimentos: RETURN, RETINT e CALL
54
3.3 Especificação da Organização
A organização do µBIP é baseada na organização do BIP II, mantendo a estrutura com
memórias de instruções e dados separadas (tipo Harvard, mostrada anteriormente na Figura 6 (a)) e
a arquitetura baseada em acumulador (previamente ilustrada na Figura 5 (b)).
A Figura 17 apresenta uma visão abstrata da organização interna do µBIP. A figura
apresenta a CPU e os barramentos com as memórias de dados e de instruções separadas, além dos
periféricos ligados no mesmo barramento da memória de dados, conforme mencionado na Subseção
3.2.2 .
Figura 17. Visão abstrata da organização do µBIP
A Figura 18 mostra uma visão detalhada da organização, na qual é visível o aumento no
número de sinais de controles e a adição de novos componentes, incluindo: (i) uma unidade
funcional que executa operações de aritmética, lógica e de deslocamento, substituindo a unidade
aritmética do BIP II. (ii ) uma pilha na unidade de controle para suporte a procedimentos e
interrupções; (iii ) uma unidade de manipulação de vetores no caminho de dados (ela inclui o
registrador INDR); (iv) uma interface de acesso via barramento da memória de dados aos
registradores de propósito especiais (SFR – Special Function Register) dos periféricos integrados;
(v) um controlador de interrupções.
55
0
1
10
da
ta_
in
ad
dr_
in
Figura 18. Visão detalhada da organização da CPU do µBIP
Unidade Funcional
A Unidade Funcional presente no caminho de dados do µBIP (Figura 18) é a união de uma
unidade aritmética (soma e subtração) com uma unidade lógica (funções lógicas: AND, OR, NOT e
XOR) e também uma unidade de deslocamento lógico (deslocamento a esquerda e a direita). Uma
visão da Unidade Funcional é apresentada na Figura 19. A entrada operation de 3 bits permite
identificar a operação a ser realizada pela Unidade Funcional, conforme os códigos apresentados na
Tabela 7. Destaca-se que a Unidade Funcional possui as três saídas de condição que compõem o
registrador STATUS: C, Z e N , conforme já descrito.
56
Figura 19. Organização da Unidade Funcional do µBIP
Tabela 7. Código de operação da Unidade Funcional
Operation Operação Instruções 000 Soma ADD e ADDI 001 Subtração SUB e SUBI 010 Função lógica E AND e ANDI 011 Função lógica OU OR e ORI 100 Função lógica XOR XOR e XORI 101 Função lógica NOT NOT 110 Deslocamento Lógico para esquerda SLL 111 Deslocamento Lógico para direita SRL
Pilha
A Pilha (Stack) incluída na Unidade de Controle tem a finalidade de guardar o endereço da
instrução seguinte à instrução CALL, mantendo assim o endereço de retorno da função. A instrução
RETURN apenas desempilha o valor colocado pela instrução CALL e restaura o conteúdo do PC,
fazendo assim que o programa continue normalmente. A Pilha possui um hardware simples, dotado
de uma memória do tipo LIFO, um somador/subtrator e um registrador para indicar a posição do
topo da pilha (SP – Stack Pointer), conforme mostra a Figura 20.
57
Manipulação de vetores
Esse bloco viabiliza a construção de aplicativos que utilizam vetores e está relacionado às
instruções LDV e STOV. A lógica de seu funcionamento já foi apresentada na Seção 3.2.5 e na
Figura 16. O hardware necessário para a implementação desse módulo é mostrado na Figura 21,
como mostrado trata-se de um registrador (INDR) e um somador. A entrada data_in e wr_indr
são utilizados para armazenar o índice no registrador INDR e isso realizado através da instrução
STO. A entrada operand contém o operando da instrução. A entrada select é utilizada para
definir se o resultado do modulo (addr ) será apenas a entrada operand ou será a somada do
operand com o valor armazenado em INDR.
SPena
-/ +
1
...
n-1
...
...
0 doutdinwren
op
Stack
Figura 20. Organização da Pilha
58
Figura 21. Organização do módulo de manipulação de vetores
Periféricos: Pinos de E/S
O µBIP possui duas portas com 16 pinos de E/S bidirecionais e com controle individual de
direção (ou seja, diferentes bits de uma mesma porta podem ser configurados como de entrada ou
de saída). A notação utilizada para identificar a porta é dada por “portX” onde X é o identificador
único da porta como, por exemplo, “port0”. A manipulação com os pinos de entrada e saída é feita
através de instruções LD e STO nos registradores portX_dir e portX_data . O registrador
portX_dir é responsável por determinar a direção (entrada ou saída) dos pinos da porta. Quando
um bit correspondente a um pino é setado (= 1) no registrador portX_dir , significa que este atuará
como entrada, e quando em ‘0’ atuará como saída. Para Souza (2004, p. 42), uma maneira prática de
o usuário memorizar esta configuração é associar o 0 (zero) à letra O de OUT (saída) e o 1 (um) à
letra I de INPUT (entrada).
O pino 0 da port0 está associado a um bloco chamado “Edge Detector”, responsável por
ativar uma interrupção caso seja detectada uma borda de subida ou descida nesse pino, conforme
configurado no registrador mcu_config .
59
Temporizador
O µBIP possui um temporizador de 16 bits com prescaler. Os registradores utilizados pelo
temporizador são: (i) trm0_config , que contem a configuração do prescaler nos bits (0 a 2); e (ii )
tmr0_value , que contem o valor atual do contador. Por ser um contador de 16 bits, o estouro do
temporizador ocorre a cada 65.536 ciclos, porém o usuário pode multiplicar o período de estouro do
temporizador utilizando o prescaler conforme a Tabela 8. A cada estouro do temporizador é gerada
um sinal de interrupção.
Tabela 8. Configuração do prescaler no registrador tmr0_config
Prescaler Escala Ciclos para um estouro 000 1:1 65.536 001 1:2 131.070 010 1:4 262.140 011 1:8 524.280 100 1:16 1.048.560 101 1:32 2.097.120 110 1:64 4.194.240 111 1:128 8.388.480
Controlador de Interrupções (IC)
O controlador de interrupções do µBIP possui apenas duas entradas de interrupção
associadas: (i) Interrupção por detecção de borda no pino 0 da port0; e (ii ) Estouro do temporizador.
As interrupções recebidas pelo IC são armazenadas em suas posições correspondentes no
registrador int_status e caso esteja ativado (=1) o bit correspondente no registrador
int_config , é gerada uma interrupção para a CPU e o controle fica aguardando o sinal de ACK.
Esse sistema é semelhante ao utilizado nos microcontroladores PIC® (MICROCHIP, 2001). A
Figura 22 apresenta um fluxograma do funcionamento do Controlador de Interrupções,
Como mostra a figura, na recepção de uma interrupção pelo controlador, é verificado
primeiramente se a chave geral de interrupções está ativa. Se sim, então é verificado se a chave
individual está ativa também e, caso seja positivo, então é enviada uma interrupção à CPU.
No atendimento de uma interrupção, o controlador desabilita temporariamente a chave geral
para impedir que ocorram novas interrupções. Sempre que ocorre uma interrupção, a CPU salva o
contexto (registrador PC) na pilha e redireciona o PC para o endereço 0x001 da memória de
60
instruções, onde deve estar a rotina de tratamento de interrupções. O tratamento de prioridade de
interrupções e limpeza do flag do int_status deve ser feito manualmente pelo usuário dentro da
rotina de tratamento de interrupção. O retorno de uma interrupção acontece após a execução da
instrução RETINT.
Figura 22. Fluxo do Controle de Interrupção
Fonte: Adaptado de Souza(2004, p. 135);
Barramento de Dados e E/S
No µBIP, a integração dos periféricos com a CPU é realizada através de um barramento com
os seguintes grupos de vias: (i) addr : que possui o endereço de um registrador interno de um
periférico ou endereço de uma posição de memória; (ii ) din : possui o dado a ser escrito no
61
endereço indicado por addr ; (iii ) wr_data : permite a escrita do dado din no endereço addr ; (iv)
dout : é uma via individual por periférico que possui o dado a ser retornado para a CPU (na sua
entrada de dados, a CPU possui um multiplexador que escolhe o dado de entrada a partir do
endereço dado por addr) ; e (v) rd_data : que informa ao periférico para colocar no canal de saída
dout o conteúdo do registrador dado por addr .
A Figura 23 apresenta este cenário. Com esse sistema de barramento, o incremento de um
novo periférico implica apenas em adicionar uma via no multiplexador do barramento de dados
(chamado de Data Bus Mux).
Figura 23. Integração da CPU com os periféricos e Memórias.
62
3.4 IMPLEMENTAÇÃO DO µBIP NO ARCHC
Nesta seção, é apresentada a implementação da arquitetura do µBIP no ArchC visando
validar o conjunto de instruções e gerar automaticamente o montador, o ligador e o simulador ISA.
Como visto anteriormente, existem dois blocos principais no ArchC e eles são apresentados nas
subseções a seguir. Ao final, mostra-se um levantando das restrições dessa implementação.
3.4.1 Recursos da arquitetura
A implementação dos recursos da arquitetura foi realizada em um único arquivo nomeado
“ubip.ac”. O código fonte referente a este arquivo é apresentado na Figura 24. Uma das limitações
encontradas na implementação do modelo no ArchC está na declaração das memórias, pois é
permitida apenas a declaração de memórias orientadas a byte, sendo que na família BIP as
memórias são orientadas a palavra. Dessa forma, as memórias de dados e de instruções foram
declaradas contendo “4K” (linhas 3 e 4), ou seja 4Kbyte ou 2K-palavras. No trecho de código
apresentado, declaram-se também os principais registradores da arquitetura (linha 5), o tamanho da
palavra de 16 bits (linha 6) e a forma de ordenação dos bytes no formato big-endian (linha 9).
1 2 3 4 5 6 7 8 9 10 11
/********************** ubip.ac ******************* **/ AC_ARCH(ubip){ ac_mem memRAM:4K; //4Kbyte/2K-Words ac_mem memROM:4K; //4Kbyte/2K-Words ac_reg PC, ACC, STATUS; ac_wordsize 16; ARCH_CTOR(ubip) { ac_isa("ubip_isa.ac"); set_endian ("big" ); }; };
Figura 24. Implementação do µBIP no ArchC – Recursos da Arquitetura.
3.4.2 Arquitetura do conjunto de instruções
A implementação da arquitetura do conjunto de instruções (AC_ISA) foi realizada em
quatro arquivos (i) ubip_isa.ac , que contem informações sobre o conjunto de instruções e
codificação assembly; (ii ) ubip_isa.cpp , que contém o comportamento de cada instrução durante
o processo de simulação; (iii ) ubip_address.h , que contém algumas constantes utilizadas dentro
do arquivo ubip_isa.cpp ; e (iv) modifiers : que permite adicionar algumas funções para o
montador/ligador. A seguir são apresentados detalhamentos desses arquivos.
63
Arquivo ubip_isa.ac
Como mencionado, esse arquivo possui informações sobre o conjunto de instruções que são
relevantes tanto para a criação do montador e do ligador como também do simulador ISA. A Figura
25 apresenta parte do código deste arquivo e a numeração na lateral esquerda da figura é apenas
ilustrativa. Primeiramente, na linha 2 é definido o formato de instrução válido denominado
INS_FORMAT com os campos op de 5 bits e operand de 11, igualmente definidos na Figura 15.
Após definido o formato de instrução, são atribuídas todas as instruções válidas para este formato
como mostrado nas linhas 4 a 11.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
AC_ISA(ubip){ ac_format INS_FORMAT = "%op:5 %operand:11" ; //Formatos ac_instr<INS_FORMAT> hlt; // CONTROLE ac_instr<INS_FORMAT> sto, ld, ldi; //TRANSFERENCIA DE DADOS ac_instr<INS_FORMAT> add, addi, sub, subi; // ARITMÉTICA ac_instr<INS_FORMAT> beq, bne, bgt, bge, blt, ble , jmp; // DESVIOS ac_instr<INS_FORMAT> not, and, andi, or, ori, xor , xori ;// LÓGICA B. ac_instr<INS_FORMAT> sll, srl; // DESLOCAMENTO ac_instr<INS_FORMAT> stov, ldv; // VETORES ac_instr<INS_FORMAT> return, retint, call; // SUPORTE A PROCEDIMENTOS ac_asm_map ubipSFR { "" [0..2047] = [0..2047]; //Todas as posicoes de memoria "$" [0..2047] = [0..2047]; //Todas as posicoes de memoria "$port0_dir" = 1024; //Configuracao dos pinos de E/S "$port0_data" = 1025 ; //Valores dos pinos de E/S "$port1_dir" = 1026; //Configuracao dos pinos de E/S "$port1_data" = 1027; //Valores dos pinos de E/S "$tmr0_config" = 1040; //Configuracao do Preecaler do Timer0 "$tmr0_value" = 1041; //Valor do contador do Timer0 "$int_config" = 1056; //Configuracao das Interrupcoes "$int_status" = 1057; //Indica quais interrupcoes estao ativas "$mcu_config" = 1072; //Opcoes "$indr" = 1073; //Auxiliar para Vetores } ISA_CTOR(ubip) //--- FORMATO ASSEMBLY E OPCODE--- { sto.set_asm( "sto %ubipSFR" , operand); sto.set_asm( "sto %exp" , operand); sto.set_decoder(op=0x01); not.set_asm( "not" , operand=0); not.set_decoder(op=0x0F); beq.set_asm( "beq %addr(align)" , operand); beq.set_decoder(op=0x08); ... pseudo_instr ("psto %ubipSFR, %imm" ) //psto $port0_data, 0xAA { "ldi %1" ; "sto %0"; } ...
Figura 25. Implementação do µBIP no ArchC – ubip_isa.ac
64
A definição presente nas linhas 13 a 27 permite criar um conjunto de constantes que durante
o processo de montagem são substituídas pelos valores correspondentes. Esse recurso é utilizado
principalmente para declarar os registradores visíveis ao programador, como por exemplo, na linha
17, é definido que a constante $port0_dir refere-se ao endereço 1024. Já na linha 16, é definido
um intervalo de valores que permite que o usuário referencie posições de memória por um cifrão ($)
seguido pelo número decimal, como, por exemplo, $15.
Na linha 30, é definida a sintaxe assembly através da palavra reservada set_asm para a
instrução STO. Nela, o campo operand do formato de instrução é representado por uma constante
definida em $ubipSFR . Dessa maneira, as instruções reconhecidas pelo montador são, por
exemplo: STO $port0_data . Na linha 31, é feita uma sobrecarga de sintaxe, permitindo também
que o campo operand do formato seja um valor do tipo exp (pré-definido pelo ArchC) que aceite,
por exemplo, usar variáveis declaradas na seção .data, rótulos e constantes inteiras no formato
hexadecimal. Agora, o montador reconhece também as seguintes instruções: STO var1; STO
0x001 .
Na linha 32, é utilizada a instrução ArchC set_decoder para atribuir um valor a um dos
campos do formato de uma instrução. Nesta linha, o campo op do formato de instrução recebe a
constante indicada. Assim, a instrução assembly STO 0x04F atribui o valor 0x01 para o campo op
do formato e 0x04F para o campo operand .
Em instruções onde não há o operando explicito, como no caso da instrução NOT, o valor
campo operand é atribuído com zero como mostra a linha 34.
Como mencionado anteriormente o ArchC trata as memórias orientadas a byte e não a
palavras. Isso resultou em algumas funções extras para lidar com essa restrição. Uma dessas
funções, denominada align , está presente no arquivo modifiers e é utilizada para realinhar o
rótulo utilizado na instrução BEQ, considerando uma memória orientada a palavras.
Outro recurso disponível pelo ArchC e utilizado neste projeto são as pseudo-instruções. Esse
recurso permite declarar instruções assembly que durante o processo de montagem são substituídas
pelas instruções nativas da linguagem, conforme declarado. No projeto, esse recurso foi utilizado
para mostrar a capacidade do ArchC e foram criadas apenas algumas pseudo-instruções. Em
destaque, nas linhas 40 a 44, é declarada a pseudo-instrução psto que permite carregar uma
65
constante em uma posição de memória de dados. Essa pseudo-instrução possui dois campos, um do
tipo $ubipSFR que indica a posição da memória de dados e outro imediato que contem o valor a
ser armazenado, e durante a montagem é substituída por duas instruções nativas: ldi %1 e
sto %0 . O termo %x, onde x é um número, é utilizado para referenciar a posição do campo da
pseudo-instrução.
Arquivo ubip_isa.cpp
Este arquivo possui informações sobre o comportamento das instruções e tem papel
fundamental na criação do simulador ISA. Além de funções que descrevem o comportamento das
instruções, foram criadas outras funções para auxiliar todo o processo. A Figura 26 apresenta
algumas das funções utilizadas para manipular as memórias de dados e de instruções devido à
limitação de endereçamento byte-a-byte. O termo AC_WORDSIZE é uma constante que possui a
quantidade de bits de uma palavra declarada previamente no arquivo ubip.ac .
Outra limitação presente na versão 2.0 do ArchC é que todos os recursos da arquitetura que
foram utilizados dentro de funções complementares devem ser passadas por parâmetro não tendo
acesso global a eles. A função DataMemoryRead , por exemplo, que recebe como parâmetro uma
memória e um endereço, calcula o endereço correspondente em uma memória byte-a-byte e retorna
a palavra.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
//================================================= ======= ac_word ProgramMemoryRead(ac_memory& memROM, unsigned mem_address ) { return memROM.read(mem_address*(AC_WORDSIZE/8)); }; //================================================= ======= ac_word DataMemoryRead(ac_memory& memRAM, unsigned mem_address ) { return memRAM.read(mem_address*(AC_WORDSIZE/8)); }; //================================================= ======= void DataMemoryWrite(ac_memory& memRAM, unsigned mem_address, ac_word datum ) { memRAM.write(mem_address*(AC_WORDSIZE/8), datum ); }; //================================================= ======= void set_PC(ac_reg< unsigned >&PC, unsigned value) { PC = value*(AC_WORDSIZE/8); }; //================================================= =======
Figura 26. Implementação do µBIP no ArchC – Funções Auxiliares (ubip_isa.cpp)
Outras funções auxiliares foram implementadas para separar e melhorar a visibilidade e
entendimento do código, como por exemplo, funções para setar os flags do registrador STATUS.
66
Na Figura 27 é apresentada a implementação do comportamento da instrução ADD. Essa
implementação demonstra o real comportamento da instrução. O primeiro operando da instrução é o
próprio acumulador (operando implícito) e o segundo é buscado na memória pelo endereço dado
pelo campo operand da instrução, a soma destes dois operandos é armazenada no acumulador. O
registrador STATUS é atualizado e o PC é incrementado. Em cada comportamento, é utilizada a
função myPrint para gerar e armazenar um log da simulação em um arquivo. É relevante notar que
as variáveis declaradas neste comportamento são do tipo ac_Sword , o qual representa um inteiro
de 16 bits com sinal. Na figura, as palavras STATUS, PC, ACC e memRAM referem-se aos mesmos
declarados no arquivo ubip.ac .
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
void ac_behavior( add ){ //Operantion ac_Sword operand1 = ACC.read(); ac_Sword operand2 = DataMemoryRead(memRAM,operand) ; ac_Sword result = operand1 + operand2; //Update ACC ACC.write(result); //Update Status Register set_status(STATUS, Z, check_zero(result)); set_status(STATUS, N, check_negative(result)); set_status(STATUS, C, check_carry_out(operand1, op erand2)); //Increment PC inc_PC(ac_pc); //Output information sprintf(strBuffer, "ACC=0x%04X+0x%04X", (ac_word)operand1, (ac_word)operand2 ); myPrint( "add" , operand, strBuffer); } void ac_behavior( call ) { //Operantion ac_word oldPC = get_PC(ac_pc)+1; STACK.push(oldPC); set_PC(ac_pc, operand); //Output information sprintf(strBuffer, "Stack.push(0x%04X)" , oldPC); myPrint( "call" , operand, strBuffer); }
Figura 27. Implementação do µBIP no ArchC – Comportamento (ubip_isa.cpp)
A Figura 27 apresenta também a implementação do comportamento da instrução CALL, o
que permite mostrar que há implementada uma estrutura de pilha que permite salvar e recuperar o
PC, no exemplo a instrução STACK.push(oldPC) armazena o valor oldPC no top da pilha. A
variável oldPC é igual ao valor do PC atual incrementado em uma unidade, ou seja, PC+1.
Neste arquivo, ainda estão presentes funções que simulam o comportamento de um
temporizador com prescaler e geração de interrupção. Ele também possui a funcionalidade de gerar
67
três arquivos de saída: (i) sim_result.txt , que contém todo o log de simulação ciclo-a-ciclo
apresentando dados dos principais registradores e movimentação na memória de dados, conforme
mostra o trecho da Figura 28; (ii ) sim_ports_result .txt , que contém todos os dados enviados
para as portas de E/S, ótimo para verificar resultados de testes; e (iii ) program1.vhd , que contém
a implementação da memória ROM do µBIP em VHDL com o código do programa simulado.
================ Simulation Start ================= Log save in: sim_result.txt ------------------- Data Memory ------------------- ----------------- Instruction Memory -------------- - | I[0000]=0x1A34 | I[0001]=0x0800 | I[0002]=0x88FF | I[0003]=0x0C01 | I[0004]=0x1000 | I[0005]=0xB808 | I[0006]=0x88FF | I[0007]=0x0C03 0x0000|0x1A34| ldi 0x234 # ACC=0x0234 operand |PC=0x0001|ACC=0x0234|Z=0x0|N=0x0|C=0x0|M[0x0 411]=0x0002 0x0001|0x0800| sto 0x000 # M[0x0000]=0x0234 |PC=0x0002|ACC=0x0234|Z=0x0|N=0x0|C=0x0|M[0x0 000]=0x0234|M[0x0411]=0x0003 0x0002|0x88FF| andi 0x0FF # 0x0234 and 0x00FF |PC=0x0003|ACC=0x0034|Z=0x0|N=0x0|C=0x0|M[0x0 411]=0x0004 0x0003|0x0C01| sto 0x401 # M[0x0401]=0x0034 |PC=0x0004|ACC=0x0034|Z=0x0|N=0x0|C=0x0|M[0x0 401]=0x0034|M[0x0411]=0x0005 0x0004|0x1000| ld 0x000 # ACC=M[0x0000]=0x0234 |PC=0x0005|ACC=0x0234|Z=0x0|N=0x0|C=0x0|M[0x0 411]=0x0006 0x0005|0xB808| srl 0x008 # ACC=0x0234>>0x0008 |PC=0x0006|ACC=0x0002|Z=0x0|N=0x0|C=0x0|M[0x0 411]=0x0007 0x0006|0x88FF| andi 0x0FF # 0x0002 and 0x00FF |PC=0x0007|ACC=0x0002|Z=0x0|N=0x0|C=0x0|M[0x0 411]=0x0008 0x0007|0x0C03| sto 0x403 # M[0x0403]=0x0002 |PC=0x0008|ACC=0x0002|Z=0x0|N=0x0|C=0x0|M[0x0 403]=0x0002|M[0x0411]=0x0009 0x0008|0x0000| hlt # ================== Simulation End ================= ------------------- Data Memory ------------------- | M[0000]=0x0234 | M[1025]=0x0034 | M[1027]=0x0002 | M[1041]=0x0009
Figura 28. Implementação do µBIP no ArchC – Arquivo de Simulação (ubip_isa.cpp)
Arquivo ubip_address.h
Este arquivo possui apenas constantes que são utilizadas dentro do arquivo ubip_isa.cpp
como, por exemplo, na Figura 27, são utilizadas as constantes Z, N e C definidas nesse arquivo.
modifiers
Conforme mencionado, são utilizados para realizar deslocamentos nos campos de formatos
de instruções como no caso de instruções de desvios que fazem uso para realinhar o endereçamento
dos rótulos para memórias baseadas em palavras.
68
3.4.3 Testes e Validações
A implementação do ArchC foi testada e validada utilizando as configurações de software
apresentadas no Apêndice D .A validação aconteceu de duas maneiras: (i) testes unitários; e (ii )
utilização de um testbench pré-definido. Ambos são apresentados nesta seção.
Testes Unitários
Os testes unitários tiveram como objetivo validar cada instrução do µBIP nas ferramentas do
ArchC (montador, ligador e simulador ISA). Para isso, foi realizado um levantamento identificando,
para cada instrução, o grupo de instruções necessárias para validá-la, bem como o estado esperado
para os registradores e para as memórias após a execução da instrução. Esse levantamento resultou
na tabela presente no Apêndice E .
Após levantamento, todos os testes foram transcritos para arquivos de código fonte e
submetidos ao montador e ao ligador. O arquivo gerado pelo ligador foi então foi submetido ao
simulador ISA e os relatórios da simulação foram analisados e comparados com os resultados
esperados. Esse processo é representado na Figura 29.
Figura 29. Implementação do µBIP no ArchC – Processo de Simulação
69
Validação usando o testbench
Em um segundo momento, os testes foram realizados utilizando um conjunto de aplicações
(testbench) disponibilizado na página do Dalton Project (THE DALTON PROJECT TEAM, 2001).
Trata-se de um conjunto de programas descritos em C++ que já foram utilizados para validar o
modelo de processador 8051 e outros processadores. Esse testbench é uma das alternativas
indicadas pelo desenvolvedores do ArchC (THE ARCHC TEAM, 2007a). A escolha por essas
aplicações de teste deveu-se à sua simplicidade para codificação na linguagem de montagem. Não
se poderia escolher um conjunto complexo já que a tradução da linguagem C++ para o assembly do
µBIP foi realizada manualmente. Essa “compilação manual” do testbench não levou em
consideração nenhuma otimização, apenas a conversão dos testes de maneira rápida e facilitada. A
Tabela 9 apresenta uma breve descrição de cada uma das aplicações do testbench, bem como a
quantidade de instruções assembly em cada arquivo.
Tabela 9. Descrição do testbench
Aplicação Descrição Número de instruções
cast Converte um número de 16 bits em dois de 8 bits 13
divmul Realiza uma seqüência de divisões e multiplicações 85
fib Série de Fibonacci 52
gcd Encontra o máximo multiplicador comum entre dois números 25
int2bin Transforma um número inteiro para binário 20
negcnt Realiza operações com números negativos 15
sort Realiza uma ordenação de vetor 99
sqroot Realiza cálculos de raiz quadrada 62
xram Realiza operações com todas as posições da memória 20
Após a “compilação manual” os testes prosseguiram o mesmo fluxo apresentado na Figura
29. Os resultados das simulações foram conferidos com os resultados esperados também
disponíveis em (THE DALTON PROJECT TEAM, 2001).
O gráfico apresentado na Figura 30 contém informações sobre o uso de cada instrução nas
aplicações do testbench. Como o pacote de testbench é composto por 9 aplicações de teste, logo o
valor máximo para cada instrução no gráfico é limitado em 9. Assim, pode-se notar que as
instruções LDI, LD, STO e HLT foram usadas em todos os testes, já as instruções RETINT,
XOR, XORI, OR e NOT não foram utilizadas nessas aplicações. Conforme tabela apresentada no
70
Apêndice F.10, em resumo, 82% de todo o conjunto de instruções foi validado pelo testbench
utilizado. As demais foram validadas apenas pelos testes unitários.
Utilização das instruções nos testbenchs
0 1 2 3 4 5 6 7 8 9
NOTOR
XORXORI
RETINT
BNEBLT
BLEANDORI
SRLBGT
ANDISLL
ADDSTOV
LDV
BEQBGE
SUBADDISUBI
RETURNCALL
JMPHLTSTO
LDLDI
Figura 30. Utilização das instruções nos testbenchs
3.4.4 Limitações
Nesta subseção são apresentadas as limitações do ArchC e da implementação do modelo. A
primeira delas, já discutida, refere-se ao fato do ArchC não utilizar tipos de memórias orientadas a
palavras e somente byte-a-byte. Isso levou a uma série de implementações descritas anteriormente.
Uma limitação da implementação do modelo deve-se à forma de utilização da seção .data
disponível no arquivo assembly aceito pelo montador. De uma forma geral, o montador gerado não
permite que as variáveis declaradas na seção .data sejam inicializadas. Este processo deve ser
feito na seção .text utilizando instruções de LDI e STO.
71
Outra limitação quanto ao modelo deve-se ao fato de que o simulador gerado pelo ArchC
serve apenas para simular o conjunto de instruções, estando incapacitado de gerar estímulos que
interajam com o simulador. A solução para este problema é a utilização do ARP (ArchC Plataform)
disponível em (THE ARCHC TEAM, 2007a). Porém, o seu uso está fora do escopo deste trabalho.
3.4.5 Considerações sobre o uso do ArchC como ferramenta de projeto arquitetural
O uso do ArchC nesse projeto teve dois pontos positivos. Primeiramente ele permitiu a
validação e revisão da arquitetura do modelo antes da sua implementação em VHDL. Conseguiu-se
verificar através do ArchC o funcionamento de cada instrução, a viabilidade da codificação
assembly para construções de programas além de madurecer as especificações iniciais do µBIP. Um
segundo ponto trata-se do benefício do ArchC em disponibilizar um conjunto de ferramentas
(montador, ligador e simulador) que incrementaram o valor final desse trabalho. As ferramentas
geradas pelo ArchC serão de grande uso para os usuários finais do µBIP tanto para estudo da
arquitetura e organização quanto para implementação de programas para µBIP.
A arquitetura proposta para o µBIP e a sua modelagem usando o ArchC foram apresentadas
no SIM 2008 (23th South Symposium on Microelectronics), sendo que um artigo foi publicado nos
anais do evento (PEREIRA; ZEFERINO, 2008).
3.5 IMPLEMENTAÇÃO DO MODELO VHDL
Esta seção tem por objetivo apresentar a implementação do modelo µBIP em VHDL e o seu
processo de validação.
Para a implementação do modelo, fez-se primeiramente um levantamento dos periféricos e
blocos existentes no modelo partindo de uma visão geral do microcontrolador final esperado e
aprofundando em detalhes e dividindo o modelo em blocos como mostra a Figura 31, ou seja, uma
visão top-down, onde aumenta-se o detalhamento a cada nível. Porém a implementação aconteceu
de forma inversa, ou seja, bottom-up dos blocos mais internos para os blocos mais externos. As
vantagens da implementação bottom-up são o reaproveitamento de blocos em módulos superiores e
a capacidade de se realizar o teste unitário de blocos internos antes da integração com outros
módulos.
72
operand 1 operand2
Function Unit
Operation
01
Extensão de
Sinal
ACCena
STATUSena
0
1
+
DecoderStack_wrStack_op
WrPC
WrACCSelA
SelB
SelCis_ vector
WrDataFU_Op
SourcePC
Opcode Z N C
PCena
STACK
013 2
IC
Program Memory
Addr Out_ Data
Data Memory
Wr Addr In_Data Out_Data
0x 001
0x 001
10
WrEn Op
Stack in
Stack out
Intr
SelA
WrACC
FU_Op
SelB
SelC
WrData
SFRs
data_out
data_in
wren
addr_in
Vector Access
da
ta_
inad
dr_
in
addr_out
is_vector
is_ vectorN Z
Z N
C
C
WrData
420 1 3
Indr
DatapathControl
CPU
1 19
2 20
3 21
4 22
5 23
6 24
7 25
8 26
9 27
10 28
11 29
12 30
13 31
14 32
15 33
16 34
17 35
18 36
µBIPµBIP+/-
ShiftLeft
ShiftRight
012
Operation
Operand1 Operand2
Z NC Result
Figura 31. Visão top-down do µBIP
A Figura 32 apresenta a hierarquia de arquivos desenvolvidos no projeto que são abordados
mais adiante e no Apêndice G .
A ferramenta utilizada para implementar e validar o modelo foi a Quartus II® – 7.2 SP3 da
fabricante ALTERA®. A escolha é pelo fato dessa ser a mesma ferramenta utilizada no LSED.
73
+ ubip
+ cpu
+ control
- stack
+ datapath
- alu
- ram
- rom
+ io_port
+ io_pin
- flip_flop_d_ena
- latch_d_ena
- timer
- interruptcontroller
- edge_detector
- databus
- frequencydivider
Figura 32. Hierarquia de arquivos VHDL
3.5.1 Testes e Validação
A validação do modelo VHDL aconteceu de duas formas. Primeiramente, cada bloco
implementado foi submetido à simulação para validar o seu funcionamento. Em um segundo
momento os blocos que foram integrados também foram validados para verificar seus
comportamentos após a integração. Neste documento, estão presentes apenas as validações
realizadas sobre o bloco de nível mais superior o “ubip.vhd ”.
A Figura 33 apresenta o diagrama de formas de onda da validação por simulação do modelo
VHDL do microcontrolador executando a aplicação cast.s, disponível no Apêndice F.1. Essa
aplicação carrega uma palavra de 16 bits no acumulador e depois separa os seus dois bytes,
escrevendo-os em duas portas de E/S diferentes. Na figura, destacam-se alguns pontos importantes:
1. O operando zero da instrução LDI (OPCODE = 0x03)é carregado no ACC (por default,
já inicializado em 0);
2. As portas de E/S (port0 e port1) são configuradas como saída;
3. O valor 0x1234, de 16 bits, é carregado no ACC por meio de três instruções (LDI , SLL e
ORI, de OPCODES 0x03, 0x16 e 0x13, respectivamente);
74
4. O byte menos significativo (0x34) é escrito na saída da port0;
5. É realizado o deslocamento de 8 bits para colocar o byte mais significativo nos bits de 7
a 0 do ACC; e
6. O byte mais significativo (0x12) é escrito na saída da port1.
Com esse teste foi possível validar as instruções utilizadas, bem como alguns blocos do
modelo, como por exemplo, as portas de E/S. A lista das instruções utilizadas também estão
disponíveis no Apêndice F.10.
Figura 33. Diagrama de formas de onda da simulação da execução da aplicação cast
Outro diagrama de forma de ondas é apresentado na Figura 34. Trata-se de um trecho da
execução do testbench fib.s, disponível no Apêndice F.3. Destacam-se alguns pontos importantes
nesta simulação (mostra-se uma região intermediária, dos instantes da execução):
1. O registrador de índice INDR é atualizado com o valor do acumulador (9);
2. A instrução LDV (OPCODE = 0x19) é utilizada para carregar um valor de memória,
dado pela posição do operando da instrução (4) mais o valor armazenado em INDR (9).
Logo, o acumulador é atualizado com o valor armazenado na posição 13 da memória de
dados, ou seja, 0x0037;
3. O valor do acumulador é escrito na port0;
75
4. Após a instrução JMP (OPCODE = 0x0E), é possível notar no registrador PC o desvio
para o valor do operando da instrução (0x0022);
5. Após a execução do BGE (OPCODE = 0x0B) com o flag Z do registrador STATUS setado
o registrador PC recebe o valor do operando da instrução evidenciando o desvio
condicional.
1 2 3 4 5
Figura 34. Diagrama de formas de onda da simulação da execução da aplicação fib
Um teste mais robusto foi realizado utilizando uma adaptação do exemplo disponível em
Souza (2004, p. 140 – 148) denominado “Exemplo 5 – Timer Simplificado”. Em resumo, trata-se de
um contador que, a cada segundo, apresenta em um display de 7-segmentos o valor do contador em
hexadecimal e utiliza de dois botões como entrada, um para ativar o contador e outro para paralisar
ou reiniciar o contador. Esse exemplo utiliza grande parte dos recursos utilizados pelo µBIP como
mostra a primeira parte da simulação na Figura 35.
76
1 2 4 65 97 8
3
Figura 35. Diagrama de formas de onda da simulação da execução da aplicação Exemplo 5 Parte-1
Na Figura 35 destacam-se os seguintes pontos:
1. Instrução JMP (OPCODE = 0x0E) no endereço 0x0000 para o endereço do rótulo
“main ”. Isto para preservar o endereço 0x0001 para tratamento das interrupções;
2. Configuração da port1 com todos os pinos como saída;
3. Configuração da port0 com todos os pinos como entrada;
4. Funcionamento do bloco de extensão de sinal de acordo com o bit 10;
5. Configuração do prescaler com valor 0x003 - 1:8, ou seja, a cada 8 pulsos o timer é
incrementado;
6. Habilitando apenas a interrupção do temporizador timer0;
7. Detectado uma borda de descida. Logo, é gerada uma interrupção;
77
8. A solicitação de interrupção do pino 0 da port0 é armazenada no registrador
int_status , porém o controlador de interrupção não gera uma interrupção à CPU pois
o bit correspondente no registrador int_config não está ativo; e
9. Ao contar até oito, o prescaler incrementa o registrador do temporizador.
1 2 3 4 5 6
Figura 36. Diagrama de formas de onda da simulação da execução da aplicação Exemplo 5 Parte-2
A Figura 36 apresenta um segundo trecho da simulação do exemplo prático. Na figura,
destacam-se os seguintes eventos:
1. O estouro do temporizador gera uma interrupção;
2. O controlador de interrupção identifica a interrupção gerada pelo temporizador como
válida e acrescenta no registrador interrupções pendentes25 (IPR , Interrupt Pending
Register) e ativa (=1) o bit correspondente (bit 0) no registrador int_status e gera
uma interrupção para a CPU;
25 Registrador interno do bloco do temporizador que contém o resultado da função: int_status AND int_config, ou seja, contem as interrupções que foram solicitadas e que estão ativas. Este registrador não está visível ao programador.
78
3. Após receber a interrupção do controlador de interrupção, a CPU transfere o PC para o
endereço de tratamento de interrupções (0x0001);
4. A flag de interrupção (int_stauts ) gerada pelo temporizador é limpa via software;
5. O contador do temporizador é inicializado com uma constante permitindo gerar
intervalos com mais precisão;
6. Após a instrução RETINT, a CPU continua seu processamento a partir do ponto de
parada.
As validações por diagrama de forma de ondas foram realizadas no simulador interno do
Quartus-II® utilizando como dispositivo de FPGA o modelo EPF10K70RC240-4 da família
FLEX10K. A escolha por este dispositivo deve-se ao fato da prototipação (etapa seguinte à
validação) ter sido realizada nesse modelo. A Tabela 10 apresenta o custo de área em FPGA para as
aplicações utilizadas no processo de validação. A variação do custo de células lógicas deve-se ao
tamanho do programa alocado na memória de programa (ROM) e dos recursos utilizados por este.
O fato do Exemplo 5 ser o que obteve maior consumo já era esperado, pois este é o que possui
maior quantidade de linhas de programa além de utilizar todos os recursos do µBIP. Para o modelo
de FPGA utilizado nesse projeto, o menor testbench, cast, utilizou aproximadamente 13% da área
de células lógicas disponíveis, já o maior testbench, Exemplo 5, utilizou aproximadamente 34%.
Tabela 10. Custo das Aplicações na FPGA FLEX10K-EPF10K70RC240-4
Aplicação Células Lógicas
Flip-flops LUTs LUTs/Flip-flops
Bits de Memória
cast 492 47 386 59 16384
divmul 1055 57 821 177 16384
fib 992 59 769 164 16384
gcd 805 46 616 143 16384
int2bin 686 41 537 108 16384
negcnt 513 50 408 55 16384
sort 1050 58 816 176 16384
sqroot 996 58 773 165 16384
xram 934 55 722 157 16384
Exemplo 5 1264 55 1019 190 16384
A Figura 37 apresenta o custo por bloco para a aplicação Exemplo 5 – Timer Simplificado.
Na figura é apresentado um comparativo com duas implementações distintas do bloco ROM: (i)
79
ROM em células lógicas, utilizando constantes; e (ii) ROM em bits de memória (uma área exclusiva
da FPGA) utilizando um modelo de memória próprio para a FPGA. Como a FPGA utilizada no
exemplo não possui uma área de “bits de memória” capaz de comportar as memórias de dados e
instruções, este espaço foi dividido entre as duas. Devido ao fato da organização do µBIP ser
monocíclico, quando o sistema é compilado utilizando ROM em células lógicas, o compilador é
capaz de reconhecer quais recursos do µBIP estão sendo utilizados pelo programa armazenado na
ROM e otimizar o hardware para isso. Já quando o sistema utiliza ROM em bits de memória a
quantidade de células lógicas utilizadas por cada bloco se mantém. Assim, se comparado a Tabela
10 é possível notar que em alguns testbenchs é vantajosa a utilização de ROM em células lógicas,
como por exemplo, o testbench cast que utiliza poucos recursos. Na figura também é possível notar
que em relação a ROM em células lógicas, o bloco que CPU é responsável por mais de 45% de toda
a área ocupada, porém do restante, 689 células lógicas, aproximadamente 44% são referentes ao
bloco de memória ROM onde está o programa.
1264 0 971 0+ cpu 575 0 589 0
+ control 231 0 246 0- stack 167 0 162 0
+ datapath 344 0 343 0- functionunit 253 0 253 0
- ram 0 16384 0 8192- rom 302 0 0 8192+ io_port0 52 0 54 0+ io_port1 53 0 53 0- timer 64 0 49 0- interruptcontroller 43 0 44 0- detector_edge 6 0 6 0- databus 133 0 142 0- frequencydivider 4 0 4 0
+ ubip
CélulasLógicas
Bits de Memória
ROM em Células Lógicas
ROM em Bits de Memória
BlocoCélulasLógicas
Bits de Memória
Figura 37. Custo por bloco da aplicação Exemplo 5
A Tabela 11 apresenta uma análise de período de clock e freqüência máxima para as
aplicações utilizadas na validação do modelo. Em resumo, o modelo possui um período de clock
médio de 146,120 ns e uma freqüência média de 6,873 MHz. Lembra-se que a variação do clock e
80
freqüência é determinada pela forma como foi implementado o modelo e que nesse trabalho não
foram realizados nenhuma otimização massiva nesse sentido.
Tabela 11. Análise de tempo na FPGA FLEX10K-EPF10K70RC240-4
Aplicação Período do clock (ns)
Freqüência (MHz)
cast 134,400 7,44
divmul 148,200 6,75
fib 143,800 6,95
gcd 148,200 6,75
int2bin 148,000 6,76
negcnt 125,400 7,97
sort 152,000 6,58
sqroot 153,600 6,51
xram 148,400 6,74
Exemplo 5 159.200 6.28
81
3.5.2 Prototipação Física
A prototipação física do modelo foi realizada utilizando o kit de prototipação UP-2 da
fabricante ALTERA® (Figura 38). Essa placa possui duas FPGA: (i) FLEX®10K:
EPF10K70RC240-4; e (ii) MAX®7000: EPM7128SLC84-7. Para a prototipação utilizou-se a
FPGA FLEX®10K nessa FPGA estão associados um dual-display de 7-segmentos, um seletor de 8
pinos, dois botões Push-Button e um oscilador de 25.175MHz. Maiores informações sobre o kit
utilizado estão disponíveis em ALTERA CORPORATION(2008).
A aplicação onde os resultados da prototipação são visíveis é o Exemplo 5- Timer
Simplificado de Souza(2004) principalmente por tratar de um exemplo típico de uso de
microcontroladores. Para esta aplicação foram utilizados: (i) display de 7-segmentos para mostrar o
contador; (i) dois botões para ativar e paralisar o timer; e (iii) um dos seletores para o botão de
reset. A configuração dos pinos para essa aplicação é apresentada na Tabela 12. Como mostra a
tabela, o µBIP utiliza 34 pinos sendo 32 deles para portas de E/S, um para o clock e outro para o
reset.
Figura 38. Kit de prototipação Altera® UP-2
Os resultados obtidos com a prototipação foram satisfatórios e confirmaram o
funcionamento do µBIP implementado nesse trabalho em um protótipo físico. Porém, não pode-se
considerar que o modelo tenha sido validado exaustivamente. Para isso seria necessário uma carga
82
horária maior destinada essa etapa. Pretende-se seguir realizando testes no protótipo físico durante o
mês de julho, a fim de confirmar ainda mais seu correto funcionamento.
Tabela 12. Configuração de pinagem para prototipação no kit UP-2
µBIP UP-2 µBIP UP-2
port0_data[15] port1_data[15] PIN_21
port0_data[14] port1_data[14] PIN_20
port0_data[13] port1_data[13] PIN_19
port0_data[12] port1_data[12] PIN_25
port0_data[11] port1_data[11] PIN_18
port0_data[10] port1_data[10] PIN_17
port0_data[9] port1_data[9] PIN_23
port0_data[8] port1_data[8] PIN_24
port0_data[7] port1_data[7] PIN_11
port0_data[6] port1_data[6] PIN_09
port0_data[5] port1_data[5] PIN_08
port0_data[4] port1_data[4] PIN_14
port0_data[3] port1_data[3] PIN_07
port0_data[2] port1_data[2] PIN_06
port0_data[1] PIN_29 port1_data[1] PIN_12
port0_data[0] PIN_28 port1_data[0] PIN_13
rst PIN_41 clk PIN_91
4 CONCLUSÕES
Neste trabalho foram apresentados o projeto e a implementação de um microcontrolador
básico planejado para uso em disciplinas introdutórias de programação de microcontroladores e
relacionadas ao projeto de sistemas digitais. Os resultados produzidos por esse trabalho foram: (i) a
especificação conceitual da arquitetura e organização de um microcontrolador com recursos
reduzidos; (ii) a criação de ferramentas de software (montador, ligador e simulador ISA) para o
microcontrolador produzido; (iii) a especificação em linguagem VHDL do microcontrolador; e (iv)
a síntese para FPGAs da Altera®.
Foram apresentados, também, uma revisão de conceitos base para a realização do projeto.
Foram feitos estudos teóricos sobre sistemas embarcados, arquitetura e organização de
computadores e microcontroladores, assim como estudos teórico-práticos sobre o uso do ArchC e a
modelagem do processador BIP II.
Destaca-se que foram encontradas algumas dificuldades relacionadas à instalação e uso do
ArchC devido a divergências de informações na documentação associada. Essas dificuldades foram
contornadas e as soluções encontradas foram registradas no guia de instalação e uso disponibilizado
no Apêndice D , onde é possível observar os passos realizados para instalação do ArchC e de suas
ferramentas de apoio, bem como os passos necessários para a geração de um simulador e montador
para uma dada arquitetura.
Destaca-se que foi apresentado e publicado nos anais do SIM 2008 (23th South Symposium
on Microelectronics) um artigo com o resumo desse trabalho e com os resultados alcançados com o
ArchC (PEREIRA; ZEFERINO, 2008). Outros dois artigos foram submetidos a dois eventos: (i)
CLEI 2008 – Conferência Latino-americana de Informática, Santa Fé – Argentina; e (ii) VIII
SFORUM, Gramado, RS – Brasil.
Entende-se que a relevância deste projeto está nos resultados obtidos, disponibilizando uma
arquitetura de microcontrolador pensada para facilitar o aprendizado da programação e da
implementação de microcontroladores. Além disso, busca-se promover uma maior integração entre
as disciplinas permitindo que os processadores da família BIP possam ser usados em diferentes
fases e disciplinas de cursos de graduação e de pós-graduação.
84
Entende-se, também, que este trabalho propiciou a este aluno a integração e consolidação de
conceitos estudados ao longo da graduação e, também, o aprendizado de novos conceitos e
tecnologias.
Por fim, destaca-se que os objetivos definidos para esse trabalho foram alcançados e
relatados nesse documento.
4.1 TRABALHOS FUTUROS
No desenvolvimento deste trabalho foram identificadas diversas oportunidades de trabalhos
co-relacionados a este e que dão continuidade a este projeto. Sendo:
• Compilador C: criação de um compilador da linguagem C para o assembly do µBIP;
• IDE de desenvolvimento: desenvolvimento de uma IDE que integre todas as ferramentas
geradas facilitando a utilização dessas pelos usuários; e
• Inclusão de novos periféricos;
• Sistema Operacional: implementação de um sistema operacional para o µBIP.
• Implementação do modelo em ASIC: implementação do modelo de microcontrolador
desenvolvido neste trabalho em um ASIC;
85
REFERÊNCIAS BIBLIOGRÁFICAS
ALTERA CORPORATION. University Program UP2 Education Kit User Guide. 2004. Disponível em: <http://www.altera.com/literature/univ/upds.pdf> Acesso em: maio/2008.
BALDASSIN, Alexandro. Geração automática de montadores em ArchC. 2005. Dissertação (Mestrado em Ciência da Computação)-Programa de Pós-Graduação em Ciência da Computação, Universidade Estadual de Campinas, Campinas, 2005.
BRITO, Alírio C. de. Considerações sobre a utilização de microcircuitos eletrônicos encapsulados em plástico nas aplicações de alta confiabilidade. 2003. Monografia (Especialização em Engenharia da Qualidade)–Escola Politécnica, Universidade de São Paulo, São Paulo, 2003.
BROWN, Stephen; VRANESIC, Zvonko. Fundamentals of Digital Logic with VHDL Design. New York: McGraw Hill. 2000.
CARRO, Luigi;WAGNER, Flávio R. Sistemas computacionais embarcados. In: XXII JORNADAS DE ATUALIZAÇÃO EM INFORMÁTICA , 2003. (Capítulo 2).
CARTER, Nicholas P. Teoria e problemas de arquitetura de computadores. Porto Alegre: Bookman, 2003.
D’AMORE, Roberto. VHDL: descrição e síntese de circuitos digitais. Rio de Janeiro: LTC, 2005.
FREESCALE SEMICONDUCTOR INC. M68HC08 microcontrollers. Arizona: Freescale, 2004.
GÜNTZEL, José L. Estilos de projeto. In: REIS, Ricardo A. da L (Org.). Concepção de circuitos integrados. 2. ed. Porto Alegre: Instituto de Informática da UFRGS: Sagra Luzzatto, 2002. (Capítulo 5).
GUPTA, Rajesh K.; ZORIAN, Yervant. Introducing Core-Based System Design. IEEE Design & Test of Computers, v. 14, n. 4, p. 15-25, dez 1997.
HENNESSY, John L.; PATTERSON, David A. Arquitetura de computadores: uma abordagem quantitativa. Rio de Janeiro: Campus, 2003.
HENZINGER, Thomas A; SIFAKIS, Joseph. The Discipline of Embedded Systems Design. Computer. v. 40, n.10, p. 32-40. out. 2007.
INTEL. 8-Bit Embedded Controllers. Arizona, 1991.
MARINHO, José E. S; MARINHO, Ednaldo S. Mini-curso de microcontrolador. Saber Eletrônica n° 2, jan. de 2001.
MATIC, Nebojsa. PIC Microcontrollers . 2000. Disponível em: <http://www.mikroe.com/en/books/picbook/0_Uvod.htm> Acesso em: 30 set 2007.
MELO, Paulo R. de S.; RIOS, Evaristo C. S. D.; GUTIERREZ, R. M. V. Componentes eletrônicos: perspectivas para o Brasil. BNDES Setorial, Rio de Janeiro, n. 13, p. 3-64, 2001.
86
MENDONÇA, Alexandre; ZELENOVSKY, Ricardo. Eletrônica digital: curso prático e exercícios. Rio de Janeiro: MZ, 2004.
MICROCHIP. PIC16F62X Data Sheet: FLASH-Based 8-Bit CMOS Microcontroller. Arizona, 2003.
MICROCHIP. PIC16F87X Data Sheet: 28/40-Pin 8-Bit CMOS FLASH microcontrollers. Arizona, 2001.
MICROCHIP. PIC18FXX2 Data Sheet: high performance, enhanced FLASH microcontroller with 10-Bit A/D. Arizona, 2002.
MORANDI, Diana ; PEREIRA, Maicon Carlos ; RAABE, André Luis Alice ; ZEFERINO, Cesar Albenes . Um processador básico para o ensino de conceitos de arquitetura e organização de computadores. Hífen, Uruguaiana, v. 30, p. 73-80, 2006.
MORANDI, Diana ; RAABE, André Luis Alice ; ZEFERINO, Cesar Albenes. Processadores para Ensino de Conceitos Básicos de Arquitetura de Computadores. In: WORKSHOP DE EDUCAÇÃO EM ARQUITETURA DE COMPUTADORES, 1., 2006, Ouro Preto. Proceedings of the 18th International Symposium on Computer Architecture and High Performance Computing - Workshops. Porto Alegre : SBC, 2006. p. 17-24.
PATTERSON, David A; HENNESSY, John L. Organização e projeto de computadores: a interface hardware/software. 2. ed. Rio de Janeiro: LTC, 2000.
PEREIRA, Maicon Carlos; ZEFERINO, Cesar Albenes. Architectural Specification of a Microcontroller by Using ArchC in: 23th South Symposium on Microelectronics – SIM2008, 2008. Bento Gonçalves. SIM 2008 Proceedings, 2008.
PREDKO, Michael. Handbook of microcontrollers. New York: McGraw-Hill, 1998.
RABBIT SEMICONDUCTOR. Rabbit 3000® Microprocessor User’s Manual. Califórnia, 2007.
REIS, André. Síntese lógica. In: REIS, Ricardo A. da L (Org.). Concepção de Circuitos Integrados, 2. ed. Porto Alegre: Instituto de Informática da UFRGS: Sagra Luzzatto: 2002. (Capítulo 7).
SHIVA, Sajjan G. Computer design and architecture. 3. ed. [S.l.]: Marcel: 2000.
SOUZA, Antonio H. de; NOVELETTO, Fabrício. Considerações sobre os microcontroladores. Disponível em: <http://www2.joinville.udesc.br/~esp7labmic/Material_HC08/artigo.doc> Acesso em: 20 set 2007.
SOUZA, José de S. Desbravando o PIC: ampliado e atualizado para PIC16F628A. 7 ed. São Paulo: Erica, 2004.
STALLINGS, William. Arquitetura e organização de computadores: projeto para o desempenho. 5. ed. São Paulo: Prentice Hall, 2002.
THE ARCHC TEAM. The ArchC architecture description language v2.0: reference manual. Campinas: The ArchC Team, 2007.
87
THE ARCHC TEAM. The ArchC project home page. Disponível em: < http://www.archc.org >. Acesso em: 15 out 2007a.
THE DALTON PROJECT TEAM. The UCR Dalton Project. University of California – Riverside, 2001. Disponível em: < http://www.cs.ucr.edu/~dalton/ >.
UYEMURA, John P. Sistemas digitais: uma abordagem integra. São Paulo: Pioneira Thomson Learning, 2002.
VAHID, Frank, GIVARGIS, Tony, Embedded sytem design: a unified hardware/software introduction. [S.l.]: John Wiley & Sons, Inc., 2002.
VAHID, Frank, GIVARGIS, Tony. Platform tuning for embedded systems design. IEEE Computer, v. 34, n. 3, p. 112-114, mar 2001
WEBER, Raul F. Fundamentos de arquitetura de computadores. 2. ed. Porto Alegre: Sagra–Luzzatto, 2004.
WOLF, Wayne. What is embedded computing? IEEE Computer, v. 35, n.1, p.136-137, jan 2002.
ZEFERINO, Cesar A. Especificação da Arquitetura e da Organização do Processador BIP. Itajaí, 2007. (Relatório Técnico).
APÊNDICES
A DESCRIÇÃO DO PROCESSADOR BIP-II EM ARCHC
Este apêndice apresenta os códigos da implementação funcional do processador BIP-II na
linguagem ARCHC realizada durante o projeto deste trabalho. As subseções a seguir apresentam os
arquivos de tais descrições.
A.1 RECURSOS DA ARQUITETURA AC_ARCH(bip2){ ac_mem memRAM:2K; ac_mem memROM:64k; ac_reg ACC; ac_reg Z, N; ac_wordsize 16; ARCH_CTOR(bip2) { ac_isa("bip2_isa.ac"); set_endian("big"); }; };
A.2 CONJUNTO DE INSTRUÇÕES AC_ISA(bip2){ ac_format Type_I = "%op:5 %operand:11"; ac_instr<Type_I> add, sub, addi, subi; ac_instr<Type_I> sto,ld,ldi; ac_instr<Type_I> hlt; ac_instr<Type_I> beq, bne, bgt, bge, blt, ble; ac_instr<Type_I> jmp; ISA_CTOR(bip2){ hlt.set_asm("hlt %imm", operand); hlt.set_decoder(op=0x00); sto.set_asm("sto %imm", operand); sto.set_decoder(op=0x01); ld.set_asm("ld %imm", operand); ld.set_decoder(op=0x02); ldi.set_asm("ldi %imm", operand); ldi.set_decoder(op=0x03); add.set_asm("add %imm", operand); add.set_decoder(op=0x04); addi.set_asm("addi %imm", operand); addi.set_decoder(op=0x05); sub.set_asm("sub %imm", operand); sub.set_decoder(op=0x06); subi.set_asm("subi %imm", operand);
90
subi.set_decoder(op=0x07); beq.set_asm("beq %imm", operand); beq.set_decoder(op=0x08); bne.set_asm("bne %imm", operand); bne.set_decoder(op=0x09); bgt.set_asm("bgt %imm", operand); bgt.set_decoder(op=0x0A); bge.set_asm("bge %imm", operand); bge.set_decoder(op=0x0B); blt.set_asm("blt %imm", operand); blt.set_decoder(op=0x0C); ble.set_asm("ble %imm", operand); ble.set_decoder(op=0x0D); jmp.set_asm("jmp %imm", operand); jmp.set_decoder(op=0x0E); }; };
A.3 COMPORTAMENTO DAS INSTRUÇÕES #include "bip2_isa.H" #include "bip2_isa_init.cpp" #include "bip2_bhv_macros.H" #include <stdio.h> #include <math.h> #include <stdarg.h> #include <systemc.h> //!'using namespace' statement to allow access to a ll bip2-specific datatypes using namespace bip2_parms; //!Behavior executed before simulation begins. void ac_behavior( begin ){ printf( "-- Inicio da Simulacao --\n" ); for ( unsigned int i=0; i< 20;i++) memRAM.write(i, 0); }; //!Behavior executed after simulation ends. void ac_behavior( end ){ printf( "-- Fim da Simulacao --\n" ); printf( "-- Resultado da memRAMoria --\n" ); //for (int i=0; i<pow(memRAM.get_size(),2);i++) for ( int i=0; i<30;i++) { printf( " memRAM[%d]=0x%x" , i, memRAM.read(i)); if (i%5==0) printf( "\n" ); } printf( "\n" ); };
91
//!Generic instruction behavior method. void ac_behavior( instruction ){ ac_pc = ac_pc + 2; }; //! Instruction Format behavior methods. void ac_behavior( Type_I ){ //Atualiza o Status //----------------------------- if (ACC.read()==0) Z.write(1); else Z.write(0); if (ACC.read()<0) N.write(1); else N.write(0); //--------------------------------- printf( "-----------------------------------------------\n" ); printf( "PC= 0x%x ACC = 0x%x Z=0x%x N=0x%x\n" , ac_pc-2, ACC.read(), Z.read(), N.read()); } //!Instruction add behavior method. void ac_behavior( add ){ printf( "ADD 0x%x + 0x%x\n" , ACC.read(), memRAM.read(operand) ); ACC.write(ACC.read()+(memRAM.read(operand)&0xFFFF) ); } //!Instruction sub behavior method. void ac_behavior( sub ){ printf( "SUB 0x%x + 0x%x\n" , ACC.read(), memRAM.read(operand) ); ACC.write(ACC.read()-(memRAM.read(operand)&0xFFFF) ); } //!Instruction addi behavior method. void ac_behavior( addi ){ printf( "ADDI 0x%x + 0x%x\n" , ACC.read(), operand ); ACC.write(ACC.read()+operand); } //!Instruction subi behavior method. void ac_behavior( subi ){ printf( "SUBI 0x%x + 0x%x\n" , ACC.read(), operand ); ACC.write(ACC.read()-operand); } //!Instruction sto behavior method. void ac_behavior( sto ){ printf( "STO 0x%x IN 0x%x\n" , ACC.read(), operand ); memRAM.write(operand, ACC.read()); printf( "memRAM[%d] = 0x%x\n" ,( int )operand,memRAM.read(operand)); } //!Instruction ld behavior method. void ac_behavior( ld ){ printf( "LD memRAM[%d] = 0x%x\n" , ( int )operand, memRAM.read(operand) ); ACC.write(memRAM.read(operand)); }
92
//!Instruction ldi behavior method. void ac_behavior( ldi ){ printf( "LDI 0x%x\n" , operand ); ACC.write(operand); } //!Instruction hlt behavior method. void ac_behavior( hlt ){ printf( "HLT\n" ); } //!Instruction beq behavior method. void ac_behavior( beq ){ printf( "BEQ 0x%x\n" , operand ); if (Z.read()==1) { ac_pc = operand; printf( "go to 0x%x\n" ,operand); } else { printf( "continue.\n" ); } } //!Instruction bne behavior method. void ac_behavior( bne ){ printf( "BNE 0x%x\n" , operand ); if (Z.read()==0) { ac_pc = operand; printf( "go to 0x%x\n" ,operand); } else { printf( "continue.\n" ); } } //!Instruction bgt behavior method. void ac_behavior( bgt ){ printf( "BGT 0x%x\n" , operand ); if ((N.read()==0)&&(Z.read()==0)) { ac_pc = operand; printf( "go to 0x%x\n" ,operand); } else { printf( "continue.\n" ); } } //!Instruction bge behavior method. void ac_behavior( bge ){ printf( "BGE 0x%x\n" , operand ); if (N.read()==0) { ac_pc = operand; printf( "go to 0x%x\n" ,operand); } else { printf( "continue.\n" ); } } //!Instruction blt behavior method. void ac_behavior( blt ){ printf( "BLT 0x%x\n" , operand ); if (N.read()==1) {
93
ac_pc = operand; printf( "go to 0x%x\n" ,operand); } else { printf( "continue.\n" ); } } //!Instruction ble behavior method. void ac_behavior( ble ){ printf( "BLE 0x%x\n" , operand ); if ((N.read()==1)&&(Z.read()==1)) { ac_pc = operand; printf( "go to 0x%x\n" ,operand); } else { printf( "continue.\n" ); } } //!Instruction jmp behavior method. void ac_behavior( jmp ){ printf( "JMP 0x%x\n" , operand ); ac_pc = operand; printf( "go to 0x%x\n" ,operand); }
B QUESTIONÁRIO
Este apêndice apresenta a pesquisa feita a professores, engenheiros e profissionais da área
sobre características básicas de um microcontrolador visando sua aplicação no âmbito educacional.
A seção mostra a carta de apresentação juntamente com o questionário enviado aos avaliadores. Já
a seção mostra o resultado da pesquisa.
B.1. CARTA DE APRESENTAÇÃO
Prezado(a) Sr(a),
Estamos realizando o projeto de uma arquitetura de microcontrolador para fins didáticos,
visando disponibilizá-la para uso no ensino em diversas disciplinas, incluindo: Programação,
Arquitetura de Computadores, Compiladores, Projeto de Sistemas Digitais, Microcontroladores,
entre outras.
O microcontrolador será baseado em uma arquitetura de processador denominada BIP -
Basic Instruction-set Processor, desenvolvida na UNIVALI. Como premissa, o BIP busca ser
simples o suficiente para que um aluno iniciante em Computação aprenda rapidamente a programá-
lo na sua linguagem de montagem, e também que um aluno com conhecimentos de circuitos digitais
e de uma linguagem de descrição de hardware consiga modelá-lo e prototipá-lo em FPGA.
O microcontrolador proposto será denominado uBIP (micro BIP) e deverá ter o mesmo foco
do BIP: facilitar o aprendizado de conceitos básicos de programação e de projeto, considerando as
aplicações básicas mais comuns de microcontroladores. A sua primeira versão será desenvolvida no
1o semestre de 2008, por um aluno de TCC do Curso de Ciência da Computação da UNIVALI,
que utilizará ferramentas e tecnologias como ArchC (www.archc.org), VHDL e FPGA.
Inicialmente, será feita a especificação da arquitetura do microcontrolador, que será modelada no
ArchC. Essa ferramenta será usada para gerar um simulador de conjunto de instruções, um
montador e um ligador para o uBIP. Após, será feito o projeto de sua organização, a qual será
modelada em VHDL e prototipada em FPGA. Aplicativos de teste serão codificados em assembly e
usados para validar o protótipo físico usando kits de desenvolvimento para FPGA da Altera.
Estamos entrando em contato com professores e profissionais experientes no ensino e no uso
de microcontroladores para identificar características mínimas para o uBIP. Agradecemos se puder
95
colaborar com essa pesquisa respondendo às perguntas abaixo, o que deverá lhe consumir poucos
minutos.
Pedimos que, ao responder, considere as aplicações tipicamente utilizadas nas fases iniciais
de aprendizagem de microcontroladores, identificando os requisitos de software e de hardware
dessas aplicações. Por favor, envie suas respostas a [email protected] ou realizando um reply a
esta mensagem.
Desde já agradecemos a sua ajuda.
Cordialmente,
Cesar Zeferino
PS: Se possível, agradecemos o reencaminhamento desta mensagem a conhecidos que
possam colaborar neste projeto.
Questionário de Levantamento de Requisitos para o µBIP
IDENTIFICAÇÃO
Nome: _______________________________________
Universidade/Empresa: _______________________________________
Cargo/Função: _______________________________________
Tempo de experiência no ensino/projeto baseado em microcontroladores: _____
QUESTIONÁRIO
1. Além das instruções aritméticas, de transferência com a memória e de desvio condicional
e incondicional (já disponíveis no BIP), que classes de instrução você considera mais relevantes
para a construção de aplicações básicas (o conjunto de instruções uBIP terá no máximo 32
instruções)?
- Lógica booleana: ( ) Sim ( ) Não
- Deslocamento lógico: ( ) Sim ( ) Não
- Deslocamento aritmético: ( ) Sim ( ) Não
96
- Manipulação e teste de bit: ( ) Sim ( ) Não
- Ativação de modo sleep: ( ) Sim ( ) Não
- Outras, indique:
2. Que periféricos você acha que seriam necessário para um microcontrolador
mínimo?
- Pinos de E/S unidirecionais:
( ) Sim ( ) Não
Se sua resposta tiver sido Sim, indique quantos pinos:____
- Pinos de E/S bidirecionais:
( ) Sim ( ) Não
Se sua resposta tiver sido Sim, indique quantos pinos: ____
- Pinos de interrupção sensível à borda:
( ) Sim ( ) Não
Se sua resposta tiver sido Sim, indique quantos pinos: ____
- Pinos de interrupção sensível ao nível:
( )Sim ( ) Não
Se sua resposta tiver sido Sim, indique quantos pinos: ____
- Temporizador programável:
( ) Sim ( ) Não
Se sua resposta tiver sido Sim, indique quantos bits: ____
- Contador de pulsos:
( ) Sim ( ) Não
Se sua resposta tiver sido Sim, indique quantos bits: ____
- Temporizador Watchdog:
( )Sim ( ) Não
Se sua resposta tiver sido Sim, indique o intervalo mínimo de estouro: ____
97
- Prescaler para os temporizadores:
( ) Sim ( ) Não
- Conversor A/D:
( ) Sim ( ) Não
Se sua resposta tiver sido Sim, indique quantos bits: ____
- Porta de comunicação serial:
( ) Sim ( ) Não
Se sua resposta tiver sido Sim, indique qual tipo (ex. UART, I2C):
- Outros. Indique:
3. Considerando o objetivo do microcontrolador proposto, qual a sua opinião sobre a
inclusão de suporte a chamada de procedimentos (pilha e instruções do tipo call e return)?
( ) Essencial
( ) Importante, mas não essencial
( ) Dispensável para aplicações básicas
( ) Irrelevante
4. Sugestões/comentários:
98
B.2. TABULAÇÃO DOS RESULTADOS
A Tabela 13 apresenta o resultado da coleta dos dados realizada com o questionário
apresentado anteriormente. A coluna “sim” mostra a quantidade de amostras que responderam
“sim”. A coluna “não” apresenta a quantidade de respostas “não”. A coluna Opc apresenta a opção
mais escolhida e a coluna “%” apresenta a porcentagem favorável ao item em questão.
No item “Com.Serial?” as respostas do tipo de comunicação serial (1-UART 2-I2C 5-SPI)
são somatórias, assim uma resposta 6 significa que o pesquisado escolheu por UART e SPI.
Tabela 13. Tabulação dos Dados Coletados
Sim Não Opc % Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9Classes de Instruções
Logica Booleana 9 0 100% S S S S S S S S SDeslocamento Lógico 7 2 78% N S S S S S S S NDeslocamento Aritmético 3 6 33% N N S N N S N S NManipulação de bit 7 2 78% S S S N N S S S SAtivação do modo sleep 1 8 11% N S N N N N N N NOutras
PeriféricosE/S Unidirecionais? 5 4 56% N S S N S N N S S
Qtd E/S Unidirecionais 8 60% 8 8 8 4 4E/S bidirecionais? 7 2 78% S S S S N S S S N
Qtd E/S bidirecionais 8 43% 10 16 8 16 8 8 4Interrupção Borda? 7 2 78% S S N S N S S S S
Qtd Interrupção 1 57% ? 2 1 1 1 2 1Interrupção Nivel? 5 4 56% N N S N S S S S N
Qtd Interrupção 1 60% 2 1 1 1 2Temporizador? 9 0 100% S S S S S S S S S
Qtd bits temporizador 16 33% 3 13 16 8 16 16 ? 8 8Contador de Pulsos? 3 6 33% N S S N N S N N N
Qtd bits contador 16 33% 13 32 16Watchdog? 3 6 33% N N N N N S S S N
Tempo estouro 1ms 67% 1s 1ms 1msPrescaler? 5 4 56% N N S N N S S S SConversor A/D? 5 4 56% S S N N S S S N N
Qtd bits 8 40% 4 8 12 8 12Com. Serial? 7 2 78% N S S N S S S S S
1-UART 2-I2C 5-SPI 1 ? 1 3 6 1 3
Chamada de ProcedimentoOpniao: (1-4) 1 67% 2 1 1 2 1 2 1 1 1
C CONJUNTO DE INSTRUÇÕES DO µBIP
Este apêndice apresenta uma descrição mais detalhada do conjunto de instrução do µBIP. As
subseções o conjunto de instruções de cada classe de instrução.
C.1. CLASSE: CONTROLE HLT Halts
Sintaxe: HLT
Descrição: Desabilita a atualização do PC
Opcode: 00000
Status: Nenhum bit afetado
PC: Não é atualizado
Operação: Nenhuma operação é realizada
Exemplo: HLT
Antes da instrução: PC = 0x0100
Após a instrução: PC = 0x0100
C.2. CLASSE: ARMAZENAMENTO STO Store
Sintaxe: STO operand
Descrição: Armazena o conteúdo do ACC em uma posição da memória
indicada pelo operand .
Opcode: 00001
Status: Nenhum bit afetado
PC: PC ← PC + 1
Operação: Memory[operand] ← ACC
Exemplo: STO 0x0002
Antes da instrução: ACC = 0x0005
MEM[2] = 0x0000
Após a instrução: ACC = 0x0005
MEM[2] = 0x0005
100
C.3. CLASSE: CARGA LD Load
Sintaxe: LD operand
Descrição: Carrega um valor armazenado em uma posição de memória
indicado pelo operand para o registrador ACC .
Opcode: 00010
Status: Nenhum bit afetado
PC: PC ← PC + 1
Operação: ACC ← Memory[operand]
Exemplo: LD 0x0002
Antes da instrução: ACC = 0x0000
MEM[2] = 0x0005
Após a instrução: ACC = 0x0005
MEM[2] = 0x0005
LDI Load Immediate
Sintaxe: LDI operand
Descrição: Carrega o valor de um operando imediato para o registrador ACC
Opcode: 00011
Status: Nenhum bit afetado
PC: PC ← PC + 1
Operação: ACC ← operand
Exemplo: LDI 0x0005
Antes da instrução: ACC = 0x0000
Após a instrução: ACC = 0x0005
101
C.4. CLASSE: ARITMÉTICA ADD
Sintaxe: ADD operand
Descrição: O valor do registrador ACC é somado com o valor armazenado na
posição de memória indicado pelo campo operand e o resultado
armazenado no ACC .
Opcode: 00100
Status: Z, N e C são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC + Memory[operand]
Exemplo: ADD 0x0002
Antes da instrução: ACC = 0x0004
MEM[2] = 0x0003
Após a instrução: ACC = 0x0007
MEM[2] = 0x0003
ADDI Add Immediate
Sintaxe: ADDI operand
Descrição: O valor do registrador ACC é somado com o valor operando
imediato e o resultado armazenado no ACC .
Opcode: 00101
Status: Z, N e C são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC + operand
Exemplo: ADDI 0x0002
Antes da instrução: ACC = 0x0004
Após a instrução: ACC = 0x0006
102
SUB Subtract
Sintaxe: SUB operand
Descrição: O valor do registrador ACC é subtraído pelo valor armazenado na
posição de memória indicado pelo campo operand e o resultado
armazenado no ACC .
Opcode: 00110
Status: Z, N e C são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC - Memory[operand]
Exemplo: SUB 0x0002
Antes da instrução: ACC = 0x0004
MEM[2] = 0x0003
Após a instrução: ACC = 0x0001
MEM[2] = 0x0003
SUBI Subtract Immediate
Sintaxe: SUBI operand
Descrição: O valor do registrador ACC é subtraído pelo valor do operando
imediato e o resultado armazenado no ACC .
Opcode: 00110
Status: Z, N e C são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC - operand
Exemplo: SUBI 0x0002
Antes da instrução: ACC = 0x0004
Após a instrução: ACC = 0x0002
103
C.5. CLASSE: LÓGICA BOOLEANA NOT
Sintaxe: NOT
Descrição: Aplica o operador de “negação” lógico ao valor armazenado no
ACC e armazena o resultado no ACC.
Opcode: 01111
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← NOT (ACC)
Exemplo: NOT
Antes da instrução: ACC = 0x000F
Após a instrução: ACC = 0xFFF0
AND
Sintaxe: AND operand
Descrição: Aplica o operador “E” lógico entre o valor do registrador ACC e o
valor armazenado na posição de memória indicado pelo
operand . O resultado é armazenado no ACC .
Opcode: 10000
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC AND Memory[operand]
Exemplo: AND 0x0002
Antes da instrução: ACC = 0x00C4
MEM[2] = 0x0007
Após a instrução: ACC = 0x0004
MEM[2] = 0x0007
104
ANDI And Immediate
Sintaxe: ANDI operand
Descrição: Aplica o operador “E” lógico entre o valor do registrador ACC e o
valor do operando imediato. O resultado é armazenado no ACC .
Opcode: 10001
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC AND operand
Exemplo: ANDI 0x0003
Antes da instrução: ACC = 0x00C5
Após a instrução: ACC = 0x0001
OR
Sintaxe: OR operand
Descrição: Aplica o operador “OU” lógico entre o valor do registrador ACC
e o valor armazenado na posição de memória indicado pelo
operand . O resultado é armazenado no ACC .
Opcode: 10010
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC OR Memory[operand]
Exemplo: OR 0x0002
Antes da instrução: ACC = 0x0004
MEM[2] = 0x00C0
Após a instrução: ACC = 0x00C4
MEM[2] = 0x00C0
105
ORI Or Immediate
Sintaxe: ORI operand
Descrição: Aplica o operador “OU” lógico entre o valor do registrador ACC
e o valor do operando imediato. O resultado é armazenado no
ACC .
Opcode: 10011
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC OR operand
Exemplo: ORI 0x0002
Antes da instrução: ACC = 0x0004
Após a instrução: ACC = 0x0006
XOR
Sintaxe: XOR operand
Descrição: Aplica o operador “OU” lógico exclusivo entre o valor do
registrador ACC e o valor armazenado na posição de memória
indicado pelo operand . O resultado é armazenado no ACC .
Opcode: 10100
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC XOR Memory[operand]
Exemplo: XOR 0x0002
Antes da instrução: ACC = 0x0006
MEM[2] = 0x0004
Após a instrução: ACC = 0x0002
MEM[2] = 0x0004
106
XORI Xor Immediate
Sintaxe: XORI operand
Descrição: Aplica o operador “OU” lógico exclusivo entre o valor do
registrador ACC e o valor do operando imediato. O resultado é
armazenado no ACC .
Opcode: 10101
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC XOR operand
Exemplo: XORI 0x0002
Antes da instrução: ACC = 0x0006
Após a instrução: ACC = 0x0004
C.6. CLASSE: DESVIO BEQ Branch Equal
Sintaxe: BEQ operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA foi zero.
Opcode: 01000
Status: Nenhum bit é afetado
PC: Se (STATUS.Z=1) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BEQ 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0005
STATUS.Z = 1 STATUS.N = 0
Após a instrução: PC = 0x0002
107
BNE Branch Non-Equal
Sintaxe: BNE operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido diferente zero.
Opcode: 01001
Status: Nenhum bit é afetado
PC: Se (STATUS.Z=0) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BNE 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0006
STATUS.Z = 0 STATUS.N = 1
Após a instrução: PC = 0x0002
BGT Branch Greater Than
Sintaxe: BGT operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido maior que zero.
Opcode: 01010
Status: Nenhum bit é afetado
PC: Se (STATUS.Z=0) e (STATUS.N=0) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BGT 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0004
STATUS.Z = 0 STATUS.N = 0
Após a instrução: PC = 0x0002
108
BGE Branch Greater Equal
Sintaxe: BGE operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido maior ou igual
zero.
Opcode: 01011
Status: Nenhum bit é afetado
PC: Se (STATUS.N=0) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BGE 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0005
STATUS.Z = 1 STATUS.N = 0
Após a instrução: PC = 0x0002
BLT Branch Less Than
Sintaxe: BLT operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido menor que zero.
Opcode: 01100
Status: Nenhum bit é afetado
PC: Se (STATUS.N=1) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BLT 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0006
STATUS.Z = 0 STATUS.N = 1
Após a instrução: PC = 0x0002
109
BLE Branch Greater Equal
Sintaxe: BLE operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido menor ou igual
a zero.
Opcode: 01101
Status: Nenhum bit é afetado
PC: Se (STATUS.N=1) ou (STATUS.Z=1) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BLE 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0006
STATUS.Z = 0 STATUS.N = 1
Após a instrução: PC = 0x0002
JMP Jump
Sintaxe: JMP operand
Descrição: Atualiza o valor do PC com o valor do campo operand, ou
seja, realiza um desvio incondicional.
Opcode: 01110
Status: Nenhum bit é afetado
PC: PC ← endereço
Operação: Nenhuma Operação Realizada
Exemplo: JMP 0x0002
Antes da instrução: PC = 0x000A
Após a instrução: PC = 0x0002
110
C.7. CLASSE: DESLOCAMENTO LÓGICO SLL Shift Left Logical
Sintaxe: SLL operand
Descrição: Realiza o deslocamento lógico à esquerda no número de bits
informado pelo operand sobre o registrador ACC.
Opcode: 10110
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC << operand
Exemplo: SLL 0x0002
Antes da instrução: ACC = 0x0001
Após a instrução: ACC = 0x0004
SRL Shift Right Logical
Sintaxe: SRL operand
Descrição: Realiza o deslocamento lógico à direita no número de bits
informado pelo operand sobre o registrador ACC.
Opcode: 10111
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC >> operand
Exemplo: SRL 0x0002
Antes da instrução: ACC = 0x0004
Após a instrução: ACC = 0x0001
111
C.8. CLASSE: MANIPULAÇÃO DE VETOR LDV Load Vector
Sintaxe: LDV operand
Descrição: Carrega o valor armazenado no endereço dado por (operand +
INDR) para o registrador ACC.
Opcode: 11000
Status: Não afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← Memory[Operand + INDR]
Exemplo: LDI 0x0001
STO $indr
LDV $0
Antes da instrução: ACC = 0x0000 MEM[0]=0x0004
MEM[1]=0x0007
Após a instrução: ACC = 0x0007 MEM[0]=0x0004
MEM[1]=0x0007
STOV Store Vector
Sintaxe: STOV operand
Descrição: Armazena o valor do registrador ACC, no endereço dado por
(operand + INDR).
Opcode: 11001
Status: Não afetados por esta operação
PC: PC ← PC + 1
Operação: Memory[operand + INDR] = ACC
Exemplo: LDI 0x0001
STO $indr
LDI 0x0003
LDV $0
Antes da instrução: ACC = 0x0000 MEM[0]=0x0004
MEM[1]=0x0007
Após a instrução: ACC = 0x0007 MEM[0]=0x0004
MEM[1]=0x0003
C.9. CLASSE: SUPORTE A PROCEDIMENTOS CALL
Sintaxe: CALL operand
Descrição: Realiza uma chamada de procedimento para o endereço de
memória de instrução indicado pelo campo operand . Antes da
chamada, o endereço de retorno (PC + 1) é armazenado na pilha
(ToS) .
Opcode: 11100
Status: Não afetados por esta operação
PC: ToS ← PC+1
PC ← operand
Operação: Nenhuma operação realizada
Exemplo: CALL 0x00F0
Antes da instrução: PC = 0x00D3 ToS = 0xXXXX
Após a instrução: PC = 0x00F0 ToS = 0x00D4
RETURN Return
Sintaxe: RETURN
Descrição: Retorna da sub-rotina, recuperando o valor do PC armazenado na
pilha (ToS) . O procedimento chamado deve usar o ACC para
retornar um valor ao procedimento chamador.
Opcode: 11010
Status: Não afetados por esta operação
PC: PC ← ToS
Operação: Nenhuma operação realizada
Exemplo: RETURN
Antes da instrução:PC=0x00F0 ToS=0x00D3
ACC=Valor de Retorno
Após a instrução: PC=0x00D3 ToS=0xXXXX
ACC=Valor de Retorno
113
RETINT Return Interrupt
Sintaxe: RETINT
Descrição: Retorna de uma interrupção para o endereço do programa antes da
interrupção e habilita a interrupção geral.
Opcode: 11011
Status: Não afetados por esta operação
PC: PC ← ToS
Operação: Nenhuma operação realizada
Exemplo: RETINT
Antes da instrução: PC = 0x00F0 ToS = 0x00D3
Após a instrução: PC = 0x00D3 ToS = 0xXXXX
D INSTALAÇÃO DO ARCHC
Esse apêndice apresenta os passos realizados para instalação e configuração do ArchC
utilizando o sistema operacional Ubuntu 7 e também testado no Kubuntu 7. As subseções deste
apêndice são seqüenciais, assim, para realizar um procedimento da Subseção D.2., deve-se realizar
primeiro a D.1. Os links indicados neste apêndice foram acessados em 10 outubro de 2007 e
consideram as versões disponíveis na data ou versões compatíveis como o caso do pacote Binutils.
D.1. OBTENDO OS ARQUIVOS DE INSTALAÇÃO
1. Criar a seguinte arvore de diretório: /home/myuser/files
2. Baixar o ArchC 2.0: <http://downloads.sourceforge.net/archc/archc-2.0.tar.gz>
3. Descompactar o pacote ArchC em: /home/myuser/files/archc2
4. Baixar o SystemC 2.2.0: <http://www.systemc.org >
5. Descompactar o pacote SystemC em: /home/myuser/files/systemc
6. Baixar o TLM 1.0: < http://www.systemc.org >
7. Descompactar o pacote TLM em: /home/myusers/files/tlm
8. Baixar o pacote Binutils 2.16.1: < http://ftp.gnu.org/gnu/binutils/binutils-2.16.1.tar.gz >
9. Descompactar o pacote Binutils em: /home/myusers/files/binutils
10. Baixar o pacote GDB 6.7.: < http://ftp.gnu.org/gnu/gdb/gdb-6.7.tar.gz >
11. Descompactar o pacote GDB em: /home/myusers/files/gdb
12. Baixar o modelo exemplo MIPS-I em:
<http://downloads.sourceforge.net/archc/mips1-v0.7.8.tgz>
13. Descompactar o MIPS em: /home/myusers/files/mips
115
14. Baixar o Benchmark JPEG para o MIPS-I em:
<http://143.106.24.201/%7Earchc/files/benchmarks/bin/mips1/mediabench/jpeg-
mips1.tgz>
15. Descompactar em: /home/myusers/files/mips/jpeg
D.2. INSTALAR O SYSTEMC Os comandos a seguir são realizados no terminal:
1. Criar diretório para o SystemC:
mkdir /usr/local/systemc/
2. Acessar o pacote do SystemC:
cd /home/myuser/files/systemc
3. Criar diretório de instalação:
mkdir /home/myuser/files/systemc/objdir/
4. Acessar diretório de instalação:
cd /home/myuser/files/systemc/objdir/
5. Configurar a instalação:
../configure --prefix=/usr/local/systemc --with-s ystemc=
/home/myuser/files/systemc
6. Instalando, utilizar usuário root para os comandos a seguir:
make
make install
make check
Maiores informações sobre a instalação do SystemC, consultar manual no site <
http://www.systemc.org >
116
D.3. INSTALAR O ARCHC Os comandos a seguir são realizados no terminal:
1. Acessar o diretório do pacote ArchC:
cd /home/myuser/files/archc2
2. Configurando a instalação (comando único):
./configure
--with-binutils=/home/myuser/files/binutils
--with-gdb=/home/myuser/files/gdb
--with-systemc=/usr/local/systemc
--with-tlm=/home/myuser/files/tlm/tlm
--prefix=/home/myuser/files/archc2
3. Instalando:
make
make install
D.4. GERANDO O MONTADOR Os comandos a seguir são realizados no terminal:
1. Acessar o diretório do MIPS-I:
cd /home/myusers/files/mips
2. Cria diretório de instalação:
mkdir /home/myusers/files/mips/install-dir
3. Configurar a instalação do montador:
../archc2/bin/acbingen.sh –i/home/myusers/files/mip s/install-dir -
amips1_4 mips1.ac
117
D.5. UTILIZANDO O MONTADOR Os comandos a seguir são realizados no terminal:
1. Para utilizar o montador, primeiramente deve-se ter um arquivo que contenha o
assembly a ser montado.
2. Gerando um objeto a partir de um código assembly:
/home/myusers/files/mips/install-dir/bin/mips1_1-as –o ArquivoDeSaída.o
ArquivoASM.s
Este comando gera um objeto baseado no formato ELF. Para visualizar o conteúdo do objeto
utilize os comandos:
readelf –x1 ArquivoObjeto.o
readelf –x2 ArquivoObjeto.o
D.6. GERANDO O SIMULADOR Os comandos a seguir são realizados no terminal:
1. Acessar o diretório do MIPS-I:
cd /home/myusers/files/mips
2. Verificar parâmetros para a construção do simulador:
/home/myusers/files/archc2/ acsim --help
3. Gerar arquivos para configuração do simulador:
/home/myusers/files/archc2/ acsim mips1.ac -s
4. Instalando o simulador:
make –f Makefile.archc
5. Caso seja necessário desinstalar o simulador utilize:
make –f Makefile.archc distclean
118
D.7. UTILIZANDO O SIMULADOR Os comandos a seguir são realizados no terminal:
1. Simulando o arquivo objeto gerado pelo montador:
/home/myusers/files/mips/mips1.x
–load=/home/myusers/files/mips/install-dir/bin/ ArquivoDeSaida.o
D.8. UTILIZANDO O LIGADOR
O ligador é gerado juntamente com o montador conforme apresentado anteriormente. O
comando abaixo é utilizado para gerar o executável com o ligador:
/home/myusers/files/mips/install-dir/bin/mips1_1-ld –o ArquivoDeSaída.x
ArquivoASM.o –Ttext=0x00 –Tdata=0x00
119
E PLANO DE TESTE UNITÁRIO
Neste Apêndice está disponível o plano de teste utilizado para validar cada instrução do
conjunto de instruções do µBIP.
Resultado esperado após a seqüência de instruções
Arquivo Instrução Seqüência de instruções para o teste
PC ACC Z N Memória add_1.s ADD
ldi 0x001 sto $14 ldi 0x003 add $14
0x0004 0x0004 0x0 0x0 M[0x000E]=0x0001
addi_1.s ADDI ldi 0x003 addi 0x004
0x0002 0x0007 0x0 0x0
and_1.s AND ldi 0x00C sto $15 ldi 0x007 and $15
0x0004 0x0004 0x0 0x0 M[0x000F]=0x000C
andi_1.s ANDI ldi 0x00C andi 0x007
0x0002 0x0004 0x0 0x0
beq_1.s BEQ ldi 0x004 subi 0x004 beq __end ldi 0x055 __end:
0x0004 0x0000 0x1 0x0
beq_2.s BEQ ldi 0x005 subi 0x004 beq __end ldi 0x055 __end:
0x0004 0x0055 0x0 0x0
bge_1.s BGE ldi 0x004 subi 0x004 bge __end ldi 0x055 __end:
0x0004 0x0000 0x1 0x0
bge_2.s BGE ldi 0x005 subi 0x004 bge __end ldi 0x055 __end:
0x0004 0x0001 0x0 0x0
bge_3.s BGE ldi 0x004 subi 0x005 bge __end ldi 0x055 __end:
0x0004 0x0055 0x0 0x1
120
Resultado esperado após a seqüência de instruções
Arquivo Instrução Seqüência de instruções para o teste
PC ACC Z N Memória bgt_1.s BGT
ldi 0x004 subi 0x003 bgt __end ldi 0x055 __end:
0x0004 0x0001 0x0 0x0
bgt_2.s BGT
ldi 0x003 subi 0x003 bgt __end ldi 0x055__end:
0x0004 0x0055 0x0 0x0
bgt_3.s BGT ldi 0x004 subi 0x005 bgt __end ldi 0x055 __end:
0x0004 0x0055 0x0 0x1
ble_1.s BLE ldi 0x004 subi 0x004 ble __end ldi 0x055 __end:
0x0004 0x0000 0x1 0x0
ble_2.s BLE ldi 0x003 subi 0x004 ble __end ldi 0x055 __end:
0x0004 0xFFFF 0x1 0x0
ble_3.s BLE ldi 0x005 subi 0x004 ble __end ldi 0x055 __end:
0x0004 0xFFFF 0x0 0x1
btl_1.s BLT ldi 0x003 subi 0x004 blt __end ldi 0x055 __end:
0x0004 0xFFFF 0x0 0x1
btl_2.s BLT ldi 0x003 subi 0x003 blt __end ldi 0x055 __end:
0x0004 0x0055 0x0 0x0
121
Resultado esperado após a seqüência de instruções
Arquivo Instrução Seqüência de instruções para o teste
PC ACC Z N Memória btl_3.s BLT
ldi 0x005 subi 0x004 blt __end ldi 0x055 __end:
0x0004 0x0055 0x0 0x0
bne_1.s BNE ldi 0x004 subi 0x003 bne __end ldi 0x055 __end:
0x0004 0x0001 0x0 0x0
bne_2.s BNE ldi 0x003 subi 0x003 bne __end ldi 0x055 __end:
0x0004 0x0055 0x0 0x0
call_1.s CALL
ldi 0x003 sto $14 ldi 0x002 sto $15 call __sum addi 0x001 jmp __end __sum: ld $14 add $15 return __end:
0x000A 0x0006 0x0 0x0 M[0x000E]=0x0003 M[0x000F]=0x0002
htl_1.s HTL ldi 0x004 hlt ldi 0x055
0x0002 0x0004 0x0 0x0
jmp_1.s JMP ldi 0x004 jmp __end ldi 0x055 __end:
0x0003 0x0004 0x0 0x0
ld_1.s LD ldi 0x044 sto $15 ldi 0x055 sto $16 ld $15
0x0005 0x0044 0x0 0x0 M[0x000F]=0x0044 M[0x0010]=0x0055
ldi_1.s LDI ldi 0x055 0x0001 0x0055 0x0 0x0
not_1.s NOT ldi 0x00F not
0x0002 0xFFF0 0x0 0x1
122
Resultado esperado após a seqüência de instruções
Arquivo Instrução Seqüência de instruções para o teste
PC ACC Z N Memória ldv_1.s LDV .text
main: ldi 1 sto $2 sto $0 for: subi 2 bgt endfor ld $0 subi 1 sto $indr ldv $2 addi 1 sto $1 ld $0 sto $indr ld $1 stov $2 ld $0 addi 1 sto $0 jmp for endfor: ldi 0 sto $0 print: subi 2 bgt endprint ld $0 sto $indr ldv $2 sto $port0_data ld $0 addi 1 sto $0 jmp print endprint: hlt endmain:
0x001F 0x0001 0x0 0x0
M[0x0000]=0x0003 M[0x0001]=0x0003 M[0x0002]=0x0001 M[0x0003]=0x0002 M[0x0004]=0x0003
or_1.s OR ldi 0x008 sto $15 ldi 0x007 or $15
0x0004 0x000F 0x0 0x0 M[0x000F]=0x0000
ori_1.s ORI ldi 0x008 ori 0x007
0x0002 0x000F 0x0 0x0
123
Resultado esperado após a seqüência de instruções
Arquivo Instrução Seqüência de instruções para o teste
PC ACC Z N Memória retint_1.s RETI jmp __start
jmp __intr __start: ldi 0x000 sto $tmr0_config ldi 0x003 sto $int_config ldi 0x000 sto $tmr0_value volta: ld $110 subi 0x100 bne volta ld $110 jmp __end __intr: ld $110 addi 0x100 sto $110 retint __end:
0x0011 0x0100 0x0 0x0
M[t0con]=0x0003 M[intrc]=0x0003 M[tmr00]=0xXXXX
M[0x000A]=0x0100
return_1.s RETURN ldi 0x003 sto $14 ldi 0x002 sto $15 call __sum addi 0x001 jmp __end __sum: ld $14 add $15 return addi 0x055 __end:
0x000B 0x0006 0x0 0x0 M[0x000E]=0x0003 M[0x000F]=0x0002
sll_1.s SLL ldi 0x004 sll 0x001
0x0003 0x0004 0x0 0x0
srl_1.s SRL ldi 0x004 srl 0x001
0x0002 0x0002 0x0 0x0
xori_1.s XOR ldi 0x005 xori 0x00A
0x0002 0x000F 0x0 0x0
sto_1.s STO ldi 0x055 sto $15
0x0002 0x0055 0x0 0x0 M[0x000F]=0x0055
124
Resultado esperado após a seqüência de instruções
Arquivo Instrução Seqüência de instruções para o teste
PC ACC Z N Memória stov_1.s STO .text
main: ldi 1 sto $2 sto $0 for: #ld $0 subi 2 bgt endfor ld $0 subi 1 sto $indr ldv $2 addi 1 sto $1 ld $0 sto $indr ld $1 stov $2 ld $0 addi 1 sto $0 jmp for endfor: hlt endmain:
0x0013 0x0001 0x0 0x0
M[0000]=0x0003 M[0001]=0x0003 M[0002]=0x0001 M[0003]=0x0002 M[0004]=0x0003
sub_1.s SUB ldi 0x00A sto $15 ldi 0x00A sub $15
0x0004 0x0000 0x1 0x0 M[0x000F]=0x000A
sub_2.s SUB ldi 0x004 sto $15 ldi 0x005 sub $15
0x0004 0x0001 0x0 0x0 M[0x000F]=0x0004
sub_3.s SUB ldi 0x004 sto $15 ldi 0x003 sub $15
0x0004 0xFFFF 0x0 0x1 M[0x000F]=0x000A
subi_1.s SUBI ldi 0x002 subi 0x005
0x0002 0xFFFD 0x0 0x1
subi_2.s SUBI ldi 0x005 subi 0x002
0x0002 0x0003 0x0 0x0
subi_3.s SUBI ldi 0x005 subi 0x005
0x0002 0x0000 0x1 0x0
xor_1.s XOR ldi 0x005 sto $15 ldi 0x00A xor $15
0x0004 0x000F 0x0 0x0 M[0x000F]=0x0005
125
F TESTBENCH (DALTON-PROJECT)
Neste apêndice, estão disponíveis todos os códigos fontes em assembly dos testes realizados
a partir dos testbenchs apresentados por Dalton-Project. Ao final é apresentado uma tabela com os
resultados da simulação no ArchC do µBIP.
F.1. TESTE: CAST.S .data x : .word 0x00 .text __start: ldi 0 sto $port0_dir sto $port1_dir ldi 0x12 sll 8 ori 0x34 sto x andi 0xFF sto $port0_data ld x srl 8 andi 0xFF sto $port1_data __end: hlt
F.2. TESTE: DIVMUL.S .data x : .word 0x00 y : .word 0x00 q : .word 0x00 r : .word 0x00 p : .word 0x00 i : .word 0x00 .text jmp main #-------Funcao de Divisao divisao: ldi 0 #Inicia o contador com 0 sto $102 jmp div2 div1: ld $102 #incrementa o contador addi 1 sto $102 div2: ld $100 sub $101 sto $100 bge div1 ld $102 return
126
#-------Funcao Modulo modulo: ldi 0 #Inicia o contador com 0 sto $102 jmp mod2 mod1: ld $102 #incrementa o contador addi 1 sto $102 mod2: ld $100 sto $103 sub $101 sto $100 bge mod1 ld $103 return #--------Funcao Multiplicacao multiplicacao: ldi 0 sto $102 mult1: ld $101 subi 0 beq mult2 ld $102 add $100 sto $102 ld $101 subi 1 sto $101 jmp mult1 mult2: ld $102 return #--------Main main: ldi 0 sto $port0_dir sto $port1_dir ldi 134 sto x ldi 1 sto y ldi 0 sto i fori: ld i subi 12 bge endfor ld y addi 1 sto y ld i addi 1 sto i jmp fori endfor: ld x sto $100
127
ld y sto $101 call divisao sto q ld x sto $100 ld y sto $101 call modulo sto r ld q sto $100 ld y sto $101 call multiplicacao add r sto p ld q sto $port0_data ld r sto $port0_data ld p sto $port0_data while_true: #jmp while_true hlt
F.3. TESTE: FIB.S .data x :.word 0x00 n :.word 0x00 buf :.word 0x00 .text jmp main fib: ldi 2 sto x #i=2 ldi 0 sto $indr #indr=0 ldi 1 stov buf #buf[0] = 1 sto $indr stov buf #buf[1] = 1 fib1: ld x sub n bge fib2 # if ( i >= n) go to fib2 ld x subi 1 sto $indr ldv buf sto $102 # temp1 = buf[i-1] ld x subi 2 sto $indr ldv buf add $102 # ACC = buf[i-2] + temp1 sto $103 # temp2 = ACC ld x
128
sto $indr ld $103 stov buf # buf[i] = temp2 ld x addi 1 sto x # i = i + 1 jmp fib1 fib2: return #------------- PRINT FUNCTION print: ldi 0 #init i sto x print_fori: sub n bge print_endfori # if (i >= n) goto print_endfor i ld x sto $indr ldv buf sto $port0_data ld x addi 1 sto x jmp print_fori print_endfori: return main: ldi 0 sto $port0_dir ldi 10 sto n call fib call print while_true: #jmp while_true end: hlt
F.4. TESTE: GCD.S .data x : .word 0x000 y : .word 0x000 .text jmp main gcd: ld x sub y beq gcd_end blt gcd2 gcd1: sto x sto $port0_data jmp gcd gcd2: ld y sub x sto y sto $port1_data jmp gcd
129
gcd_end: ld x return main: ldi 0 sto $port0_dir sto $port1_dir ldi 47 sto x ldi 11 sto y call gcd sto $port1_data while_true: #jmp while_true hlt
F.5. TESTE: INT2BIN.S .data x : .word 0x00 i : .word 0x00 .text jmp main check: beq print0 ldi 1 print0: sto $port0_data return main: ldi 0 sto $port0_dir ldi 0xaa sto x ldi 1 sto i for: ld x and i call check ld i sll 1 sto i subi 0x100 bne for while_true: #jmp while_true end: hlt
F.6. TESTE: NEGCNT.S .data x : .word 0x000 .text ldi 0 sto $port0_dir ldi -960 sto x
130
for: ld i subi -950 bge endfor ld x andi 255 sto $port0_data ld x addi 1 sto x jmp for endfor: while_true: #jmp while_true hlt
F.7. TESTE: SORT.S .data i :.word 0 j :.word 0 n :.word 0 buf :.word 0,0,0,0,0,0,0,0,0,0 .text jmp main #------------- SORT FUNCTION sort: ldi 0 #init i sto i fori: ld i sub n bge endfori # if (i >= n) goto endfori ld i sto j # init j=i forj: ld j sub n bge endforj # if (j >= n ) goto endforj ld i sto $indr ldv buf sto $100 # $100 = buf[i] ld j sto $indr ldv buf sto $101 # $101 = buf[j] ld j addi 1 sto j # j++ ld $100 sub $101 ble forj # if ( buf[i] <= buf[j] ) goto forj ld $100 stov buf # buf[j] = buf[i]($100) ld i sto $indr ld $101 stov buf # buf[i] = buf[j]($101) jmp forj # goto forj
131
endforj: ld i addi 1 sto i # i++ jmp fori # goto fori endfori: ldi 0 sto $port0_data return #------------- PRINT FUNCTION print: ldi 0 #init i sto i print_fori: sub n bge print_endfori # if (i >= n) goto print_endfor i ld i sto $indr ldv buf sto $port0_data ld i addi 1 sto i jmp print_fori print_endfori: return #------------- MAIN main: ldi 0 sto $port0_dir ldi 10 sto n ldi 0 sto $indr ldi 19 stov buf # buf[0] = 19 ldi 1 sto $indr ldi 18 stov buf # buf[1] = 18 ldi 2 sto $indr ldi 17 stov buf # buf[2] = 17 ldi 3 sto $indr ldi 16 stov buf # buf[3] = 16 ldi 4 sto $indr ldi 15 stov buf # buf[4] = 15 ldi 5 sto $indr ldi 14 stov buf # buf[5] = 14 ldi 6 sto $indr ldi 13 stov buf # buf[6] = 13
132
ldi 7 sto $indr ldi 12 stov buf # buf[7] = 12 ldi 8 sto $indr ldi 11 stov buf # buf[8] = 11 ldi 9 sto $indr ldi 10 stov buf # buf[9] = 10 call sort call print while_true: #jmp while_true hlt end:
F.8. TESTE: SQROOT.S .data x :.word 0 y :.word 0 xx :.word 0 yy :.word 0 xx_yy :.word 0 sqrt_xx_yy :.word 0 .text jmp main # Square. square: sto $100 sto $101 call multiplication return multiplication: ldi 0 sto $102 mult1: ld $101 subi 0 beq mult2 ld $102 add $100 sto $102 ld $101 subi 1 sto $101 jmp mult1 mult2: ld $102 return sqroot: sto $110 ldi 1 sto $111 sto $112 sqr1: ld $111
133
sto $100 sto $101 call multiplication sub $110 beq sqr3 bgt sqr2 ld $111 sto $112 addi 1 sto $111 jmp sqr1 sqr2: ld $112 return sqr3: ld $111 return main: ldi 0 sto $port0_dir sto $port1_dir ldi 3 sto x # x = 3 ldi 4 sto y # y = 4 ld x call square sto xx # xx = x * x sto $port0_data ld y call square sto yy #yy = y * y sto $port1_data ld xx add yy sto xx_yy #xx_yy = xx + yy sto $port0_data call sqroot sto sqrt_xx_yy sto $port1_data hlt
F.9. TESTE: XRAM.S .text main: ldi 1 sto $2 # buffer[0] = 1 sto $0 # x = 1 for: subi 1021 # 1024 - 2($0 and $1) = 1022 bgt endfor # if (x >= 1022) goto endfor ld $0 subi 1 sto $indr ldv $2 addi 1 sto $1 # temp1 = buffer[i - 1] + 1 ld $0 sto $indr ld $1 stov $2 # buffer[i] = buffer[i - 1] + 1 ld $0 addi 1
134
sto $0 jmp for endfor: while_true: #jmp while_true hlt endmain:
F.10. RESULTADO DOS TESTES Instrução/
Testes cast divmul fib gcd int2bin negcnt sort sqroot xram Total
Executadas Total Ocorrência
HLT 1 1 1 1 1 1 1 1 1 9 9
STO 4 123 84 23 19 22 385 88 4086 4834 9 LD 1 131 69 15 16 31 471 93 4084 4911 9 LDI 2 7 6 3 7 2 25 11 1 64 9 ADD 0 14 8 0 0 0 0 23 0 45 3 ADDI 0 44 18 0 0 10 75 4 2042 2193 6 SUB 0 22 20 14 0 0 142 5 0 203 5 SUBI 0 40 16 0 8 11 0 51 2043 2169 6 BEQ 0 14 0 10 8 0 0 34 0 66 4 BNE 0 0 0 0 8 0 0 0 0 8 1 BGT 0 0 0 0 0 0 0 4 1022 1026 2 BGE 0 35 20 0 0 11 87 0 0 153 4 BLT 0 0 0 9 0 0 0 0 0 9 1 BLE 0 0 0 0 0 0 55 0 0 55 1 JMP 0 28 19 10 1 10 66 27 1021 1182 8 NOT 0 0 0 0 0 0 0 0 0 0 0 AND 0 0 0 0 8 0 0 0 0 8 1 ANDI 2 0 0 0 0 10 0 0 0 12 2
OR 0 0 0 0 0 0 0 0 0 0 0 ORI 1 0 0 0 0 0 0 0 0 1 1 XOR 0 0 0 0 0 0 0 0 0 0 0 XORI 0 0 0 0 0 0 0 0 0 0 0 SLL 1 0 0 0 8 0 0 0 0 9 2 SRL 1 0 0 0 0 0 0 0 0 1 1
STOV 0 0 10 0 0 0 100 0 1021 1131 3 LDV 0 0 26 0 0 0 120 0 1021 1167 3
RETURN 0 3 2 1 8 0 2 10 0 26 6 RETINT 0 0 0 0 0 0 0 0 0 0 0 CALL 0 3 2 1 8 0 2 10 0 26 6
Total Executadas:
13 465 301 87 100 108 1531 361 16342 19308
Total Utilizadas:
8 13 14 10 12 9 13 13 10 24
%Utilização do Conjunto de Instrução
27%
44% 48% 34% 41% 31% 44% 44% 34% 82%
135
G BLOCOS VHDL
Bloco: Frequency Divider (frequencydivider.vhd)
Comportamento: Implementação de um bloco que permite dividir o ciclo do clock em N
vezes. Utilizado quando o clock fornecido para o µBIP é maior que o permitido.
INTERFACE
clk_in IN Clock de entrada ao µBIP clk_out OUT Clock dividido conforme configuração
Bloco: Data bus mux (databusmux.vhd)
Comportamento: Implementação de um multiplexador que determina através de um
endereço qual dado que deve passar pelo barramento.
INTERFACE
target_addr IN Endereço do registrador ram_data IN Entrada do conteúdo da RAM port0_data IN Entrada do conteúdo da port0 port1_data IN Entrada do conteúdo da port1 tmr0_data IN Entrada do conteúdo do timer 0 intr_data IN Entrada do conteúdo do controlador de interrupção mcu_config_data IN Entrada do conteúdo do registrador mcu_config cpu_data OUT Saída com o conteúdo determinado pelo target_addr.
136
Bloco: Edge Detector(edge_detector.vhd)
Comportamento: Implementação de um bloco capaz de verificar a presença de uma
conforme configuração, se verificado gera uma interrupção. A configuração de Borda de Subida /
Borda de Descida é realizada através do endereço do registrador MCU_CONFIG no bit 0.
Registradores Internos: MCU_CONFIG(0)
INTERFACE
clk IN Entrada do clock rst IN Reseta o bloco quando em ‘1’ addr IN Barramento: Endereço din IN Barramento: Dado de entrada dout OUT Barramento: Dado de saída rd_data IN Barramento: Permita a leitura do registrador indicado por
addr wr_data IN Barramento: Permite a escrita do valor de din no endereço
indicado por addr pin IN Sinal a ser verificado a presença de borda intr OUT Interrupção gerada no caso de identificação de borda
137
Bloco: Interrupt Controller (interruptcontroller.vh d)
Comportamento: Implementação de um controlador responsável por gerenciar um conjunto
de interrupções e interromper a CPU quando necessário.
Registradores: int_config e int_status
INTERFACE
clk IN Entrada do clock rst IN Reseta o bloco quando em ‘1’ addr IN Barramento: Endereço din IN Barramento: Dado de entrada dout OUT Barramento: Dado de saída rd_data IN Barramento: Permita a leitura do registrador indicado por
addr wr_data IN Barramento: Permite a escrita do valor de din no endereço
indicado por addr irq IN Interrupt Request: Solicita ao controlador uma interrupção da
CPU. intr OUT Interrupção gerada no caso uma interrupção(irq) solicitada
esteja ativa.
138
Bloco: Timer (timer.vhd)
Comportamento: Implementação de temporizador que gera uma interrupção em intervalos
programados.
Registradores: trm0_config e tmr0_value
INTERFACE
clk IN Entrada do clock rst IN Reseta o bloco quando em ‘1’ addr IN Barramento: Endereço din IN Barramento: Dado de entrada dout OUT Barramento: Dado de saída rd_data IN Barramento: Permita a leitura do registrador indicado por
addr wr_data IN Barramento: Permite a escrita do valor de din no endereço
indicado por addr Intr OUT Interrupção gerada no caso do contador interno estourar.
Bloco: RAM (ram.vhd)
Comportamento: Implementação de uma memória do tipo RAM.
INTERFACE
clk IN Entrada do clock addr IN Endereço din IN Dado a ser escrito na memória de dados dout OUT Dado lido da memória de dados wren IN Permite a escrita de do dado (din) no endereço dado (addr).
139
Bloco: I/O Pin (io_pin.vhd)
Comportamento: Implementação um pino de interface externa bidirecional com seletor de
direção.
Registradores: bit especifico de portX_dir e portX_data
INTERFACE
clk IN Entrada do clock rst IN Reseta o bloco quando em ‘1’ data_bus_in IN Dado de entrada data_bus_out OUT Dado de saída rd_port IN Permite a leitura do registrador com o conteúdo da porta
quando configurada como entrada. rd_tris IN Permite a leitura do registrador tris (configuração da direção
da porta). wr_port IN Permite a escrita do valor de data_bus_in no pino quando
configurado com saída. wr_tris IN Permite escrever o valor de data_bus_in no registrador de
configuração da direção da porta. pin IN/OUT Representa o pino de interface externa.
140
Bloco: I/O Port (io_port.vhd)
Comportamento: Implementação de um vetor de I/O Pins, ou seja, uma porta de interface
externa bidirecional.
Registradores: portX_dir e portX_data
INTERFACE
clk IN Entrada do clock rst IN Reseta o bloco quando em ‘1’ addr IN Barramento: Endereço din IN Barramento: Dado de entrada dout OUT Barramento: Dado de saída rd_data IN Barramento: Permita a leitura do registrador indicado por
addr wr_data IN Barramento: Permite a escrita do valor de din no endereço
indicado por addr pin IN/OUT Representa os pinos de interface externa.
Bloco: ROM (rom.vhd)
Comportamento: Implementação de uma memória do tipo ROM.
INTERFACE
clk IN Entrada do clock addr IN Endereço da instrução. dout OUT Instrução lida pelo endereço.
141
Bloco: Pilha (stack.vhd)
Comportamento: Implementação de uma memória do tipo PILHA.
INTERFACE
clk IN Entrada do clock rst IN Reinicializa o bloco cmd_insert IN Comando para inserir o dado (data_in) na pilha cmd_remove IN Comando para remover o dado da pilha data_in IN Dado a ser inserido na pilha data_out OUT Retorno do topo da pilha
Bloco: FunctionUnit (functionunit.vhd)
Comportamento: Implementação da unidade funcional que comporta instruções aritméticas,
lógicas e de deslocamentos..
INTERFACE
operandA IN Operando operandB IN Operando operation IN Codigo da operação result OUT Resultado da operação status OUT Informação sobre os resultado.
142
Bloco: Datapath (datapath.vhd)
Comportamento: Implementação o cominho de controle da CPU do µBIP.
INTERFACE
clk IN Entrada do clock rst IN Reinicializa o bloco is_vector IN Indica que a instrução atual uso o modulo de manipulação de
vetores SelA IN Determina qual a origem do primeiro operando da unidade
funcional SelB IN Determina qual a origem do segundo operando da unidade
funcional wr_acc IN Habilita a escrita no registrador ACC wr_indr IN Habilita a escrita no registrador INDR operand IN Operando da instrução din IN Dado vindo da memória de dados ou SFR fu_op IN Indica a operação da unidade funcional addr OUT Endereço da memória de dados ou SFR dout OUT Dado de saída do datapath (ACC) status OUT Rediriciona as informações sobre o resultado da unidade
funcional
143
Bloco: Unidade de Controle (control.vhd)
Comportamento: Implementação o cominho de controle da CPU do µBIP.
INTERFACE
clk IN Entrada do clock rst IN Reinicializa o bloco intr IN Entrada da interrupção vinda do controlador de interrupções din IN Entrada da instrução vinda da ROM status IN Entrada das informações do resultado da unidade funcional,
para tomada de decisão referente a saltos. ack OUT Saída para o controlador de interrupção que informa-o o
recebimento da interrupção. is_vector OUT Indica que instrução irá utilizar o modulo de manipulação de
vetores SelA OUT Determina qual a origem do primeiro operando da unidade
funcional SelB OUT Determina qual a origem do segundo operando da unidade
funcional wr_acc OUT Habilita a escrita no registrador ACC wr_indr OUT Habilita a escrita no registrador INDR operand OUT Operando da instrução rd_data OUT Habilita a leitura na memória RAM ou SFR wr_data OUT Habilita a escrita na memória RAM ou SFR fu_op OUT Indica a operação da unidade funcional Addr OUT Endereço da memória ROM.
144
Bloco: CPU (cpu.vhd)
Comportamento: Implementação o cominho de controle e unidade de controle do µBIP.
INTERFACE
clk IN Entrada do clock rst IN Reinicializa o bloco intr IN Entrada da interrupção vinda do controlador de interrupções rom_din IN Entrada da instrução vinda da ROM cpu_din IN Entrada de dados da memória de dados ou SFR ack OUT Saída para o controlador de interrupção que informa-o o
recebimento da interrupção. rd_data OUT Habilita a leitura na memória RAM ou SFR wr_data OUT Habilita a escrita na memória RAM ou SFR cpu_dout OUT Dado de saída da CPU target_addr OUT Endereço do registrador ou posição de memória rom_addr OUT Endereço de instrução da memória ROM.
Bloco: µBIP (ubip.vhd)
Comportamento: Bloco que representa o µBIP, ou seja, contêm todos os outros blocos.
INTERFACE
clk IN Entrada do clock rst IN Reinicializa o bloco port0_data IN/OUT Pinos de Entrada e Saída da port0 port1_data IN/OUT Pinos de Entrada e Saída da port1
145
H REGISTRADORES
Este apêndice apresenta maiores informações sobre os registradores especiais do µBIP. As tabelas a seguir possuem o nome do registrador, seu endereço e uma descrição. Além dessas informações possui ainda informação quanto ao acesso: (i) R, bit somente para leitura (read); (ii) R/W, bit de leitura e escrita (read/write); e (iii) U para os bits não implementados (Unimplemented). Para alguns registradores é apresentado a nomenclatura por bit. A linha após a descrição do registrador é posição do bit.
Registrador: port0_dir Endereço: 0x400
Descrição:
Define quais pinos são saídas e quais pinos são entradas
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W
D0_15 D0_14 D0_13 D0_12 D0_11 D0_10 D0_9 D0_8 D0_7 D0_6 D0_5 D0_4 D0_3 D0_2 D0_1 D0_0
D0_X 0 = O pino é definido como saída. 1 = O pino é definido como entrada
Registrador: port0_data Endereço: 0x401 Descrição:
Possui os dados dos pinos de E/S da porta port0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W
P0_15 P0_14 P0_13 P0_12 P0_11 P0_10 P0_9 P0_8 P0_7 P0_6 P0_5 P0_4 P0_3 P0_2 P0_1 P0_0
Registrador: port1_dir Endereço: 0x402
Descrição:
Define quais pinos são saídas e quais pinos são entradas
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W
D1_15 D1_14 D1_13 D1_12 D1_11 D1_10 D1_9 D1_8 D1_7 D1_6 D1_5 D1_4 D1_3 D1_2 D1_1 D1_0
D1_X 0 = O pino é definido como saída. 1 = O pino é definido como entrada
Registrador: port1_data Endereço: 0x403 Descrição:
Possui os dados dos pinos de E/S da porta port0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W
P1_15 P1_14 P1_13 P1_12 P1_11 P1_10 P1_9 P1_8 P1_7 P1_6 P1_5 P1_4 P1_3 P1_2 P1_1 P1_0
146
Registrador: tmr0_config Endereço: 0x410
Descrição:
Registrador de configuração do timer 0, mais especificamente o prescaler do timer.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
U U U U U U U U U U U U U R/W R/W R/W
- - - - - - - - - - - - - PS2 PS1 PS0
Configuração do prescaler: PS2 PS1 PS0 0 0 0 = 1:1 0 0 1 = 1:2 0 1 0 = 1:4 0 1 1 = 1:8 1 0 0 = 1:16 1 0 1 = 1:32 1 1 0 = 1:64 1 1 1 = 1:128
Registrador: tmr0_value Endereço: 0x411 Descrição:
Possui o valor atual do contador interno do timer 0.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W
Registrador: int_config Endereço: 0x420
Descrição:
Registrador de configuração do controlador de interrupção. Indica quais interrupções estão habilitadas
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
U U U U U U U U U U U U U R/W R/W R/W
- - - - - - - - - - - - - EDIE T0IE GIE
GIE Chave geral de Interrupção - General Interrupt Enable 0 = Chave geral de interrupção desabilitada 1 = Chave geral de interrupção habilitada T0IE Interrupção de estouro do Timer 0 (tmr0) - Timer 0 Interrupt Enable 0 = Interrupção do Timer 0 desabilitada 1 = Interrupção do Timer 0 habilitada EDIE Interrupção externa no P0_0 - Edge detect Interrupt Enable 0 = Interrupção externa no P0_0 desabilitada 1 = Interrupção externa no P0_0 habilitada
147
Registrador: int_status Endereço: 0x421
Descrição:
Registrador que identifica as interrupções solicitadas
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
U U U U U U U U U U U U U U R/W R/W
- - - - - - - - - - - - - - EDIE T0IE
T0IF Identificação da Interrupção de estouro do Timer 0 (tmr0) - Timer 0 Interrupt Flag 0 = Não ocorreu interrupção 1 = Ocorreu interrupção do Timer 0 EDIF Interrupção por detecção de borda (P0_0)- Edge detect Interrupt Enable 0 = Não ocorreu interrupção 1 = Ocorreu interrupção externa no P0_0
Registrador: mcu_config Endereço: 0x430 Descrição:
Registrador de configuração geral do microcontrolador
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
U U U U U U U U U U U U U U U R/W
- - - - - - - - - - - - - - EDG
EDG Identifica a borda que gerará a interrupção externa no P0_0 0 = borda de descida
1 = borda de subida
Registrador: indr Endereço: 0x431
Descrição:
Possui o índice do vetor. Utilizado pelas instruções LDV e STOV
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W
148
Registrador: status Endereço: 0x432
Descrição:
Registrador que possui informações sobre o resultado da unidade funcional
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
U U U U U U U U U U U U U R R R
- - - - - - - - - - - - - C N Z
Z Indica que o resultado da unidade funcional é zero
0 = O resultado da unidade funcional é diferente de zero
1 = O resultado da unidade funcional é zero N Indica que o resultado da unidade funcional é um número menor que zero
0 = O resultado da unidade funcional é maior ou igual a zero
1 = O resultado da unidade funcional é menor que zero C Indica a ocorrência de carry-out/borrow na operação aritmética 0 = Não ocorreu um carry-out/borrow 1 = Ocorreu um carry-out/borrow
