Guilherme Quentel Melo Modelagem do processador Nios2 para uma plataforma de SoCs

Transcrição

1 Guilherme Quentel Melo Modelagem do processador Nios2 para uma plataforma de SoCs Florianópolis SC 2006/2

2 Guilherme Quentel Melo Modelagem do processador Nios2 para uma plataforma de SoCs Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação. Orientador: Prof. Dr. Luiz Cláudio Villar dos Santos UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE CIÊNCIAS DA COMPUTAÇÃO Florianópolis SC 2006/2

3 Sumário Lista de Figuras Lista de Tabelas 1 Introdução p. 6 2 O Processador Nios 2 p Visão Geral p Registradores p Controlador de exceções p Memória p Memória Cache p Modos de Endereçamento p Conjunto de Instruções p Categorias p Instruções não implementadas p Instruções personalizadas p Formatos de instruções p Diferentes Implementações p Modelagem p A ADL ArchC p Modelo puramente funcional p. 13

4 3.3 Modelo com precisão de ciclos p Resultados Experimentais p Conclusão e Trabalhos Futuros p Atividades Faltantes p. 19 Referências Bibliográficas p. 20

5 Lista de Figuras

6 Lista de Tabelas 2.1 Registradores de uso geral p Implementações do Nios II p Conjunto de programas Mibench p. 18

7 6 1 Introdução A miniaturização está permitindo que cada vez mais dispositivos possuam processadores embutidos. Isso chega a levar a termos em inglês como Disapearing Computer(1), significando que os computadores estão desaparecendo, pois estão cada vez menores. Em razão disso, vê-se um aumento na necessidade de desenvolvimento de softwares para esses dispositivos embarcados. Com a criação de modelos de processadores, pode-se realizar simulações de um mesmo software para vários processadores diferentes e obter uma análise de qual deles possui um melhor desempenho, sem a necessidade de adquirir cada processador. Isso proporciona uma grande economia de tempo e dinheiro. Esse trabalho consiste na utilização de uma Linguagem de Descrição de Arquiteturas (ADL), para a descrição de um processador específico. A ADL escolhida foi a ArchC (2), com a qual alguns processadores e microcontroladores já foram modelados e estão disponíveis em (2). O processador Nios II foi escolhido para a realização desse trabalho por não haver ainda um modelo descrito em ArchC e por ser um processador importante para sistemas embarcados. A descrição desse processador consiste basicamente em duas etapas: Descrição puramente funcional - Implementação das instruções do processador sem levar em consideração a temporização. Descrição com precisão de ciclos - Implementação das instruções do processador com um nível de detalhamento maior, como, por exemplo, a inclusão de informações sobre o pipeline. O processo das duas descrições são semelhantes, ambas consistindo em implementação e testes parciais das instruções, execução de conjuntos de testes para a validação parcial do modelo e certificação do modelo junto à equipe ArchC (2) para a disponibilização em repositório público.

8 1 Introdução 7 O modelo funcional foi obtido a partir de um protótipo implementado por Richard Maciel e o modelo com precisão de ciclos foi criado a partir do primeiro já implementado.

9 8 2 O Processador Nios 2 Esse capítulo apresenta alguns dados obtidos a partir de (3) e (4). 2.1 Visão Geral O Nios R II é um processador desenvolvido pela Altera R (3). para propósitos gerais com uma arquitetura RISC.É um processador voltado para sistemas embarcados, sendo desenvolvido para a implementação em FPGA s, e por isso é o que se chama de softcore. Isso permite uma maior flexibilidade no desenvolvimento de sistemas, pois pode-se testar um sistema diretamente na placa e refiná-lo, adicionando ou retirando componentes, até que se atinja os requisitos necessários, sem precisar gastar com um novo hardware. 2.2 Registradores Existem 32 registradores de 32 bits de uso geral e 6, também de 32 bits, de controle. Há a possibilidade, também, dos registradores de controle serem protegidos contra programas de usuário, utilizando-se os modos supervisor e usuário. A tabela 2.1 lista os registradores de uso geral, com o uso padrão de cada um. 2.3 Controlador de exceções Qualquer exceção no Nios II causa um desvio na execução para um único endereço. O tratador de exceções verifica, então, a causa da exceção e executa a rotina apropriada.

10 2.4 Memória 9 Tabela 2.1: Registradores de uso geral. Registrador Nome Uso Padrão r0 zero Constante 0 r1 at Temporário p/ Montador r2 Valor de Retorno (32 bits menos significativos) r3 Valor de Retorno (32 bits mais significativos) r4 Argumento (Primeiros 32 bits) r5 Argumento (Próximos 32 bits) r6 Argumento (Próximos 32 bits) r7 Argumento (Próximos 32 bits) r8.. r15 Registradores temporários r16.. r23 Registradores salvos pela função chamada r24 et Temporário p/ exceção r25 bt Temporário p/ break r26 gp Global Pointer r27 sp Stack Pointer r28 fp Frame Pointer r29 ea Endereço de Retorno de Exceção r30 ba Endereço de Retorno de Break r31 ra Endereço de Retorno 2.4 Memória Memória Cache A arquitetura Nios II suporta memórias caches separadas para instruções e dados, possibilitando uma melhora no tempo médio de acesso à memória. As caches estão sempre ativas, no entanto há formas de desativá-la, de forma que periféricos possam acessar a memória principal ou memórias de outros dispositivos diretamente Modos de Endereçamento Registrador: Todos os registradores são operandos e o resultado é salvo também em um registrador. Displacement: O endereço é calculado pela soma de um registrador e um valor imediato com sinal. Imediato: Nesse modo, o operando é o próprio valor imediato. Register Indirect: É como o modo Displacement, mas o valor da constante é 0.

11 2.5 Conjunto de Instruções 10 Absoluto: Endereçamento absoluto é obtido a partir do uso do modo Displacement com o registrador r Conjunto de Instruções Categorias As instruções do Nios II podem ser divididas nas seguintes categorias. Instruções de transferência de dados Aritméticas e lógicas Move Comparação Deslocamento e rotação Instruções de controle do programa Outras Custom nop Instruções não implementadas O processador Nios II pode ter diferentes implementações, e em conseqüência disso pode haver instruções não implementadas em algumas versões. Essas instruções, quando encontradas pelo processador, causam uma exceção, que fazem com que o tratador de exceções desvie o fluxo de execução para a rotina que emula a respectiva operação em software Instruções personalizadas A arquitetura Nios II permite ao usuário a criação de suas próprias instruções, sendo usadas da mesma forma que as instruções nativas.

12 2.5 Conjunto de Instruções 11 Núcleo Item Nios II/e Nios II/s Nios II/f Freqüência máx. 200 MHz 165 MHz 185 MHz Pipeline 1 estágio 5 estágios 6 estágios Espaço de Endereçamento 2GB 2GB 2GB Multiplicação em Hardware - 3 ciclos 1 ciclo Divisão em Hardware - Opcional Opcional Shifter 1 ciclo/bit 3 ciclos 1 ciclo Tabela 2.2: Implementações do Nios II Formatos de instruções Tipo I Tipo R Tipo J Diferentes Implementações Como foi dito, o Nios II pode se apresentar em diferentes implementações. Três tipos são oferecidos pela Altera. A tabela 2.2 mostra alguns dados dessas 3 implementações. A versão escolhida para a realização desse trabalho foi a NiosII/f, por ser mais abrangente que as demais.

13 12 3 Modelagem 3.1 A ADL ArchC As Linguagens de Descrição de Arquitetura (ADL) foram criadas com o objetivo de facilitar o desenvolvimento de sistemas, considerando que a complexidade dos mesmos vêm aumentando cada vez mais, tornando o desenvolvimento mais difícil. Através de ADL s há a possibilidade de geração automática de ferramentas, como, por exemplo, montadores, ligadores, simuladores e compiladores. Uma ADL pode ajudar na escolha dos recursos a serem usados, tais como processador, frequência do relógio, tamanho de memórias cache e principal, etc. A ADL escolhida foi ArchC, que foi desenvolvida pelo Laboratório de Sistemas Computacionais (LSC) do Instituto de Computação (IC) da Universidade de Campinas (UNICAMP). Ela é baseada em SystemC, que é uma extensão de C/C++ voltada para o desenvolvimento de sistemas embarcados. Uma descrição de arquitetura em ArchC é composta de duas partes: AC ISA e AC ARCH. AC ISA corresponde à descrição do conjunto de instruções da arquitetura. Nela, o projetista informa detalhes sobre o formato, nome e tamanho das instruções e informações necessárias para a decodificação de cada instrução. Por sua vez, a descrição AC ARCH contém informações sobre, por exemplo, armazenamento e estrutura do pipeline. A linguagem possui algumas palavras reservadas em cada tipo de descrição, as quais estão listadas abaixo. Em uma AC ARCH: ac wordsize: informa o tamanho da palavra da arquitetura. ac format: declara um formato, o qual pode ser usado, por exemplo, para a declaração de registradores. ac cache, ac icache, ac dcache: declara um objeto do tipo ac cache para armazenamento. ac mem: declara um objeto do tipo ac mem, correspondendo a memória principal.

14 3.2 Modelo puramente funcional 13 ac regbank: declara um banco de registradores. ac reg: declara um registrador. ac pipe: cria um pipeline, com os estágios declarados juntamente. ARCH CTOR: início do construtor de AC ARCH. ac isa: informa o nome do arquivo que contém a descrição AC ISA. set endian: define o endianness da arquitetura. Em uma AC ISA: ac format: declara um formato e seus campos. ac instr: declara uma instrução com o formato fornecido. ISA CTOR: início do construtor de AC ISA. ac asm map: mapeia símbolos usados em código assembly para seus valores reais. set asm: associa uma sintaxe em assembly a uma instrução. set decoder: Especifica os valores dos campos para a codificação de uma instrução. ac pipe: cria um pipeline, com os estágios declarados juntamente. pseudo instr: cria uma pseudoinstrução com base nas instruções já criadas. A atual versão de ArchC (1.6.0) possibilita a geração de simuladores interpretados e compilados, e montadores a partir de um modelo descrito com a linguagem. Porém uma versão 2.0 Beta já está publicamente disponível (2) e oferece também a geração de desmontadores e debuggers (GDB). 3.2 Modelo puramente funcional A modelagem do processador Nios II partiu da implementação do modelo puramente funcional. O modelo é composto de 5 arquivos. O arquivo niosiif.ac contém a descrição AC ARCH. O conteúdo desse arquivo é mostrado na figura (A FAZER)3.2. Nela pode-se verificar a o tamanho da palavra (32 bits), um banco contendo 32 registradores, alguns outros registradores separados, uma memória de 5 MB, a indicação do arquivo com a descrição AC ISA e o

15 3.3 Modelo com precisão de ciclos 14 endianess da arquitetura, nesse caso little. É importante ressaltar que, apesar de o processador possuir uma memória cache, para o modelo puramente funcional isso não é importante. A razão disso é que a memória cache serve para diminuir o número de ciclos perdidos em um acesso à memória e um modelo puramente funcional não faz qualquer menção de como as instruções são executadas, e sim o resultado que cada uma produz. O arquivo niosiif-isa.ac contém a descrição AC ISA. A figura (A FAZER)3.2 mostra um fragmento desse arquivo. Primeiramente, pode-se observar a declaração dos formatos do Nios II. Por exemplo, o tipo J é declarado contendo os campos op e imm26, de 6 e 26 bits respectivamente. Mais adiante, são declaradas as instruções com seus devidos tipos. Em ac asm map é feito um mapeamento entre nomes de registradores e seus valores. Em ISA CTOR, as instruções são associadas às strings em assembly e seus códigos para decodificação. E por último são declaradas as pseudoinstruções. O arquivo niosiif-isa.cpp contém a implementação das instruções declaradas anteriormente. Já os arquivos niosiif gdb funcs.cpp e niosiif syscall.cpp não são obrigatórios para uma descrição de um processador. Eles contém informações que possibilitam o debug de programas e chamadas de sistema. No arquivo niosiif syscall.cpp é informado, por exemplo, como se retorna de uma chamada de sistema e onde se localizam os argumentos de um programa. 3.3 Modelo com precisão de ciclos Tópico a ser executado em Projetos 2.

16 15 4 Resultados Experimentais O modelo obtido foi submetido a diversos experimentos. Primeiramente, foi usado um conjunto de pequenos programas chamado acstone. A aplicação desse benchmark é um prérequisito para a validação de um modelo. Esses programas têm como objetivo apontar eventuais falhas básicas na implementação do modelo. São, portanto, programas sem uma aplicação prática. Após a execução correta do acstone foram usados mais dois benchmarks: Mediabench e Mibench. Esses dois benchmarks possuem aplicações e algoritmos muito usados em diversas áreas, incluindo telecomunicações, redes, automóveis, etc. Todos esses programas produziram arquivos como resultado da execução. Esses arquivos, foram, então, comparados com arquivos exemplos, produzidos, muitas vezes, pelo modelo do processador MIPS. A tabela 4.1 listam os programas testados e algumas informações sobre os mesmos.

17 4 Resultados Experimentais 16 Tabela 4.1: Conjunto de programas Mibench. Nome Número de instruções Instruções executadas Tempo de execução (s) basicmath-small basicmath-large bitcount-small ,6 bitcount-large qsort-small ,6 qsort-large susan-small corners ,7 susan-small edges ,3 susan-small smoothing ,9 susan-large corners ,2 susan-large edges ,5 susan-large smoothing dijkstra-small ,1 dijkstra-large ,4 patricia-small patricia-large adpcm-small encoder ,3 adpcm-small decoder ,1 adpcm-large encoder ,2 adpcm-large decoder ,6 crc32-small ,8 crc32-large ,3 fft-small fft-small inv gsm-small encode ,3 gsm-small decode ,3 gsm-large encode gsm-large decode

18 17 5 Conclusão e Trabalhos Futuros Devido ao grande número de aplicações que foram executadas, pôde-se verificar que o modelo apresenta um comportamento correto. Também foi importante verificar que é possível executar aplicações reais com o modelo obtido, o que o torna útil para o seu uso no desenvolvimento de sistemas. 5.1 Atividades Faltantes Geração de desmontador e depurador a partir do modelo funcional, para verificar a robustez do modelo. Certificação do modelo funcional. Implementação do modelo com precisão de ciclos. Aplicação dos benchmarks no modelo com precisão de ciclos. Certificação do modelo com precisão de ciclos.

19 18 Referências Bibliográficas 1 MARWEDEL, P. Embedded System Design. [S.l.]: Kluwer Academic Publishers, ARCHC. The ArchC Description Language ALTERA. 4 NIOS II Processor Reference Handbook,