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