Plano de Tese de Doutorado - cin.ufpe.brbopp/bopp-saap-2012-1.pdf · Universidade Federal de...

Universidade Federal de PernambucoCentro de Informática

Grupo de Engenharia da Computação

Plano de Tese de Doutorado

Título:Construção e geração de software dependente de hardware de

modelos de sistema de alto nível

Orientando: Bruno Otávio Piedade PradoOrientadora: Profa. Dra. Edna Natividade da Silva Barros

Recife, 3 de Março de 2012

Sumário

1 Introdução.............................................................................................................................. 5

1.1 Motivação e justificativa................................................................................................. 6

1.2 Resumo do Estado da Arte............................................................................................. 7

1.3 Objetivos do trabalho....................................................................................................10

1.4 Estrutura do documento...............................................................................................10

2 Estado da Arte.......................................................................................................................11

2.1 Systematic Embedded Software Generation from SystemC[6]...................................11

2.2 Multi-Processor SoC Design Methodology using a Concept of Two-Layer Hardware-

dependent Software[8]........................................................................................................13

2.3 A Generic RTOS Model for Real-time Systems Simulation with SystemC[9]............15

2.4 Embedded Software Generation from System Level Design Languages[10].............16

2.5 Combination of Instruction Set Simulator and Abstract RTOS Model Execution for

Fast and Accurate Target Software Evaluation[11]............................................................ 17

2.6 Automatic Generation of Hardware dependent Software for MPSoCs from Abstract

System Specifications[12]................................................................................................... 18

2.7 Software Performance Simulation Strategies for High-level Embedded System

Design[13]............................................................................................................................19

2.8 A Design Flow Based on a Domain Specific Language to Concurrent Development of

Device Drivers and Device Controller Simulation Models[14]..........................................21

3 Proposta do Trabalho.......................................................................................................... 23

3.1 Descrição do problema.................................................................................................23

3.2 Abordagem proposta....................................................................................................23

3.3 Validação da proposta..................................................................................................26

4 Resultados obtidos.............................................................................................................. 26

5 Cronograma......................................................................................................................... 28

Bibliografia...............................................................................................................................33

Assinaturas.............................................................................................................................. 34

Índice de figuras

Figura 1: Lei de Moore...............................................................................................................5

Figura 2: Análise de capacidade e produtividade de HW e SW[3]..........................................6

Figura 3: Representação dos processos...................................................................................11

Figura 4: Fluxo de geração de código HW/SW.......................................................................12

Figura 5: Abstração de plataforma (hardware).......................................................................13

Figura 6: Abstração de sistema (SoC)..................................................................................... 14

Figura 7: Modelagem das tarefas e do RTOS.......................................................................... 15

Figura 8: Fluxo de desenvolvimento.......................................................................................16

Figura 9: Combinação de ISS com modelo de RTOS..............................................................17

Figura 10: Fluxo de desenvolvimento HdS.............................................................................18

Figura 11: Abordagem do trabalho de estimativa de desempenho........................................20

Figura 12: Estágios de desenvolvimento de HdS....................................................................21

Figura 13: Fluxo de desenvolvimento da abordagem proposta............................................. 25

Índice de tabelas

Tabela 1: Cronograma de atividades 2009 - 2010................................................................. 28

Tabela 2: Cronograma de atividades 2010 - 2011.................................................................. 29

Tabela 3: Cronograma de atividades 2011 - 2012................................................................... 31

Tabela 4: Cronograma de atividades 2012 – 2013................................................................. 32

Introdução GrecO - CIn/UFPE

1 Introdução

A importância de software embarcado tem crescido significativamente, devido

principalmente a sua flexibilidade, capacidade de adaptação rápida e possibilidade de

mudanças ou atualizações posteriores. Entretanto, para que estes sistemas possam

funcionar adequadamente são necessárias grandes porções de código de interface com o

hardware e complexa infraestrutura de carregamento, escalonamento de tarefas e pilhas de

protocolos de comunicação (software dependente de hardware ou HdS[1]).

Figura 1: Lei de Moore

E com o contínuo aumento da complexidade das plataformas, como foi previsto pela Lei de

Moore[2], criam-se novas possibilidades para funcionalidades que tem mais poder

computacional e memória disponível. Contudo, para os sistemas embarcados sempre

existem limitações de potência e memória devido a sua natureza de mobilidade, de baixo

custo e de baixa potência.

Construção e geração de software dependente de hardware de modelos de sistema de alto nível Página 5 de 34


Figura 2: Análise de capacidade e produtividade de HW e SW[3]

Apesar de suas restrições naturais, o software embarcado cresce exponencialmente, tendo

seu tamanho aumentado de 10 vezes em 5 anos[4]. A figura 2 ilustra bem como é grande a

diferença entre a capacidade de produção de software e a sua produtividade.

1.1 Motivação e justificativa

A principal motivação deste trabalho é sem dúvida a redução da diferença entre as taxas de

crescimento do software e da capacidade com que ele pode ser produzido (System Design

Gap, ver figura 2), desta forma tornando o desenvolvimento de software mais eficiente.

Para atingir esta melhoria na produtividade de software embarcado, serão utilizados

recursos que proporcionem abstração ao desenvolvedor e projetista, permitindo que uma

maior quantidade de funcionalidades possam ser implementadas mais facilmente. Outro

ponto importante são as simulações do sistema que, utilizando-se de simuladores de



instrução (Instruction Set Simulator ou ISS)[5], que mesmo em níveis funcionais,

representam um gargalo durante o desenvolvimento, consumindo longos períodos de

simulação. Para melhorar significativamente o desempenho das simulações e ainda sim

permitir um maior nível de abstração do sistema, serão utilizados modelos executáveis

descritos em uma linguagem de descrição de sistemas. Este modelos permitem um

aumento significativo da velocidade de simulação, além que ser implementado em alto

nível de abstração.

Por fim, como já foi dito anteriormente, as restrições são naturais nos sistemas

embarcados e, por isso, é importante que o código gerado seja sempre o menor possível

para seja utilizado menos memória e se dissipe menos potência.

1.2 Resumo do Estado da Arte

Para consolidação desta proposta de trabalho, foi realizada uma extensa pesquisa sobre

sistemas embarcados e que oportunidades para melhorias ainda estavam disponíveis, além

de considerar as oportunidades de melhoria das soluções existentes.

De forma a tornar mais sistemática e simples a leitura, os trabalhos serão listados em

tópicos e em ordem cronológica com informações resumidas, como se observa a seguir:

• Systematic Embedded Software Generation from SystemC[6]

◦ Autores: F. Herrera, H. Posadas, P. Sánchez e E. Villar;

◦ Instituição: University of Cantabria;

◦ Ano e publicador: 2003, DATE;

◦ Descrição: modelo executável do sistema em SystemC[7], com abstração do

RTOS (Real Time Operating System), permitindo particionamento

hardware/software, cosimulação e geração de código.

• Multi-Processor SoC Design Methodology using a Concept of Two-Layer

Hardware-dependent Software[8]

◦ Autores: S. Yoo, M. Youssef, A. Bouchhima e A. Jerraya;



◦ Instituição: TIMA Laboratory e ST Microelectronics;


◦ Descrição: duas camadas de abstração, uma para abstração do hardware

(Hardware Abstraction Layer ou HAL) para mudanças locais de arquitetura e

uma para abstração do SoC (SoC Abstraction Layer ou SAL) através da definição

de API padrão.

• A Generic RTOS Model for Real-time Systems Simulation with

SystemC[9]

◦ Autores: R. Moigne, O. Pasquier e J-P. Calvez;

◦ Instituição: University of Nantes;


◦ Descrição: modelo genérico de RTOS implementado em SystemC que possua

restrições temporais e que permita a redução do tempo de projeto, através de

modelagem de escalonamento e tempo.

• Embedded Software Generation from System Level Design

Languages[10]

◦ Autores: H. Yu, R. Dömer e D. Gajski;

◦ Instituição: University of California;

◦ Ano e publicador: 2004, IEEE;

◦ Descrição: geração de software embarcado (ANSI C) automaticamente a partir

de sistemas em linguagens de descrição de sistemas (SystemC, SpecC, etc) para

RTOS POSIX, suportando concorrência e comunicação.

• Combination of Instruction Set Simulator and Abstract RTOS Model

Execution for Fast and Accurate Target Software Evaluation[11]

◦ Autores: M. Krause, D. Englert, O. Bringmann e W. Rosenstiel;



◦ Instituição: FZI Informatik e Universität Tübingen;

◦ Ano e publicador: 2008, CODES+ISSS;

◦ Descrição: combinação de simulação a nível de instrução (ISS) com emulação de

RTOS para redução do tempo de simulação, mantendo alto nível de precisão de

resultados.

• Automatic Generation of Hardware dependent Software for MPSoCs

from Abstract System Specifications[12]

◦ Autores: G. Schirner, A. Gerstlauer e R. Dömer;

◦ Instituição: University of California;

◦ Ano e publicador: 2008, IEEE;

◦ Descrição: geração automática de software embarcado com driver,

gerenciamento de interrupção, código de inicialização e suporte ou não a RTOS

que é simulado por ISS padrão.

• Software performance simulation strategies for high-level embedded

system design[13]

◦ Autores: Zhonglei Wang e Andreas Herkersdorf;

◦ Instituição: Technische Universität Müchen;

◦ Ano e publicador: 2009, Elsevier;

◦ Descrição: análise de desempenho do sistema através de anotação de

informações sobre o código gerado para um determinado processador,

permitindo que o mesmo seja executado nativamente com alto desempenho e

precisão.

• A Design Flow Based on a Domain Specific Language to Concurrent

Development of Device Drivers and Device Controller Simulation

Models[14]



◦ Autores: Edson Lisboa, Luciano Silva, Igino Chaves, Thiago Lima e Edna Barros;

◦ Instituição: Universidade Federal de Pernambuco;

◦ Ano e publicador: 2009, SCOPES;

◦ Descrição: modelagem e simulação de driver em linguagem de domínio

específico (DevC), além de síntese deste modelo de alto nível para geração do

controlador do dispositivo e do driver.

1.3 Objetivos do trabalho

Este trabalho tem como objetivo melhorar significativamente a produtividade e a

velocidade das simulações de sistemas embarcados (software dependente de hardware ou

HdS), para tanto este trabalho propõe um modelo para desenvolvimento e simulação em

alto nível, descrito em uma linguagem de descrição de sistemas, que será automaticamente

sintetizado em um conjunto de componentes de software. Desta forma, espera-se que todo

os componentes de software gerados, uma vez compilados e carregados em um

determinado processador executem fielmente o comportamento exibido pelo modelo.

1.4 Estrutura do documento

A estrutura deste documento é definida pelo primeiro capítulo de Introdução, onde uma

visão geral e concisa da proposta é oferecida; o segundo capítulo de Estado da Arte detalha

todas as soluções ou conjunto de técnicas e metodologias associadas ou relacionadas a este

trabalho; o terceiro capítulo de Proposta de Trabalho define que problema será atacado,

que abordagem será utilizada para isto e qual será o fluxo proposto; no quarto capítulo o

cronograma de atividades por ano é exibido, com granularidade mensal; e por fim o índice

bibliográfico e as assinaturas do orientando e orientador da tese.


Estado da Arte GrecO - CIn/UFPE

2 Estado da Arte

Neste capítulo o Estado da Arte será detalhado e todos os aspectos e contribuições

observados em cada um dos trabalhos serão destacados, como forma de facilitar ao leitor

que conceitos foram utilizados na concepção deste trabalho.

2.1 Systematic Embedded Software Generation from SystemC[6]

Este trabalho tem como objetivo a redução do custo de construção de sistemas embarcados

através da geração de software embarcado a partir de modelos em SystemC que permite

modelagem de alto nível. Após o particionamento HW/SW, as interfaces de comunicação

são geradas e o mapeamento para o sistema operacional escolhido pelo usuário é realizado.

Figura 3: Representação dos processos

Um dos pontos mais interessantes deste trabalho está na modelagem dos processos, como

pode ser visto na figura 3, onde os nós representam eventos e as arestas representam os



trechos de código que executam sem bloqueio. Esta representação é a forma como o

escalonador de SystemC trata a execução de suas tarefas, o que facilita bastante o

mapeamento do modelo para a estrutura da interna de representação.

Figura 4: Fluxo de geração de código HW/SW

O fluxo de geração de código deste trabalho é ilustrado na figura 4, onde existem três

níveis fundamentais de trabalho: especificação, algorítmico e geração de software. Na

etapa de especificação, a descrição sem particionamento é implementada e simulada

utilizando os recursos padrões de SystemC. Após a finalização desta etapa, é realizado o

particionamento do hardware e do software, onde o software executará sobre uma

infraestrutura de mapeamento do SystemC para o RTOS (precisa ser implementada) e o

hardware executa sobre o SystemC padrão. Após a finalização destas primeiras etapas, o

software é gerado em C/C++ padrão que irá executar em hardware e RTOS definido pelo



usuário.

Para validação e obtenção de resultados, foi utilizado um processador ARM7TDMI e o

RTOS eCos, como infraestrutura de hardware e software respectivamente. Foi

desenvolvida uma aplicação de ABS (Anti-lock Braking System) que ocupou cerca de 4.1

Kb de memória dos 68.7 Kb totais do projeto, ou seja, boa parte da memória foi ocupada

pelo RTOS, pelo sistema de gerenciamento de memória dinâmica e pelos canais de

comunicação entre os processos. O autor ressalta que apesar do gasto extra com a

comunicação (11.4 Kb de código), a vantagem de ter um sistema desenvolvido

independente de RTOS é muito relevante.

2.2 Multi-Processor SoC Design Methodology using a Concept of Two-Layer Hardware-dependent Software[8]

As ideias principais deste trabalho consistem em abstrair mudanças no hardware da

plataforma, como barramento ou periféricos (abstração de hardware) e abstrair mudanças

no sistema em chip ou SoC (System-on-Chip) que são mais globais, normalmente se

tratando de subsistemas.

Figura 5: Abstração de plataforma (hardware)

A abordagem de abstração de hardware (HAL) consiste em definir uma interface padrão

(HAL API) que será utilizada pelo software da aplicação, sendo que todos os aspectos

específicos da plataforma, como tipo de processador ou dispositivo, serão tratados

exclusivamente pela HAL1 e HAL2, como é ilustrado na figura 5. Desta forma, evita-se

mudanças no domínio da aplicação, o que além de reduzir o custo no caso de migração de



plataforma, ainda assegura menores taxas de inserção de erros.

Figura 6: Abstração de sistema (SoC)

De maneira análoga à abstração de plataforma, também existe a abstração de sistema

(SAL) que consiste em definir para a aplicação de software uma interface padrão (SAL API)

de forma a permitir o acesso aos demais subsistemas, como pode ser visto na figura 6. Com

a SAL (SoC Abstraction Layer), a aplicação fica imune à mudanças em subsistemas,

permitindo maior escalabilidade e robustez do SoC.

A validação e coleta de informações foi feita através do estudo de caso OpenDIVX (sistema

de codificação) em uma plataforma multiprocessada, obtendo um código extra (devido a

HAL e SAL) de somente 6.3 Kb e 5.7 Kb, respectivamente, de um total de 715 Kb de código

de aplicação. Além de fornecer abstração, este trabalho também possibilitou a simulação a

nível de API, ou seja, emulando o funcionamento da interface sem que o hardware precise

ser de fato simulado. Com esta emulação, o software obteve um aumento de 3.5 até 17

vezes no seu desempenho de simulação, com até 86% de precisão, quando comparado ao

hardware simulado.



2.3 A Generic RTOS Model for Real-time Systems Simulation with SystemC[9]

Este trabalho busca facilitar o desenvolvimento de sistemas de tempo real através da

utilização de um sistema operacional de tempo real genérico (RTOS) baseado em SystemC,

que permite análise de tempo e da influência do escalonamento (políticas, tempo de troca

de contexto e latência).

Figura 7: Modelagem das tarefas e do RTOS

Através da definição dos tempos de escalonamento, carregamento de contexto e

armazenamento de contexto, são feitas as análises de tempo durante a simulação. Sendo

que cada um destes parâmetros de tempo são ativados na mudança de estado das tarefas,

como do RTOS, como pode ser observado na figura 7.

A validação e análise dos resultados foi feita com um sistema de tarefas simples e um timer

em hardware, sendo que os resultados das trocas de contexto podem ser observadas

graficamente através de uma ferramenta também desenvolvida por este trabalho. Toda a



infraestrutura de simulação roda em cima de SystemC, sem modificações na linguagem, o

que além de elegante permite uma flexibilidade na exploração de espaço de projeto, além

de excelente desempenho nas simulações.

2.4 Embedded Software Generation from System Level Design Languages[10]

Para melhorar a capacidade de produção de software embarcado, este trabalho propõe a

utilização de linguagens de descrição a nível de sistema (SLDL) que permite a construção

de modelos de sistema em maior nível de abstração. A ideia principal é gerar software

(ANSI C) automaticamente a partir destes modelos de alto nível, através de refinamentos e

passos intermediários suportados por ferramenta.

Figura 8: Fluxo de desenvolvimento

O fluxo de desenvolvimento deste trabalho pode ser visto na figura 8, sendo composto

pelas etapas principais de especificação do modelo, modelagem a nível de transações e



implementação do modelo.

Para análise de resultados e validação do trabalho, foi implementado um modelo de um

codificador de voz (VOCODER) em SpecC e foi utilizado o RTOS µC/OS-II, atingindo um

tamanho total de 75 Kb. A principal contribuição deste trabalho está na geração

automática de software a partir de um modelo de especificação, o que reduz as chances de

erros e unifica as versões de alto nível e de implementação.

2.5 Combination of Instruction Set Simulator and Abstract RTOS Model Execution for Fast and Accurate Target Software Evaluation[11]

A proposta deste trabalho consiste em combinar a alta precisão dos simuladores de

instrução (ISS) com o alto desempenho da emulação de RTOS que funcionam

cooperativamente. Com isso, consegue-se reduzir significativamente o tempo de

simulação, com baixíssima perda de precisão (inferior a 0.3%).

Figura 9: Combinação de ISS com modelo de RTOS

Uma visão geral da abordagem pode ser observada na figura 9, onde existem duas

unidades básicas: o ISS (realiza execução do programa) e o modelo de RTOS que se

utilizando do escalonador de SystemC coordena as trocas de contexto das tarefas que

executam no processador. Sem dúvida a parte crucial deste trabalho se concentra na



comunicação entre o ISS e o modelo RTOS, permitindo inclusive que operações dinâmicas

sejam realizadas, como criação e remoção de tarefas em tempo de execução, tudo

ocorrendo de forma desacoplada.

Os resultados experimentais demonstram o baixo índice de erro da abordagem,

ressaltando os ganhos em termos de tempo de simulação que foram bem menores. Mais

uma vez, o objetivo deste trabalho é permitir ao projetista um ambiente de avaliação de

decisões de projeto, de forma precisa e eficiente.

2.6 Automatic Generation of Hardware dependent Software for MPSoCs from Abstract System Specifications[12]

Seguindo a linha de modelos de especificação abstratos , este trabalho propõe a geração

automática de software dependente de hardware (HdS) que sofre de forte acoplamento.

Além da geração de código HdS de um modelo abstrato, o trabalho também propõe a

geração de driver, gerenciador de interrupção e código de inicialização, suportando ou não

RTOS. Sem o suporte de RTOS, as tarefas são escalonadas através de implementação

baseada em interrupção, o que reduz significativamente o tamanho de código gerado.

Figura 10: Fluxo de desenvolvimento HdS

Como pode ser visto na figura 10, a especificação do sistema é feita em nível de sistema,

utilizando-se a linguagem SystemC que permite análise comportamental através de

execução. Após feita esta análise, é realizado o particionamento HW/SW, até que as



restrições do projeto sejam atendidas de forma satisfatória, através de sucessivas

simulações e refinamentos. Por fim, tanto o hardware necessário é gerado como o software

que está acoplado a ele também, permitindo um rápido desenvolvimento e reduzida

chance de erros.

Para suportar o escalonamento de tarefas, duas opções podem ser realizadas: utilização de

RTOS (camada de abstração de RTOS ou RAL) que necessitará de mapeamento com o

sistema operacional escolhido ou escalonamento baseado em interrupção que é muito

adequado em sistemas com fortes restrições de memória, processamento digital de sinais

ou poucas tarefas.

Para obtenção de resultados e validação do trabalho, seis estudos de caso foram realizados,

entre eles um codificador JPEG e um decodificador MP3, mostrando decisões de

particionamento e resultados de número de ciclos de CPU e número de interrupções

gerados.

2.7 Software Performance Simulation Strategies for High-level Embedded System Design[13]

Este trabalho destoa levemente dos objetivos apresentados pelo trabalhos anteriores, por

focar em uma solução engenhosa para medição de desempenho de software embarcado.

Isto é feito sem de fato precisar realizar a simulação em um ISS que muito lentos e muito

difíceis de se desenvolver. Através da execução nativa em um computador pessoal e com a

extração de informações de instruções geradas para a plataforma destino é possível gerar

um modelo de simulação extremamente eficiente em termos de tempo de simulação e com

alta precisão de estimativa de desempenho, além de baixa complexidade de

implementação.



Figura 11: Abordagem do trabalho de estimativa de desempenho

A ideia geral do trabalho é resumida na figura 11, onde o código fonte é processado para

obtenção de uma representação intermediária. Na etapa de instrumentação, o código

gerado é anotado com informações de mapeamento e análise de tempo. Com este formato

de representação instrumentado, o código é compilado para execução nativa e com as

informações anotadas em seu código é capaz de fornecer estimativas sobre desempenho

para a plataforma para qual será implantado.

Para validação da abordagem foram implementados vários estudos de caso que tiveram

suas análises realizadas do modo tradicional com ISS e com a abordagem proposta. O

resultado foi que as estimativas tiveram taxas de erros muito baixas (inferiores a 3%), com

taxas de MIPS muito maiores.



2.8 A Design Flow Based on a Domain Specific Language to Concurrent Development of Device Drivers and Device Controller Simulation Models[14]

Este trabalho tem como objetivo fornecer um ambiente para desenvolvimento de software

dependente de hardware (HdS), através de uma linguagem de domínio específico (DevC)

para simulação e geração de código de driver e controlador de dispositivo. O objetivo

principal é reduzir o esforço para o desenvolvimento de software básico, reduzindo

também as chances de erros durante o desenvolvimento.

Figura 12: Estágios de desenvolvimento de HdS

Os estágios deste trabalho estão ilustrados na figura 12, perfazendo um total de 6 estágios

que são:



• Estágio 1: é feita a descrição do sistema operacional, do dispositivo que será

utilizado e das funcionalidades disponíveis na plataforma;

• Estágio 2: ocorre o particionamento do hardware (controlador) e do software

(driver em C);

• Estágio 3: o controlador gerado é integrado a plataforma virtual existente;

• Estágio 4: a plataforma virtual contendo o controlador gerado é compilada e está

pronta para receber o software gerado compilado;

• Estágio 5: o software gerado funciona juntamente com o controlador, executando

sobre a plataforma virtual e gerando resultados;

• Estágio 6: por fim, o software gerado é executado no hardware real e tem seus

resultados comparados aos obtidos pela plataforma virtual.

Para validação da proposta foram utilizados dois dispositivos: serial e LCD gráfico, de

forma a demonstrar a eficácia da abordagem, verificando quanto trabalho manual precisou

sr feito e quando do código foi gerado pela ferramenta. A principal vantagem deste

trabalho está na redução do esforço de desenvolvimento de HdS, através de

desenvolvimento gradual e facilidades de depuração do comportamento.


Proposta do Trabalho GrecO - CIn/UFPE

3 Proposta do Trabalho

Este capítulo é destinado a descrever em detalhes os objetivos propostos, baseando-se

fortemente no estado da arte considerado e procurando contribuir positivamente em

pontos que oferecem oportunidades de melhoria.

3.1 Descrição do problema

Os problemas que serão abordados por este trabalho são:

• O grande aumento de complexidade do software embarcado, que vem tornando

simulações a nível de instruções inviáveis, além do fato dos ISS serem bastante

complexos de serem criados;

• Maior complexidade e funcionalidades levam a utilização de sistemas operacionais

para acelerar e facilitar o desenvolvimento de sistemas multitarefas, que leva ao

problema de escolher qual o sistema operacional mais adequado ainda na etapa de

exploração de arquitetura;

• Falta de suporte a nível de simulação nativa para desenvolvimento de software

dependente de hardware (HdS) que permita precisão a nível de registrador,

combinada com alto nível de abstração e desempenho.

3.2 Abordagem proposta

A proposta para este trabalho consiste em proporcionar um ambiente para simulação de

software embarcado de alto desempenho e precisão, através das seguintes funcionalidades:

• Simulação nativa do software embarcado, ao invés do uso de simuladores de

instrução (ISS), que além de mais rápido, permite maior liberdade para escolha de

que processador é mais adequado;

• Geração de camada de emulação de plataforma (a partir de uma especificação da

plataforma), contendo todas as informações, a nível de registradores, sobre os



componentes da plataforma, permitindo que software dependente de hardware

(HdS) possa ser desenvolvido com precisão e rapidez de simulação;

• Desenvolvimento da aplicação em nível de sistema, utilizando-se a linguagem

SystemC, provendo ao desenvolvedor abstração e com isso reduzindo a chance de

erros;

• Geração de software com suporte à multitarefas da aplicação através de uma

interface padrão de abstração de sistema operacional (Operating System

Abstraction Layer ou OSAL), permitindo que a aplicação seja portada para executar

no sistema operacional que seja mais adequado;

• Abstração do sistema de interrupção do processador escolhido através da adoção de

uma camada padrão de abstração de interrupção (Interruption Handling

Abstraction Layer ou IHAL), que possibilitará o mapeamento da aplicação em

processadores com diversos esquemas de interrupção.



Figura 13: Fluxo de desenvolvimento da abordagem proposta

Na figura 13, pode-se ter uma visão geral do fluxo da abordagem proposta, onde, de

maneira transparente e correta por construção, o software, com suas camadas de abstração

de sistema operacional e de gerenciamento de interrupção, é gerado em ANSI C, podendo

ser compilado juntamente com o sistema operacional escolhido para o processador de

destino.

A principal contribuição deste trabalho é sem dúvida a capacidade criar rapidamente

aplicações com software dependente de hardware (HdS), com tempos de simulação bem

mais curtos e com precisão de registradores. Além de permitir que exista uma abstração de

qual sistema operacional poderá ser utilizado, através da camada de abstração de sistema

operacional (OSAL) e abstração do gerenciamento de interrupções do processador, através

da camada de abstração de interrupção (IHAL).



3.3 Validação da proposta

Para a validação da proposta deste trabalho, serão feitos estudos que caso que explorem

efetivamente os problemas apresentados, com o objetivo de demonstrar a eficácia desta

solução. Para tanto, será utilizado 0 modelo ISS[5] de processador SPARC-V8 com dois

periféricos (Timer, RTC, etc). As plataformas montadas explorarão as capacidades de

configuração via registradores e geração de interrupções.

O propósito desta combinação é demonstrar que uma aplicação multitarefa modelada em

nível de sistema, pode ser simulada e verificada amplamente em nível de sistema e depois

ser gerado código para produção de maneira automatizada.

Para fins comparativos, serão analisados os seguintes aspectos:

• Tempos de simulação em alto nível e o tempo de simulação em ISS, para mostrar

quantas vezes mais rápida é a solução proposta;

• Medição do erro associado pela abstração do modelo proposto em comparação com

o modelo ISS preciso;

• Medir os tempos de desenvolvimento e tamanhos de código gerado utilizando a

abordagem proposta e a abordagem tradicional, quantificando o ganho de

produtividade e memória disponível.

4 Resultados obtidos

Foi implementada uma infraestrutura completa de simulação hardware e software

integrada que permitiu a execução de estudos de caso de classe industrial como Dhrystone,

Coremark e Mibench para avaliação de desempenho e erro de simulação obtidos.

Apesar de terem sido obtidos resultados preliminares, este trabalho obteve uma melhoria

da ordem de 1000 vezes o desempenho, quando comparado a abordagem tradicional ISS,

mantendo taxas de erro inferiores a 3%. Desta forma, apresenta uma sólida contribuição

ao estado da arte considerado, apresentando uma nova abordagem para tratar o difícil

desenvolvimento de hardware e software integrados.


Resultados obtidos GrecO - CIn/UFPE

Um dos primeiros resultados externos deste trabalho foi a sua aceitação para publicação e

apresentação na Symposium on Integrated Circuits and Systems Design (SBCCI) no ano de

2011, sendo escolhido como um dos melhores trabalhos para ter uma oportunidade de

publicação estendida no Journal of Integrated Circuits and Systems (JICS) neste ano de

2012.

Os feedbacks internos e externos obtidos estão sendo utilizados para refinar este trabalho,

além de vislumbrar novas publicações e ainda mais aceitação do meio acadêmico.


5 Cronograma

O cronograma, ilustrado nas tabelas a seguir, mostra quais serão as macro atividades, suas respectivas durações e suas intersecções com

as outras atividades e seus detalhes.

Cronograma 2009 - 2010

Atividades

Ma

rç

o

Ab

ri

l

Ma

io

Ju

nh

o

Ju

lh

o

Ag

os

to

Se

te

mb

ro

Ou

tu

br

o

No

ve

mb

ro

De

ze

mb

ro

Ja

ne

ir

o

Fe

ve

re

ir

o

Disciplinas necessárias para completar a carga horária

Análise de trabalhos relacionados e estado da arte

Concepção do trabalho, definição do problema e solução proposta

Tabela 1: Cronograma de atividades 2009 - 2010

Como pode ser visto na tabela 1, as atividades do primeiro ano do doutorado são estruturais e fundamentam todas as demais atividades

que serão desenvolvidas nos demais anos. A seguir é feito um detalhamento destas atividades:

• Disciplinas necessárias para completar carga horária: os 6 primeiros meses de doutorado foram dedicados à disciplinas

de suporte, como algoritmos e arquiteturas multiprocessadas, onde já procurou observar oportunidades de uso de ferramentas

para auxiliar o desenvolvimento deste trabalho;

• Análise de trabalhos relacionados e estado da arte: etapa que foi iniciada com o final do período de aulas, contando com

pesquisas extensas sobre trabalhos relacionados a área de interesse (HdS), suas oportunidades e limitações. Além de verificar o

que existe e o que pode ser feito, nesta atividade também foi avaliado a viabilidade das possíveis propostas, para que fosse evitado

trabalhos excessivamente complexos ou até mesmo fora dos objetivos acadêmicos;

• Concepção do trabalho, definição do problema e solução proposta: uma vez tendo uma visão ampla de como é o estado

da arte, foram realizadas reuniões com o intuito de deixar claro quais os problemas carecem de solução adequada ou se existem

oportunidades de melhoria em abordagens já existentes. Uma vez estando bem definidos os cenários, foram propostas soluções

que foram refinadas até que este solução proposta fosse concebida.


Atividades

Ma

rç

o

Ab

ri

l

Ma

io

Ju

nh

o

Ju

lh

o

Ag

os

to

Se

te

mb

ro

Ou

tu

br

o

No

ve

mb

ro

De

ze

mb

ro

Ja

ne

ir

o

Fe

ve

re

ir

o

Criação de infraestrutura, ferramentas e ambiente

Implementação e análise dos estudo de caso

Validação dos experimentos e estudos de caso realizados

Preparação e elaboração dadefesa da tese


Como pode ser observado na tabela 2, neste segundo ano do doutorado as atividades se concentram em criar a infraestrutura necessária,

implementando também os estudos de caso e realizando suas validações e coletas de resultados. O detalhamento destas atividades é feito

a seguir:

• Criação de infraestrutura, ferramentas e ambiente: esta atividade se destina a construção de um ambiente completo de

desenvolvimento e depuração de todas as ferramentas necessárias para suportar os requisitos desta proposta de trabalho. Este

ambiente é composto, por exemplo, de linguagens de programação, compiladores, sistemas operacionais e bibliotecas de terceiros.

O objetivo desta atividade é gerar todo o conjunto de ferramentas que permitam a realização e análise dos estudos de caso que

serão implementados;

• Implementação e análise dos estudos de caso: uma vez consolidada, mesmo que parcialmente, o ambiente de

desenvolvimento, a implementação e análise dos estudos de caso pode ser realizada. Esta etapa servirá como verificação do

ferramental criado e geração de correções para as falhas detectadas;

• Validação dos experimentos e estudos de caso realizados: em consonância com a sua implementação, os estudos de caso

estão sendo avaliados para que sua eficácia seja garantida, além da geração de implementações que seguem fluxos tradicionais que

serão utilizadas para fins comparativos;

• Preparação e elaboração da proposta de tese: preparação para defesa da tese de doutorado e apresentação para a banca.


Atividades

Ma

rç

o

Ab

ri

l

Ma

io

Ju

nh

o

Ju

lh

o

Ag

os

to

Se

te

mb

ro

Ou

tu

br

o

No

ve

mb

ro

De

ze

mb

ro

Ja

ne

ir

o

Fe

ve

re

ir

o

Publicação de artigos e participação em congressos


Estruturação, edição e revisão da tese

Preparação e elaboração daproposta de tese



Atividades

Ma

rç

o

Ab

ri

l

Ma

io

Ju

nh

o

Ju

lh

o

Ag

os

to

Se

te

mb

ro

Ou

tu

br

o

No

ve

mb

ro

De

ze

mb

ro

Ja

ne

ir

o

Fe

ve

re

ir

o

Publicação de artigos e participação em congressos


Estruturação, edição e revisão da tese

Preparação e elaboração daproposta de tese

Tabela 4: Cronograma de atividades 2012 – 2013

Nas tabelas 3 e 4, todo o trabalho de refinamento da proposta, estudos de casos e obtenção de resultados está sendo terminado, restando

a escrita e artigos e preparação de apresentações, além da finalização e estruturação da tese, recebendo e aplicando as revisões geradas

pelo orientador. O detalhamento das atividades é feito a seguir:

• Publicação de artigos e participação em congressos: tendo em mãos uma proposta validada e uma série de resultados

relevantes, o foco desta atividade será de selecionar os congressos e conferências que possuam temática relacionada, para que seja

feita a submissão de artigos e apresentação do trabalho;

• Estruturação, edição e revisão da teste: esta atividade se dedica a completar e refinar todas as informações já existentes no

documento de tese, adicionando comentários e críticas coletadas ao longo do processo de participação em congressos, além de

sugestões e contribuições oriundas do próprio grupo de pesquisa.

Bibliografia

[1] W. Ecker, W. Müller e R. Dömer, Hardware-dependent Software, 2009

[2] Gordon E. Moore, Cramming more components onto integrated circuits, 1965

[3] Sematech Inc, International technology roadmap for semiconductors (ITRS), 2004

[4] S. Humphrey Watts, The future of software engineering: Part V, 2002

[5] LSC, IC-Unicamp, ArchC Architecture Description Language, 2010

[6] F. Herrera, H. Posadas, P. Sánchez e E. Villar, Systematic Embedded Software

Generation from SystemC, 2003

[7] Open Source SystemC Initiative, SystemC Language Reference Manual, 2005

[8] S. Yoo, M. Youssef, A. Bouchhima e A. Jerraya, Multi-Processor SoC Design

Methodology using a Concept of Two-Layer Hardware-dependent Software, 2004

[9] R. Moigne, O. Pasquier e J-P. Calvez, A Generic RTOS Model for Real-time Systems

Simulation with SystemC, 2004

[10] H. Yu, R. Dömer e D. Gajski, Embedded Software Generation from System Level

Design Languages, 2004

[11] M. Krause, D. Englert, O. Bringmann e W. Rosenstiel, Combination of Instruction Set

Simulator and Abstract RTOS Model Execution for Fast and Accurate Target Software

Evaluation, 2008

[12] G. Schiner, A. Gerstlauer e R. Dömer, Automatic Generation of Hardware dependent

Software for MPSoCs from Abstract System Specifications, 2008

[13] Zhonglei Wang e Andreas Herkersdorf, Software performance simulation strategies

for high-level embedded system design, 2009

[14] E. Lisboa, L. Silva, I. Chaves, T. Lima e E. Barros, A Design Flow Based on a Domain

Specific Language to Concurrent Development of Device Drivers and Device Controller

Simulation Models, 2009

Assinaturas

Bruno Otávio Piedade PradoOrientando

Edna Natividade da Silva BarrosOrientadora

Recife, 3 de Março de 2012

Plano de Tese de Doutorado - cin.ufpe.brbopp/bopp-saap-2012-1.pdf · Universidade Federal de...

Documents

Transcript of Plano de Tese de Doutorado - cin.ufpe.brbopp/bopp-saap-2012-1.pdf · Universidade Federal de...