INTERFACE RECONFIGURÁVEL PARA ARQUITETURA PARALELA BASEADA EM PROCESSADOR EMBARCADO NIOS II

Transcrição

1 CENTRO UNIVERSITÁRIO POSITIVO NÚCLEO DE CIÊNCIAS EXATAS E TECNOLÓGICAS ENGENHARIA DA COMPUTAÇÃO INTERFACE RECONFIGURÁVEL PARA ARQUITETURA PARALELA BASEADA EM PROCESSADOR EMBARCADO NIOS II UNICENP / NCET Curitiba 2007

2 CENTRO UNIVERSITÁRIO POSITIVO NÚCLEO DE CIÊNCIAS EXATAS E TECNOLÓGICAS ENGENHARIA DA COMPUTAÇÃO INTERFACE RECONFIGURÁVEL PARA ARQUITETURA PARALELA BASEADA EM PROCESSADOR EMBARCADO NIOS II Antonio Edson Ceccon Monografia apresentada à disciplina de Projeto Final, como requisito parcial à conclusão do Curso de Engenharia da Computação. Orientador: Prof. Edson Pedro Ferlin UNICENP / NCET Curitiba 2007

3 TERMO DE APROVAÇÃO Antonio Edson Ceccon INTERFACE RECONFIGURÁVEL PARA ARQUITETURA PARALELA BASEADA EM PROCESSADOR EMBARCADO NIOS II Monografia aprovada como requisito parcial à conclusão do Curso de Engenharia da Computação do Centro Universitário Positivo, pela seguinte banca examinadora: Prof. Edson Pedro Ferlin (Orientador) Prof. Valfredo Pilla Jr. Prof. Mauricio Perreto Curitiba, 01 de Novembro de 2007.

4 AGRADECIMENTOS Gostaria de agradecer à minha família, que sempre esteve me apoiando, confiando e ajudando a superar todas as dificuldades durante esta jornada. Também gostaria de agradecer aos amigos, professores, colegas de trabalho, todos que fizeram parte desse período acadêmico da minha vida.

5 RESUMO Com a crescente demanda por capacidade de processamento em diversas áreas, as pesquisas na área de processamento paralelo são cada vez mais freqüentes. O processamento paralelo existe em sistemas com vários processadores operando simultaneamente sobre as mesmas tarefas. Para controlar o processamento há a necessidade de interfaces, o objetivo desse projeto é desenvolver uma interface por meio da computação reconfigurável, utilizandose FPGA (Field Programmable Gate Array), que é um dos tipos de dispositivos lógico programáveis, os quais permitem que o projeto seja implementado sem a necessidade de construção física dos componentes, aumentando a produtividade e a flexibilidade no desenvolvimento do projeto. A arquitetura do projeto é desenvolvida baseada no processador embarcado Nios II da Altera para uma arquitetura paralela reconfigurável aplicada a cálculo numérico. O projeto visa obter um ganho crescente de desempenho por meio de uma arquitetura padronizada e de menor custo de manutenção. A entrada de dados faz-se por meio de um computador, o qual possui um software para gerar as operações a serem processadas e software de comunicação para enviar as operações do computador para a máquina paralela. Quando as operações forem finalizadas os resultados serão enviados de volta para o computador. O transporte e controle do tráfego de informações são gerenciados pela interface desenvolvida neste projeto. Palavras-chave: Nios II, processador embarcado, VHDL, FPGA, processamento paralelo.

6 RECONFIGURABLE INTERFACE FOR PARALLEL ARCHITECTURE USING NIOS II EMBEDDED PROCESSOR ABSTRACT The increasing demand for processing power in several areas, made research in the parallel processing more intense. Control over that architecture is necessary and this project intends to develop an interface to a reconfigurable parallel machine based on the embedded Nios II processor which provide a powerful and robust platform for developing and implementing processing control and by combining logic, memory and configurable processor core, embedded processor FPGA solutions allow system designers to integrate an entire system on a single device. Nios II based interface utilize a reconfigurable computing component called FPGA (Field Programmable Gate Array), which is a kind of reconfigurable logic device. Data will flow from a microcomputer, which run a software called template generator and will go to the interface to be processed by the parallel machine. When processing finishes, data will flow from the parallel machine to the template generator, which show the processing results to the user. The main interface function is data flow and status control over the parallel machine. Key words: Nios II, embedded processor, VHDL, FPGA, parallel processing.

7 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS LISTA DE SÍMBOLOS INTRODUÇÃO CAPÍTULO INTRODUÇÃO AO PROJETO Motivação Contextualização Principais Funcionalidades Tecnologia Utilizada CAPÍTULO FUNDAMENTAÇÃO TEÓRICA Teoria de Software Modelo de Software Embarcado Modelo de Fluxo de Dados Teoria de Hardware Modelo de Processamento Embarcado Linguagem para Descrição de Hardware Computação Reconfigurável Dispositivos Lógicos Programáveis...24 CAPÍTULO ESPECIFICAÇÃO DO PROJETO Análise de Contexto Descrição do Objeto do Desenvolvimento Descrição do Sistema Descrição das Interfaces Descrição das Restrições Descrição dos Benefícios Esperados Benefícios Operacionais Benefícios Estratégicos Descrição dos Impactos Esperados Impactos Institucionais Análise Funcional Funções de Comunicação Funções de Processamento de Informação Funções de Controle Automático Funções de Interface Homem/Máquina Funções de Aquisição de Dados Funções de Atuação Análise de Requisitos Funcionalidade Adequação Acurácia Interoperabilidade Conformidade...34 vii

8 Segurança Confiabilidade Maturidade Tolerância a Falhas Recuperabilidade Usabilidade Inteligibilidade Apreensibilidade Operacionalidade Eficiência Comportamento no Tempo Comportamento na Utilização de Recursos Mantenebilidade Analisabilidade Modificabilidade Estabilidade Testabilidade Análise de Arquitetura CAPÍTULO DESENVOLVIMENTO E IMPLEMENTAÇÃO Desenvolvimento da Interface de Controle Análise de Requisitos Requisitos de Hardware Requisitos de Firmware Requisitos de Software Desenvolvimento do Sistema de Hardware Processador Nios II Controlador SDRAM Controlador de Comunicação USB Controlador de LCD Temporizador Identificador do Sistema Interface Avalon MM Banco de Registradores Núcleo AP Desenvolvimento do Firmware Desenvolvimento do Software Recursos Necessários ao Desenvolvimento da Interface de Controle Quartus II SOPC Builder Nios II IDE Documentação Necessária Documentação do Processador Nios II Documentação de Periféricos Documentação da Ferramenta SOPC Builder Documentação da Ferramenta Nios II IDE Hardware Estudo e Aprendizagem Documentação Software Componentes de Eletrônicos FPGA Utilizada Kit Altera Seqüência de Desenvolvimento Prova de Conceito Construção do Sistema de Hardware JTAG UART Processador Nios II Controlador SDRAM...48 viii

9 Controlador de LCD Interface USB Temporizador Identificador do Sistema Interface Avalon MM Banco de Registradores Núcleo Costumizado Desenvolvimento do Firmware Desenvolvimento do Software Implementação do Projeto Construção do Sistema de Hardware Processador Nios II Controlador SDRAM Controlador de LCD Interface USB Temporizador Identificador do Sistema Banco de Registradores Núcleo AP Desenvolvimento do Firmware Desenvolvimento do Software...58 CAPÍTULO VALIDAÇÃO E RESULTADOS Validação do Protótipo Validação do Hardware Validação do Firmware Validação Funcional Resultados do Protótipo Problemas Encontrados no Desenvolvimento do Protótipo Validação do Projeto Validação do Hardware Validação do Firmware Validação do Software Validação Funcional Testes Realizados Testes de Hardware Testes de Firmware Testes de Software Resultados do Projeto Problemas Encontrados no Desenvolvimento do Projeto CAPÍTULO CONCLUSÃO...67 REFERÊNCIAS BIBLIOGRÁFICAS PÁGINAS DA INTERNET VISITADAS ANEXO - A DIAGRAMA DE CONEXÕES ENTRE INTERFACES...71 ANEXO - B SIMULAÇÃO DO FUNCIONAMENTO DA INTERFACE...72 ANEXO - C ix

10 MANUAL DO USUÁRIO...74 ANEXO - D MANUAL TÉCNICO...78 ANEXO - E CRONOGRAMA...80 ANEXO - F ESTUDO DE VIABILIDADE Instalações Recursos Humanos Recursos Financeiros Recursos Materiais Custos Diretos ANEXO - G - ARTIGO x

11 LISTA DE FIGURAS Figura 2.1: Exemplo de Grafo de Fluxo de Dados da Equação...20 Figura 2.2: Circuito Comparador Lógico Figura 2.3: Posicionamento da Computação Reconfigurável...23 Figura 2.4: Estrutura Interna em Blocos de um FPGA...25 Figura 3.5: Principais Módulos...26 Figura 3.6: Núcleo do Processador Nios II...28 Figura 3.7: Diagrama em Blocos da Interface Avalon...29 Figura 3.8: Interface Serial...29 Figura 3.9: Interface Processador-Máquina Paralela...30 Figura 3.10: Interface de Depuração JTAG...30 Figura 3.11: Diagrama de Blocos da Interface de Controle...37 Figura 4.12: Interface de Controle...39 Figura 4.13: Banco de Registradores...41 Figura 4.14: Diagrama da Estrutura de Comunicação USB...41 Figura 4.15: Diagrama do Fluxo de Processamento do Firmware Figura 4.15: Diagrama da Classe de Comunicação USB...43 Figura 4.17: Kit DE2 da Altera...46 Figura 4.18: Fluxo Para Desenvolvimento de Sistemas Nios II...47 Figura 4.19: Protótipo Utilizado Para Prova de Conceito...48 Figura 4.20: Subsistema Nios II...54 Figura 4.21: Tela Principal do Software...59 Figura 5.22: Desempenho do Subsistema Nios II...63 Figura 5.23: Desempenho do Processamento...64 Figura 5.24: Desempenho da Comunicação...64 Figura 5.25: Grafo da Equação de 2º Grau...65 Figura 5.26: Resultado do Cálculo da Equação de 2º Grau...66

12 Figura A.27: Conexões entre Interfaces...71 Figura B.28: Simulação do Funcionamento entre Interfaces...72 Figura B.29: Componente VHDL - Simulação do Funcionamento entre Interfaces...73 Figura C.31: Botão de programação do FPGA com o projeto aberto no Quartus II Figura C.32: Tela de programação do FPGA no Quartus II...76 Figura C.30: Tela principal do software Montador...76 Figura C.33: Tela de execução dos templates na máquina paralela...77

13 LISTA DE TABELAS Tabela 4-1: Lista de Comandos de Comunicação...42 Tabela 5-2: Resultados do protótipo Etapa I e Etapa II...61 Tabela 5-3: Template Gerado...65 Tabela E-4: Cronograma do Projeto...80 Tabela F-5: Materiais Disponibilizados - Resumo de Custos...84 Tabela F-6: Resumo de Custos Diretos do Projeto...84

14 LISTA DE SIGLAS E ABREVIATURAS ASIC Application-Specific Integrated Circuits. CPLD Complex Programmable Logic Device. EEPROM Electrically Erasable Programmable Read-Only Memory. EP Elemento Processador. EPROM Erasable Programmable Read-Only Memory. FIFO First In First Out. FPGA Field Programmable Gate Arrays. GAL Generic Array Logic. HDL Hardware Description Language. IDE Integrated Development Environment. IP Intellectual Property. JTAG Joint Test Action Group. MIF Memory Initialization File. PAL Programmable Array Logic. PLA Programmable Logic Array. PLD Programmable Logic Device. PLL Phased Locked Loop. PROM Programmable Read-Only Memory. RAM Read Only Memory. VHDL VHSIC Hardware Description Language. VHSIC Very High Speed Integrated Circuit. USB Universal Serial Bus.

15 LISTA DE SÍMBOLOS Hz MHz Vcc Vca Hertz. Mega Hertz. Volts Corrente Contínua. Volts Corrente Alternada.

16 INTRODUÇÃO Apesar do grande avanço na área de computadores, as arquiteturas reconfiguráveis possuem um grande campo de atuação na engenharia e nas ciências, pois existe uma necessidade crescente de poder computacional e flexibilidade que uma arquitetura reconfigurável pode proporcionar. Entre todos os campos de estudo associados com projeto de sistemas embarcados, as tecnologias de software e hardware, em particular dos processadores, são as que têm experimentado a evolução mais rápida (FERLIN, 2005). Em função dessa acelerada evolução tecnológica, a idéia de se utilizar estruturas abertas e reconfiguráveis que possam adaptar-se a novas demandas torna-se muito atraente. Isto pode até ser um pré-requisito na consideração de projetos de sistemas embarcados. Sistemas de desenvolvimento baseados em computação reconfigurável (sistemas de hardware reconfigurável) apresentam características adequadas para uso nesta classe de projetos. Eles apresentam, dentre outras vantagens, as características de baixo consumo, alta velocidade de operação, capacidade de integração, flexibilidade, facilidade de programação e operação modular. Este projeto utiliza uma arquitetura reconfigurável, que emprega os conceitos de Arquitetura de Computadores para obter um desempenho escalável e teve sua proposta lançada a partir de outro projeto desenvolvido no Centro Universitário Positivo UnicenP, pelo Prof. Edson Pedro Ferlin e pelo aluno Mauricio Brodzinski, no ano de 2006 como Projeto Final do Curso de Engenharia da Computação. Nesse projeto há a necessidade do desenvolvimento de uma interface de comunicação com grande desempenho no gerenciamento de informações, arquitetura padronizada e menor custo de manutenção. Para que esses requisitos sejam satisfeitos utiliza-se o processador embarcado Nios II da Altera. 16

17 CAPÍTULO INTRODUÇÃO AO PROJETO 1.1. Motivação No ano de 2006 foi desenvolvida uma versão básica de uma arquitetura paralela reconfigurável. Contudo existe a necessidade de uma interface que facilite o envio de informações de configuração, dos programas e dados a serem processados a partir de um computador front-end. Essa interface será utilizada também para retornar os resultados para esse computador Contextualização Embora os computadores estejam cada vez mais velozes (TANENBAUM, 2001), as exigências sobre eles crescem mais rapidamente do que a sua capacidade de processamento. Apesar da grande potência computacional disponível nos computadores utilizados nos mais diferentes ramos de atividade, ela não é suficiente para muitas aplicações. A velocidade de operação dos processadores está sempre crescendo, mas não podem continuar assim indefinidamente, pois existem limitações físicas que em algum momento impedirão a evolução dos processadores como é feito atualmente. Em razão disso os projetistas de computadores estão se voltando para os computadores paralelos, em busca de arquiteturas que utilizem vários processadores para obter ganho de desempenho em relação a computadores que operam por meio de um único processador. Para a operação dessas máquinas paralelas há a necessidade de um conjunto de interfaces de controle. Esse projeto está relacionado ao desenvolvimento de uma interface entre o computador no qual estão as informações a serem processadas e a máquina paralela que realizará o processamento Principais Funcionalidades O projeto será composto de um software montador de templates, da interface a ser desenvolvida e da arquitetura paralela desenvolvida no ano anterior. Para a execução software montador de templates será executado em um microcomputador sendo o responsável pelo fornecimento das informações que serão processados pela máquina paralela. A interface apresenta-se como um componente de hardware embarcado em FPGA (Field Programmable Gate Array), sendo responsável pelo gerenciamento do fluxo de informações vindas do microcomputador e que devem ser enviadas à máquina paralela. Essa configuração em 17

18 hardware foi adotada a fim de proporcionar maior desempenho, o que é conseguido devido à integração da interface com a máquina paralela por meio do processador Nios II que utiliza um barramento de alta velocidade e grande capacidade de processamento, chamado de Avalon, para a comunicação com a máquina paralela. Essa configuração apresenta melhor desempenho em relação à interface paralela atualmente implantada, pois a largura do barramento permite um fluxo maior de informações e com alta velocidade. A arquitetura paralela é composta por uma unidade de controle que efetua a distribuição de processamento e de vários EPs ( Elementos Processadores ) que são responsáveis pelo processamento Tecnologia Utilizada A interface será implementada em lógica programável usando FPGA do fabricante Altera e o processador embarcado Nios II fornecido como IP ( Intelectual Property ). Será utilizado como sistema de desenvolvimento as ferramentas Quartus II da Altera, o Ambiente Integrado de Desenvolvimento para o Processador NIOS, o ambiente SOPC Builder e o kit eletrônico contendo os dispositivos programáveis. 18

19 CAPÍTULO FUNDAMENTAÇÃO TEÓRICA Neste capítulo apresenta-se o estudo teórico dos conceitos e tecnologias que serão utilizadas no decorrer do projeto. Os conceitos abordados são: modelo de software embarcado, modelo de propriedade intelectual, modelo de fluxo de dados, computação reconfigurável, dispositivos lógicos programáveis e linguagem para descrição de hardware Teoria de Software Modelo de Software Embarcado Para o controle do fluxo de dados entre o microcomputador e a máquina paralela, utiliza-se o conceito de software embarcado chamado de firmware que será o responsável pela inicialização da interface de controle, diagnóstico de falhas e controle do fluxo de informações de e para a máquina paralela Modelo de Fluxo de Dados A arquitetura Fluxo de Dados (Data Flow) surgiu no final da década de 70 para explorar o paralelismo entre as instruções de um programa. Essas máquinas possuem uma única memória para os dados e para as instruções e não possuem um apontador de instruções como no modelo Von Neumann. Os sistemas Fluxo de Dados não possuem variáveis, pois os valores são representados por pacotes que são transmitidos entre os processadores. Cada processador possui a tarefa de executar alguma operação com sua entrada e produzir uma saída contendo o resultado. Nesse caso cada operação depende somente de suas entradas. Dessa forma, não há variáveis globais ou qualquer outra informação externa, por isso cada processador pode iniciar a execução assim que seus dados de entrada forem disponibilizados. Para cada processador disponível, associa-se um template (pacote) que contém informações a respeito da operação a ser realizada, os dados de entrada, operação, sinais de controle e uma lista dos destinos de saída. O ciclo de execução consiste em buscar e despachar todos os templates prontos e executá-los armazenando os resultados nos destinos apropriados, tornando assim disponíveis templates que utilizam como entrada o resultado do processamento de outro template. Sob estas condições, se o processamento for iniciado com um único processador e posteriormente for adicionando processadores, o desempenho do computador crescerá até que todo paralelismo implícito tenha sido explorado, aproveitando a escalabilidade do 19

20 sistema. O fluxo de controle sobre as operações é dado pela disponibilidade dos dados de entrada para a execução de uma instrução dataflow, num processo chamado data driven (dirigido pelos dados). Um programa dataflow é organizado como um grafo, os nós representam as instruções e os arcos representam o fluxo de dados entre os nós. No modelo data driven no instante que um nó do grafo referente a uma instrução detectar que todos os seus arcos de entrada estão habilitados, ele executa a instrução e fornece um resultado de saída, que pode vir a habilitar outros nós do programa dataflow. Dessa forma, o paralelismo entre as instruções acontece de forma natural, na medida em que a disponibilidade dos dados para um nó esteja satisfeita. Este modelo pode explorar o paralelismo existente nas as operações envolvidas no cálculo numérico de equações diferenciais como y +2xy +2 y = 0, em que várias operações podem ser executadas simultaneamente usando o modelo do grafo de fluxo de dados do problema. Na Figura 2.1 pode-se constatar que esta equação possui 16 operações elementares: 6 (multiplicação), 2 (adição), 2 (subtração), 3 (duplicação d ), 1 (condicional se ), 1 (condicional < ) e 1 (parada P ). Como mostrado na figura 2.1, inicialmente tem-se 5 nós independentes que podem ser executados simultaneamente, depois outros 5 e assim sucessivamente, seguindo o grafo de fluxo de dados. Figura 2.1: Exemplo de Grafo de Fluxo de Dados da Equação. (Fonte: FERLIN, 2005) 20

21 2.2. Teoria de Hardware Modelo de Processamento Embarcado A interface utiliza o conceito de processamento embarcado, em que pela combinação de lógica, memória e núcleo de processamento configurável é possível o desenho de sistemas inteiros em um único componente eletrônico Linguagem para Descrição de Hardware Como a tecnologia de circuitos integrados tem sido melhorada para permitir mais componentes em um chip, sistemas digitais continuam a aumentar a complexidade consumindo mais tempo para o detalhamento dos sistemas no nível de portas e flip-flops. Uma linguagem de descrição de hardware permite a um sistema digital ser desenvolvido e depurado em um nível mais alto antes da conversão para o nível de portas e flip-flop. As linguagens mais populares para descrição de hardware são VHDL ( VHSIC Hardware Description Language COHEN, 1999) e Verilog ( ROTH, 1998 ). O seu desenvolvimento foi patrocinado pelo Departamento de Defesa dos Estados Unidos e a primeira versão foi lançada em 1985 (YALAMANCHILI, 1998). Desde então, a indústria de automatização de projetos expandiu o uso de VHDL de concepção inicial da documentação, para implementação e verificação funcional. Projetos em VHDL possuem duas seções principais: ENTITY, que define as portas de entrada e saída e ARCHITECTURE, que define o funcionamento do projeto. Uma architecture pode ser desenvolvida em três modos: fluxo de dados, funcional e estrutural. O circuito lógico de um comparador é mostrado na Figura 2.2 e abaixo segue uma descrição dos três modos da linguagem com um exemplo de implementação do comparador. Figura 2.2: Circuito Comparador Lógico. Saída O=1 para A=B e O=0 para A B. 21

22 Declaração da entity para o comparador a qual pode utilizar uma das architectures apresentadas em seguida : library ieee; use ieee.std_logic_1164.all; entity comparador is port ( A, B: in std_logic_vector (1 downto 0); O: out std_logic ); end comparador; A declaração entity do comparador define A e B como entradas de dois bits e O como bit de saída. As duas primeiras linhas definem a biblioteca necessária para o tipo de dados das entradas e saídas: std_logic e std_logic_vector. A funcionalidade do comparador pode ser implementada em qualquer um dos três modos, descritos a seguir: Fluxo de dados: Define as relações entre as entradas e saídas. As instruções não são executadas de forma seqüencial como em linguagens de programação de software. Cada saída tem seu valor alterado após um evento (mudança de valor) em um sinal de entrada da qual seja dependente (ou sensitivo). architecture fluxo_de_dados of comparador is begin O <= '1' when (A = B) else '0'; end fluxo_de_dados; Funcional: Nesse modo, é feita a descrição da funcionalidade da entity por meio de uma representação algorítmica, semelhante a uma linguagem de programação. A descrição funcional é feita por meio da instrução process, que possui uma lista das entradas pela qual o processo é sensível, ou seja, as entradas que iniciam a execução após uma mudança no seu valor. architecture funcional of comparador is begin process (A,B) begin if A = B then C <= '1'; else C <= '0'; end if; end process; end funcional; 22

23 Estrutural: Nesse modo, o projeto é implementado pela declaração das portas lógicas e componentes do projeto, e as suas interligações. A declaração dos componentes está na linha use work.comportas.all, e indica que xnor2 e and2 estão no mesmo local do projeto. Por meio da declaração signal definem-se as ligações entre os componentes. use work.comportas.all; architecture estrutural of comp is signal x: std_logic_vector (0 to 1); begin U0: xnor2 port map (a(0), b(0), x(0)); U1: xnor2 port map (a(1), b(1), x(1)); U2: and2 port map (x(0), x(1), c); end estrutural; Computação Reconfigurável A idéia da utilização de hardware reconfigurável para o desenvolvimento de computadores reconfiguráveis surgiu na década de 60. A Computação Reconfigurável tem por objetivo a utilização de dispositivos lógicos programáveis (PLD Programmable Logic Devices) para dispensar a construção de circuitos digitais específicos à aplicação. A computação reconfigurável pode ser entendida como uma solução intermediária entre ASIC (Application-Specific Integrated Circuits) e microprocessadores, combinando vantagens das duas áreas, como mostrado na Figura 2.3. Figura 2.3: Posicionamento da Computação Reconfigurável. (Fonte: FERLIN, 2005) As arquiteturas reconfiguráveis ou arquiteturas de sistemas computacionais reconfiguráveis são aquelas implementadas por meio de técnicas de reconfiguração. Apresentam blocos lógicos e de interconexão que podem ser reconfigurados. 23 Os

24 blocos lógicos normalmente são as unidades funcionais de processamento, armazenamento, comunicação, entrada e saída de dados (FERLIN, 2005). A história da computação reconfigurável começou com as memórias PROM (Programmable Read Only Memory), e posteriormente com dispositivos PAL (Programmable Array Logic) e PLA (Programmable Logic Array). Na década de 80 foram lançados os primeiros PLDs, que deram origem às tecnologias CPLD (Complex Programmable Array Logic) e FPGA (Field Programmable Gate Array). Atualmente no mercado pode-se encontrar três tipos de FPGAs quanto à sua tecnologia de construção e descritas abaixo : RAM Estática: PLD na qual suas conexões entre as portas são feitas entre blocos lógicos por meio de portas de transmissão ou multiplexadores controladas por células SRAM. Tem como vantagem a possibilidade de ser rapidamente configurada, porém exige hardware externo auxiliar que deve ser montado junto com os blocos lógicos. Transistores de Passagem: Essa é uma opção mais barata que a opção de RAM estática, composta por uma grande concentração de transistores que são configurados em modo de corte ou modo de condução. EPROM/EEPROM: Sua principal vantagem é permitir a reprogramação sem que se precise armazenar a configuração externa Dispositivos Lógicos Programáveis Um FPGA é um dispositivo lógico programável que é largamente utilizado em sistemas digitais. Foi criado pela Xilinx e teve o seu lançamento no ano de 1985 como um dispositivo que poderia ser programado de acordo com as aplicações do usuário. FPGAs podem ser utilizados para a implementação de praticamente qualquer projeto de hardware. Um dos usos mais comuns é a prototipação de componentes que virão no futuro a transformar-se em ASIC (Application-Specific Integrated Circuits). No entanto, não existem problemas em se distribuir FPGAs em produtos finais. Esta decisão requer basicamente uma análise de custo, uma vez que o desenvolvimento de um ASIC é um processo bastante caro e inflexível, mas que gera componentes de custos bastante reduzidos se produzidos em larga escala. Já os FPGAs possuem flexibilidade e custo baixo de prototipação, mas preços finais pouco competitivos se comparados à ASIC com alta escala de produção. Cada fabricante de FPGA possui sua própria arquitetura, mas em geral elas são variações da arquitetura apresentada na 24

25 Figura 2.3. A arquitetura consiste de blocos lógicos configuráveis, blocos de E/S configuráveis e interconexões programáveis. (ZEIDMAN, 2006). Bloco lógico Interconexão programável Bloco de E/S Figura 2.4: Estrutura Interna em Blocos de um FPGA (Fonte: BARR, 1999) O desenvolvimento de um FPGA é fruto de uma evolução do conceito dos PLD/CPLD, mas a sua arquitetura é um tanto distinta destes últimos. Como mostrado na Figura 2.4, a arquitetura de um FPGA é composta de 3 estruturas básicas: blocos de entrada e saída (IOB Input/Output Block ), blocos lógicos configuráveis (CLB Configuration Logical Block ) e chaves de interconexão (Switch Matrix). blocos lógicos são dispostos de forma bidimensional, as chaves de interconexão são dispostas em formas de trilhas verticais e horizontais entre as linhas e as colunas dos blocos lógicos. CLB: Circuitos idênticos, construídos pela reunião de flip-flops (entre 2 e 4) e a utilização de lógica combinacional. Utilizando os CLBs, um usuário pode construir elementos funcionais lógicos. IOB: São circuitos responsáveis pelo interfaceamento das saídas provenientes das combinações de CLBs. São basicamente buffers, que funcionarão como um pino bidirecional entrada e saída do FPGA. SWITCH MATRIX: São os barramentos utilizados para conectar os CLBs e IOBs. Os Os recursos de interconexões possuem trilhas para conectar as entradas e saídas dos CLBs e IOBs para as redes apropriadas. Geralmente a configuração é estabelecida por programação interna, que determinam funções lógicas e conexões internas implementadas no FPGA entre os CLBs e os IOBs. O processo de escolha das interconexões é chamado de roteamento. 25

26 CAPÍTULO ESPECIFICAÇÃO DO PROJETO Nesse capítulo tem-se a especificação dos principais componentes do projeto. Os módulos de software, interface de controle reconfigurável e máquina paralela são representados na Figura Análise de Contexto Figura 3.5: Principais Módulos Descrição do Objeto do Desenvolvimento O objeto do desenvolvimento consiste em uma interface de controle reconfigurável para uma máquina de processamento paralelo desenvolvida no ano de O desenvolvimento será feito utilizando-se a computação reconfigurável, no qual se utilizam circuitos integrados que podem ser programados com a lógica desejada, por meio de um software que permite fazer o projeto de lógica digital. Na ferramenta de desenvolvimento de lógica digital o projeto é feito na forma de blocos lógicos utilizando-se a linguagem VHDL, que é um dos tipos de HDL (Hardware Description Language), ou Linguagem de Descrição de Hardware, sendo posteriormente feita a programação na FPGA. A interface será desenvolvida baseada 26

27 no processador embarcado Nios II da Altera. Esse processador possibilita o desenvolvimento de uma interface robusta, de menor custo de manutenção e grande poder de processamento visto que o processador Nios II permite um ambiente padronizado e amplamente aceito tanto no meio acadêmico como no meio comercial Descrição do Sistema Descrição do Software O software é a principal interface com o usuário e por meio do qual são montados os templates. Utilizando essa interface o usuário poderá observar os resultados obtidos dentre outras informações. Os parâmetros são passados à interface de controle que devolverá os resultados sempre que disponíveis ao final do processamento Descrição do Núcleo de Comunicação O núcleo de comunicação consiste dos componentes necessários para que se possa implementar a troca de informações entre o software e o processador Nios II. Esse núcleo é composto de hardware controlador dos sinais de comunicação, sendo que esse hardware pode implementar o padrão de sinais RS232 ou USB (Universal Serial Bus) e firmware responsável por estabelecer o protocolo de controle das informações de/para o microcomputador Descrição do Firmware O firmware controla o hardware diretamente sendo responsável pelo gerenciamento do núcleo de comunicação, do processador Nios II e do núcleo de controle da máquina paralela. O firmware tem acesso ao software gerador de templates por meio do núcleo de comunicação, sendo que o protocolo adotado pode ser RS232 ou USB. O acesso à máquina paralela é feito por meio do núcleo de controle, que é responsável por disponibilizar os sinais de controle e comunicação que interligam a máquina paralela e a interface de controle. O firmware será escrito em linguagem de programação C, também é capaz de acessar os periféricos inseridos na interface de controle pelo barramento de 32 bits chamado de Avalon Descrição do Processador Nios II O processador Nios II é um dos componentes de hardware configurado na FPGA sendo um processador RISC com barramento de dados configurável para 27

28 16 ou 32 bits. Também disponibiliza uma biblioteca de periféricos configuráveis para uma ampla gama de aplicações. Na Figura 3.6 tem-se a ilustração dos recursos do processador Nios II. Figura 3.6: Núcleo do Processador Nios II Descrição do Núcleo de Controle O processador Nios II é um dos componentes de hardware configurado na FPGA. Também serão escritos diversos componentes em linguagem de descrição de hardware. O principal componente de hardware a ser construído em VHDL nesse projeto é chamado de Controlador do Núcleo AP e implementa a interface de comunicação entre o microprocessador Nios II e a máquina paralela de processamento numérico. Todos os componentes escritos linguagem de descrição de hardware serão configurados em uma única FPGA. Além do CORE capaz de realizar a interface, tem-se também um processador, interface de comunicação e diversos controladores de dispositivos presentes no kit de desenvolvimento Descrição da Máquina Paralela A Máquina Paralela corresponde à parte do hardware responsável pelo processamento do cálculo numérico das funções disponibilizadas pelo usuário por meio do software montador de templates. 28

29 Descrição das Interfaces Interface de Comunicação Processador-Periféricos O processador Nios II comunica-se com os dispositivos por meio de uma interface denominada de Fábrica de Chaveamento Avalon. Todos os dispositivos necessários ao funcionamento do projeto devem ser interligados por meio dessa interface, que pode ser visualizada na Figura 3.7. Figura 3.7: Diagrama em Blocos da Interface Avalon Interface de Comunicação Serial O processador Nios II pode comunicar-se com o microcomputador por meio de uma interface serial. No kit de desenvolvimento existem dois padrões de comunicação serial RS232 e USB. Embora os dois padrões possam ser utilizados por esse projeto, o padrão USB deve ser preferido em relação ao padrão RS232, pois nos microcomputadores mais modernos, especialmente notebooks, torna-se cada vez mais difícil encontrar essa interface disponível. Na Figura 3.8 pode-se observar a integração entre o microcomputador e a interface por meio da comunicação serial. Figura 3.8: Interface Serial 29

30 Interface Processador-Máquina Paralela Para permitir o fluxo de informações entre o microcomputador e a máquina paralela existe a necessidade de uma interface entre o processador e a máquina paralela. Essa interface chamada de Controlador Núcleo AP pode ser visualizada na Figura 3.9. Figura 3.9: Interface Processador-Máquina Paralela Interface de Gravação JTAG Para configurar a FPGA deve ser utilizada a interface e o cabo de comunicação padrão JTAG presentes no kit de desenvolvimento Interface de Depuração JTAG Para depuração do firmware utiliza-se a interface de comunicação JTAG entre o microcomputador e o processador Nios II, que pode ser visualizada na Figura Figura 3.10: Interface de Depuração JTAG 30

31 Descrição das Restrições Restrição de custos O desenvolvimento do projeto da interface por ser um projeto acadêmico possui grande restrição nos custos. Para que seja viável esse projeto deve utilizar dos recursos já disponíveis evitando ao máximo a necessidade de investimentos na aquisição de materiais Restrição de Recursos O projeto da interface tem grande restrição de recursos humanos, pois devido ao fato de ser um Projeto de Final de Curso, apenas uma pessoa deve ser capaz de desenvolvê-lo. Há também a limitação do uso de recursos materiais disponíveis no laboratório, a aprovação de recursos extras depende de discussão e aprovação entre o aluno e orientador Restrição de Prazos O projeto está restrito aos prazos estabelecidos em cronograma para a entrega dos artefatos produzidos sendo que a interface deve estar finalizada no final de setembro de Condições Ambientais O projeto resulta em artefato de hardware que deverá ser instalado em ambiente com temperatura e umidade que permitam o funcionamento dos componentes eletrônicos como microcomputadores. Não há grande exigência no controle dessas variáveis, embora algum controle deva existir Condições Mecânicas Para a implementação do hardware utiliza-se um kit fornecido pela Altera. Esse kit apresenta as condições mecânicas necessárias ao bom funcionamento do projeto Condições de Energização Como todos os circuitos digitais, esse projeto necessita de fonte de energia elétrica estabilizada, sendo também necessário conversor de tensão que dependerá da tensão primária onde for instalado o equipamento. A tensão secundária será de 9Vcc ( Volts Corrente Contínua ). O kit de desenvolvimento Altera fornece um conversor com tensão primária de 127Vca ( Volts Corrente Alternada ) e tensão secundária de 9Vcc. 31

32 Condições Tecnológicas A tecnologia a ser utilizada impõe a utilização de FPGAs de grande capacidade de elementos de configuração, pois caso contrário pode haver limitação no desenvolvimento do projeto Condições de Interferência Eletromagnética Apesar de circuitos digitais apresentarem boa imunidade à interferência eletromagnética, recomenda-se a instalação em ambiente no qual não haja equipamentos de produzam grande quantidade de interferência eletromagnética como motores, geradores e grandes alto-falantes Descrição dos Benefícios Esperados Benefícios Econômicos Equipamentos de computação na área de processamento paralelo normalmente são importados o que acarreta em altos custos de aquisição. Esse projeto visa a reduzir os custos de fabricação de tais equipamentos disponibilizando uma arquitetura completa de processamento paralelo que pode ser produzida localmente Benefícios Operacionais A interface tem como objetivo reduzir a complexidade de operação da máquina paralela já desenvolvida Benefícios Estratégicos Equipamentos de computação paralela são necessários em muitas áreas do conhecimento humano, sendo que sua tecnologia e dominada por poucos centros ao redor do mundo. Dessa forma, a produção local de tais equipamentos apresenta uma grande vantagem competitiva para quem os produz Descrição dos Impactos Esperados Impactos Institucionais Para a operação do equipamento produzido por esse projeto haverá a necessidade do treinamento dos usuários, por isso deverá ser implementado um projeto para treinamento tanto dos usuários como dos responsáveis pela manutenção, projeto esse que deve ser tratado à parte e com recursos próprios. 32

33 3.2. Análise Funcional Funções de Comunicação A interface deve ser capaz de se comunicar de forma bidirecional com o microcomputador para recebimento da informação a ser processada, retorno dos resultados obtidos e troca de informações de controle. Há também a necessidade de comunicação bidirecional entre a interface e a máquina paralela para o envio das informações a serem processadas, recebimento dos resultados e das informações de controle Funções de Processamento de Informação A maior carga de processamento ocorrerá no interior da máquina paralela, havendo na interface apenas o processamento de informações de controle Funções de Controle Automático A interface deve ser capaz de determinar se os dispositivos necessários ao seu funcionamento estão operacionais e indicar possíveis falhas ao usuário. O controle da comunicação entre a interface, o microcomputador e a máquina paralela deve ser de forma automática sem a intervenção do usuário Funções de Interface Homem/Máquina A interface homem/máquina deverá ser capaz de permitir a entrada de dados das equações a serem processadas, do envio e controle dessas informações para a máquina de processamento paralelo. Essa interface também deverá permitir a visualização do estado da máquina paralela antes e durante o processamento Funções de Aquisição de Dados A interface deverá obter os dados para processamento, vindos do microcomputador, por meio de comunicação serial e também deve obter os resultados e sinais de controle da máquina paralela utilizando o barramento Avalon Funções de Atuação A interface deverá permitir a reinicialização de todo o sistema de hardware bem como a parada do processamento quando necessário. 33

34 3.3. Análise de Requisitos Funcionalidade Adequação A interface utiliza os recursos de comunicação e interação entre os componentes de forma a receber, processar e retornar os dados calculados, que é o objetivo final desse projeto Acurácia O projeto utiliza o processador embarcado Nios II da Altera, processador esse com bastante aceitação no meio acadêmico, isso faz com que se tenha um padrão de desenvolvimento no qual há redução de custos em relação a uma solução personalizada. Também deve utilizar interface de comunicação padronizada e de grande aceitação no mercado, pois isso facilita a manutenção do sistema. Para o desenvolvimento do software deve ser utilizada a linguagem C++, que é bastante aceita pela acedemia bem como no meio comercial Interoperabilidade Para esse projeto deve ser utilizado o kit de desenvolvimento do fabricante Altera. Esse kit apresenta uma arquitetura comercial e comprovadamente operacional em todos os aspectos relevantes para interoperação entre os sistemas envolvidos nesse projeto Conformidade Os sistemas produzidos nessa fase de pesquisa estão de acordo com as normas utilizadas para a produção do kit de desenvolvimento fornecido pelo fabricante Altera. A produção comercial do equipamento deverá estar em conformidade com as normas que regulam a produção de equipamentos computacionais com relação ao isolamento elétrico e produção de interferência eletromagnética Segurança Não serão estabelecidas normas de segurança para esse projeto, a implementação de restrições para o acesso ao equipamento de processamento paralelo deve ser objetivo de outro projeto. 34

35 Confiabilidade Maturidade O fato de se utilizar um kit comercial para o desenvolvimento do projeto evidência grande maturidade, pois esse mesmo kit é utilizado em muitos outros lugares, tendo o suporte de grandes empresas. A máquina paralela por ter sido desenvolvida no ano de 2006, tendo muitas horas de teste, apresenta grande maturidade. A interface desenvolvida nesse projeto utilizará biblioteca de componentes do fabricante Altera que também são amplamente utilizadas e suportadas, apresentando grande confiabilidade Tolerância a Falhas A tolerância a falhas terá papel secundário nesse projeto devendo ser tratada em outro projeto específico Recuperabilidade Caso ocorra alguma espécie instabilidade no funcionamento do sistema, a recuperação será feita por meio de dispositivo de reinicialização. Esse dispositivo não terá como função o resguardo das informações já processadas, ou seja, haverá perda do processamento sendo necessário o reinício do mesmo Usabilidade Inteligibilidade A inteligibilidade do sistema está na apresentação do objetivo a ser atingido pelo sistema completo, que é o de calcular os valores que resolvem equações numéricas. Os conceitos envolvidos no desenvolvimento da arquitetura são especializados e com um nível de compreensão mais difícil por usuários que não possuírem conhecimento de computação reconfigurável e eletrônica digital Apreensibilidade A interface foi projetada para permitir a interação com o usuário sem a necessidade de aprendizagem dos conceitos envolvidos em sua arquitetura. A interação com o usuário deve ser feita utilizando-se a ferramenta de montagem de templates, que foi desenvolvida no projeto do ano de

36 Operacionalidade O esforço operacional está centrado na ferramenta de montagem de template, pois a parte da interface e hardware adjacente tem funcionamento automático e integrado à ferramenta que será responsável pela interação com o usuário Eficiência Comportamento no Tempo Todo o sistema deve apresentar disponibilidade total ao longo do tempo independente do início de sua energização Comportamento na Utilização de Recursos Os recursos utilizados na comunicação e processamento devem ser liberados quando estiverem fora de uso, permitindo total disponibilidade do sistema para novo processamento Mantenebilidade Analisabilidade O projeto tem desenho modular, com funcionalidades bem definidas para cada um dos componentes. Isso permite uma facilidade maior na análise de melhorias a serem implementadas bem como de falhas existentes no processamento Modificabilidade O desenho modular garante um bom nível de modificabilidade ao sistema. Pode haver, contudo, dificuldade na modificação dos componentes do sistema, visto que são componentes altamente dedicados e que exigem alto grau de especialização dos recursos humanos. Para minimizar essa dificuldade, o sistema foi projetado com tecnologias comerciais e que são de grande aceitação no mercado Estabilidade O sistema é projetado de forma modular com o objetivo de permitir grande estabilidade. Alterações advindas de atualização do módulo do processador Nios II não devem alterar a estabilidade do sistema. Também as atualizações do módulo da máquina paralela ou no módulo do software montador de templates 36

37 não devem alterar a estabilidade. O risco de instabilidade, no entanto, ocorre quando houver necessidade de alteração no interfaceamento entre sistemas Testabilidade Como em todo projeto de interação de sistemas, ou interfaces entre sistemas, há a necessidade de grande esforço para teste de integração das funcionalidades. O desenvolvimento de rotinas de auto-teste é desejável, pois isso reduz o tempo total de testes de novas funcionalidades Análise de Arquitetura Na Figura 3.11 pode-se visualizar o diagrama detalhado da interface com a disposição lógica dos componentes. Figura 3.11: Diagrama de Blocos da Interface de Controle 37

38 CAPÍTULO DESENVOLVIMENTO E IMPLEMENTAÇÃO Neste capítulo faz-se o detalhamento do projeto da interface e os procedimentos adotados para o desenvolvimento Desenvolvimento da Interface de Controle Abaixo são enumerados os requisitos, componentes e as funcionalidades da interface de controle Análise de Requisitos Antes do início do desenvolvimento do hardware, software e do firmware deve-se identificar os requisitos necessários à interface de controle, abaixo segue a análise dos requisitos necessários ao projeto Requisitos de Hardware Processador Nios II. Controlador para periférico de comunicação USB. Controlador de memória SDRAM. Controlador da Arquitetura Paralela (Núcleo Controlador AP). Componente temporizador. Controlador de mostrador LCD Requisitos de Firmware Implementar funções de inicialização e diagnóstico de todos os periféricos. Implementar funções para controle da comunicação USB. Implementar funções para controle do Núcleo AP (Máquina Paralela). Implementar funções para controle do mostrador LCD. Implementar funções de aviso ao final da rotina de diagnóstico Requisitos de Software O software deve implementar a interface USB para comunicação entre o microcomputador e o microprocessador. 38

39 Implementar protocolo para envio de templates para a interface de controle. Implementar protocolo para recebimento de templates da interface de controle Desenvolvimento do Sistema de Hardware Com o estabelecimento dos requisitos torna-se possível a construção lógica da interface de controle que pode ser visualizada na Figura A descrição dos componentes segue abaixo. Figura 4.12: Interface de Controle Processador Nios II Componente disponibilizado na ferramenta SOPC Buider, onde são disponibilizadas três configurações. Para a implementação da interface de controle deve-se utilizar a configuração Nios II/e por ser a opção que utiliza a menor quantidade de recursos de hardware entre todas as configurações possíveis Controlador SDRAM Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir o uso do componente de memória RAM externo. Essa memória torna-se necessária para o armazenamento do firmware e dos dos templates a serem processados. 39

40 Controlador de Comunicação USB Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir a comunicação serial entre o microcomputador e a interface de controle por meio de uma interface padrão USB Controlador de LCD Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir o uso do mostrador de LCD. O mostrador deve ser utilizado para mostrar informações de diagnóstico ao usuário do sistema Temporizador Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir a temporização nas funções do firmware Identificador do Sistema Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir a identificação do modelo de FPGA para o qual o sistema foi compilado evitando erros pela utilização em outros modelos de FPGA Interface Avalon MM Esse componente tem a responsabilidade de receber os sinais de leitura, escrita, endereçamento e dados disponíveis no barramento Avalon e direcioná-los para o banco de registradores, devendo ser implementado em linguagem VHDL Banco de Registradores O banco de registradores recebe os dados e endereços assinalados pelo firmware por meio da interface Avalon MM e os envia para a Interface do Núcleo AP. Também recebe dados e sinais de controle retornados pelo Núcleo AP. Esse componente tem funcionalidade costumizada e deve ser construído em linguagem VHDL. Na Figura 4.13 poder ser visualizado mais detalhadamente os sinais da interface entre o banco de registradores e o Núcleo AP. 40

41 Figura 4.13: Banco de Registradores Núcleo AP Esse componente foi desenvolvido no ano de 2006 integrando-se à interface de forma a receber os templates a serem processados e o envio dos resultados para o computador host Desenvolvimento do Firmware O firmware deve implementar a comunicação entre o software do microcomputador e o processador Nios II através da interface USB para recebimento dos templates e envio dos resultados obtidos pelo Núcleo AP. Também deve implementar a comunicação entre o processador Nios II e o Núcleo AP para o envio de templates e o recebimento de resultados processados pelo Núcleo AP. Para que a comunicação possa ocorrer de forma adequada deve ser implementado um protocolo de comunicação baseado na troca de comandos entre o host e a interface embarcada na FPGA, na Figura 4.14 pode ser visualizada a estrutura do pacote utilizado para a troca de informações entre a Interface de Controle e o host. Na Figura 4.15 pode-se observar o fluxo de processamento e na Tabela 4.1 a relação de comandos utilizados. Figura 4.14: Diagrama da Estrutura de Comunicação USB 41

42 Figura 4.15: Diagrama do Fluxo de Processamento do Firmware Tabela 4-1: Lista de Comandos de Comunicação Comando Resposta Descrição 0x99 -- Reinicializa porta USB. 0x55 0x56 Inicia o processamento na máquina paralela ( Núcleo AP ). 0x57 0x58 Verifica se o processamento foi finalizado na máquina paralela. 0xAA 0xAB Comando de transmissão de templates do host para a interface. 0xBB 0xBC Indica que a transmissão dos templates do host para a interface será iniciada. 0xDD 0xDF Transmissão de templates da interface para o host. 0xEE 0xEF Indica que a transmissão dos templates da interface para o host será iniciada. 0xFD 0xFF Indica que os dados recebidos do host devem ser usados para depuração. 0xFE 0xFF Indica que dados de depuração devem ser enviados para o host. 42

43 Desenvolvimento do Software A versão do software desenvolvida em 2006, utilizava a comunicação paralela padrão CENTRONICS, a qual será substituída pela comunicação USB. Na implementação das rotinas de comunicação deve-se utilizar o driver fornecido com o kit DE2 chamado de EasyD12. Esse driver disponibiliza uma biblioteca na forma de DLL para o sistema operacional Windows. Para o controle de fluxo na comunicação deve ser implementado no software o mesmo protocolo a ser implementado pelo firmware. Na Figura 4.15 pode ser visualizado o diagrama de classe do componente. Figura 4.16: Diagrama da Classe de Comunicação USB 4.2. Recursos Necessários ao Desenvolvimento da Interface de Controle Para viabilizar a implementação da interface projetada foi feita uma análise para identificar os recursos de hardware, software e documentação a serem empregados. Como resultado dessa análise identificou-se os recursos que são descritos a seguir Quartus II Esse é o software que deve ser utilizado para o desenvolvimento dos componentes de 43

44 hardware costumizados. Nessa ferramenta também será feita a integração de todos os componentes de hardware do projeto, bem como a simulação de funcionamento e a gravação no dispositivo FPGA selecionado para execução do sistema desenvolvido. Para evitar instabilidade por erros de software foi escolhida a versão 6.10 do Quartus II para o desenvolvimento do projeto SOPC Builder Essa deve ser o software utilizado para o desenvolvimento do subsistema do processador Nios II e seus periféricos. Essa ferramenta permite a configuração dos recursos do processador Nios II e a seleção de quais periféricos serão utilizados como suporte às operações do processador. Os componentes costumizados também devem ser integrados ao sistema processado através de uma interface que deve ser implementada nessa ferramenta Nios II IDE Esse deve ser o software utilizado para o desenvolvimento do firmware responsável pelo gerenciamento processador Nios II e seus periféricos. Essa ferramenta disponibiliza um ambiente integrado de desenvolvimento, distribuição e depuração na qual é possível escrever os programas em liguagem C ou C++, compilar, distribuir para um hardware específico e depurar o programa implementado. Essa ferramenta também está integrada ao SOPC Builder, o que permite a utilização do sistema processado sem a necessidade de grande esforço adicional Documentação Necessária Para permitir a utilização das ferramentas citadas anteriormente torna-se necessária a leitura de documentação adicional, descrita abaixo Documentação do Processador Nios II Nios II Flash Programmer - User Guide. Nios II Software Developer s Handbook. Nios II Hardware Development Tutorial. Nios II Processor Reference Handbook Documentação de Periféricos Using the SDRAM Memory on Altera s DE2 Board Documentação da Ferramenta SOPC Builder Introduction to the Altera SOPC Builder 44

45 Quartus II Version 6.1 Handbook - Volume 4 SOPC Builder Documentação da Ferramenta Nios II IDE Ajuda da Ferramenta Nios II IDE Hardware A execução do sistema construído depende da sua instalação em um hardware com o suporte necessário para o correto funcionamento. Esse hardware deve permitir a instalação de sistemas com processadores Nios II. Para isso deve ser utilizado o kit DE2 da Altera. Esse kit permite a execução de sistemas com processadores Nios II bem como possui periféricos para comunicação serial, mostrador de LCD e memória RAM Estudo e Aprendizagem Após a identificação dos recursos, deve ser iniciado o estudo e a aprendizagem conforme a descrição a seguir : Documentação Para o entendimento da arquitetura dos sistemas embarcados Nios II e dos conceitos envolvidos na utilização dos periféricos, deve ser feito o estudo da documentação em formato PDF descrita anteriormente. Também deve ser estudada a documentação das ferramentas para a aprendizagem dos recursos disponibilizados e sua utilização Software Finalizada a leitura da documentação devem ser instaladas as ferramentas passando-se à aprendizagem do uso de cada uma delas. Para se ter um melhor aproveitamento recomenda-se a utilização dos exercícios propostos nos tutoriais de cada ferramenta Componentes de Eletrônicos A implementação física do projeto depende diretamente dos componentes eletrônicos os quais devem atender aos requisitos funcionais FPGA Utilizada A FPGA a ser utilizada será a linha Cyclone II, por apresentar os recursos necessários à implementação da interface de controle. Dentro dessa linha foi escolhido o modelo EP2C35F672C6, abaixo estão indicados os recursos disponíveis nesse componente : 45

46 Elementos lógicos: ; Bit de memória: ; Pinos de entrada e saída: 475; Kit Altera Baseando-se no componente FPGA necessário ao projeto, fez-se um estudo que apontou o kit DE2 da Altera, o qual disponibiliza todos os componentes já montados e integrados às ferramentas de projeto. Os recursos do kit que têm utilidade para o projeto são listados abaixo. Na Figura 4.17 pode-se visuzalizar a aparência do kit como também todos os recursos disponíveis. SDRAM de 8-Mbytes. Flash de 4-Mbytes. Display de LCD 16x2. Interface USB push buttons. 18 LEDs vermelhos. 9 LEDs verdes. Oscilador de 50 MHz para o FPGA. Figura 4.17: Kit DE2 da Altera Seqüência de Desenvolvimento A implementação deve ser baseada no fluxo para desenvolvimento de sistemas Nios II proposto pela Altera e que pode ser visualizado na Figura

47 Figura 4.18: Fluxo para Desenvolvimento de Sistemas Nios II Prova de Conceito A fase inicial de desenvolvimento tem como objetivo a implementação de um protótipo, em que será comprovado o conceito proposto para o projeto. Essa implementação utiliza-se do fluxo de desenvolvimento para o sistema Nios II mostrado acima. Para que o modelo inicial atenda aos conceitos do projeto, deve implementar os requisitos determinados para o hardware e software Construção do Sistema de Hardware Com o estabelecimento dos requisitos e a utilização dos conceitos de desenvolvimento de sistemas Nios II, foi possível a construção do projeto lógico do protótipo. Esse protótipo pode ser visualizado na Figura Para a implementação dos componentes a primeira atividade desenvolvida deve ser a criação de um projeto na ferramenta Quartus II, selecionando-se como alvo a FPGA Cyclone II EP2C35F672C6 disponível no kit DE2. A atividade seguinte deve ser a criação de um projeto Nios II na ferramenta SOPC Builder, nessa ferramenta monta-se o sistema Nios II com os periféricos disponibilizados em forma de IP ( Intellectual Property ). 47

48 Figura 4.19: Protótipo Utilizado Para Prova de Conceito JTAG UART Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir a depuração do firmware embarcado no sistema Nios II Processador Nios II Para esse componente pode-se selecionar uma de três configurações possíveis. Para a prova de conceito deve ser selecionada a configuração Nios II/e por ser a configuração a ser utilizada pela interface de controle Controlador SDRAM Esse componente é disponibilizado pela ferramenta SOPC Builder, permitindo o uso de memória RAM externa. Essa memória é utilizada para o armazenamento do firmware e também para memória de dados Controlador de LCD Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir o uso do mostrador de LCD. Esse componente é utilizado para mostrar informações para o usuário do sistema Interface USB Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo 48

49 necessário para permitir a comunicação serial entre o microcomputador e a interface de controle Temporizador Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir a temporização nas funções do firmware Identificador do Sistema Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir a identificação do tipo de componente para o qual o sistema foi compilado evitando erros pela utilização em outras FPGAs Interface Avalon MM Esse componente tem a responsabilidade de receber os sinais disponíveis no barramento Avalon e direcioná-los adequadamente para o banco de registradores, devendo ser implementado em linguagem VHDL Banco de Registradores O banco de registradores recebe os valores assinalados pelo firmware por meio da interface Avalon MM e os armazena em um dos registradores. 49 Esse componente tem funcionalidade customizada e deve ser construído em linguagem VHDL o que pode-se observar na parte do código abaixo. PROCESS( read_to_reg0, read_to_reg1, read_to_enable, reg0_register, reg1_register, enable_register ) --Read Data Bus Mux BEGIN IF( read_to_reg0 = '1' ) THEN read_data <= reg0_register; ELSE IF( read_to_reg1 = '1' ) THEN read_data <= reg1_register; ELSE IF( read_to_enable = '1' ) THEN read_data <= Std_Logic_Vector'( A_REP(std_logic'('0'), 31) & enable_register ); ELSE read_data <= A_REP(std_logic'('0'), 32); END IF; END IF; END IF; END PROCESS;

50 Núcleo Costumizado Esse componente recebe os dados e sinais de controle vindos do banco de registradores. A lógica de processamento implementada permite que o valor do registrador A seja visualizado em um mostrador externo ao núcleo Costumizado. O registrador de habilitação controla o funcionamento da lógica de processamento, habilitando ou desabilitando a execução. Esse componente tem lógica costumizada e deve ser implementado em linguagem VHDL, sendo possível observar parte do código abaixo. PROCESS( clk, resetn ) -- Processor Counter Process BEGIN IF( resetn = '0') THEN processor_reg0out <= " "; processor_reg1out <= " "; ELSE IF( processor_enable = '1' ) THEN -- Recebe os valores enviados pelo Nios II. processor_reg0out <= processor_reg0( 15 downto 0 ); processor_reg1out <= processor_reg1( 15 downto 0 ); ELSE processor_reg0out <= " "; processor_reg1out <= " "; END IF; END IF; END PROCESS; Desenvolvimento do Firmware O desenvolvimento do firmware para o protótipo é feito utilizando-se a ferramenta Nios IDE sendo escrito em linguagem C. O firmware tem duas etapas de desenvolvimento, na primeira etapa deve ser implementada a comunicação entre o microprocessador Nios II e o Núcleo Costumizado. O fluxo de processamento da etapa I pode ser visualizado abaixo. Etapa I : 1. Inicialização dos registradores. 2. Incialização do mostrador LCD. 3. Habilitação do Núcleo Costumizado. 50

51 protótipo. 4. Realizar contagem de zero a dez e gravar o incremento nos registradores de contagem. 5. Realizar a leitura dos registradores de contagem para validar os valores gravados. 6. Finalizar o processamento. Abaixo se observa uma parte do código desenvolvido para a etapa I do int initializeap() { int return_code = CORE_AP_OK; //Initializa o Core AP e verifica código de retorno. printf("inicializando Core AP.\n"); return_code = core_ap_init( CTRL_CORE_AP_BASE ); check_return_code( CTRL_CORE_AP_BASE, return_code); printf("core AP Inicializado.\n"); } return return_code; int resetcoreap() { ); // Liga sinal de reset do Nucleo AP core_ap_write_controlreg( CTRL_CORE_AP_BASE, RESET_SIGNAL // Desliga sinal de reset do Nucleo AP core_ap_write_controlreg( CTRL_CORE_AP_BASE, RESETREG ); } return 1; Na segunda etapa, o processador Nios II recebe os dados do microcomputador, processando-os para envio ao Núcleo Costumizado. Abaixo se enumera o fluxo de processamento. Etapa II : 1. Inicialização dos registradores. 2. Incialização do mostrador LCD. 3. Inicialização da Interface USB. 4. Habilitação do Núcleo Costumizado. 5. Aguardar o envio de dois valores pelo software do 51

52 microcomputador. 6. Gravar os valores recebidos contagem nos registradores de contagem. 7. Fazer a leitura dos registradores de contagem para validar os valores gravados. 8. Voltar ao passo 5. protótipo. Abaixo se observa uma parte do código desenvolvido para a etapa II do void receivedebugdata() { // Copy debug data. memcpy( &usbdatacontrol.datainbuffer[ usbdatacontrol.bytesreceived ], datapacket.data, datapacket.datalen ); usbdatacontrol.bytesreceived = datapacket.datalen; datapacket.command = debugdataok; datapacket.datalen = 0; usbdatacontrol.bdebugdata = 1; } Hal4D13_WriteEndpoint( EPINDEX4EP02, &datapacket.command, sizeof(datapacket) ); void receiveusbdata() { memcpy( &usbdatacontrol.datainbuffer[ usbdatacontrol.bytesreceived ], datapacket.data, datapacket.datalen ); usbdatacontrol.bytesreceived += datapacket.datalen; datapacket.command = datareceiveok; } Hal4D13_WriteEndpoint( EPINDEX4EP02, &datapacket.command, sizeof(datapacket) ); Desenvolvimento do Software O desenvolvimento do software para o protótipo deve ser feito utilizandose a ferramenta CBuilder IDE sendo escrito em linguagem C++. Tem como funções iniciar a comunicação com o processador usando da interface USB e o envio de valores para o microprocessador Nios II. O objetivo do protótipo do software é o de comprovar o funcionamento da comunicação serial por meio da porta USB. Uma vez implementada essa comunicação, torna-se possível o envio 52

53 dos dados a serem processados pelo núcleo de processamento paralelo. pode ser visualizada a função de envio de dados para o processador Nios II. Abaixo void fastcall TForm1::botaoEnviarClick( TObject* Sender) { unsigned char buff[8]; memset( buff, 0, sizeof(buff)); buff[0] = 0xFD; /* Comando de envio de dados para */ /* depuração. */ buff[1] = 0x01; /* Tamanho dos dados */ buff[2] = 0x01; /* Dado a ser enviado */ WritePort1(buff,sizeof(buff));/* Envia comando ao Nios */ buff[0]=0x00; /* Limpa buffer de comando */ ReadPort2(buff, sizeof(buff));/* Recebe retorno do Nios*/ buff[0] = 0xFE; /* Comando para receber dados de */ /* depuração. */ buff[1] = 0x01; WritePort1(buff,sizeof(buff)); /* Envia comando ao Nios*/ buff[0]=0x00; /* Limpa buffer de comando */ ReadPort2(buff, sizeof(buff));/* Recebe retorno do Nios*/ } /* Verifica se ocorreu erro no processamento */ if( buff[0] == 0xCC ) { Form1->Memo1->Lines->Add("Error "); } Implementação do Projeto Odesenvolvimento tem como objetivo a implementação do projeto seguindo os requisitos determinados para o hardware, software e firmware Construção do Sistema de Hardware Com o estabelecimento dos requisitos e a utilização dos conceitos de desenvolvimento de sistemas Nios II, foi possível a construção lógica do projeto. Esse protótipo pode ser visualizado na Figura Para a implementação dos componentes fez-se como primeira atividade a criação de um projeto na ferramenta Quartus II, selecionando-se como alvo a FPGA Cyclone II EP2C35F672C6 disponível no kit DE2. A atividade seguinte deve ser a criação de um projeto Nios II na ferramenta SOPC Builder, nessa ferramenta monta-se o sistema Nios II com os periféricos disponibilizados sendo que o resultado pode ser visualizado na Figura

54 Figura 4.20: Subsistema Nios II Processador Nios II Para esse componente pode-se selecionar uma de três configurações possíveis. Para a prova de conceito deve ser selecionada a configuração Nios II/e por ser a configuração a ser utilizada pela interface de controle Controlador SDRAM Esse componente é disponibilizado pela ferramenta SOPC Builder, permitindo o uso de memória RAM externa. Essa memória é utilizada para o armazenamento do firmware e também para memória de dados Controlador de LCD Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir o uso do mostrador de LCD. Esse componente é utilizado para mostrar informações para o usuário do sistema Interface USB Esse componente permite a comunicação serial entre o microcomputador e a interface de controle sendo disponibilizado pela ferramenta SOPC Builder Temporizador Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo 54

55 necessário para permitir a temporização nas funções do firmware Identificador do Sistema Esse componente é disponibilizado pela ferramenta SOPC Builder, sendo necessário para permitir a identificação do tipo de componente para o qual o sistema foi compilado evitando erros pela utilização em outras FPGAs Banco de Registradores O banco de registradores recebe os valores assinalados pelo firmware por meio da interface Avalon MM e os armazena em um dos registradores. Esse componente tem funcionalidade customizada e deve ser construído em linguagem VHDL o que pode-se observar na parte do código abaixo. --Write Registers PROCESS( clk, resetn ) BEGIN IF( resetn = '0') THEN control_register <= rf_controlreg_init; ep_register <= rf_epreg_init; datain_register <= rf_datainreg_init; ELSE IF( clk'event AND clk = '1') THEN -- Control Register IF( write_to_controlreg = '1' ) THEN control_register <= write_data; ELSE control_register <= control_register; END IF; -- EP register IF( write_to_epreg = '1' ) THEN ep_register <= write_data; ELSE ep_register <= ep_register; END IF; -- Datain Register IF( write_to_datainreg = '1' ) THEN datain_register <= write_data; ELSE datain_register <= datain_register; END IF; END IF; END IF; END PROCESS; --assign register values to the processor controlreg <= control_register; datainreg <= datain_register; epreg <= ep_register; status_register <= statusreg; dataout_register <= dataoutreg; 55

56 Núcleo AP Esse componente recebe os templates e sinais de controle vindos do banco de registradores e os conecta com a arquitetura paralela. Esse componente tem lógica costumizada e deve ser implementado em linguagem VHDL, sendo possível observar parte do código abaixo. ARCHITECTURE NucleoAP_Arch OF NucleoAP IS BEGIN AP Interface Instance main_inst : main GENERIC MAP( 64 ) PORT MAP( clock => mclk, reset => controlreg_reset, wr => controlreg_wr, ack => controlreg_ack, inittransfer => controlreg_inittransfer, datain => datain_register, n_ep => ep_register, mpreadhostdata => statusreg_mpready, wrhost => statusreg_wr_host, fim => statusreg_fim, inicio => statusreg_inicio, dataout => dataout_register, wrep => wrepout_register ); controlreg_reset <= controlreg(0); controlreg_wr <= controlreg(1); controlreg_ack <= controlreg(2); controlreg_inittransfer <= controlreg(3); statusreg(0) <= statusreg_wr_host; statusreg(1) <= statusreg_fim; statusreg(2) <= statusreg_inicio; statusreg(3) <= statusreg_mpready; statusreg(31 DOWNTO 4) <= Std_Logic_Vector'( A_REP(std_logic'('0'), 28)); ep_register <= epreg( 1 DOWNTO 0 ); datain_register <= datainreg( 7 DOWNTO 0); dataoutreg <= Std_Logic_Vector'( A_REP(std_logic'('0'), 8) & dataout_register ); wrepoutreg <= wrepout_register; END NucleoAP_Arch; 56

57 Desenvolvimento do Firmware O desenvolvimento do firmware para o projeto faz-se utilizando a ferramenta Nios IDE sendo escrito em linguagem C/C++. O firmware implementa a comunicação entre o software, o microprocessador Nios II e o Núcleo AP. Abaixo se observa uma parte do código desenvolvido para o projeto. int initializeap() { int return_code = CORE_AP_OK; //Initializa o Core AP e verifica código de retorno. printf("inicializando Core AP.\n"); return_code = core_ap_init( CTRL_CORE_AP_BASE ); check_return_code( CTRL_CORE_AP_BASE, return_code); printf("core AP Inicializado.\n"); } return return_code; int resetcoreap() { // Reset Nucleo AP core_ap_write_controlreg( RESET_SIGNAL ); // Reset on core_ap_write_controlreg( RESETREG ); // Reset off } return 1; void receivedebugdata() { // Copy debug data. memcpy( &usbdatacontrol.datainbuffer[ usbdatacontrol.bytesreceived ], datapacket.data, datapacket.datalen ); usbdatacontrol.bytesreceived = datapacket.datalen; datapacket.command = debugdataok; datapacket.datalen = 0; usbdatacontrol.bdebugdata = 1; } Hal4D13_WriteEndpoint( EPINDEX4EP02, &datapacket.command, sizeof(datapacket) ); void receiveusbdata() { memcpy( &usbdatacontrol.datainbuffer[ usbdatacontrol.bytesreceived ], datapacket.data, datapacket.datalen ); usbdatacontrol.bytesreceived += datapacket.datalen; datapacket.command = datareceiveok; } Hal4D13_WriteEndpoint( EPINDEX4EP02, &datapacket.command, sizeof(datapacket) ); 57

58 Desenvolvimento do Software O desenvolvimento do software para o projeto deve ser feito utilizando-se a ferramenta CBuilder IDE sendo escrito em linguagem C++. Tem como funções iniciar a comunicação com o processador usando a interface USB, o envio e recebimento de templates para o microprocessador Nios II. Abaixo pode-se visualizar as funções de envio e recebimento de dados para o processador Nios II e na Figura 4.21 a tela principal do software. double ccom::executa() { envia_templates(); double tempo = aguarda(); recebe_templates(); } return tempo; void ccom::envia_templates() {... // Envia à porta USB os dados. if( porta.starttransmission() ) { // Envia número de EPS. porta.senddata( &m_qtdeeps, 1 ); // Envia templates. porta.senddata( data, sizeof(data) ); // Inicia processamento. porta.startprocessing(); } } void ccom::recebe_templates() {... // Recebe operandos em grupos de 4 bits. porta.receivedata( data, datareceived ); for( int oppos = 0; oppos < datareceived; oppos++ ) { // Armazena operando de 8 bits datapos = oppos * 3; int oper = (data[ datapos ] & 0x0F); } op [oppos] = oper; op2r[oppos] = data[ datapos + 1 ]; op1r[oppos] = data[ datapos + 2 ]; if( oper == 0x0F ) { break; } }... 58

59 Figura 4.21: Tela Principal do Software 59

60 CAPÍTULO VALIDAÇÃO E RESULTADOS Neste capítulo descrevem-se os procedimentos adotados para validação do projeto e os resultados obtidos Validação do Protótipo A validação do protótipo desenvolve-se em duas etapas conforme as funcionalidades necessárias em cada etapa da implementação sendo enumeradas abaixo : Etapa I : 1. Validação do sistema de hardware na ferramenta Quartus II. 2. Validação do firmware na ferramenta Nios II IDE. 3. Validação funcional do protótipo através do envio de valores para o Núcleo Costumizado a partir do firmware. Etapa II : 1. Validação do firmware no kit DE2. 2. Validação do software no microcomputador. 3. Validação funcional do protótipo através do envio de valores para a interface de controle a partir do software no microcomputador Validação do Hardware A primeira validação do sistema de hardware faz-se usando a ferramenta Quartus II, na qual fez-se a compilação e a observação da inexistência de erros e alertas críticos sobre o sistema. A segunda validação fez-se por meio da atribuição dos sinais de interfaceamento aos pinos físicos da FPGA, nesse ponto validou-se a relação de sinais disponíveis e suas correspondências aos pinos. A terceira validação fez-se através da gravação do sistema para o kit Altera DE2. Nessa validação foi observada a inexistência de erros Validação do Firmware A primeira validação do firmware fez-se por meio da ferramenta Nios II IDE, na qual foi feita a compilação e observou-se a inexistência de erros e alertas críticos sobre o código. A segunda validação fez-se através da gravação do firmware 60

61 gerado para o kit Altera DE2, observando-se a inexistência de erros durante o processo Validação Funcional A validação funcional fez-se por meio da observação do acendimento de leds em seqüência binária pré-determinada, tanto para a fase I quanto para a fase II Resultados do Protótipo Os resultados obtidos são enumerados conforme as fases de validação. Abaixo são descritos os resultados obtidos nas atividades de validação. Na fase I obtém-se como resultado o acendimento dos leds a partir do valor enviado pelo firmware conforme a seqüência binária de zero a dez, enviada ao Núcleo Costumizado. Na fase II observou-se o acendimento dos leds a partir do valor enviado pelo software do microcomputador para o microprocessador. Na tabela 5.2 pode ser observada a seqüência de acendimento dos leds em função dos valores enviados ao Núcleo Costumizado o que comprova o correto funcionamento do protótipo da interface de controle. Tabela 5-2: Resultados do protótipo Etapa I e Etapa II Valor Enviado 0 Seqüência Observada

62 5.3. Problemas Encontrados no Desenvolvimento do Protótipo Abaixo se enumeram-se os problemas encontrados durante a implementação dos componentes do protótipo. Necessidade de configuração dos softwares utilizados em computadores diferentes conforme a disponibilidade. Por esse motivo optou-se pela utilização de um notebook também nos laboratórios do Unicenp. Na primeira versão do protótipo, houve problema na implementação do dispositivo controlador de memória SDRAM. Após análise verificou-se que um dos pinos de controle da memória estava com sua interligação errada. Na segunda versão do protótipo, houve problemas com a implementação do controlador de comunicação USB. Após análise verificou-se que os pinos de controle de velocidade de comunicação estavam com suas interligações erradas. Também se verificou que havia a necessidade de um componente temporizador de reinicialização da CPU Nios II, o qual foi incorporado à interface de controle Validação do Projeto A validação do projeto desenvolveu-se conforme as funcionalidades necessárias em cada componente sendo descrita abaixo : Validação do Hardware A primeira validação do sistema de hardware fez-se por meio da ferramenta Quartus II, na qual foi criado componente específico para envio de template ao Núcleo AP, com esse componente fez-se a simulação do envio de um template e a observação do processamento ocorrido, essa simulação pode ser visualizada na Figura B.28 localizada no Anexo B. A segunda validação fez-se com o envio de template por meio do firmware, observando-se o cálculo efetuado após o recebimento dos resultados Validação do Firmware A validação do firmware fez-se por meio do envio de pacotes de informações usando-se o software montador e a observação do resultado do processamento de cada comando disponível no protocolo de comunicação Validação do Software A validação do software fez-se por meio do envio de templates para o 62

63 microprocessador Nios II através da interface USB e a observação do correto recebimento desses templates pelo microprocessador Validação Funcional A validação funcional fez-se por meio da criação de template, transferência do template para o kit DE2 e recebimento do cálculo efetuado pelo Núcleo AP. Com isso pode-se observar o correto funcionamento do software, firmware e hardware do projeto Testes Realizados Testes de Hardware 1. Depuração e diagnóstico de funcionamento do Núcleo Controlador AP, por meio da criação de componente de hardware responsável pelo envio de templates para a Arquitetura Paralela. Nesse teste foi feita a simulação de funcionamento na ferramenta Quartus II que pode ser observada na Figura B.28 e parte do código VHDL utilizado na Figura B Inicialmente a velocidade de relógio utilizada para o subsistema Nios II foi 50MHz, sendo essa velocidade de relógio fornecida diretamente pelo kit DE2. Para melhorar o desempenho aumentou-se a velocidade para 100 MHz utilizando-se de um circuito PLL ( Phased Locked Loop ). Através do gráfico da Figura 5.22 pode-se observar o ganho de desempenho obtido em função do aumento da velocidade de processamento. O teste foi realizado utilizando-se o template para cálculo da equação de 2º grau com dez mil iterações. Figura 5.22: Desempenho do Subsistema Nios II 3. Inicialmente utilizou-se o modelo de processador Nios II/e. Para melhorar o desempenho realizou-se testes com os outros dois modelos disponíveis. No gráfico da Figura 5.23 pode-se observar o ganho de desempenho obtido em 63

64 função do modelo utilizado para processamento. O teste foi realizado utilizando-se o template para cálculo da equação de 2º grau com dez mil iterações. Figura 5.23: Desempenho do Processamento Testes de Firmware 1. Depuração e diagnóstico de funcionamento do firmware por meio da interligação do kit DE2 com um microcomputador. Nesse teste foi validado o correto recebimento e envio de dados de e para o microcomputador. 2. Depuração e diagnóstico de funcionamento do firmware através da interligação do subsistema Nios II com a Arquitetura Paralela. Nesse teste foi validado o correto recebimento e envio de dados de e para a Arquitetura Paralela ( memória de armazenamento ). 3. Na primeira versão do firmware utilizava-se a interface USB com a configuração do tamanho do pacote com 8 bytes. Posteriormente realizou-se testes com o aumento progressivo do tamanho do pacote até 64 bytes, que é o tamanho máximo permitido pelo driver Easy12 que é disponibilizado pelo kit DE2. Na Figura 5.24 pode-se observar o ganho de desempenho na comunicação entre o microcomputador e o microprocessador Nios II. O teste foi realizado utilizando-se o template para cálculo da equação de 2º grau como template de comunicação. Figura 5.24: Desempenho da Comunicação 64

65 Testes de Software 1. Depuração e diagnóstico de funcionamento do software por meio da leitura de template armazenado em disco, processamento e validação do envio ao microprocessador Nios II. Esse teste foi feito utilizando o mostrador LCD para validação dos dados recebidos pelo microprocessador Nios II. 2. Depuração e diagnóstico de funcionamento do software por meio do recebimento de template do microprocessador Nios II com a correspondende validação do processamento e armazenamento do template recebido. 3. Depuração e diagnóstico de funcionamento do software por meio da geração de template com a correspondende validação do processamento, armazenamento e leitura. Inicialmente foi criado o grafo da equação de 2º grau o qual pode ser visualizado na Figura 5.25 e após foi gerado o template que pode ser observado na Tabela 5.3. Figura 5.25: Grafo da Equação de 2º Grau Tabela 5-3: Template Gerado Tabela de Templates Endereço Op1 Chk Op2 Chk Dest Port Dest Port Operação Op1 Op * * * fim 65

66 5.6. Resultados do Projeto Como resultado do projeto obtém-se a montagem e a transferência de templates para o Núcelo AP, onde o processamento é realizado. Na Figura 5.26 pode ser visualizado o cálculo realizado por meio da tela do software montador. Figura 5.26: Resultado do Cálculo da Equação de 2º Grau 5.7. Problemas Encontrados no Desenvolvimento do Projeto Abaixo se enumeram os problemas encontrados durante a implementação dos componentes do projeto. Durante a simulação da interface verificou-se que havia falta de sincronismo entre a memória e as filas de armazenamento de templates do elemento processador. A solução encontrada foi fazer com que as filas trabalhassem na borda de descida do relógio ao invés da borda de subida. Durante os testes de cálculo, verificou-se que havia travamento do Núcleo AP quando o segundo operando seria disponibilizado pelo elemento processador. Durante a análise do componente controlador de filas, verificou-se que uma das filas não estava sendo processada por erro na lógica de tratamento das filas. Durante os testes de cálculo, verificou-se que havia travamento do Núcleo AP quando os dois operandos seriam disponibilizados por meio do cálculo pelo elemento processador. Por meio de análise do componente controlador de filas, verificou-se que a inicialização do componente não estava ocorrendo. A solução encontrada foi a correção do sinal de inicialização. 66

67 CAPÍTULO CONCLUSÃO Com os resultados obtidos no projeto pode-se observar que o interfaceamendo entre o software Montador de Templates e a Máquina de Processamento Paralelo utilizando-se o processador embarcado Nios II permite grande flexibilidade, pois com a modificação do firmware é possível a inclusão de novas funcionalidades. A arquitetura de hardware do Nios II também é baseada na utilização de componentes que podem ser interligados por um barramento de comunicação e controle, essa arquitetura permite a inserção e remoção de componentes de forma mais flexível que a inserção de componentes em projetos de hardware configurável em projetos totalmente costumizados. Esse conjunto de aspectos permite a redução de custos e maior rapidez na implementação, permitindo que o produto chegue ao mercado mais rapidamente e com preços mais competitivos. Trabalhos futuros podem ser desenvolvidos para a melhoria no desempenho da comunicação entre o microcomputador e a interface embarcada. Essa melhoria pode ser implementada utilizando-se de um driver com maior capacidade de comunicação para a interface USB ou a implementação de uma interface Ethernet com o uso do protocolo TCP/IP o que permitiria acesso remoto à interface. Tanto no firmware quanto no hardware da interface pode-se melhorar o tratamento do fluxo de dados para permitir que a quantidade de templates enviada seja variável ao invés da quantidade fixa da versão atual. 67

68 REFERÊNCIAS BIBLIOGRÁFICAS KARALIS, Edward; Digital Design Principles and Computer Architecture. New Jersey, Prentice-Hall Inc, ISBN ( K18d ). LEE, Weng Fook; VHDL Coding and Logic Syntesis with Synopsys. Diego, Academic Press, ISBN ( VHDL L482v ). COHEN, Bem; VHDL Coding Styles and Methodologies. 2ª ed. Massachusetts, Kluver Academic Publishers, ISBN ( VHDL C678v ). ZAINALABEDIN, Navabi; Embedded Core Design with FPGAs. Hill, ISBN San McGraw- TOCCI, Ronald J.; WIDMER, Neal S. Sistemas Digitais: Princípios e Aplicações. 8ª ed. São Paulo, Prentice Hall, ISBN ( T631s ). TANENBAUM, A. S. Organização Estruturada de Computadores. Rio de Janeiro, LTC, FERLIN, E. P. Proposta de uma Arquitetura Paralela de Alto Desempenho Aplicada a Métodos Numéricos. Curitiba, BARR, M. Programmable Logic: What's it to You?. Embedded Systems Programming, ROTH, C. H. Digital Systems Design Using VHDL. Boston. PWS Publishing, YALAMANCHILI, S. VHDL starter's guide. Upper Saddle River, New Jersey, Prentice Hall, ALTERA CORPORATION, Quartus II Development Software Handbook v5.1 (Complete Five-Volume Set) disponível em < Acesso em fevereiro de ALTERA CORPORATION, Quartus II Version 6.1 Handbook - Volume 4 SOPC Builder disponível em < Acesso em fevereiro de ALTERA CORPORATION, Nios II Software Developer s Handbook disponível em < Acesso em fevereiro de ALTERA CORPORATION, Introduction to the Altera SOPC Builder disponível na em < Acesso em fevereiro de ALTERA CORPORATION, Nios II Processor Reference Handbook disponível na Internet em < Acesso em fevereiro de ALTERA CORPORATION, DE2 Development and Education Board - User Manual disponível em 68

69 < fevereiro de Acesso em 69

70 PÁGINAS DA INTERNET VISITADAS Página do fabricante Altera : Página do fabricante Terasic : 70

71 ANEXO - A DIAGRAMA DE CONEXÕES ENTRE INTERFACES Figura A.27: Conexões entre Interfaces 71

72 ANEXO - B SIMULAÇÃO DO FUNCIONAMENTO DA INTERFACE Figura B.28: Simulação do Funcionamento entre Interfaces 72

73 Figura B.29: Componente VHDL - Simulação do Funcionamento entre Interfaces 73

74 ANEXO - C MANUAL DO USUÁRIO O Manual do Usuário destina-se a apresentar a instalação, configuração e utilização do sistema, assim como os requisitos de software e hardware e os componentes do sistema. 2. REQUISITOS E COMPONENTES Requisitos de hardware: Placa de desenvolvimento Altera DE2; Computador PC com interface USB e porta paralela; Cabo de comunicação da porta paralela, com uma extremidade com o conector DB-25 macho e na outra extremidade um cabo flat. Requisitos de software: Sistema operacional Windows 2000 ou XP; Quartus II 5.1 ou superior; Driver do cabo USB-Blaster. Componentes do sistema: Software Montador de Templates; Arquivos das duas versões do projeto da máquina paralela (versão com 4 EPs e versão com 16) a serem utilizados no Quartus II. 3. INSTALAÇÃO E CONFIGURAÇÃO Instalação A instalação do sistema é feita apenas pela cópia dos arquivos no disco rígido. Para a utilização do software Montador, é necessário apenas o arquivo executável, que pode ser executado de qualquer mídia, como disco rígido ou CD. Os arquivos do projeto da interface devem estar armazenados no disco rígido em pastas com permissões para leitura e gravação, pois estes serão utilizados no Quartus II, que faz alterações em alguns arquivos durante a utilização. Porta USB: Para permitir a comunicação entre o microcomputador e o kit DE2, deve ser instalado o driver Easy12 que está localizado na pasta <Driver USB> na mesma pasta onde está o software montador. 74

75 Número de EPs: O número de EPs que será utilizado na execução da máquina paralela pode ser selecionado na tela de execução de templates. Pode-se escolher entre um e quatro EPs para cada seção de memória. Quartus II: As configurações de dispositivo e pinagem são feitas automaticamente pelo software ao abrir o projeto. Uma configuração do Quartus II que pode ser necessária é a alteração do hardware JTAG (interface por onde será feita a programação do FPGA) na tela de programação, que deve ser USB-Blaster. A opção Program/Configure deve estar habilitada e o arquivo de extensão sof deve estar aparecendo no campo File. 3. UTILIZAÇÃO DO SISTEMA 3.1. Montagem do hardware Para a execução no FPGA, a placa Altera DE2 deve estar ligada e conectada com o computador pelo cabo USB-Blaster Programação do FPGA O usuário deve escolher qual versão do projeto deseja executar: a versão com 4 EPs ou com 16. O projeto deve ser aberto no Quartus II, em seguida, deve-se clicar no botão de programação do FPGA, ou no menu Tools -> Programmer. Figura C.30: Botão de programação do FPGA com o projeto aberto no Quartus II. 75

76 Na tela de programação, o campo Hardware Setup deve estar como mostra a Figura C.32. Clicar em Start, o FPGA será programado com o projeto. Figura C.31: Tela de programação do FPGA no Quartus II Execução do software Primeiramente o usuário deve executar o Software Montador de Templates pelo arquivo Montador.exe. Em seguida o usuário deve abrir um arquivo do tipo mnt existente ou criar um novo. Para criar um arquivo novo, basta digitar os campos dos templates e clicar no botão Incluir, o template será incluído no endereço indicado na caixa Endereço. Pode-se incluir um template em um endereço que não esteja vazio, nesse caso este será substituído. Para excluir um template, deve-se indicar o endereço que se deseja excluir na caixa Endereço e clicar no botão Excluir. Para iniciar a utilização do sistema, o usuário pode também abrir um arquivo existente, no botão Abrir. Figura C.32: Tela principal do software Montador. 76

77 3.4. Execução na máquina paralela Para executar o arquivo com a extensão mnt na máquina paralela, voltar ao software montador e pressionar o botão Executar. Será apresentada a janela de execução. Figura C.33: Tela de execução dos templates na máquina paralela. Se o arquivo mnt aberto não estiver salvo, será apresentada uma mensagem avisando que o arquivo deve ser salvo antes de executá-lo. Clicar no botão Executar da janela de execução. Os templates serão enviados, executados e os operandos lidos da máquina paralela após o processamento serão exibidos na caixa de texto Outros recursos O software possui as funcionalidades básicas para manipulação de arquivos: Novo, Abrir, Salvar e Salvar Como. Isso permite que vários arquivos de templates sejam criados e armazenados em disco. 77

78 ANEXO - D MANUAL TÉCNICO O manual técnico tem por objetivo apresentar os requisitos para o funcionamento do sistema e as configurações necessárias, bem como os principais erros que podem ocorrer durante a sua utilização. 1. Requisitos e Componentes Requisitos de hardware: Placa de desenvolvimento Altera DE2; Computador PC com interface USB; Cabo de comunicação USB. Requisitos de software: Sistema operacional Windows 2000 ou XP; Quartus II versão 7.1 ou superior; Driver de comunicaçãoo USB-Blaster. Driver de comunicação Easy12. Componentes do sistema: Software Montador de Templates; Arquivos do projeto da interface a serem utilizados no Quartus II. 2. Configurações Quartus II: As configurações de dispositivo e pinagem são feitas automaticamente pelo software ao abrir o projeto. Uma configuração do Quartus II que pode ser necessária é a alteração do hardware JTAG (interface por onde será feita a programação do FPGA) na tela de programação, que deve ser USB-Blaster. A opção Program/Configure deve estar habilitada e o arquivo de extensão sof deve estar aparecendo no campo File. 4. Erros Erro de comunicação: Quando não é possível completar a transmissão de dados entre o FPGA e o host, uma mensagem de erro de comunicação é apresentada ao usuário. O motivo do 78

79 problema pode ser a configuração da porta USB. Faltando USB-Blaster: Na tela de programação do FPGA no Quartus II, se na configuração do hardware não estiver disponível o USB-Blaster, pode estar faltando o driver. Deve-se instalar o driver, que está disponível dentro da pasta de instalação do Quartus II, normalmente em C:\altera\quartus51\drivers\usb-blaster. 79

80 ANEXO - E CRONOGRAMA Tabela E-4: Cronograma do Projeto Atividade Duração ( dias ) Data de Início Data de Término Proposta 15 Seg 12/02/07 Seg 05/03/07 Definição da proposta 5 Seg 12/20/07 Seg 16/02/07 Documentação da Proposta 10 Seg 19/02/07 Sex 02/03/07 Envio ao orientador para revisão 2 Seg 19/02/07 Ter 20/02/07 Correções necessárias 3 Qua 21/02/07 Sex 23/02/07 Envio ao orientador para revisão 2 Seg 26/02/07 Ter 27/02/07 Correções finais 3 Qua 28/02/07 Sex 02/03/07 Entrega da proposta 0 Seg 05/03/07 Seg 05/03/07 Especificações Técnicas 21 Seg 05/03/07 Seg 02/04/07 Definição da Arquitetura 10 Seg 05/03/07 Sex 16/03/07 Definição dos Recursos Necessários 3 Seg 19/03/07 Qua 21/03/07 Definição do Software Necessário 2 Seg 19/03/07 Ter 20/03/07 Definição do Hardware Necessário 1 Qua 21/03/07 Qua 21/03/07 Documentação das Especificações 8 Qua 21/03/07 Sex 30/03/07 Redação do Documento de Especificação 3 Qua 21/03/07 Sex 23/03/07 Apresentação ao orientador para revisão 2 Seg 26/03/07 Ter 27/03/07 Correções necessárias 1 Qua 28/03/07 Qua 28/03/07 Reapresentação ao orientador para Revisão 1 Qui 29/03/07 Qui 29/03/07 Correções finais 2 Qui 29/03/07 Sex 30/03/07 Entrega das especificações 0 Seg 02/04/07 Seg 02/04/07 Monografia e Testes Preliminares 50 Ter 03/04/07 Seg 11/06/07 Download e Instalação das Ferramentas da Altera 3 Ter 03/04/07 Qui 05/04/07 Download e Instalação Quartus II Ter 03/04/07 Ter 03/04/07 Download e Instalação SOPC Buider Qua 04/04/07 Qua 04/04/07 Download e Instalação Nios II IDE 1 Qui 05/04/07 Qui 05/04/07 Estudo da documentação do NIOS II 5 Seg 09/04/07 Sex 13/04/07 Nios II Flash Programmer - User Guide 1 Seg 09/04/07 Seg 09/04/07 Quartus II Version 6.1 Handbook - Volume 4 SOPC Builder 1 Ter 10/04/07 Ter 10/04/07 Nios II Software Developer s Handbook 1 Qua 11/04/07 Qua 11/04/07 Nios II Hardware Development Tutorial 1 Qui 12/04/07 Qui 12/04/07 Nios II Processor Reference Handbook 1 Sex 13/04/07 Sex 13/04/07 Estudo da Ferramenta SOPC Builder 1 Seg 16/04/07 Seg 16/04/07 Introduction to the Altera SOPC Builder 1 Seg 16/04/07 Seg 16/04/07 Estudo da Ferramenta Nios II IDE 1 Ter 17/04/07 Ter 17/04/07 Leitura da Ajuda da Ferramenta Nios II IDE 1 Ter 17/04/07 Ter 17/04/07 80

81 Atividade Duração ( dias ) Data de Início Data de Término Estudo do Kit de Desenvolvimento para NIOS II 8 Qua 18/04/07 Sex 27/04/07 Download e Instalação do CD do kit de desenvolvimento DE2 1 Qua 18/04/07 Qua 18/04/07 Leitura do Manual do Kit de Desenvolvimento 1 Qui 19/04/07 Qui 19/04/07 Estudo de Projetos Exemplo para o Kit Nios II 5 Seg 23/04/07 Sex 27/04/07 Estudo do Projeto do Aluno Maurício Brodzinski 3 Seg 30/04/07 Qua 02/05/07 Monografia 1 Seg 30/04/07 Seg 30/04/07 Projeto de hardware Quartus II 2 Ter 01/05/07 Qua 02/05/07 Estudo do Projeto do Aluno Hamon Veloso da Silva 2 Qui 03/05/07 Sex 04/05/07 Monografia 1 Qui 03/05/07 Qui 03/05/07 Projeto de hardware Quartus II 1 Sex 04/05/07 Sex 04/05/07 Montagem de Protótipo para Prova de Conceito 25 Seg 07/05/07 Sex 08/06/07 Pedido de Orientação 1 Seg 07/05/07 Seg 07/05/07 Especificação do Protótipo da Interface 1 Ter 08/05/07 Ter 08/05/07 Desenvolvimento do Protótipo 3 Qua 09/05/07 Sex 11/05/07 Apresentação ao Orientador 1 Seg 14/05/07 Seg 14/05/07 Testes e Depuração 4 Ter 15/05/07 Sex 18/05/07 Apresentação ao Orientador 1 Seg 21/05/07 Seg 21/05/07 Redação da Monografia 4 Ter 22/05/07 Sex 25/05/07 Apresentação para Revisão 3 Seg 28/05/07 Qua 30/05/07 Correções na Monografia 2 Qui 07/06/07 Sex 08/06/07 Entrega da Monografia e Testes Preliminares 0 Seg 11/06/07 Seg 11/06/07 Apresentação Prévia do Projeto 39 Ter 12/06/07 Seg 06/08/07 Implementação da Interface 14 Ter 12/06/07 Sex 29/06/07 Implementação 4 Ter 12/06/07 Sex 15/06/07 Pedido de orientação 1 Seg 18/06/07 Seg 18/06/07 Implementação 4 Ter 19/06/07 Sex 22/06/07 Pedido de orientação 1 Seg 25/06/07 Seg 25/06/07 Implementação 4 Ter 26/06/07 Sex 29/06/07 Implementação do Cálculo com Ponto Flutuante 25 Seg 02/07/07 Sex 03/08/07 Pedido de Orientação 1 Seg 02/07/07 Seg 02/07/07 Implementação do Cálculo 4 Ter 03/07/07 Sex 06/07/07 Pedido de Orientação 1 Seg 09/07/07 Seg 09/07/07 Implementação do Cálculo 4 Ter 10/07/07 Sex 13/07/07 Pedido de Orientação 1 Seg 16/07/07 Seg 16/07/07 Implementação do Cálculo 4 Ter 17/07/07 Sex 20/07/07 Pedido de Orientação 1 Seg 23/07/07 Seg 23/07/07 Depuração e Testes 4 Ter 24/07/07 Sex 27/07/07 Pedido de Orientação 1 Seg 30/07/07 Seg 30/07/07 Depuração e Testes 4 Ter 31/07/07 Sex 03/08/07 Entrega Prévia do Projeto 0 Seg 06/08/07 Seg 06/08/07 81

82 Atividade Duração ( dias ) Data de Início Data de Término Apresentação do Projeto 39 Ter 07/8/07 Seg 01/10/07 Melhorias na Arquitetura 4 Ter 07/08/07 Sex 10/08/07 Pedido de Orientação 1 Seg 13/08/07 Seg 13/08/07 Melhorias na Arquitetura 4 Ter 14/08/07 Sex 17/08/07 Pedido de Orientação 1 Seg 20/08/07 Seg 20/08/07 Depuração e Testes 4 Ter 21/08/07 Sex 24/08/07 Pedido de Orientação 1 Seg 27/08/07 Seg 27/08/07 Depuração e Testes 4 Ter 28/08/07 Sex 31/08/07 Fim do Desenvolvimento da Arquitetura 0 Sex 31/08/07 Sex 31/08/07 Pedido de Orientação 1 Seg 03/09/07 Seg 03/09/07 Ampliação da Monografia 4 Ter 04/09/07 Sex 07/09/07 Pedido de Orientação 1 Seg 10/09/07 Seg 10/09/07 Ampliação da Monografia 4 Ter 11/09/07 Sex 14/09/07 Pedido de Orientação 1 Seg 17/09/07 Seg 17/09/07 Ampliação da Monografia 4 Ter 18/09/07 Sex 21/09/07 Pedido de Orientação 1 Seg 24/09/07 Seg 24/09/07 Redação do Artigo Científico 4 Ter 25/09/07 Sex 28/09/07 Apresentação do Projeto 0 Seg 01/10/07 Seg 01/10/07 Entrega da Documentação Completa em Espiral 25 Ter 02/10/07 Seg 05/11/07 Revisão da Monografia 4 Ter 02/10/07 Sex 05/10/07 Revisão do Manual do Usuário 5 Seg 08/10/07 Sex 12/10/07 Revisão do Manual Técnico 5 Seg 15/10/07 Sex 19/10/07 Revisão do Artigo Científico 5 Seg 22/10/07 Sex 26/10/07 Encadernação dos Documentos 5 Seg 29/10/07 Sex 02/11/07 Entrega da Documentação 0 Seg 05/11/07 Seg 05/11/07 Defesa Formal do Projeto 14 Ter 06/11/07 Seg 26/11/07 Confecção da Apresentação 14 Ter 06/11/07 Sex 23/11/07 Apresentação do Projeto 0 Seg 26/11/07 Seg 26/11/07 Entrega da Documentação Final em Capa Dura 9 Ter 27/11/07 Seg 10/12/07 Encadernação dos Documentos 8 Ter 27/11/07 Qui 06/12/07 Confecção da Página Web 8 Ter 27/11/07 Qui 06/12/07 Confecção do CD 1 Sex 07/12/07 Sex 07/12/07 Entrega da Documentação 0 Seg 10/12/07 Seg 10/12/07 82

83 ANEXO - F ESTUDO DE VIABILIDADE O estudo de viabilidade deve analisar a disponibilidade de instalações, recursos humanos, materiais necessários e recursos financeiros. 1. Instalações Para viabilidade na questão de instalações deve-se analisar se essas são suficientes para a realização de todas as etapas do projeto. O curso disponibiliza para os alunos os laboratórios, biblioteca e instalações complementares. Essas instalações são suficientes para viabilizar o projeto, pois apresentam as condições necessárias e suficientes para abrigá-lo. 2. Recursos Humanos Os recursos humanos disponibilizados compreendem o orientador do projeto, a banca de professores que fazem o acompanhamento do projeto e laboratoristas responsáveis pela disponibilização das instalações. O aluno propõe-se a disponibilizar tempo em quantidade suficiente para a materialização do projeto. A disponibilidade desses recursos viabiliza o projeto em relação ao conhecimento e experiência necessários à sua concretização. 3. Recursos Financeiros Por se tratar de um projeto acadêmico de graduação a disponibilidade de recursos financeiros é muito limitada, tanto por parte da instituição quanto por parte do aluno. A viabilidade financeira do projeto somente é possível caso a utilização de recursos financeiros seja mínima. O projeto final em questão está viabilizado financeiramente, pois a utilização de recursos financeiros será minimizada e restrita à compra de materiais de escritório, impressão de documentos, acesso à Internet, energia elétrica, alimentação e custos de locomoção do aluno até a instituição, com fins de utilização das instalações. A utilização das instalações acadêmicas ajuda a reduzir os custos de aquisição de energia elétrica e acesso pago à Internet melhorando a viabilidade financeira. 4. Recursos Materiais Essa é a parte mais crítica para a viabilidade do projeto, pois os recursos materiais necessários ao projeto envolvem itens de alta tecnologia como software e componentes dedicados do fabricante Altera materializados em um kit de desenvolvimento para o 83

84 processador Nios II. Também há a necessidade de microcomputador e software de infraestrutura para editoração de documentos, controle de cronograma, desenvolvimento de software. Esses recursos são disponibilizados pelo aluno e pelo Curso de Engenharia da Computação o que permite a viabilidade do projeto com relação aos recursos materiais necessários. Na Tabela 5-2 pode-se visualizar o custo aproximado dos recursos materiais disponibilizados, não sendo necessária sua aquisição para o desenvolvimento do projeto. Tabela F-5: Materiais Disponibilizados - Resumo de Custos Componente Subtotal Kit de desenvolvimento Altera R$ 570,00 Microcomputador pessoal R$ 2.000,00 Ferramenta Borland C++ R$ 1800,00 Microsoft Word ( Versão Acadêmica ) R$ 133,00 Microsoft Excel ( Versão Acadêmica ) R$ 133,00 Total R$ 4.633,00 5. Custos Diretos O tempo de desenvolvimento contabilizado, em torno de 500 horas, tem custo aproximado de R$ 5000,00. Há também a necessidade de conexão com a Internet para busca de documentação para o desenvolvimento, em torno de R$ 400,00. Os custos de impressão são em torno de R$ 300,00. O Material de escritório necessário exige um gasto de aproximadamente R$ 150,00. Na Tabela 5.3 pode-se visualizar um resumo dos custos diretos envolvidos no projeto. Tabela F-6: Resumo de Custos Diretos do Projeto Componente Subtotal Recursos humanos especializados R$ 5.000,00 Custo de acesso à Internet R$ 400,00 Custo de impressão R$ 300,00 Material de Escritório R$ 150,00 Total R$ 5.850,00 84

85 ANEXO - G - ARTIGO INTERFACE RECONFIGURÁVEL PARA ARQUITETURA PARALELA BASEADA EM PROCESSADOR EMBARCADO NIOS II Antonio Edson Ceccon 1, Edson Pedro Ferlin 2 Curso de Engenharia da Computação - Centro Universitário Positivo - UnicenP cecconae@ig.com.br Resumo. Com a crescente demanda por capacidade de processamento em diversas áreas, as pesquisas na área de processamento paralelo são cada vez mais freqüentes. O processamento paralelo existe em sistemas com vários processadores operando simultaneamente sobre as mesmas tarefas. Para controlar o processamento há a necessidade de interfaces, o objetivo deste projeto é desenvolver uma interface por meio da computação reconfigurável, utilizando-se FPGA (Field Programmable Gate Array), que é um dos tipos de dispositivos lógicos programáveis, os quais permitem que o projeto seja implementado sem a necessidade de construção física dos componentes, aumentando a produtividade e a flexibilidade no desenvolvimento do projeto. A arquitetura do projeto é desenvolvida baseada no processador embarcado Nios II da Altera para uma arquitetura paralela reconfigurável aplicada ao cálculo numérico. O projeto visa obter um ganho crescente de desempenho por meio de uma arquitetura padronizada e de menor custo de manutenção. Palavras-chave: Nios II, processador embarcado, VHDL, FPGA, processamento paralelo. 1. INTRODUÇÃO Apesar do grande avanço na área de computadores, as arquiteturas reconfiguráveis possuem um grande campo de atuação na engenharia e nas ciências, pois existe uma necessidade crescente de poder computacional e flexibilidade que uma arquitetura reconfigurável pode proporcionar. Entre todos os campos de estudo associados com projeto de sistemas embarcados, as tecnologias de software e hardware, em particular dos processadores, são as que têm experimentado a evolução mais rápida (FERLIN, 2005). Em função dessa evolução acelerada tecnológica, a idéia de se utilizar estruturas abertas e 1 Concluinte do Curso. 2 Professor Orientador. 85 reconfiguráveis que possam adaptar-se a novas demandas torna-se muito atraente. Isto pode até ser um pré-requisito na consideração de projetos de sistemas embarcados. Sistemas de desenvolvimento baseados em computação reconfigurável (sistemas de hardware reconfigurável) apresentam características adequadas para uso nesta classe de projetos. Eles apresentam, dentre outras vantagens, as características de baixo consumo, alta velocidade de operação, capacidade de integração, flexibilidade, facilidade de programação e operação modular. Este projeto utiliza uma arquitetura reconfigurável, que emprega os conceitos de Arquitetura de Computadores para obter um desempenho escalável, tendo sua proposta lançada a partir de outro projeto desenvolvido no Centro Universitário Positivo UnicenP em Neste projeto há a necessidade do desenvolvimento de uma interface de comunicação com grande desempenho no gerenciamento de informações, arquitetura padronizada e menor custo de manutenção. Para que esses requisitos sejam satisfeitos utiliza-se o processador embarcado Nios II da Altera Motivação No ano de 2006 foi desenvolvida uma versão básica de uma arquitetura paralela reconfigurável. Contudo existe a necessidade de uma interface que facilite o envio de informações de configuração, dos programas e dados a serem processados a partir de um computador front-end. Essa interface será utilizada também para retornar os resultados para esse computador Contextualização Embora os computadores estejam cada vez mais velozes (TANENBAUM, 2001), as exigências sobre eles crescem mais rapidamente do que a sua capacidade de processamento. Apesar da grande potência computacional disponível nos computadores utilizados nos mais diferentes ramos de atividade, ela não é suficiente para muitas aplicações. A velocidade de operação dos processadores está sempre crescendo, mas não podem continuar assim indefinidamente, pois existem limitações físicas que em algum momento impedirão a evolução dos processadores como é feito atualmente. Em razão disso os projetistas de computadores estão se voltando para os computadores paralelos, em busca de arquiteturas que utilizem vários processadores para obter ganho de desempenho em relação a computadores que operam por meio de um

86 único processador. Para a operação dessas máquinas paralelas há a necessidade de um conjunto de interfaces de controle. Esse projeto está relacionado ao desenvolvimento de uma interface entre o computador no qual estão as informações a serem processadas e a máquina paralela que realizará o processamento Principais Funcionalidades O projeto será composto de um software montador de templates, da interface a ser desenvolvida e da arquitetura paralela desenvolvida no ano O software montador de templates será executado em um microcomputador sendo o responsável pelo fornecimento das informações que serão processados pela máquina paralela. A interface apresenta-se como um componente de hardware embarcado em FPGA, sendo responsável pelo gerenciamento do fluxo de informações vindas do microcomputador e que devem ser enviadas à máquina paralela. Essa configuração em hardware foi adotada a fim de proporcionar maior desempenho, o que é conseguido devido à integração da interface com a máquina paralela por meio do processador Nios II que utiliza um barramento de alta velocidade e grande capacidade de processamento, denominado de Avalon, para a comunicação com a máquina paralela. Essa configuração apresenta melhor desempenho em relação à interface paralela atualmente implantada, pois a largura do barramento permite um fluxo maior de informações e com alta velocidade. A arquitetura paralela é composta por uma unidade de controle que efetua a distribuição de processamento e de vários Elementos Processadores ( EPs ) que são responsáveis pelo processamento Tecnologia Utilizada A interface foi implementada em lógica programável usando FPGA do fabricante Altera e o processador embarcado Nios II fornecido como IP (Intelectual Property). Utilizou-se como sistema de desenvolvimento as ferramentas Quartus II da Altera, o Ambiente Integrado de Desenvolvimento para o Processador NIOS, o ambiente SOPC Builder e o kit eletrônico contendo os dispositivos programáveis. 2. FUNDAMENTAÇÃO TEÓRICA 2.1. Software Embarcado Para o controle do fluxo de dados entre o microcomputador e a máquina paralela, utiliza-se o conceito de software embarcado chamado de firmware que é o responsável pela inicialização da interface de controle, diagnóstico de falhas e controle do fluxo de informações de e para a máquina paralela. possuem uma única memória para os dados e para as instruções e não possuem um apontador de instruções como no modelo Von Neumann. Os sistemas Fluxo de Dados não possuem variáveis, pois os valores são representados por pacotes que são transmitidos entre os processadores. Cada processador possui a tarefa de executar alguma operação com sua entrada e produzir uma saída contendo o resultado. Nesse caso cada operação depende somente de suas entradas Modelo de Processamento Embarcado A interface utiliza o conceito de processamento embarcado, em que pela combinação de lógica, memória e núcleo de processamento configurável é possível o desenho de sistemas inteiros em um único componente eletrônico Linguagem de Descrição de Hardware Como a tecnologia de circuitos integrados tem sido melhorada para permitir mais componentes em um chip, sistemas digitais continuam a aumentar a complexidade consumindo mais tempo para o detalhamento dos sistemas no nível de portas e flipflops consome muito tempo. Uma linguagem de descrição de hardware permite a um sistema digital ser desenvolvido e depurado em um nível mais alto antes da conversão para o nível de portas e flip-flop. As linguagens mais populares para descrição de hardware são VHDL (VHSIC Hardware Description Language) (COHEN, 1999) e Verilog (ROTH, 1998) Computação Reconfigurável A idéia da utilização de hardware reconfigurável no desenvolvimento de computadores reconfiguráveis surgiu na década de 60. Contudo, a primeira demonstração prática só ocorreu na década de 80 com o advento dos dispositivos reprogramáveis, como no caso os FPGAs (Field-Programmable Gate Array) (TOCCI & WIDMER, 2003). A Computação Reconfigurável tem por objetivo a utilização de dispositivos lógicos programáveis (PLD Programmable Logic Devices) para dispensar a construção de circuitos digitais específicos à aplicação. A computação reconfigurável pode ser entendida como uma solução intermediária entre ASIC (Application- Specific Integrated Circuits) e microprocessadores, combinando vantagens das duas áreas, como mostrado na Figura Modelo de Fluxo de Dados A arquitetura Fluxo de Dados (Data Flow) surgiu no final da década de 70 para explorar o paralelismo entre as instruções de um programa. Essas máquinas Figura 2.1: Posicionamento da Computação Reconfigurável. (Fonte: FERLIN, 2005) 86

87 3. DESENVOLVIMENTO Com o estabelecimento dos requisitos torna-se possível a construção lógica da interface de controle que pode ser visualizada na Figura Sistema de Firmware O firmware deve implementar a comunicação entre o software do microcomputador e o processador Nios II através da interface USB. Também deve implementar a comunicação entre o processador Nios II e o Núcleo AP para o envio de templates e recebimento de resultados processados pelo Núcleo AP. Para que a comunicação possa ocorrer de forma adequada deve ser implementado um protocolo de comunicação baseado na troca de comandos entre o host e a interface embarcada na FPGA, na Figura 3.14 pode ser visualizada a estrutura do pacote utilizado para a troca de informações entre a Interface de Controle e o host. Na Figura 3.3 pode-se observar o fluxo de processamento. Figura 3.34: Interface de Controle 3.1. Sistema de Software A versão do software desenvolvida em 2006, utilizava a comunicação paralela padrão CENTRONICS, a qual foi substituída pela comunicação USB. Na implementação das rotinas de comunicação deve-se utilizar o driver fornecido com o kit DE2 denominado EasyD12. Esse driver disponibiliza uma biblioteca na forma de DLL para o sistema operacional Windows. Para o controle de fluxo na comunicação deve ser implementado um protocolo comum ao software e firmware. Na Figura 3.2 pode ser visualizado o diagrama de classe do componente. Figura 3.3: Fluxo de Processamento do Firmware 4. IMPLEMENTAÇÃO 4.1. Subsistema Nios II Figura 3.2: Diagrama de Classe O subsistema Nios II faz parte do hardware e compõem-se dos seguintes componentes : Processador Nios II. Controlador SDRAM. Controlador de comunicação USB. Temporizador. 87

88 Identificador de Sistema. Banco de registradores. Núcleo AP Firmware O desenvolvimento do firmware para o projeto faz-se utilizando a ferramenta Nios IDE sendo escrito em linguagem C/C++. O firmware implementa a comunicação entre o software, o microprocessador Nios II e o Núcleo AP. velocidade disponível diretamente pelo kit DE2. Para avaliar o desempenho foram realizados testes com velocidades entre 25 e 100 MHz através de um circuito PLL ( Phased Locked Loop ). No gráfico da Figura 5.2 pode-se observar o ganho de desempenho obtido em função do aumento da velocidade do processador. O teste foi realizado utilizando-se o template para cálculo da equação de 2º grau com dez mil iterações. 5. TESTES REALIZADOS 5.1. Testes de Firmware 1. Depuração e diagnóstico de funcionamento do firmware através da interligação do kit DE2 com um microcomputador. Nesse teste foi validado o correto recebimento e envio de dados de e para o microcomputador. 2. Depuração e diagnóstico de funcionamento do firmware através da interligação do subsistema Nios II com a Arquitetura Paralela. Nesse teste foi validado o correto recebimento e envio de dados de e para a Arquitetura Paralela (memória de armazenamento ). 3. Na primeira versão do firmware utilizava-se a interface USB com tamanho de pacotes de 8 bytes. Posteriormente foram realizados testes com o aumento progressivo do tamanho do pacote até 64 bytes, que é o tamanho máximo permitido pelo driver Easy12 que é disponibilizado pelo kit DE2. Na Figura 5.1 pode-se observar o ganho de desempenho na comunicação entre o microcomputador e o microprocessador Nios II. O teste foi realizado com o envio do template para cálculo da equação de 2º grau. Figura 5.35: Desempenho da Comunicação 5.2. Testes de Hardware 4. Depuração e diagnóstico de funcionamento do Núcleo Controlador AP, por meio da criação de componente de hardware responsável pelo envio de templates para a Arquitetura Paralela. Nesse teste foi feita a simulação de funcionamento na ferramenta Quartus II. 5. Inicialmente a velocidade de clock utilizada para o subsistema Nios II foi 50MHz, sendo essa Figura 5.2: Desempenho do Subsistema Nios II 6. Inicialmente utilizou-se o modelo de processador Nios II/e. Para melhorar o desempenho foram realizados testes com outros dois modelos disponíveis. No gráfico da Figura 5.3 pode-se observar o ganho de desempenho obtido em função do modelo utilizado para processamento. O teste foi realizado utilizando-se o template para cálculo da equação de 2º grau com dez mil iterações. Figura 5.3: Desempenho do Processamento 5.3 Testes de Software 6. Depuração e diagnóstico de funcionamento do software por meio da leitura de template armazenado em disco, processamento e validação do envio ao microprocessador Nios II. Esse teste foi feito utilizando o mostrador LCD para validação dos dados recebidos pelo microprocessador Nios II. 7. Depuração e diagnóstico de funcionamento do software por meio do recebimento de template do microprocessador Nios II com a correspondende validação do processamento e armazenamento do template recebido. 8. Depuração e diagnóstico de funcionamento do software por meio da geração de template com a correspondente validação do processamento, armazenamento e leitura. Inicialmente foi criado o grafo da equação de 2º grau o qual pode ser visualizado na Figura 5.4 e após foi gerado o template que pode ser observado na Tabela

89 TCP/IP o que permitiria acesso remoto à interface. Tanto no firmware quanto no hardware da interface pode-se melhorar o tratamento do fluxo de dados para permitir que a quantidade de templates enviada seja variável ao invés da quantidade fixa da versão atual. 7. REFERÊNCIAS BIBLIOGRÁFICAS Figura 5.436: Grafo da Equação de 2º grau 5.4. Resultados Como resultado do projeto obtém-se a montagem e a transferência de templates para o Núcleo AP, no qual há o processamento. Na Figura 5.5 pode ser visualizado o cálculo realizado através da tela do software montador. 1- KARALIS, Edward; Digital Design Principles and Computer Architecture. New Jersey, Prentice-Hall Inc, LEE, Weng Fook. VHDL Coding and Logic Syntesis with Synopsys. San Diego, Academic Press, COHEN, Bem; VHDL Coding Styles and Methodologies. 2ª ed. Massachusetts, Kluver Academic Publishers, ZAINALABEDIN, Navabi; Embedded Core Design with FPGAs. McGraw-Hill, TOCCI, Ronald J.; WIDMER, Neal S. Sistemas Digitais: Princípios e Aplicações. 8ª ed. São Paulo, Prentice Hall, TANENBAUM, A. S. Organização Estruturada de Computadores. Rio de Janeiro, LTC, FERLIN, E. P. Proposta de uma Arquitetura Paralela de Alto Desempenho Aplicada a Métodos Numéricos. Curitiba, Figura 5.5: Tela de Visualização do Cálculo 6. CONCLUSÃO Por meio dos resultados obtidos no projeto podese observar que o interfaceamendo entre o software Montador de Templates e a Máquina de Processamento Paralelo utilizando-se o processador embarcado Nios II permite grande flexibilidade, pois através da modificação do firmware é possível a inclusão de novas funcionalidades. A arquitetura de hardware do Nios II também é baseada na utilização de componentes que podem ser interligados por um barramento de comunicação e controle, essa arquitetura permite a inserção e remoção de componentes de forma mais flexível que a inserção de componentes em projetos de hardware configurável em projetos totalmente costumizados. Esse conjunto de aspectos permite a redução de custos e maior rapidez na implementação, permitindo que o produto chegue ao mercado mais rapidamente e com preços mais competitivos. Trabalhos futuros podem ser desenvolvidos para a melhoria no desempenho da comunicação entre o microcomputador e a interface embarcada. Essa melhoria pode ser implementada através do uso de um driver com maior capacidade de comunicação para a interface USB ou a implementação de uma interface Ethernet com o uso do protocolo 8- BARR, M. Programmable Logic: What's it to You?. Embedded Systems Programming, ROTH, C. H. Digital Systems Design Using VHDL. Boston. PWS Publishing, YALAMANCHILI, S. VHDL starter's guide. Upper Saddle River, New Jersey, Prentice Hall, ALTERA CORPORATION, Quartus II Development Software Handbook v5.1 (Complete Five-Volume Set) disponível em < handbook.pdf>. Acesso em fevereiro de ALTERA CORPORATION, Quartus II Version 6.1 Handbook - Volume 4 SOPC Builder disponível em < 4.pdf>. Acesso em fevereiro de ALTERA CORPORATION, Nios II Software Developer s Handbook disponível em < v2.pdf>. Acesso em fevereiro de