Guilherme Quentel Melo

Modelagem do processador Nios2 para uma

plataforma de SoCs

Florianopolis – SC

2006/2

Guilherme Quentel Melo

Modelagem do processador Nios2 para uma

plataforma de SoCs

Trabalho de conclusao de curso apresentadocomo parte dos requisitos para obtencaodo grau de Bacharel em Ciencias da Com-putacao.

Orientador:

Prof. Dr. Luiz Claudio Villar dos Santos

Universidade Federal de Santa CatarinaCentro Tecnologico

Departamento de Informatica e EstatısticaCurso de Ciencias da Computacao

Florianopolis – SC

2006/2

Monografia de graduacao 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 Florianopolis , Santa Catarina, pela banca examinadora constituıda pelos

professores:

Prof. Dr. Luiz Claudio Villar dos SantosUniversidade Federal de Santa Catarina

Orientador

Prof. Dr. Luıs Fernando FriedrichUniversidade Federal de Santa Catarina

Membro da Banca

Prof. Dr. Olinto Jose Varela FurtadoUniversidade Federal de Santa Catarina

Membro da Banca

“Four or five computers should be enough for

the entire world until the year 2000.”

T.J. Watson, Chairman IBM, 1945

Resumo

As nanotecnologias permitiram acomodar sistemas complexos de hardware e softwareem um unico circuito integrado, dando origem aos Systems-on-Chip (SoCs). Um SoCcontem processadores, memorias, meios de conexao e componentes para entrada/saıda eaceleracao de tarefas.

A medida que esses sistemas tornam-se mais complexos, e inevitavel o uso de ferra-mentas que auxiliem nos processos de desenvolvimento e teste. Uma das possibilidades eo uso de modelos de diversos componentes para tornar possıvel uma simulacao completado sistema.

Este trabalho descreve o processo de modelagem de dois modelos para o processadorNios 2 da Altera. Os modelos foram validados atraves de benchmarks bem conhecidos.Por ser um processador muito popular e pelos modelos serem disponibilizados sob a licencaGPL, espera-se que os produtos desse trabalho sejam largamente utilizados.

Sumario

Lista de Figuras

Lista de Tabelas

1 Introducao p. 9

2 O Processador Nios 2 p. 11

2.1 Visao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11

2.2 Registradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11

2.3 Controlador de excecoes . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11

2.4 Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

2.4.1 Memoria Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

2.4.2 Modos de Enderecamento . . . . . . . . . . . . . . . . . . . . . p. 12

2.5 Conjunto de Instrucoes . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

2.5.1 Categorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

2.5.2 Instrucoes nao implementadas . . . . . . . . . . . . . . . . . . . p. 14

2.5.3 Instrucoes personalizadas . . . . . . . . . . . . . . . . . . . . . . p. 14

2.5.4 Formatos de instrucoes . . . . . . . . . . . . . . . . . . . . . . . p. 14

2.5.5 Diferentes Implementacoes . . . . . . . . . . . . . . . . . . . . . p. 15

3 Modelagem p. 16

3.1 A ADL ArchC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

3.2 Modelo puramente funcional . . . . . . . . . . . . . . . . . . . . . . . . p. 17

3.3 Modelo com precisao de ciclos . . . . . . . . . . . . . . . . . . . . . . . p. 20

3.4 Dificuldades enfrentadas . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

4 Resultados Experimentais p. 22

4.1 Configuracao experimental . . . . . . . . . . . . . . . . . . . . . . . . . p. 22

4.2 Validacao dos modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22

5 Conclusao e Trabalhos Futuros p. 27

Referencias p. 28

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 Descricao dos parametros do processador para o modelo funcional . . . p. 18

5 Descricao do conjunto de instrucoes . . . . . . . . . . . . . . . . . . . . p. 19

6 Descricao do comportamento da instrucao add para o modelo funcional p. 20

7 Descricao do conjunto de instrucoes para o modelo com precisao de ciclos p. 20

8 Descricao do comportamento da instrucao add para o modelo com pre-

cisao de ciclos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

9 Instrucoes buscadas - Puramente funcional x Precisao de ciclos . . . . . p. 23

Lista de Tabelas

1 Registradores de uso geral. . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

2 Implementacoes do Nios II . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

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

4 Conjunto de programas Mibench - Modelo com precisao de ciclos . . . p. 26

9

1 Introducao

A miniaturizacao esta permitindo que cada vez mais dispositivos possuam processa-

dores embutidos. Isso chega a levar a termos em ingles como Disapearing Computer(1),

significando que os computadores estao desaparecendo, pois estao cada vez menores. Em

razao disso, ve-se um aumento na necessidade de desenvolvimento de softwares para esses

dispositivos embarcados. Com a criacao de modelos de processadores, pode-se realizar si-

mulacoes de um mesmo software para varios processadores diferentes e obter uma analise

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 utilizacao de uma Linguagem de Descricao de Arquiteturas (ADL), para a descricao

de um processador especıfico.

A ADL escolhida foi a ArchC (2), com a qual alguns processadores e microcontro-

ladores ja foram modelados e estao disponıveis em (2). As principais vantagens dessa

linguagem e que ela e distribuıda sob a licenca GPL e permite a geracao de varias ferra-

mentas a partir do modelo criado.

O processador Nios II foi escolhido para a realizacao desse trabalho por nao haver

ainda um modelo descrito em ArchC e por ser um processador bastante difundido no

mercado de sistemas embarcados.

A descricao desse processador consiste basicamente em duas etapas:

• Descricao puramente funcional - Implementacao das instrucoes do processador sem

levar em consideracao a temporizacao.

• Descricao com precisao de ciclos - Implementacao das instrucoes do processador com

um nıvel de detalhamento maior, como, por exemplo, a inclusao de informacoes sobre

o pipeline.

O processo das duas descricoes sao semelhantes, ambas consistindo em implementacao

e testes parciais das instrucoes, execucao de conjuntos de testes para a validacao parcial

1 Introducao 10

do modelo e certificacao do modelo junto a equipe ArchC (2) para a disponibilizacao em

repositorio publico.

O modelo funcional foi obtido a partir de um prototipo implementado por Richard

Maciel e o modelo com precisao de ciclos foi criado a partir do primeiro ja implementado.

O restante desse trabalho esta organizado da seguinte maneira. No capıtulo 2 sao

apresentados alguns detalhes da arquitetura e organizacao do processador em questao. No

capıtulo 3 e apresentada uma visao geral da ADL ArchC e detalhes sobre a modelagem dos

dois modelos. No capıtulo 4 sao mostrados o resultados experimentais obtidos e algumas

analises desses dados. Por ultimo, o capıtulo 5 traz algumas conclusoes e expectativas de

trabalhos futuros.

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 Visao Geral

O Nios II e um processador desenvolvido pela Altera (3) para propositos gerais com

uma arquitetura RISC. E um processador voltado para sistemas embarcados, sendo de-

senvolvido para a implementacao em FPGA’s, e por isso e 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 refina-lo, adicionando ou retirando componentes, ate

que se atinja os requisitos necessarios, sem precisar gastar com um novo hardware.

2.2 Registradores

Existem 32 registradores de 32 bits de uso geral e 6, tambem de 32 bits, de controle. Ha

a possibilidade, tambem, dos registradores de controle serem protegidos contra programas

de usuario, utilizando-se os modos supervisor e usuario. A tabela 1 lista os registradores

de uso geral, com o uso padrao de cada um.

2.3 Controlador de excecoes

Qualquer excecao no Nios II causa um desvio na execucao para um unico endereco.

O tratador de excecoes verifica, entao, a causa da excecao e executa a rotina apropriada.

2.4 Memoria 12

Tabela 1: Registradores de uso geral.

Registrador Nome Uso Padraor0 zero Constante 0r1 at Temporario p/ Montadorr2 Valor de Retorno (32 bits menos significativos)r3 Valor de Retorno (32 bits mais significativos)r4 Argumento (Primeiros 32 bits)r5 Argumento (Proximos 32 bits)r6 Argumento (Proximos 32 bits)r7 Argumento (Proximos 32 bits)r8 .. r15 Registradores temporariosr16 .. r23 Registradores salvos pela funcao chamadar24 et Temporario p/ excecaor25 bt Temporario p/ breakr26 gp Global Pointerr27 sp Stack Pointerr28 fp Frame Pointerr29 ea Endereco de Retorno de Excecaor30 ba Endereco de Retorno de Breakr31 ra Endereco de Retorno

2.4 Memoria

2.4.1 Memoria Cache

A arquitetura Nios II suporta memorias caches separadas para instrucoes e dados,

possibilitando uma melhora no tempo medio de acesso a memoria. As caches estao sempre

ativas, no entanto ha formas de desativa-la, de forma que perifericos possam acessar a

memoria principal ou memorias de outros dispositivos diretamente.

2.4.2 Modos de Enderecamento

• Registrador: Todos os registradores sao operandos e o resultado e salvo tambem em

um registrador.

• Displacement : O endereco e calculado pela soma de um registrador e um valor

imediato com sinal.

• Imediato: Nesse modo, o operando e o proprio valor imediato.

• Register Indirect : E como o modo Displacement, mas o valor da constante e 0.

2.5 Conjunto de Instrucoes 13

• Absoluto: Enderecamento absoluto e obtido a partir do uso do modo Displacement

com o registrador r0.

2.5 Conjunto de Instrucoes

2.5.1 Categorias

As instrucoes do Nios II podem ser divididas nas seguintes categorias.

• Instrucoes de transferencia de dados: Nessa categoria estao incluıdas instrucoes

para ler ou escrever palavras, meia-palavras ou bytes em um endereco de memoria.

Inclui, tambem, instrucoes que ignoram a cache, operando diretamente na memoria

principal (cache bypassing).

• Aritmeticas e logicas: Inclui instrucoes que realizam adicao, subtracao, multiplicacao,

divisao e operacoes logicas como E, OU, OU exclusivo, etc.

• Move: Essas instrucoes copiam o valor de uma constante ou de um registrador para

outro.

• Comparacao: Instrucoes que comparam o valor entre dois registradores ou um re-

gistrador e uma constante e escrevem o resultado 1 ou 0 em outro registrador.

• Deslocamento e rotacao: Realizam o deslocamento e a rotacao do valor de um

registrador, sendo o numero de bits a ser deslocados ou rodados expresso em um

outro registrador ou na forma de um imediato.

• Instrucoes de controle do programa: Inclui instrucoes de desvio condicionais e in-

condicionais.

• Outras: Instrucoes para tratamento de excecoes, para ferramentas de depuracao,

gerenciamento de cache e escrita e leitura de registradores de controle.

• Custom: Instrucoes especificadas em tempo de geracao do sistema.

• nop: Instrucao que nao realiza nenhuma operacao.

2.5 Conjunto de Instrucoes 14

2.5.2 Instrucoes nao implementadas

O processador Nios II pode ter diferentes implementacoes, e em consequencia disso

pode haver instrucoes nao implementadas em algumas versoes. Essas instrucoes, quando

encontradas pelo processador, causam uma excecao, que fazem com que o tratador de

excecoes desvie o fluxo de execucao para a rotina que emula a respectiva operacao em

software. As unicas instrucoes que podem ter que ser emuladas por software sao as de

multiplicacao e divisao.

2.5.3 Instrucoes personalizadas

A arquitetura Nios II permite ao usuario a criacao de suas proprias instrucoes, sendo

usadas da mesma forma que as instrucoes nativas.

2.5.4 Formatos de instrucoes

• Tipo I: Esse formato e usado por instrucoes que utilizam ate 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 e utilizado pelas instrucoes que operam apenas com registrado-

res, permitindo o uso de ate 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 e usado apenas pela instrucao call, que exige a utilizacao de um

valor absoluto, nesse caso de 26 bits. A figura 3 ilustra os campos desse tipo de

instrucao.

2.5 Conjunto de Instrucoes 15

Figura 3: Campos do Tipo J

NucleoItem Nios II/e Nios II/s Nios II/f

Frequencia max. 200 MHz 165 MHz 185 MHzPipeline 1 estagio 5 estagios 6 estagios

Espaco de Enderecamento 2GB 2GB 2GBMultiplicacao em Hardware - 3 ciclos 1 ciclo

Divisao em Hardware - Opcional OpcionalShifter 1 ciclo/bit 3 ciclos 1 ciclo

Tabela 2: Implementacoes do Nios II

2.5.5 Diferentes Implementacoes

Como foi dito, o Nios II pode se apresentar em diferentes implementacoes. Tres tipos

sao oferecidos pela Altera. A tabela 2 mostra alguns dados dessas 3 implementacoes.

A versao Nios II/f e voltada para alto desempenho com um aumento relativamente

pequeno do nucleo em relacao a Nios II/s. Esta, por sua vez, e uma versao que proporciona

um equilıbrio entre custo e desempenho. E a versao Nios II/e visa a economia, reduzindo

ao maximo o tamanho do nucleo.

A versao escolhida para a realizacao desse trabalho foi a Nios II/f, por ser mais

abrangente que as demais.

16

3 Modelagem

3.1 A ADL ArchC

As Linguagens de Descricao de Arquitetura (ADL) foram criadas com o objetivo de

facilitar o desenvolvimento de sistemas, considerando que a complexidade dos mesmos vao

aumentando cada vez mais, tornando o desenvolvimento mais difıcil. Atraves de ADL’s

ha a possibilidade de geracao automatica de ferramentas, como, por exemplo, montadores,

ligadores, simuladores e compiladores. Uma ADL pode ajudar na escolha dos recursos a

serem usados, tais como processador, frequencia do relogio, tamanho de memorias cache

e principal, etc.

A ADL escolhida foi ArchC, que foi desenvolvida pelo Laboratorio de Sistemas Com-

putacionais (LSC) do Instituto de Computacao (IC) da Universidade de Campinas (UNI-

CAMP). Ela e baseada em SystemC (5), que e uma extensao de C/C++ voltada para

o desenvolvimento de sistemas embarcados. Uma descricao de arquitetura em ArchC e

composta de duas partes: AC ISA e AC ARCH. AC ISA corresponde a descricao do con-

junto de instrucoes da arquitetura. Nela, o projetista informa detalhes sobre o formato,

nome e tamanho das instrucoes e informacoes necessarias para a decodificacao de cada

instrucao. Por sua vez, a descricao AC ARCH contem informacoes sobre, por exemplo,

armazenamento e estrutura do pipeline. A linguagem possui algumas palavras reservadas

em cada tipo de descricao, as quais estao 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-

claracao de registradores.

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

mento.

3.2 Modelo puramente funcional 17

• ac mem: declara um objeto do tipo ac mem, correspondendo a memoria principal.

• ac regbank: declara um banco de registradores.

• ac reg: declara um registrador.

• ac pipe: cria um pipeline, com os estagios declarados juntamente.

• ARCH CTOR: inıcio do construtor de AC ARCH.

• ac isa: informa o nome do arquivo que contem a descricao 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 instrucao com o formato fornecido.

• ISA CTOR: inıcio do construtor de AC ISA.

• ac asm map: mapeia sımbolos usados em codigo assembly para seus valores reais.

• set asm: associa uma sintaxe em assembly a uma instrucao.

• set decoder: Especifica os valores dos campos para a codificacao de uma instrucao.

• ac pipe: cria um pipeline, com os estagios declarados juntamente.

• pseudo instr: cria uma pseudoinstrucao com base nas instrucoes ja criadas.

A atual versao de ArchC (1.6.0) possibilita a geracao de simuladores interpretados

e compilados, e montadores a partir de um modelo descrito com a linguagem. Porem

uma versao 2.0 Beta ja esta publicamente disponıvel (2) e oferece tambem a geracao de

desmontadores e debuggers (GDB).

3.2 Modelo puramente funcional

A modelagem do processador Nios II partiu da implementacao do modelo puramente

funcional. O modelo e composto de 5 arquivos. O arquivo niosIIf.ac contem a descricao

AC ARCH. O conteudo desse arquivo e mostrado na figura 4. Nela pode-se verificar o

3.2 Modelo puramente funcional 18

tamanho da palavra (32 bits), um banco contendo 32 registradores, alguns outros re-

gistradores separados, uma memoria de 5 MB, a indicacao do arquivo com a descricao

AC ISA e o endian da arquitetura, nesse caso little. E importante ressaltar que, apesar de

o processador possuir uma memoria cache, para o modelo puramente funcional isso nao e

importante. A razao disso e que a memoria cache serve para diminuir o numero de ciclos

perdidos em um acesso a memoria e um modelo puramente funcional nao faz qualquer

mencao de como as instrucoes sao executadas, e sim o resultado que cada uma produz.

Figura 4: Descricao dos parametros do processador para o modelo funcional

O arquivo niosIIf-isa.ac contem a descricao AC ISA. A figura 5 mostra um fragmento

desse arquivo. Primeiramente, pode-se observar a declaracao 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, sao declaradas as instrucoes com seus devidos tipos. Em

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

ISA CTOR, as instrucoes sao associadas aos seus mnemonicos em assembly e seus codigos

para decodificacao. E por ultimo sao declaradas as pseudoinstrucoes.

O arquivo niosIIf-isa.cpp contem a implementacao das instrucoes declaradas anteri-

ormente. A figura 6 ilustra um fragmento desse arquivo contendo a implementacao do

comportamento da instrucao add. Nela, escreve-se no registrador destino o resultado da

soma dos registradores-fonte.

3.2 Modelo puramente funcional 19

Figura 5: Descricao do conjunto de instrucoes

Alem desses tres arquivos citados acima ha tambem um arquivo de descricao de

chamadas de sistema (niosIIf syscall.cpp) e um arquivo de suporte a depuracao (nio-

sIIf gdb funcs.cpp). No arquivo niosIIf syscall.cpp e informado, por exemplo, como se

retorna de uma chamada de sistema e onde se localizam os argumentos de um programa.

Ja no arquivo niosIIf gdb funcs.cpp, e determinado como ler e escrever o conteudo de um

registrador.

Embora nao sejam arquivos obrigatorios de uma descricao em ArchC, eles contem

informacoes que possibilitam a emulacao de chamadas de sistema operacional na maquina

hospedeira e a depuracao de programas, usando o depurador GNU GDB.

3.3 Modelo com precisao de ciclos 20

Figura 6: Descricao do comportamento da instrucao add para o modelo funcional

3.3 Modelo com precisao de ciclos

O modelo com precisao de ciclos e uma extensao do modelo puramente funcional, adi-

cionando informacoes relacionadas a temporizacao. Tal temporizacao resulta na inclusao

dos estagios de pipeline. Apenas duas descricoes precisam ser estendidas: a descricao dos

parametros da arquitetura e a descricao dos comportamentos.

A figura 7 mostra as diferencas encontradas no arquivo niosIIf.ac. Nela, pode-se

observar a declaracao dos formatos dos registradores do pipeline, a declaracao dos proprios

registradores que isolam os estagios do pipeline e a declaracao dos estagios propriamente

ditos.

Figura 7: Descricao do conjunto de instrucoes para o modelo com precisao de ciclos

A figura 8 mostra como e feita a descricao do comportamento da instrucao add no

modelo com precisao de ciclos. Nessa descricao e explicitada a implementacao de cada

estagio do pipeline. Quando algum dado de um estagio precisa ser passado para outro,

escreve-se nos campos dos registradores de pipeline.

3.4 Dificuldades enfrentadas 21

Figura 8: Descricao do comportamento da instrucao add para o modelo com precisao deciclos

3.4 Dificuldades enfrentadas

Algumas dificuldades foram encontradas durante o desenvolvimento dos modelos. Nao

foi possıvel gerar um montador adequado com os modelos obtidos. O montador gerado

invertia a posicao dos bytes das instrucoes. Isso ocorreu pelo fato de que esses sao os

primeiros modelos little endian disponıveis. Dessa forma, a geracao de montadores little

endian nao havia sido testada ainda.

Outro problema ocorreu no modelo com precisao de ciclos. Nao foi possıvel gerar

as paradas do pipeline. Isso porque a funcao ArchC responsavel por isso (ac stall), nao

apresentou o comportamento esperado. Consequentemente, nao foi possıvel simular as

latencias entre as instrucoes nem simular instrucoes que levam mais de 1 ciclo na sua

execucao.

22

4 Resultados Experimentais

4.1 Configuracao experimental

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

com frequencia de 3,0 GHz, 1 MB de cache L2, com 1 GB de memoria principal. Foi

utilizado o sistema operacional Debian GNU/Linux, com kernel versao 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 necessario configura-lo para adicionar a cada arquivo

executavel as chamadas de sistema suportadas pelo ArchC.

4.2 Validacao dos modelos

Os modelo obtidos foram submetidos a diversos experimentos. Durante o desenvol-

vimento dos modelos, cada instrucao foi testada individualmente imediatamente apos ser

implementada, utilizando um pequeno programa em assembly escrito somente para esse

teste individual. Apos dispor de todas as instrucoes implementadas e testadas, foi usado

um conjunto de pequenos programas chamado acstone. A aplicacao desse benchmark e

um pre-requisito para a validacao de um modelo. Esses programas tem como objetivo

apontar eventuais falhas basicas na implementacao do modelo. Eles executam simples

adicoes, subtracoes, multiplicacoes, divisoes, loops, etc. Sao, portanto, programas sem

uma aplicacao pratica.

Apos a execucao 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 aplicacoes e

algoritmos muito conhecidos e utilizados em diversas areas importantes de aplicacoes de

sistemas embarcados, incluindo telecomunicacoes, redes e automoveis.

4.2 Validacao dos modelos 23

Todos esses programas produziram arquivos como resultado da execucao. Esses ar-

quivos, foram, entao, comparados com arquivos exemplos, produzidos, muitas vezes, pelo

modelo do processador MIPS (8), que esta disponıvel em (2).

A tabela 3 lista alguns programas executados no simulador do modelo puramente

funcional e algumas informacoes sobre os mesmos.

Ja a tabela 4 lista alguns dos programas que ja foram testados no modelo com precisao

de ciclos. Nessa tabela e feito referencia as instrucoes buscadas e nao as executadas,

diferente do que acontece na tabela 3. Isso ocorre porque no modelo puramente funcional,

todas as instrucoes buscadas sao executadas ate o final. Ja no modelo com precisao de

ciclos ocorre a anulacao de instrucoes, principalmente causada por instrucoes de desvios.

Em razao disso, percebe-se um maior numero de instrucoes buscadas no modelo com

precisao de ciclos do que no modelo puramente funcional.

Figura 9: Instrucoes buscadas - Puramente funcional x Precisao de ciclos

A figura 9 mostra um grafico que auxilia na visualizacao dessa diferenca nas instrucoes

buscadas entre os dois modelos. No programa bitcount small, o modelo com precisao de

ciclos chega a executar 30% de instrucoes a mais. No gsm small encoder, que apresenta

a menor diferenca, o aumento e de cerca de 8%. No entanto, o processador oferece uma

tecnica de previsao de desvios, que ainda nao esta implementada. Essa tecnica certamente

diminuiria essa diferenca. Isso mostra uma outra utilidade para o modelo: testar o impacto

de diferentes tecnicas relacionadas a implementacao de processadores. Nesse caso, poderia

ser feita uma comparacao entre diversas tecnicas de previsao de desvios, sem a necessidade

de se utilizar o hardware real.

Na tabela 4 tambem pode-se perceber que o tempo de execucao chega a ser ate 200

vezes maior em relacao ao do modelo puramente funcional. No entanto, essa comparacao

4.2 Validacao dos modelos 24

nao e justa porque para o modelo funcional foi utilizado um simulador compilado. O

mesmo nao acontece com o modelo com precisao de ciclos, pois a versao utilizada da

linguagem ArchC suporta, para modelos com precisao de ciclos, apenas a geracao de

simuladores interpretados.

Ao termino da execucao desses programas e apos cada resultado ser devidamente

comparado com o esperado, o modelo funcional foi considerado como validado e certificavel

junto a equipe ArchC. Esse modelo passara por mais uma serie de testes realizado pela

equipe ArchC para constatar a sua certificacao. Adicionalmente, esse modelo funcional

foi portado para a versao 2.0 do ArchC que esta sendo desenvolvida e ainda se encontra

no versao beta. Com esse porte, foi possıvel testar as novas ferramentas de geracao de

depuradores (GDB) e desmontadores (OBJDUMP), que estao inclusas nessa nova versao.

Esse modelo contribuiu para a correcao de alguns bugs nessas ferramentas, visto que e o

primeiro modelo little endian disponıvel para essa ADL.

4.2 Validacao dos modelos 25

Tabela 3: Conjunto de programas Mibench - Modelo Funcional

Pacote Programa Numero deinstrucoes

Instrucoesexecutadas

Tempo deexecucao (s)

Automotive basicmath-small 15191 1561063336 215,0basicmath-large 15369 22039599769 3767,0bitcount-small 10763 41479000 5,6bitcount-large 10763 622394114 83,0qsort-small 13745 16136424 2,6qsort-large 15995 192013514 31,0susan-small corners 18912 3759468 0,7susan-small edges 18912 6880985 1,3susan-small smoothing 18912 31118438 4,9susan-large corners 18912 46385816 9,2susan-large edges 18912 163131547 30,5susan-large smoothing 18912 332160363 48,0

Network dijkstra-small 13567 48535523 7,1dijkstra-large 13567 204657540 29,4patricia-small 14394 309980718 35,0patricia-large 14394 1964724183 270,0

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

Security rijndael-small coder 13776 36561506 5,3rijndael-small decoder 13776 36289080 5,4rijndael-large coder 13776 380709693 54,9rijndael-large decoder 13776 377868505 56,1sha-small 10256 12834645 1,0sha-large 10256 133605127 11,0

Consumer jpeg-small encoder 29970 26552292 2,4jpeg-small decoder 32576 7542980 0,7jpeg-large encoder 29970 97888608 8,5jpeg-large decoder 32576 26130691 2,4lame-small decoder 75524 9306508888 1138,7

4.2 Validacao dos modelos 26

Tabela 4: Conjunto de programas Mibench - Modelo com precisao de ciclos

Pacote Programa Numero deinstrucoes

Instrucoesbuscadas

Tempo deexecucao (s)

Automotive basicmath-small 15191 1818830726 40011,0bitcount-small 10763 54108933 964,1bitcount-large 10763 812080873 18860,5qsort-small 13745 20118742 311,1qsort-large 15995 2652559671 71943,9susan-small corners 18912 4465279 58,2susan-small edges 18912 8252388 114,1susan-small smoothing 18912 36563256 785,7susan-large corners 18912 54724273 986,6susan-large edges 18912 197695161 3516,8susan-large smoothing 18912 389530864 10565,6

Network dijkstra-small 13567 62641949 1398,4dijkstra-large 13567 261058157 5068,5patricia-small 14394 366072907 9778,4patricia-large 14394 2318139718 50436,1

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

Security rijndael-small coder 13776 38842459 892,4rijndael-small decoder 13776 38646011 809,6rijndael-large coder 13776 404455295 11176,2rijndael-large decoder 13776 402406815 12513.8sha-small 10256 14650038 225,0sha-large 10256 152497460 3375,4

Consumer jpeg-small encoder 29970 33096950 551,4jpeg-small decoder 32576 8522363 119,3jpeg-large encoder 29970 120951421 2366,4jpeg-large decoder 32576 29306712 536,3

27

5 Conclusao e Trabalhos Futuros

Devido ao grande numero de aplicacoes que foram executadas, pode-se verificar que

os modelos apresentam um comportamento adequado. Tambem foi importante verificar

que e possıvel executar aplicacoes reais com tais modelos obtidos, o que o torna util para

o seu uso no desenvolvimento de sistemas.

Porem, o modelo com precisao de ciclos ainda nao e muito fiel ao processador real.

Portanto, como trabalho futuro ainda deve ser feita a correcao das latencias entre as

instrucoes, o que nao foi possıvel realizar devido as dificuldades encontradas. Alem disso,

ainda precisa ser implementada uma Branch History Table (9), que e a tecnica de previsao

de desvios presente na versao utilizada do Nios 2. Tambem seria interessante simular

os diversos tipos de multiplicadores possıveis de se utilizar com esse processador. O

multiplicador utilizado nesse modelo realiza qualquer operacao em apenas um ciclo.

Nos dois modelos ainda existem algumas poucas instrucoes, que por serem pouco

usadas, nao foram implementadas. Essas instrucoes devem ser implementadas com o

objetivo de se obter modelos completos.

O modelo funcional devera ser certificado pela equipe ArchC em breve, sendo disponi-

bilizado em seguida em repositorio publico (2). Ja o modelo com precisao de ciclos devera

ser submetido a certificacao quando for finalizada a sua validacao.

28

Referencias

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 embeddedbenchmark suite. IEEE 4th Annual Workshop on Workload Characterization. Disponıvelem http://www.eecs.umich.edu/mibench/.

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

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

MODELAGEM FUNCIONAL E COM PRECISÃO DE CICLOS DO PROCESSADOR NIOS 2

Guilherme Quentel Melo

Departamento de Informática e EstatísticaUniversidade 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  utilizando­se 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  Systems­on­Chip  (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 baseia­se 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]   mostra­se   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  mostra­se bastante promissor  para a diminuição   do   time­to­market   e   para   o   projeto concorrente de hardware e software, conforme relatos da indústria [5].

A   modelagem   TLM   é   a   tecnologia­chave   para   o projeto   de   SoCs   em   nível   de   sistema   (ESL).   Para viabilizá­la,  precisa­se 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, costuma­se 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 gerar­se um mero simulador, um modelo de simulação é   encapsulado   dentro   de   um   módulo   SystemC, compatibilizando­o 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 

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, MIPS­I,  SPARC­V8, 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 funcionalO   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   pode­se   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   (niosIIf­isa.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,   pode­se   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 niosIIf­isa.cpp). O fragmento mostra  a implementação de uma instrução add  no   modelo   funcional:     escreve­se   no   registrador destino o resultado da soma dos registradores­fonte.

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 

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 ciclosO 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, escreve­se 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). Utilizou­se 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 MibenchNome do programa Número de 

instruçõesInstruções executadas

Tempo (s) simulação

basicmath­small 15191 1.561.063.336 215,0basicmath­large 15369 22.039.599.769 3767,0bitcount­small 10763 41.479.000 5,6bitcount­large 10763 622.394.114 83,0qsort­small 13745 16.136.424 2,6qsort­large 15995 192.013.514 31,0susan­small corners 18912 3.759.468 0,7susan­small edges 18912 6.880.985 1,3susan­small smoothing 18912 31.118.438 4,9susan­large corners 18912 46.385.816 9,2susan­large edges 18912 163.131.547 30,5susan­large smoothing 18912 332.160.363 48,0dijkstra­small 13567 48.535.523 7,1dijkstra­large 13567 204.657.540 29,4patricia­small 14394 309.980.718 35,0patricia­large 14394 1.964.724.183 270,0adpcm­small encoder 9747 29.179.525 2,3adpcm­small decoder 9741 26.270.157 2,1adpcm­large encoder 9747 579.119.635 49,2adpcm­large decoder 9741 518.201.806 44,6crc32­small 10369 38.469.170 2,8crc32­large 10369 747.721.150 62,3fft­small 13280 898.972.685 112,0fft­small inv 13280 2.174.894.392 312,0gsm­small encode 19847 25.404.166 4,3

gsm­small decode 19847 14.326.004 2,3gsm­large encode 19847 1.369.426.957 231,0gsm­large 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]   Sangiovanni­Vincentelli,   A.   and   Martin,.   G., “Platform­based   design   and   Software   Design   and software   design   methodology   for   embedded   systems”, IEEE Design and Test, 18(6): 23­33, 2001.

[2] Maillet­Contoz, L.   and Ghenassia, F., “Transaction Level   Modeling:   An   Abstraction   Beyond   RTL”.   In Transaction­Level   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 Transaction­Level 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_large_decoder

sha_small

gsm_small_encoder 

crc32_small 

bitcount_small 

0

5000000

10000000

15000000

20000000

25000000

30000000

35000000

40000000

45000000

50000000

55000000

Mibench

FuncionalPrecisão de ciclos

Inst

ruçõ

es b

usca

das