Estudo de performance de algoritmos de controle em sistema embarcado

(1)

UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO

DEPARTAMENTO DE AUTOMAÇÃO E SISTEMAS ENGENHARIA DE CONTROLE E AUTOMAÇÃO

Iago de Oliveira Silvestre

Estudo de Performance de Algoritmos de Controle em

Sistema Embarcado

[Florianópolis] [2020]

(2)

Estudo de Performance de Algoritmos de Controle em

Sistema Embarcado

Trabalho Conclusão do Curso de Graduação em En-genharia de Controle e Automação do Centro Tec-nológico da Universidade Federal de Santa Catarina como requisito para a obtenção do título de Bacharel em Engenharia de Controle e Automação

Orientador: Prof. Dr. Leandro Buss Becker

Florianópolis 2020

(3)

Ficha de identificação da obra elaborada pelo autor,

através do Programa de Geração Automática da Biblioteca Universitária da UFSC. Silvestre, Iago

Estudo de Performance de Algoritmos de Controle em Sistema Embarcado / Iago Silvestre ; orientador, Leandro Becker, 2020.

60 p.

Trabalho de Conclusão de Curso (graduação)

-Universidade Federal de Santa Catarina, Centro Tecnológico, Graduação em Engenharia de Controle e Automação,

Florianópolis, 2020. Inclui referências.

1. Engenharia de Controle e Automação. 2. sistemas embarcados. 3. sistemas computacionais. 4. gem5. 5. VANT. I. Becker, Leandro. II. Universidade Federal de Santa Catarina. Graduação em Engenharia de Controle e Automação. III. Título.

(4)

Estudo de Performance de Algoritmos de Controle em

Sistema Embarcado

Esta monograﬁa foi julgada no contexto da disciplina DAS5511: Projeto de Fim de Curso e aprovada na sua forma ﬁnal pelo Curso de Engenharia de Controle e

Automa-ção.

Florianópolis, 27 de janeiro de 2020.

________________________ Prof. Leandro Buss Becker, Dr.

Coordenador do Curso

Banca Examinadora:

________________________ Prof. Leandro Buss Becker,

Orientador

________________________ Lázaro Ismael Hardy Llins,

Avaliador

________________________ Prof. Fabio Baldissera,

Presidente da banca

Matheus Domingos da Silva e Silva, Debatedor

Gabriel José Prá Gonçalves, Debatedor

(5)

Este trabalho é dedicado aos meus colegas e professores de universidade, à minha família e todos que me motivaram.

(6)

AGRADECIMENTOS

A Universidade Federal de Santa Catarina e seu corpo docente, que me fornece-ram a oportunidade de estudar e me aprofundar na minha área de interesse.

Ao meu orientador Leandro Buss Becker, que me instigou, motivou e colaborou no projeto.

Ao meus pais Marcio e Margareth, por desde cedo me motivarem a estudar e aprender, algo que acredito jamais conseguir retribuir.

A minha vó Yvonne, por ter acolhido a mim e meu irmão e pelo seu carinho. Ao meu amigo e irmão Igor, que me acompanha e motiva nos sucessos e erros.

(7)

The scholar’s greatest weakness: calling procrastination research.

(8)

Resumo

O estudo de performance do sistema embarcado é vital quando tratamos de sistemas ciber-físicos que, para garantir estabilidade do sistema, devem operar respeitando deadli-nes impostos durante o projeto do sistema. Este estudo pode ser realizado diretamente na plataforma embarcada porém quando realizado por simulação oferece um nível de liber-dade muito alto para conﬁguração do Sistema Computacional sendo testado. A precisão e abstração dos modelos da simulação podem assumir diferentes níveis, assim é preciso alcançar uma abstração adequada para tornar o método de simulação ágil e também oferecer uma boa precisão para que os dados tenham validade quando comparados aos testes físicos. O objetivo desse trabalho é criar um método de análise de algoritmos de controle em sistema embarcado, Para validar a proposta são utilizados algoritmos desen-volvidos pelo projeto colaborativo entre UFMG e UFSC ProVANT , permitindo com isso um estudo da performance desses diferentes algoritmos. Esta análise foi feita através de uma ferramenta de simulação controlada por eventos, com precisão em nível de ciclos da CPU e que oferece um ambiente de simulação altamente ajustável. Os resultados obtidos tiveram um alto nível de complexidade e demonstraram uma boa precisão do modelo do Sistema Computacional quando comparados aos testes físicos realizados na placa de desenvolvimento Raspberry Pi 3 Model B+.

Palavras-chave: Automação. Sistemas Embarcados. VANT. Sistemas Computacionais.

(9)

Abstract

The performance analysis of the of embedded systems is critical when dealing with cyber physical systems that to guarantee the system stability have to operate respecting mul-tiple deadlines imposed during the project of the system. This analysis can be realized through tests on the embedded system designed hardware but also through simulation software which offers a great degree of liberty for the user to configure the desired system for the tests to be ran on. The accuracy and abstraction of the simulation models can be of different levels, but the desired combination would be a model with enough abstraction so that the simulation tests can be ran in an agile manner and enough accuracy so that the simulation data have validation when compared with the tests ran on the embedded system designed hardware. The main objective of this work is to provide a method of anal-ysis of an embedded system control algorithms, using for the tests algorithms developed by the colaborative project between UFMG and UFSC called ProVANT, to analyze the simulation data generated from the tests of these algorithms. The tests were realized on a modular discrete event driven computer system simulator platform with cycle-accurate precision. The simulation data acquired through the tests had a high level of complexity and demonstrated good precision of the computer system when compared with the tests ran on the Raspberry Pi 3 Model B+ development board.

(10)

Lista de ilustrações

Figura 1 – Sensores distribuídos pelo VANT. . . 16

Figura 2 – Expectativas do mercado estadunidense de VANTs em milhões de doláres. 17 Figura 3 – Modelo ProVANT com conﬁguração tiltrotor. . . . 19

Figura 4 – Implementação sem pipeline. . . 23

Figura 5 – Implentação com pipeline. . . 23

Figura 6 – Modelo de One-Level Branch Predictor. . . . 25

Figura 7 – Regiões dos planos s e z. . . 26

Figura 8 – Modelo do processo para método H∞ . . . 27

Figura 9 – Abstração e precisão de modelos executáveis. . . 29

Figura 10 – Fluxo de dados na simulação FS. . . 32

Figura 11 – Utilização do resetstats e dumpstats em exemplo de código. . . . 37

Figura 12 – M akef ile padrão dos algortimos adaptados. . . . 38

Figura 13 – Raspberry Pi 3 Model B+. . . 39

Figura 14 – Modelo de processador HPI. . . 40

Figura 15 – Modelos de memória da ferramenta gem5. . . 41

Figura 16 – Exemplo de script. . . 47

Figura 17 – Protótipo do VANT 2.0. . . 48

Figura 18 – Tempos de execução da placa e da simulação. . . 51

(11)

Lista de tabelas

Tabela 1 – Mismatch dos Benchmarks executados na ferramenta gem5 . . . . 32 Tabela 2 – Build targets do gem5 . . . . 35

(12)

Lista de abreviaturas e siglas

VANT Veiculo Aéreo Não Tripulado CPU Central P rocessing U nit

RISC Reduced Instruction Set Computer

CISC Complex Instruction Set Computer

LQR Linear− quadratic regulator

MPC M odel P redictive Control

UFSC Universidade Federal de Santa Catarina UFMG Universidade Federal de Minas Gerais RAM Random Acess Memory

ROS Robot Operating System

(13)

Lista de símbolos

∞ Inﬁnito sup Supremum || || Norma matemática T Periódo AT _{Matriz transposta de A} A−1 Matriz inversa de A

s Plano complexo da transformada de Laplace

(14)

Sumário

1 INTRODUÇÃO . . . 16 1.1 Motivação . . . 19 1.1.1 Objetivos Gerais . . . 20 1.1.2 Objetivos Especíﬁcos . . . 20 1.1.3 Estrutura do Trabalho . . . 20 2 REVISÃO DA LITERATURA . . . 22 2.1 Arquitetura de CPUs . . . 22 2.1.1 Instruction Pipelining . . . 22 2.1.2 Branch Prediction . . . 24

2.1.3 In Order and Out of Order . . . 25

2.2 Estabilidade de Sistemas Discretizados . . . 26

2.3 Estrategias de Controle Analisadas . . . 27

2.3.1 H∞ . . . 27

2.3.2 Linear-Quadratic Regulator Control . . . . 28

2.4 Análise de Performance de Sistemas Computacionais por Simulação 29 3 FERRAMENTA GEM5 . . . 31

3.1 Introdução . . . 31

3.2 Setup do Ambiente . . . 33

3.2.1 Requisitos da ferramenta gem5 . . . 33

3.2.2 Requisitos para os algoritmos testados . . . 34

3.3 Conﬁguração da Ferramenta . . . 35

3.3.1 Compilação do sistema ARM no gem5 . . . 35

3.3.2 Compilação do m5op.arm e dos Códigos Testados . . . 36

3.3.3 Conﬁguração do Ambiente de Simulação . . . 39

3.3.4 Kernel e Imagem de Disco para Simulação . . . 42

3.4 Medidas Para Acelerar o Processo de Simulação . . . 43

3.4.1 Alterações Necessárias para Rodar Simulação com Duas Imagens . . . 44

3.4.2 Criação de Checkpoints . . . 45

3.4.2.1 Veriﬁcando a Restauração de Checkpoint com Modelo de CPU Correto . . . 46

3.4.3 Utilização de scripts . . . 46

4 ALGORITMOS TESTADOS E RESULTADOS . . . 48

4.1 vant2load_Hinﬁnity . . . 48

(15)

4.1.2 Veriﬁcação dos Resultados em Placa de Desenvolvimento . . . 51

4.1.3 Encontrando Gargalos . . . 52

4.2 vant2_lqr . . . 53

4.2.1 Discussão dos Resultados da Simulação . . . 53

4.3 vant2load_Franklin . . . 54

4.3.1 Discussão dos Resultados da Simulação . . . 55

5 CONSIDERAÇÕES E TRABALHOS FUTUROS . . . 57

(16)

16

1 Introdução

Sistemas Embarcados são sistemas computadorizados, em outras palavras uma combinação de processadores, memórias e dispositivos de entrada e saída, totalmente dedicados ao sistema que controlam. Como sistemas embarcados usualmente são utili-zados para controlar movimentos mecânicos do sistema em que estão incorporados, eles geralmente tem obrigações de computação em tempo-real para garantir a estabilidade do sistema (AMINIFAR, 2016). Os sistemas embarcados modernos geralmente recorrem à utilização de microcontroladores, microprocessadores com memória integrada e interfaces para periféricos.

Uma utilização dos Sistemas Embarcados são nos Veículos Aéreos Não Tripu-lados (VANT), que são qualquer tipo de aeronave que pode ser controlada nos 3 eixos e que voa sem ter um piloto humano dentro dela, eles podem ser operados por contro-les a distância ou de forma autônoma por uma lógica de controle projetada. O VANTs é considerados um sistema ciber-físico, onde dispositivos físicos são controlados por um sistema computacional, que geralmente utiliza de dados disponibilizados por uma rede de sensores, externos ou distribuídos pelo sua estrutura, como mostra a Figura 1.

Figura 1 – Sensores distribuídos pelo VANT.

Fonte: Relatório (WINKLER, 2016)

As utilizações dos VANTs são diversas e uma área de constante pesquisa, prin-cipalmente nos últimos anos. No escopo militar, os VANTs tiveram grande notoriedade nos últimos anos pelo uso em ataques teleguiados, porém também podem ser usados para reconhecimento de áreas. O uso civil é muito diversiﬁcado mas podemos apontar algumas áreas que tem tido pesquisa de maior notoriedade nos últimos anos:

(17)

CAPÍTULO 1. INTRODUÇÃO 17

• Levantamento topográﬁco em regiões de agricultura ou ﬂorestas; • Localização e resgate em locais de difícil acesso;

• Transporte de cargas;

• Atendimento médico emergencial.

O projeto de VANTs é um processo com diversas etapas de extrema importância para o produto ﬁnal, uma das etapas importantes após ter o modelo físico do projeto é projetar as leis de controle (DONADEL,2015 ; MELLO,2016). Outra etapa importante é desenvolver o sistema embarcado que irá gerenciar todas suas tarefas com determinadas prioridades (SILVANO, 2014), sendo o VANT um sistema crítico esse sistema embarcado deve ser implementado de forma que consiga respeitar seus deadlines.

Com tantas aplicações possíveis o mercado de VANTs tem tomado proporções signiﬁcativas, como mostra a Figura 2. Juntando isso a constante demanda por produtos mais eﬁcientes e competitivos, é preciso investir nos testes dos produtos para avaliar a es-tabilidade do VANT, tendo isso em mente os testes nessa área são de extrema importância para o projeto e aperfeiçoamento de novos produtos.

Figura 2 – Expectativas do mercado estadunidense de VANTs em milhões de doláres.

Fonte: (GRAND-VIEW-RESEARCH)

O ProVANT é um projeto colaborativo entre as Universidades Federais de Santa Catarina e Minas Gerais que iniciou em 2012, sendo que a equipe da UFSC está inserida no DAS (Departamento de Automação e Sistemas) sob coordenação do professor Leandro Buss Becker. O projeto tem como foco principal a pesquisa na área de design e controle

(18)

de Veículos Aéreos Não Tripulados, buscando gerar conhecimento e avanços. Os estudos atuais do projeto são diversos, porém em relação à equipe situada na UFSC, os mais recentes são os seguintes:

• Utilização de normas para a fase de projeto de um VANT

• Inter-comunicação de VANTs em missões de resgate, utilizando de sistemas multi-agentes

• Utilização do ROS (Robot Operating System), que pode facilitar o desenvolvimento do sistema embarcado de sistemas ciber-físicos e melhorando a transportabilidade entre arquiteturas

• Simulações utilizando de HIL ( Hardware in the Loop), para analisar estabilidade do sistema em situações que a veriﬁcação formal não conseguiu ser executada devido a explosão de estados

Além destes pontos, o projeto ProVANT também tem como alvo a análise de perfor-mance dos algoritmos de controle sendo desenvolvidos para rodar no sistema embarcado do VANT. Essa análise é importante primeiramente para veriﬁcar se os códigos de controle conseguem ser executados dentro das janelas projetadas, e também para detectar possíveis pontos de gargalo na execução do código permitindo explorar soluções para garantir que a lei de controle consiga ser executada respeitando suas obrigações de execução em tempo real. Esse estudo será explorado nesta monograﬁa e é a área de minha responsabilidade dentro do projeto ProVANT atualmente.

A análise de programas de controle durante o projeto de um VANT pode oferecer desafios significativos. Uma das alternativas é rodar os testes em alguma placa de desenvol-vimento, tais como BeagleBone, Raspberry, entre outras, porém uma grande desvantagem desse método é que não é possível alterar os dispositivos do sistema embarcado, não é possível testar o impacto que alterações nos tamanhos de memória cache ou frequência do processador trariam por exemplo. Além disso os processadores das placas de desen-volvimento tem uma arquitetura de instruções definitiva o que também limita os testes, já que para testar os impactos da utilização de outra arquitetura seria necessário ter em mãos uma placa de desenvolvimento com determinada arquitetura de instruções

Outra alternativa é utilizar ferramentas de simulação, porém em sua grande mai-oria essas ferramentas utilizam chamadas de serviços implementadas pelo próprio desen-volvedor, não oferecem um cálculo preciso do tempo de execução e muitas vezes utilizam de algum método de aproximação para calcular esse tempo, quando o mais desejado seria uma simulação com precisão em nível de ciclo da CPU.

(19)

de ser parametrizada, alterando o ambiente de simulação com liberdade, e oferecendo uma simulação precisa do sistema embarcado sendo simulado.

O principal fator para a construção dos VANTs pelo projeto é a diﬁculdade de customizar VANTs comerciais, sendo que muitas vezes varias funcionalidades não são documentadas e e nem oferecem possibilidade de serem alteradas pelo usuário. Por causa disso o projeto ProVANT visa capturar todo o escopo do projeto de um VANT, incluindo seu sistema embarcado, componentes elétricos, aspectos mecânicos e criação de modelos e protótipos, como por exemplo o demonstrado na Figura 3.

Figura 3 – Modelo ProVANT com conﬁguração tiltrotor.

Fonte: Dissertação (SILVANO, 2014)

Independentemente da utilização do VANT, para conseguirmos a estabilidade do voo em modo autônomo um dos pontos chaves é garantir que os sensores estão fornecendo informações de maneira rápida suﬁciente para que a lei de controle discreta consiga sempre ter valores atualizados das variáveis de controle. Além disso para termos um controle discreto estável é preciso designar um período que a lei de controle deve obedecer e ser executada em determinada frequência, veriﬁcar se o algoritmo de controle consegue ser executado dentro dessa janela de tempo também é vital para garantir a estabilidade do VANT.

1.1 Motivação

Analisando o escopo de simulações realizadas para veriﬁcação de performance e estabilidade de sistemas ciber-físicos, é possível perceber que em sua grande maioria, essas simulações estão fortemente atreladas as arquiteturas do sistema sobre teste. Tendo isso em mente o trabalho desenvolvido teve como maior motivação buscar um método de

(20)

realizar simulações dos algoritmos de uma maneira onde as características da plataforma alvo possam ser alteradas simplesmente mudando alguns parâmetros.

1.1.1 Objetivos Gerais

Este trabalho tem como objetivo principal explicar como modiﬁcar e realizar testes com a ferramenta gem5, de modo a oferecer uma simulação que pode ser ajustada facilmente para reﬂetir a arquitetura desejada de teste, além de esclarecer como podem ser extraídas informações dos resultados gerados pela simulação.

1.1.2 Objetivos Especíﬁcos

Como objetivos especíﬁcos do trabalho, podem ser citados:

• Estudar a ferramenta e o processo de simulação sendo realizado, explicando os passos necessários para replicação dos testes realizados

• Fornecer opções de modiﬁcar conﬁgurações da ferramenta para reduzir o tempo de simulação consideravelmente

• Realização de testes utilizando de algoritmos de controle desenvolvidos pelo projeto ProVANT para alguns modelos de VANT

• Enaltecer como os resultados gerados da simulação podem fornecer informações importantes relacionadas a performance e utilização do hardware

• Validação dos resultados obtidos através da simulação utilizando os dados obtidos com testes realizados em uma placa de desenvolvimento.

1.1.3 Estrutura do Trabalho

Esta monograﬁa foi organizada da seguinte forma:

O segundo capítulo tem como objetivo realizar uma revisão de conceitos tratados nesta monograﬁa, de forma a explicar brevemente a estabilidade de sistemas discretiza-dos, as estratégias de controle que foram testadas em seções posteriores e o estudo de performance de Sistemas Computacionais através de simulação.

O terceiro capítulo tem como objetivo explicar desde o inicio o trabalho ne-cessário para replicar as simulações realizadas nesta monograﬁa, desde as conﬁgurações iniciais da ferramenta até as alterações que foram realizadas para acelerar o processo de simulação.

(21)

O quarto capítulo apresenta os algoritmos testados e resultados obtidos atra-vés das simulações realizadas, além de enaltecer quais os dados foram lidos para extrair informações de performance e utilização dos componentes simulados.

No quinto e ultimo capítulo são feitas as considerações finais, tendo em mente os resultados obtidos, para concluir se os objetivos gerais e específicos foram alcançados, além de levantar a possibilidade para trabalhos futuros levando em conta temas que não tiveram oportunidade de serem explorados nesta monografia.

(22)

22

2 Revisão da Literatura

2.1 Arquitetura de CPUs

Nesta monograﬁa, alguns temas relacionados ao design de CPUs serão explora-dos, portanto uma breve revisão deve os familiarizar aos termos abordados.

2.1.1 Instruction Pipelining

O método de pipelining (ZARGHAM, 1996) começou a ganhar popularidade nas décadas de 1970 e 1980 e está presente na grande maioria das CPUs atuais, basicamente se trata de uma estratégia para paralelizar instruções realizadas por um núcleo do pro-cessador. O processamento de cada instrução pela CPU não é instantâneo, enquanto o número de etapas varia dependendo da implementação, conceitualmente elas podem ser resumidas em 5 passos.

1. Fetch : Pega as instruções da memória

2. Decode : Decodiﬁca a instrução, vendo o que é necessário para sua execução, como

por exemplo algum resultado de uma instrução anterior.

3. Execute : Executa a instrução

4. Memory : Acessa a memória de dados 5. Write : Escreve o resultado da instrução

Sem a implementação de um pipeline, cada instrução é processada exclusivamente do inicio ao ﬁm, como mostra a Figura 4 onde se assume que cada etapa toma 1 ciclo da CPU. Porém como cada etapa acaba utilizando de partes diferentes do hardware da CPU, os processadores modernos utilizam dos pipelines para aumentar a sua eﬁciência, como mostrado na Figura 5.

(23)

Capítulo 2. Revisão da Literatura 23

Figura 4 – Implementação sem pipeline.

Fonte: (SHINSEL)

Figura 5 – Implentação com pipeline.

Fonte: (SHINSEL)

Apesar de aumentar bastante o throughput de instruções, é bom ressaltar que por causa de overhead do controle do pipeline, o tempo de execução de cada instrução acaba sendo ligeiramente maior. Além disso, a implementação de pipelines tem impacto mais perceptível em processadores com arquiteturas de instruções reduzidas, como RISC e ARM, já que tem instruções mais simples que tomam menos tempo de execução. A solução tomada para aumentar a efetividade de pipelines em arquiteturas com design CISC(Complex Instruction Set Computer ), tais como x86, foi de separar cada operação do processador em micro operações (µops), tendo que a separação de cada instrução é feita na etapa de decodiﬁcação do pipeline.

(24)

2.1.2 Branch Prediction

Outro tema abordado relacionado a arquitetura de CPUs é o Branch Predictor (LEE), um circuito digital que tenta calcular o caminho que uma instrução condicional irá tomar antes do caminho ser conhecido deﬁnitivamente. O objetivo do Branch Predictor é aumentar o ﬂuxo de instruções no pipeline da CPU e uma boa implementação dele é importante para se ter uma boa performance em processadores modernos.

Sem a utilização de um Branch Predictor, o processador tem de esperar até que a instrução do pulo condicional tenha passado pela etapa de execução no pipeline para que a próxima instrução possa ir para a etapa de fetch. O Branch Predictor tenta então assumir qual pulo condicional é o mais provável e começa a processar as instruções do caminho especulado, quando a instrução do pulo condicional é executada duas situações podem ocorrer.

1. O Branch Predictor fez uma boa predição e o caminho tomado era realmente o

caminho correto, o processador segue o processamento deste caminho e o impacto na performance da CPU pelo preditor é positivo.

2. O Branch Predictor fez uma predição ruim e o pulo condicional estipulado não

estava correto, o processamento do caminho predito é descartado e o impacto na performance da CPU é negativo.

A primeira vez que uma instrução condicional é encontrada, não há muitas informações nas quais se basear para fazer a predição, porém o Branch Predictor guarda as decisões anteriores para utilizar em predições futuras. O nível de complexidade do Branch Predictor varia de implementação para implementação, alguns podem, por exemplo, reconhecer padrões como um pulo condicional que ocorre em todo terceira repetição de um loop.

A implementação mais simples possível do Branch Predictor é encontrada no microprocessador MIPS-X, onde todos os caminhos de instruções condicionais são aceitos como uma boa estimativa. Porém com o avanço dos microprocessadores, implementações mais avançadas precisaram ser implementadas, elas podem ser separadas em dois grupos:

• Static Branch Prediction O preditor utiliza somente de informações obtidas antes da execução do programa.

• Dynamic Branch Prediction O preditor utiliza de dados sendo obtidos em tempo de execução do programa.

Um dos modelos mais simples do preditor dinâmico é o One-Level Branch Predictor de-monstrado na Figura 6, k bits do endereço do caminho de um pulo condicional são armaze-nados no preditor e toda vez que esse caminho for tomado o seu contador é incrementado

(25)

com valor máximo de n, em contraponto quando o caminho não é tomado seu contador é decrementado com valor mínimo de 0. O preditor então toma a decisão de tomar ou não o caminho veriﬁcando o contador do caminho, caso seu valor seja menor que 2n−1 o caminho não é tomado, de outra forma o caminho é tomado.

Figura 6 – Modelo de One-Level Branch Predictor.

Fonte: (LEE)

2.1.3 In Order and Out of Order

Outro tema relacionado ao design de CPUs é o modo de que o processador executa as instruções, de forma geral duas abordagens podem ser tomadas:

1. In Order Execution O processador busca, executa e completa instruções na ordem

gerada pelo compilador, desta maneira se alguma instrução demora a ser executada e ocupa a vaga de execução do pipeline do processador por mais tempo, as outras ins-truções tem de esperar. Neste modo de processador as insins-truções são estaticamente escalonadas.

2. Out of Order Execution O processador busca as instruções na ordem gerada pelo

compilador, porem as executa em uma ordem direcionada pela disponibilidade dos dados utilizados na instrução e não na ordem original do executável. Desta maneira o processador tenta evitar ﬁcar esperando os resultados de uma instrução prévia e pode-se dizer que as instruções são dinamicamente escalonadas.

O modo de execução Out of Order permite uma maior performance do processador por evitar tempos de espera que ocorrem durante a execução do código. Uma de suas grandes

(26)

desvantagens é não ser nada fácil garantir o tempo de execução no pior caso (SCHOE-BERL, 2008) e portanto CPUs com esse design são geralmente consideradas inadequadas para sistemas com obrigações de tempo real.

2.2 Estabilidade de Sistemas Discretizados

Quando tratamos da estabilidade de um sistema linear discretizado invariante no tempo (LATHI, 2006), podem ser citadas as possíveis situações:

1. O sistema é assintoticamente estável se e somente se todos os polos de sua função

de transferência H[z] estiverem dentro do circulo unitário.

2. O sistema é instável se uma ou duas das seguintes condições existirem : (i) ao menos

um polo estiver fora do circulo unitário, (ii) Existirem polos repetidos sobre o circulo unitário.

3. O sistema é marginalmente estável se não existirem polos fora do circulo unitário e

existirem polos simples sobre o circulo unitário.

Figura 7 – Regiões dos planos s e z.

Fonte: (VILLANUEVA, 2019)

Como a função de transferência H[z] depende do período de amostragem (VIL-LANUEVA, 2019) tendo que z = eT s_{, é uma conclusão lógica que caso o processador seja}

incapaz de executar o código de controle dentro da janela de amostragem projetada, a estabilidade em si do sistema estará comprometida já que os polos não serão mais aqueles projetados.

(27)

2.3 Estrategias de Controle Analisadas

Enquanto a álgebra por trás dos métodos de controle testados não são de maior pertinência para esta monograﬁa, é importante apresentar os conceitos básicos de cada um para ao menos se ter ciência do que os caracteriza.

2.3.1 H

∞

O método de controle H∞ (MELLO, 2016) é utilizado para sintetizar controla-dores que alcançam estabilidade com performance garantida, para utilizar desse método o projetista deve expressar o problema de controle como um problema de otimização ma-temática e encontrar o controlador que soluciona o problema de otimização. Entre suas desvantagens estão a necessidade de ter boas fundamentações matemáticas para aplicar o método corretamente e de ter um bom modelo do sistema que será controlado. Porém uma das vantagens que esse método tem sobre as técnicas clássicas é o fato de ser apli-cável em sistemas multivariáveis com variáveis de controle acopladas. O termo H∞ vem do espaço matemático onde a otimização é feita,H∞ é o espaço Hardy de funções com valores matriciais . Tendo um processo representado na Figura 8

Figura 8 – Modelo do processo para método H∞

Fonte: Wikipedia

O sistema pode ser formulado por 2.1 e 2.2 " z v # = P(s) " w u # = " P11(s) P12(s) P21(s) P22(s) # " w u # (2.1) u = K(s) v (2.2)

então pode-se expressar a relação de z com w por 2.3

(28)

e realizando a transformação linear fracionária, Fl pode ser deﬁnida por 2.4

Fℓ(P, K) = P11+ P12K (I − P22K)−1P21 (2.4)

então o objetivo do controle com design H∞ é de encontrar o controlador K que minimiza a norma inﬁnita 2.5

||Fℓ(P, K)||∞ = sup ω

¯

σ(Fℓ(P, K)(jω)) (2.5)

o mesmo se aplica ao controle com design H2

2.3.2 Linear-Quadratic Regulator Control

Uma das estratégias de controle ótimo mais conhecidas é o LQR , tem como ob-jetivo controlar um sistema dinâmico, descrito por um conjunto de equações diferenciais, com custo mínimo. O ajuste do controlador é feito utilizando um algoritmo que minimiza uma função de custo, com critérios fornecidos pelo engenheiro, essa função de custo ge-ralmente se trata de uma forma de soma das variações de dados do sistema, como altura ou temperatura do processo, dos valores desejados. O algoritmo então encontra o ajuste que minimiza as variações indesejadas, sendo que o processo de ajuste normalmente é um processo iterativo, onde o engenheiro julga por simulação se o controle ótimo gerado se alinha com os objetivos do projeto. De maneira geral o método LQR se trata de uma forma de encontrar um controle por realimentação de estados que minimiza a função de custo fornecida pelo engenheiro.

Para um sistema linear continuo descrito por 2.6:

˙x = Ax + Bu (2.6)

com uma função de custo deﬁnida por 2.7:

J =

Z _∞

0

xTQx + uTRu + 2xTN udt (2.7) a lei de controle por realimentação de estados que minimiza o valor da função de custo é 2.8:

u =−Kx (2.8)

sendo que o ganho K é dado por 2.9:

K = R−1(BTP + NT) (2.9)

e a matriz P pode ser encontrada resolvendo a equação de Riccati 2.10:

AT

P + PA − P BR−1BTP +Q = 0 (2.10) sendo que 2.11:

A = A − BR−1_NT _{Q = Q − NR}−1

(29)

2.4 Análise de Performance de Sistemas Computacionais por

Si-mulação

Dentro da área de Sistemas Computacionais, a análise de performance de sistema embarcado é um problema de constante pesquisa, os métodos utilizados variam bastante porém um caminho tem sido explorado bastante ultimamente, o de utilizar modelos exe-cutáveis para estudo da performance, até mesmo durante a fase de projeto do sistema embarcado. O nível de complexidade dos modelos podem variar, sendo que modelos mais complexos tendem a ter menos abstração do sistema simulado, como mostra a Figura 9.

Figura 9 – Abstração e precisão de modelos executáveis.

Fonte: (BUTKO et al., 2014)

Os modelos executáveis que utilizam de linguagens de descrição de hardware, tais como VHDL ou Verilog, tem um baixo nível de abstração e por isso, se bem utiliza-das, conseguem modelar com precisão o Sistema Computacional. Porém esse baixo nível de abstração também se mostra como uma grande desvantagem, já que o processo de modelagem do sistema toma muito tempo e como normalmente esses modelos são usados durante o projeto do sistema é desejável um modelo mais ágil. Por esses fatores a maioria das aplicações de simulação constam de ferramentas com modelos com níveis de abstração mais altos.

(30)

Simu-Capítulo 2. Revisão da Literatura 30

lation, onde a ferramenta de alguma maneira faz com que o software testado acredite que

esteja rodando no hardware físico, fazendo com que o software projetado não precise ser alterado entre simulação e testes reais. Além disso uma simulação em modo Full System deve permitir que sistemas operacionais, drivers de dispositivos, kernels, middleware, entre outros sejam simulados, por causa disso a sua utilização mais comum é testar e detectar falhas de um sistema em processo de desenvolvimento, o que permite o desenvolvimento do software antes do projeto de hardware do sistema. Os dados dos testes da simulação

Full System podem ser utilizados também para guiar o projeto de hardware do sistema.

A precisão de Full-System Simulators pode ser separada em 3 níveis:

• Precisão em nível funcional : A simulação fornece dados relativamente próximos aos dados obtidos em testes físicos, porém não há precisão no número total de instruções executadas ou ciclos da CPU

• Precisão em nível de instruções : Os dados gerados pela ferramenta são relati-vamente próximos aos dados obtidos em testes físicos e oferecem precisão do número de instruções realizadas pela CPU

• Precisão em nível de ciclos da CPU : As informações retiradas dos dados fornecem precisão no número de instruções e ciclos da CPU, além de fornecer outros dados de performance relativamente próximos aos dados em testes físicos.

Outras características que diferenciam as ferramentas atuais são as arquiteturas de ins-truções suportadas e forma de licença, assim como os dispositivos disponibilizados pela ferramenta. Normalmente estas ferramentas oferecem diferentes tipos de modelos de CPU, memórias RAM, Cache e outros dispositivos, estes modelos tem diferentes níveis de com-plexidade e tem o intuito de modelar diferentes tipos de arquitetura do dispositivo, tais como o tipo de execução das instruções do processador, níveis de cache, entre outros.

(31)

31

3 Ferramenta Gem5

3.1 Introdução

Para realizar esse estudo de performance de algoritmos foi escolhida a ferramenta de simulação gem5, que em sua essência é uma ferramenta de simulação de sistema que pode ser usada para testar comportamento e performance de um sistema desejado. Ela se originou de uma união de duas ferramentas anteriores:

• M5 (Universidade de Michigan - Estados Unidos)

• GEMS (Universidade de Wisconsin-Madison - Estados Unidos)

A ferramenta herdou os modelos de infraestrutura e de CPU do M5 com os protocolos de memória e modelos de coerência de cache do GEMS, a gem5 é classiﬁcada como uma plataforma modular de simulação controlada por eventos discretos de sistemas computadorizados com precisão em nível de ciclos da CPU, isso signiﬁca que:

• Seus componentes podem ser rearranjados, parametrizados ou substituídos facil-mente para se adequar ao ambiente de simulação desejado

• Ela simula a passagem do tempo como uma serie de eventos discretos

• A intenção de seu uso é simular um ou mais sistemas computadorizados de diversas maneiras

• É considerada uma plataforma de simulação pois fornece diversos componentes já desenvolvidos para o usuário determinar como deseja montar o seu sistema.

É uma ferramenta Open Source, o que signiﬁca que seu código é disponibilizado abertamente para que o usuário possa realizar alterações e redistribuir gratuitamente, por causa disso ela é uma ferramenta que ainda está evoluindo, recebendo atualizações de acordo com os alterações realizadas pela comunidade que a usa, sendo para adicionar novas capacidades ou para facilitar as já disponíveis.

A ferramenta no momento atual esta escrita na linguagem C++ para os cons-trutores dos seus componentes e em Python para os scripts que são utilizados para passar os parâmetros aos construtores. A gem5 tem primariamente dois modos de simulação, no primeiro chamado Full System Mode (FS mode), é possivel simular o sistema completo

(32)

Capítulo 3. Ferramenta Gem5 32

com seus componentes e sistema operacional, já no modo denominado Syscall Emulation

Mode (SE mode) a simulação é limitada a execução de programas de espaço do usuário e

a utilizar os serviços de sistema disponíveis pela ferramenta. Como o modo Full System oferece uma simulação mais realística do Sistema Computacional, este foi escolhido para realização dos testes dos algoritmos de controle dos quais a performance é de interesse de estudo. Uma visão geral do ﬂuxo de dados que ocorre no modo de simulação Full System pode ser visto na Figura10

Figura 10 – Fluxo de dados na simulação FS.

Fonte: Arquivo Pessoal

A gem5 suporta múltiplas arquiteturas de instruções, tais como Alpha, ARM, MIPS, Power, SPARC, RISC-V e x86, também oferece diversos modelos de CPU, incluindo dois modelos simpliﬁcados CPI(Clocks per Instruction), um modelo que utiliza execução

Out of order e ﬁnalmente um que utiliza de execução In order com a simulação do pipeline

do processador.

A precisão das diversas ferramentas de simulação é objeto de estudo de diversos artigos e pode ser avaliada por diversas maneiras, uma delas é a simulação de benchmarks por simulação e por testes físicos e medir a diferença dos resultados. Os resultados do teste de alguns benchmarks na ferramenta gem5 pode ser visualizados na tabela 1.

Tabela 1 – Mismatch dos Benchmarks executados na ferramenta gem5

(33)

3.2 Setup do Ambiente

Para se conseguir executar as simulações demonstradas nesta monograﬁa, foi necessário realizar um setup para que durante a compilação e execução da simulação nenhum erro ocorra(LOWE-POWER).

3.2.1 Requisitos da ferramenta gem5

A ferramenta foi desenvolvida para ser executada em qualquer sistema opera-cional baseado em UNIX, porém ela é mais comumente utilizada em sistemas Linux e Mac OS. Os testes executados nesta monograﬁa foram executados no sistema operacional Ubuntu 18.04.

Além dos requisitos de sistema operacional, alguns pacotes que são utilizados pela ferramenta precisam ser instalados:

• git

Sistema de gerenciamento de repositórios utilizado para adquirir a versão mais atu-alizada da ferramenta gem5 e os arquivos dos algoritmos utilizados para teste. • gcc 4.8+

Compilador de C/C++ • SCons

Similar ao Make, o SCons é uma ferramenta de construção de software open source. • Python 2.7+

Como mencionado anteriormente, a ferramenta utiliza do Python nos scripts. • protobuf 2.1+

Biblioteca utilizada para geração e reprodução de arquivos de trace, utilizados para veriﬁcar a ordem de execuções da simulação.

• Boost

Biblioteca com algumas funções de uso geral em C++.

Em sistemas Ubuntu, os pacotes mencionados necessários para funcionamento da ferra-menta gem5 podem ser instalados com a seguinte linha de comando no terminal:

sudo apt install build-essential git m4 scons zlib1g zlib1g-dev libprotobuf-dev protobuf-compiler libprotoc-dev libgoogle-perftools-dev python-dev python gcc-arm*

(34)

Após os pacotes necessários instalados, o código fonte da ferramenta pode ser importado em um sistema Ubuntu através da seguinte linha de comando no terminal:

git clone

| {z }

git cloning command

https : //gem5.googlesource.com/public/gem5

| {z }

git repository

3.2.2 Requisitos para os algoritmos testados

Para testar os algoritmos de controle desenvolvidos pelo projeto ProVANT, são necessários alguns outros pacotes para a compilação obter sucesso.

• Eigen

Uma biblioteca de C++ para álgebra linear, matrizes, vetores e algoritmos relacio-nados.

• gcc-arm-linux-gnueabihf/g++-arm-linux-gnueabihf(ARM cross compiler) Para compilar os algoritmos de controle do projeto, foi utilizado um Cross

Compi-ler para a arquitetura de instruções em que o código foi projetado, no nosso caso a

arquitetura atual é a ARM.

• Robot Operating System (ROS)

Um conjunto de bibliotecas de software com intuito de ajudar o desenvolvimento de aplicações robóticas. Neste teste a versão do ROS utilizada foi a versão Melodic

Enquanto o ROS necessita de alguns passos adicionais para ser instalado, o restante dos pacotes podem obtidos em sistemas Ubuntu com a seguinte linha de comando no terminal:

sudo apt-get install libeigen3-dev g++-arm-linux-gnueabi

O ROS precisa de uma conﬁguração prévia dos repositórios do Ubuntu, porém sua instalação está amplamente documentada no seu site oﬁcial (ROS).A documentação é extensa e deve resolver qualquer problema se for encontrado durante a instalação e uso. Após a instalação do ROS, resta somente adquirir os algoritmos desenvolvidos pelo projeto ProVANT e depois adaptados para conseguirem rodar na ferramenta. O código fonte dos algoritmos adaptados está disponível no seguinte repositório:

(35)

3.3 Conﬁguração da Ferramenta

Tendo todos os pacotes necessários instalados, tanto para a ferramenta quando para os códigos adaptados desenvolvidos pelo projeto ProVANT, é preciso realizar as conﬁgurações da gem5. É necessário escolher o executável de simulação que irá rodar a simulação, obter o Kernel e imagem do disco do sistema a ser testado, e conﬁgurar as características do hardware que a ferramenta deve simular.

3.3.1 Compilação do sistema ARM no gem5

Após a instalação dos pacotes necessários para evitar quaisquer erros durante a simulação, devemos compilar o sistema onde a simulação irá rodar, essa compilação deve ser realizada somente uma vez e o executável gerado será sempre utilizado para executar as simulações posteriormente. A ferramenta oferece alguns tipos de executáveis de simulação, cada um oferece um conjunto de recursos que podem ser usados na simulação, como mostra a tabela 2

Tabela 2 – Build targets do gem5

Fonte: (SAIDI et al., )

Os testes realizados com a ferramenta utilizaram do executável gem5.fast, já que os recursos de debug em tempo de execução e suporte a ferramentas de caracterização tais como gprof e gperftools não era de interesse atual. De maneira geral os executáveis de simulação podem ser resumidos da seguinte maneira:

• gem5.debug

Usado para debug do código em tempo-real, como foi construído sem otimizações tem um tempo de compilação do executável mais rápido, porém tempo de execução da simulação consideravelmente mais lento.

(36)

• gem5.opt

Tem toda as capacidades de debug do gem5.debug e um tempo de execução da simulação bem mais rápido, porém com um tempo de compilação do executável mais lento.

• gem5.fast

Não oferece nenhum recurso adicional, porém oferece o tempo de execução da simu-lação mais rápido entre os executáveis disponíveis.

• gem5.prof

Oferece suporte a ferramenta de proﬁling gprof. • gem5.perf

Oferece suporte a ferramenta de proﬁling gperftools (GOOGLE).

Tendo o executável de simulação escolhido, podemos compilar usando a seguinte linha de comando no terminal dentro do repositório da ferramenta gem5 :

scons build/ARM/gem5.fast -j5

O argumento -j está relacionado ao número de núcleos de processador dedicados a com-pilação do executável e na maioria dos casos para agilizar o processo deve ser setado para o número de núcleos da máquina somados a um, no caso a máquina utilizada para testes possuía um processador com 4 núcleos então o comando atribuído foi -j5.

3.3.2 Compilação do m5op.arm e dos Códigos Testados

Para que os dados gerados pela simulação sejam mais precisos, a ferramenta gem5 oferece a biblioteca m5op de comandos que podem ser chamadas durante a execução do código para facilitar a análise performance posteriormente. Dentre os comandos que a biblioteca m5op oferece, podemos dar destaque aos seguintes que foram utilizados para os testes desta monograﬁa:

• resetstats [delay [period]]: Reseta as estatísticas de simulação em determinado delay em nanosegundos, e repete essa operação a cada período, também em nanosegundos. • dumpstats [delay [period]]: Salva as estatísticas de simulação desde o inicio da si-mulação ou desde o ultimo resetstats, também oferece as opções de ser executado após determinado delay e de ser executado periodicamente.

• checkpoint [delay [period]]: Cria um checkpoint da simulação que pode ser restau-rado, salvando o tempo de iniciar a simulação.

(37)

• readﬁle: Lê o arquivo de script passado como parâmetro na linha de comando que executa a simulação.

Enquanto os dois últimos comandos serão explorados em outras seções deste capítulo, podemos demonstrar a utilidade dos dois primeiros. Sem esses dois comandos, após a simulação de algum código, o resultado obtido seria relativo a todos recursos utilizados pelo sistema operacional desde o inicio da simulação. Como o que é de interesse desse estudo é a performance dos algoritmos de controle, podemos adaptar o código para separa-lo em seções onde a performance é de interesse, como a Figura 11 demonstra.

Figura 11 – Utilização do resetstats e dumpstats em exemplo de código.

Tendo em vista a utilidade oferecida por esse biblioteca, para utiliza-la alguns passos são necessários. Primeiramente um executável que terá os comandos deve ser com-pilado e copiado para a imagem de disco do sistema, enquanto a inserção desse executável na imagem de disco será tratada na seção 3.3.4 a compilação do executável pode ser feita seguindo estes passos:

1. Acessar o caminho /gem5/util/m5

2. Renomear o arquivo desejado, no caso Makeﬁle.arm para somente Makeﬁle 3. Abrir um terminal no caminho e dar o comando make

(38)

Além disso, também é preciso lincar um arquivo em Assembly durante compila-ção do código. Esse arquivo é dependente da arquitetura de instruções, como a utilizada para os testes foi a ARM, o arquivo escolhido foi o m5op_arm.S. Para facilitar a lincagem deste arquivo podemos criar uma variável de caminho em sistemas Ubuntu pelos seguintes passos:

1. Abrir o terminal e inserir a linha de comando:

gedit ~/.bashrc

2. Um arquivo de texto irá abrir

3. Adicionar uma nova linha no ﬁnal do arquivo e inserir o caminho de destino da

pasta onde a ferramente gem5 foi instalada.

Exemplo:export GEM5_PATH=/home/iago/gem5

4. Salvar o arquivo de texto e fechar todos terminais abertos.

5. É possível veriﬁcar se a variável foi criada utilizando a seguinte linha de comando:

echo $GEM5_PATH

Caso a resposta seja o caminho inserido no arquivo de texto a variável foi criada com sucesso.

Os códigos desenvolvidos pelo projeto ProVANT foram adaptados de maneira a conseguirem rodar na ferramenta gem5, como mencionado anteriormente a arquitetura de instruções que o código foi projetado é a ARM, portanto para não precisar compilar os códigos em um processador com essa arquitetura, foi utilizado um Cross Compiler em conjunto com um arquivo Makeﬁle relativamente simples, como mostra a Figura 12.

Figura 12 – M akef ile padrão dos algortimos adaptados.

(39)

Tendo todos os pacotes corretamente instalados, os algoritmos de controle podem ser compilados abrindo um terminal dentro de sua pasta e inserindo o comando make.

3.3.3 Conﬁguração do Ambiente de Simulação

A configuração do ambiente de simulação pode ser realizada de duas maneiras, o usuário pode criar o seu próprio script em Python que modela o hardware específico que o usuário deseja, utilizando dos construtores disponíveis da ferramenta ou criando os seus próprios, ou o usuário pode utilizar dos scripts disponibilizados pela ferramenta. Como a ferramenta já oferece uma boa variedade de dispositivos modelados, para os testes realizados nesta monografia foi utilizado o script disponível da ferramenta chamado fs.py, que tem o intuito de realizar a simulação no modo de operação Full System Mode. A simulação então seria executada da seguinte maneira:

build/ARM/gem5.f ast

| {z }

executável de simulação

conf igs/example/f s.py

| {z }

simulation script

...

|{z}

parameters

A grande vantagem da ferramenta é que todo o ambiente de simulação, como hardware, arquitetura, sistema operacional, entre outros, pode ser trocado facilmente. Com isso em mente o ambiente de simulação escolhido para ser testado foi parametrizado com intuito de se assemelhar a uma Raspberry Pi 3 Model B+, placa de desenvolvimento popular e de relativamente fácil aquisição. Para que o ambiente de simulação se assemelhe a uma Raspberry Pi 3 Model B+, exibida na Figura 13, os parâmetros necessários para rodar o script fs.py tem que serem escolhidos de maneira a chegar o mais perto possível do hardware da placa de desenvolvimento.

Figura 13 – Raspberry Pi 3 Model B+.

(40)

• CPU

Como mencionado na introdução da ferramenta, são oferecidos alguns modelos de CPU que visam simular o comportamento de processadores atuais. Um dos modelos mais atuais se trata de um desenvolvido pela própria empresa ARM com intuito de imitar o comportamento de um processador ARMv8 moderno, esse modelo se chama HPI(High

Performance In Order ) e foi o escolhido para os testes realizados, o único problema é que

como se trata de um modelo mais novo, ele ainda tem alguns bugs. O bug que teve que ser contornado na realização dos testes foi que durante a inicialização da simulação, para simulações com mais de um núcleo de processamento, quando se utiliza do modelo HPI a simulação trava. Porém a ferramenta gem5 oferece algumas maneiras de trocar o modelo de CPU sendo utilizado para simulação, para que modelos mais simples sejam utilizados durante a parte do código que não interessa a analise de performance e que os modelos mais adequados sejam usados durante a seção de interesse. A maneira escolhida foi utilizar o parâmetro –restore-with-cpu=HPI que faz com que a simulação inicie com um modelo mais simpliﬁcado de processador, e a partir da criação de um checkpoint quando este for restaurado a simulação estará utilizando o modelo HPI. O modelo HPI oferece o modelo de um processador com execução em ordem e um modelo de pipeline de processadores ARM, como mostra a Figura 14

Figura 14 – Modelo de processador HPI.

Fonte: (TOUSI; ZHU, 2017)

Além do modelo de processador, para se assemelhar a uma Raspberry Pi 3 Model B+ é preciso ajustar o número de núcleos de processamento e a velocidade deles.

(41)

De maneira geral os parâmetros relacionados à CPU do ambiente de simulação são os seguintes:

−−cpu-type=AtomicSimpleCPU −−num-cpus=4 −−cpu-clock=1.4GHz −−restore-with-cpu=HPI

• Memória

Alguns tipos de modelos de memória são disponibilizados pelo gem5, estes mode-los são diferenciados pelo seus níveis de precisão e velocidade da simulação, como mostra a Figura 15. Estes também são diferenciados pelo seus modelos de protocolos de coerência da memória cache.

Figura 15 – Modelos de memória da ferramenta gem5.

Fonte: (BINKERT et al., 2011)

Apesar dos modelos importados da ferramenta GEMS do sistema de memória Ruby serem mais precisos, para os testes realizados foi utilizado o modelo clássico para agilizar o processo de simulação. A ferramenta gem5 oferece alguns dispositivos de me-mória do modelo clássico para os usuários, estes podem ser visualizados com o seguinte comando no terminal no caminho da gem5:

build/ARM/gem5.fast conﬁgs/example/fs.py –list-mem-types

O modelo então escolhido para se assemelhar ao hardware disponível na Raspberry foi o

(42)

Além da memória RAM do sistema, podemos especiﬁcar a memória cache do processador, seus tamanhos de cache de instruções e dados e níveis de memória cache. De maneira geral os parâmetros relacionados à memória do sistema são os seguintes:

−−mem-type=LPDDR2_S4_1066_1x32 −−mem-size=1GB −−caches −−l2cache −−l2_size=512kB −−l1i_size=16kB −−l1d_size=16kB

3.3.4 Kernel e Imagem de Disco para Simulação

Algo necessário para o modo de simulação que é utilizado nestes testes, o Full

System Mode(FS mode), é ter os arquivos de Kernel e uma imagem do disco de um sistema

para a arquitetura de instruções desejada, no caso dos testes realizados nesta monograﬁa a arquitetura ARM. As imagens de kernel e de imagem do disco utilizadas podem ser adquiridas abrindo um novo terminal e seguindo os passos:

1. Para facilitar os trabalhos posteriores, foi criado um destino para os arquivos do

sistema com o seguinte comando:

mkdir fs

2. Movendo o terminal para o novo destino com o comando:

cd fs

3. Para facilitar etapas posteriores foi criada uma variável de caminho similar como

feita na seção 3.3.2 com o comando gedit ~/.bashrc e editando o arquivo de texto com uma nova linha :

export M5_PATH=/home/iago/fs/

4. Adquirindo os arquivos de sistema com a linha de comando no terminal:

wget http://www.m5sim.org/dist/current/arm/aarch-system-20180409.tar.xz

Após o download ter terminado, os arquivos devem ser extraidos com o seguimente co-mando no terminal no caminho de download:

tar xf aarch-system-20180409.tar.xz

Com os arquivo extraídos, podemos escolher os arquivos que serão utilizados para a si-mulação Full System, que precisa de 3 arquivos passados como parâmetros para conseguir inicializar a simulação.

• Imagem do disco, uma cópia de todos arquivos do sistema sendo simulado

(43)

• Arquivo do Kernel, programa responsável por fazer o intermédio entre as aplicações sendo rodadas no sistema operacional e o hardware do sistema.

−−kernel=vmlinux.vexpress_gem5_v1_64

• Arquivo Device Tree Build, utilizado durante a inicialização do sistema para realizar a conﬁguração do hardware.

−−dtb=armv8_gem5_v1_4cpu.dtb

Como a variável de caminho M5_PATH foi criada, não é preciso passar como parâmetro o caminho completo dos arquivos, somente o nome de cada já basta.

Como mencionado na seção 3.3.2, é preciso inserir o arquivo compilado m5 dentro da imagem de disco do sistema operacional para que as vantagens da biblioteca m5op oferece possam ser usufruídas. Fazemos isso seguindo estes passos:

1. Abrir um novo terminal e entrar no caminho onde a imagem de disco se encontra

cd fs/disks

2. Criar o destino para montar a imagem de disco

sudo mkdir /mnt/p1

3. Montar a imagem de disco

sudo mount -o loop,oﬀset=32256 linaro-minimal-aarch64.img /mnt/p1

4. Copiar o arquivo compilado para dentro da imagem de disco montada

sudo cp $GEM5_PATH/util/m5/m5 /mnt/p1/bin/

5. Desmontar a imagem de disco

sudo umount /mnt/p1

Uma das últimas atualizações da ferramenta requer um rápido ajuste nos arquivos obtidos de kernel e imagem de disco. Dentro da pasta binaries devemos criar uma cópia do arquivo boot_emm.arm64 e renomear essa cópia para boot.arm64. Isso precisa ser feito já que uma nova atualização da ferramenta requer um arquivo de bootloader para 64bits com essa denominação.

3.4 Medidas Para Acelerar o Processo de Simulação

É possível acelerar o processo de simulação consideravelmente de algumas ma-neiras, as duas utilizadas nesta monograﬁa foram a modiﬁcação do código fonte do script

(44)

que contêm os executáveis que desejam ser testados, a outra medida utilizada para acele-rar o processo de simulação foi utilizar checkpoints, que removem o tempo de simulação da inicialização do sistema operacional.

3.4.1 Alterações Necessárias para Rodar Simulação com Duas Imagens

É possível alterar o script de maneira que as simulações em Full System Mode rodem com uma imagem adicional que não é montada durante a inicialização do sistema operacional. Isso é uma solução para um problema que os checkpoints apresentam, ape-sar de acelerarem bastante a simulação eles não oferecem um método de importar novos arquivos para dentro da imagem do sistema que foi montada durante a inicialização do sistema operacional. Como a imagem adicional não é montada durante o sistema operacio-nal, podemos altera-la com liberdade, alterando os executáveis de controle ou adicionando novos, e ainda utilizar dos checkpoints.

Primeiramente é preciso construir a imagem que vai ser utilizada nessa alteração, essa imagem deve ser criada no mesmo caminho onde a imagem de disco que vai ser utilizada para a simulação está. A criação da nova imagem pode ser feita então seguindo esses passos:

1. Abrindo um novo terminal e indo para o caminho onde a imagem de disco se

en-contra.

cd $M5_PATH/disks

2. Criando uma imagem com o tamanho desejado, nestes testes foi criada com 4GB.

dd if=/dev/zero of=workloads.img bs=1M count=4096

3. Formatar a imagem criada com a extensão desejada, nos testes realizados foi

utili-zada uma imagem de disco com extensão ext2.

mkfs ext2 -F workloads.img

4. Com a imagem formatada na extensão correta, podemos monta-la com o seguinte

comando:

sudo mount -o loop, workloads.img /mnt/p1

5. Copiar os executáveis que desejamos testar para dentro da imagem

sudo cp (caminho do executável) /mnt/p1

6. E ﬁnalmente desmontar o arquivo de imagem workloads.img

sudo umount /mnt/p1

Em versões anteriores da ferramenta, precisam ser feitas consideráveis mudanças no scripts FSConﬁg.py para que o sistema suportasse duas imagens de disco, porém os

(45)

desenvolvedores atualizaram a ferramenta e no momento da escrita desta monograﬁa agora só é necessário passar um segundo parâmetro de imagem de disco com o comando:

−−disk-image=workloads.img

3.4.2 Criação de Checkpoints

Como mencionado, os checkpoints são um recurso muito útil da ferramenta, tendo resolvido uma de suas limitações com a criação da imagem workloads.img as suas vantagens só aumentam. Normalmente o processo de inicialização da simulação demora um tempo relativamente alto, dependente do poder de processamento da máquina rodando a ferramenta, porém com a criação de checkpoints essa inicialização só precisa ser feita uma vez. Tendo acesso ao terminal de simulação após o setup do sistema operacional podemos criar um checkpoint com o comando m5 checkpoint.

Primeiro é preciso realizar a inicialização da ferramenta, o que geralmente demora uma boa quantidade de tempo e pode ser feita seguindo estes passos:

1. Abrir um novo terminal e se direcionar ao destino da ferramenta:

cd gem5

2. Iniciar a simulação Full System:

build/ARM/gem5.fast conﬁgs/example/fs.py

−−disk-image=linaro-minimal-aarch64.img −−disk-image=workloads.img

−−kernel=vmlinux.vexpress_gem5_v1_64 −−machine-type=VExpress_GEM5_V1 −−dtb=armv8_gem5_v1_4cpu.dtb −−cpu-type=AtomicSimpleCPU −−num-cpus=4 −−mem-type=LPDDR2_S4_1066_1x32 −−mem-size=1GB −−caches −−l2cache −−l2_size=512kB −−l1i_size=16kB −−l1d_size=16kB −−cpu-clock=1.4GHz −−sys-clock=1.4GHz −−restore-with-cpu=HPI

3. Em outro terminal acessar o terminal de simulação.

telnet localhost 3456

Obs: O id para conectar geralmente é 3456, porém em algumas situações pode ser diferente, caso isso aconteça durante a inicialização da ferramenta no terminal onde os parâmetros foram passados a ferramenta informa o id sendo utilizado.

system.terminal: Listening for connections on port 3456

4. No terminal de simulação, esperar o sistema operacional inicializar, que é

identiﬁ-cado quando a seguinte mensagem aparecer:

I N I T : no m o r e p r o c e s s e s l e f t in t h i s r u n l e v e l L a s t l o g i n : Mon Jan 27 0 8 : 0 0 : 0 0 UTC 2 0 1 4 on t t y 1 r o o t @ g e n e r i c a r m v 8 :~#

(46)

5. Podemos então criar o checkpoint com o comando:

m5 checkpoint

5. E ﬁnalizar a simulação com o comando:

m5 exit

Com o checkpoint, podemos restaura-lo facilmente adicionando um comando no ﬁnal do comando de iniciar a simulação indicando a restauração do checkpoint número 1 e mudando o modelo de CPU para HPI, para os testes realizados só foi necessário a criação de um checkpoint porém não há um número limite.

−−cpu-type=HPI −r 1

3.4.2.1 Veriﬁcando a Restauração de Checkpoint com Modelo de CPU Correto

Para verificar que todos os dispositivos foram inicializados corretamente, como por exemplo o modelo selecionado para o processador, é possível verificar, após o término da simulação através do comando m5 exit, o arquivo denominado config.ini. Neste arquivo é possível encontrar todos os dados relativos aos dispositivos inicializados para o ambiente de simulação.

3.4.3 Utilização de scripts

A utilização de shell scripts é opcional porém recomendada para a execução dos testes, com eles podemos de certa maneira automatizar os testes e remover o trabalho repetitivo de montar a imagem com os executáveis, executar os algoritmos sendo testados via linha do terminal de simulação, entre outros. Um exemplo de script é demonstrado na Figura 16, onde é feito a montagem da imagem workloads.img no diretório /mnt, a simulação reseta os dados de performance, roda o executável de controle que se deseja testar e ﬁnaliza o teste.

(47)

Figura 16 – Exemplo de script.

Esses scripts podem ser criados facilmente abrindo o editor de texto básico dis-ponível em distribuições Ubuntu e salvando com a terminação .rcS dentro da pasta do gem5. Para utilizar esses scripts na simulação é preciso passa-los como um parâmetro durante a inicialização da simulação:

−−script=control.rcS

Com o script importado é só preciso digitar a seguinte linha de comando dentro do ter-minal de simulação depois da restauração do checkpoint criado.

m5 readﬁle |sh

• Execução dos Testes

Com todas etapas realizadas, os testes realizados para obtenção dos resultados foram executados com a seguinte linha de comando:

build/ARM/gem5.fast conﬁgs/example/fs.py −−disk-image=linaro-minimal-aarch64.img −−disk-image=workloads.img −−kernel=vmlinux.vexpress_gem5_v1_64

−−machine-type=VExpress_GEM5_V1 −−dtb=armv8_gem5_v1_4cpu.dtb −−cpu-type=HPI −−num-cpus=4 −−mem-type=LPDDR2_S4_1066_1x32 −−mem-size=1GB −−caches −−l2cache −−l2_size=512kB −−l1i_size=16kB

−−l1d_size=16kB −−cpu-clock=1.4GHz −−sys-clock=1.4GHz −−restore-with-cpu=HPI −−script=control.rcS −r 1

(48)

48

4 Algoritmos Testados e Resultados

Apesar de inúmeros algoritmos terem sidos testados, foram escolhidos somente alguns para que a analise de resultados não se torne repetitiva. Além disso é bom ressaltar que os algoritmos tiveram que ser adaptados para poderem ser testados na ferramenta, em seu estados originais os algoritmos recebiam os dados dos sensores através de uma simulação em Gazebo, portanto nos códigos adaptados foi assumido que a thread de sen-soriamento consegue executar de maneira a sempre ter dados atualizados e portanto não causa impacto na performance da thread de controle.

Em relação aos resultados da simulação da ferramenta gem5, a maior parte deles são armazenados após o termino da simulação dentro de um arquivo texto denominado stats.txt dentro da pasta m5out. Trata-se de um arquivo relativamente extenso e de difícil leitura, tendo em média 3 mil linhas de dados por loop de controle.

4.1 vant2load_Hinﬁnity

Esse algoritmo tem como objetivo fazer o controle do VANT demonstrado na Figura 17 realizando o transporte de carga, através de um método de controle misto entre H2 e H∞.

Figura 17 – Protótipo do VANT 2.0.

(49)

Capítulo 4. Algoritmos Testados e Resultados 49

Esse foi um dos algoritmos escolhidos para discussão dos resultados já que não conseguiu ser executado dentro da janela de tempo projetada, neste caso de 12 milisse-gundos, em um ambiente de simulação com conﬁgurações similares a uma Raspberry Pi 3 Model B+.

4.1.1 Discussão dos Resultados da Simulação

O algoritmo foi adaptado para executar 50 loops de controle e ao menos no quesito temporal podemos notar que se simulação for feita usando conﬁgurações similares a uma Raspberry Pi 3 Model B+ ela é incapaz de executar o código dentro do período de amostragem de 12 milissegundos estipulado para o controle. É possível constatar isso veriﬁcando a variável sim_seconds dentro do arquivo stats.txt, a primeira execução do controle tem um tempo de execução de 52 milissegundos e após 50 iterações do controle o tempo médio cai para aproximadamente 34 milissegundos. Além disso é possível visualizar o tempo que cada iteração de controle leva para ser simulada pela ferramenta com o computador utilizado, sendo que a média para esse algoritmo foi de 49,5 segundos.

• sim_seconds 0.052865 # Number of seconds simulated • host_seconds 49.50 # Real time elapsed on the host

No quesito de uso de CPU, é possivel visualizar nos resultados gerados que apesar do ambiente de simulação ter 4 núcleos de processamento disponiveis, como o código não foi estruturado com uma visão multitarefa apenas há a utilização de um núcleo durante a simulação, nos resultados encontrado foi a cpu2, como podem ser visto por esses resultados de uma das iterações do laço de controle.

• system.cpu0.numCycles 0 # number of cpu cycles simulated • system.cpu1.numCycles 0

• system.cpu2.numCycles 46 834 046 • system.cpu3.numCycles 0

Com os dados relacionados a CPU também já podemos notar algo de estranho na per-formance desse algoritmo, já que dos 46 834 046 ciclos do núcleo cpu2 simulados, em 21 055 885 a cpu2 esteve em modo idle ou seja parado esperando alguma informação, cerca de 45% dos ciclos de CPU simulados, muito provavelmente por causa da leitura lenta dos dados da memória RAM, que teve alta utilização neste algoritmo.

(50)

Capítulo 4. Algoritmos Testados e Resultados 50

• system.cpu2.idleCycles 21 055 885 (45% dos ciclos simulados) • system.cpu2.numCycles 46 834 046

Ainda sobre a CPU, é possível veriﬁcar os tipos de instruções executadas durante a simu-lação do algoritmo de controle.

• system.cpu2.op_class_0::IntAlu 13085008 79.21% • system.cpu2.op_class_0::IntMult 92896 0.56% • system.cpu2.op_class_0::MemRead 1552229 9.40% • system.cpu2.op_class_0::MemWrite 1789706 10.83%

Também podemos veriﬁcar que a memória cache do sistema esteve ocupada durante toda a simulação, sendo que a percentagem de 1 signiﬁca 100%.

• system.iocache.tags.occ_percent::total 1 # Average percentage of cache occupancy • system.cpu2.icache.tags.occ_percent::total 1

• system.cpu2.dcache.tags.occ_percent::total 1

Além disso também podemos ver que o segundo nível de cache teve sua maior uti-lização para armazenar instruções da cpu2, além de ter sido também ocupado totalmente durante a simulação

• system.l2.tags.occ_percent::.cpu2.inst 0.980486 • system.l2.tags.occ_percent::.cpu2.data 0.012194

Enquanto a memória cache teve uma utilização tao alta durante a simulação, a memória RAM teve um acesso relativamente baixo de 9%, aonde a grande maioria das solicitações de leitura também foram para instruções da cpu2.

• system.mem_ctrls.busUtil 9.00 # Data bus utilization in percentage

• system.mem_ctrls.num_reads::.cpu2.inst 197 233 # Number of read requests res-ponded to by this memory