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.
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.
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]; }
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.
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
public class Porta1 {
static int msg2;
static int fila[] = new int[128];
static int proximo;
static int inicio;
static boolean fila_cheia;
static boolean fila_vazia;
public static void inicializa(){ proximo = 0;
inicio = 0;
fila_cheia= false; 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; } }
public static void receive(){ if(fila_vazia!=true){ msg2 = fila[inicio]; if (inicio+1==128){ inicio = 0; } else{ inicio = inicio+1; } if(fila_cheia=true) fila_cheia=false; if(proximo==inicio) fila_vazia=true; } } }
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
Tabela 1 – Conjunto de experimentos realizados
Tamanho da Mensagem Tamanho
do Pacote
8 bytes 64 bytes 128 bytes 256 bytes
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 COMPARTILHADA TROCA DE 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 x 8 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 x 8 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 x 8 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 x 8 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 x 8 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 x 8 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 COMPARTILHADA TROCA DE MENSAGENS ROM ROM 1 inteiro x 8 109 243 x 64 439 465 x 128 823 721 x 256 1592 1234 2 inteiros x 8 123 265 x 64 309 403 x 128 533 563 x 256 982 884 4 inteiros x 8 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 software-hardware-software-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.
