Guilherme Quentel Melo
Modelagem do processador Nios2 para uma
plataforma de SoCs
Florian´opolis – SC 2006/2
Guilherme Quentel Melo
Modelagem do processador Nios2 para uma
plataforma de SoCs
Trabalho de conclus˜ao de curso apresentado como parte dos requisitos para obtenc¸˜ao do grau de Bacharel em Ciˆencias da Computac¸˜ao.
Orientador:
Prof. Dr. Luiz Cl´audio Villar dos Santos
UNIVERSIDADEFEDERAL DE SANTA CATARINA
CENTROTECNOLOGICO´
DEPARTAMENTO DE INFORMATICA E´ ESTAT´ISTICA
CURSO DE CIENCIAS DAˆ COMPUTAC¸ ˜AO
Florian´opolis – SC 2006/2
Sum´ario
Lista de Figuras Lista de Tabelas 1 Introduc¸˜ao p. 6 2 O Processador Nios 2 p. 8 2.1 Vis˜ao Geral . . . p. 8 2.2 Registradores . . . p. 8 2.3 Controlador de excec¸˜oes . . . p. 8 2.4 Mem´oria . . . p. 9 2.4.1 Mem´oria Cache . . . p. 9 2.4.2 Modos de Enderec¸amento . . . p. 9 2.5 Conjunto de Instruc¸˜oes . . . p. 10 2.5.1 Categorias . . . p. 10 2.5.2 Instruc¸˜oes n˜ao implementadas . . . p. 10 2.5.3 Instruc¸˜oes personalizadas . . . p. 10 2.5.4 Formatos de instruc¸˜oes . . . p. 11 2.5.5 Diferentes Implementac¸˜oes . . . p. 113 Modelagem p. 12
3.1 A ADL ArchC . . . p. 12 3.2 Modelo puramente funcional . . . p. 13
3.3 Modelo com precis˜ao de ciclos . . . p. 14
4 Resultados Experimentais p. 17
5 Conclus˜ao e Trabalhos Futuros p. 19
5.1 Atividades Faltantes . . . p. 19
Lista de Tabelas
2.1 Registradores de uso geral. . . p. 9 2.2 Implementac¸˜oes do Nios II . . . p. 11 4.1 Conjunto de programas Mibench. . . p. 18
6
1
Introduc¸˜ao
A miniaturizac¸˜ao est´a permitindo que cada vez mais dispositivos possuam processadores embutidos. Isso chega a levar a termos em inglˆes como Disapearing Computer(1), signifi-cando que os computadores est˜ao desaparecendo, pois est˜ao cada vez menores. Em raz˜ao disso, vˆe-se um aumento na necessidade de desenvolvimento de softwares para esses dispositivos em-barcados. Com a criac¸˜ao de modelos de processadores, pode-se realizar simulac¸˜oes de um mesmo software para v´arios processadores diferentes e obter uma an´alise de qual deles possui um melhor desempenho, sem a necessidade de adquirir cada processador. Isso proporciona uma grande economia de tempo e dinheiro. Esse trabalho consiste na utilizac¸˜ao de uma Linguagem de Descric¸˜ao de Arquiteturas (ADL), para a descric¸˜ao de um processador espec´ıfico.
A ADL escolhida foi a ArchC (2), com a qual alguns processadores e microcontroladores j´a foram modelados e est˜ao dispon´ıveis em (2).
O processador Nios II foi escolhido para a realizac¸˜ao desse trabalho por n˜ao haver ainda um modelo descrito em ArchC e por ser um processador importante para sistemas embarcados.
A descric¸˜ao desse processador consiste basicamente em duas etapas:
• Descric¸˜ao puramente funcional - Implementac¸˜ao das instruc¸˜oes do processador sem levar
em considerac¸˜ao a temporizac¸˜ao.
• Descric¸˜ao com precis˜ao de ciclos - Implementac¸˜ao das instruc¸˜oes do processador com
um n´ıvel de detalhamento maior, como, por exemplo, a inclus˜ao de informac¸˜oes sobre o pipeline.
O processo das duas descric¸˜oes s˜ao semelhantes, ambas consistindo em implementac¸˜ao e testes parciais das instruc¸˜oes, execuc¸˜ao de conjuntos de testes para a validac¸˜ao parcial do mo-delo e certificac¸˜ao do momo-delo junto `a equipe ArchC (2) para a disponibilizac¸˜ao em reposit´orio p´ublico.
1 Introduc¸˜ao 7
O modelo funcional foi obtido a partir de um prot´otipo implementado por Richard Maciel e o modelo com precis˜ao de ciclos foi criado a partir do primeiro j´a implementado.
8
2
O Processador Nios 2
Esse cap´ıtulo apresenta alguns dados obtidos a partir de (3) e (4).
2.1
Vis˜ao Geral
O Nios II ´e um processador desenvolvido pela AlteraR (3). para prop´ositos gerais comR
uma arquitetura RISC. ´E um processador voltado para sistemas embarcados, sendo desenvol-vido para a implementac¸˜ao 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 direta-mente na placa e refin´a-lo, adicionando ou retirando componentes, at´e que se atinja os requisitos necess´arios, sem precisar gastar com um novo hardware.
2.2
Registradores
Existem 32 registradores de 32 bits de uso geral e 6, tamb´em de 32 bits, de controle. H´a a possibilidade, tamb´em, dos registradores de controle serem protegidos contra programas de usu´ario, utilizando-se os modos supervisor e usu´ario. A tabela 2.1 lista os registradores de uso geral, com o uso padr˜ao de cada um.
2.3
Controlador de excec¸˜oes
Qualquer excec¸˜ao no Nios II causa um desvio na execuc¸˜ao para um ´unico enderec¸o. O tratador de excec¸˜oes verifica, ent˜ao, a causa da excec¸˜ao e executa a rotina apropriada.
2.4 Mem´oria 9
Tabela 2.1: Registradores de uso geral. Registrador Nome Uso Padr˜ao
r0 zero Constante 0
r1 at Tempor´ario p/ Montador
r2 Valor de Retorno (32 bits menos significativos) r3 Valor de Retorno (32 bits mais significativos) r4 Argumento (Primeiros 32 bits)
r5 Argumento (Pr´oximos 32 bits) r6 Argumento (Pr´oximos 32 bits) r7 Argumento (Pr´oximos 32 bits) r8 .. r15 Registradores tempor´arios
r16 .. r23 Registradores salvos pela func¸˜ao chamada r24 et Tempor´ario p/ excec¸˜ao
r25 bt Tempor´ario p/ break r26 gp Global Pointer r27 sp Stack Pointer r28 fp Frame Pointer
r29 ea Enderec¸o de Retorno de Excec¸˜ao r30 ba Enderec¸o de Retorno de Break r31 ra Enderec¸o de Retorno
2.4
Mem´oria
2.4.1
Mem´oria Cache
A arquitetura Nios II suporta mem´orias caches separadas para instruc¸˜oes e dados, possibi-litando uma melhora no tempo m´edio de acesso `a mem´oria. As caches est˜ao sempre ativas, no entanto h´a formas de desativ´a-la, de forma que perif´ericos possam acessar a mem´oria principal ou mem´orias de outros dispositivos diretamente.
2.4.2
Modos de Enderec¸amento
• Registrador: Todos os registradores s˜ao operandos e o resultado ´e salvo tamb´em em um
registrador.
• Displacement: O enderec¸o ´e calculado pela soma de um registrador e um valor imediato
com sinal.
• Imediato: Nesse modo, o operando ´e o pr´oprio valor imediato.
2.5 Conjunto de Instruc¸˜oes 10
• Absoluto: Enderec¸amento absoluto ´e obtido a partir do uso do modo Displacement com
o registrador r0.
2.5
Conjunto de Instruc¸˜oes
2.5.1
Categorias
As instruc¸˜oes do Nios II podem ser divididas nas seguintes categorias.
• Instruc¸˜oes de transferˆencia de dados • Aritm´eticas e l´ogicas
• Move • Comparac¸˜ao
• Deslocamento e rotac¸˜ao
• Instruc¸˜oes de controle do programa • Outras
• Custom • nop
2.5.2
Instruc¸˜oes n˜ao implementadas
O processador Nios II pode ter diferentes implementac¸˜oes, e em conseq¨uˆencia disso pode haver instruc¸˜oes n˜ao implementadas em algumas vers˜oes. Essas instruc¸˜oes, quando encontradas pelo processador, causam uma excec¸˜ao, que fazem com que o tratador de excec¸˜oes desvie o fluxo de execuc¸˜ao para a rotina que emula a respectiva operac¸˜ao em software.
2.5.3
Instruc¸˜oes personalizadas
A arquitetura Nios II permite ao usu´ario a criac¸˜ao de suas pr´oprias instruc¸˜oes, sendo usadas da mesma forma que as instruc¸˜oes nativas.
2.5 Conjunto de Instruc¸˜oes 11
N´ucleo
Item Nios II/e Nios II/s Nios II/f Freq¨uˆencia m´ax. 200 MHz 165 MHz 185 MHz
Pipeline 1 est´agio 5 est´agios 6 est´agios Espac¸o de Enderec¸amento 2GB 2GB 2GB Multiplicac¸˜ao em Hardware - 3 ciclos 1 ciclo
Divis˜ao em Hardware - Opcional Opcional Shifter 1 ciclo/bit 3 ciclos 1 ciclo
Tabela 2.2: Implementac¸˜oes do Nios II
2.5.4
Formatos de instruc¸˜oes
• Tipo I • Tipo R • Tipo J
2.5.5
Diferentes Implementac¸˜oes
Como foi dito, o Nios II pode se apresentar em diferentes implementac¸˜oes. Trˆes tipos s˜ao oferecidos pela Altera. A tabela 2.2 mostra alguns dados dessas 3 implementac¸˜oes.
A vers˜ao escolhida para a realizac¸˜ao desse trabalho foi a NiosII/f, por ser mais abrangente que as demais.
12
3
Modelagem
3.1
A ADL ArchC
As Linguagens de Descric¸˜ao de Arquitetura (ADL) foram criadas com o objetivo de fa-cilitar o desenvolvimento de sistemas, considerando que a complexidade dos mesmos vˆem aumentando cada vez mais, tornando o desenvolvimento mais dif´ıcil. Atrav´es de ADL’s h´a a possibilidade de gerac¸˜ao autom´atica de ferramentas, como, por exemplo, montadores, liga-dores, simuladores e compiladores. Uma ADL pode ajudar na escolha dos recursos a serem usados, tais como processador, frequˆencia do rel´ogio, tamanho de mem´orias cache e principal, etc.
A ADL escolhida foi ArchC, que foi desenvolvida pelo Laborat´orio de Sistemas Computa-cionais (LSC) do Instituto de Computac¸˜ao (IC) da Universidade de Campinas (UNICAMP). Ela ´e baseada em SystemC, que ´e uma extens˜ao de C/C++ voltada para o desenvolvimento de siste-mas embarcados. Uma descric¸˜ao de arquitetura em ArchC ´e composta de duas partes: AC ISA e AC ARCH. AC ISA corresponde `a descric¸˜ao do conjunto de instruc¸˜oes da arquitetura. Nela, o projetista informa detalhes sobre o formato, nome e tamanho das instruc¸˜oes e informac¸˜oes necess´arias para a decodificac¸˜ao de cada instruc¸˜ao. Por sua vez, a descric¸˜ao AC ARCH cont´em informac¸˜oes sobre, por exemplo, armazenamento e estrutura do pipeline. A linguagem possui algumas palavras reservadas em cada tipo de descric¸˜ao, as quais est˜ao 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 declarac¸˜ao de
registradores.
• ac cache, ac icache, ac dcache: declara um objeto do tipo ac cache para armazenamento. • ac mem: declara um objeto do tipo ac mem, correspondendo a mem´oria principal.
3.2 Modelo puramente funcional 13
• ac regbank: declara um banco de registradores. • ac reg: declara um registrador.
• ac pipe: cria um pipeline, com os est´agios declarados juntamente. • ARCH CTOR: in´ıcio do construtor de AC ARCH.
• ac isa: informa o nome do arquivo que cont´em a descric¸˜ao AC ISA. • set endian: define o endianness da arquitetura.
Em uma AC ISA:
• ac format: declara um formato e seus campos.
• ac instr: declara uma instruc¸˜ao com o formato fornecido. • ISA CTOR: in´ıcio do construtor de AC ISA.
• ac asm map: mapeia s´ımbolos usados em c´odigo assembly para seus valores reais. • set asm: associa uma sintaxe em assembly a uma instruc¸˜ao.
• set decoder: Especifica os valores dos campos para a codificac¸˜ao de uma instruc¸˜ao. • ac pipe: cria um pipeline, com os est´agios declarados juntamente.
• pseudo instr: cria uma pseudoinstruc¸˜ao com base nas instruc¸˜oes j´a criadas.
A atual vers˜ao de ArchC (1.6.0) possibilita a gerac¸˜ao de simuladores interpretados e com-pilados, e montadores a partir de um modelo descrito com a linguagem. Por´em uma vers˜ao 2.0 Beta j´a est´a publicamente dispon´ıvel (2) e oferece tamb´em a gerac¸˜ao de desmontadores e debuggers (GDB).
3.2
Modelo puramente funcional
A modelagem do processador Nios II partiu da implementac¸˜ao do modelo puramente funci-onal. O modelo ´e composto de 5 arquivos. O arquivo niosIIf.ac cont´em a descric¸˜ao AC ARCH. O conte´udo desse arquivo ´e mostrado na figura (A FAZER)3.2. Nela pode-se verificar a o tamanho da palavra (32 bits), um banco contendo 32 registradores, alguns outros registrado-res separados, uma mem´oria de 5 MB, a indicac¸˜ao do arquivo com a descric¸˜ao AC ISA e o
3.3 Modelo com precis˜ao de ciclos 14
endianess da arquitetura, nesse caso little. ´E importante ressaltar que, apesar de o processador possuir uma mem´oria cache, para o modelo puramente funcional isso n˜ao ´e importante. A raz˜ao disso ´e que a mem´oria cache serve para diminuir o n´umero de ciclos perdidos em um acesso `a mem´oria e um modelo puramente funcional n˜ao faz qualquer menc¸˜ao de como as instruc¸˜oes s˜ao executadas, e sim o resultado que cada uma produz.
O arquivo niosIIf-isa.ac cont´em a descric¸˜ao AC ISA. A figura (A FAZER)3.2 mostra um fragmento desse arquivo. Primeiramente, pode-se observar a declarac¸˜ao dos formatos do Nios II. Por exemplo, o tipo J ´e declarado contendo os campos op e imm26, de 6 e 26 bits respecti-vamente. Mais adiante, s˜ao declaradas as instruc¸˜oes com seus devidos tipos. Em ac asm map ´e feito um mapeamento entre nomes de registradores e seus valores. Em ISA CTOR, as instruc¸˜oes s˜ao associadas `as strings em assembly e seus c´odigos para decodificac¸˜ao. E por ´ultimo s˜ao de-claradas as pseudoinstruc¸˜oes.
O arquivo niosIIf-isa.cpp cont´em a implementac¸˜ao das instruc¸˜oes declaradas anteriormente. J´a os arquivos niosIIf gdb funcs.cpp e niosIIf syscall.cpp n˜ao s˜ao obrigat´orios para uma descric¸˜ao de um processador. Eles cont´em informac¸˜oes que possibilitam o debug de programas e chama-das de sistema. 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.
3.3
Modelo com precis˜ao de ciclos
15
4
Resultados Experimentais
O modelo obtido foi submetido a diversos experimentos. Primeiramente, foi usado um conjunto de pequenos programas chamado acstone. A aplicac¸˜ao desse benchmark ´e um pr´e-requisito para a validac¸˜ao de um modelo. Esses programas tˆem como objetivo apontar eventuais falhas b´asicas na implementac¸˜ao do modelo. S˜ao, portanto, programas sem uma aplicac¸˜ao pr´atica.
Ap´os a execuc¸˜ao correta do acstone foram usados mais dois benchmarks: Mediabench e Mibench. Esses dois benchmarks possuem aplicac¸˜oes e algoritmos muito usados em diversas ´areas, incluindo telecomunicac¸˜oes, redes, autom´oveis, etc.
Todos esses programas produziram arquivos como resultado da execuc¸˜ao. Esses arquivos, foram, ent˜ao, comparados com arquivos exemplos, produzidos, muitas vezes, pelo modelo do processador MIPS.
4 Resultados Experimentais 16
Tabela 4.1: Conjunto de programas Mibench.
Nome N´umero de instruc¸˜oes Instruc¸˜oes executadas Tempo de execuc¸˜ao (s)
basicmath-small 15191 1561063336 215 basicmath-large 15369 22039599769 3767 bitcount-small 10763 41479000 5,6 bitcount-large 10763 622394114 83 qsort-small 13745 16136424 2,6 qsort-large 15995 192013514 31 susan-small corners 18912 3759468 0,7 susan-small edges 18912 6880985 1,3 susan-small smoothing 18912 31118438 4,9 susan-large corners 18912 46385816 9,2 susan-large edges 18912 163131547 30,5 susan-large smoothing 18912 332160363 48 dijkstra-small 13567 48535523 7,1 dijkstra-large 13567 204657540 29,4 patricia-small 14394 309980718 35 patricia-large 14394 1964724183 270 adpcm-small encoder 9747 29179525 2,3 adpcm-small decoder 9741 26270157 2,1 adpcm-large encoder 9747 579119635 49,2 adpcm-large decoder 9741 518201806 44,6 crc32-small 10369 38469170 2,8 crc32-large 10369 747721150 62,3 fft-small 13280 898972685 112 fft-small inv 13280 2174894392 312 gsm-small encode 19847 25404166 4,3 gsm-small decode 19847 14326004 2,3 gsm-large encode 19847 1369426957 231 gsm-large decode 19847 779962071 123
17
5
Conclus˜ao e Trabalhos Futuros
Devido ao grande n´umero de aplicac¸˜oes que foram executadas, pˆode-se verificar que o mo-delo apresenta um comportamento correto. Tamb´em foi importante verificar que ´e poss´ıvel executar aplicac¸˜oes reais com o modelo obtido, o que o torna ´util para o seu uso no desenvolvi-mento de sistemas.
5.1
Atividades Faltantes
• Gerac¸˜ao de desmontador e depurador a partir do modelo funcional, para verificar a
robus-tez do modelo.
• Certificac¸˜ao do modelo funcional.
• Implementac¸˜ao do modelo com precis˜ao de ciclos.
• Aplicac¸˜ao dos benchmarks no modelo com precis˜ao de ciclos. • Certificac¸˜ao do modelo com precis˜ao de ciclos.
18
Referˆencias Bibliogr´aficas
1 MARWEDEL, P. Embedded System Design. [S.l.]: Kluwer Academic Publishers, 2005. 2 ARCHC. The ArchC Description Language - http://www.archc.org.
3 ALTERA. http://www.altera.com.
