Avaliação de Desempenho, Área e Potência

de Mecanismos de Comunicação em Sistemas Embarcados

Alexandre I. Gervini1, Edgard de F. Corrêa1,2, Luigi Carro3, Flávio R. Wagner1
1
Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)
Caixa Postal 15064 – 91501-970 – Porto Alegre – RS – Brasil
2
Superintendência de Informática – Universidade Federal do Rio Grande do Norte (UFRN)
Av. Salgado Filho, 3000 – 59078-970 – Natal – RN – Brasil
3
Depto. Engenharia Elétrica – Universidade Federal do Rio Grande do Sul (UFRGS)
Av. Osvaldo Aranha, 103 – 90035-190 – Porto Alegre – RS – Brasil
{gervini, edgard, flavio}@inf.ufrgs.br, carro@eletro.ufrgs.br

Abstract. For embedded systems-on-chip whose design is software-dominated,

mechanisms for communication among processes have a considerable impact
on performance, power consumption, and area of the final system. This paper
evaluates classic communication mechanisms, showing their impact on those
metrics for an architectural platform based on an application-specific Java
microcontroller. With these results, the developer of an embedded software
application may estimate, at a high abstraction level, the impact of his/her
design decisions on the final synthesized SoC.

Resumo. Em sistemas embarcados integrados numa pastilha, cujo projeto é

dominado pelo software, os mecanismos adotados para comunicação entre
processos têm grande influência sobre o desempenho, a potência consumida e
a área ocupada pelo sistema. Este artigo avalia mecanismos de comunicação
clássicos, mostrando seu impacto sobre estas métricas em uma plataforma
arquitetural baseada em um microcontrolador Java dedicado à aplicação.
Com estes resultados, o desenvolvedor de uma aplicação de software
embarcada pode estimar, num alto nível de abstração, o impacto de suas
decisões de projeto sobre o SoC sintetizado final.

1. Introdução
Os sistemas embarcados [Wolf 2001] apresentam características em comum com
sistemas computacionais de propósitos gerais, mas não possuem a uniformidade desses.
Cada aplicação pode apresentar requisitos diferentes de desempenho, consumo de
potência e área ocupada, o que vai acarretar em uma combinação distinta de módulos de
hardware e software para atender estes requisitos.
Em muitas aplicações é adequada a integração do sistema em uma única pastilha
(SoC – System-on-a-Chip). A arquitetura de hardware de um SoC embarcado pode
conter um ou mais processadores, memórias, interfaces para periféricos e blocos
dedicados. Os componentes são interligados por uma estrutura de comunicação que
pode variar de um barramento a uma rede complexa (NoC - Network-on-a-Chip)
[Micheli 2002]. Os processadores podem ser de tipos diversos (RISC, VLIW, DSP, até
ASIPs – processadores integrados para aplicações específicas), conforme a aplicação.
O software de aplicação pode ser composto por múltiplos processos, distribuídos entre
diversos processadores e comunicando-se através de diferentes mecanismos. Em muitos
casos são gerenciados através de um sistema operacional de tempo real (RTOS) [Burns
1997], que fornece, pelo menos, serviços de comunicação e escalonamento de
processos.
Sendo, em geral, os projetos de sistemas embarcados dominados pelo software
(aplicações e RTOS), é ideal que a exploração do espaço de projeto seja feita no nível
de abstração mais alto possível. Esta exploração consiste em avaliar as alternativas de
arquitetura de hardware e de software, verificando o impacto sobre desempenho,
potência e área do sistema. Para que esta prévia avaliação corresponda ao sistema real é
necessária a utilização de bons estimadores.
A escolha da forma de comunicação (software-software, software-hardware e
hardware-hardware) e do mecanismo (memória compartilhada, troca de mensagens,
acesso direto à memória, etc.) representa um dos aspectos mais importantes em um
projeto de sistemas embarcados. Outro fator importante na exploração do espaço de
projeto é a definição dos serviços que serão fornecidos pelo RTOS. O nível de suporte
de comunicação oferecido pelas primitivas e o tamanho do sistema operacional são
exemplos de alguns dos parâmetros que devem ser levados em conta.
As abordagens atuais para síntese de um RTOS dedicado e mínimo [Chivukula
2002] [Gauthier 2001] consideram as necessidades da aplicação, mas não consideram
explicitamente o atendimento de restrições de projeto como área e potência. Por outro
lado, existem diversas abordagens para projeto de software que consideram restrições
de potência [Yang 2001] [Zhang 2002], mas não especificamente no caso do projeto da
comunicação.
Este trabalho demonstra o impacto de dois mecanismos clássicos de
comunicação (memória compartilhada e troca de mensagens) sobre o desempenho,
potência e área de memória de um sistema embarcado. Estes mecanismos foram
desenvolvidos em Java e tiveram seus custos caracterizados para uma plataforma-alvo
baseada em um microcontrolador Java dedicado (ASIP). Com estes resultados, o
desenvolvedor de uma aplicação de software embarcada para esta plataforma pode
estimar, num alto nível de abstração, o impacto de suas decisões de projeto sobre o
sistema sintetizado final.
O restante deste artigo está organizado da seguinte forma: a Seção 2 discute
trabalhos relacionados. Na Seção 3 é apresentada a plataforma-alvo e na Seção 4 os
mecanismos de comunicação avaliados. A Seção 5 descreve a ferramenta utilizada na
avaliação de potência e desempenho dos mecanismos. Os resultados obtidos são
apresentados e discutidos na Seção 6. Por fim, a Seção 7 apresenta as conclusões e
introduz trabalhos futuros.

2. Trabalhos Relacionados
Sistemas Embarcados geralmente interagem com o ambiente ou tem alguma função
relacionada ao tempo. Sistemas Operacionais de Tempo Real (RTOS) podem ser
utilizados na implementação do domínio de software de tais sistemas. As principais
características de RTOS são:
• determinismo na latência do tratamento de interrupções;
• implementação otimizada para ocupar menos espaço na memória e
executar mais rapidamente;
• escalonamento baseado em prioridades;
• escalabilidade;
• suporte a multitarefas preemptivas.
Para que um sistema embarcado possa ser executado, as tarefas devem ser
mapeadas para processos no sistema operacional. Tais processos podem comunicar-se
através de estruturas providas pelo sistema operacional como caixas de mensagens ou
diretamente através da memória compartilhada.
Durante o projeto, um fator a ser considerado é que tipo de sistema operacional
será utilizado: genérico ou sintetizado a partir das necessidades da aplicação. RTOS
genéricos, como o QNX [Oakley 1997] e o eCos [RedHat 2003], demonstram as
vantagens de serem flexíveis e adaptáveis tendo implementações para diferentes
arquiteturas, sendo, portanto, portáveis. Outros propõem a síntese de um sistema
operacional específico para a aplicação. Ditze [Ditze 1998] apresenta resultados da
síntese de um RTOS baseado na biblioteca DREAMS, demonstrando que a utilização de
um sistema operacional específico resulta em um menor espaço de memória ocupado e
melhor desempenho.
Vários trabalhos propõem a síntese do sistema operacional a partir da
especificação do sistema. Em [Gauthier 2001] é apresentada uma ferramenta para
síntese de sistemas operacionais a partir de descrições realizadas em SystemC. A
comunicação entre os processos é transformada em chamadas do sistema na forma de
readX, writeX, onde X é o tipo do dado a ser transferido. A implementação de tais
chamadas de sistema varia conforme a organização dos processos. Para processos em
um mesmo processador é utilizada a memória compartilhada enquanto que para
processos em processadores diferentes a comunicação é realizada pelo barramento
utilizando-se endereços para especificar o canal a ser utilizado.
Böke [Böke 2000] apresenta um ambiente para síntese do RTOS com ênfase nas
estruturas de comunicação. O sistema operacional é construído a partir de uma
biblioteca pré-definida denominada DREAMS. Após a análise da aplicação é possível
verificar os recursos utilizados e se a estrutura de comunicação utilizada atende aos
requisitos da aplicação. Em [Brunel 2000] a síntese também é feita considerando a
comunicação entre componentes de software. Outra abordagem de síntese de RTOS é
apresentada em [Mooney 2002], onde o sistema operacional é sintetizado como um
módulo de hardware em um SoC.
De um modo geral, tanto nos casos de RTOS dedicados, como naqueles
sintetizados não existe uma preocupação direta na avaliação de potência, área e
desempenho. A prioridade é a minimização do tamanho do software. O aumento do
desempenho e a minimização da potência e da área, muitas vezes, são resultantes da
síntese, mas não objetivo central desta.
 Algumas abordagens propõem análises de consumo de potência utilizando
estimadores baseados nas instruções do processador. Em [Tiwari 1994] a estimativa é
obtida através de experimentos. Outras abordagens também baseadas em simulação ao
nível de instruções [Choi 2001] [Chen 2001] [Dalal 2001], consideram modelos
específicos de consumo de potência para os componentes da arquitetura (unidades
funcionais, barramentos, registradores, memórias, unidades de controle) que são
afetados por cada instrução, de acordo com a atividade de chaveamento das entradas
dos componentes e de suas propriedades físicas. Existem ainda abordagens [Givargis
2001] [Stitt 2000] que combinam ambos os modelos de estimativa: baseado em
componentes e baseado em instruções.
Além do impacto do software na plataforma de hardware (através do sistema
operacional, dos diferentes algoritmos possíveis, do estilo de codificação e da
compilação da aplicação), a gerência da potência do sistema tem se tornado uma parte
fundamental no projeto do sistema operacional [Micheli 2000]. Quando alguns
componentes do sistema não estão sendo utilizados o sistema operacional pode desligá-
los, enquanto permanecer esta inatividade.

3. Plataforma

A plataforma-alvo utilizada na caracterização dos mecanismos de comunicação foi um

microcontrolador Java - FemtoJava [Ito 2001]. Na síntese dos algoritmos que
descrevem os mecanismos em linguagem Java foi utilizado um ambiente CAD [Ito
2000] que realiza automaticamente esta síntese para a plataforma-alvo.
O microcontrolador FemtoJava é baseado em pilha e executa bytecodes Java.
Suas principais características são: um conjunto reduzido de instruções bytecodes,
arquitetura Harvard, execução ortogonal, tamanho pequeno e fácil inserção/remoção de
instruções.
O FemtoJava implementa uma máquina de execução Java em hardware através
de uma máquina de pilha compatível com a especificação da máquina virtual Java (JVM
– Java Virtual Machine). Em geral a JVM tem três componentes principais: carregador
de classe, verificador de classe e mecanismo de execução. Os dois primeiros atuam em
tempo de execução e somente são necessários para plataformas com multi-aplicações ou
que tenham carregamento dinâmico de código através da rede. No nosso caso é usado
um compilador que obedece a especificação da JVM e sintetiza uma versão de um
processador FemtoJava específico para a aplicação (ASIP - Application Specific
Instruction-Set Processor). Somente as execuções do núcleo e de algumas ferramentas
para extração do software em tempo de projeto são realmente necessárias.
A síntese foi realizada em um ambiente CAD - SASHIMI (Systems As Software
and Hardware In MIcrocontrollers) [Ito 2000] que utiliza as vantagens de
compatibilidade de software através do microcontrolador FemtoJava. Devido à
flexibilidade e ao baixo custo, a síntese é feita para FPGA. Esta abordagem é também
caracterizada pela alta integração de funções, pelo ambiente simples de execução, por
ser desnecessário desenvolver um novo compilador, pela compatibilidade de software e
pela possibilidade de desenvolvimento independente de plataforma.
Uma vantagem da execução nativa de bytecodes Java é a compatibilidade de
software. Esta característica garante a possibilidade de desenvolvimento e execução
com independência de plataforma. Em algumas plataformas Java (PC ou estações de
trabalho, por exemplo) somente é possível executar um programa Java. Assim, a
execução de um programa é equivalente à simulação do ambiente da aplicação no
microcontrolador alvo, com todos os recursos e conveniências do ambiente de um
computador na fase de desenvolvimento.
A implementação básica do FemtoJava tem 68 instruções e é feita usando
VHDL. A síntese suporta instruções para aritmética de inteiros e operações de bit,
desvios condicionais/incondicionais, instruções load/store, operações de pilha e dois
bytecodes extras para load/store arbitrários. Nesse núcleo todas as instruções
implementadas são executadas em 3, 4, 7 ou 14 ciclos, por causa da ausência de
memória cache no microcontrolador e pela limitação de memória de várias instruções.

4. Caracterização dos Mecanismos de Comunicação

Os mecanismos a serem avaliados foram escolhidos dentre os mais tradicionais na

comunicação de processos: memória compartilhada e troca de mensagens. Esses
mecanismos foram descritos em alto nível, em linguagem Java, com posterior síntese
através da ferramenta SASHIMI.

4.1. Memória Compartilhada

O uso compartilhado de variáveis de memória para realizar a comunicação entre
processos é a forma de implementação mais simples, e que, em geral, deveria apresentar
menor custo de potência e melhor desempenho. Entretanto, o compartilhamento de
memória vai exigir um maior cuidado para manter a consistência dos dados no controle
de escrita e leitura das variáveis envolvidas.
O código fonte Java utilizado para descrever comunicação utilizando memória
compartilhada de uma palavra (16 bits) é apresentado na Figura 1.

public class mem1 {

static int msg2;
static int memcomp[] = new int[128]; // area da memoria compartilhada
public static void escrever(int msg0,int end){
memcomp[end] = msg0;
}
public static void ler(int end){
msg2 = memcomp[end];
}
}

Figura 1 – Implementação de memória compartilhada

Como apresentado na Figura 1, a área de memória compartilhada é definida pelo
arranjo de inteiros memcomp[ ]. O arranjo pode ser manipulado através dos métodos
(primitivas) escrever, utilizado para enviar um dado para um determinado endereço da
memória (memcomp[ ]), e ler, que é utilizado para buscar um dado da memória
compartilhada para dentro de uma variável.
4.2. Troca de Mensagens
A utilização de troca de mensagens na comunicação entre processos resolve o problema
de consistência que tem que ser tratado na memória compartilhada, mas vai exigir a
existência de um protocolo que controle o envio e o recebimento das mensagens.
Este protocolo representa uma sobrecarga de processamento, provavelmente
reduzindo o desempenho e aumentando o consumo de potência. O código fonte usado
para descrever troca de mensagens de uma palavra (16 bits) é mostrado na Figura 2.

public class Porta1 { public static void receive(){

static int msg2; if(fila_vazia!=true){
static int fila[] = new int[128]; msg2 = fila[inicio];
static int proximo; if (inicio+1==128){
static int inicio; inicio = 0;
static boolean fila_cheia; }
static boolean fila_vazia; else{
public static void inicializa(){ inicio = inicio+1;
proximo = 0; }
inicio = 0; if(fila_cheia=true)
fila_cheia= false; fila_cheia=false;
fila_vazia=true; if(proximo==inicio)
} fila_vazia=true;
}
public static void send(int msg0){
}
if(fila_cheia!=true) {
}
fila[proximo] = msg0;
if(proximo + 1==128){
proximo = 0;
}
else
proximo = proximo+1;
if(fila_vazia=true)
fila_vazia=false;
if(proximo==inicio)
fila_cheia=true;
}
}

Figura 2 - Implementação de troca de mensagens

5. Ferramenta de avaliação
Um simulador ciclo-a-ciclo CACO-PS (Cycle-Accurate COmpiled-code Power
Simulator) [Beck 2003] do microcontrolador FemtoJava foi utilizado para prover dados
do consumo de energia, uso de memória e performance. Este simulador atua sobre uma
descrição estrutural do microcontrolador, avaliando a potência consumida por cada
bloco funcional acionado a cada ciclo de relógio na execução de cada instrução.
A dissipação de potência é avaliada em termos de chaveamento de carga dos
capacitores, e como o processador tem as instruções separadas da memória de dados, o
módulo de avaliação fornece também a avaliação distinta para as memórias RAM e
ROM. Dessa forma, é possível verificar o consumo de potência da CPU, da memória de
programa e da memória de dados. Isso é importante para avaliar o impacto de cada um
desses blocos para melhor explorar o espaço de projeto. Por exemplo, se o consumo de
potência da ROM e da RAM forem muito diferentes, versões distintas do mesmo
algoritmo podem ser avaliadas para reduzir o consumo total do sistema. Um algoritmo
com ênfase no número reduzido de instruções, que utilize mais laços e registradores da
CPU, implicará numa ROM reduzida e numa maior memória de dados. Por outro lado,
outra versão que utilize mais constantes e instruções de endereçamento imediato gerará
uma menor RAM e uma memória de programa maior.
O simulador coleta a quantidade de capacitâncias chaveadas durante a execução
de um determinado programa e fornece o número de ciclos, a quantidade utilizada de
memória de programa e de memória de dados, assim como o consumo de potência.
Dessa forma, o projetista pode medir facilmente o impacto sobre aspectos físicos de seu
sistema a partir de uma descrição de alto nível de abstração da aplicação embarcada,
avaliando rapidamente o impacto de diferentes alternativas do projeto de software.

6. Avaliação dos Mecanismos de Comunicação

A avaliação dos mecanismos de comunicação foi realizada em três etapas.
Inicialmente, num nível alto de abstração, descreveu-se em linguagem Java o
comportamento de cada um dos mecanismos a serem avaliados. Em seguida utilizou-se
o ambiente SASHIMI para fazer a síntese dos mecanismos para linguagem de hardware
(VHDL e MIF) em um processador alvo - FemtoJava. O passo seguinte foi utilizar os
arquivos com as descrições em MIF da ROM e da RAM para obter o consumo de
potência e custo de comunicação no simulador.
De forma a se ter um conjunto representativo do comportamento dos
mecanismos de comunicação e considerando que o FemtoJava trabalha com inteiros de
16 bits, foram realizados os experimentos mostrados na Tabela 1. Cada um dos
experimentos foi realizado tanto para o caso de memória compartilhada como para o
caso de troca de mensagens.
Assim, para enviar dados de 64 bytes, por exemplo, têm-se as seguintes
alternativas:
• enviar 32 pacotes com tamanho de 2 bytes (1 inteiro);
• enviar 16 pacotes com tamanho de 4 bytes (2 inteiros) ou
• enviar 8 pacotes com tamanho de 8 bytes (4 inteiros).
 Tabela 1 – Conjunto de experimentos realizados
Tamanho da
Mensagem
Tamanho 8 bytes 64 bytes 128 bytes 256 bytes
do Pacote
1 inteiro (2 bytes) 4 pacotes 32 pacotes 64 pacotes 128 pacotes

2 inteiros (4 bytes) 2 pacotes 16 pacotes 32 pacotes 64 pacotes

4 inteiros (8 bytes) 1 pacote 8 pacotes 16 pacotes 32 pacotes

6.1. Análise de Desempenho

A análise de desempenho feita através do levantamento do número de ciclos gasto em
cada mecanismo, apresentou os resultados mostrados na Tabela 2.
Tabela 2 – Número de ciclos gastos pelos mecanismos de comunicação

MEMÓRIA TROCA DE
COMPARTILHADA MENSAGENS

1 inteiro x 8 574 1788

x 64 4186 13126
x 128 8314 26040
x 256 16573 51895

2 inteiros x 8 574 1252

x 64 4186 8802
x 128 8314 17410
x 256 16573 34629

4 inteiros x 8 524 928

x 64 3786 6210
x 128 7514 12226
x 256 14973 24249

Analisando os dados obtidos pode-se constatar que o mecanismo de troca de

mensagens é significativamente mais custoso, comparado com o de memória
compartilhada, na questão do tempo de computação. Porém, esta diferença diminui
conforme o aumento da palavra de dados a ser transmitida. Isto porque o custo de
gerência da fila dilui-se, pois o mecanismo para o tratamento da mesma relativamente
decresce conforme o aumento da palavra de dados. Isto se torna evidente, por exemplo,
observando a variação percentual de ciclos que os dois mecanismos obtiveram para
enviar 256bytes de dados, com palavras de 64 bits.
 Enquanto na memória compartilhada o número de ciclos diminuiu cerca de 10%
(16573 → 14973), no mecanismo de troca de mensagens o valor decresce cerca de 39%
(24249 → 14973).
Um resultado peculiar foi a obtenção de número de ciclos idênticos entre os
dados de memória compartilhada, utilizando palavras de um inteiro (16 bits) e dois
inteiros (32 bits). Isto ocorreu por casualidade, devido às instruções escolhidas pelo
compilador. Em cada um dos casos era diferente o número e o grupo de instruções
geradas. No entanto, uma análise dos bytecodes gerados revelou que o caso onde
ocorria o menor número de instruções, estas eram as que necessitavam de um maior
número de ciclos, o que gerou um número total de ciclos idêntico para os dois tamanhos
de dados.

6.2. Análise de Potência

O consumo de potência, medido em capacitâncias de gate (Cg), fornecido pela
ferramenta CACO-PS, apresentou os resultados da Tabela 3.
Tabela 3 – Potência consumida pelos mecanismos de comunicação

MEMÓRIA COMPARTILHADA TROCA DE MENSAGENS

Potência # Ciclos Potência # Ciclos

1 inteiro x8 5.071.396 574 8.546.373 1788

x 64 35.292.187 4186 59.009.816 13126
x 128 69.832.380 8314 116.585.716 26040
x 256 138.898.060 16573 231.778.054 51895

2 inteiros x8 3.948.712 574 5.999.682 1252

x 64 26.335.360 4186 38.575.964 8802
x 128 51.956.902 8314 75.778.420 17410
x 256 103.225.496 16573 150.256.148 34629

4 inteiros x8 3.196.211 524 4.528.034 928

x 64 20.307.086 3786 26.799.189 6210
x 128 39.897.075 7514 52.219.850 12226
x 256 79.108.788 14973 103.069.104 24249

Observando os dados da tabela constata-se que a potência, independente do

método de comunicação, diminui de acordo com tamanho da palavra a ser transmitida.
Ainda, novamente o método de troca de mensagens mostrou-se mais custoso em relação
à potência do que o de memória compartilhada. Isto já era esperado, pelo fato do
método de troca de mensagens possuir um número de ciclos maior do que o de memória
compartilhada. É interessante ressaltar que, conforme se aumenta os dados a serem
transmitidos, maior é a linearidade entre os números de ciclos e a potência, pois as
operações de escrita e leitura de dados começam a dominar e não o processamento de
CPU. Outro fator relevante, é que apesar de haver uma linearidade entre os valores de
potência e números de ciclo nos dois mecanismos, esta relação não é mantida inter-
relacionando os dois mecanismos. Isto pode ser comprovado confrontando os valores do
envio de 128 bytes com palavras de 32 bits do método de troca de mensagens, com o
envio de 256 bytes com palavras de 32 bits no método de memória compartilhada. Os
valores de número de ciclos são semelhantes, porém os valores de potência diferem de
forma significativa. Isto ocorre porque o mecanismo de memória compartilhada está
utilizando um maior número operações de acessos à memória, que possui um custo de
potência diferente das operações que acessam a CPU.

6.3. Variando a Potência da RAM

Outros resultados interessantes sobre a potência foram obtidos com a variação da
potência da memória RAM. Nesses cálculos foram considerados os valores de potência
para a RAM de 23.000 Cg e 4.600 Cg. Os resultados são apresentados na Tabela 4.
Tabela 4 – Potência consumida na RAM pelos mecanismos de comunicação

POTÊNCIA TOTAL
MEMÓRIA COMPARTILHADA TROCA DE MENSAGENS
RAM(23000) RAM(4600) RAM(23000) RAM(4600)
1 inteiro x8 5.071.396 1.575.396 8.546.373 3.504.773
x 64 35.292.187 11.188.187 59.009.816 25.061.816
x 128 69.832.380 22.176.380 116.585.716 49.646.516
x 256 138.898.060 44.138.060 231.778.054 98.856.454

2 inteiros x8 3.948.712 1.335.912 5.999.682 2.430.082

x 64 26.335.360 9.296.960 38.575.964 16.440.764
x 128 51.956.902 18.432.102 75.778.420 32.446.420
x 256 103.225.496 36.727.896 150.256.148 64.530.548

4 inteiros x8 3.196.211 1.135.411 4.528.034 1.804.834

x 64 20.307.086 7.684.686 26.799.189 11.435.189
x 128 39.897.075 15.204.275 52.219.850 22.430.250
x 256 79.108.788 30.275.188 103.069.104 44.465.104

Percebe-se nitidamente, com o auxílio da Tabela 4, que com a diminuição da

potência da memória em cinco vezes, o impacto sobre a potência total dos métodos de
comunicação é diminuído significativamente. Porém, o mecanismo de troca de
mensagens é mais fortemente influenciado que o de memória compartilhada, pois ele
possui um maior número operações a serem realizadas pela CPU, que não sofrem
influência da variação de potência sofrida pela memória RAM.
Desta forma, é mais custoso percentualmente realizar troca de mensagens em
relação à memória compartilhada conforme o valor da potência da memória RAM é
diminuída. Ainda deve-se ressaltar, que com o aumento da palavra de dados diminui-se
o aumento percentual de potência em relação à troca de dados na memória
compartilhada, causado pela variação de potência da memória RAM.
6.4. Análise de Área
Na tabela 5, percebe-se que, conforme o aumento da palavra de dados, o código
sintetizado da aplicação diminui. Isto se dá pela diminuição de chamadas de métodos
causadas pelo envio de grandes pacotes de dados para memória.
Tabela 5 – Área ocupada pelo código dos mecanismos de comunicação

MEMÓRIA TROCA DE
COMPARTILHADA MENSAGENS
ROM ROM
1 inteiro x8 109 243
x 64 439 465
x 128 823 721
x 256 1592 1234

2 inteiros x8 123 265

x 64 309 403
x 128 533 563
x 256 982 884

4 inteiros x8 167 313

x 64 281 409
x 128 425 521
x 256 714 746

7. Conclusões e trabalhos futuros

O artigo demonstrou que há grandes diferenças no impacto de dois mecanismos
clássicos de comunicação (memória compartilhada e troca de mensagens) sobre o
desempenho, potência e área de memória de um sistema embarcado implementado
sobre uma plataforma-alvo baseada em um microcontrolador Java dedicado, para
diferentes tamanhos de dados a serem transmitidos. A caracterização prévia de uma
biblioteca de mecanismos de comunicação é, portanto, de grande utilidade para o
desenvolvedor de uma aplicação de software embarcada, já que permite a ele a
estimação, num alto nível de abstração, do impacto de suas decisões de projeto sobre o
sistema sintetizado final.
Além disto, a avaliação mostrou que a diferença de consumo entre a CPU e as
memórias de dados e de programa também provoca alterações nos custos relativos entre
os dois mecanismos de comunicação. Na medida em que o custo em potência da
memória de dados torna-se da mesma ordem de valor do custo da CPU, mecanismos
mais complexos como troca de mensagens tem seu custo em potência elevado em
relação a mecanismos mais simples. Isto claramente abre um espaço de projeto na
escolha do mecanismo de comunicação quando a diferença entre as potências da CPU e
da memória é muito discrepante.
 A biblioteca de comunicação está sendo estendida para outros estudos de caso,
incluindo comunicação por DMA e inclusive mecanismos para comunicação software-
hardware e hardware-hardware. Esta biblioteca, devidamente caracterizada em termos
de custos de projeto dos diversos mecanismos, será integrada a uma metodologia para
geração automática de RTOS considerando o atendimento de restrições de projeto
(desempenho, potência, área) de uma aplicação específica. Esta metodologia faz parte
de um ambiente de exploração arquitetural de alto nível de projeto de SoCs.

Agradecimentos
Este artigo teve financiamento parcial do CNPq e CAPES.

Referências
Beck Filho, A. C. S. (2003). “CACO-PS: um avaliador de potência”. (Relatório de
Pesquisa) Porto Alegre: PPGC da UFRGS.
Böke, C. (2000) “Combining Two Customization Approaches: Extending the
Customization Tool TEReCS for Software Synthesis of Real-Time Execution
Platforms”. In: Proceedings of the Workshop on Architectures of Embedded
Systems.
Brunel, J-Y. et al. (2000) “COSY Communication IP’s”. In: DAC'00 — Design
Automation Conference, Los Angeles. Proceedings, ACM.
Burns, A. and Wellings, A. (1997) “Real-Time Systems and Their Programming
Languages”. Addison-Wesley.
Chen, R., Irwin, M. J. and Bajwa, R. (2001) “Architecture-Level Power Estimation and
Design Experiments”. In: ACM Transactions on Design Automation of Electronic
Systems, vol. 6, n. 1. pp 50-66.
Chivukula, R. P., Böke, C. and Ramming, F. J. (2002) “Customizing the Configuration
Process of an Operating System Using Hierarchy and Clustering”. In: Proceedings of
the 5th IEEE International Symposium on Object Oriented Real Time Distributed
Computing. Crystal City. IEEE Computer Society Press. p. 280-287.
Choi, K. and Chatterjee, A. (2001) "Efficient Instruction-Level Optimization
Methodology for Low-Power Embedded Systems". International Symposium on
System Synthesis. Montréal. ACM. pp 147-152.
Dalal, V. and Ravikumar, C. P. (2001) "Software Power Optimizations in an Embedded
System". VLSI Design Conference. IEEE Computer Science Press. pp 254-259.
Ditze, C. and Böke, C. (1998) “Supporting Software Synthesis of Communication
Infrastructures for Embedded Real-Time Applications”. In: Proceedings of the
Workshop on Distributed Computer Control Systems, Italy.
Gauthier, L., Yoo, S. and Jerraya, A. (2001) “Automatic Generation and Targeting of
Application-Specific Operating Systems and Embedded Systems Software”. In:
Proceedings of the Design, Automation, and Test in Europe Conference. Munich.
IEEE Computer Society Press.
Givargis, T., Vahid, F. and Henkel, J. (2001) “System-Level Exploration for Pareto-
optimal Configurations in Parameterized Systems-on-a-chip”. International
Conference on Computer-Aided Design. Santa Clara.
Ito, S. A., Carro, L. and Jacobi, R. (2000) "System Design Based on Single Language
and Single-Chip Java ASIP Microcontroller". Design, Automation and Test in
Europe Conference. Paris. IEEE Computer Society.
Ito, S. A., Carro, L. and Jacobi, R. (2001) "Making Java Work for Microcontroller
Applications". In: IEEE Design & Test, vol. 18, n. 5, Sept. /Oct. pp. 100-110.
Micheli, G. and Benini, L. (2000) “System-Level Power Optimization: Techniques And
Tools”. In: Proceedings of the Design, Automation, and Test in Europe Conference.
Paris. IEEE Computer Society.
Micheli, G. and Benini, L. (2002) "Networks-on-Chip: a New Paradigm for Systems-
on-Chip Design". In: Proceedings of the Design, Automation, and Test in Europe
Conference. Paris. IEEE Computer Society Press.
Mooney III, V. J. and Blough, D. M. (2001) "A Hardware-Software Real-Time
Operating Systems Framework for SoCs". In: IEEE Design & Test of Computers,
Nov. /Dec.
Oakley, R. (1997) “QNX microkernel technology: a scalable approach to real-time
distributed and embedded systems”. In: Proceedings of the Symposium on Operating
System Principles. ACM.
RedHat, (2003) “eCos Reference Manual” (http://sources.redhat.com/ ecos/docs-
latest/ref/ecos-ref.html), Technical Reference Manual, RedHat, Mar.
Stitt, G., Vahid, F., Givargis, T. and Lysecky, R. (2000) "A First-Step Towards an
Architecture Tuning Methodology". International Conference on Compilers,
Architecture and Synthesis for Embedded Systems. San Jose.
Tiwari, V., Malik, S. and Wolf, A. (1994) "Power Analysis of Embedded Software: a
First Step Towards Software Power Minimization". In: IEEE Transactions on Very
Large Scale Integration Systems, vol. 2, n. 4, Dec. pp 437-445.
Wolf, W. (2001) “Computers as Components”. McGraw-Hill.
Yang, P. et al. (2001) "Energy-Aware Runtime Scheduling for Embedded-
Multiprocessor SOCs". In: IEEE Design & Test of Computers, Sept./Oct.
Zhang, Y., Hu, X., and Chen, D. Z. (2002) "Task Scheduling and Voltage Selection for
Energy Minimization". In: Proceedings of the Design Automation Conference, New
Orleans. ACM.