Modelagem do processador Nios2 para uma plataforma de SoCs

(1)

Guilherme Quentel Melo

Modelagem do processador Nios2 para uma

plataforma de SoCs

Florian´opolis – SC 2006/2

(2)

Guilherme Quentel Melo

Modelagem do processador Nios2 para uma

plataforma de SoCs

Trabalho de conclus˜ao de curso apresentado como parte dos requisitos para obten¸c˜ao

do grau de Bacharel em Ciˆencias da

Com-puta¸c˜ao.

Orientador:

Prof. Dr. Luiz Cl´

audio Villar dos Santos

Universidade Federal de Santa Catarina

Centro Tecnol´ogico

Departamento de Inform´atica e Estat´ıstica

Curso de Ciências da Computação

Florian´opolis – SC 2006/2

(3)

Monografia de gradua¸c˜ao sob o t´ıtulo “Modelagem do processador Nios2 para uma plataforma de SoCs”, defendida por Guilherme Quentel Melo e aprovada em 8 de dezembro de 2006, em Florian´opolis , Santa Catarina, pela banca examinadora constitu´ıda pelos professores:

Prof. Dr. Luiz Cl´audio Villar dos Santos Universidade Federal de Santa Catarina

Orientador

Prof. Dr. Lu´ıs Fernando Friedrich Universidade Federal de Santa Catarina

Membro da Banca

Prof. Dr. Olinto Jos´e Varela Furtado Universidade Federal de Santa Catarina

(4)

“Four or five computers should be enough for the entire world until the year 2000.” T.J. Watson, Chairman IBM, 1945

(5)

Resumo

As nanotecnologias permitiram acomodar sistemas complexos de hardware e software

em um ´unico circuito integrado, dando origem aos Systems-on-Chip (SoCs). Um SoC

contém processadores, memórias, meios de conexão e componentes para entrada/sa´ıda e acelera¸cão de tarefas.

A medida que esses sistemas tornam-se mais complexos, é inevitável o uso de ferra-mentas que auxiliem nos processos de desenvolvimento e teste. Uma das possibilidades é o uso de modelos de diversos componentes para tornar poss´ıvel uma simula¸cão completa do sistema.

Este trabalho descreve o processo de modelagem de dois modelos para o processador Nios 2 da Altera. Os modelos foram validados atrav´es de benchmarks bem conhecidos. Por ser um processador muito popular e pelos modelos serem disponibilizados sob a licen¸ca GPL, espera-se que os produtos desse trabalho sejam largamente utilizados.

(6)

Sum´

ario

Lista de Figuras Lista de Tabelas 1 Introdu¸cão p. 9 2 O Processador Nios 2 p. 11 2.1 Visão Geral . . . p. 11 2.2 Registradores . . . p. 11 2.3 Controlador de exce¸cões . . . p. 11 2.4 Memória . . . p. 12 2.4.1 Memória Cache . . . p. 12 2.4.2 Modos de Endere¸camento . . . p. 12 2.5 Conjunto de Instru¸cões . . . p. 13 2.5.1 Categorias . . . p. 13 2.5.2 Instru¸cões não implementadas . . . p. 14 2.5.3 Instru¸cões personalizadas . . . p. 14 2.5.4 Formatos de instru¸cões . . . p. 14 2.5.5 Diferentes Implementa¸cões . . . p. 15

3 Modelagem p. 16

3.1 A ADL ArchC . . . p. 16 3.2 Modelo puramente funcional . . . p. 17

(7)

3.3 Modelo com precis˜ao de ciclos . . . p. 20 3.4 Dificuldades enfrentadas . . . p. 21

4 Resultados Experimentais p. 22

4.1 Configura¸c˜ao experimental . . . p. 22 4.2 Valida¸c˜ao dos modelos . . . p. 22

5 Conclus˜ao e Trabalhos Futuros p. 27

(8)

Lista de Figuras

1 Campos do Tipo I . . . p. 14 2 Campos do Tipo R . . . p. 14 3 Campos do Tipo J . . . p. 15 4 Descri¸cão dos parâmetros do processador para o modelo funcional . . . p. 18 5 Descri¸cão do conjunto de instru¸cões . . . p. 19 6 Descri¸cão do comportamento da instru¸cão add para o modelo funcional p. 20 7 Descri¸cão do conjunto de instru¸cões para o modelo com precisão de ciclos p. 20 8 Descri¸cão do comportamento da instru¸cão add para o modelo com

pre-cisão de ciclos . . . p. 21 9 Instru¸cões buscadas - Puramente funcional x Precisão de ciclos . . . p. 23

(9)

Lista de Tabelas

1 Registradores de uso geral. . . p. 12 2 Implementa¸c˜oes do Nios II . . . p. 15

3 Conjunto de programas Mibench - Modelo Funcional . . . p. 25

(10)

9

1 Introdu¸

c˜

ao

A miniaturiza¸cão está permitindo que cada vez mais dispositivos possuam processa-dores 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¸cão de modelos de processadores, pode-se realizar si-mula¸cõ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 processa-dor. Isso proporciona uma grande economia de tempo e dinheiro. Esse trabalho consiste na utiliza¸cão de uma Linguagem de Descri¸cão de Arquiteturas (ADL), para a descri¸cão de um processador espec´ıfico.

A ADL escolhida foi a ArchC (2), com a qual alguns processadores e microcontro-ladores já foram modelados e estão dispon´ıveis em (2). As principais vantagens dessa linguagem é que ela é distribu´ıda sob a licen¸ca GPL e permite a gera¸cão de várias ferra-mentas a partir do modelo criado.

O processador Nios II foi escolhido para a realiza¸c˜ao desse trabalho por n˜ao haver ainda um modelo descrito em ArchC e por ser um processador bastante difundido no mercado de sistemas embarcados.

A descri¸c˜ao desse processador consiste basicamente em duas etapas:

• Descri¸cão puramente funcional - Implementa¸cão das instru¸cões do processador sem levar em considera¸cão a temporiza¸cão.

• Descri¸cão com precisão de ciclos - Implementa¸cão das instru¸cões do processador com um n´ıvel de detalhamento maior, como, por exemplo, a inclusão de informa¸cões sobre o pipeline.

O processo das duas descri¸cões são semelhantes, ambas consistindo em implementa¸cão e testes parciais das instru¸cões, execu¸cão de conjuntos de testes para a valida¸cão parcial

(11)

1 Introdu¸c˜ao 10

do modelo e certifica¸cão do modelo junto à equipe ArchC (2) para a disponibiliza¸cão em repositório público.

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. O restante desse trabalho está organizado da seguinte maneira. No cap´ıtulo 2 são apresentados alguns detalhes da arquitetura e organiza¸cão do processador em questão. No cap´ıtulo 3 é apresentada uma visão geral da ADL ArchC e detalhes sobre a modelagem dos dois modelos. No cap´ıtulo 4 são mostrados o resultados experimentais obtidos e algumas análises desses dados. Por último, o cap´ıtulo 5 traz algumas conclusões e expectativas de trabalhos futuros.

(12)

11

2 O Processador Nios 2

Esse cap´ıtulo apresenta alguns dados do processador Nios 2, obtidos a partir de (3) e (4).

2.1 Vis˜

ao Geral

O Nios II é um processador desenvolvido pela Altera (3) para propósitos gerais com uma arquitetura RISC. É um processador voltado para sistemas embarcados, sendo de-senvolvido para a implementa¸cã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 1 lista os registradores de uso geral, com o uso padrão de cada um.

2.3 Controlador de exce¸

c˜

oes

Qualquer exce¸cão no Nios II causa um desvio na execu¸cão para um único endere¸co. O tratador de exce¸cões verifica, então, a causa da exce¸cão e executa a rotina apropriada.

(13)

2.4 Mem´oria 12

Tabela 1: Registradores de uso geral.

Registrador Nome Uso Padr˜ao

r0 zero Constante 0

r1 at Tempor´ario 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´oximos 32 bits)

r8 .. r15 Registradores tempor´arios

r16 .. r23 Registradores salvos pela fun¸c˜ao chamada

r24 et Tempor´ario p/ exce¸c˜ao

r25 bt Tempor´ario p/ break

r26 gp Global Pointer

r27 sp Stack Pointer

r28 fp Frame Pointer

r29 ea Endere¸co de Retorno de Exce¸c˜ao

r30 ba Endere¸co de Retorno de Break

r31 ra Endere¸co de Retorno

2.4 Mem´

oria

2.4.1 Mem´

oria Cache

A arquitetura Nios II suporta memórias caches separadas para instru¸cõ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.

2.4.2 Modos de Endere¸

camento

• Registrador: Todos os registradores são operandos e o resultado é salvo também em um registrador.

• Displacement : O endere¸co ´e calculado pela soma de um registrador e um valor imediato com sinal.

• Imediato: Nesse modo, o operando ´e o pr´oprio valor imediato.

(14)

2.5 Conjunto de Instru¸c˜oes 13

• Absoluto: Endere¸camento absoluto ´e obtido a partir do uso do modo Displacement com o registrador r0.

2.5 Conjunto de Instru¸

c˜

oes

2.5.1 Categorias

As instru¸c˜oes do Nios II podem ser divididas nas seguintes categorias.

• Instru¸cões de transferência de dados: Nessa categoria estão inclu´ıdas instru¸cões para ler ou escrever palavras, meia-palavras ou bytes em um endere¸co de memória. Inclui, também, instru¸cões que ignoram a cache, operando diretamente na memória principal (cache bypassing).

• Aritméticas e lógicas: Inclui instru¸cões que realizam adi¸cão, subtra¸cão, multiplica¸cão, divisão e opera¸cões lógicas como E, OU, OU exclusivo, etc.

• Move: Essas instru¸c˜oes copiam o valor de uma constante ou de um registrador para outro.

• Compara¸cão: Instru¸cões que comparam o valor entre dois registradores ou um re-gistrador e uma constante e escrevem o resultado 1 ou 0 em outro rere-gistrador. • Deslocamento e rota¸cão: Realizam o deslocamento e a rota¸cão do valor de um

registrador, sendo o n´umero de bits a ser deslocados ou rodados expresso em um outro registrador ou na forma de um imediato.

• Instru¸c˜oes de controle do programa: Inclui instru¸c˜oes de desvio condicionais e in-condicionais.

• Outras: Instru¸cões para tratamento de exce¸cões, para ferramentas de depura¸cão, gerenciamento de cache e escrita e leitura de registradores de controle.

• Custom: Instru¸cões especificadas em tempo de gera¸cão do sistema. • nop: Instru¸cão que não realiza nenhuma opera¸cão.

(15)

2.5.2 Instru¸

c˜

oes n˜

ao implementadas

O processador Nios II pode ter diferentes implementa¸cões, e em conseqüência disso pode haver instru¸cões não implementadas em algumas versões. Essas instru¸cões, quando encontradas pelo processador, causam uma exce¸cão, que fazem com que o tratador de exce¸cões desvie o fluxo de execu¸cão para a rotina que emula a respectiva opera¸cão em software. As únicas instru¸cões que podem ter que ser emuladas por software são as de multiplica¸cão e divisão.

2.5.3 Instru¸

c˜

oes personalizadas

A arquitetura Nios II permite ao usuário a cria¸cão de suas próprias instru¸cões, sendo usadas da mesma forma que as instru¸cões nativas.

2.5.4 Formatos de instru¸

c˜

oes

• Tipo I: Esse formato é usado por instru¸cões que utilizam até dois registradores e uma constante. A figura 1 ilustra os campos do Tipo I. Normalmente os campos A e IMM16 representam os operandos fontes e o B o registrador destino.

Figura 1: Campos do Tipo I

• Tipo R: O formato R é utilizado pelas instru¸cões que operam apenas com registrado-res, permitindo o uso de até 3. A figura 2 ilustra os campos do Tipo R. Geralmente os campos A e B especificam os operandos fontes e o C o registrador destino.

Figura 2: Campos do Tipo R

• Tipo J: Esse tipo é usado apenas pela instru¸cão call, que exige a utiliza¸cão de um valor absoluto, nesse caso de 26 bits. A figura 3 ilustra os campos desse tipo de instru¸cão.

(16)

Figura 3: Campos do Tipo J N´ucleo

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¸co de Endere¸camento 2GB 2GB 2GB

Multiplica¸c˜ao em Hardware - 3 ciclos 1 ciclo

Divis˜ao em Hardware - Opcional Opcional

Shifter 1 ciclo/bit 3 ciclos 1 ciclo

Tabela 2: Implementa¸c˜oes do Nios II

2.5.5 Diferentes Implementa¸

c˜

oes

Como foi dito, o Nios II pode se apresentar em diferentes implementa¸cões. Três tipos são oferecidos pela Altera. A tabela 2 mostra alguns dados dessas 3 implementa¸cões.

A versão Nios II/f é voltada para alto desempenho com um aumento relativamente pequeno do núcleo em rela¸cão à Nios II/s. Esta, por sua vez, é uma versão que proporciona um equil´ıbrio entre custo e desempenho. E a versão Nios II/e visa a economia, reduzindo ao máximo o tamanho do núcleo.

A vers˜ao escolhida para a realiza¸c˜ao desse trabalho foi a Nios II/f, por ser mais abrangente que as demais.

(17)

16

3 Modelagem

3.1 A ADL ArchC

As Linguagens de Descri¸cão de Arquitetura (ADL) foram criadas com o objetivo de facilitar o desenvolvimento de sistemas, considerando que a complexidade dos mesmos vão aumentando cada vez mais, tornando o desenvolvimento mais dif´ıcil. Através de ADL’s há a possibilidade de gera¸cã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, freqüência do relógio, tamanho de memórias cache e principal, etc.

A ADL escolhida foi ArchC, que foi desenvolvida pelo Laborat´orio de Sistemas Com-putacionais (LSC) do Instituto de Computa¸c˜ao (IC) da Universidade de Campinas

(UNI-CAMP). Ela é baseada em SystemC (5), que é uma extensão de C/C++ voltada para

o desenvolvimento de sistemas embarcados. Uma descri¸cão de arquitetura em ArchC é composta de duas partes: AC ISA e AC ARCH. AC ISA corresponde à descri¸cão do con-junto de instru¸cões da arquitetura. Nela, o projetista informa detalhes sobre o formato, nome e tamanho das instru¸cões e informa¸cões necessárias para a decodifica¸cão de cada instru¸cão. Por sua vez, a descri¸cão AC ARCH contém informa¸cões sobre, por exemplo, armazenamento e estrutura do pipeline. A linguagem possui algumas palavras reservadas em cada tipo de descri¸cã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 de-clara¸c˜ao de registradores.

• ac cache, ac icache, ac dcache: declara um objeto do tipo ac cache para armazena-mento.

(18)

3.2 Modelo puramente funcional 17

• ac mem: declara um objeto do tipo ac mem, correspondendo a mem´oria principal. • ac regbank: declara um banco de registradores.

• ac reg: declara um registrador.

• ac pipe: cria um pipeline, com os est´agios declarados juntamente. • ARCH CTOR: in´ıcio do construtor de AC ARCH.

• ac isa: informa o nome do arquivo que cont´em a descri¸c˜ao AC ISA. • set endian: define o endian da arquitetura.

Em uma AC ISA:

• ac format: declara um formato e seus campos.

• ac instr: declara uma instru¸c˜ao com o formato fornecido. • ISA CTOR: in´ıcio do construtor de AC ISA.

• ac asm map: mapeia s´ımbolos usados em c´odigo assembly para seus valores reais. • set asm: associa uma sintaxe em assembly a uma instru¸c˜ao.

• set decoder: Especifica os valores dos campos para a codifica¸cão de uma instru¸cão. • ac pipe: cria um pipeline, com os estágios declarados juntamente.

• pseudo instr: cria uma pseudoinstru¸cão com base nas instru¸cões já criadas.

A atual vers˜ao de ArchC (1.6.0) possibilita a gera¸c˜ao de simuladores interpretados

e compilados, e montadores a partir de um modelo descrito com a linguagem. Por´em

uma versão 2.0 Beta já está publicamente dispon´ıvel (2) e oferece também a gera¸cão de desmontadores e debuggers (GDB).

3.2 Modelo puramente funcional

A modelagem do processador Nios II partiu da implementa¸cão do modelo puramente funcional. O modelo é composto de 5 arquivos. O arquivo niosIIf.ac contém a descri¸cão AC ARCH. O conteúdo desse arquivo é mostrado na figura 4. Nela pode-se verificar o

(19)

tamanho da palavra (32 bits), um banco contendo 32 registradores, alguns outros re-gistradores separados, uma memória de 5 MB, a indica¸cão do arquivo com a descri¸cão AC ISA e o endian 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¸cão de como as instru¸cões são executadas, e sim o resultado que cada uma produz.

Figura 4: Descri¸c˜ao dos parˆametros do processador para o modelo funcional

O arquivo niosIIf-isa.ac contém a descri¸cão AC ISA. A figura 5 mostra um fragmento desse arquivo. Primeiramente, pode-se observar a declara¸cão dos formatos do Nios II.

Por exemplo, o tipo J ´e declarado contendo os campos op e imm26, de 6 e 26 bits

respectivamente. Mais adiante, s˜ao declaradas as instru¸c˜oes com seus devidos tipos. Em

ac asm map ´e feito um mapeamento entre nomes de registradores e seus valores. Em

ISA CTOR, as instru¸cões são associadas aos seus mnemônicos em assembly e seus códigos para decodifica¸cão. E por último são declaradas as pseudoinstru¸cões.

O arquivo niosIIf-isa.cpp contém a implementa¸cão das instru¸cões declaradas anteri-ormente. A figura 6 ilustra um fragmento desse arquivo contendo a implementa¸cão do comportamento da instru¸cão add. Nela, escreve-se no registrador destino o resultado da soma dos registradores-fonte.

(20)

Figura 5: Descri¸c˜ao do conjunto de instru¸c˜oes

Além desses três arquivos citados acima há também um arquivo de descri¸cão de chamadas de sistema (niosIIf syscall.cpp) e um arquivo de suporte à depura¸cão (nio-sIIf gdb funcs.cpp). No arquivo nio(nio-sIIf syscall.cpp é informado, por exemplo, como se retorna de uma chamada de sistema e onde se localizam os argumentos de um programa. Já no arquivo niosIIf gdb funcs.cpp, é determinado como ler e escrever o conteúdo de um registrador.

Embora não sejam arquivos obrigatórios de uma descri¸cão em ArchC, eles contém informa¸cões que possibilitam a emula¸cão de chamadas de sistema operacional na máquina

(21)

3.3 Modelo com precis˜ao de ciclos 20

Figura 6: Descri¸c˜ao do comportamento da instru¸c˜ao add para o modelo funcional

3.3 Modelo com precis˜

ao de ciclos

O modelo com precisão de ciclos é uma extensão do modelo puramente funcional, adi-cionando informa¸cões relacionadas à temporiza¸cão. Tal temporiza¸cão resulta na inclusão dos estágios de pipeline. Apenas duas descri¸cões precisam ser estendidas: a descri¸cão dos parâmetros da arquitetura e a descri¸cão dos comportamentos.

A figura 7 mostra as diferen¸cas encontradas no arquivo niosIIf.ac. Nela, pode-se observar a declara¸cão dos formatos dos registradores do pipeline, a declara¸cão dos próprios registradores que isolam os estágios do pipeline e a declara¸cão dos estágios propriamente ditos.

Figura 7: Descri¸cão do conjunto de instru¸cões para o modelo com precisão de ciclos

A figura 8 mostra como é feita a descri¸cão do comportamento da instru¸cão add no modelo com precisão de ciclos. Nessa descri¸cão é explicitada a implementa¸cão de cada estágio do pipeline. Quando algum dado de um estágio precisa ser passado para outro, escreve-se nos campos dos registradores de pipeline.

(22)

3.4 Dificuldades enfrentadas 21

Figura 8: Descri¸cão do comportamento da instru¸cão add para o modelo com precisão de ciclos

3.4 Dificuldades enfrentadas

Algumas dificuldades foram encontradas durante o desenvolvimento dos modelos. Não foi poss´ıvel gerar um montador adequado com os modelos obtidos. O montador gerado invertia a posi¸cão dos bytes das instru¸cões. Isso ocorreu pelo fato de que esses são os primeiros modelos little endian dispon´ıveis. Dessa forma, a gera¸cão de montadores little endian não havia sido testada ainda.

Outro problema ocorreu no modelo com precisão de ciclos. Não foi poss´ıvel gerar as paradas do pipeline. Isso porque a fun¸cão ArchC responsável por isso (ac stall ), não apresentou o comportamento esperado. Conseqüentemente, não foi poss´ıvel simular as latências entre as instru¸cões nem simular instru¸cões que levam mais de 1 ciclo na sua execu¸cão.

(23)

22

4 Resultados Experimentais

4.1 Configura¸

c˜

ao experimental

Os experimentos foram realizados em um computador com processador Pentium 4,

com frequˆencia de 3,0 GHz, 1 MB de cache L2, com 1 GB de mem´oria principal. Foi

utilizado o sistema operacional Debian GNU/Linux, com kernel versão 2.6. O simula-dor foi obtido pela ADL ArchC 1.6.0 e os programas dos benchmarks foram compilados utilizando-se o cross-compiler GCC 3.4.1 fornecido pela Altera (3) junto com o kit de desenvolvimento do Nios 2. Foi necessário configurá-lo para adicionar a cada arquivo executável as chamadas de sistema suportadas pelo ArchC.

4.2 Valida¸

c˜

ao dos modelos

Os modelo obtidos foram submetidos a diversos experimentos. Durante o desenvol-vimento dos modelos, cada instru¸cão foi testada individualmente imediatamente após ser implementada, utilizando um pequeno programa em assembly escrito somente para esse teste individual. Após dispor de todas as instru¸cões implementadas e testadas, foi usado um conjunto de pequenos programas chamado acstone. A aplica¸cão desse benchmark é um pré-requisito para a valida¸cão de um modelo. Esses programas têm como objetivo apontar eventuais falhas básicas na implementa¸cão do modelo. Eles executam simples adi¸cões, subtra¸cões, multiplica¸cões, divisões, loops, etc. São, portanto, programas sem uma aplica¸cão prática.

Após a execu¸cão correta do acstone, o modelo tornou-se apto a ser submetido a testes mais complexos e amplos. Para tal tarefa, foram utilizados outros dois conjuntos de benchmarks: Mediabench (6) e Mibench(7). Esses dois benchmarks possuem aplica¸cões e algoritmos muito conhecidos e utilizados em diversas áreas importantes de aplica¸cões de sistemas embarcados, incluindo telecomunica¸cões, redes e automóveis.

(24)

4.2 Valida¸c˜ao dos modelos 23

Todos esses programas produziram arquivos como resultado da execu¸cão. Esses ar-quivos, foram, então, comparados com arquivos exemplos, produzidos, muitas vezes, pelo modelo do processador MIPS (8), que está dispon´ıvel em (2).

A tabela 3 lista alguns programas executados no simulador do modelo puramente funcional e algumas informa¸c˜oes sobre os mesmos.

Já a tabela 4 lista alguns dos programas que já foram testados no modelo com precisão de ciclos. Nessa tabela é feito referência às instru¸cões buscadas e não às executadas, diferente do que acontece na tabela 3. Isso ocorre porque no modelo puramente funcional, todas as instru¸cões buscadas são executadas até o final. Já no modelo com precisão de ciclos ocorre a anula¸cão de instru¸cões, principalmente causada por instru¸cões de desvios. Em razão disso, percebe-se um maior número de instru¸cões buscadas no modelo com precisão de ciclos do que no modelo puramente funcional.

Figura 9: Instru¸c˜oes buscadas - Puramente funcional x Precis˜ao de ciclos

A figura 9 mostra um gráfico que auxilia na visualiza¸cão dessa diferen¸ca nas instru¸cões buscadas entre os dois modelos. No programa bitcount small, o modelo com precisão de ciclos chega a executar 30% de instru¸cões a mais. No gsm small encoder, que apresenta a menor diferen¸ca, o aumento é de cerca de 8%. No entanto, o processador oferece uma técnica de previsão de desvios, que ainda não está implementada. Essa técnica certamente diminuiria essa diferen¸ca. Isso mostra uma outra utilidade para o modelo: testar o impacto de diferentes técnicas relacionadas à implementa¸cão de processadores. Nesse caso, poderia ser feita uma compara¸cão entre diversas técnicas de previsão de desvios, sem a necessidade de se utilizar o hardware real.

Na tabela 4 também pode-se perceber que o tempo de execu¸cão chega a ser até 200 vezes maior em rela¸cao ao do modelo puramente funcional. No entanto, essa compara¸cão

(25)

não é justa porque para o modelo funcional foi utilizado um simulador compilado. O mesmo não acontece com o modelo com precisão de ciclos, pois a versão utilizada da linguagem ArchC suporta, para modelos com precisão de ciclos, apenas a gera¸cão de simuladores interpretados.

Ao término da execu¸cão desses programas e após cada resultado ser devidamente comparado com o esperado, o modelo funcional foi considerado como validado e certificável junto à equipe ArchC. Esse modelo passará por mais uma série de testes realizado pela equipe ArchC para constatar a sua certifica¸cão. Adicionalmente, esse modelo funcional foi portado para a versão 2.0 do ArchC que está sendo desenvolvida e ainda se encontra no versão beta. Com esse porte, foi poss´ıvel testar as novas ferramentas de gera¸cão de depuradores (GDB) e desmontadores (OBJDUMP), que estão inclusas nessa nova versão. Esse modelo contribuiu para a corre¸cão de alguns bugs nessas ferramentas, visto que é o primeiro modelo little endian dispon´ıvel para essa ADL.

(26)

Tabela 3: Conjunto de programas Mibench - Modelo Funcional

Pacote Programa N´umero de

instru¸cões Instru¸cões executadas Tempo de execu¸cão (s) Automotive basicmath-small 15191 1561063336 215,0 basicmath-large 15369 22039599769 3767,0 bitcount-small 10763 41479000 5,6 bitcount-large 10763 622394114 83,0 qsort-small 13745 16136424 2,6 qsort-large 15995 192013514 31,0 susan-small corners 18912 3759468 0,7 susan-small edges 18912 6880985 1,3 susan-small smoothing 18912 31118438 4,9 susan-large corners 18912 46385816 9,2 susan-large edges 18912 163131547 30,5 susan-large smoothing 18912 332160363 48,0 Network dijkstra-small 13567 48535523 7,1 dijkstra-large 13567 204657540 29,4 patricia-small 14394 309980718 35,0 patricia-large 14394 1964724183 270,0

Telecomm adpcm-small encoder 9747 29179525 2,3

adpcm-small decoder 9741 26270157 2,1 adpcm-large encoder 9747 579119635 49,2 adpcm-large decoder 9741 518201806 44,6 crc32-small 10369 38469170 2,8 crc32-large 10369 747721150 62,3 fft-small 13280 898972685 112,0 fft-small inv 13280 2174894392 312,0 fft-large 13280 18227603026 2490,5 fft-large inv 13280 17682569892 2468,9 gsm-small encode 19847 25404166 4,3 gsm-small decode 19847 14326004 2,3 gsm-large encode 19847 1369426957 231,0 gsm-large decode 19847 779962071 123,0

Security rijndael-small coder 13776 36561506 5,3

rijndael-small decoder 13776 36289080 5,4

rijndael-large coder 13776 380709693 54,9

rijndael-large decoder 13776 377868505 56,1

sha-small 10256 12834645 1,0

sha-large 10256 133605127 11,0

Consumer jpeg-small encoder 29970 26552292 2,4

jpeg-small decoder 32576 7542980 0,7

jpeg-large encoder 29970 97888608 8,5

jpeg-large decoder 32576 26130691 2,4

(27)

Tabela 4: Conjunto de programas Mibench - Modelo com precis˜ao de ciclos

Pacote Programa N´umero de

instru¸cões Instru¸cões buscadas Tempo de execu¸cão (s) Automotive basicmath-small 15191 1818830726 40011,0 bitcount-small 10763 54108933 964,1 bitcount-large 10763 812080873 18860,5 qsort-small 13745 20118742 311,1 qsort-large 15995 2652559671 71943,9 susan-small corners 18912 4465279 58,2 susan-small edges 18912 8252388 114,1 susan-small smoothing 18912 36563256 785,7 susan-large corners 18912 54724273 986,6 susan-large edges 18912 197695161 3516,8 susan-large smoothing 18912 389530864 10565,6 Network dijkstra-small 13567 62641949 1398,4 dijkstra-large 13567 261058157 5068,5 patricia-small 14394 366072907 9778,4 patricia-large 14394 2318139718 50436,1

Telecomm adpcm-small encoder 9747 38079617 646,0

adpcm-small decoder 9741 33269427 596,4 adpcm-large encoder 9747 646154426 13691,0 crc32-small 10369 46722296 822,4 crc32-large 10369 908119214 24393,3 fft-small 13280 1054182177 31678,2 fft-small inv 13280 2550950742 60474,9 gsm-small encode 19847 27451209 462,3 gsm-small decode 19847 16481579 245,4 gsm-large encode 19847 1478217580 47831,0 gsm-large decode 19847 897362602 27958,7

Security rijndael-small coder 13776 38842459 892,4

rijndael-small decoder 13776 38646011 809,6

rijndael-large coder 13776 404455295 11176,2

rijndael-large decoder 13776 402406815 12513.8

sha-small 10256 14650038 225,0

sha-large 10256 152497460 3375,4

Consumer jpeg-small encoder 29970 33096950 551,4

jpeg-small decoder 32576 8522363 119,3

jpeg-large encoder 29970 120951421 2366,4

(28)

27

5 Conclus˜

ao e Trabalhos Futuros

Devido ao grande número de aplica¸cões que foram executadas, pôde-se verificar que

os modelos apresentam um comportamento adequado. Tamb´em foi importante verificar

que é poss´ıvel executar aplica¸cões reais com tais modelos obtidos, o que o torna útil para o seu uso no desenvolvimento de sistemas.

Porém, o modelo com precisão de ciclos ainda não é muito fiel ao processador real. Portanto, como trabalho futuro ainda deve ser feita a corre¸cão das latências entre as instru¸cões, o que não foi poss´ıvel realizar devido às dificuldades encontradas. Além disso, ainda precisa ser implementada uma Branch History Table (9), que é a técnica de previsão de desvios presente na versão utilizada do Nios 2. Também seria interessante simular os diversos tipos de multiplicadores poss´ıveis de se utilizar com esse processador. O multiplicador utilizado nesse modelo realiza qualquer opera¸cão em apenas um ciclo.

Nos dois modelos ainda existem algumas poucas instru¸c˜oes, que por serem pouco

usadas, n˜ao foram implementadas. Essas instru¸c˜oes devem ser implementadas com o objetivo de se obter modelos completos.

O modelo funcional deverá ser certificado pela equipe ArchC em breve, sendo disponi-bilizado em seguida em repositório público (2). Já o modelo com precisão de ciclos deverá ser submetido à certifica¸cão quando for finalizada a sua valida¸cão.

(29)

28

Referˆ

encias

1 MARWEDEL, P. Embedded System Design. [S.l.]: Kluwer Academic Publishers, 2005. 2 ARCHC. The ArchC Description Language - Dispon´ıvel em http://www.archc.org. 3 ALTERA. Dispon´ıvel em http://www.altera.com.

4 NIOS II Processor Reference Handbook, 2003 - http://www.altera.com/literature. 5 SYSTEMC. The Open SystemC Initiative. - Dispon´ıvel em http://www.systemc.org. 6 MEDIABENCH. Mediabench Consortium - Dispon´ıvel em http://www.altera.com. 7 GUTHAUS M., e. a. Mibench: A free, commercially representative embedded benchmark suite. IEEE 4th Annual Workshop on Workload Characterization. Dispon´ıvel em http://www.eecs.umich.edu/mibench/.

8 PATTERSON, D. A.; HENNESSY, J. L. Computer Organization and Design: The Hardware/Software Interface. 3. ed. [S.l.]: Morgan Kaufmann Publishers, 2004.

9 PATTERSON, D. A.; HENNESSY, J. L. Computer Architecture: A Quantitative Approach. [S.l.]: Morgan Kaufmann Publishers, 2003.

(30)

MODELAGEM FUNCIONAL E COM PRECISÃO DE CICLOS DO

PROCESSADOR NIOS 2

Guilherme Quentel Melo Departamento de Informática e Estatística Universidade Federal de Santa Catarina Florianópolis, SC, Brasil saddan@inf.ufsc.br RESUMO

A necessidade de explorar várias possibilidades de processadores para uso em um SoC torna a utilização de modelos de processadores quase que obrigatória. Esse trabalho descreve um modelo funcional e um modelo com precisão de ciclos para o processador de 32 bits Nios 2, o qual é voltado para sistemas embarcados. Os modelos foram descritos utilizandose uma Linguagem de Descrição de Arquiteturas (ADL), chamada ArchC. Com esses modelos é possível gerar simuladores executáveis, permitindo executar o mesmo arquivo binário que seria usado no processador real. Os simuladores foram submetidos a uma série de testes e

benchmarks, visando a validação dos modelos.

1. INTRODUÇÃO

As nanotecnologias permitiram acomodar sistemas complexos de hardware e software em um único circuito integrado, dando origem aos SystemsonChip (SoCs). Um SoC contém processadores, memórias, meios de conexão e componentes para entrada /saída e aceleração de tarefas.

A crescente complexidade dos SoCs, o alto custo das máscaras e o custo crescente de engenharia não recorrente deram origem a um paradigma de projeto baseado em plataforma [1]. Uma plataforma consiste na adoção de uma arquitetura de referência que atende a um determinado domínio de aplicação e no reuso de blocos de propriedade intelectual (IPs). Plataformas podem ser descritas em diferentes níveis e estilos de abstração, tais como o nível de transferência

entre registradores (RTL), o estilo funcional com precisão de ciclos (CAM) e o estilo transacional (TLM)

[2]. Este último baseiase em descrições funcionais dos IPs e admite duas variantes: uma não temporizada que se limita à perspectiva do programador (PV) e outra com

temporização aproximada onde se combina a perspectiva

do programador com temporização (PVT).

A linguagem SystemC [3] mostrase a melhor alternativa para a modelagem em nível de sistema (ESL) e admite vários níveis e estilos de descrição (RTL, CAM, TLM). Em especial, o estilo TLM foi recentemente padronizado [4] e mostrase bastante promissor para a diminuição do timetomarket e para o projeto concorrente de hardware e software, conforme relatos da indústria [5].

A modelagem TLM é a tecnologiachave para o projeto de SoCs em nível de sistema (ESL). Para viabilizála, precisase de modelos dos vários IPs para compor uma plataforma. Entretanto, a modelagem de processadores diretamente em SystemC não seria pragmática, pois admitiria diversos estilos de descrição, o que dificultaria a geração automática do kit de ferramentas necessário para o desenvolvimento de software embarcado (compilador, montador, ligador, simulador, depurador, etc.). Para a geração automática desse kit, costumase utilizar linguagens de descrição de arquiteturas ou architecture description languages (ADLs). A ADL ArchC [6] tem a vantagem de ser distribuída sob licença GPL e gera modelos SystemC compatíveis com TLM. Por um lado, o modelo formal descrito com a ADL permite a geração automática do kit de ferramentas para o desenvolvimento de software. Por outro, ao invés de gerarse um mero simulador, um modelo de simulação é encapsulado dentro de um módulo SystemC, compatibilizandoo com TLM.

Este trabalho adota a ADL ArchC [6] para a modelagem do processador Nios 2 [7] da Altera, resultando em dois modelos distintos: um puramente funcional (compatível com a variante TLM/PV) e um com precisão de ciclos (compatível com a variante TLM/PV+T). A descrição puramente funcional considera apenas o efeito produzido por cada instrução, abstraindo as informações de temporização. A descrição com

(31)

precisão de ciclos, modela parte da organização do processador como, por exemplo, estágios de pipeline, que tem impacto na temporização das instruções.

Portanto, a contribuição deste trabalho é um par de modelos compatíveis com o paradigma de projeto contemporâneo de SoCs. Os modelos desenvolvidos são disponibilizados sob licença GPL, juntamente com outros modelos já armazenados em repositório [6]. Este artigo está organizado da seguinte forma: a Seção 2 revisa os trabalhos correlatos; a Seção 3 descreve os modelos puramente funcional e com precisão de ciclos do Nios 2 e algumas de suas características; a Seção 4 apresenta os resultados experimentais, Seção 5 contém conclusões e perspectivas de trabalhos futuros. 2. TRABALHOS CORRELATOS A ADL adotada para descrição, ArchC, foi desenvolvida pelo Computer Systems Laboratory (LSC) da Universidade de Campinas (Unicamp), Brasil.

Juntamente com a ADL, são disponibilizados alguns geradores de ferramentas para desenvolvimento e depuração de código. Dada uma descrição ArchC de um processador, é gerada uma cadeia de ferramentas incluindo montador, ligador, desmontador e depurador. Além disso, a partir da mesma descrição, geradores de simuladores podem criar modelos (puramente funcionais ou com precisão de ciclos) escritos em SystemC para a CPU descrita. Há vários modelos de processadores já disponíveis no repositório ArchC. Alguns processadores dispõem de modelos funcionais e com precisão de ciclos, tais como PowerPC, MIPSI, SPARCV8, Intel 8051 e PIC16F84. Outros possuem apenas o modelo puramente funcional.

À exceção de um protótipo inicial (não certificado) para o processador Nios2 (veja Seção 6), não é do conhecimento dos autores a existência de modelos ArchC para o processador Nios2 em domínio público. Assim, a motivação deste trabalho foi contribuir com dois modelos para um processador de uso bastante difundido em sistemas embarcados, permitindo utilizálo em descrições TLM de SoCs.

3. DESCRIÇÃO DOS MODELOS

O Nios 2 [7] é um processador RISC com muitas semelhanças com o processador MIPS [8]. Ele possui 38 registradores de 32 bits, sendo 32 de uso geral (r0 a r31) e 6 de controle. Há 3 formatos de instrução: R, I e J. Eles são idênticos aos formatos utilizados pelo MIPS.

3.1. Descrição do modelo funcional

O modelo funcional é composto de 5 descrições, organizadas em arquivos distintos.

A Figura 1 mostra um fragmento do arquivo que descreve os principais parâmetros do processador (niosIIf.ac). Nela podese observar características do

processador, tais como, o tamanho da palavra (32 bits), o banco contendo 32 registradores, os registradores de status e de controle e uma memória de 5 MB. Ao final, é especificado o arquivo que contém a descrição da arquitetura do conjunto de instruções (niosIIfisa.ac) e definido o endian do processador (little endian). Figura 1 – Descrição dos parâmetros do processador A Figura 2 ilustra apenas um fragmento da descrição do conjunto de instruções do modelo (arquivo niosIIf isa.ac), pois o arquivo completo é bastante extenso. Note que a descrição contém informações como formato, mnemônico e tamanho de cada instrução, bem como informações necessárias para decodificação.

Primeiramente, podese observar a declaração dos formatos do Nios 2. Por exemplo, o formato 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 a seus mnemônicos em assembly e seus códigos para decodificação. Por último, são declaradas as pseudoinstruções.

A Figura 3 ilustra um fragmento da descrição de comportamentos das instruções (arquivo niosIIfisa.cpp). O fragmento mostra a implementação de uma instrução

add no modelo funcional: escrevese no registrador

destino o resultado da soma dos registradoresfonte. Além dos três arquivos exemplificados nas figuras, há também um arquivo de descrição de chamadas de sistema (niosIIf_syscall.cpp) e um arquivo de suporte à depuração (niosIIf_gdb_funcs.cpp). O primeiro informa, por exemplo, como se retorna de uma chamada de sistema e onde se localizam os argumentos de um programa. O segundo mostra como ler e escrever o conteúdo de um registrador.

Embora estes não sejam arquivos obrigatórios de uma descrição em ArchC, eles contém informações que possibilitam a emulação de chamadas de sistema

(32)

operacional na máquina hospedeira e a depuração de programas, usando o depurador GNU GDB. Figura 2 – Descrição do conjunto de instruções Figura 3 – Descrição de comportamento de instrução 3.2. Descrição do modelo com precisão de ciclos O modelo com precisão de ciclos é uma extensão do modelo puramente funcional, onde a temporização resulta da inclusão da estrutura dos estágios de pipeline. Duas descrições precisam ser estendidas: a descrição dos parâmetros da arquitetura e a descrição dos comportamentos.

A Figura 4 mostra as principais modificações na descrição de parâmetros da arquitetura (niosIIf.ac). Observe a declaração dos formatos dos registradores do

pipeline, a declaração dos próprios registradores que

isolam os estágios do pipeline e a declaração dos estágios propriamente ditos. Figura 4 – Extensão da descrição de parâmetros Figura 5 – Extensão dos comportamentos A Figura 5 mostra as extensões em um fragmento da descrição de comportamentos para a instrução add. Essa descrição torna explícitos todos os eventos que ocorrem dentro de cada estágio do pipeline. Quando algum dado de um estágio precisa ser passado para outro, escrevese nos campos dos registradores de pipeline. 4. RESULTADOS EXPERIMENTAIS Os experimentos foram executados em um processador Pentium 4 (3,0 GHz; 1GB de memória principal). Utilizouse o ArchC 1.6.0 e o compilador GCC 3.4.1. Os modelos foram validados com os conjuntos de

benchmarks Mediabench [9] e Mibench [10].

A Tabela 1 mostra os resultados obtidos para o modelo puramente funcional com os programas do

benchmark Mibench. Tabela 1 – Resultados do benchmark Mibench Nome do programa Número de instruções Instruções executadas Tempo (s) simulação basicmathsmall 15191 1.561.063.336 215,0 basicmathlarge 15369 22.039.599.769 3767,0 bitcountsmall 10763 41.479.000 5,6 bitcountlarge 10763 622.394.114 83,0 qsortsmall 13745 16.136.424 2,6 qsortlarge 15995 192.013.514 31,0 susansmall corners 18912 3.759.468 0,7 susansmall edges 18912 6.880.985 1,3 susansmall smoothing 18912 31.118.438 4,9 susanlarge corners 18912 46.385.816 9,2 susanlarge edges 18912 163.131.547 30,5 susanlarge smoothing 18912 332.160.363 48,0 dijkstrasmall 13567 48.535.523 7,1 dijkstralarge 13567 204.657.540 29,4 patriciasmall 14394 309.980.718 35,0 patricialarge 14394 1.964.724.183 270,0 adpcmsmall encoder 9747 29.179.525 2,3 adpcmsmall decoder 9741 26.270.157 2,1 adpcmlarge encoder 9747 579.119.635 49,2 adpcmlarge decoder 9741 518.201.806 44,6 crc32small 10369 38.469.170 2,8 crc32large 10369 747.721.150 62,3 fftsmall 13280 898.972.685 112,0 fftsmall inv 13280 2.174.894.392 312,0 gsmsmall encode 19847 25.404.166 4,3

(33)

gsmsmall decode 19847 14.326.004 2,3

gsmlarge encode 19847 1.369.426.957 231,0

gsmlarge decode 19847 779.962.071 123,0

Os resultados obtidos com o modelo funcional coincidiram com os esperados para todos os casos testados. O modelo foi enviado à equipe ArchC pra certificação e disponibilização em repositório [6].

O mesmo foi realizado com o modelo com precisão de ciclos. Os resultados foram idênticos aos obtidos no modelo anterior.

Com os dados obtidos através dos dois modelos, podemos fazer uma comparação em relação ao número de instruções buscadas em cada caso.

Figura 6 – Instruções buscadas

A Figura 6 mostra um gráfico que auxilia na visualização dessa diferença nas instruções buscadas entre os dois modelos.

No programa bitcount_small, o modelo com precisão de ciclos chega a executar 30% de instruções a mais.

No gsm_small_encoder, que apresenta a menor diferença, o aumento é de cerca de 8%. No entanto, o processador oferece uma técnica de previsão de desvios, que não foi implementada. Essa técnica certamente diminuiria essa diferença. O modelo funcional foi portado para a versão 2.0 do ArchC. Esse porte permitiu testar as novas ferramentas de geração de depuradores e desmontadores, disponíveis na nova versão. Esse modelo contribuiu para a correção de alguns bugs nessas ferramentas, visto que é o primeiro modelo little endian disponível para essa ADL. 5. CONCLUSÕES E TRABALHOS FUTUROS Os modelos propostos têm um grande número de usuários potenciais por serem disponibilizados sob licença GPL e por representarem um processador bastante popular. A correção dos modelos é amparada

pelo grande número de programas executados corretamente. O modelo com precisão de ciclos ainda precisa ser submetido à certificação. Além disso, há ainda umas poucas instruções não implementadas nos dois modelos. 6. AGRADECIMENTOS Agradeço a Richard Maciel, autor de um protótipo inicial usado como ponto de partida para produzir o modelo puramente funcional aqui descrito. REFERÊNCIAS

[1] SangiovanniVincentelli, A. and Martin,. G., “Platformbased design and Software Design and software design methodology for embedded systems”,

IEEE Design and Test, 18(6): 2333, 2001.

[2] MailletContoz, L. and Ghenassia, F., “Transaction Level Modeling: An Abstraction Beyond RTL”. In TransactionLevel Modeling with SystemC: TLM Concepts and Applications for Embedded Systems, Springer, 2005, chapter 2.

[3] The Open SystemC Initiative. URL: http://www.systemc.org.

[4] OSCI Standard for SystemC TLM. URL: http://www.systemc.org.

[5] Ghenassia, F. and Clouard, A., “TLM: An Overview and Brief History”. In TransactionLevel Modeling with SystemC: TLM Concepts and Applications for Embedded Systems, Springer, 2005, chapter 1.

[6] The ArchC Architectural Description Language. URL: http://www.archc.org. [7] Nios 2 Processor Reference Handbook, 2003. URL: http://www.altera.com/literature. [8] Patterson, D., Hennessy, J., Computer Organization and Design: The Hardware/Software Interface, 3rd ed. Morgan Kaufmann Publishers, 2004.

[9] Mediabench Consortium. Disponível em http://euler.slu.edu/~fritts/mediabench/.

[10] Guthaus, M., et al. “MiBench: A free, commercially representative embedded benchmark suite.” IEEE 4th

Annual Workshop on Workload Characterization. URL: http://www.eecs.umich.edu/mibench/ jpeg_lar ge_deco der sha_sm all gsm_small_enco der crc32_s mall bitcount_small

0 5000000 10000000 15000000 20000000 25000000 30000000 35000000 40000000 45000000 50000000 55000000 Mibench Funcional Precisão de ciclos Instru çõ es buscadas