Melhoramentos ao Simulador de Exactidão de Ciclo … simulações de vários programas de teste....
102
Melhoramentos ao Simulador de Exactidão de Ciclo para a Arquitectura FireWorks/SideWorks João Carlos dos Santos Ferreira Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores Orientador: Prof. Dr. José João Henriques Teixeira de Sousa Júri Presidente: Prof. Dr. João Manuel Torres Caldinhas Simões Vaz Orientador: Prof. Dr. José João Henriques Teixeira de Sousa Vogais: Prof. Dr. João Manuel Paiva Cardoso Prof. Dr. Nuno Filipe Valentim Roma Abril 2014
Transcript of Melhoramentos ao Simulador de Exactidão de Ciclo … simulações de vários programas de teste....
Melhoramentos ao Simulador de Exactidão de Ciclo para
a Arquitectura FireWorks/SideWorks
João Carlos dos Santos Ferreira
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Orientador: Prof. Dr. José João Henriques Teixeira de Sousa
Júri
Presidente: Prof. Dr. João Manuel Torres Caldinhas Simões Vaz Orientador: Prof. Dr. José João Henriques Teixeira de Sousa
Vogais: Prof. Dr. João Manuel Paiva Cardoso Prof. Dr. Nuno Filipe Valentim Roma
Abril 2014
i
Resumo
O trabalho realizado no âmbito desta tese consistiu no melhoramento de um simulador de ciclo
exacto para o processador FireWorks, anteriormente desenvolvido pelo autor desta tese, com o
objectivo de o dotar com capacidades de depuração e análise de desempenho. O simulador foi
implementado em Java.
Em modo simulador, opera ao nível das instruções assembly, é de ciclo exacto, e obedece a uma
arquitectura modular, permitindo a utilização de módulos de processadores e de periféricos
desenvolvidos posteriormente. O simulador suporta o carregamento do software em formato
Executable and Linking Format (ELF) e a configuração do sistema a simular através de ficheiros
Extensible Markup Language (XML).
Em modo depurador/servidor GNU Debugger (GDB), suporta o protocolo GDB Remote Serial
Protocol (GDB RSP) e opera como um servidor GDB.
Em modo analisador de desempenho, produz relatórios de desempenho em termos de instruções
e em termos de funções do software simulado.
Para aferir o correcto funcionamento e o desempenho do simulador desenvolvido, foram
efectuadas simulações de vários programas de teste.
Palavras-chave: Processadores, Executable and Linking Format (ELF), Simulador, Depurador GNU
Debugger (GDB), Analisador de desempenho.
ii
Abstract
The work realised in the scope of this thesis consisted in the improvement of a cycle accurate
simulator for the Fireworks processor, previously developed by the author of this thesis, with the
objective of emphasizing the debugging capabilities and performance analysis. The simulator was
implemented in Java.
In simulator mode it operates in assembly instruction mode and is cycle accurate, obeying a
modular architecture, permitting the usage of processor and peripheral modules previously developed.
The simulator supports the software loading in Executable and Linking Format (ELF) format and the
configuration of the system to simulate through Extensible Markup Language (XML) files.
In debugger/GNU Debugger (GDB) server mode, the protocol GDB Remote Serial Protocol (GDB
RSP) is supported and operates as a GDB server.
In performance analyser mode, it produces performance reports in terms of instructions and in
terms of function of the simulated software.
To assess the correct operation and performance of the developed simulator, various test
programs simulations were made.
Keywords: Microprocessors, Executable and Linking Format (ELF), Simulator, Debugger GNU
Debugger (GDB), Performance analyser.
iii
Índice
RESUMO.................................................................................................................................................. I
ABSTRACT............................................................................................................................................. II
ÍNDICE ................................................................................................................................................... III
LISTA DE TABELAS ............................................................................................................................. VI
LISTA DE FIGURAS ............................................................................................................................. VII
LISTA DE ABREVIATURAS ................................................................................................................. IX
1 INTRODUÇÃO ................................................................................................................................. 1
1.1 MOTIVAÇÃO ............................................................................................................................ 1
1.2 CONTEXTO .............................................................................................................................. 2
1.3 OBJECTIVOS ........................................................................................................................... 2
1.4 APLICAÇÕES ........................................................................................................................... 3
1.5 ORGANIZAÇÃO DA DISSERTAÇÃO ............................................................................................. 3
2 SISTEMAS BASEADOS NO PROCESSADOR FIREWORKS ...................................................... 5
2.1 PROCESSADOR FIREWORKS .................................................................................................... 5
2.1.1 Instruções ...................................................................................................................... 7
2.1.2 Registos ......................................................................................................................... 7
2.1.3 Pipeline .......................................................................................................................... 9
2.1.3.1 Instruções de Salto sem Delay Slot......................................................................................... 9
2.1.3.2 Instruções de Salto com Delay Slot........................................................................................10
2.1.3.3 Instruções de Acesso à Memória ...........................................................................................11
2.1.4 Arquitectura da Memória ............................................................................................. 12
2.1.5 Reset, Excepções e Interrupções ................................................................................ 12
2.1.5.1 Reset ......................................................................................................................................13
2.1.5.2 Excepções de Hardware ........................................................................................................13
2.1.5.3 Interrupções ...........................................................................................................................15
2.1.5.4 Excepções de Software ..........................................................................................................16
2.2 MEMÓRIA E PERIFÉRICOS ...................................................................................................... 16
2.2.1 Barramentos ................................................................................................................ 16
2.2.2 Memória ....................................................................................................................... 16
2.2.3 Periféricos .................................................................................................................... 17
2.2.4 Acesso a Dados e a Instruções ................................................................................... 18
2.2.5 Mapeamento ................................................................................................................ 19
2.3 AMBIENTES E FERRAMENTAS DE SIMULAÇÃO E DEPURAÇÃO .................................................... 20
2.4 DOCUMENTAÇÃO ................................................................................................................... 21
iv
3 SIMULADOR ................................................................................................................................. 23
3.1 PORQUÊ SIMULAR? ............................................................................................................... 23
3.2 DESCRIÇÃO DO SIMULADOR ................................................................................................... 24
3.3 ARQUITECTURA DO SIMULADOR ............................................................................................. 24
3.3.1 Configuração................................................................................................................ 25
3.3.2 Motor de Simulação ..................................................................................................... 27
3.3.3 Memória ....................................................................................................................... 28
3.3.4 Processador ................................................................................................................. 29
3.3.5 Periféricos .................................................................................................................... 30
4 MELHORAMENTOS ..................................................................................................................... 33
4.1 MODO ANALISADOR DE DESEMPENHO .................................................................................... 33
4.1.1 Motivação? ................................................................................................................... 33
4.1.2 Descrição do Modo Analisador de Desempenho ........................................................ 34
4.1.3 Arquitectura do Modo Analisador de Desempenho ..................................................... 35
4.2 MODO DEPURADOR/SERVIDOR GDB ...................................................................................... 36
4.2.1 Motivação? ................................................................................................................... 36
4.2.2 Descrição do Modo Depurador/Servidor GDB ............................................................ 36
4.2.3 Arquitectura do Modo Depurador/Servidor GDB ......................................................... 38
5 TESTES EXPERIMENTAIS .......................................................................................................... 43
5.1 TESTES DE AFERIÇÃO DO SIMULADOR .................................................................................... 43
5.1.1 Descrição dos Testes .................................................................................................. 43
5.1.2 Resultados dos Testes no Sistema Real ..................................................................... 46
5.1.3 Resultados dos Testes no Simulador .......................................................................... 46
5.2 TESTES MODO SIMULADOR .................................................................................................... 47
5.2.1 Descrição dos Testes .................................................................................................. 47
5.2.2 Resultados dos Testes em Modo Simulador ............................................................... 48
5.2.3 Resultados dos Testes Funcionais do Processador ................................................... 49
5.3 TESTES MODO ANALISADOR DE DESEMPENHO ....................................................................... 49
5.3.1 Descrição dos Testes .................................................................................................. 49
5.3.2 Resultados dos Testes em Modo Analisador de Desempenho .................................. 49
5.4 TESTES MODO DEPURADOR/SERVIDOR GDB ......................................................................... 50
5.4.1 Descrição dos Testes .................................................................................................. 50
5.4.2 Resultados dos Testes em Modo Depurador/Servidor GDB ....................................... 51
6 CONCLUSÕES E TRABALHO FUTURO ..................................................................................... 55
6.1 CONCLUSÕES ....................................................................................................................... 55
6.2 TRABALHO FUTURO ............................................................................................................... 56
v
APÊNDICES ......................................................................................................................................... 59
A. ESTRUTURA DO CD .................................................................................................................... 61
B. GUIA DE INSTALAÇÃO E REMOÇÃO DO SIMULADOR ....................................................................... 62
B.1 Modo de disponibilização do simulador ............................................................................. 62
B.2 Sistemas operativos suportados ........................................................................................ 62
B.3 Pré-requisitos ..................................................................................................................... 62
B.4 Sistemas operativos Microsoft Windows ............................................................................ 63
B.5 Sistemas operativos GNU/Linux ........................................................................................ 64
B.6 Testes ao simulador no âmbito da tese ............................................................................. 64
C. GUIA DE UTILIZAÇÃO DO SIMULADOR ........................................................................................... 65
C.1 Modos de Operação ........................................................................................................... 65
C.2 Manual de Utilização .......................................................................................................... 66
C.3 Ligação com a Ferramenta mb-gdb ................................................................................... 67
D. FORMATO DOS FICHEIROS DE CONFIGURAÇÃO DO SISTEMA ......................................................... 71
E. FORMATO DOS FICHEIROS DE CONFIGURAÇÃO DOS MÓDULOS ..................................................... 75
F. RELATÓRIO DA ANÁLISE DE DESEMPENHO DA SEQUÊNCIA DE FIBONACCI ...................................... 79
G. PROTOCOLO GDB REMOTE SERIAL PROTOCOL .......................................................................... 85
H. RELATÓRIO DA COMUNICAÇÃO DO MODO DEPURADOR/SERVIDOR GDB ....................................... 87
vi
Lista de Tabelas
Tabela 1. Mercado global dos sistemas embebidos em milhões de dólares, fonte BCC Inc. [1] ........... 1
Tabela 2. Convenção do modo de utilização dos registos ..................................................................... 8
Tabela 3. Vectores e registo que contém o endereço de retorno ........................................................ 13
Tabela 4. Modos de acesso para leitura de dados através dos barramentos ...................................... 18
Tabela 5. Modos de acesso para escrita de dados através dos barramentos ..................................... 19
Tabela 6. Estados do sistema ............................................................................................................... 28
Tabela 7. Estados da memória ............................................................................................................. 28
Tabela 8. Estados do processador ....................................................................................................... 29
Tabela 9. Instruções especiais do processador.................................................................................... 30
Tabela 10. Pacotes para manipulação de registos ............................................................................... 38
Tabela 11. Pacotes para manipulação da memória ............................................................................. 39
Tabela 12. Pacotes de informação do estado do sistema .................................................................... 39
Tabela 13. Pacotes de controlo do software......................................................................................... 39
Tabela 14. Extensão dos estados do sistema ...................................................................................... 41
Tabela 15. Extensão das instruções do processador ........................................................................... 42
Tabela 16. Nome dos executáveis dos algoritmos com relógio ........................................................... 45
Tabela 17. Tamanho dos executáveis dos algoritmos com relógio ...................................................... 45
Tabela 18. Nome dos executáveis do Dhrystone Benchmark .............................................................. 45
Tabela 19. Tamanho dos executáveis do Dhrystone Benchmark ........................................................ 45
Tabela 20. Número de ciclos obtidos nos testes dos algoritmos com relógio no sistema real ............ 46
Tabela 21. Dhrystones por segundo obtidos nos testes do Dhrystone Benchmark no sistema real ... 46
Tabela 22. Número de ciclos obtidos nos testes dos algoritmos com relógio no simulador ................ 46
Tabela 23. Dhrystones por segundo obtidos nos testes do Dhrystone Benchmark no simulador ....... 47
Tabela 24. Nome dos executáveis dos algoritmos sem relógio ........................................................... 47
Tabela 25. Tamanho dos executáveis dos algoritmos sem relógio ...................................................... 48
Tabela 26. Nome dos executáveis dos testes funcionais do processador ........................................... 48
Tabela 27. Resultados dos testes dos algoritmos sem relógio no simulador ....................................... 48
Tabela 28. Nome dos executáveis sem informação de depuração ...................................................... 51
Tabela 29. Tamanho dos executáveis sem informação de depuração ................................................ 51
Tabela 30. Nome dos executáveis com informação de depuração ...................................................... 51
Tabela 31. Tamanho dos executáveis com informação de depuração ................................................ 51
Tabela 32. Comandos de implementação obrigatória substituídos ...................................................... 52
Tabela 33. Comandos sem resposta imediata ..................................................................................... 86
vii
Lista de Figuras
Figura 1. Diagrama de blocos de um sistema baseado no processador FireWorks [6] ......................... 6
Figura 2. Formato das instruções do Tipo A ........................................................................................... 7
Figura 3. Formato das instruções do Tipo B ........................................................................................... 7
Figura 4. Comportamento de instruções de salto sem delay slot no pipeline ...................................... 10
Figura 5. Comportamento de uma instrução de salto com delay slot no pipeline, seguida de uma
instrução com um ciclo de relógio de latência no andar Execute (EX) .......................................... 10
Figura 6. Comportamento de uma instrução de salto com delay slot no pipeline, seguida de uma
instrução com três ciclos de relógio de latência no andar Execute (EX) ....................................... 11
Figura 7. Comportamento de instruções de acesso à memória no pipeline ........................................ 12
Figura 8. Mapeamento típico de um sistema baseado no processador FireWorks ............................. 20
Figura 9. Configuração do simulador .................................................................................................... 26
Figura 10. Motor de simulação do simulador ........................................................................................ 27
Figura 11. Processamento de um ciclo de um periférico ...................................................................... 31
Figura 12. Motor de simulação do modo analisador de desempenho .................................................. 35
Figura 13. Interligação entre o hardware e as ferramentas XMD e mb-gdb ........................................ 37
Figura 14. Interligação entre o simulador e a ferramenta mb-gdb........................................................ 38
Figura 15. Configuração do modo depurador/servidor GDB ................................................................ 40
Figura 16. Motor de simulação do modo depurador/servidor GDB ...................................................... 41
Figura 17. Excerto do relatório da análise de desempenho do programa número de Fibonacci ......... 50
Figura 18. Estrutura do CD ................................................................................................................... 61
Figura 19. Janela de selecção das ferramentas e utilidades a instalar ................................................ 63
Figura 20. Janela de escolha da directoria de instalação ..................................................................... 63
Figura 21. Janela de finalização da instalação ..................................................................................... 64
Figura 22. Manual de operação do simulador ...................................................................................... 67
Figura 23. Informação sobre a versão e configuração por defeito ....................................................... 67
Figura 24. Inicialização do simulador em modo depurador/servidor GDB ........................................... 68
Figura 25. Ferramenta mb-gdb em modo janela .................................................................................. 69
Figura 26. Janela Target Selection ............................................................................................... 69
Figura 27. Ferramenta mb-gdb com um executável ELF carregado .................................................... 70
Figura 28. systemconfig.dtd, ficheiro utilizado na definição e validação do sistema ............................ 71
Figura 29. systemconfig.xml ficheiro de configuração do sistema usado nos testes experimentais ... 74
Figura 30. deviceconfig.dtd, ficheiro de definição e validação dos módulos dos periféricos ............... 75
Figura 31. opbuartlite.xml, ficheiro de configuração do módulo OPB UART Lite ................................. 75
Figura 32. opbtimercounter.xml, ficheiro de configuração do módulo OPB Timer/Counter ................. 76
Figura 33. cpuconfig.dtd, ficheiro de definição e validação dos módulos dos processadores ............. 76
Figura 34. fw_3sp.xml, ficheiro de configuração do módulo do processador FireWorks ..................... 78
Figura 35. Relatório da análise de desempenho do programa número de Fibonacci .......................... 84
Figura 36. Excerto do relatório da comunicação, inicialização do programa teste Print ...................... 89
viii
Figura 37. Excerto do relatório da comunicação, inserção do breakpoint no programa teste Print ..... 89
Figura 38. Excerto do relatório da comunicação, finalização do programa teste Print ........................ 90
ix
Lista de Abreviaturas
AAGR - Average Annual Growth Rate 1
ASCII - American Standard Code for Information Interchange 63
ASIC - Application-Specific Integrated Circuit 5
BRAM - Block Random Access Memory 16, 43
CAN-bus - Controller-area Network Bus 85
CD – Compact Disc 61
DDR SDRAM - Double Data Rate Synchronous Dynamic Random Access Memory 17
DSP - Digital Signal Processing 17
DTD - Document Type Definition 25
EDK - Embedded Development Kit 20, 24
ELF - Executable and Linking Format passim
FEUP - Faculdade de Engenharia de Universidade do Porto 3
FPGA - Field-Programmable Gate Array 5, 36, 43
FPU - Floating Point Unit 7
FSL - Fast Simplex Link 5
GCC - GNU Compiler Collection 25, 44
GDB – GNU Debugger passim
GDB RSP - GDB Remote Serial Protocol passim
GPIO - General Purpose Input/Output 18
I²C - Inter-Integrated Circuit 17
IP Blocks - Intellectual Property Blocks 20
ISA - Instruction Set Architecture 5, 25
ISS - Instruction Set Simulator 21, 24, 55
IST - Instituto Superior Técnico 3
JTAG - Joint Test Action Group 21, 36
LMB - Local Memory Bus 5, 24
MAC - Media Access Control 17
MIEEC - Mestrado Integrado em Engenharia Electrotécnica e de Computadores 3
MIT License - Massachusetts Institute of Technology License 5
MMU - Memory Management Unit 5
OPB - IBM CoreConnect On-chip Peripheral Bus 5, 17, 25
PC – Personal Computer 36, 43
RISC - Reduced Instruction Set Computing 5
RS-232 - Recommended Standard 232 85
SDRAM - Synchronous Dynamic Random Access Memory 17
SPI - Serial Peripheral Interface 17
SRAM - Static Random Access Memory 17, 43
TCP/IP – Transmission Control Protocol/Internet Protocol 36
x
UART - Universal Asynchronous Receiver/Transmitter 2, 17
UML - Unified Modeling Language 26, 35
USB – Universal Serial Bus 36
UTL - Universidade Técnica de Lisboa 3
VHDL – VHSIC Hardware Description Language 20
VHSIC – Very High Speed Integrated Circuit 20
XMD - Xilinx Microprocessor Debugger 21, 24, 36, 55
XML - Extensible Markup Language passim
XPS - Xilinx Platform Studio 20, 43
ZBT - Zero Bus Turnaround 17
1
1 Introdução
1.1 Motivação
Desde o início deste século tem ocorrido um crescimento incessante no uso de sistemas
embebidos, colocando continuamente novos desafios ao desenvolvimento de soluções inovadoras e
de novas aplicações. Os sistemas embebidos encontram-se em todos os aspectos da vida
contemporânea, existindo muitos exemplos do seu uso na área das telecomunicações e dos
computadores, passando pela área da medicina e escritórios, indústria, sector da defesa e espaço,
bem como da electrónica de consumo e indústria automóvel. O mercado dos sistemas embebidos é
extremamente competitivo tendo um grande impacto na economia. A qualidade, inovação,
funcionalidades e o preço são os principais factores de escolha de um sistema embebido.
Os lucros obtidos através do negócio dos sistemas embebidos provêm tanto do hardware como
do software. O hardware é constituído pelas placas de sistema e pelos circuitos integrados; o
software é constituído pelas ferramentas de desenvolvimento, aplicações e sistemas operativos.
Apesar da maior parte das receitas serem provenientes dos circuitos integrados, a mais alta taxa de
crescimento de receitas provem do software. O valor adicionado pelo software embebido ao produto
final é em geral de uma ordem superior ao custo do próprio dispositivo. Na Tabela 1, encontra-se
representado o valor total das receitas em milhões de dólares do mercado global dos sistemas
embebidos, assim como das suas três componentes software, circuitos integrados e placas de
sistema, e os respectivos valores da taxa anual média de crescimento Average Annual Growth Rate
(AAGR), todos os valores são referentes aos anos 2004 e 2009.
Tabela 1. Mercado global dos sistemas embebidos em milhões de dólares, fonte BCC Inc. [1]
2004 2009 AAGR (%)
Software Embebido 1641 3448 16,0
Circuitos Integrados Embebidos 40536 78746 14,2
Placas de Sistema Embebidos 3693 5950 10,0
Total Receitas 45873 88144 14,0
Muitos sistemas embebidos residem em máquinas das quais se espera que funcionem
continuamente durante anos, são aplicados em sistemas críticos, ou mesmo em máquinas de difícil
acesso em funcionamento como é o caso de satélites e robots espaciais. Por estes motivos o
software dos sistemas embebidos é usualmente desenvolvido e testado com muito mais cuidado do
que o software dos computadores pessoais.
Assim, este trabalho foca-se no melhoramento de um simulador de ciclo exacto com novas
funcionalidades para simplificar o desenvolvimento de software embebido, destinado a sistemas
baseados na arquitectura FireWorks da Coreworks [2], nomeadamente as funcionalidades de
depuração e análise de desempenho.
2
1.2 Contexto
O trabalho desenvolvido no âmbito desta tese foi realizado em colaboração entre o autor da tese
e a empresa startup portuguesa de tecnologia Coreworks, proprietária do processador FireWorks [3].
O autor teve como objectivo o de obter o grau académico de mestre em engenharia electrotécnica e
de computadores no Instituto Superior Técnico, apoiando a empresa Coreworks no seu esforço de
desenvolvimento de ferramentas e aplicações para a sua arquitectura reconfigurável
FireWorks/SideWorks [4].
1.3 Objectivos
Esta tese teve como objectivo o melhoramento de um simulador ciclo exacto para apoio ao
desenvolvimento de software destinado a sistemas embebidos. Apesar do simulador poder ser
facilmente adaptado para sistemas com outros processadores, o seu desenvolvimento teve em
mente sistemas baseados na arquitectura FireWorks.
Os requisitos de desenvolvimento foram:
O simulador deve permitir a simulação de ciclo exacto de sistemas baseados na
arquitectura FireWorks;
O simulador deve ser desenvolvido em Java de forma a facilitar a portabilidade do mesmo
em diferentes sistemas operativos;
O simulador deve ser capaz de ler no formato Executable and Linking Format (ELF) o
código assembly dos programas a carregar;
O simulador deve ter uma arquitectura que facilite a ligação de periféricos e de memórias
aos barramentos do sistema a simular, como por exemplo o processador de sinais digitais
SideWorks da Coreworks;
O simulador deve possibilitar a configuração de todo o sistema, desde o processador, a
latência das instruções, definir os periféricos e memórias que fazem parte do sistema, e
configurar o mapeamento e latência das memórias e dos periféricos utilizados;
O sistema embebido suportado pelo simulador deve incluir memórias, Universal
Asynchronous Receiver/Transmitter (UART), e temporizadores preconcebidos que
possibilitem a interligação ao sistema e respectiva simulação;
A partir do simulador desenvolvido efectuar melhoramentos ao nível das funcionalidades
permitindo o simulador operar como analisador de desempenho e como
depurador/servidor GNU Debugger (GDB).
3
1.4 Aplicações
O simulador de sistemas baseados no processador FireWorks concebido no âmbito desta tese
tem tido aplicações práticas, enumerando-se na lista seguinte exemplos de trabalhos que utilizaram
ou utilizam o simulador:
“Methods for Dynamic Identification of Program Control-Flow Structures for FPGA-based
Systems”, Tiago José Rocha Alves da Costa, Tese de Mestrado Integrado em Engenharia
Electrotécnica e de Computadores (MIEEC), Faculdade de Engenharia de Universidade
do Porto (FEUP), Porto, Julho 2009;
“Mapping Runtime-Detected Loops from Microprocessors to Reconfigurable Processing
Units”, João Carlos Viegas Martins Bispo, Tese de Doutoramento em Engenharia
Informática e de Computadores, Instituto Superior Técnico (IST), Universidade Técnica de
Lisboa (UTL), Lisboa, Portugal, Julho 2012.
Em ambos os trabalhos o simulador foi usado para gerar relatórios com o traçado do percurso de
programas. No âmbito do trabalho de doutoramento de João Bispo, uma versão do simulador tem
sido utilizada para identificar determinadas sequências de instruções em traçados de execução.
1.5 Organização da Dissertação
No seguimento deste capítulo introdutório, o capítulo 2 apresenta a arquitectura e as
características do processador FireWorks e dos sistemas nele baseado. São apresentadas as
ferramentas de simulação, depuração e os ambientes actualmente utilizados na implementação e
desenvolvimento do software e do hardware de sistemas baseados no processador FireWorks.
O capítulo 3 é dedicado ao simulador de ciclo exacto desenvolvido no âmbito deste trabalho. São
explicados os motivos para o desenvolvimento de um simulador deste tipo e descritas as
características, funcionalidades e arquitectura do mesmo.
No capítulo 4 são apresentados os melhoramentos efectuados ao simulador e o porquê de tais
melhoramentos. Sendo descritas as modificações realizadas no simulador tendo em vista os novos
modos de operação análise de desempenho e depurador/servidor GDB.
Os resultados dos testes experimentais efectuados ao simulador encontram-se disponibilizados
no capítulo 5.
No capítulo 6 são apresentadas as conclusões e os trabalhos futuros que podem ser
desenvolvidos a partir do trabalho realizado nesta tese.
4
5
2 Sistemas Baseados no Processador FireWorks
Neste capítulo é apresentada a arquitectura FireWorks [3], são descritas as suas características e
funcionalidades, bem como os principais dispositivos que a compõem, desde o processador
FireWorks às memórias e periféricos e suas interligações. É dada uma visão geral sobre os
ambientes e ferramentas de simulação e depuração actualmente utilizadas no desenvolvimento de
software e hardware para esta arquitectura. Na parte final do capítulo, a documentação actualmente
disponível é introduzida.
2.1 Processador FireWorks
O FireWorks é um processador desenvolvido pela Coreworks [2] tendo por referência a versão 3.0
do processador OpenFire [5], e tendo em vista o seu uso em sistemas embebidos. É sintetizável e
optimizado para a implementação em Field-Programmable Gate Array (FPGA) e Application-Specific
Integrated Circuit (ASIC). As suas características permitem a concepção de sistemas tendo em conta
requisitos específicos, bem como o custo/performance. Os sistemas baseados neste processador
têm um variado leque de aplicações: comunicações de dados, multimédia, automação comercial,
controlo industrial, entre outras.
O processador OpenFire é uma implementação em Verilog do processador MicroBlaze da Xilinx,
o seu código fonte é de distribuição livre, disponibilizado sob a licença Massachusetts Institute of
Technology License (MIT License).
A seguinte lista, indica as características partilhadas pelos processadores FireWorks e OpenFire:
Arquitectura Reduced Instruction Set Computing (RISC);
Arquitectura com pipeline;
Instruções de 32 bits;
Instruction Set Architecture (ISA) idêntica ao do processador MicroBlaze da Xilinx;
Trinta e dois registos de uso geral de 32 bits;
Arquitectura totalmente ortogonal (ver subcapítulo 2.1.2);
Arquitectura Harvard (ver subcapítulo 2.1.4);
Barramento de endereçamento de 32 bits;
Formato big-endian é usado para representação dos dados e endereçamento (ver
subcapítulo 2.1.4);
Sem Memory Management Unit (MMU);
Sem sistema de cache;
Sem gestor de energia.
Entre o processador FireWorks e o processador OpenFire existem três grandes diferenças. A
primeira diferença encontra-se nos barramentos suportados. O FireWorks é constituído pelos
barramentos Local Memory Bus (LMB) e IBM CoreConnect On-chip Peripheral Bus (OPB) enquanto
a versão do processador OpenFire é constituída pelo barramento Fast Simplex Link (FSL) . As
características do barramento OPB permitem a interligação ao FireWorks de um grande número e
6
variedade de periféricos e memória externa, enquanto o barramento FSL do processador OpenFire
só permite interligação até ao máximo de oito dispositivos. A segunda diferença é o suporte de
interrupções e excepções por parte do processador FireWorks, algo que o processador OpenFire não
suporta. A terceira e última diferença está relacionada com os ciclos das instruções. No processador
FireWorks as instruções são executadas no mesmo número de ciclos que o processador MicroBlaze,
isto é o processador FireWorks é de ciclo exacto em relação ao processador MicroBlaze, enquanto
no processador OpenFire as instruções de multiplicação não o são.
Na Figura 1 encontra-se representado um diagrama de blocos de um sistema baseado no
processador FireWorks, contendo memória interna e externa, bem como dois periféricos.
Program
Counter
Instruction
DecodeGeneral
Purpose
Registers
Internal Rapidy Memory
(BRAM)
Inst
ruct
ion
Sid
e B
us In
terfa
ce
Dat
a S
ide
Bus
Inte
rface
UARTTimer/
Counter
Memory
Controller
External
Memory
OPB Bus
Special
Purpose
Registers
ALU
Barrel
Shift
Shift
Multiplier
Divisor
FireWorks Soft Processor
Field-Programmable Gate Array
LMB Bus
8/16/32 bits Memory Bus
LMB Bus
Figura 1. Diagrama de blocos de um sistema baseado no processador FireWorks [6]
Até à data da finalização do desenvolvimento da ferramenta ainda não existia documentação
oficial por parte da Coreworks em relação ao seu processador FireWorks, por este motivo e visto o
funcionamento do processador ser muito idêntico ao processador MicroBlaze pelo menos no ponto
de vista funcional, a documentação usada na descrição das características e funcionalidades do
processador FireWorks é a mesma que a Xilinx fornece para o seu processador MicroBlaze [6] [7] [8].
O manual e o código fonte do processador OpenFire são usados como documentação complementar
[5].
7
2.1.1 Instruções
Uma das características que o processador FireWorks partilha com o processador OpenFire é o
suporte da mesma ISA. A ISA suportada é idêntica à do processador MicroBlaze v6.00 da Xilinx, com
a excepção das instruções que operam com breaks, com a cache, com a interface FSL e com a
Floating Point Unit (FPU); todas as outras instruções são suportadas e implementadas na íntegra.
As instruções encontram-se agrupadas nas seguintes cinco categorias: aritméticas, lógicas,
saltos, especiais e leitura/escrita. São representadas por 32 bits e definidas num dos dois seguintes
formatos: o Tipo A ou o Tipo B.
O Tipo A é usado para instruções registo – registo. Contém o código de operação (Opcode), um
registo de destino (Destination Reg) e dois registos origem (Source Reg A e Source Reg B). Na
Figura 2 mostra-se este formato; o bit 0 é o mais significativo e o bit 31 é o menos significativo:
Opcode Destination Reg Source Reg A Source Reg B 0 0 0 0 0 0 0 0 0 0 0
0 6 11 16 21 31 Figura 2. Formato das instruções do Tipo A
O Tipo B é usado para instruções registo – imediato. Contém o Opcode, um registo de destino,
um registo de origem e um valor imediato de origem com dimensão de 16 bits. O valor imediato pode
ser estendido para uma dimensão de 32 bits, para isso é necessário preceder a instrução de Tipo B
com a instrução IMM. Na Figura 3 mostra-se este formato; o bit 0 é o mais significativo e o bit 31 é o
menos significativo:
Opcode Destination Reg Source Reg A Immediate Value
0 6 11 16 31 Figura 3. Formato das instruções do Tipo B
2.1.2 Registos
A arquitectura do processador é uma arquitectura totalmente ortogonal, isto é, as instruções têm o
mesmo formato base, permitindo o uso de qualquer registo e modo de endereçamento. Contém trinta
e dois registos de uso geral de 32 bits, enumerados de R0 a R31, e dezoito registos de uso especial
de 32 bits.
Ao se efectuar a chamada de funções, o valor de certos registos e o valor do endereço de retorno
da sub-rotina devem ser guardados para que se não perca o contexto da execução do programa.
Esses registos são todos os não voláteis. Normalmente, os valores destes registos são guardados na
stack durante o prólogo e repostos durante o epílogo.
Na Tabela 2 encontram-se indicados todos os registos de uso geral bem como os de uso especial
do processador FireWorks. Cada registo é identificado pela sua enumeração, sendo indicado o seu
tipo, o seu propósito, e como se efectua a sua modificação.
8
Tabela 2. Convenção do modo de utilização dos registos
REGISTO TIPO MODIFICAÇÃO PROPÓSITO
R0 Dedicado Inalterável Valor 0
R1 Dedicado Software Stack Pointer
R2 Dedicado Software Ponteiro da área de dados de leitura
R3-R4 Volátil Software Valores de retorno / Temporários
R5-R10 Volátil Software Passagem de parâmetros / Temporários
R11-R12 Volátil Software Temporários
R13 Dedicado Software Ponteiro da área de dados de leitura e escrita
R14 Dedicado Hardware Endereço de retorno de interrupções
R15 Dedicado Software Endereço de retorno de sub-rotinas
R16 Dedicado Hardware Endereço de retorno de depuração
R17 Dedicado Hardware Endereço de retorno de excepções
R18 Dedicado Software Reservado para o Assembler
R19-R31 Não volátil Software Uso geral e devem ser salvos ao chamar funções
RPC Especial Hardware Program Counter (PC)
RMSR Especial Hardware Machine Status Register (MSR)
REAR Especial Hardware Exception Address Register (EAR)
RESR Especial Hardware Exception Status Register (ESR)
RFSR Especial Hardware Floating Point Status Register (FSR)
RBTR Especial Hardware Branch Target Register (BTR)
RPVR0-RPVR11 Especial Hardware Processor Version Register, de 0 a 11 (PVR)
A função e como se procede à leitura e escrita dos registos de uso especial são descritos de
seguida:
Program Counter (PC) guarda o valor do endereço da instrução que se encontra no andar
Execute (EX). Pode ser lido através da instrução MFS, mas não pode ser escrito através
da instrução MTS;
Machine Status Register (MSR) contém os bits de controlo e de estado do processador.
Pode ser lido através da instrução MFS, e ser escrito através da instrução MTS ou pelas
instruções dedicadas MSRSET e MSRCLR;
Exception Address Register (EAR) guarda o endereço completo da instrução de
leitura/escrita que provoque uma excepção, caso contrario o seu conteúdo é indefinido.
Pode ser lido com a instrução MFS, mas não pode ser escrito através da instrução MTS;
Exception Status Register (ESR) contém os bits de estado das excepções do processador.
Pode ser lido com a instrução MFS, mas não pode ser escrito através da instrução MTS;
Floating Point Status Register (FSR) guarda o estado da unidade de vírgula flutuante.
Pode ser lido através da instrução MFS, e ser escrito através da instrução MTS. Este
registo no momento só é utilizado para manter a compatibilidade as ferramentas de
desenvolvimento do processador MicroBlaze. Pode ser utilizado para uma futura
implementação de uma unidade de vírgula flutuante;
Branch Target Register (BTR) no caso de não ocorrerem excepções causadas pelo
hardware, guarda o valor do endereço de destino das instruções de salto. Se uma
9
excepção for provocada por uma instrução no delay slot a execução retorna para o
endereço contido neste registo ao invés da execução normal guardada no registo R17.
Pode ser lido com a instrução MFS, mas não pode ser escrito através da instrução MTS;
Processor Version Register (PVR) é um conjunto de doze registos que guardam a
configuração do processador, entres outros dados. Estão enumerados de PVR0 a PVR11.
Podem ser lidos através da instrução MFS, e serrem escritos através da instrução MTS.
Estes registos no momento só são utilizados para manter a compatibilidade com as
ferramentas de desenvolvimento do processador MicroBlaze.
2.1.3 Pipeline
O processador é constituído por uma arquitectura em pipeline, dividida em três andares: Fetch
(IF), Decode (OF) e Execute (EX).
A maioria das instruções ao serem executadas demoram três ciclos de relógio, embora o
funcionamento em pipeline permita atingir desempenhos próximos de um ciclo de relógio por
instrução. Existe uma minoria de instruções que não obedecem à situação anterior. Essas instruções
específicas ocupam múltiplos ciclos de relógio no andar Execute (EX). Para que tal seja conseguido,
o funcionamento do pipeline é bloqueado até que a instrução no andar Execute (EX) seja terminada;
este bloqueio é conhecido por stall.
Em cada andar existe um registo interno Program Counter (PC), onde é guardado o valor do
endereço da instrução a executar.
Saltos, bloqueios do funcionamento do pipeline e data forwarding [9] são resolvidos
automaticamente pelo processador.
2.1.3.1 Instruções de Salto sem Delay Slot
Independentemente de ser salto condicional ou incondicional, uma instrução de salto sem delay
slot demora três ciclos de relógio a concluir o salto. O primeiro ciclo é utilizado para se efectuar
execução da instrução de salto, descarregar as instruções que se encontram nos andares Decode
(OF) e Fetch (IF) do pipeline, e carregar o andar Fetch (IF) com a instrução contida no endereço
para onde é efectuado o salto. Os restantes ciclos são utilizados no recarregamento do pipeline. Um
salto só se dá como terminado quando a instrução que se encontra no endereço para onde é
efectuado o salto ocupar o andar Execute (EX).
No caso de um salto condicional, se durante a execução da instrução não houver condições para
a ocorrência do salto a instrução é descartada. Nesta situação a instrução demora um ciclo de
relógio no andar Execute (EX). No ciclo de relógio seguinte é executada a instrução que
anteriormente ocupava o andar Decode (OF).
Na Figura 4 encontra-se representado um pequeno trecho da execução de um programa tendo
em conta o comportamento da execução das instruções no pipeline, onde se exemplifica a execução
da instrução de salto incondicional BRAI [10].
10
Ciclo 1 Ciclo 2 Ciclo 3 Ciclo 4 Ciclo 5 Ciclo 6 BRAI 80 IF OF EX
ADD R0,R0,R0 IF OF
BRAI 5832 IF
80: ADDIK R13,R0,9652 IF OF EX
ADDIK R2,R0,9584 IF OF
ADDIK R1,R0,19760 IF
Figura 4. Comportamento de instruções de salto sem delay slot no pipeline
2.1.3.2 Instruções de Salto com Delay Slot
O termo delay slot é utilizado para definir a posição ocupada pela instrução que se segue a uma
instrução de salto.
Ao ser efectuado um salto através de uma instrução de salto com delay slot a execução da
instrução que ocupa o delay slot é sempre efectuada. O primeiro ciclo da execução do salto é
utilizado para se efectuar a execução da instrução de salto com delay slot, descarregar a instrução
que se encontra no andar Fetch (IF) do pipeline, e carregar no mesmo andar a instrução contida no
endereço para onde é efectuado o salto. Os restantes ciclos são utilizados para o recarregamento do
pipeline e execução da instrução que se encontrava no delay slot. Só se dá um salto com delay slot
por concluído quando a instrução que se encontra no endereço para onde é efectuado o salto ocupar
o andar Execute (EX).
O número de ciclos de relógio necessários para se concluir um salto com delay slot depende da
latência da instrução que se encontra no delay slot.
Se a instrução que se encontra no delay slot, ao ser executada no andar Execute (EX) não
demorar mais de dois ciclos de relógio, o número total de ciclos necessários para se concluir o salto
é igual a três. Na Figura 5 encontra-se exemplificada a execução da instrução de salto com delay slot
BRLID, com o delay slot ocupado pela instrução OR, cuja latência é de um ciclo de relógio no andar
Execute (EX).
Ciclo 1 Ciclo 2 Ciclo 3 Ciclo 4 Ciclo 5 Ciclo 6 BRLID R15,136 IF OF EX
OR R0,R0,R0 IF OF EX
ADDI R1,R1,16 IF
ADDI R1,R1,-20 IF OF EX
SW R15,R1,R0 IF OF
Figura 5. Comportamento de uma instrução de salto com delay slot no pipeline, seguida de uma instrução
com um ciclo de relógio de latência no andar Execute (EX)
No caso da instrução contida no delay slot demorar mais do que dois ciclos de relógio a ser
executada no andar Execute (EX), o número de ciclos que um salto deste tipo demora a ser
concluído passa a ser igual ao número de ciclos de relógio que a instrução no delay slot demora a
ser executada no andar Execute (EX) mais o ciclo utilizado na finalização da instrução de salto com
delay slot. Na Figura 6 encontra-se exemplificada a execução da instrução de salto com delay slot
11
BRLID a efectuar um salto, com o delay slot ocupado por a instrução MUL de latência igual a três
ciclos de relógio no andar Execute (EX).
Ciclo 1 Ciclo 2 Ciclo 3 Ciclo 4 Ciclo 5 Ciclo 6 Ciclo 7 BRLID R15,136 IF OF EX
MUL R7,R5,5 IF OF EX EX EX
ADDI R1,R1,16 IF
ADDI R1,R1,-20 IF OF Stall EX
SW R15,R1,R0 IF Stall OF
Figura 6. Comportamento de uma instrução de salto com delay slot no pipeline, seguida de uma instrução
com três ciclos de relógio de latência no andar Execute (EX)
Se o salto não for efectuado as instruções deste tipo demoram um ciclo de relógio no andar
Execute (EX), sendo de seguida executadas as instruções que se encontram no pipeline.
A técnica de salto com delay slot reduz os dois ciclos de relógio de penalização para um ciclo, ao
se efectuar o recarregamento do pipeline durante execução de instruções saltos, aumentando assim
a eficiência do pipeline.
A mnemónica das instruções de salto com delay slot é sempre terminada pelo caracter D. O delay
slot não pode conter nem instruções de salto independentemente do seu tipo, nem a instrução IMM.
2.1.3.3 Instruções de Acesso à Memória
O acesso à memória é efectuado para se proceder a operações de leitura e de escrita. Cada uma
destas operações tem um valor de latência associado. Estes dois valores dependem das
características da memória a que se acede.
A latência de uma dada instrução de acesso à memória é igual à latência da operação que se
pretende efectuar na memória acedida.
Em geral a latência da memória para qualquer tipo de operação é superior a um ciclo de relógio,
esta situação leva a que instruções de acesso à memória ao serem executadas demorem vários
ciclos de relógio no andar Execute (EX) até serem finalizadas. Enquanto uma instrução deste tipo
ocupar o andar Execute (EX) o pipeline encontra-se bloqueado pelo processador até que a instrução
seja finalizada.
Quanto maior for o valor da latência da memória acedida menor vai ser a eficiência do pipeline.
Na Figura 7 encontra-se exemplificada a execução da instrução SW. Esta instrução tem a função
de escrever na memória uma palavra com o tamanho word (32 bits). Nesta execução o processador
acede a uma memória cujo valor da latência é igual a dois ciclos de relógio para operações de
escrita.
12
Ciclo 1 Ciclo 2 Ciclo 3 Ciclo 4 Ciclo 5 Ciclo 6 SW R15,R1,R0 IF OF EX EX
ADDI R6,R0,8476 IF OF Stall EX
ADDI R7,R0,8476 IF Stall OF EX
Figura 7. Comportamento de instruções de acesso à memória no pipeline
2.1.4 Arquitectura da Memória
O FireWorks é um processador baseado na arquitectura Harvard, o que significa que o acesso à
memória é efectuado através de dois barramentos: o de dados e de instruções. Ambos os
barramentos utilizam endereçamento de 32 bits, permitindo assim 4 Gbytes de endereçamento por
cada barramento (de dados e de instruções). A sobreposição dos barramentos é possível. Para tal
ser conseguindo o mapeamento deve ser realizado na mesma memória física.
O barramento de dados do processador suporta três tipos de acesso à memória diferenciados
pelo tamanho: byte (8 bits), halfword (16 bits) e word (32 bits). No acesso o alinhamento à word (os
dois bits menos significativos do endereço ao byte são sempre nulos) deve ser respeitado
independentemente do tipo utilizado. Na situação do alinhamento não ser respeitado é gerado o
evento correspondente para posterior tratamento.
No caso do barramento de instruções o único tipo de acesso suportado é o word (32 bits). No
acesso o alinhamento também deve ser respeitado como na situação anterior, mas se não o for não
será gerado qualquer tipo de evento.
O formato big-endian é utilizado tanto no endereçamento como na representação de dados, isto é,
os bytes são ordenados por ordem decrescente quanto ao seu peso em posições de memória
sucessivas.
Os periféricos utilizados em sistemas embebidos com o processador FireWorks são mapeados
em zonas de endereçamento de dados e acedidos pelo respectivo barramento de dados.
2.1.5 Reset, Excepções e Interrupções
O processador FireWorks suporta os seguintes excepção: reset, interrupções e excepções. O
tratamento dos mesmos é efectuado tendo em conta a sua prioridade. Encontrando-se ordenados
segundo esse factor por ordem decrescente na seguinte lista:
Reset;
Excepção de hardware;
Interrupção;
Excepção de software.
São utilizados certos endereços de memória para guardar vectores para o tratamento das
excepções. O vector não é mais que o endereço (directo ou indirecto) de uma porção de código para
o qual a execução do programa é desviada para tratamento do respectivo evento. Neste caso, o
vector é implementado por uma instrução IMM seguida da instrução BRAI, assim permitindo o
endereçamento de qualquer posição de memória.
13
A localização dos endereços de memória associados aos vectores e os registos de arquivo com o
endereço de retorno encontram-se definidos na Tabela 3. O intervalo de endereços entre 0x18 e
0x1C e o intervalo entre 0x28 e 0x4F encontram-se reservados para futuro uso e não devem ser
utilizados para que se possa garantir a compatibilidade com aplicações e sistemas desenvolvidos
posteriormente.
Tabela 3. Vectores e registo que contém o endereço de retorno
EVENTO ENDEREÇO DOS VECTORES REGISTO QUE CONTÉM O ENDEREÇO DE RETORNO
Reset 0x00000000 – 0x00000004
Excepção de software 0x00000008 – 0x0000000C Rx
Interrupções 0x00000010 – 0x00000014 R14
Reservado para uso futuro 0x00000018 – 0x0000001C
Excepção de hardware 0x00000020 – 0x00000024 R17 ou BTR
Reservado para uso futuro 0x00000028 – 0x0000004F
2.1.5.1 Reset
Na ocorrência de um reset, o processador esvazia o pipeline e carregar a instrução localizada no
endereço do vector correspondente. Os valores dos registos especiais Program Counter (PC),
Machine Status Register (MSR), Exception Address Register (EAR), Exception Status Register (ESR) e
Floating Point Status Register (FSR) são alterados para o valor 0.
Os registos de uso geral não são alterados pelo evento reset.
2.1.5.2 Excepções de Hardware
Ao se executar certo tipo de instruções no andar Execute (EX), erros internos do sistema ou
certas condições na unidade de divisão de inteiros ou na unidade de vírgula flutuante podem ocorrer.
Estas situações são reportadas ao processador para tratamento através do evento excepção de
hardware.
As excepções de hardware encontram-se em fase de implementação na versão do processador
FireWorks considerada neste trabalho. Na seguinte lista constam as excepções de hardware a
suportar e as descrições das mesmas:
Instruction Bus Exception é causada pela activação do sinal de erro IOPB_errAck por
parte de um dispositivo escravo ligado ao barramento OPB, com o acesso efectuado
através do barramento de instruções, o erro é provocado pelo acesso a uma posição de
memória não mapeada. A excepção também é causada pela activação do sinal
IOPB_timeout por parte do árbitro do barramento OPB ligado ao barramento de
instruções, o sinal é activado devido à não devolução da instrução pretendida dentro de
um determinado prazo. O barramento LMB de acesso à memória de instruções não causa
esta excepção;
Illegal Opcode Exception é causada por instruções que não constam na ISA utilizada pelo
processador FireWorks ou não são suportadas por ele. A instrução add r0,r0,r0
representa por 0x00000000 também causa este tipo de excepção;
14
Data Bus Exception é causada pela activação do sinal de erro DOPB_errAck por parte de
um dispositivo escravo ligado ao barramento OPB, com o acesso efectuado através do
barramento de dados, o erro é provocado pelo acesso a uma posição de memória não
mapeada. A excepção também é causada pela activação do sinal IOPB_timeout por
parte do árbitro do barramento OPB ligado ao barramento de dados, o sinal é activado
devido à não devolução do dado pretendido dentro de um determinado prazo. O
barramento LMB de acesso à memória de dados não causa esta excepção;
Unaligned Exception é despoletada pelo acesso não alinhado independentemente do tipo
ao barramento de dados;
Divide by Zero Exception é causada quando se efectua operações de divisão inteira onde
o divisor é igual a 0. Este tipo de operações é realizado através das instruções idiv ou
idivu;
FPU Exception é causada quando se efectuam determinadas operações na unidade de
vírgula flutuante. As operações que causam a excepção vão desde operações ilegais,
operações em que o divisor é igual a 0 e operações em que se obtêm determinados
resultados. Só se tirará proveito desta excepção numa futura versão do processador que
contenha uma unidade de vírgula flutuante.
Ao ser despoletada uma excepção o processador só procede ao seu tratamento se o bit
Exception Enable (EE) se encontrar no nível lógico 1 e o bit Exception In Progress (EIP) no nível
lógico 0, estes bits fazem parte do registo especial Machine Status Register (MSR).
A excepção de hardware ao ser tratada leva a que a instrução que provocou a excepção não seja
finalizada, o valor do registo interno Program Counter (PC) do andar Decode (OF) seja guardado no
registo de uso geral R17, o pipeline esvaziado e a instrução que se encontra no endereço do vector
de excepção de hardware (0x20) seja carregada no andar Fetch (IF). O bit Exception Enable (EE) é
inibido para não permitir o tratamento de outras excepções que possam ocorrer durante o tratamento
da actual, e o bit Exception In Progress (EIP) é desinibido para que não seja permitido o tratamento
de outro tipo de excepções. Estes dois bits encontram-se no registo especial Machine Status
Register (MSR). No registo especial Exception Address Register (EAR) é guardado o endereço da
instrução que provocou a excepção. No tratamento de uma excepção do tipo FPU Exception o
registo especial Floating Point Status Register (FSR) é alterado conforme a causa que a provocou.
Sempre que uma excepção é tratada o registo especial Exception Status Register (ESR) é modificado
tendo em conta o tipo de excepção que se encontra em tratamento.
Se a excepção for causada por uma instrução no delay slot, o endereço de destino resultante da
execução da instrução de salto com delay slot executada anteriormente é guardado no registo
especial Branch Target Register (BTR) e o bit Exception in delay slot (DS) do registo especial
Exception Status Register (ESR) é colocado no nível lógico 1. Apesar de nesta situação se continuar
a guardar o valor do registo interno Program Counter (PC) do andar Decode (OF) no registo de uso
geral R17, o seu valor deixa de ser válido. No delay slot são permitidas instruções que possam
causar excepções de hardware em que a execução normal do programa possa ser retomada, como
15
é o exemplo das instruções que têm como função a leitura e escrita de dados na memória (estas
podem causar excepção do tipo Unaligned Exception).
A instrução RTED é usada para o retorno deste tipo de evento, coloca automaticamente o bit
Exception Enable (EE) no nível lógico 1 e o bit Exception In Progress (EIP) no nível lógico 0 do
registo especial Machine Status Register (MSR) permitindo assim o tratamento de futuras excepções
e de outros tipos de excepções. O registo especial Exception Address Register (EAR) é modificado
para o valor 0. A execução é continuada a partir do endereço guardado no registo especial Branch
Target Register (BTR), isto se a excepção foi causada por uma instrução no delay slot. Se não, é
continuada a partir do endereço contido no registo de uso geral R17. Para tal basta verificar o bit
Exception in delay slot (DS) do registo especial Exception Status Register (ESR); se o seu valor lógico
for 1 a excepção foi provocada por uma instrução no delay slot; se o seu valor lógico for 0 é porque
não foi.
2.1.5.3 Interrupções
Só uma fonte de interrupção exterior é suportada pelo processador, sendo activada através do
porto de entrada Interrupt do mesmo. Para que possa responder a mais do que uma fonte de
interrupção é necessário o uso de um periférico específico para o caso, i.e., um controlador de
interrupções.
Se surgir uma interrupção no decorrer do tratamento de uma excepção de hardware, o tratamento
da mesma não é efectuado. O tratamento só terá lugar se a interrupção se mantiver activa depois de
terminado o tratamento da excepção de hardware.
Na ocorrência de uma interrupção o processador só procede ao seu tratamento se o valor do bit
Interrupt Enable (IE) for igual a 1 e o nível lógico do bit Exception In Progress (EIP) for igual a 0.
Ambos os bits encontram-se no registo especial Machine Status Register (MSR).
No início do tratamento de uma interrupção é permitida a finalização da execução da instrução
que se encontra no andar Execute (EX). Se esta instrução for do tipo salto com delay slot também é
permitida a finalização da execução da instrução no delay slot.
A instrução seguinte é substituída por uma instrução de salto para o vector de interrupção
localizado no endereço 0x10 e o seu endereço é guardado como endereço de retorno no registo de
uso geral R14. Se a instrução permitida for do tipo salto ou salto com delay slot o endereço de
retorno é guardado durante o último ciclo de relógio da finalização do respectivo salto. Se for de outro
tipo, o mesmo endereço é guardado durante o último ciclo de relógio da finalização da execução
dessa instrução.
Durante o tratamento de uma interrupção não é permitido o tratamento de outras interrupções.
Para tal o processador no início do tratamento coloca a 0 o bit Interrupt Enable (IE) do registo
especial Machine Status Register (MSR), desinibindo assim o tratamento de futuras excepções deste
tipo.
16
A instrução RTID é usada para o retorno deste tipo de evento, colocando automaticamente o bit
Interrupt Enable (IE) no nível lógico 1 para permitir o tratamento de futuras interrupções e retomado
a execução a partir do endereço guardado no registo de uso geral R14.
O número de ciclos de relógio que o processador demora a entrar na Interrupt Service Routine
(ISR) desde que é inicializado o tratamento da interrupção depende da latência da instrução ou
instruções que foram permitidas finalizar.
2.1.5.4 Excepções de Software
A excepção de software é causada pela inserção da instrução BRALID Rx,0x8 no código de um
programa. Neste tipo de evento o endereço de retorno é guardado no registo Rx. Embora possa ser
usado qualquer registo de uso geral, é recomendada a utilização do registo R15.
A instrução RTSD é usada para o retorno deste tipo de excepção, retomando a execução a partir
do endereço guardado no registo de uso geral utilizado para tal. O vector para este evento encontra-
se localizado no endereço 0x8.
2.2 Memória e Periféricos
2.2.1 Barramentos
O FireWorks sendo um processador baseado na arquitectura Harvard utiliza dois barramentos
para o acesso à memória; um barramento é utilizado para o acesso a dados e outro para o acesso a
instruções. Os barramentos utilizados são os seguintes: o barramento LMB e o barramento OPB.
O barramento LMB é simples, eficiente, síncrono, garantindo o acesso em um único ciclo de
relógio a memórias do tipo Block Random Access Memory (BRAM) e do tipo único mestre. Este
barramento é apenas utilizado para ligação à memória interna rápida do sistema, sendo esta
constituída por memória do tipo BRAM. O processador é constituído por dois barramentos LMB, um é
utilizado para o acesso à memória de instruções e o outro à memória de dados.
Para a ligação de periféricos, bem como de memória externa, a um processador FireWorks é
utilizada a versão 2.0 do barramento OPB. Este barramento é do tipo multi-mestre multi-escravo de
32 bit. A memória externa destina-se só a memória de dados, instruções armazenadas neste tipo de
memória não podem ser carregadas directamente pelo processador.
2.2.2 Memória
Um sistema baseado num processador FireWorks pode conter dois tipos de memória: memória
interna rápida, sempre parte integrante de qualquer sistema, e memória externa presente ou não
dependendo da configuração do mesmo.
A memória interna rápida é constituída por memória do tipo BRAM, apesar de o processador usar
uma arquitectura do tipo Harvard a memória interna rápida encontra-se unificada em uma única
BRAM de dois portos.
17
Para que um sistema baseado no processador FireWorks possa utilizar memória externa é
necessária a utilização de um controlador de memória. O controlador tem a função de aceder e gerir
os acessos à memória e é colocado entre o barramento OPB e a memória externa. O sistema
FireWorks suporta vários tipos de controladores de memória sendo diferenciados principalmente pelo
tipo de memória a que pretende aceder. Enumeram-se de seguida alguns tipos de controladores
suportados:
Controlador de memória Flash;
Controlador de memória Static Random Access Memory (SRAM);
Controlador de memória Synchronous Dynamic Random Access Memory (SDRAM);
Controlador de memória Double Data Rate Synchronous Dynamic Random Access
Memory (DDR SDRAM);
Controlador de memória BRAM;
Controlador de memória Zero Bus Turnaround (ZBT).
No acesso a dados na memória interna rápida, o valor da latência para operações de escrita
como para operações de leitura é igual a dois ciclos de relógio. No carregamento de instruções o
valor da latência é igual a um ciclo. O motivo da diferença de valores de latência no acesso a dados
e a instruções é devido ao barramento de instruções se encontrar na prática ligado directamente à
memória BRAM e não interligado através do barramento LMB. Com esta solução não existe assim
uma diminuição da eficiência do carregamento do pipeline devido à latência no acesso à memória
interna rápida através do barramento LMB, permitindo evitar o uso de uma unidade de pré-
carregamento de instruções no pipeline.
No caso da memória externa os valores das latências dependem do barramento OPB, do
controlador de memória usado, e do tipo de memória utilizado.
2.2.3 Periféricos
Os periféricos podem ser constituídos por registos de controlo, registos de estado, registos de
dados e memória, etc. Conforme o tipo de periférico pode ser necessário que o processador aceda a
todos esses recursos ou a apenas alguns. Para que tal seja possível é necessário proceder ao
mapeamento desses recursos no barramento OPB do barramento de dados. Todos os registos
mapeados têm o tamanho word (32 bits).
Existe um grande leque de periféricos que podem ser utilizados num sistema FireWorks. Na lista
seguinte constam algumas das funcionalidades de periféricos existentes:
Controlador de interrupções (encontra-se em fase de desenvolvimento);
Ethernet Media Access Control(MAC) ;
Universal Asynchronous Receiver/Transmitter (UART);
Serial Peripheral Interface (SPI);
Digital Signal Processing (DSP), por exemplo, o processador sinal digital SideWorks;
FPU;
Inter-Integrated Circuit (I²C);
18
Temporizadores/Contadores;
General Purpose Input/Output (GPIO);
Co-processadores;
Controladores de memória.
2.2.4 Acesso a Dados e a Instruções
O barramento de dados tanto para operações de escrita como para operações de leitura suporta
os seguintes tipos de transferências:
byte (8 bits), halfword (16 bits) e word (32 bits) para dispositivos de endereçamento à
word;
byte (8 bits) e halfword (16 bits) para dispositivos de endereçamento à halfword;
byte (8 bits) para dispositivos de endereçamento à byte.
O processador só suporta transferências que respeitem o endereçamento dos dispositivos
presentes no sistema. Outros tipos de transferências não são suportados.
No acesso a dados o alinhamento deve ser respeitado. Considera-se acesso alinhado se for
efectuado num dos seguintes modos: acesso através do tipo byte, acesso através do tipo halfword
onde o bit menos significativo do endereço é igual a 0 e o acesso através do tipo word onde os dois
bits menos significativos do endereço são iguais a 0.
Os modos de acesso para leitura de dados encontram-se representados na Tabela 4, e os modos
de acesso para escrita de dados encontram-se representados na Tabela 5. Nas tabelas
apresentadas os intervalos de bits de um endereço ou registo são representados entre parênteses
rectos e separados por dois pontos. Nessa representação o bit 0 representa o bit mais significativo e
o bit 31 representa o bit menos significativo.
Tabela 4. Modos de acesso para leitura de dados através dos barramentos
DADOS DO REGISTO rD
ENDEREÇO[30:31] TAMANHO DA
TRANSFERÊNCIA rD[0:7] rD[8:15] rD[16:23] rD[24:31]
11 byte Byte 3
10 byte Byte 2
01 byte Byte 1
00 byte Byte 0
10 halfword Byte 2 Byte 3
00 halfword Byte 0 Byte 1
00 word Byte 0 Byte 1 Byte 2 Byte 3
19
Tabela 5. Modos de acesso para escrita de dados através dos barramentos
DADOS DE UM ENDEREÇO DE UM DOS
BARRAMENTOS
ENDEREÇO[30:31] TAMANHO DA
TRANSFERÊNCIA Byte 0 Byte 1 Byte 2 Byte 3
11 byte rD[24:31]
10 byte rD[24:31]
01 byte rD[24:31]
00 byte rD[24:31]
10 halfword rD[16:23] rD[24:31]
00 halfword rD[16:23] rD[24:31]
00 word rD[0:7] rD[8:15] rD[16:23] rD[24:31]
O barramento de instruções só efectua transferências com o tamanho word (32 bits).
O acesso a instruções processa-se na mesma forma que o acesso a dados através do tipo word
(32 bits). Só que no caso das instruções, o acesso não alinhado não é possível de ocorrer, devido
aos dois bits menos significativos do registo especial Program Counter (PC) serem iguais a 0. Nestes
dois bits não é possível efectuar operações de escrita só operações de leitura, em qualquer operação
de escrita no registo especial Program Counter (PC) estes dois bits são descartados.
2.2.5 Mapeamento
Ambos os barramentos do processador utilizam endereçamento de 32 bits, em resultado acedem
a periféricos e memória num espaço de endereçamento de 0x00000000 a 0xFFFFFFFF. O espaço
de endereçamento começa no endereço de menor valor 0x00000000 e cresce até o endereço
0xFFFFFFFF.
Nos endereços de menor valor é onde se encontra mapeada a memória interna rápida; esta
memória é utilizada para guardar instruções e dados. Sendo este o único tipo de memória utilizado
para armazenar instruções tem de ocupar obrigatoriamente o intervalo de endereços de 0x0 a 0x4F,
devido às posições de memória deste intervalo encontram-se reservadas para o armazenamento dos
vectores de tratamento das excepções: reset, interrupções e excepções. De seguida encontra-se
mapeada a memória externa (caso faça parte da configuração do sistema). Esta memória só é
utilizada para o armazenamento de dados. Por último encontram-se mapeados os periféricos.
No espaço de endereçamento não é permitido o sobre posicionamento dos barramentos. O
barramento LMB só endereça a região mapeada para a memória interna rápida, todo o restante
espaço é endereçado pelo barramento OPB.
No intervalo de endereçamento do barramento OPB, pode-se associar regiões para memória
externa e periféricos, arbitrariamente. O número de periféricos que o barramento suporta depende do
número de recursos necessários a mapear pelos periféricos e do espaço de endereçamento livre que
o barramento dispõe para tal.
Ao se efectuar o mapeamento de periféricos ou memória, tem de se ter em consideração os
modos de acesso suportados pelos barramentos e pelos periféricos, para que não ocorram acessos
não alinhados. No acesso a instruções, apesar de não ocorrer acesso não alinhado, o mapeamento
da memória onde se situam as instruções deve respeitar o modo word (32 bits), para que a instrução
pretendida seja correctamente carregada pelo processador.
20
Na Figura 8 encontra-se representado o mapeamento típico de um sistema baseado no
processador FireWorks. O sistema é constituído por memória interna rápida, memória externa e por
periféricos. A configuração do sistema é que define os limites das regiões ocupadas pelos vários
dispositivos no espaço de endereçamento.
Memória Interna Rápida
(BRAM)
Memória Externa
Periféricos
(0x00000000)
(0xFFFFFFFF)
Sentido de crescimento
dos endereços
Figura 8. Mapeamento típico de um sistema baseado no processador FireWorks
2.3 Ambientes e Ferramentas de Simulação e Depuração
O processador FireWorks foi projectado para tirar o máximo partido das ferramentas de
desenvolvimento concebidas pela Xilinx para o processador MicroBlaze.
A Xilinx [11] disponibiliza o pacote de desenvolvimento Embedded Development Kit (EDK) para a
implementação de sistemas baseados no processador MicroBlaze em FPGAs da Xilinx. O pacote
EDK é constituído por um variado leque de ferramentas que possibilitam o desenvolvimento tanto do
hardware como do software. O EDK encontra-se disponível para as plataformas Windows, Solaris e
Linux.
Todo o processo de desenvolvimento do hardware de um sistema e sua implementação em FPGA
obedece a uma sequência de etapas. A primeira etapa consiste na síntese do sistema a partir da
descrição do mesmo em VHSIC Hardware Description Language (VHDL) ou Verilog. Na etapa
seguinte efectua-se o mapeamento, a colocação e encaminhamento, e a geração da configuração da
FPGA (bitstream). Na última etapa procede-se ao carregamento do bitstream gerado na FPGA.
Existem duas formas de realizar as etapas do processo de desenvolvimento de software e
hardware com o EDK; uma manual e outra através da ferramenta Xilinx Platform Studio (XPS)
incluída no pacote EDK. Na manual, todos os ficheiros e scripts usados nas várias etapas do
processo de desenvolvimento têm de ser criados e editados pelo utilizador, requerendo
conhecimentos avançados para tal. A ferramenta XPS actua como uma interface gráfica por cima do
EDK, e permite uma maior simplificação e interacção com o utilizador em todo o processo de
desenvolvimento e implementação do hardware. Através do XPS é possível criar e configurar um
sistema na totalidade: configurar o processador MicroBlaze, adicionar Intellectual Property Blocks (IP
Blocks) anteriormente concebidos pelo utilizador ou de bibliotecas, interligar os vários componentes
do sistema, efectuar o carregamento do software, gerar automaticamente o conjunto de scripts
necessários para efectuar a síntese e implementação, e proceder ao carregamento do bitstream
gerado na FPGA.
Para programação e depuração de software, o pacote EDK inclui uma versão modificada da
versão standard do conjunto de ferramentas da GNU, conhecida por GNU Toolchain [12]. As
21
modificações realizadas têm a finalidade de adaptar e fornecer opções adicionais que são
específicas dos sistemas baseados no processador MicroBlaze. Este conjunto de ferramentas
contém o compilador de C/C++ GNU Compiler Collection (GCC) [13] e o depurador GNU Debugger
(GDB) [14], entre outras ferramentas.
Com a função de depurar software carregado no sistema físico, o pacote EDK inclui a ferramenta
Xilinx Microprocessor Debugger (XMD). A ferramenta XMD permite conectar o computador onde se
efectua o desenvolvimento de programas ao microprocessador MicroBlaze, implementado
fisicamente numa placa de desenvolvimento de FPGA, através da interface Joint Test Action Group
(JTAG), possibilitando assim o carregamento do software na memória do sistema, o controlo da
execução do software, o acesso aos registos do processador, entre outras funcionalidades. Também
permite a depuração através do simulador do processador MicroBlaze de ciclo exacto Instruction Set
Simulator (ISS) disponibilizado no pacote EDK.
O utilizador pode usar a versão gráfica do cliente GDB, também disponibilizada no pacote EDK,
para se ligar à ferramenta XMD, permitindo assim uma maior simplificação da interacção
carregamento, execução e depuração do software.
2.4 Documentação
Até à data da finalização do desenvolvimento da ferramenta a conceber no âmbito desta tese não
existia documentação por parte da Coreworks referente ao processador FireWorks. Durante o
desenvolvimento da ferramenta foi utilizada a documentação referente ao processador OpenFire e ao
processador MicroBlaze e o apoio técnico de membros da Coreworks.
A documentação disponível para o processador MicroBlaze e suas ferramentas de
desenvolvimento é muito elucidativa, pode ser obtida através do sítio da Xilinx na internet [11]. A
documentação do processador OpenFire encontra-se disponível na internet na página do projecto do
processador [5]. Embora limitada, indica como fonte de informação mais detalhada a consulta da
documentação referente ao processador MicroBlaze. O código fonte escrito em Verilog, também
disponível na página do projecto, é uma fonte de informação a ter em conta.
O processador FireWorks bem como o processador MicroBlaze suportam excepções e
interrupções algo que o processador OpenFire não suporta. No entanto, a documentação destas
características é incompleta, tornando assim muito difícil desenvolver um simulador ou um depurador
independente para o processador MicroBlaze [15].
22
23
3 Simulador
Este capítulo é dedicado ao simulador ciclo exacto para arquitectura FireWorks. No início é
analisado o porquê de simular, sendo de seguida dada uma visão geral das características e
funcionalidades do simulador. Por último é descrita a arquitectura do simulador tendo em conta os
vários componentes do sistema, o processador, a memória e os periféricos.
3.1 Porquê Simular?
O método mais utilizado para a depuração de erros em software de sistemas embebidos é
proceder à sua execução controlada directamente no hardware do sistema. O controlo da execução
é efectuado através de um computador pessoal ligado ao sistema embebido através de um interface
de comunicação. Mas para que o controlo seja possível é necessário adicionar ao software uma
aplicação de monitorização (debug stub) no momento da criação do executável. Esta aplicação tem a
função de comunicar com o computador pessoal, proceder ao controlo interno da execução do
software, ler e escrever nos registos do processador, entre outras funcionalidades.
Este método de depurar erros traz inconvenientes. Devido à presença extra da aplicação de
monitorização, o software é carregado em posições de memória diferentes para o qual foi concebido,
o que pode causar alterações na execução normal do software, como por exemplo acesso a
posições de memória diferentes para o qual foi programado, o que pode esconder outros erros. Outro
inconveniente deste método é não proporcionar o controlo total sobre o ambiente de execução, se a
execução for interrompida por algum motivo e posteriormente for despoletado uma excepção ele não
será tratado pelo software, outra consequência é ser difícil replicar a ocorrência de certo tipo de
excepções.
O emprego de simuladores para a detecção de erros em software permite ultrapassar estes
inconvenientes e acrescentar funcionalidades não atingíveis pelo método anterior. Um simulador de
ciclo exacto, direccionado a sistemas embebidos é um programa que efectua a modelação parcial ou
mesmo completa de todos os aspectos do hardware em computadores pessoais. Permite a
modificação e acesso a todos os estados de um sistema e o controlo da execução, sem a utilização
de aplicações de monitorização, isto é, de forma não intrusiva. Esta funcionalidade possibilita assim o
seu uso para detecção de erros do software executado no simulador, sem as possíveis
consequências causadas pela utilização de uma aplicação de monitorização ou o não
processamento de excepções devido a paragens na execução do software.
A utilização de simuladores não tem só implicações a nível do software. As implicações também
se repercutem a nível do hardware, pois permite a avaliação de diferentes projectos sem o gasto na
construção física dos sistemas.
Apesar do custo inicial de desenvolvimento de um simulador, a sua utilização possibilita o acesso
a sistemas ou periféricos não existentes e o desenvolvimento e teste do software antecipadamente,
reduzindo drasticamente a duração do projecto e diminuindo significativamente os custos iniciais de
desenvolvimento e de manutenção do software para sistemas embebidos.
24
3.2 Descrição do Simulador
O simulador actualmente utilizado na simulação de sistemas baseados na arquitectura FireWorks
é o simulador de sistemas baseados na arquitectura MicroBlaze disponibilizado no pacote Embedded
Development Kit (EDK) pela Xilinx. O simulador é do tipo Instruction Set Simulator (ISS), é de ciclo
exacto e não permite o acesso a periféricos. A sua utilização só é possível através da ferramenta
Xilinx Microprocessor Debugger (XMD) e o seu código fonte não se encontra disponível ao público. O
software a simular só pode residir na memória mapeada no barramento Local Memory Bus (LMB) e o
tamanho do mesmo define o tamanho máximo da memória.
No âmbito desta tese é proposto um simulador totalmente concebido de raiz, desenvolvido em
Java de forma a facilitar a sua portabilidade entre diferentes sistemas operativos e a possibilitar uma
arquitectura modular através da utilização do mecanismo de carregamento dinâmico de classes. A
sua concepção permite o carregamento de ficheiros executáveis no formato Executable and Linking
Format (ELF) e a operação de forma autónoma, não dependendo das ferramentas actualmente
existentes. O código fonte é de acesso livre possibilitando assim futuras modificações.
O simulador efectua a modelação total do sistema. Tanto no ponto de vista funcional como do
ponto de vista temporal. A modelação temporal permite ao simulador ser de ciclo exacto e executar a
simulação ciclo a ciclo. Permite desta forma o acesso a todos os estados do sistema, e a obtenção
de resultados de desempenho do software, como o número de instruções e de ciclos processados.
No arranque o simulador carrega um ficheiro do tipo Extensible Markup Language (XML) com
toda a configuração do sistema a simular. Através deste ficheiro é possível definir o processador e os
vários periféricos que constituem o sistema, configurar a latência das instruções, mapeamento e
latência dos registos de cada periférico e definir o tipo, latência, dimensão e mapeamento das
memórias.
Em termos da arquitectura do simulador o processador e os periféricos não são parte integrante
do simulador, são módulos à parte. O seu carregamento é efectuado durante o arranque do
simulador conforme a configuração do sistema a simular. Esta funcionalidade permite o
desenvolvimento posterior de novos módulos, tanto de processadores como de periféricos.
Com o intuito de aferir e demostrar as funcionalidades do simulador foi concebido um sistema
baseado na arquitectura FireWorks constituído por um processador FireWorks com três andares de
pipeline, por um periférico OPB Timer/Counter [16] e por um periférico OPB UART Lite [17], sendo
este modelado parcialmente.
3.3 Arquitectura do Simulador
Os sistemas baseados na arquitectura FireWorks podem ter diferentes configurações,
dependendo da aplicação a que se destinam. Tendo em conta esta característica, o desenvolvimento
do simulador teve em mente uma arquitectura modular.
25
A estrutura do simulador consiste em duas partes, o núcleo central e os módulos. O núcleo central
desempenha três funções:
Configuração do simulador, procedendo à configuração do sistema pretendido através de
um ficheiro de configuração XML e ao carregamento do ficheiro executável ELF do
software a simular;
Operação do motor de simulação;
Modelação funcional e temporal da memória do sistema.
Os módulos definem e modelam funcionalmente e temporalmente os periféricos e o processador.
A descrição da arquitectura do simulador deve ser acompanhada com a visualização do código
fonte, diagrama de classes Unified Modeling Language (UML) e Javadoc do mesmo. Toda esta
documentação contém informação mais detalhada sobre o seu funcionamento, ver apêndice A. .
3.3.1 Configuração
Para que se possa efectuar a simulação do sistema pretendido, procede-se primeiro à
configuração do simulador. Esta acção decorre durante a inicialização da execução, e é composta
por quatro fases.
Na primeira fase é efectuado o carregamento e a validação do ficheiro XML de configuração do
sistema. Neste ficheiro encontra-se definido o processador e a latência das suas instruções, os
periféricos e o mapeamento e latência dos seus registos, as memórias definidas quanto ao tipo,
mapeamento e latência. A validação do ficheiro de configuração XML é efectuada de duas formas, é
validado quanto ao seu formato através do ficheiro Document Type Definition (DTD), e é validado
quanto ao seu conteúdo. No conteúdo é verificada a coerência do mapeamento das memórias e dos
registos dos periféricos do sistema a simular com a arquitectura FireWorks, e é verificado se as
instruções do processador e os registos dos periféricos estão definidos mais do que uma vez.
A segunda fase consiste no carregamento e validação dos ficheiros de configuração XML dos
módulos dos periféricos e do processador, os quais são referenciados no ficheiro de configuração do
sistema. No ficheiro de configuração do processador encontra-se definido o nome e número total de
instruções, e o número (0xbaab) de identificação do processador utilizado pelo compilador GNU
Compiler Collection (GCC). Nos ficheiros de configuração dos periféricos é definido o número e o
nome dos registos. Estes ficheiros são validados quanto ao seu formato através dos respectivos
ficheiros DTD, e é verificada a concordância entre os dados da configuração do sistema e os dados
da configuração dos módulos.
Na terceira fase é efectuada toda a configuração do sistema. É inicializada a memória com a
definição dos seus limites, tanto para o barramento LMB como para o barramento IBM CoreConnect
On-chip Peripheral Bus (OPB). O processador é inicializado efectuando-se o carregamento dinâmico
das classes do módulo correspondente e registando-se a Instruction Set Architecture (ISA) no
sistema de modelação da memória do núcleo central, com o objectivo de descodificar as instruções.
Os periféricos são inicializados efectuando-se o carregamento dinâmico das classes dos módulos
correspondentes, e alocando-se os registos na memória do sistema.
26
Na quarta e última fase é efectuada a validação e o carregamento do ficheiro executável ELF do
software a simular. É verificado se o ficheiro executável se destina ao processador do sistema a
simular e verifica se o mapeamento definido no ficheiro executável esta em conformidade com o
mapeamento da memória do sistema. Com as verificações realizadas é efectuado o carregamento do
conteúdo do ficheiro executável na memória do sistema e a sua descodificação em instruções.
Sempre que ocorra algum erro de configuração ou de validação o processo é interrompido,
provocando-se a finalização da execução do simulador. O simulador ao ser configurado com sucesso
fica pronto para iniciar a simulação através do motor de simulação.
No diagrama de actividades UML da Figura 9 representam-se as quatro fases da configuração do
simulador, implementadas através da classe system.SystemConfiguration.
Carrega ficheiro XMLde
configuração do sistema
Carrega ficheiros XMLdos módulos dos
periféricos e do processador
Configura o sistema- Inicializa Memória
- Inicializa Processador- Inicializa Periféricos
Carrega ficheiro ELF(ficheiro executável do software)
Simulador configurado(simulador pronto para dar inicio à simulação)
[não válido]
[não válidos]
[válido]
[válidos]
Finaliza execução(erro na configuração)
[válido]
[não válido]
[configuração errada]
[configuração correcta]
Figura 9. Configuração do simulador
27
3.3.2 Motor de Simulação
O controlo e a execução da simulação de todo o sistema são realizados através do motor de
simulação. O motor de simulação é uma máquina de estados em que as transições são despoletadas
pelo processador e a execução da simulação efectuada ciclo a ciclo.
O motor de simulação processa a cada ciclo de sistema um ciclo de processamento do
processador e um ciclo de processamento de cada periférico do sistema. Com os ciclos de
processamento do processador e dos periféricos a serem executados de forma sequencial torna-se
necessário manter o contexto temporal da simulação, uma vez que na realidade essas acções
ocorrem em simultâneo.
Para tal, a implementação de um registo de escrita deve conter um atributo temporário e um
atributo real. O atributo real é o atributo que é utilizado no processamento interno do periférico, visto
ser este que guarda o valor coerente com a contextualização da simulação. O processador ao
escrever num registo de escrita de um periférico o valor é guardado no atributo temporário do registo,
e ao ocorrer a finalização do processamento do ciclo do periférico é realizada a actualização do valor
do atributo real com o valor presente no atributo temporário.
Na Figura 10 encontra-se representado o diagrama de actividades UML do motor de simulação do
simulador do sistema baseado na arquitectura FireWorks utilizado durante os testes experimentais
realizados no âmbito desta tese. A implementação do motor de simulação foi realizada através do
método continue_ da classe system.SysteM.
Processa cicloprocessador FireWorks
Processa cicloperiférico OPB Timer/Counter
Processa cicloperiférico OPB UART Lite
[System Status = sys_status.Normal][System Status <> sys_status.Normal]
Figura 10. Motor de simulação do simulador
28
Na Tabela 6 apresentam-se os estados do sistema do motor de simulação. O sistema ao se
encontrar num estado diferente do estado Normal efectua a paragem da simulação.
Tabela 6. Estados do sistema
ESTADOS DESCRIÇÃO
Normal sistema a executar a simulação do software
Stop sistema finalizou a simulação do software
3.3.3 Memória
A modelação funcional e temporal da memória do sistema é efectuada no núcleo central do
simulador através da classe system.memory.Memory. A modelação efectuada no núcleo central
engloba o barramento LMB, o barramento OPB e a interligação do barramento OPB com os registos
dos periféricos, permitindo operações de escrita e leitura de dados e instruções.
Em operações de acesso e transferência de dados, a modelação é efectuada através de uma
máquina de estados. Os estados definem o comportamento da memória durante as operações
efectuadas pelas instruções. As transições de estado estão relacionadas com os tempos de acesso
das diferentes memórias e registos que compõem o sistema e com a forma de acesso aos dados.
Através da classe system.memory.Memory são disponibilizados métodos de leitura e escrita que
implementam os vários tipos de transferências suportados pela arquitectura FireWorks. Na Tabela 7
mostram-se os estados da máquina de estados da memória.
Tabela 7. Estados da memória
ESTADOS DESCRIÇÃO
Standby memória em estado de espera
Access acesso a uma posição de memória
Unaligned acesso a uma posição de memória de forma não alinhada
Mapped acesso a uma posição de memória não mapeada
Ready posição de memória pronta para ser lida ou escrita
Como o carregamento de instruções pelo processador num sistema baseado na arquitectura
FireWorks só pode ocorrer a partir da memória mapeada no barramento LMB, demorando esta
operação um ciclo de relógio, não existe a necessidade de implementar formalmente uma máquina
de estados. Foi antes implementado um método simples que permite ao processador carregar as
instruções.
No simulador os dados e as instruções contidas nas memórias e registos do sistema são
armazenados através da classe java.util.HashMap. A classe system.memory.Memory que
modela a memória do sistema contém três instâncias da classe java.util.HashMap: uma guarda
os dados, outra armazena as instruções e a outra guarda as instâncias das classes dos registos dos
periféricos. Ao se escrever um determinado dado numa posição de memória no barramento LMB o
núcleo central armazena o valor do dado na classe java.util.HashMap referente aos dados, e a
partir do mesmo dado efectua a descodificação da instrução, criando uma instância da classe da
instrução na classe java.util.HashMap referente às instruções.
29
3.3.4 Processador
A modelação temporal e funcional do processador é implementa no simulador através de um
módulo desenvolvido para o efeito. A implementação de processadores através de módulos
possibilita o desenvolvimento de várias versões de um dado processador, variando as suas
funcionalidades, como por exemplo, suporte ou não de interrupções, suporte ou não de excepções,
número de andares de pipeline, ISA, sem haver necessidade de se efectuar qualquer modificação ao
simulador. A utilização de módulos permite também a elaboração de uma biblioteca de módulos de
processadores possibilitando o teste de várias soluções de hardware para uma dada aplicação.
Os módulos de processadores obedecem a certas regras. Os módulos só podem ser instalados
na directória de instalação do simulador, mais propriamente na directória dtool/processors. A
implementação dos módulos é efectuada a partir das classes abstractas do pacote system.cpu. As
classes abstractas pertencentes ao pacote system.cpu são as seguintes:
system.cpu.CPU: classe que implementa o processador propriamente dito;
system.cpu.Instruction: classe que implementa a instrução genérica;
system.cpu.InstructionSetArchitecture: classe que efectua a descodificação
das instruções pertencentes ao processador.
A implementação propriamente dita do processador é efectuada a partir da classe do módulo do
processador instanciada por herança da classe system.cpu.CPU. A modelação do funcionamento
do processador é efectuada tanto temporalmente como funcionalmente através de uma máquina de
estados. As transições de estados estão relacionadas com a execução das instruções. Para tal o
comportamento das instruções é modelado a nível de ciclo e de pipeline. A modelação do
processador suporta o tratamento de interrupções e de excepções.
Na Tabela 8 descrevem-se os estados do processador FireWorks com três andares de pipeline
utilizado nos testes experimentais no âmbito desta tese.
Tabela 8. Estados do processador
ESTADOS DESCRIÇÃO
Normal processador a executar uma instrução normal
Delay_Slot processador a executar uma instrução com delay slot
Jump processador a executar uma instrução de salto
Stall processador a executar paragem do pipeline
Empty processador a executar uma instrução vazia
Mem_Access processador a executar uma instrução que acede à memória
DBZ processador a processar excepção de divisão por zero
Mem_Mapped processador a processar excepção de acesso a uma posição de memória de dados não mapeada
Mem_Unaligned processador a processar excepção de acesso a uma posição de memória de dados de forma não alinhada
Illegal processador a processar excepção de execução de uma instrução ilegal
Mapped processador a processar excepção de execução de acesso a uma posição de memória de instruções não mapeada
Stop processador para a execução do software
30
O processador pode evoluir do estado Normal para qualquer um dos outros estados.
Independentemente do processador modelado, uma vez atingido o estado Stop, o sistema
permanece nesse estado até ser reiniciado. Todos os restantes estados transitam para o estado
Normal.
As instruções do processador no simulador são implementadas através de classes, uma classe
por cada instrução. As classes de instruções são instanciadas por herança a partir da classe
system.cpu.Instruction. O processador ao efectuar o carregamento de uma dada instrução
não efectua internamente a sua descodificação, visto esta já se encontrar previamente descodificada
no sistema de memória do núcleo central do simulador.
No simulador o processador não é só constituído pelas instruções pertencentes à ISA, é também
constituído por instruções especiais. As instruções especiais têm o objectivo de definir estados que o
processador pode operar e não são despoletados pelas instruções da ISA.
A classe que define as instruções contém referência a uma classe do mesmo tipo. Esta
funcionalidade possibilita uma instrução ter o mesmo comportamento de outra instrução. Esta
funcionalidade é utilizada na implementação das instruções especiais, tem o mesmo comportamento
da instrução referenciada mas causa diferente transição do estado do processador.
Na Tabela 9 as instruções especiais pertencentes ao módulo do processador FireWorks com três
andares de pipeline utilizado nos trabalhos realizados no âmbito desta tese.
Tabela 9. Instruções especiais do processador
INSTRUÇÕES DESCRIÇÃO
empty instrução vazia
illegal instrução ilegal
mapped instrução não mapeada numa posição de memória
stop instrução de finalização da execução da simulação
A classe do módulo do processador é registada no sistema de memória do núcleo central do
simulador ao se efectuar o carregamento dinâmico das classes do módulo do processador, durante o
processo de configuração do simulador. A sua função é descodificar as instruções do processador.
3.3.5 Periféricos
Num sistema baseado na arquitectura FireWorks o número e tipo de periféricos variam
dependendo da configuração usada. A modelação temporal e funcional é implementada através de
módulos. A utilização de módulos permite a elaboração de uma biblioteca de módulos de periféricos,
possibilitando assim o teste de várias soluções e configurações de hardware.
Como os módulos de processadores, os módulos de periféricos obedecem a certas regras. Os
módulos só podem ser instalados na directória de instalação do simulador, mais propriamente na
directória dtool/opbdevices. A implementação dos módulos é efectuada a partir das classes
abstractas do pacote system.opb_device. Há duas as classes abstractas pertencentes ao pacote
system.opb_device:
system.opb_device.OPBDevice, classe que implementa o periférico;
31
system.opb_device.OPBRegister, classe que implementa o registo genérico do
periférico.
Os periféricos podem conter vários registos. Os registos no simulador são classes instanciadas
por herança a partir da classe system.opb_device.OPBRegister. Durante o processo de
configuração, ao se efectuar o carregamento dinâmico das classes do módulo do periférico as
classes referentes aos registos são alocadas no sistema de memória do núcleo central.
Na Figura 11 encontra-se representado o diagrama de actividades UML do processamento de um
ciclo de um periférico genérico com a funcionalidade de gerar interrupções. Na primeira fase é
efectuado o processamento propriamente dito do periférico. Na segunda são efectuadas as
actualizações dos registos de escrita modificados pelo processador, mantendo-se assim o contexto
da simulação. Na última fase é gerada a interrupção do periférico se as condições para tal se
verificarem.
Processa ciclo
Actualiza os registos de escrita
Gera interrupção
[necessita gerar interrupção]
[não necessita gerar interrupção]
[necessita actualizar registos de escrita]
[não necessita actualizar registos de escrita]
Figura 11. Processamento de um ciclo de um periférico
32
33
4 Melhoramentos
Este capítulo explica as melhorias efectuadas ao simulador de ciclo exacto da arquitectura
FireWorks. São analisados as motivações dos melhoramentos, e apresentadas as modificações
realizadas ao simulador que permitiram o funcionamento em modo de analisador de desempenho
(profiler) e modo de depurador/servidor GNU Debugger (GDB).
4.1 Modo Analisador de Desempenho
4.1.1 Motivação?
Dependendo da função para o qual um dado software é concebido, podem existir requisitos
específicos quanto ao desempenho que obrigatoriamente têm de ser compridos. Se não se verificar o
cumprimento desses requisitos corre-se o risco de o software não desempenhar correctamente a
função para a qual foi desenvolvido. Em sistemas embebidos, devido a recursos limitados e ao tipo
de aplicações a que se destinam, esta situação é de extrema importância, como é o caso dos
sistemas multimédia e de tempo-real. Para se efectuar a validação do cumprimento destes requisitos
recorre-se à utilização de uma ferramenta de desenvolvimento, conhecida como analisador de
desempenho.
O analisador de desempenho é uma ferramenta que recolhe informação acerca do
comportamento de um programa, no decorrer da sua execução, com o objectivo de medir a
frequência e duração das chamadas das funções, e assim determinar que secções do software
devem ser optimizadas.
Com a informação recolhida consegue-se saber se o número de vezes que as funções foram
executadas eram as esperadas, podendo assim detectar possíveis erros cuja origem poderia ser
difícil de detectar de outra forma. Como o analisador de desempenho usa informação recolhida
durante a execução do programa, pode ser usado em programas muito grandes e complexos cujo
código fonte é extenso e difícil de analisar. É uma forma dinâmica de análise, por oposição a outras
formas estática de análise do código fonte.
Os analisadores de desempenho usam uma larga variedade de técnicas para a recolha dos
dados, onde se incluem:
Instrumentação: coloca código no programa para recolha dos dados;
Estatísticos: utiliza métodos de amostragem para recolha de dados;
Excepções: utiliza excepções para a recolha de dados;
Simulador: recolhe dados utilizando um simulador de instruções.
Todas estas técnicas têm as suas vantagens e desvantagens, sendo usadas dependendo do fim
a que se destinam e das respostas a que se pretende chegar. Existem analisadores que usam uma
mistura de algumas destas técnicas para a recolha da informação.
34
4.1.2 Descrição do Modo Analisador de Desempenho
Para a análise de desempenho a ferramenta actualmente utilizada é o gprof [18] da GNU. O gprof
efectua análise de desempenho por amostragem e de forma intrusiva. Para que a ferramenta possa
gerar os resultados da análise de desempenho é necessário adicionar ao software a analisar código
para efectuar a recolha dos dados. Esta adição é efectuada durante a compilação de forma
automática através da opção de compilação –pg. A inclusão do código de recolha de dados de
desempenho no software pode causar respostas diferentes para as quais foi programado.
Adicionalmente, a utilização do método de amostragem para a recolha de dados leva com que os
resultados obtidos não sejam precisos.
Com as funcionalidades do simulador já referidas anteriormente, a capacidade de identificar que
instrução foi executada e que posição memória a mesma ocupa, a capacidade de efectuar a
contagem do número de ciclos realizados e o suporte de carregamento de ficheiros executáveis no
formato Executable and Linking Format (ELF) [19], foi desenvolvido o modo de funcionamento
analisador de desempenho.
A partir da informação contida no ficheiro executável ELF sobre as funções que constituem o
software, foi desenvolvido um novo motor de simulação com a habilidade de efectuar a contagem
das funções e das instruções executadas bem como o número de ciclos realizados. Efectua-se assim
a recolha dos dados de desempenho ao nível do simulador, isto é, de forma não intrusiva, sem a
necessidade de introduzir código para efectuar essa recolha. Outra consequência da recolha de
dados de desempenho ao nível do simulador é a contabilização de todas as ocorrências, obtendo-se
assim dados precisos.
A análise de desempenho é efectuada desde o começo da execução do software até à sua
finalização, considerando-se como fim de execução a execução da função exit.
Os resultados obtidos são apresentados através de um relatório de análise de desempenho
baseado no formato dos relatórios produzidos pela ferramenta GNU gprof, e fornecido ao utilizador
na forma de ficheiro de texto, ver apêndice F. para mais detalhes. O relatório é composto por quatro
secções: flat profile, general profile, instruction profile e function profile.
Na secção flat profile os resultados são apresentados por função quanto ao número de
chamadas, número de ciclos realizados, fracção do tempo de execução e número de ciclo realizados
por chamada.
A secção general profile apresentada os resultados por função quanto ao número total de ciclos
realizados, número total de instruções executadas, número de execuções e número de chamadas.
Na secção instruction profile os resultados são apresentados por instrução quanto ao número total
e frequência relativa das execuções.
Na última secção, function profile, os resultados reportados são os mesmos que os reportados na
secção general profile adicionando-se os resultados da execução das instruções nas funções. Os
resultados das instruções reportam o tipo de instrução, o número de execuções por instrução e a
frequência relativa das instruções executadas.
35
4.1.3 Arquitectura do Modo Analisador de Desempenho
A arquitectura do modo analisador de desempenho é na generalidade idêntica à arquitectura do
modo simulador, exceptuando-se a configuração e o motor de simulação.
Na configuração a diferença encontra-se na fase do carregamento do ficheiro executável em
formato ELF. No modo analisador de desempenho não é só efectuado o carregamento do código
executável do software; é também efectuado o carregamento da informação com a descrição das
funções que fazem parte do software. Esta informação igualmente disponibilizada através do ficheiro
ELF contém as referências de todas as funções bem como o espaço de memória que ocupam.
A partir do motor de simulação do simulador foi desenvolvido um novo motor de simulação para o
modo analisador de desempenho com o intuito de permitir a contabilização dos ciclos e instruções
executadas por função do software simulado. O motor de simulação foi implementado através do
método profile da classe system.SysteM. Na sua implementação recorreu-se a certas
funcionalidades do simulador como capacidade do processador identificar se uma instrução foi
executada ou não e que posição de memória ocupa, e de efectuar a contagem do número de ciclos
processados. Toda a recolha de dados é efectuada ao nível do simulador e não ao nível do software
simulado, logo, de forma não intrusiva. O método desenvolvido para a recolha de dados no motor de
simulação permite a contabilização de todas as ocorrências, o que permite uma análise precisa e não
aproximada.
No fim de cada ciclo processado e se uma instrução foi executada, os dados da instrução são
cruzados com a informação disponibilizada pelo ficheiro ELF sobre as funções para saber a que
função pertence a instrução. O resultado é armazenado em tabelas para posterior tratamento. No
final da simulação processam-se os dados e o resultado é disponibilizado um relatório de análise de
desempenho do software em formato de texto.
Na Figura 12 representa-se o diagrama de actividades Unified Modeling Language (UML) do
motor de simulação do analisador de desempenho.
Processa cicloprocessador FireWorks
Processa cicloperiférico OPB Timer/Counter
Processa cicloperiférico OPB UART Lite
[System Status = sys_status.Normal] [System Status <> sys_status.Normal]
Contabilizaciclos e instruções
por função
Contabilizaciclos e instruções
por função
[instrução ISAexecutada]
[instrução ISA não executada]
Figura 12. Motor de simulação do modo analisador de desempenho
36
4.2 Modo Depurador/Servidor GDB
4.2.1 Motivação?
No processo de desenvolvimento de software destinado a sistemas embebidos, boa parte do
tempo é gasto na correcção de erros, validação e eliminação de defeitos do programa. A todo este
procedimento dá-se o nome depuração.
A depuração é um trabalho demorado e com algum grau de complexidade. Todos estes factores
dependem do ambiente de desenvolvimento utilizado, do qual fazem parte a linguagem de
programação e as ferramentas de desenvolvimento, as quais incluem o depurador.
O depurador é um programa de computador, cuja função é verificar e controlar a execução de
outros programas com o objectivo de detectar os seus erros e defeitos. O controlo consiste em
examinar/alterar valores dos registos e da memória, definir posições no programa onde a execução
deve ser suspensa (breakpoints), reinicializar ou voltar atrás na execução, etc. Todas estas
características variam de depurador para depurador, até para um dado depurador as suas
características podem variar dependendo do sistema para o qual foi implementado.
A importância de uma ferramenta destas pode ser um factor decisivo a favor da escolha de um
dado sistema ou linguagem de programação. A sua inexistência ou existência de poucas
capacidades podem conduzir mesmo à situação de se preterir um sistema ou linguagem de
programação melhor adaptada à tarefa pretendida, a favor de outras menos adequadas.
Não se deve subestimar o impacto de uma ferramenta como o depurador num projecto de
concepção de software de sistemas embebidos. Esta provoca a diminuição do tempo gasto em
desenvolvimento e em suporte, e a diminuição do número de erros e defeitos do programa.
Reduzindo os custos com o desenvolvimento, e aumentando a qualidade do suporte e do produto
final.
4.2.2 Descrição do Modo Depurador/Servidor GDB
Actualmente na depuração de software para sistemas baseados na arquitectura FireWorks são
utilizadas duas ferramentas, a ferramenta mb-gdb e a ferramenta Xilinx Microprocessor Debugger
(XMD). O princípio de funcionamento de ambas as ferramentas obedece a uma arquitectura
cliente/servidor, com a comunicação efectuada através do protocolo GDB Remote Serial Protocol
(GDB RSP) (ver apêndice G. ) [14] sobre o protocolo Transmission Control Protocol/Internet Protocol
(TCP/IP). A ferramenta mb-gdb é uma versão adaptada da ferramenta cliente GDB para o
processador MicroBlaze. A ferramenta XMD actua como servidor GDB. Ambas as ferramentas
correm no Personal Computer (PC), ligado ao hardware (placa de Field-Programmable Gate Array
(FPGA)) por um cabo Universal Serial Bus (USB) do lado do PC, ligado a um conversor físico
USB/Joint Test Action Group (JTAG) que por sua vez está ligado ao conector JTAG da placa de
FPGA. Esta montagem está ilustrada na Figura 13.
37
mb-gdb
(Cliente GNU Debugger)
XMD
(servidor GNU Debugger)
ISS (Instruction Set Simulator)
ProtocoloGDB RSP
(Protocolo TCP/IP)
Hardware Baseado na Arquitectura FireWorks
Personal Computer
(Interface JTAG)
(Interface USB)
Conversor USB/JTAG
Figura 13. Interligação entre o hardware e as ferramentas XMD e mb-gdb
A ferramenta XMD tem dois modos de depuração; o modo de hardware e o modo de simulador.
Em modo hardware a execução do software ocorre no hardware, sendo necessário, no acto da
compilação do software adicionar uma porção de código com o nome de stub. A função do stub é a
de controlar a execução do software e efectuar a comunicação entre o hardware e a ferramenta
XMD. A adição do stub é efectuada de forma automática no acto da compilação através da opção –
xl-mode-xmdstub. Este modo acarreta alguns inconvenientes já referidos: é necessário ter acesso
ao hardware físico o que nem sempre é possível; não se consegue ter o controlo total sobre o
ambiente de execução; ao se introduzir o stub pode haver efeitos colaterais durante a execução do
software.
No modo de simulador a ferramenta XMD em conjunto com o simulador do processador
MicroBlaze de ciclo exacto ISS da Xilinx permite a depuração não intrusiva. Como já foi referido,
nesta abordagem o simulador contém as seguintes limitações:
Não pode aceder a periféricos;
O software só pode residir na memória interna do sistema;
A dimensão do software define o tamanho máximo da memória a que o simulador pode
aceder;
Só é possível a utilização através da ferramenta XMD;
O seu código fonte é fechado.
Para que a ferramenta mb-gdb possa fornecer depuração ao nível do código fonte o ficheiro
executável ELF deve conter informação no formato Debug With Attributed Record Format (DWARF),
versão 2 [20]. Esta informação é adicionada automaticamente durante a compilação do software
através da opção –g.
Uma das alterações efectuadas ao simulador foi a eliminação da ferramenta XMD no processo de
depuração do software. A alteração foi implementada através da concepção de um novo modo de
funcionamento do simulador: o modo depurador/servidor GDB. A arquitectura usada continua a
38
permitir o uso da ferramenta cliente GDB mb-gdb no processo de depuração. A arquitectura
cliente/servidor é mantida: a ferramenta mb-gdb continua a operar como cliente GDB e o simulador
no modo depurador/servidor GDB opera como servidor. A interligação é igualmente efectuada
através do protocolo GDB RSP sobre o protocolo TCP/IP. Na Figura 14 ilustra-se a interligação entre
o simulador e a ferramenta mb-gdb.
Personal Computer
mb-gdb
(Cliente GNU Debugger)
simulador
(servidor GNU Debugger)
Modo Depurador/Servidor GNU Debugger
ProtocoloGDB RSP
(Protocolo TCP/IP)
Figura 14. Interligação entre o simulador e a ferramenta mb-gdb
Os comandos implementados do protocolo GDB RSP possibilitam a execução normal do
software, a execução instrução a instrução, a inserção e remoção de breakpoints e a visualização e
modificação dos registos, memória e variáveis.
O simulador foi adaptado para permitir paragens de execução do software através de breakpoints.
A técnica utilizada é efectuada ao nível do simulador de uma forma não intrusiva, visto não se
adicionar ou alterar código ao software, esta técnica não tem restrições quanto ao número de
breakpoints que se pode utilizar num sistema. Uma vantagem desta técnica é a de suspender toda a
simulação do sistema num breakpoint, eliminando-se assim a possibilidade de ocorrerem excepções
não tratadas.
4.2.3 Arquitectura do Modo Depurador/Servidor GDB
A arquitectura do modo depurador/servidor GDB do ponto de vista geral, é um servidor do tipo
GDB integrado com simulador da FireWorks.
A implementação do servidor GDB consistiu no desenvolvimento de uma interface de
comunicação entre a ferramenta mb-gdb e o simulador. As funcionalidades desta interface foram
implementadas através de métodos na classe tools.Gdb.
Os pacotes do protocolo GDB RSP suportados pela interface estão descritos nas tabelas
seguintes. Os pacotes implementam comandos que o cliente dá ao servidor, para mais detalhes
consultar apêndice G. . Na Tabela 10 listam-se os pacotes utilizados para a manipulação de registos
do processador, tanto em operações de escrita como de leitura.
Tabela 10. Pacotes para manipulação de registos
PACOTE DEFINIÇÃO DO packet-data
retorna o valor de todos os registos g
retorna o valor do registo n... pn...
modifica os registos para XX... GXX...
modifica o registo n... para r... Pn...=r...
39
Na Tabela 11 são indicados os pacotes para a manipulação da memória. Com estes, pacotes é
possível efectuar operações de escrita e leitura na memória do sistema.
Tabela 11. Pacotes para manipulação da memória
PACOTE DEFINIÇÃO DO packet-data
lê length bytes da memória a partir do endereço addr maddr,length
modifica length bytes da memória a partir do endereço addr com os
dados XX...
Maddr,length:XX...
modifica length bytes da memória a partir do endereço addr com os
dados binários XX... codificado no sistema de oito bit
Xaddr,length:XX...
Os pacotes utilizados para obtenção da informação sobre o estado do sistema encontram-se
representados na Tabela 12.
Tabela 12. Pacotes de informação do estado do sistema
PACOTE DEFINIÇÃO DO packet-data
inquire sobre o offset das secções Text , Data, Bss do software qOffsets
O controlo da simulação do software é efectuado através dos pacotes indicados na Tabela 13,
estes pacotes permitem a inserção e remoção de breakpoints, a definição das tarefas e o controlo da
execução do software. Neste último caso os pacotes implementados permitem a execução de uma
só instrução como a execução contínua do software.
Tabela 13. Pacotes de controlo do software
PACOTE DEFINIÇÃO DO packet-data
define tarefa para as operações subsequentes (m, M, g, G, …),
tarefa usada nos comandos C e s:
. T igual a -1 é aplicado a todas as tarefas
. T igual a 0 é aplicado a qualquer a tarefa
HcT
define tarefa para as operações subsequentes (m, M, g, G, …),
tarefa usada em outras operações:
. T igual a 0 é aplicado a qualquer a tarefa
HgT
executa o programa a partir do ponto onde actualmente se encontra c
executa uma única instrução do programa a partir do ponto onde actualmente se encontra
s
remove software breakpoint z0,addr,length
insere software breakpoint Z0,addr,length
termina o programa K
reporta o último sinal ?
Com a excepção da fase final, todo o procedimento de configuração do simulador no modo
depurador/servidor GDB é realizado da mesma forma que na configuração no modo simulador. A
fase destinada a efectuar o carregamento do ficheiro executável ELF foi removida no modo
depurador/servidor GDB, uma vez que a ferramenta md-gdb já inclui esta funcionalidade. Foi
adicionada uma nova fase no final da configuração para efectuar a configuração da comunicação e
colocar a interface em modo de espera no final. Na Figura 15 encontra-se representado o diagrama
de actividades UML das fases da configuração do modo depurador/servidor GDB.
40
Carrega ficheiro XMLde
configuração do sistema
Carrega ficheiros XMLdos módulos dos
periféricos e do processador
Configura o sistema- Inicializa Memória
- Inicializa Processador- Inicializa Periféricos
Configura a comunicação da interface
[não válido]
[não válidos]
[válido]
[válidos]
Finaliza execução(erro na configuração)
[configuração correcta]
[configuração errada]
[configuração errada]
[configuração correcta]
Interface em modo espera(simulador pronto para dar inicio à simulação)
Figura 15. Configuração do modo depurador/servidor GDB
Dois dos comandos implementados do protocolo GDB RSP estão relacionados com o controlo da
execução do software. Um dos pacotes efectua a execução contínua do software parando em
breakpoints. O outro pacote efectua a execução de uma só instrução do software.
Para que o simulador opere destas duas formas a parte da arquitectura referente ao motor de
simulação foi alterada para suportar dois motores de simulação. Um motor para a execução contínua
e outro para a execução de uma só instrução. A arquitectura foi reformulada para permitir a utilização
41
de vários motores de simulação, podendo apenas um operar a cada instante. A arquitectura
possibilita durante a paragem de execução do software efectuar a troca do motor de simulação, esta
troca só é possível de realizar devido ao facto do simulador guardar a cada instante todo o contexto
da simulação do sistema.
O motor de simulação que permite a execução contínua do software é o mesmo que foi utilizado
no modo de simulador. O motor de simulação que possibilita a execução de uma só instrução
encontra-se representado no diagrama de actividades UML da Figura 16, tendo sido implementado
pelo do método step da classe system.SysteM.
Processa cicloprocessador FireWorks
Processa cicloperiférico OPB Timer/Counter
Processa cicloperiférico OPB UART Lite
[instrução ISA não executada]
[instrução ISA executa]
Figura 16. Motor de simulação do modo depurador/servidor GDB
Foi adicionado um novo estado ao sistema, o estado Breakpoint para implementar a paragem
do sistema num breakpoint durante a execução do software. Este estado provoca a paragem de todo
o sistema. Na Tabela 14 listam-se novamente os estados do processador com inclusão do estado
Breakpoint.
Tabela 14. Extensão dos estados do sistema
ESTADOS DESCRIÇÃO
Normal sistema a executar a simulação do software
Stop sistema finalizou a simulação do software
Breakpoint sistema com execução parada devido a breakpoint
Nas operações de leitura e escrita efectuadas com a ferramenta mb-gdb na memória do sistema
não se justifica a modelação funcional e temporal da memória; são efectuadas de forma directa ao
nível do simulador. Para possibilitar esta funcionalidade foram implementados novos métodos de
42
acesso à memória na classe system.memory.Memory. Para permitir ao mb-gdb efectuar operações
de leitura e escrita nos registos do processador foram implementados métodos com essa finalidade
na classe system.cpu.CPU.
Devido ao facto de serem as instruções a causar a mudança de estado do processador, houve a
necessidade de desenvolver uma nova instrução especial, a instrução breakpoint, que leva o
processador para o estado Breakpoint. Na Tabela 15 listam-se novamente as instruções do
processador com a inclusão especial breakpoint.
Tabela 15. Extensão das instruções do processador
INSTRUÇÕES DESCRIÇÃO
empty instrução vazia
illegal instrução ilegal
mapped instrução não mapeada numa posição de memória
stop instrução de finalização da execução da simulação
breakpoint instrução breakpoint
A instrução especial breakpoint é semelhante à instrução especial Stop com a excepção de
não provocar a paragem final da execução do software, mas apenas a paragem por breakpoint, de
onde a execução do software pode ser retomada novamente.
A inserção e remoção dos breakpoints na memória do sistema são efectuadas pela interface entre
o servidor GDB e o simulador, em consequência do envio de comandos por parte da ferramenta mb-
gdb. Este tipo de comando contém informação sobre a posição de memória onde deve ser colocado
o breakpoint. A inserção de um breakpoint na memória do sistema é efectuada da mesma forma que
a inserção da instrução especial Stop. Na remoção de um breakpoint a interface coloca na sua
posição de memória a instrução referenciada pela instrução breakpoint, deixando assim o
breakpoint estar guardado na memória do programa.
43
5 Testes Experimentais
Neste capítulo são descritos os testes experimentais realizados no simulador e num sistema real
baseado na arquitectura FireWorks, e são apresentados os resultados obtidos, efectuando-se a
aferição do simulador. As funcionalidades das melhorias implementadas, o modo de analisador de
desempenho e o modo de depurador/servidor GNU Debugger (GDB), são demonstradas através de
testes funcionais.
5.1 Testes de Aferição do Simulador
5.1.1 Descrição dos Testes
Devido à complexidade de implementação de um simulador de um sistema baseado num
microprocessador não se consegue provar a sua funcionalidade. Consegue-se sim dar um certo grau
de confiança sobre o seu funcionamento através de testes de aferição. Os testes de aferição
consistem na realização de testes no simulador tendo como referência o sistema real. Isto é, são
executados tanto no sistema real como no simulador um conjunto de testes julgados adequados para
a função, os resultados obtidos comparados com o objectivo de detectar erros. Com a inexistência de
erros a confiança na funcionalidade do simulador aumenta.
O sistema real usado no âmbito desta tese foi fornecido pela CoreWorks através de uma placa de
desenvolvimento Field-Programmable Gate Array (FPGA) da Digilent [21]. O modelo da placa
fornecida Spartan-3 Board é constituído pela FPGA Spartan-3 da Xilinx [11]. O sistema FireWorks
configurado foi o seguinte:
Processador FireWorks de três andares de pipeline;
Periférico OPB Timer/Counter;
Periférico OPB UART Lite;
64kBytes de memória interna rápida, tipo Block Random Access Memory (BRAM);
64kBytes de memória externa, tipo Static Random Access Memory (SRAM);
Frequência do relógio do sistema 50MHz.
As operações necessárias para se realizar os testes no sistema real são efectuadas através de
um Personal Computer (PC), interligado à placa de desenvolvimento FPGA através de um cabo null
modem ligado nas respectivas portas séries de ambos os dispositivos. Para se descarregar os
programas de teste utilizou-se o programa Xilinx Platform Studio (XPS) da Xilinx e para visualizar os
resultados obtidos um programa do tipo HyperTerminal [22].
Para se realizar os testes no simulador à que primeiro efectuar a sua instalação num PC, como
indicado no apêndice B. . E saber como opera-lo, ver apêndice C. para mais detalhes.
O ficheiro Extensible Markup Language (XML) com a configuração do sistema baseado no
processador FireWorks utilizada nos testes é instalado com o simulador e usado por defeito pelo
mesmo, o conteúdo do ficheiro é auto-explicativo ver apêndice D. . Os ficheiros XML com a
configuração dos módulos dos periféricos e do processador encontram-se no apêndice E. .
44
Todos os programas de teste utilizados nos testes do simulador foram compilados com a versão
mb-gcc 3.4.1 do compilador GNU Compiler Collection (GCC) presente no Microblaze GNU Toolchain
(Xilinx EDK 8.1.0i). E compilados por defeito com os seguintes opções:
-mxl-barrel-shift, para o compilador utilizar instruções Barrel Shift;
-mno-xl-soft-div, para o compilador utilizar as instruções Interger Divide;
-mno-xl-soft-mul, para o compilador utilizar as instruções Multiply;
-xl-mode-executable, para o compilador usar o modo por defeito na compilação, o
programa começa no endereço 0x00000000 e é ligado com o crt0.o;
-Wall, para activar todos os avisos opcionais durante a compilação;
-O2, para o compilador gerar código executável com o nível dois de optimização.
O objectivo de forçar o compilador utilizar as instruções acima referidas é de testar o máximo
número de instruções diferentes.
Os ficheiros executáveis dos testes realizados no âmbito dos testes de aferição encontram-se na
subdirectoria benchmark da directoria test_programs_executable referenciada no apêndice
B.6 . O código fonte e os respectivos ficheiros de compilação Makefile dos testes de aferição
encontram-se na subdirectoria benchmark da directoria test_programs_source_code
referenciada no apêndice B.6 .
Os testes de aferição encontram-se divididos em dois grupos. O primeiro, constituído por oito
algoritmos e o segundo por cinco versões do Dhrystone Benchmark diferenciadas pelo nível de
optimização do código executável gerado. A utilização Dhrystone Benchmark deve-se ao facto de ser
um dos principais benchmarks utilizados pela indústria neste tipo de sistemas.
Para se poder validar os testes de aferição, os testes realizados para o efeito devem produzir
informação tanto a nível funcional com a nível temporal. No caso dos algoritmos esse requisito não é
completamente satisfeito, principalmente a nível temporal. Com o objectivo de contornar esta
situação os programas dos algoritmos sofreram alterações. Na função main() de cada algoritmo foi
introduzido um sistema de contagem de ciclos de relógio, a contagem começa a ser efectuada antes
do começo da execução do algoritmo propriamente dito e finalizada depois da sua finalização. O
número de ciclos obtidos é mostrado no final. No caso do Dhrystone Benchmark esta situação não se
coloca porque o resultado disponibilizado pelo benchmark está relacionado com o número de
iterações do loop principal por segundo, logo apresenta informação tanto a nível funcional como a
nível temporal.
O Dhrystone Benchmark ao ser executado pede ao utilizador que indique o número de vezes que
o benchmark internamente deve ser executado, nos testes realizados no âmbito desta tese foi
indicado quatro.
45
Os nomes dos ficheiros executáveis dos algoritmos com relógio usados nos testes de aferição do
simulador encontram-se listados na Tabela 16.
Tabela 16. Nome dos executáveis dos algoritmos com relógio
ALGORITMOS EXECUTÁVEIS
Autocorrelation autocorrelation.clock
Discrete Cosine Transform Algorithm fdct.clock
Fibonacci Number fibonacci.clock
Intel/DVI ADPCM Coder adpcm-coder.clock
Intel/DVI ADPCM Decoder adpcm-decoder.clock
Quicksort Algorithm quicksort.clock
Tak Benchmark tak.clock
Tower of Hanoi hanoi.clock
Na Tabela 17 encontram-se indicados o tamanho total e das secções dos ficheiros executáveis
dos algoritmos com relógio usados nos testes de aferição do simulador.
Tabela 17. Tamanho dos executáveis dos algoritmos com relógio
ALGORITMOS text data bss TOTAL
Autocorrelation 3093 48 1384 4525
Discrete Cosine Transform Algorithm 3925 48 2568 6541
Fibonacci Number 3113 48 1032 4193
Intel/DVI ADPCM Coder 3333 456 3592 7393
Intel/DVI ADPCM Decoder 3273 456 3080 6821
Quicksort Algorithm 3293 248 1232 4773
Tak Benchmark 3197 48 1032 4277
Tower of Hanoi 3133 48 1032 4213
Os nomes dos ficheiros executáveis das várias versões do Dhrystone Benchmark usados nos
testes de aferição do simulador encontram-se listados na Tabela 18.
Tabela 18. Nome dos executáveis do Dhrystone Benchmark
BENCHMARK EXECUTÁVEIS
Dhrystone Benchmark (–O0) dhrystone.-O0
Dhrystone Benchmark (–O1) dhrystone.-O1
Dhrystone Benchmark (–O2) dhrystone.-O2
Dhrystone Benchmark (–O3) dhrystone.-O3
Dhrystone Benchmark (–Os) dhrystone.-Os
Na Tabela 19 encontram-se indicados o tamanho total e das secções dos ficheiros executáveis
das várias versões do Dhrystone Benchmark usado nos testes de aferição do simulador.
Tabela 19. Tamanho dos executáveis do Dhrystone Benchmark
BENCHMARK text data bss TOTAL
Dhrystone Benchmark (–O0) 10569 80 11296 21945
Dhrystone Benchmark (–O1) 7793 80 11296 19169
Dhrystone Benchmark (–O2) 7549 80 11296 18925
Dhrystone Benchmark (–O3) 8325 80 11296 19701
Dhrystone Benchmark (–Os) 7245 80 11296 18621
46
5.1.2 Resultados dos Testes no Sistema Real
Encontram-se listados na Tabela 20 o número de ciclos de relógio obtidos nos testes dos
algoritmos com relógio no sistema real.
Tabela 20. Número de ciclos obtidos nos testes dos algoritmos com relógio no sistema real
ALGORITMOS NÚMERO DE CICLOS
Autocorrelation 43750
Discrete Cosine Transform Algorithm 10119
Fibonacci Number 4711
Intel/DVI ADPCM Coder 64033
Intel/DVI ADPCM Decoder 59423
Quicksort Algorithm 49605243
Tak Benchmark 89760594
Tower of Hanoi 53477387
Na Tabela 21 encontram-se indicados os Dhrystones por segundo obtidos através dos testes do
Dhrystone Benchmark realizados no sistema real.
Tabela 21. Dhrystones por segundo obtidos nos testes do Dhrystone Benchmark no sistema real
BENCHMARK DHRYSTONES POR SEGUNDO
Dhrystone Benchmark (–O0) 17
Dhrystone Benchmark (–O1) 38
Dhrystone Benchmark (–O2) 38
Dhrystone Benchmark (–O3) 45
Dhrystone Benchmark (–Os) 39
5.1.3 Resultados dos Testes no Simulador
Encontram-se listados na Tabela 22 o número de ciclos de relógio obtidos nos testes dos
algoritmos com relógio no simulador.
Tabela 22. Número de ciclos obtidos nos testes dos algoritmos com relógio no simulador
ALGORITMOS NÚMERO DE CICLOS
Autocorrelation 43750
Discrete Cosine Transform Algorithm 10119
Fibonacci Number 4711
Intel/DVI ADPCM Coder 64033
Intel/DVI ADPCM Decoder 59423
Quicksort Algorithm 49605243
Tak Benchmark 89760594
Tower of Hanoi 53477387
47
Na Tabela 23 encontram-se indicados os Dhrystones por segundo obtidos através dos testes do
Dhrystone Benchmark realizados no simulador.
Tabela 23. Dhrystones por segundo obtidos nos testes do Dhrystone Benchmark no simulador
BENCHMARK DHRYSTONES POR SEGUNDO
Dhrystone Benchmark (–O0) 17
Dhrystone Benchmark (–O1) 38
Dhrystone Benchmark (–O2) 38
Dhrystone Benchmark (–O3) 45
Dhrystone Benchmark (–Os) 39
Efectuando a comparação entre os resultados obtidos nos testes efectuados no sistema real e no
simulador no âmbito dos testes de aferição pode-se concluir que os resultados obtidos são iguais,
validando assim o funcionamento do simulador para este conjunto de testes.
5.2 Testes Modo Simulador
5.2.1 Descrição dos Testes
Os testes modo simulador são compostos por dois conjuntos de testes, são eles os testes modo
simulador propriamente ditos e os testes funcionais do processador.
Os ficheiros executáveis, código fonte e respectivos ficheiros de compilação Makefile dos testes
realizados no âmbito dos testes modo simulador situam-se nas mesmas subdirectorias dos testes de
aferição.
Na realização dos testes modo simulador foi utilizado o grupo dos algoritmos. Os algoritmos
sofreram uma modificação em relação ao grupo de algoritmos usados nos testes de aferição, o
sistema de contagem de ciclos de relógio foi retirado. O número de ciclos que o algoritmo levou a ser
executado passou a ser dado directamente pelo simulador, com a diferença de serem resultados
totais e não de trechos como acontece nos testes realizados para aferir o simulador.
O objectivo dos testes modo simulador é de demostrar o seu funcionamento e a capacidade do
simulador obter o número de ciclos de relógio e de instruções executadas sem a necessidade de
inserir código extra nos programas.
Os nomes dos ficheiros executáveis dos algoritmos sem relógio usados nos testes do modo
simulador encontram-se listados na Tabela 24.
Tabela 24. Nome dos executáveis dos algoritmos sem relógio
ALGORITMOS EXECUTÁVEIS
Autocorrelation autocorrelation
Discrete Cosine Transform Algorithm fdct
Fibonacci Number fibonacci
Intel/DVI ADPCM Coder adpcm-coder
Intel/DVI ADPCM Decoder adpcm-decoder
Quicksort Algorithm quicksort
Tak Benchmark tak
Tower of Hanoi hanoi
48
Na Tabela 25 encontram-se indicados o tamanho total e das secções dos ficheiros executáveis
dos algoritmos sem relógio usados nos testes do modo simulador.
Tabela 25. Tamanho dos executáveis dos algoritmos sem relógio
ALGORITMOS text data bss TOTAL
Autocorrelation 572 36 1384 1992
Discrete Cosine Transform Algorithm 1428 36 2568 4032
Fibonacci Number 2633 36 1032 3701
Intel/DVI ADPCM Coder 828 456 3592 4876
Intel/DVI ADPCM Decoder 776 456 3080 4312
Quicksort Algorithm 2837 236 1232 4305
Tak Benchmark 2717 36 1032 3785
Tower of Hanoi 2665 36 1032 3733
Os ficheiros executáveis dos testes realizados no âmbito dos testes funcionais do processador
encontram-se na subdirectoria cpu_tests da directoria test_programs_executable
referenciada no apêndice B.6 . O código fonte e os respectivos ficheiros de compilação Makefile
dos testes de aferição encontram-se na subdirectoria cpu_tests da directoria
test_programs_source_code referenciada no apêndice B.6 .
O objectivo dos testes funcionais do processador é demonstrar a implementação e o
funcionamento das interrupções e excepções do processador modelado no simulador.
Os nomes dos ficheiros executáveis dos testes funcionais do processador constam na Tabela 26.
Tabela 26. Nome dos executáveis dos testes funcionais do processador
TESTES EXECUTÁVEIS
Interrupções clock
Excepções exceptions
5.2.2 Resultados dos Testes em Modo Simulador
Na Tabela 27 encontram-se listados os resultados obtidos através dos testes realizados em modo
simulador. Por cada teste efectuado é indicado o número de ciclos, número de instruções, Cycles Per
Instruction (CPI) e o tempo de execução num sistema real equivalente.
Tabela 27. Resultados dos testes dos algoritmos sem relógio no simulador
ALGORITMOS NÚMERO
DE CICLOS NÚMERO DE INSTRUÇÕES
CPI
TEMPO DE EXECUÇÃO
REAL
Autocorrelation 44489 31342 1,42 0,00088978
Discrete Cosine Transform Algorithm 12981 8125 1,60 0,00025962
Fibonacci Number 5347 3556 1,50 0,00010694
Intel/DVI ADPCM Coder 68659 48753 1,41 0,00137318
Intel/DVI ADPCM Decoder 63148 45166 1,40 0,00126296
Quicksort Algorithm 49605730 31304147 1,58 0,99211454
Tak Benchmark 89761134 59217380 1,52 1,79522280
Tower of Hanoi 53477516 37748824 1,42 1,06955030
Comparando os resultados dos testes modo simulador a nível funcional com os testes
equivalentes efectuados na aferição do simulador obtiveram-se resultados idênticos.
49
Como o número de ciclos em modo simulador é um valor total e não de um trecho do programa
não se consegue comparar directamente os valores. Mas pode-se efectuar comparação através da
grandeza dos mesmos, o valor do número de ciclos em modo simulador teoricamente será sempre
maior que o valor obtido através dos testes de aferição. Efectuando a comparação tendo em conta a
grandeza entre os valores obtidos foi esse o resultado obtido.
Os outros resultados demostram a capacidade do simulador em recolher dados para efectuar
análise de desempenho sem a necessidade de inserir código nos programas para essa finalidade.
5.2.3 Resultados dos Testes Funcionais do Processador
Os resultados dos testes funcionais do processador deram os resultados esperados.
O teste Interrupções não passa de um relógio, com o processador a tratar e a efectuar contagem
do número de interrupções geradas pelo periférico OPB Timer/Counter. Periférico OPB
Timer/Counter foi configurado para gerar uma interrupção a cada segundo.
Para testar as excepções foi utilizado o teste Excepções, uma excepção de cada tipo é provocada
pelo programa teste e tratada pelo processador. Até à finalização da tese o tratamento de excepções
ainda não tinha sido totalmente implementado no processador FireWorks real, como tal a
implementação efectuada no módulo do processador disponibilizado no simulador foi parcial.
5.3 Testes Modo Analisador de Desempenho
5.3.1 Descrição dos Testes
Os programas de testes utilizados em modo analisador de desempenho são os mesmos que
foram usados em o modo simulador.
O objectivo dos testes modo analisador de desempenho é de mostrar o funcionamento do
simulador na recolher de dados detalhados e precisos para a análise de desempenho. E na produção
de um relatório de desempenho com esses mesmos dados.
5.3.2 Resultados dos Testes em Modo Analisador de Desempenho
Na demonstração dos resultados obtidos dos testes modo analisador de desempenho, tomou-se o
algoritmo Fibonacci Number como referência. O algoritmo foi configurado para efectuar o cálculo
( ). A Figura 17 exibe um excerto do relatório de desempenho do algoritmo Fibonacci Number. O
excerto do relatório mostra a informação contida na secção General Profile. Os dados apresentados
estão organizados por função. Sendo indicado o número de ciclos e instruções executadas, o
número de vezes que a função foi executada e chamada, bem como os resultados totais. Para a
visualização completa do relatório da análise de desempenho do algoritmo ver apêndice F. .
50
General profile
cycles instructions execute calls function
6 1 1 1 _start
0 0 0 0 _vector_sw_exception
0 0 0 0 _vector_interrupt
0 0 0 0 _vector_hw_exception
7 6 2 1 _start1
1 1 1 1 exit
22 13 1 1 __do_global_dtors_aux
13 7 1 1 frame_dummy
40 29 6 1 _crtinit
4687 3183 1 1 fib
17 12 3 1 main
0 0 0 0 RS232_readByte
66 30 3 3 RS232_writeByte
33 21 6 3 cw_outbyte
0 0 0 0 cw_inbyte
54 34 2 2 cw_padding
195 85 6 1 cw_outnum
0 0 0 0 cw_getnum
124 80 3 1 cw_printf
0 0 0 0 _exception_handler
0 0 0 0 _hw_exception_handler
0 0 0 0 _interrupt_handler
3 2 1 1 _program_clean
3 2 1 1 _program_init
31 22 1 1 strlen
20 12 1 1 __do_global_ctors_aux
14 9 3 1 __init
11 7 2 1 __fini
5347 3556 45 24
Figura 17. Excerto do relatório da análise de desempenho do programa número de Fibonacci
Com os testes modo analisador de desempenho mostrou-se a capacidade do simulador gerar
relatórios detalhados de desempenho sem a necessidade de se inserir código nos programas a
analisar.
5.4 Testes Modo Depurador/Servidor GDB
5.4.1 Descrição dos Testes
Os ficheiros executáveis dos testes realizados no âmbito dos testes funcionais do processador
encontram-se na subdirectoria gdb_tests da directoria test_programs_executable
referenciada no apêndice B.6 . O código fonte e os respectivos ficheiros de compilação Makefile
dos testes de aferição encontram-se na subdirectoria gdb_tests da directoria
test_programs_source_code referenciada no apêndice B.6 .
O propósito da realização dos testes em modo depurador/servidor GDB é demostrar as
funcionalidades do simulador quando aplicado na depuração de software. Com o objectivo de realizar
os testes foram concebidos dois programas para o efeito. Cada programa tem duas versões
diferenciadas pela configuração usada na compilação. Em ambas as versões foi utilizada a
configuração de compilação usada nos programas de teste dos outros modos de funcionamento.
Sendo numa versão adicionado a essa configuração a opção de compilação –g, como já referido
anteriormente esta opção dá indicação ao compilador para adicionar informação de depuração ao
programa.
51
Os nomes dos ficheiros executáveis sem informação de depuração usados nos testes modo
depurador/servidor GDB do simulador encontram-se listados na Tabela 28.
Tabela 28. Nome dos executáveis sem informação de depuração
TESTES EXECUTÁVEIS
Loop loop
Print print
Interrupções clock
Na Tabela 29 encontram-se indicados o tamanho total e das secções dos ficheiros executáveis
dos testes sem informação de depuração realizados em modo depurador/servidor GDB do simulado.
Tabela 29. Tamanho dos executáveis sem informação de depuração
TESTES text data bss TOTAL
Loop 536 36 1032 1604
Print 2717 60 1032 3809
Interrupções 3213 36 1040 4289
Os nomes dos ficheiros executáveis com informação de depuração usados nos testes modo
depurador/servidor GDB do simulador encontram-se listados na Tabela 30.
Tabela 30. Nome dos executáveis com informação de depuração
TESTES EXECUTÁVEIS
Loop (debug) loop.debug
Print (debug) print.debug
Interrupções (debug) clock.debug
Na Tabela 31 encontram-se indicados o tamanho total e das secções dos ficheiros executáveis
dos testes com informação de depuração realizados em modo depurador/servidor GDB do simulado.
Tabela 31. Tamanho dos executáveis com informação de depuração
TESTES text data bss TOTAL
Loop (debug) 536 36 1032 1604
Print (debug) 2717 60 1032 3809
Interrupções (debug) 3213 36 1040 4289
A intenção de efectuar testes com o programa Interrupções é de testar se o simulador em modo
depurador/servidor GDB ao efectuar uma paragem da execução do software devido a uma
breakpoint todo o funcionamento do sistema fica suspenso, incluindo os periféricos (neste caso o
periférico OPB Timer/Counter). Eliminando-se assim a possibilidade de ocorrerem excepções não
tratadas.
5.4.2 Resultados dos Testes em Modo Depurador/Servidor GDB
O simulador em modo depurador/servidor GDB funcionou como o esperado, possibilitou ao
programa cliente mb-gdb o controlo da execução dos programas testados.
52
Através do programa cliente mb-gdb foram efectuadas um conjunto de operações durante as
execuções dos programas com o objectivo de validar e testar os comandos do protocolo GDB
Remote Serial Protocol (GDB RSP) implementados no simulador. As operações consistiram em
inserir e remover breakpoints, ler e alterar valores dos registos e de posições de memória, visualizar
valores de variáveis, acompanhar a execução do programa através do código assembly e através do
código fonte escrito em linguagem C entre outras. Excertos da comunicação podem ser visualizadas
no apêndice H. .
Todos os comandos opcionais implementados no simulador com a excepção do comando pn...
(retorna o valor do registo n...) foram testados com êxito. Não foi possível testar o comando
anterior devido não ter sido utilizado pelo programa cliente mb-gdb em todos os testes efectuados.
Quanto aos comandos de implementação obrigatória foram todos validados com êxito através dos
testes efectuados.
À que salientar a seguinte situação, existem dois comandos de implementação obrigatória que o
programa cliente mb-gdb em operação substitui por outros comandos de implementação opcional,
ver Tabela 32. Esta situação deve-se ao facto de o programa cliente mb-gdb dar prioridade ao uso de
comandos mais eficientes, apesar de se atingir os mesmos objectivos com ambos os comandos, os
opcionais pelos quais os obrigatórios são substituídos são mais eficientes em termos de
comunicação, necessitam de menos largura de banda para efectuar a mesma transmissão de dados.
O programa cliente mb-gdb só utiliza os comandos de implementação obrigatória substituídos se os
comandos opcionais não se encontrarem implementados no servidor GDB, algo que não acontece no
modo depurador/servidor GDB. Com o intuito de testar os dois comandos de implementação
obrigatória utilizou-se uma versão do simulador em que os dois comandos opcionais em causa não
foram implementados.
Tabela 32. Comandos de implementação obrigatória substituídos
COMANDOS OBRIGATÓRIOS COMANDOS OPCIONAIS
GXX...
(modifica os registos para XX...)
Pn...=r...
(modifica o registo n... para r...)
Maddr,length:XX...
(modifica length bytes da memória a partir
do endereço addr com os dados XX...)
Xaddr,length:XX...
(modifica length bytes da memória a partir do endereço
addr com os dados binários XX... codificado no sistema
de oito bit)
As versões dos programas de teste sem a informação de depuração apesar de terem funcionado
correctamente só permitiram o acompanhamento da execução através do código assembly.
Enquanto as versões dos programas de teste com a informação de depuração permitiram o
acompanhamento da execução tanto através do código assembly com através do código fonte
escrito em linguagem C. Como se pode constatar pelos tamanhos dos executáveis de ambas as
versões dos programas de teste a adição da informação de depuração num programa não vai
provocar a inserção qualquer código, sendo assim a adição da informação de depuração não vai
influenciar o correcto funcionamento dos mesmos.
53
O comportamento do simulador em modo depurador/servidor GDB ao executar o programa de
teste Interrupções foi o esperado. Foi inserido um breakpoint na linha if(minute == 60) da
função void timer_counter() do ficheiro clock.c, com o objectivo de parar a execução do
programa após se ter atingido a contagem do primeiro minuto. Ao atingir o breakpoint o simulador
suspendeu a execução do programa, parando não só o processador como os periféricos que fazem
parte do sistema. A pausa da execução dos periféricos que compõem o sistema pode ser constada
pela paragem de geração de interrupções por parte do periférico OPB Timer/Counter.
54
55
6 Conclusões e Trabalho Futuro
6.1 Conclusões
O trabalho desenvolvido no âmbito desta tese consistiu no melhoramento de um simulador de
ciclo exacto para sistemas baseados na arquitectura FireWorks.
Foi apresentado um estudo sobre as vantagens da utilização de simuladores, analisando-se os
simuladores actualmente utilizados, de modo a propor um simulador com uma arquitectura flexível,
possibilitando a configuração das funcionalidades desejadas.
A arquitectura concebida possibilita a utilização de módulos de processadores e periféricos
posteriormente desenvolvidos, e efectua a modelação total do sistema. A simulação é realizada ao
nível da instrução, sendo de ciclo exacto, o que permite a obtenção de resultados de desempenho. O
software é carregado no formato Executable and Linking Format (ELF), e o sistema pode ser
configurado usando ficheiros Extensible Markup Language (XML). O código fonte é aberto e permite
futuras modificações.
O simulador do processador MicroBlaze de ciclo exacto Instruction Set Simulator (ISS) contém as
seguintes limitações:
Não pode aceder a periféricos;
O software só pode residir na memória interna do sistema;
A dimensão do software define o tamanho máximo da memória a que o simulador pode
aceder;
Só é possível a utilização através da ferramenta Xilinx Microprocessor Debugger (XMD);
O seu código fonte é fechado.
As melhorias efectuadas ao simulador permitem a operação como analisador de desempenho e
como depurador/servidor GNU Debugger (GDB) de uma forma não intrusiva, e possibilitando a
obtenção de valores exactos na análise de resultados, sem os problemas normalmente observados
em outros métodos.
Na análise de desempenho a ferramenta actualmente utilizada, o gprof, adiciona código ao
software a analisar, podendo assim originar efeitos colaterais, e efectua análise por amostragem, não
obtendo desta forma resultados precisos. Na depuração a ferramenta actualmente utilizada, o XMD,
adiciona ao software a depurar uma porção de código com o nome de stub com o intuito de controlar
a execução do software e efectuar a comunicação com o programa cliente mb-gdb, o que também
pode originar efeitos colaterais na execução do software.
Os resultados obtidos nos testes realizados num sistema real e no simulador, através da
execução de benchmarks adaptados para o efeito, permitiram aferir e demonstrar as funcionalidades
do simulador concebido. O trabalho atingiu todos os objectivos a que se propunha e pode ser
aperfeiçoado para integrar o pacote de ferramentas de desenvolvimento de sistemas baseados no
processador FireWorks.
56
6.2 Trabalho Futuro
Apesar de terem sido atingidos os objectivos do trabalho, várias funcionalidades podem ser
melhoradas e muitas outras adicionadas.
No que respeita ao modo simulação, vários melhoramentos podem ser implementados mas
seleccionámos três pela sua importância face às necessidades observadas na Coreworks:
O motor de simulação pode ser melhorado para suportar sistemas com múltiplos
processadores, a operar em diferentes frequências;
O funcionamento com ficheiros de estímulos, simulando assim a interacção com o mundo
exterior;
A monitorização da stack do software simulado para depuração de problemas associados
a violações da dimensão da stack.
O modo de análise de desempenho poderia ser melhorado para suportar a análise parcial de
programas em vez da análise global ora implementada, o que permitia focar numa dada zona
problemática do problema. A extensão deste modo a sistemas com múltiplos processadores seria
também bastante útil.
O modo depurador/servidor GDB poderia ser melhorado de forma a ser possível o acesso e a
visualização de registos de periféricos. O suporte de sistemas com múltiplos processadores é
também útil neste modo.
Numa perspectiva de facilitar a sua utilização, podia pensar-se em integrar o simulador
desenvolvido no ambiente integrado de desenvolvimento Eclipse [23]. À semelhança de outros
ambientes de desenvolvimento, seria assim possível efectuar todo o processo de desenvolvimento
de software embebido a partir de um único programa: desenvolvimento do código fonte, compilação,
configuração do simulador para o sistema pretendido, controlo do simulador, depuração, análise de
desempenho e visualização dos relatórios da informação gerada.
Podia também adaptar-se o simulador ao ambiente de simulação dinâmica Simulink [24],
permitindo assim a simulação de software embebido em interacção com sistemas dinâmicos.
57
Referências
[1] BCC Inc, “Future of Embedded Systems Technology,” Abril 2009.
[2] Coreworks, “Coreworks,” Coreworks, 6 Junho 2013. [Online]. Available: http://www.coreworks-sa.com. [Acedido em 6 Junho 2013].
[3] Coreworks, “Fireworks,” Coreworks, 6 Junho 2013. [Online]. Available: http://www.coreworks-sa.com/index.php?view=fireworks_tech. [Acedido em 6 Junho 2013].
[4] Coreworks, “SideWorks,” Coreworks, 6 Junho 2013. [Online]. Available: http://www.coreworks-sa.com/index.php?view=computing_text. [Acedido em 6 Junho 2013].
[5] S. Craven, “OpenFire Processor Core,” 10 Março 2009. [Online]. Available: http://opencores.org/project,openfire_core. [Acedido em 7 Fevereiro 2011].
[6] Xilinx, MicroBlaze Processor Reference Guide, Embedded Development Kit EDK 9.1i, Xilinx, 2007.
[7] Xilinx, MicroBlaze™ RISC 32-Bit Soft Processor, Xilinx, 21 de Agosto de 2002.
[8] Xilinx, MicroBlaze™ Software Reference Guide, Xilinx, Abril 2002.
[9] D. A. Patterson e J. L. Hennessy, Computer Organization and Design, The Hardware/Software Interface (4th ed.), Morgan Kaufmann, 2009, pp. 335-343.
[10] Xilinx, MicroBlaze Processor Reference Guide, Embedded Development Kit EDK 9.1i, Xilinx, 2007, pp. 73-153.
[11] Xilinx, 6 Junho 2013. [Online]. Available: http://www.xilinx.com. [Acedido em 6 Junho 2013].
[12] GNU, “GNU toolchain,” 6 Junho 2013. [Online]. Available: http://en.wikipedia.org/wiki/GNU_toolchain. [Acedido em 6 Junho 2013].
[13] Richard M. Stallman and the GCC Developer Community, Using the GNU Compiler Collection (GCC), for GCC 3.4.6, Free Software Foundation, 23 de Maio de 2004.
[14] Richard Stallman, Roland Pesch, Stan Shebs, et al., Debugging with gdb, The gnu Source-Level Debugger, Ninth Edition, for gdb version 6.7.50.20071027, Free Software Foundation, 2004.
[15] Daniel Mattsson and Marcus Christensson, Evaluation of synthesizable CPU cores, Master's Thesis, Chalmers University of Technology, 2004.
[16] Xilinx, OPB Timer/Counter (v1.00b) DS465, Xilinx, 2 de Dezembro de 2005.
[17] Xilinx, OPB UART Lite (v1.00b) DS422, Xilinx, 2 de Dezembro de 2005.
[18] Jay Fenlason and Richard Stallman, GNU gprof, The gnu Profiler, Version 2.18.50, Free Software Foundation, 2003.
[19] TIS Committee, Tool Interface Standard (TIS), Executable and Linking Format (ELF) Specification, Version 1.2, TIS Committee, Maio 1995.
[20] UNIX International, Inc., DWARF Debugging Information Format, Revision: 2.0.0, UNIX International, Inc., 27 de Julho de1993.
[21] Digilent, “Digilent Inc. - Digital Design Engineer's Source,” 6 Junho 2013. [Online]. Available: http://www.digilentinc.com. [Acedido em 6 Junho 2013].
[22] Hilgraeve, “HyperTerminal Windows 7 Terminal Emulation Program,” 6 Junho 2013. [Online]. Available: http://www.hilgraeve.com/hyperterminal/. [Acedido em 6 Junho 2013].
[23] Eclipse Foundation, “Eclipse.org home,” 6 Junho 2013. [Online]. Available: http://www.eclipse.org. [Acedido em 6 Junho 2013].
[24] MathWorks, “Simulink - Simulation and Model-Based Design,” 6 Junho 2013. [Online]. Available: http://www.mathworks.com/products/simulink. [Acedido em 6 Junho 2013].
[25] Dropbox, Inc., “Dropbox,” 11 Abril 2014. [Online]. Available: https://www.dropbox.com/. [Acedido em 11 Abril 2014].
[26] Oracle, “For Java Developers,” Oracle, 6 Junho 2013. [Online]. Available: http://www.oracle.com/technetwork/java/index.html. [Acedido em 6 Junho 2013].
58
59
Apêndices
60
61
A. Estrutura do CD
No âmbito desta tese é fornecido um Compact Disc (CD) com o simulador e toda a documentação
requerida. O simulador é disponibilizado em duas versões, uma para sistema operativo Microsoft
Windows e outra para o sistema operativo GNU/Linux. É fornecido o código fonte do simulador e dos
programas de teste, o diagrama de classes UML e o Javadoc do simulador.
Na Figura 18 mostra-se a estrutura do CD, a estrutura é auto-explicativa.
raiz
[Simulador]
[Código Fonte]
dtool codigo fonte 1.0.0.1.zip
programas de teste codigo fonte.zip
dissertação.pdf
identificação.pdf
resumo.pdf
[Instalação]
[Javadoc]
[UML]
dtool-1.0.0.1-1.i686.rpm
dtool-1.0.0.1-Setup.exe
dtool javadoc 1.0.0.1.zip
diagrama de classes uml rev.1.pdf
Figura 18. Estrutura do CD
Caso o utilizador não tenha acesso ao CD disponibilizado no âmbito desta tese, pode aceder ao
seu conteúdo através do serviço de armazenamento e partilha de arquivos Dropbox [25], o pedido de
partilha do conteúdo deve ser efectuado através do seguinte endereço electrónico
62
B. Guia de Instalação e Remoção do Simulador
B.1 Modo de disponibilização do simulador
O simulador de sistemas baseados no processador FireWorks concebido no âmbito desta tese é
disponibilizado em conjunto com o pacote de ferramentas de desenvolvimento MicroBlaze GNU
Toolchain, juntamente com o código fonte e executáveis dos programas de teste. Deste modo, todos
os meios utilizados durante os testes experimentais para validação e demostração das
funcionalidades do simulador são facultados ao utilizador. Todo este pacote de ferramentas e
utilitários são fornecidos por um programa de instalação desenvolvido para o efeito.
Com este conjunto de ferramentas é possível efectuar as etapas de concepção, simulação e
depuração de software para sistemas embebidos baseados no microprocessador FireWorks.
B.2 Sistemas operativos suportados
O pacote de ferramentas de desenvolvimento MicroBlaze GNU Toolchain e o simulador
desenvolvido suportam os seguintes sistemas operativos Windows da Microsoft:
Microsoft Windows XP (32 bit/64 bit)
Microsoft Windows Vista (32 bit/64 bit)
Microsoft Windows 7 (32 bit/64 bit)
As distribuições do sistema operativo GNU/Linux suportadas são as seguintes:
Red Hat Enterprise Linux (32 bit/64 bit)
Fedora (32 bit/64 bit)
B.3 Pré-requisitos
O simulador requer a instalação de uma máquina virtual Java no sistema operativo onde vai
operar. São suportadas os seguintes pacotes:
Java SE Development Kit 6 (JDK)
Java SE Runtime Enviroment 6 (JRE)
Se o sistema operativo não tiver instalada uma das versões de Java referidas, o utilizador poderá
obter uma através do sítio da internet da Oracle [26] e proceder à sua instalação.
63
B.4 Sistemas operativos Microsoft Windows
O conjunto de ferramentas é fornecido através de um programa de instalação com o nome
dtool-1.0.0.1-Setup.exe, o qual deve ser executado para se proceder à instalação. No caso
de ter acesso ao suporte informático fornecido no âmbito desta tese o programa de instalação pode
ser encontrado na directoria /Simulador/Instalação.
No início da instalação aparecer a janela da Figura 19, onde é dada ao utilizador a opção de
seleccionar as ferramentas e utilitários a instalar. Por defeito, todas as ferramentas e utilitários estão
inicialmente seleccionados para instalação, esta deve ser a opção a tomar pelo utilizador caso
pretenda efectuar os testes do simulador no âmbito da tese.
Figura 19. Janela de selecção das ferramentas e utilidades a instalar
A próxima janela da Figura 20 dá ao utilizador a opção de escolher a directoria onde pretende
instalar o conjunto de ferramentas. Ter em atenção à directoria que se escolhe, pois as ferramentas
mb-gdb e mb-uclinux-gdb incluídas no pacote de ferramentas MicroBlaze GNU Toolchain só
funcionam correctamente em directorias cujo caminho total contenha caracteres visíveis do código
American Standard Code for Information Interchange (ASCII), não estendido, e não inclua o caracter
espaço.
Figura 20. Janela de escolha da directoria de instalação
64
Na janela de finalização da instalação na Figura 21 existe a opção de visualizar o ficheiro Readme.
É aconselhável a sua visualização, visto conter informação quanto ao funcionamento e
características da ferramenta de simulação e depuração.
Figura 21. Janela de finalização da instalação
B.5 Sistemas operativos GNU/Linux
Neste sistema operativo o pacote de instalação do simulador efectua a instalação de todo o
conjunto das ferramentas e utilitários por defeito, não dando opções de selecção de componentes ao
utilizador.
Num terminal, coloque-se na directoria onde se encontra o programa de instalação do conjunto de
ferramentas. No caso de ter acesso ao suporte informático fornecido no âmbito desta tese o
programa de instalação encontra-se na directoria /Simulador/Instalação. E execute o seguinte
comando:
$ rpm –i dtool-1.0.0.1-1.i686.rpm
Caso exista uma versão anterior instalada o comando a usar é o seguinte:
$ rpm –Uvh dtool-1.0.0.1-1.i686.rpm
Após finalização da instalação as ferramentas podem ser encontradas na directoria /opt/dtool, e
estão prontas para utilização.
Para se proceder à remoção do conjunto das ferramentas e utilitários execute o comando:
$ rpm –e dtool-1.0.0.1-1
B.6 Testes ao simulador no âmbito da tese
Todo o material relacionado com os testes ao simulador é instalado na directoria de instalação
das ferramentas e utilitários. Na subdirectoria test_programs_source_code encontra-se o código
fonte e na subdirectoria test_programs_executable encontra-se os executáveis.
65
C. Guia de Utilização do Simulador
C.1 Modos de Operação
O simulador é disponibilizado através de um programa que funciona em modo terminal. É
constituído por quatro modos de operação indicados na lista seguinte, entre parênteses rectos
encontra-se o parâmetro a utilizar para a selecção do respectivo modo de operação:
Modo de simulador [sim]: neste modo é efectuada a simulação do software. No final é
reportado o número total de instruções e de ciclos realizados.
Modo de análise de desempenho [prf]: neste modo é efectuada a simulação do software
com análise de desempenho. Os resultados são disponibilizados através de um ficheiro
criado para o efeito.
Modo de depurador/servidor GDB [gdb]: através deste modo é efectuada a simulação
com depuração do software. Este modo opera em ligação com a ferramenta mb-gdb
através do protocolo GDB RSP sobre o protocolo TCP/IP.
Modo de traçador de percurso [trc]: através desde modo é efectuada a simulação do
software, sendo reportado para um ficheiro o percurso traçado pelas instruções.
Tendo em mente o desenvolvimento e depuração do próprio simulador foram desenvolvidos três
modos de operação auxiliares, indicados na lista seguinte. Entre parênteses rectos, o parâmetro a
utilizar para a selecção do respectivo modo de operação:
Modo de teste [tst]: através deste modo pode-se efectuar a simulação podendo-se ter
acesso a todos os registos internos do processador, visualizar as instruções que se
encontram nos vários andares de pipeline do processador bem como ao conteúdo da
memória e dos registos dos periféricos. A simulação pode ser controlada instrução a
instrução, ciclo a ciclo, por número de ciclos, por número de instruções e executada até a
finalização normal do software.
Modo de configuração [cfg]: neste modo pode-se efectuar a validação do ficheiro de
configuração XML do sistema a simular.
Modo de ficheiro executável ELF [elf]: neste modo pode-se visualizar a informação
contida neste ficheiro, tais como as funções que fazem parte do software e as posições
de memória que ocupam, o tamanho total e das várias secções do código executável do
ficheiro, bem como verificar a existência da função exit utilizada para a finalização da
execução da simulação.
66
C.2 Manual de Utilização
O simulador é evocado no terminal através do comando dtool. Para aceder ao manual utilização
do simulador basta executar o seguinte comando:
$ dtool –-help
Na Figura 22 visualiza-se o manual de operação do simulador obtido através da execução do
comando, com os parâmetros e opções a utilizar nos diferentes modos de operação.
Development Tool 1.0.0.1 (dtool) [09/04/2014]
by Joao Ferreira (email: [email protected])
Test mode:
usage: dtool -tst [OPTION]... <binary_file>
[OPTION]...
--syscf <systemconfig_file> ,XML file with the system configuration
--prff <profile_file> ,output file with the simulation profile
--trcf <trace_file> ,output file with the simulation trace
--eventv ,verbose the exceptions and interruptions
<binary_file> ,ELF binary file for FireWorks CPU
Simulator mode:
usage: dtool -sim [OPTION]... <binary_file>
[OPTION]...
--syscf <systemconfig_file> ,XML file with the system configuration
--eventv ,verbose the exceptions and interruptions
<binary_file> ,ELF binary file for FireWorks CPU
GDB Server mode:
usage: dtool -gdb [OPTION]...
[OPTION]...
--syscf <systemconfig_file> ,XML file with the system configuration
--portc <port_number> ,port number for the TCP/IP protocol
--prtclv ,verbose the GDB remote serial protocol
--eventv ,verbose the exceptions and interruptions
Profile mode:
usage: dtool -prf [OPTION]... <binary_file>
[OPTION]...
--syscf <systemconfig_file> ,XML file with the system configuration
--prff <profile_file> ,output file with the simulation profile
Trace mode:
usage: dtool -trc [OPTION]... <binary_file>
[OPTION]...
--syscf <systemconfig_file> ,XML file with the system configuration
--trcf <trace_file > ,output file with the simulation trace
ELF binary file mode:
usage: dtool -elf <binary_file>
<binary_file> ,ELF binary file for the system cpu
System configuration file mode:
usage: dtool -cfg [OPTION]... <systemconfig_file>
or: dtool -cfg [OPTION]...
[OPTION]...
67
--sysv ,show system configuration
--cpuv ,show cpu configuration
--devv ,show OPB Devices configuration
<systemconfig_file> ,XML file with the system configuration
Others options:
--version ,output version information and defaults
--help ,display this help
Figura 22. Manual de operação do simulador
Com o parâmetro -–version é disponibilizada a localização das directorias onde se encontra
instalado o simulador, os módulos dos processadores e os periféricos bem como dos ficheiros de
configuração. É indicado o ficheiro de configuração XML do sistema utilizado nos testes
experimentais e na demonstração de funcionalidades do simulador. Também são disponibilizados os
nomes por defeitos dos ficheiros gerados pelo modo de análise de desempenho e pelo modo de
traçador de percurso, bem como do número por defeito da porta do protocolo TCP/IP utilizado pelo
modo de depurador/servido GDB. Exemplificação do comando:
$ dtool –version
Na Figura 23 visualiza-se a informação sobre a versão, configuração e valores dos parâmetros
por defeito do simulador.
Development Tool 1.0.0.1 (dtool) [09/04/2014]
by Joao Ferreira (email: [email protected])
Instalation folders:
Program : C:\dtool\dtool\
Configuration : C:\dtool\dtool\configuration_files
OPB Devices : C:\dtool\dtool\opbdevices
Processors : C:\dtool\dtool\processors
Default files:
<systemconfig_file> : systemconfig.xml
<profile_file> : profile.txt
<trace_file> : trace.txt
<systemconfig_file> file path:
Folder : C:\dtool\dtool\configuration_files
Default values:
<port_number> : 1234
Figura 23. Informação sobre a versão e configuração por defeito
C.3 Ligação com a Ferramenta mb-gdb
O primeiro passo para efectuar a ligação entre o simulador e a ferramenta mb-gdb é correr o
simulador em modo depurador/servidor GDB. O utilizador tem a opção de configurar o número da
porta TCP/IP e de iniciar o ficheiro de configuração do sistema. Neste exemplo utilizam-se os valores
por defeito. Abrir um terminal e executar o seguinte comando:
68
$ dtool –gdb
Development Tool 1.0.0.1 (dtool) [09/04/2014]
by Joao Ferreira (email: [email protected])
GDB Server mode:
System
. File: C:\dtool\dtool\configuration_files\systemconfig.xml
Memory Latency
. LMB, Read: 2 Write: 2
. OPB, Read: 2 Write: 1
. Mapped: 16
Memory Range
. LMB, Begin: 0x00000000 End: 0x0000ffff
. OPB, Begin: 0x80200000 End: 0x8020ffff
Memory Size
. LMB, Size: 65536bytes Size: 64.0kbytes
. OPB, Size: 65536bytes Size: 64.0kbytes
Devices
. Device: OPB Timer Counter Number: 0
- Read latency: 8 Write latency: 4
- Register: TCSR0 Address: 0x80004000
- Register: TLR0 Address: 0x80004004
- Register: TCR0 Address: 0x80004008
- Register: TCSR1 Address: 0x80004010
- Register: TLR1 Address: 0x80004014
- Register: TCR1 Address: 0x80004018
. Device: OPB UART Lite Number: 1
- Read latency: 8 Write latency: 4
- Register: RX Address: 0x80004100
- Register: TX Address: 0x80004104
- Register: STATUS Address: 0x80004108
- Register: CONTROL Address: 0x80004110
CPU
. Name : FireWorks three stage pipeline
. Pipeline stages: 3
. GCC id : 0xbaab
. Frequency : 50.0MHz
--------------------------------------------------------------------------------
Waiting for connections...
. hostname: Windows
. ip: 10.0.2.15
. port: 1234
Figura 24. Inicialização do simulador em modo depurador/servidor GDB
No segundo passo efectua-se a execução da ferramenta mb-gdb. Existem duas formas de o
fazer. A primeira é executar a ferramenta num terminal, correndo o seguinte comando:
$ mb-gdb
A segunda forma é em modo janela, sendo esta forma a utilizada no resto explicação. No sistema
operativo Microsoft Windows executar a ferramenta através do botão Início, escolhendo Início >
Development Tool > mb-gdb. No sistema operativo GNU/Linux executar a ferramenta através do
menu de aplicações, escolhendo Application Menu > Programming > mb-gdb. No ecrã irá
aparecer a janela da Figura 25.
69
Figura 25. Ferramenta mb-gdb em modo janela
No terceiro passo configurar-se a ferramenta mb-gdb para que a ligação com o simulador possa
ser efectuada. Para tal no menu File seleccione a opção Target Selection. Irá aparecer a
janela da Figura 26 na qual deve ser introduzida a seguinte configuração:
Target: Remote/TCP : XMD/gdbserver
Hostname: localhost
Port: 1234
Figura 26. Janela Target Selection
De salientar que o número da porta a usar tem de ser o mesmo em ambos tanto no simulador
como na ferramenta mb-gdb; nesta demostração foi usado o número da porta por defeito 1234.
70
O último passo a efectuar é carregamento do software a depurar e proceder à sua execução. No
menu File do mb-gdb seleccione Open… e escolha o executável ELF depurar. Na Figura 27 é
exibida a ferramenta mb-gdb com um executável ELF carregado.
Figura 27. Ferramenta mb-gdb com um executável ELF carregado
De seguida executar o programa seleccionando Run no menu Run. Relembrar que, para obter
todas as potencialidades da ferramenta mb-gdb, deve colocar a opção –g no acto da compilação do
software.
71
D. Formato dos Ficheiros de Configuração do Sistema
Os sistemas a simular são configurados através de ficheiros do tipo XML Pode-se configurar o
tipo de processador e a latência das suas instruções, o número e tipo de periféricos, o mapeamento
e latência dos registos dos periféricos. Pode-se também configurar, o tipo, mapeamento e latência
das memórias e a frequência de operação do sistema. O ficheiro de configuração XML é definido e
validado através do ficheiro systemconfig.dtd do tipo DTD da Figura 28.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT SYSTEMCONFIGURATION (DESCRIPTION,MEMORY,DEVICE*,CPU)>
<!ELEMENT DESCRIPTION (NAME,VERSION,AUTHOR,COMPANY,DATE,OBS)>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT VERSION (#PCDATA)>
<!ELEMENT AUTHOR (#PCDATA)>
<!ELEMENT COMPANY (#PCDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT OBS (#PCDATA)>
<!ELEMENT MEMORY (LMB,OPB?,MAPPED)>
<!ELEMENT LMB EMPTY>
<!ELEMENT OPB EMPTY>
<!ELEMENT MAPPED EMPTY>
<!ATTLIST LMB read CDATA "1" write CDATA "1" end CDATA #REQUIRED>
<!ATTLIST OPB read CDATA "1" write CDATA "1" begin CDATA #REQUIRED end CDATA #REQUIRED>
<!ATTLIST MAPPED cycle CDATA "1">
<!ELEMENT DEVICE (DEVCLASS,LATENCY,REG*)>
<!ELEMENT DEVCLASS (#PCDATA)>
<!ELEMENT LATENCY EMPTY>
<!ELEMENT REG EMPTY>
<!ATTLIST LATENCY read CDATA "1" write CDATA "1">
<!ATTLIST REG name CDATA #REQUIRED address CDATA #REQUIRED>
<!ELEMENT CPU (CPUCLASS,FREQ?,INST*)>
<!ELEMENT CPUCLASS (#PCDATA)>
<!ELEMENT FREQ (#PCDATA)>
<!ELEMENT INST EMPTY>
<!ATTLIST INST name CDATA #REQUIRED latency CDATA "1" cond_latency CDATA "0">
Figura 28. systemconfig.dtd, ficheiro utilizado na definição e validação do sistema
Na Figura 29 mostra-se o ficheiro de configuração do sistema usado nos testes experimentais e
na demonstração das funcionalidades do simulador.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE SYSTEMCONFIGURATION SYSTEM "systemconfig.dtd">
<SYSTEMCONFIGURATION>
<DESCRIPTION>
<NAME>FireWorks System</NAME>
<VERSION>1.0</VERSION>
<AUTHOR>João Ferreira</AUTHOR>
<COMPANY>Alentejo, S.A.</COMPANY>
72
<DATE>24/04/2008</DATE>
<OBS>Test system</OBS>
</DESCRIPTION>
<MEMORY>
<LMB read="2" write="2" end="0000ffff"/>
<OPB read="2" write="1" begin="80200000" end="8020ffff"/>
<MAPPED cycle="16"/>
</MEMORY>
<DEVICE>
<DEVCLASS>OPBTimerCounter</DEVCLASS>
<LATENCY read="8" write="4"/>
<REG name="TCSR0" address="80004000"/>
<REG name="TLR0" address="80004004"/>
<REG name="TCR0" address="80004008"/>
<REG name="TCSR1" address="80004010"/>
<REG name="TLR1" address="80004014"/>
<REG name="TCR1" address="80004018"/>
</DEVICE>
<DEVICE>
<DEVCLASS>OPBUARTLite</DEVCLASS>
<LATENCY read="8" write="4"/>
<REG name="RX" address="80004100"/>
<REG name="TX" address="80004104"/>
<REG name="STATUS" address="80004108"/>
<REG name="CONTROL" address="80004110"/>
</DEVICE>
<CPU>
<CPUCLASS>FW_3SP</CPUCLASS>
<FREQ>50000000</FREQ>
<INST name="add"/>
<INST name="addc"/>
<INST name="addi"/>
<INST name="addic"/>
<INST name="addik"/>
<INST name="addikc"/>
<INST name="addk"/>
<INST name="addkc"/>
<INST name="and"/>
<INST name="andi"/>
<INST name="andn"/>
<INST name="andni"/>
<INST name="beq"cond_latency="1"/>
<INST name="beqd"cond_latency="1"/>
<INST name="beqi"cond_latency="1"/>
<INST name="beqid"cond_latency="1"/>
<INST name="bge"cond_latency="1"/>
<INST name="bged"cond_latency="1"/>
<INST name="bgei"cond_latency="1"/>
<INST name="bgeid"cond_latency="1"/>
<INST name="bgt"cond_latency="1"/>
<INST name="bgtd"cond_latency="1"/>
<INST name="bgti"cond_latency="1"/>
<INST name="bgtid"cond_latency="1"/>
<INST name="ble"cond_latency="1"/>
<INST name="bled"cond_latency="1"/>
<INST name="blei"cond_latency="1"/>
<INST name="bleid"cond_latency="1"/>
<INST name="blt"cond_latency="1"/>
<INST name="bltd"cond_latency="1"/>
<INST name="blti"cond_latency="1"/>
<INST name="bltid"cond_latency="1"/>
<INST name="bne"cond_latency="1"/>
<INST name="bned"cond_latency="1"/>
<INST name="bnei"cond_latency="1"/>
<INST name="bneid"cond_latency="1"/>
<INST name="br"/>
<INST name="bra"/>
<INST name="brad"/>
<INST name="brai"/>
<INST name="braid"/>
<INST name="brald"/>
<INST name="bralid"/>
<INST name="brd"/>
<INST name="bri"/>
<INST name="brid"/>
<INST name="brk"latency="3"/>
<INST name="brki"latency="3"/>
73
<INST name="brld"/>
<INST name="brlid"/>
<INST name="bsll"latency="2"/>
<INST name="bslli"latency="2"/>
<INST name="bsra"latency="2"/>
<INST name="bsrai"latency="2"/>
<INST name="bsrl"latency="2"/>
<INST name="bsrli"latency="2"/>
<INST name="cget"latency="2"/>
<INST name="cmp"/>
<INST name="cmpu"/>
<INST name="cput"latency="2"/>
<INST name="fadd"latency="6"/>
<INST name="fcmpeq"latency="3"/>
<INST name="fcmpge"latency="3"/>
<INST name="fcmpgt"latency="3"/>
<INST name="fcmple"latency="3"/>
<INST name="fcmplt"latency="3"/>
<INST name="fcmpne"latency="3"/>
<INST name="fcmpun"latency="3"/>
<INST name="fdiv"latency="30"/>
<INST name="fmul"latency="6"/>
<INST name="frsub"latency="6"/>
<INST name="get"latency="2"/>
<INST name="idiv"latency="34"/>
<INST name="idivu"latency="34"/>
<INST name="imm"/>
<INST name="lbu"/>
<INST name="lbui"/>
<INST name="lhu"/>
<INST name="lhui"/>
<INST name="lw"/>
<INST name="lwi"/>
<INST name="mfs"/>
<INST name="msrclr"/>
<INST name="msrset"/>
<INST name="mts"/>
<INST name="mul"latency="3"/>
<INST name="mulh"latency="3"/>
<INST name="mulhu"latency="3"/>
<INST name="muli"latency="3"/>
<INST name="ncget"latency="2"/>
<INST name="ncput"latency="2"/>
<INST name="nget"latency="2"/>
<INST name="nput"latency="2"/>
<INST name="or"/>
<INST name="ori"/>
<INST name="pcmpbf"/>
<INST name="pcmpeq"/>
<INST name="pcmpne"/>
<INST name="put"latency="2"/>
<INST name="rsub"/>
<INST name="rsubc"/>
<INST name="rsubi"/>
<INST name="rsubic"/>
<INST name="rsubik"/>
<INST name="rsubikc"/>
<INST name="rsubk"/>
<INST name="rsubkc"/>
<INST name="rtbd"/>
<INST name="rted"/>
<INST name="rtid"/>
<INST name="rtsd"/>
<INST name="sb"latency="1"/>
<INST name="sbi"latency="1"/>
<INST name="sext16"/>
<INST name="sext8"/>
<INST name="sh"latency="1"/>
<INST name="shi"latency="1"/>
<INST name="sra"/>
<INST name="src"/>
<INST name="srl"/>
<INST name="sw"latency="1"/>
74
<INST name="swi"latency="1"/>
<INST name="wdc"/>
<INST name="wic"/>
<INST name="xor"/>
<INST name="xori"/>
</CPU>
</SYSTEMCONFIGURATION>
Figura 29. systemconfig.xml ficheiro de configuração do sistema usado nos testes experimentais
75
E. Formato dos Ficheiros de Configuração dos Módulos
Os módulos dividem-se em dois grupos periféricos e processadores, ambos são configurados
através de ficheiros do tipo XML. Cada módulo tem o seu próprio ficheiro de configuração. O ficheiro
situa-se na directoria do respectivo módulo.
No caso dos módulos dos periféricos o ficheiro de configuração permite definir os registos que
fazem parte do dispositivo. O ficheiro de configuração XML é validado e definido através do ficheiro
deviceconfig.dtd to tipo DTD da Figura 30.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT DEVICECONFIGURATION (DESCRIPTION,DEVCLASS,REG*)>
<!ELEMENT DESCRIPTION (NAME,VERSION,AUTHOR,COMPANY,DATE,OBS)>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT VERSION (#PCDATA)>
<!ELEMENT AUTHOR (#PCDATA)>
<!ELEMENT COMPANY (#PCDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT OBS (#PCDATA)>
<!ELEMENT DEVCLASS EMPTY>
<!ELEMENT REG (#PCDATA)>
<!ATTLIST DEVCLASS name CDATA #REQUIRED number CDATA #REQUIRED> Figura 30. deviceconfig.dtd, ficheiro de definição e validação dos módulos dos periféricos
Na Figura 31 mostra-se o ficheiro de configuração do módulo do periférico OPB UART Lite [17],
usado nos testes experimentais e na demostração das funcionalidades do simulador.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE DEVICECONFIGURATION SYSTEM "deviceconfig.dtd">
<DEVICECONFIGURATION>
<DESCRIPTION>
<NAME>OPB UART Lite</NAME>
<VERSION>1.00b</VERSION>
<AUTHOR>João Ferreira</AUTHOR>
<COMPANY>Alentejo, S.A.</COMPANY>
<DATE>24/04/2008</DATE>
<OBS>Test System</OBS>
</DESCRIPTION>
<DEVCLASS name="opbuartlite" number="4"/>
<REG>control</REG>
<REG>status</REG>
<REG>rx</REG>
<REG>tx</REG>
</DEVICECONFIGURATION> Figura 31. opbuartlite.xml, ficheiro de configuração do módulo OPB UART Lite
76
Na Figura 32 mostra-se o ficheiro de configuração do módulo do periférico OPB Timer/Counter
[16], usado nos testes experimentais e na demostração das funcionalidades do simulador.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE DEVICECONFIGURATION SYSTEM "deviceconfig.dtd">
<DEVICECONFIGURATION>
<DESCRIPTION>
<NAME>OPB Timer/Counter</NAME>
<VERSION>1.00b</VERSION>
<AUTHOR>João Ferreira</AUTHOR>
<COMPANY>Alentejo, S.A.</COMPANY>
<DATE>24/04/2008</DATE>
<OBS>Test system</OBS>
</DESCRIPTION>
<DEVCLASS name="opbtimercounter" number="6"/>
<REG>tcsr0</REG>
<REG>tcsr1</REG>
<REG>tlr0</REG>
<REG>tlr1</REG>
<REG>tcr0</REG>
<REG>tcr1</REG>
</DEVICECONFIGURATION>
Figura 32. opbtimercounter.xml, ficheiro de configuração do módulo OPB Timer/Counter
Nos módulos dos processadores o ficheiro de configuração permite definir as instruções que
fazem parte da ISA do processador, a latência das instruções, o número de andares de pipeline e o
código de identificação do processador com o qual é identificado pelo compilador. O ficheiro de
configuração XML é validado e definido através do ficheiro cpuconfig.dtd da Figura 33.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT CPUCONFIGURATION (DESCRIPTION,CPUCLASS,PIPELINE,INST*)>
<!ELEMENT DESCRIPTION (NAME,VERSION,AUTHOR,COMPANY,DATE,OBS)>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT VERSION (#PCDATA)>
<!ELEMENT AUTHOR (#PCDATA)>
<!ELEMENT COMPANY (#PCDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT OBS (#PCDATA)>
<!ELEMENT CPUCLASS EMPTY>
<!ELEMENT PIPELINE EMPTY>
<!ELEMENT INST EMPTY>
<!ATTLIST CPUCLASS name CDATA #REQUIRED gcc_id CDATA #REQUIRED number CDATA #REQUIRED>
<!ATTLIST PIPELINE stages CDATA #REQUIRED execute CDATA #REQUIRED>
<!ATTLIST INST name CDATA #REQUIRED cond (1|0) "0">
Figura 33. cpuconfig.dtd, ficheiro de definição e validação dos módulos dos processadores
77
Na Figura 34 mostra-se o ficheiro de configuração do módulo do processador FireWorks com três
andares de pipeline usado nos testes experimentais e na demostração das funcionalidades do
simulador.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE CPUCONFIGURATION SYSTEM "cpuonfig.dtd">
<CPUCONFIGURATION>
<DESCRIPTION>
<NAME>FireWorks Three Stage Pipeline</NAME>
<VERSION>6.0</VERSION>
<AUTHOR>João Ferreira</AUTHOR>
<COMPANY>Alentejo, S.A.</COMPANY>
<DATE>24/04/2008</DATE>
<OBS>Test cpu</OBS>
</DESCRIPTION>
<CPUCLASS name="fw_3sp" gcc_id="baab" number="126"/>
<PIPELINE stages="3" execute="3"/>
<INST name="add"/>
<INST name="addc"/>
<INST name="addi"/>
<INST name="addic"/>
<INST name="addik"/>
<INST name="addikc"/>
<INST name="addk"/>
<INST name="addkc"/>
<INST name="and"/>
<INST name="andi"/>
<INST name="andn"/>
<INST name="andni"/>
<INST name="beq"cond="1"/>
<INST name="beqd"cond="1"/>
<INST name="beqi"cond="1"/>
<INST name="beqid"cond="1"/>
<INST name="bge"cond="1"/>
<INST name="bged"cond="1"/>
<INST name="bgei"cond="1"/>
<INST name="bgeid"cond="1"/>
<INST name="bgt"cond="1"/>
<INST name="bgtd"cond="1"/>
<INST name="bgti"cond="1"/>
<INST name="bgtid"cond="1"/>
<INST name="ble"cond="1"/>
<INST name="bled"cond="1"/>
<INST name="blei"cond="1"/>
<INST name="bleid"cond="1"/>
<INST name="blt"cond="1"/>
<INST name="bltd"cond="1"/>
<INST name="blti"cond="1"/>
<INST name="bltid"cond="1"/>
<INST name="bne"cond="1"/>
<INST name="bned"cond="1"/>
<INST name="bnei"cond="1"/>
<INST name="bneid"cond="1"/>
<INST name="br"/>
<INST name="bra"/>
<INST name="brad"/>
<INST name="brai"/>
<INST name="braid"/>
<INST name="brald"/>
<INST name="bralid"/>
<INST name="brd"/>
<INST name="bri"/>
<INST name="brid"/>
<INST name="brk"/>
<INST name="brki"/>
<INST name="brld"/>
<INST name="brlid"/>
<INST name="bsll"/>
<INST name="bslli"/>
<INST name="bsra"/>
<INST name="bsrai"/>
<INST name="bsrl"/>
<INST name="bsrli"/>
78
<INST name="cget"/>
<INST name="cmp"/>
<INST name="cmpu"/>
<INST name="cput"/>
<INST name="fadd"/>
<INST name="fcmpeq"/>
<INST name="fcmpge"/>
<INST name="fcmpgt"/>
<INST name="fcmple"/>
<INST name="fcmplt"/>
<INST name="fcmpne"/>
<INST name="fcmpun"/>
<INST name="fdiv"/>
<INST name="fmul"/>
<INST name="frsub"/>
<INST name="get"/>
<INST name="idiv"/>
<INST name="idivu"/>
<INST name="imm"/>
<INST name="lbu"/>
<INST name="lbui"/>
<INST name="lhu"/>
<INST name="lhui"/>
<INST name="lw"/>
<INST name="lwi"/>
<INST name="mfs"/>
<INST name="msrclr"/>
<INST name="msrset"/>
<INST name="mts"/>
<INST name="mul"/>
<INST name="mulh"/>
<INST name="mulhu"/>
<INST name="muli"/>
<INST name="ncget"/>
<INST name="ncput"/>
<INST name="nget"/>
<INST name="nput"/>
<INST name="or"/>
<INST name="ori"/>
<INST name="pcmpbf"/>
<INST name="pcmpeq"/>
<INST name="pcmpne"/>
<INST name="put"/>
<INST name="rsub"/>
<INST name="rsubc"/>
<INST name="rsubi"/>
<INST name="rsubic"/>
<INST name="rsubik"/>
<INST name="rsubikc"/>
<INST name="rsubk"/>
<INST name="rsubkc"/>
<INST name="rtbd"/>
<INST name="rted"/>
<INST name="rtid"/>
<INST name="rtsd"/>
<INST name="sb"/>
<INST name="sbi"/>
<INST name="sext16"/>
<INST name="sext8"/>
<INST name="sh"/>
<INST name="shi"/>
<INST name="sra"/>
<INST name="src"/>
<INST name="srl"/>
<INST name="sw"/>
<INST name="swi"/>
<INST name="wdc"/>
<INST name="wic"/>
<INST name="xor"/>
<INST name="xori"/>
</CPUCONFIGURATION>
Figura 34. fw_3sp.xml, ficheiro de configuração do módulo do processador FireWorks
79
F. Relatório da Análise de Desempenho da Sequência de Fibonacci
Na Figura 35 encontra-se o ficheiro gerado com o resultado da análise de desempenho de um
programa que gera a sequência de Fibonacci. Este programa foi usado para efectuar os testes
experimentais e de funcionalidades do simulador. O programa foi executado com o valor do
argumento da sequência de Fibonacci igual a 11, este argumento representa o número de números
da sequência de Fibonacci a gerar. O formato do ficheiro é auto-explicativo.
System configuration file
C:\dtools\tools\configuration_files\systemconfig.xml
Binary file
fibonacci
Performance
instructions: 3556
cycles : 5347
cpi : 1.5036558
<frequency> : 50.0MHz
simulation : 0.022666685s
real : 1.0694E-4s
ratio : 210.95703
Flat profile
% cumulative self self
time cycles cycles calls cycles/call function
87,66 4687 4687 1 4687,00 fib
3,65 4882 195 1 195,00 cw_outnum
2,32 5006 124 1 124,00 cw_printf
1,23 5072 66 3 22,00 RS232_writeByte
1,01 5126 54 2 27,00 cw_padding
0,75 5166 40 1 40,00 _crtinit
0,62 5199 33 3 11,00 cw_outbyte
0,58 5230 31 1 31,00 strlen
0,41 5252 22 1 22,00 __do_global_dtors_aux
0,37 5272 20 1 20,00 __do_global_ctors_aux
0,32 5289 17 1 17,00 main
0,26 5303 14 1 14,00 __init
0,24 5316 13 1 13,00 frame_dummy
0,21 5327 11 1 11,00 __fini
0,13 5334 7 1 7,00 _start1
0,11 5340 6 1 6,00 _start
0,06 5343 3 1 3,00 _program_clean
0,06 5346 3 1 3,00 _program_init
0,02 5347 1 1 1,00 exit
0,00 5347 _vector_sw_exception
0,00 5347 _vector_interrupt
0,00 5347 _vector_hw_exception
0,00 5347 RS232_readByte
0,00 5347 cw_inbyte
0,00 5347 cw_getnum
0,00 5347 _exception_handler
0,00 5347 _hw_exception_handler
0,00 5347 _interrupt_handler
General profile
cycles instructions execute calls function
6 1 1 1 _start
0 0 0 0 _vector_sw_exception
0 0 0 0 _vector_interrupt
80
0 0 0 0 _vector_hw_exception
7 6 2 1 _start1
1 1 1 1 exit
22 13 1 1 __do_global_dtors_aux
13 7 1 1 frame_dummy
40 29 6 1 _crtinit
4687 3183 1 1 fib
17 12 3 1 main
0 0 0 0 RS232_readByte
66 30 3 3 RS232_writeByte
33 21 6 3 cw_outbyte
0 0 0 0 cw_inbyte
54 34 2 2 cw_padding
195 85 6 1 cw_outnum
0 0 0 0 cw_getnum
124 80 3 1 cw_printf
0 0 0 0 _exception_handler
0 0 0 0 _hw_exception_handler
0 0 0 0 _interrupt_handler
3 2 1 1 _program_clean
3 2 1 1 _program_init
31 22 1 1 strlen
20 12 1 1 __do_global_ctors_aux
14 9 3 1 __init
11 7 2 1 __fini
5347 3556 45 24
Instruction profile
instruction # %
addi 12 0,337
addik 1028 28,909
addk 380 10,686
and 3 0,084
andi 13 0,366
beqi 4 0,112
beqid 5 0,141
bgei 4 0,112
bgeid 177 4,978
bgti 1 0,028
blei 2 0,056
blti 1 0,028
bltid 2 0,056
bnei 7 0,197
bneid 6 0,169
bra 1 0,028
brai 1 0,028
bralid 3 0,084
bri 3 0,084
brid 3 0,084
brlid 194 5,456
bslli 1 0,028
bsrli 6 0,169
cmp 177 4,978
cmpu 4 0,112
idivu 2 0,056
imm 8 0,225
lbu 8 0,225
lbui 6 0,169
lw 194 5,456
lwi 382 10,742
mul 2 0,056
or 110 3,093
rsub 3 0,084
rsubk 9 0,253
rtsd 197 5,540
sb 3 0,084
sbi 3 0,084
sext8 6 0,169
sw 193 5,427
swi 385 10,827
xori 7 0,197
3556
Function profile
81
cycles instructions execute calls function
6 1 1 1 _start
instruction # %
brai 1 100,000
cycles instructions execute calls function
7 6 2 1 _start1
instruction # %
addi 1 16,667
addik 3 50,000
brlid 1 16,667
or 1 16,667
cycles instructions execute calls function
1 1 1 1 exit
instruction # %
bri 1 100,000
cycles instructions execute calls function
22 13 1 1 __do_global_dtors_aux
instruction # %
addik 4 30,769
beqi 1 7,692
bneid 1 7,692
lbui 1 7,692
lw 2 15,385
lwi 1 7,692
rtsd 1 7,692
sbi 1 7,692
sw 1 7,692
cycles instructions execute calls function
13 7 1 1 frame_dummy
instruction # %
addik 2 28,571
beqi 1 14,286
lw 1 14,286
lwi 1 14,286
rtsd 1 14,286
sw 1 14,286
cycles instructions execute calls function
40 29 6 1 _crtinit
instruction # %
addi 10 34,483
bgti 1 3,448
blei 2 6,897
brlid 5 17,241
lw 1 3,448
or 4 13,793
rsub 3 10,345
rtsd 1 3,448
sw 2 6,897
cycles instructions execute calls function
4687 3183 1 1 fib
instruction # %
addik 973 30,569
addk 353 11,090
bgeid 177 5,561
brlid 176 5,529
cmp 177 5,561
lw 177 5,561
lwi 354 11,122
82
or 88 2,765
rtsd 177 5,561
sw 177 5,561
swi 354 11,122
cycles instructions execute calls function
17 12 3 1 main
instruction # %
addik 4 33,333
addk 2 16,667
brlid 2 16,667
lw 1 8,333
or 1 8,333
rtsd 1 8,333
sw 1 8,333
cycles instructions execute calls function
66 30 3 3 RS232_writeByte
instruction # %
andi 6 20,000
bnei 3 10,000
bsrli 3 10,000
imm 6 20,000
lwi 3 10,000
or 3 10,000
rtsd 3 10,000
swi 3 10,000
cycles instructions execute calls function
33 21 6 3 cw_outbyte
instruction # %
addik 6 28,571
andi 3 14,286
brlid 3 14,286
lw 3 14,286
rtsd 3 14,286
sw 3 14,286
cycles instructions execute calls function
54 34 2 2 cw_padding
instruction # %
addik 4 11,765
addk 2 5,882
and 2 5,882
bgei 2 5,882
lw 2 5,882
lwi 6 17,647
or 4 11,765
rsubk 4 11,765
rtsd 2 5,882
sw 2 5,882
swi 4 11,765
cycles instructions execute calls function
195 85 6 1 cw_outnum
instruction # %
addik 10 11,765
addk 13 15,294
beqid 1 1,176
bgei 2 2,353
blti 1 1,176
bltid 1 1,176
bneid 2 2,353
brlid 5 5,882
bsrli 2 2,353
cmpu 3 3,529
idivu 2 2,353
83
lbu 2 2,353
lbui 3 3,529
lw 1 1,176
lwi 9 10,588
mul 2 2,353
or 3 3,529
rsubk 4 4,706
rtsd 1 1,176
sb 3 3,529
sbi 1 1,176
sext8 2 2,353
sw 2 2,353
swi 7 8,235
xori 3 3,529
cycles instructions execute calls function
124 80 3 1 cw_printf
instruction # %
addi 1 1,250
addik 12 15,000
addk 9 11,250
andi 2 2,500
beqid 4 5,000
bltid 1 1,250
bneid 3 3,750
bra 1 1,250
brid 3 3,750
brlid 2 2,500
bslli 1 1,250
bsrli 1 1,250
cmpu 1 1,250
lbu 3 3,750
lbui 2 2,500
lw 2 2,500
lwi 6 7,500
or 1 1,250
rtsd 1 1,250
sbi 1 1,250
sext8 4 5,000
sw 1 1,250
swi 16 20,000
xori 2 2,500
cycles instructions execute calls function
3 2 1 1 _program_clean
instruction # %
or 1 50,000
rtsd 1 50,000
cycles instructions execute calls function
3 2 1 1 _program_init
instruction # %
or 1 50,000
rtsd 1 50,000
cycles instructions execute calls function
31 22 1 1 strlen
instruction # %
addik 3 13,636
addk 1 4,545
and 1 4,545
andi 2 9,091
beqi 2 9,091
bnei 3 13,636
bri 1 4,545
imm 2 9,091
lbu 3 13,636
lw 1 4,545
rsubk 1 4,545
84
rtsd 1 4,545
xori 1 4,545
cycles instructions execute calls function
20 12 1 1 __do_global_ctors_aux
instruction # %
addik 3 25,000
bnei 1 8,333
bri 1 8,333
lw 1 8,333
lwi 2 16,667
rtsd 1 8,333
sw 1 8,333
swi 1 8,333
xori 1 8,333
cycles instructions execute calls function
14 9 3 1 __init
instruction # %
addik 2 22,222
bralid 2 22,222
lw 1 11,111
or 2 22,222
rtsd 1 11,111
sw 1 11,111
cycles instructions execute calls function
11 7 2 1 __fini
instruction # %
addik 2 28,571
bralid 1 14,286
lw 1 14,286
or 1 14,286
rtsd 1 14,286
sw 1 14,286
Figura 35. Relatório da análise de desempenho do programa número de Fibonacci
85
G. Protocolo GDB Remote Serial Protocol
O processo de comunicação entre o cliente GDB e sistema alvo é definido através do protocolo
GDB Remote Serial Protocol (GDB RSP) [14]. Este protocolo é baseado num sistema de pacotes
constituídos por caracteres ASCII e desenhado para ser usado em qualquer meio de comunicação
que suporte a transferência de dados do tipo half-duplex. É adequado para o uso em redes locais,
como por exemplo Ethernet e comunicações série, como por exemplo a interface Recommended
Standard 232 (RS-232), interface Controller-area Network Bus (CAN-bus), entre outras.
O cliente GDB envia comandos, o sistema alvo envia repostas. Tanto os comandos como as
respostas são enviados através de pacotes. Independentemente do tipo de pacote recebido é
necessário enviar uma notificação acerca da validade do pacote ao emissor. Se o checksum do
pacote recebido estiver correcto é enviado para o emissor o carácter ‘+’; no caso do checksum do
pacote estar errado o carácter enviado é o ‘-‘, indicando que o pacote deve ser reenviado.
A partir da versão 5.0 do protocolo, cada pacote é inicializado pelo carácter cifrão ‘$’, seguido do
campo packet-data e terminado pelo campo checksum. Os campos encontram-se separados
pelo caracter cardinal ‘#’. Os pacotes representam-se assim seguinte forma: $packet-
data#checksum.
O packet-data é o campo que define o comando no caso do cliente GDB ou a reposta no caso
do stub. É composto por uma sequência de caracteres dividido em uma ou mais secções separadas
por um dos caracteres ‘,’, ‘;’ ou ‘:’. São permitidos todos os caracteres com excepção dos
caracteres ‘#’, ‘$’ e dos caracteres com valor numericamente superior a 126. Assim, o protocolo pode
ser usado sobre ligações que só suportam sistemas de caracteres de sete bits, encontradas com
frequência em sistemas anteriores a meados da década de noventa. Actualmente o protocolo já
permite enviar, nalguns tipos de respostas e comandos, dados binários codificados em sistemas de
caracteres de oito bits, tornando assim a transmissão mais eficiente.
O checksum consiste num valor de oito bits sem sinal, obtido através da soma de todos os
caracteres do packet-data no formato de oito bits sem sinal. É representado por dois dígitos no
sistema hexadecimal utilizando os seguintes caracteres [0-9] e [a-f], sem suprimir os zeros à
esquerda.
O envio de dados binários é efectuado através da codificação de cada byte em ASCII, utilizando
os caracteres [0-9], [a-f] e [A-F], para representarem os dois dígitos hexadecimais do byte. Os bytes
são enviados pela ordem utilizada pelo sistema alvo para a representação de dados. Com a
excepção de dados binários da memória ou de registos, todos os zeros à esquerda são suprimidos.
Os dados da resposta podem ser comprimidos de forma a diminuir o tamanho do pacote a ser
enviado, tornando assim mais rápido o seu envio, mas essa característica não é abordada neste
texto.
Certos comandos permitem o envio de dados binários no formato binário, sem recorrer à sua
codificação em ASCII. Para tal seja possível são usados os caracteres de escape ‘#’, ‘$’ e ‘}’. Nas
respostas, o carácter ‘*’ também deve ser considerado um carácter de escape devido à sua
utilização no sistema de compressão de dados.
86
A comunicação é sempre iniciada pelo cliente GDB que envia um comando ao stub, ficando à
espera da deste. Em geral a resposta é imediata excepto para os comandos ‘C’, ‘c’, ‘s’ e ‘S’ descritos
na Tabela 33. Para estes comandos a resposta só é enviada quando o processamento for suspenso,
por exemplo, um ponto predefinido de interrupção ter sido encontrado.
Tabela 33. Comandos sem resposta imediata
COMANDO DESCRIÇÃO
caddr executa o programa a partir do endereço addr. Se o endereço addr for omisso, a execução começa no ponto onde actualmente se encontra.
Csig;addr executa o programa a partir do endereço addr e envia um número sinal (sig). O número sig não se encontra bem definido no protocolo. Em geral usa-se o sistema de numeração dos sinais do UNIX. Se o endereço addr for omisso, a execução começa no ponto onde actualmente se encontra.
saddr executa uma única instrução do programa a partir do endereço addr. Se o endereço addr for omisso, a execução começa no ponto onde actualmente se encontra.
Ssig;addr executa o programa a partir do endereço addr e envia um número sinal (sig) . O número sig não se encontra bem definido no protocolo. Em geral usa-se o sistema de numeração dos sinais do UNIX. Se o endereço addr for omisso, a execução começa no ponto onde actualmente se encontra.
O stub deve suportar obrigatoriamente os seguintes comandos: ‘g’ (lê registos), ‘G’ (escreve
registos), ‘m’ (lê a memória), ‘M’ (escreve memória), ‘c’ (executa o programa) e ‘s’ (efectua um passo
da execução do programa). Todos os outros comandos são opcionais. Caso o cliente GDB envie um
comando não suportado o stub envia uma resposta vazia (‘$#00‘). Desta forma pode-se adicionar
mais comandos ao protocolo sem causar qualquer tipo de problemas de retro compatibilidade. Se
certos comandos não são suportados o cliente GDB pode substituir por um equivalente ou utilizar
uma sequência de comandos para obter a resposta pretendida.
Se na sequência da execução de um comando ocorrer um erro é enviada como resposta uma
mensagem de erro ($EXX#xx). ‘XX’ são dois caracteres que representam um número no sistema
hexadecimal utilizado para identificar o erro; o número a enviar não vem definido no protocolo. Neste
caso os zeros à esquerda não são suprimidos.
Os dois caracteres ‘xx’ representam o checksum do packet-data do pacote. No caso de
sucesso na execução muitos comandos enviam a resposta OK ($OK#9a).
87
H. Relatório da Comunicação do Modo Depurador/Servidor GDB
A comunicação efectuada através do protocolo GDB Remote Serial Protocol (GDB RSP) entre o
simulador a operar em modo depurador/servidor GDB e o programa cliente mb-gdb pode ser
visualizada e acompanhada pelo utilizador, ao executar o simulador em modo depurador/servidor
GDB com a opção –-prtclv, ver apêndice B. para mais detalhes.
Os seguintes excertos com a visualização da comunicação apresentados foram obtidos através
da depuração do programa teste Print.
Na Figura 36 encontra-se o excerto inicial da comunicação. Este excerto ocorre logo após o
estabelecimento da comunicação entre ambos os programas. Nesta fase o sistema no simulador é
inicializado, sendo de seguida preparado pelo programa cliente mb-gdb para se efectuar o
descarregamento do programa a depurar. A preparação ao ser finalizada é efectuado o
descarregamento do programa teste para a memória do sistema simulado. Com o descarregamento
efectuado o programa cliente mb-gdb insere automaticamente dois breakpoints, um no inicio da
função main() e outro no inicio da função exit(). A inserção destes breakpoints é efectuada por
defeito, o utilizador tem a opção de remover ambos ou um dos breakpoints da configuração, ou
mesmo de inserir no começo da inicialização do sistema um breakpoint na posição de memória que
pretender. Como se pode ver no fim do excerto da comunicação os dois breakpoints foram inseridos
na posição de memória 0x16c, referente ao inicio da função main(), e na posição 0x68, referente ao
inicio da função exit(). No fim desta fase o simulador e o programa cliente mb-gdb ficam pronto
para inicializar a depuração, aguardando ordens do utilizador.
<-: $Hc-1#09...Ack
->: $OK#9a...Ack
<-: $qC#b4...Ack
->: $#00...Ack
<-: $qOffsets#4b...Ack
->: $Text=0;Data=0;Bss=0#04...Ack
<-: $?#3f...Ack
->: $S05#b8...Ack
<-: $Hg0#df...Ack
->: $OK#9a...Ack
<-: $g#67...Ack
->: $0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#00...nAck
->: $0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#00...nAck
->: $0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#00...nAck
->: $0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#00...Ack
<-: $qSymbol::#5b...Ack
->: $#00...Ack
<-: $qxil,D0,2f746573745f70726f6772616d735f65786563757461626c652f6764625f74657374732f70726
96e742f7072696e742e6465627567#f6...Ack
88
/test_programs_executable/gdb_tests/print/print.debug
->: $OK#9a...Ack
<-: $X0,0:#1e...Ack
->: $OK#9a...Ack
<-: $X0,4:#32...Ack
->: $OK#9a...Ack
<-: $X8,4:#72...Ack
->: $OK#9a...Ack
<-: $X10,4:#4e...Ack
->: $OK#9a...Ack
<-: $X20,4:#47...Ack
->: $OK#9a...Ack
<-: $X50,400:#42...Ack
->: $OK#9a...Ack
<-: $X450,388:#7b...Ack
->: $OK#9a...Ack
<-: $X7d8,24:#94...Ack
->: $OK#9a...Ack
<-: $X7fc,1c:#d3...Ack
->: $OK#9a...Ack
<-: $X818,8:#93...Ack
->: $OK#9a...Ack
<-: $X820,8:#8c...Ack
->: $OK#9a...Ack
<-: $X828,2c5:#7f...Ack
->: $OK#9a...Ack
<-: $Xaf0,28:#df...Ack
->: $OK#9a...Ack
<-: $Xb18,4:#bd...Ack
->: $OK#9a...Ack
<-: $Mf,0:f#af...Ack
->: $OK#9a...Ack
<-: $m68,4#3b...Ack
->: $b8000000#ba...Ack
<-: $m68,4#3b...Ack
->: $b8000000#ba...Ack
<-: $m68,4#3b...Ack
->: $b8000000#ba...Ack
<-: $m68,4#3b...Ack
->: $b8000000#ba...Ack
<-: $m168,4#6c...Ack
->: $30a00828#c6...Ack
<-: $m168,4#6c...Ack
->: $30a00828#c6...Ack
<-: $m16c,4#97...Ack
->: $3021ffd0#26...Ack
<-: $m170,4#65...Ack
->: $d9e00800#fa...Ack
<-: $m174,4#69...Ack
->: $b9f40304#fc...Ack
<-: $m168,4#6c...Ack
->: $30a00828#c6...Ack
<-: $m168,4#6c...Ack
->: $30a00828#c6...Ack
<-: $m16c,4#97...Ack
->: $3021ffd0#26...Ack
<-: $m170,4#65...Ack
->: $d9e00800#fa...Ack
<-: $m174,4#69...Ack
->: $b9f40304#fc...Ack
<-: $m168,4#6c...Ack
->: $30a00828#c6...Ack
<-: $m168,4#6c...Ack
->: $30a00828#c6...Ack
<-: $m16c,4#97...Ack
->: $3021ffd0#26...Ack
<-: $m170,4#65...Ack
->: $d9e00800#fa...Ack
<-: $m174,4#69...Ack
->: $b9f40304#fc...Ack
<-: $Z0,68,4#84...Ack
->: $OK#9a...Ack
Insert breakpoint at 0x00000068.
89
<-: $Z0,16c,4#e0...Ack
->: $OK#9a...Ack
Insert breakpoint at 0x0000016c.
<-: $Hc0#db...Ack
->: $OK#9a...Ack
Figura 36. Excerto do relatório da comunicação, inicialização do programa teste Print
Na Figura 37 encontra-se um excerto da comunicação referente à inserção de um breakpoint pelo
utilizador. Com a simulação parada o utilizador coloca um breakpoint na linha vinte e quatro
(cw_printf("a - 5 = %d\n",a - 5);) do ficheiro print.c, sendo 0x1a4 a posição de
memória correspondente. E dá ordem para simulação arrancar.
Com o desenrolar da simulação é atingido o breakpoint colocado pelo utilizador provocando a
interrupção da simulação.
<-: $Z0,1a4,4#dc...Ack
->: $OK#9a...Ack
Insert breakpoint at 0x000001a4.
<-: $Hc0#db...Ack
->: $OK#9a...Ack
<-: $c#63...Ack
--------------------------------------------------------------------------------
Print Test Program !!!
Hello Development Tools !!!
a = 30
--------------------------------------------------------------------------------
->: $S05#b8...Ack
Program stopped with signal 5. (breakpoint)
Figura 37. Excerto do relatório da comunicação, inserção do breakpoint no programa teste Print
Na Figura 38 encontra-se o excerto da comunicação referente à finalização da depuração. No
início a simulação encontra-se parada, sendo dada ordem pelo utilizador para o seu arranque. Com o
desenrolar da simulação é atingido o breakpoint que se situa no começo da função exit(),
provocando a interrupção da simulação. O programa cliente mb-gdb remove os breakpoints e finaliza
a comunicação com o simulador, ficando este à espera de uma nova ligação para se reinicializar
novamente o processo de depuração.
<-: $c#63...Ack
--------------------------------------------------------------------------------
a - 5 = 25
a + 5 = 35
a * 5 = 150
a / 5 = 6
--------------------------------------------------------------------------------
->: $S05#b8...Ack
Program stopped with signal 5. (breakpoint)
<-: $g#67...Ack
->: $0000000000000f2800000bc80000000100000000000000000000088700ff0eff34ff2fffc9ffceff36003
100000000000000000000000bf8000000000000005c00000068000000000000002f00000000000000000000000
90
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000680
000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#78...nAck
->: $0000000000000f2800000bc80000000100000000000000000000088700ff0eff34ff2fffc9ffceff36003
100000000000000000000000bf8000000000000005c00000068000000000000002f00000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000680
000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#78...nAck
->: $0000000000000f2800000bc80000000100000000000000000000088700ff0eff34ff2fffc9ffceff36003
100000000000000000000000bf8000000000000005c00000068000000000000002f00000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000680
000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#78...nAck
->: $0000000000000f2800000bc80000000100000000000000000000088700ff0eff34ff2fffc9ffceff36003
100000000000000000000000bf8000000000000005c00000068000000000000002f00000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000680
000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000#78...Ack
<-: $z0,68,4#a4...Ack
->: $OK#9a...Ack
Remove breakpoint at 0x00000068.
<-: $z0,16c,4#00...Ack
->: $OK#9a...Ack
Remove breakpoint at 0x0000016c.
<-: $z0,1a4,4#fc...Ack
->: $OK#9a...Ack
Remove breakpoint at 0x000001a4.
<-: $k#6b...Ack
--------------------------------------------------------------------------------
Connection close by GDB client.
--------------------------------------------------------------------------------
Waiting for connections...
. hostname: Windows
. ip: 10.0.2.15
. port: 1234
Figura 38. Excerto do relatório da comunicação, finalização do programa teste Print
