UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 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

2 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 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

3 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. ii

4 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. iii

5 SUMÁRIO LISTA DE ABREVIATURAS...vii LISTA DE FIGURAS...ix LISTA DE TABELAS...x RESUMO...xi ABSTRACT...xii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA SISTEMAS EMBARCADOS Características de Sistemas Embarcados Projeto de Sistemas Embarcados Tecnologias de Processadores Embarcados Tecnologias de Circuito Integrado (CI) Tecnologias de Projeto Linguagem de descrição de hardware e VHDL ARQUITETURA E ORGANIZAÇÃO DE COMPUTADORES Arquitetura Organização PROCESSADOR BIP II Arquitetura do BIP II Organização do BIP II MICROCONTROLADORES Características de Microcontroladores ARCHC Recursos da Arquitetura (AC_ARCH) Arquitetura do Conjunto de Instruções (AC_ISA) DESENVOLVIMENTO ANÁLISE DE REQUISITOS ESPECIFICAÇÃO DA ARQUITETURA Tamanho da Palavra e Tipo de Dados iv

6 3.2.2 Espaços de Endereçamento Registradores Formatos de Instrução Modos de Endereçamento Conjunto de Instruções Resumo da Arquitetura µbip ESPECIFICAÇÃO DA ORGANIZAÇÃO IMPLEMENTAÇÃO DO µbip NO ARCHC Recursos da arquitetura Arquitetura do conjunto de instruções Testes e Validações Limitações Considerações sobre o uso do ArchC como ferramenta de projeto arquitetural IMPLEMENTAÇÃO DO MODELO VHDL Testes e Validação Prototipação Física CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS...85 A DESCRIÇÃO DO PROCESSADOR BIP-II EM ARCHC...89 A.1 RECURSOS DA ARQUITETURA A.2 CONJUNTO DE INSTRUÇÕES A.3 COMPORTAMENTO DAS INSTRUÇÕES B QUESTIONÁRIO...94 B.1. CARTA DE APRESENTAÇÃO B.2. TABULAÇÃO DOS RESULTADOS C CONJUNTO DE INSTRUÇÕES DO µbip...99 C.1. CLASSE: CONTROLE C.2. CLASSE: ARMAZENAMENTO C.3. CLASSE: CARGA C.4. CLASSE: ARITMÉTICA C.5. CLASSE: LÓGICA BOOLEANA C.6. CLASSE: DESVIO C.7. CLASSE: DESLOCAMENTO LÓGICO C.8. CLASSE: MANIPULAÇÃO DE VETOR C.9. CLASSE: SUPORTE A PROCEDIMENTOS D INSTALAÇÃO DO ARCHC D.1. OBTENDO OS ARQUIVOS DE INSTALAÇÃO D.2. INSTALAR O SYSTEMC v

7 D.3. INSTALAR O ARCHC D.4. GERANDO O MONTADOR D.5. UTILIZANDO O MONTADOR D.6. GERANDO O SIMULADOR D.7. UTILIZANDO O SIMULADOR D.8. UTILIZANDO O LIGADOR E PLANO DE TESTE UNITÁRIO F TESTBENCH (DALTON-PROJECT) G BLOCOS VHDL H REGISTRADORES vi

8 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 vii

9 ROM RF RNF RT RX SFR SMD SOP SPI TCC TOS TX UF ULA UNIVALI VHDL VHSIC VLSI Read Only Memory Requisito Funcional Requisito Não Funcional Register-Transfer Receptor Special Function Register Surface Mounted Devices Small Outline Package Serial Peripheral Interface Trabalho de Conclusão de Curso Top of Stack Transmissor Unidade Funcional Unidade Lógica Aritmética Universidade do Vale do Itajaí VHSIC Hardware Description Language Very High-Speed Integrated Circuits Very Large Scale Integration viii

10 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 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 Figura 36. Diagrama de formas de onda da simulação da execução da aplicação Exemplo 5 Parte Figura 37. Custo por bloco da aplicação Exemplo Figura 38. Kit de prototipação Altera UP ix

11 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-EPF10K70RC Tabela 11. Análise de tempo na FPGA FLEX10K-EPF10K70RC Tabela 12. Configuração de pinagem para prototipação no kit UP Tabela 13. Tabulação dos Dados Coletados...98 x

12 RESUMO PEREIRA, Maicon C. µbip: Microcontrolador básico para o ensino de Sistemas Embarcados. Itajaí, f. 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í, 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. xi

13 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 Instructionset 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. xii

14 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.

15 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ósgraduaçã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 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 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 2

16 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 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 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 partes: A metodologia adotada nesse Trabalho de Conclusão de Curso (TCC) é dividida em seis 3

17 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 4

18 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. 5

19 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;

20 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 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 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; 7

21 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. 8

22 Figura 1. Lançamento do produto x retorno financeiro Fonte: Carro e Wagner (2003) 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). 9

23 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 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 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 10

24 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)) 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 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. 11

25 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 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 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 12

26 previamente, e o projetista deve apenas posicionar alguns blocos e realizar o roteamento das interconexões. Exemplos de tecnologia ASIC incluem os Gate Arrays 1 e as Standard Cells 2. 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) 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 ; 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). 13

27 Figura 3. Visão abstrata da organização de uma FPGA Fonte: Adaptado de Brown e Vranesic (2000, p. 93) 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. Densidade Lógica Desempenho Custo Unitário Tempo de Prototipação Full-Custom Semi-Custom PLD Figura 4. Comparativo entre as Tecnologias de CI. Fonte: Adaptado de Güntzel (2002, p.81) 14

28 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 RT 3 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 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. 15

29 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) 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 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 16

30 abstração. Após a implementação, são aplicados tanto nos protótipos, quanto nos produtos fabricados 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 (VHSIC 4 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. 17

31 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 ), 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 Arquitetura Conjunto de Instruções Para o processador uma instrução é um arranjo de bits que indica uma seqüência de microoperaçõ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 dados 5 (também denominadas de carga e de armazenamento); (b) instruções lógicas 6 e aritméticas 7 ; (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 ) 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 ). 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. 18

32 Segundo Hennessy e Patterson (2003, p ), 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) 19

33 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 ). 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 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 ; 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 simples 8 (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 20

34 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) 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 ) 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 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 ; PATTERSON; HENNESSY, 2000, p. 375; WEBER, 2004, p ). 21

35 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 ; MENDONÇA; ZELENOVSKY, 2004, p ; WEBER, 2004, p. 253) Organização 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 ), 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 ; PATTERSON; HENNESSY, 2000, p ; 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 22

36 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 ; WEBER, 2004, p. 36) 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 ). 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üencial 9 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 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. 23

37 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 ; WEBER, 2004, p ). 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 Processador Memória Dados Memória Programa 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 ). 24

38 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): 25

39 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 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 a 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. 26

40 Tabela 1. Arquitetura do BIP II Tamanho da palavra de dados 16 bits Tipos de dados Inteiro de 16 bits com sinal a Tamanho da palavra de instrução 16 bits Formato de instrução Cód. Operação Operando Modos de endereçamento Registradores Classes de instrução Fonte: Adaptado de Morandi, Raabe e Zeferino (2006) Direto: o operando é um endereço da memória Imediato: o operando é uma constante ACC: acumulador PC: contador de programa STATUS: registrador de Status IR: registrador de instruções (depende da implementaçã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 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. 27

41 Tabela 2. Conjunto de instruções do BIP II Opcode Instrução Operação e atualização do PC HLT Desabilita atualização do PC PC PC STO operand Memory[operand] ACC PC PC LD operand ACC Memory[operand] PC PC LDI operand ACC operand PC PC ADD operand ACC ACC + Memory[operand] PC PC ADDI operand ACC ACC + operand PC PC SUB operand ACC ACC Memory[operand] PC PC SUBI operand ACC ACC operand PC PC BEQ operand BNE operand BGT operand BGE operand BLT operand BLE operand Se (STATUS.Z=1) então PC endereço Senão PC PC + 1 Se (STATUS.Z=0) então PC endereço Senão PC PC + 1 Se (STATUS.Z=0) e (STATUS.N=0) então PC endereço Senão PC PC + 1 Se (STATUS.N=0) então PC endereço Senão PC PC + 1 Se (STATUS.N=1) então PC endereço Senão PC PC + 1 Se (STATUS.Z=1) ou (STATUS.N=1) então PC endereço Senão PC PC JMP operand PC endereço Reservado para as futuras gerações Fonte: Adaptado de Zeferino (2007) 28

42 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. Control CPU Datapath Extensão de Sinal 1 ena 1 PC + 0 Decoder Opcode Branch WrPC SelA SelB WrAcc Op WrRam N Z Operand WrAcc SelA ena Op ACC +/ 1 Z N 0 SelB Instruction Addr Data Wr Addr In_Data Out_Data Program Memory Data Memory Figura 8. Organização do Processador BIP II Fonte: Adaptado de Zeferino (2007) 29

43 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 Mnemônico Entradas Saídas Opcode Z N Op SelA SelB WrACC WrRAM WrPC Branch HLT X X X XX X X STO X X X XX X LD X X X 00 X LDI X X X 01 X ADD X X ADDI X X SUB X X SUBI X X BEQ X X XX X BNE X X XX X BGT X XX X BGE X 0 X XX X BLT X XX X BLE X XX X X XX X X X XX XX X X JMP X X X XX X Reservado X X X X X X Fonte: Zeferino (2007) 30

44 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 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 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 31

45 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 oscilador 10 interno 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átil 11 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. 32

46 Á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 subrotina 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 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 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); 33

47 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) 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 estouro 12 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 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. 34

48 watchdog. Quando o contador desse temporizador estoura o seu limite de contagem, ele provoca a reinicialização do microcontrolador 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 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. 35

49 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 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 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) Microcontroladores Comerciais O objetivo desta subseção é apresentar um estudo comparativo de alguns modelos de microcontroladores comerciais, com foco naqueles mais utilizados no LSED 13, 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í) 36

50 Tabela 4. Características de Microcontroladores comerciais Modelo PIC 16F628 PIC 16F877 PIC 18F Rabbit 3000 MC68HC908QY4 Fabricante Microchip Microchip Microchip Intel Rabbit Semiconductor Motorola Freqüência Max. de Operação (MHz) Palavra de Dados (bits) Palavra de Instrução (bits) Variável (8, 16) Memória de Dados RAM (bytes) Até 64K externa Externa 128 Memória de Dados EEPROM (bytes) Externa - Memória de Instrução (palavra) FLASH 2K FLASH 8K FLASH ROM 4K + até 64K externa Externa FLASH 4K I/O Ports (Qtd) Comunicação Serial USART MSSP MSSP, UART UART, HDLC USART USART Timers (Qtd) 2/8-bit 2/8-bit 1/8-bits 2/16-bit 10/8-bit 2/16-bit 1/16-bit 1/16-bit 2/16-bits 1/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) Conversor A/D (Qtd/Bits) 0 8/10-bit 8/10-bit 0 0 4/8-bit Comparador (Qtd) 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) Arquitetura Interna Harvard Harvard Harvard Von Neumann Von Neumann RISC RISC RISC CISC CISC Fonte: Adaptado de Freescale (2004); Intel (1991); Microchip (2001); Microchip (2002); Microchip (2003); Rabbit Semiconductor (2007) Von Neumann CISC

51 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 ArchC O ArchC é uma Linguagem de Descrição de Arquitetura (Architecture Description Language, ADL) baseada no SystemC 14, 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 pipeline 15 ; 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.

52 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 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; 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. 39

53 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 endianness 17 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 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). 40

54 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 41

55 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; ISA_CTOR(bip2){ 10. hlt.set_asm("hlt %imm", operand); 11. hlt.set_decoder(op=0x00); sto.set_asm("sto %imm", operand); 14. sto.set_decoder(op=0x01); }; 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) 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. 42

56 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 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 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) 43

57 //!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 44

58 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)

59 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. 46

60 RNF04: O simulador de conjunto de instruções deverá ser implementado no ArchC 19. RNF05: O modelo sintetizável do µbip deverá ser implementado em VHDL 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 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 e Portanto, quanto aos aspectos de tamanho de palavra e tipo de dados, o µbip conserva aqueles utilizados no BIP II, apresentado anteriormente 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 (2 11 ) 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 ), 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. 47

61 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 ) 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. 48

62 Figura 14. Organização da Memória de E/S 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 Funcional 23 (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. 49

63 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 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 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). 50

64 Figura 16. Modo de endereçamento Indireto 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= 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 (2 5 ), 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. 51

65 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 HLT Desabilita atualização do PC PC PC STO operand Memory[operand] ACC PC PC LD operand ACC Memory[operand] PC PC LDI operand ACC operand PC PC ADD operand Z,N,C ACC ACC + Memory[operand] PC PC ADDI operand Z,N,C ACC ACC + operand PC PC SUB operand Z,N,C ACC ACC Memory[operand] PC PC SUBI operand Z,N,C ACC ACC operand PC PC BEQ operand BNE operand BGT operand BGE operand BLT operand BLE operand Se (STATUS.Z=1) então PC endereço Se não PC PC + 1 Se (STATUS.Z=0) então PC endereço Se não PC PC + 1 Se (STATUS.Z=0) e (STATUS.N=0) então PC endereço Se não PC PC + 1 Se (STATUS.N=0) então PC endereço Se não PC PC + 1 Se (STATUS.N=1) então PC endereço Se não PC PC + 1 Se (STATUS.Z=1) ou (STATUS.N=1) então PC endereço Se não PC PC

66 Tabela 5. Conjunto de instruções do µbip (continuação) Opcode Instrução Flags Operação e atualização do PC JMP operand PC endereço NOT Z,N ACC NOT(ACC) PC PC AND operand Z,N ACC ACC AND Memory[operand] PC PC ANDI operand Z,N ACC ACC AND operand PC PC OR operand Z,N ACC ACC OR Memory[operand] PC PC ORI operand Z,N ACC ACC OR operand PC PC XOR operand Z,N ACC ACC XOR Memory[operand] PC PC XORI operand Z,N ACC ACC XOR operand PC PC SLL operand Z,N ACC ACC << operand PC PC SRL operand Z,N ACC ACC >> operand PC PC STOV operand Memory[operand + INDR] ACC PC PC LDV operand ACC Memory[operand + INDR] PC PC RETURN PC ToS RETINT PC ToS CALL operand PC operand ToS PC 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 a Tamanho da palavra de instrução 16 bits Formato de instrução Modos de endereçamento Registradores Classes de instrução Cód. Operação Operando 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 ACC: acumulador PC: contador de programa STATUS: registrador de Status INDR: registrador de índice SP: apontador do topo da pilha 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 53

67 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 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. 54

68 addr_in data_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. 55

69 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

70 Stack n din wren 0 dout ena SP op - / + 1 Figura 20. Organização da Pilha 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 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. 57

71 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. 58

72 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 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: : : : : : : : 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 59

73 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 60

74 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. 61

75 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 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) /********************** 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 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. 62

76 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 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 { ""[ ] = [ ]; //Todas as posicoes de memoria "$"[ ] = [ ]; //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 63

77 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 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 64

78 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 //======================================================== 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. 65

79 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 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, operand2)); //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 66

80 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[0x0411]=0x0002 0x0001 0x0800 sto 0x000 # M[0x0000]=0x0234 PC=0x0002 ACC=0x0234 Z=0x0 N=0x0 C=0x0 M[0x0000]=0x0234 M[0x0411]=0x0003 0x0002 0x88FF andi 0x0FF # 0x0234 and 0x00FF PC=0x0003 ACC=0x0034 Z=0x0 N=0x0 C=0x0 M[0x0411]=0x0004 0x0003 0x0C01 sto 0x401 # M[0x0401]=0x0034 PC=0x0004 ACC=0x0034 Z=0x0 N=0x0 C=0x0 M[0x0401]=0x0034 M[0x0411]=0x0005 0x0004 0x1000 ld 0x000 # ACC=M[0x0000]=0x0234 PC=0x0005 ACC=0x0234 Z=0x0 N=0x0 C=0x0 M[0x0411]=0x0006 0x0005 0xB808 srl 0x008 # ACC=0x0234>>0x0008 PC=0x0006 ACC=0x0002 Z=0x0 N=0x0 C=0x0 M[0x0411]=0x0007 0x0006 0x88FF andi 0x0FF # 0x0002 and 0x00FF PC=0x0007 ACC=0x0002 Z=0x0 N=0x0 C=0x0 M[0x0411]=0x0008 0x0007 0x0C03 sto 0x403 # M[0x0403]=0x0002 PC=0x0008 ACC=0x0002 Z=0x0 N=0x0 C=0x0 M[0x0403]=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. 67

81 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 68

82 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 69

83 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. LDI LD STO HLT JMP CALL RETURN SUBI ADDI SUB BGE BEQ LDV STOV ADD SLL ANDI BGT SRL ORI AND BLE BLT BNE RETINT XORI XOR OR NOT Utilização das instruções nos testbenchs Figura 30. Utilização das instruções nos testbenchs 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. 70

84 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 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. 71

85 STACK Stack in Stack out WrEn Op Control CPU Extensão de Sinal Datapath µbip IC Intr 1 0 0x x ena PC Decoder Stack_wr Stack_op WrPC WrACC SelA SelB SelC is_ vector WrData FU_Op SourcePC Opcode Z N C Z N C WrData SelA WrACC ena FU_Op Indr addr_in ACC operand 1 operand2 Operation is_ vector is_vector Vector Access addr_out 4 Function Unit data_in 1 0 ena SelB STATUS N Z C WrData SelC addr_in data_in wren SFRs data_out Operand1 Operation +/- C Z N 2 1 Result 0 Shift Left Operand2 Shift Right Addr Out_Data Wr Addr In_Data Out_Data 9 27 Program Memory Data Memory 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. 72

86 + 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 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); 73

87 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; 74

88 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 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 ) 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

89 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; 76

90 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 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 pendentes 25 (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. 77