Projetodepesquisa Exemplo

Universidade Federal de Pernambuco
Centro 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 Prado

Orientadora: 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
F e ve r e i r o
S e t e mb r o
Nove mb r o
De z e mb r o
Out ub r o
J a ne i r o
A g os t o
Ab r i l
J ul h o
J unh o
Ma r ç o
Ma i o
Atividades
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.
F e ve r e i r o
S e t e mb r o
Nove mb r o
De z e mb r o
Out ub r o
J a ne i r o
A g os t o
Ab r i l
J ul h o
J unh o
Ma r ç o
Ma i o
Atividades
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 da
defesa 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.
F e ve r e i r o
S e t e mb r o
Nove mb r o
De z e mb r o
Out ub r o
J a ne i r o
A g os t o
Ab r i l
J ul h o
J unh o
Ma r ç o
Ma i o
Atividades
Publicação de artigos e
participação em congressos
Estruturação, edição e revisão da
tese
proposta de tese

F e ve r e i r o
S e t e mb r o
Nove mb r o
De z e mb r o
Out ub r o
J a ne i r o
A g os t o
Ab r i l
J ul h o
J unh o
Ma r ç o
Ma i o
Atividades
Publicação de artigos e
participação em congressos
Estruturação, edição e revisão da
tese
proposta 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 Prado

Orientando
Edna Natividade da Silva Barros

Orientadora
Recife, 3 de Março de 2012

Projetodepesquisa Exemplo

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projetodepesquisa Exemplo

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal de Pernambuco

Plano de Tese de Doutorado

Orientando: Bruno Otávio Piedade Prado

Recife, 3 de Março de 2012

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

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

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

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

Figura 1: Lei de Moore

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

1.1 Motivação e justificativa

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

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

1.2 Resumo do Estado da Arte

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

• 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

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

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

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

◦ Ano e publicador: 2004, DATE;

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

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

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

◦ Instituição: University of Nantes;

◦ Ano e publicador: 2004, DATE;

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

• Embedded Software Generation from System Level Design

◦ 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

• Combination of Instruction Set Simulator and Abstract RTOS Model

◦ 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

• Automatic Generation of Hardware dependent Software for MPSoCs

◦ 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,

• Software performance simulation strategies for high-level embedded

◦ 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

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

◦ Instituição: Universidade Federal de Pernambuco;

◦ Ano e publicador: 2009, SCOPES;

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

1.3 Objetivos do trabalho

Este trabalho tem como objetivo melhorar significativamente a produtividade e a

1.4 Estrutura do documento

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

2.1 Systematic Embedded Software Generation from SystemC[6]

Figura 3: Representação dos processos

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

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