ANÁLISE DE DESEMPENHO E CONSUMO DE POTÊNCIA NA COMUNICAÇÃO
INTERPROCESSOS EM SOFTWARE EMBARCADO
Marcio Seiji Oyamada 1,2
Alexandre Irigon Gervini 1
Edgard Faria Correa 1,3
Flávio Rech Wagner1
Luigi Carro 1
UFRGS - Universidade Federal do Rio Grande do Sul1
Instituto de Informática – Porto Alegre – RS – Brasil
UNIOESTE - Universidade Estadual do Oeste do Paraná2
Centro de Ciências Exatas e Tecnológicas – Cascavel – PR- Brasil
UFRN – Universidade Federal do Rio Grande do Norte3
Superintendência de Informática – Natal – RN- Brasil
{ marcio, gervini, edgard, flavio, carro}@inf.ufrgs.br
SUMMARY
For embedded systems-on-chip whose design is software-dominated, mechanisms for communication among
software processes may have a significant impact on performance, power consumption, and memory footprint of
the final system. This paper analyzes these metrics, using three different communication mechanisms: sharedmemory without semaphores, shared-memory with semaphores, and message passing. These mechanisms are
evaluated for an architectural platform based on an application-specific Java microcontroller. An embedded
Crane control was modeled with different task partitions and the power consumption, performance and memory
footprint of different interprocess communication mechanisms was evaluated. The results obtained shows that
the performance and power consumption overhead of message passing mechanism can be minimized using a
suitable task set.
RESUMO
No projeto de sistemas embarcados onde grande parte do projeto está relacionada ao desenvolvimento de
software, diferentes mecanismos de comunicação interprocessos podem ter impacto significante no
desempenho, consumo de potência e área de memória do sistema final. Este artigo analisa estas métricas,
utilizando três mecanismos de comunicação: memória compartilhada sem semáforos, memória compartilhada
com semáforos e troca de mensagens. Estes mecanismos foram avaliados em uma plataforma arquitetural
baseada em um microcontrolador Java de aplicação específica. Um sistema de controle embarcado de guindaste
foi modelado e vários mecanismos de comunicação foram utilizados na comunicação entre os processos que
compõem o sistema. Além do mecanismo de comunicação o particionamento das tarefas foi avaliado. Desta
forma, podemos verificar que o aumento do consumo de potência e ciclos consumidos pela utilização de um
método mais sofisticado e seguro de comunicação pode ser minimizado pela divisão adequada dos processos que
compõem a aplicação.
ANÁLISE DE DESEMPENHO E CONSUMO DE POTÊNCIA NA COMUNICAÇÃO
INTERPROCESSOS EM SOFTWARE EMBARCADO
Marcio Seiji Oyamada 1,2
Alexandre Gervini 1
Edgard Farria Correa 1,3
Flávio Rech Wagner1
Luigi Carro 1
Universidade Federal do Rio Grande do Sul1
Instituto de Informática – Porto Alegre – RS – Brasil
Universidade Estadual do Oeste do Paraná2
Centro de Ciências Exatas e Tecnológicas – Cascavel – PR- Brasil
UFRN – Universidade Federal do Rio Grande do Norte3
Superintendência de Informática – Natal – RN- Brasil
{ marcio, gervini, edgard, flavio, carro}@inf.ufrgs.br
RESUMO
No projeto de sistemas embarcados onde grande parte do
projeto está relacionada ao desenvolvimento de software,
diferentes mecanismos para comunicação através de
processos podem ter impactos significantes no
desempenho, consumo de potência e área de memória do
sistema final. Este artigo analisa estas métricas, utilizando
três mecanismos de comunicação: memória compartilhada
sem semáforos, memória compartilhada com semáforos e
troca de mensagens. Estes mecanismos foram avaliados em
uma
plataforma
arquitetural
baseada
em
um
microcontrolador Java de aplicação específica. Um sistema
de controle embarcado de guindaste foi modelado e vários
mecanismos de comunicação foram utilizados na
comunicação entre os processos que compõem o sistema.
Além do mecanismo de comunicação o particionamento
das tarefas foi avaliado. Desta forma, podemos verificar
que o aumento do consumo de potência e ciclos
consumidos pela utilização de um método mais sofisticado
e seguro de comunicação pode ser minimizado pela divisão
adequada dos processos que compõem a aplicação.
1. INTRODUÇÃO
Sistemas Embarcados têm requisitos de projetos que não
são encontrados em sistemas de uso geral. Requisitos
como desempenho, consumo de potência, e área de
memória determinam qual tipo de tecnologia, arquitetura, e
algoritmos serão utilizados.
Em algumas situações, o baixo consumo de potência, alta
densidade de código, e a habilidade de integrar
dispositivos periféricos em um mesmo circuito podem
influenciar o projeto tanto quanto os requisitos de
desempenho. O sistema embarcado pode ser implementado
em um sistema em uma única pastilha (SoC - System-onchip) através do reuso de componentes de propriedade
intelectual, com o intuito de reduzir a complexidade e o
tempo de projeto. Metodologias de projeto no nível de
sistema estão sendo propostas para suportar o projeto de
SoC, onde ferramentas de projeto de alto-nível são
utilizadas para a exploração arquitetural visando uma
implementação otimizada.
Um sistema embarcado é composto de vários módulos
(processadores, memórias, blocos IP dedicados,
periféricos) que são integrados através de um barramento
compartilhado ou uma rede complexa (NoC – Network on
chip). O software aplicativo pode ser composto de
múltiplos processos e distribuídos através de vários
processadores.
Processos
são
normalmente
desenvolvidos
para executar sobre um Sistema
Operacional de Tempo Real (RTOS), que fornece vários
serviços e funcionam como uma camada abstrata que
facilita e aumenta a velocidade do projeto do software
aplicativo.
Com o objetivo de obedecer aos requisitos de projeto, um
paradigma de projeto baseado em plataformas pode ser
utilizado[1]. Desta forma, uma plataforma de hardware pode
ser compartilhada através de várias aplicações de um
mesmo domínio, assim reduzindo os custos e tempo de
projeto. A configuração da plataforma para uma dada
aplicação torna-se principalmente um projeto de
desenvolvimento de software. Devido a crescente
complexidade do software embarcado, o projeto do
software torna-se decisivo e requer ferramentas
adequadas. Assim como para o hardware, uma plataforma
de software pode ser adotada para oferecer ao projetista
uma camada de abstração para acessar os recursos de
hardware e suporte no gerenciamento de tarefas. O acesso
do hardware pode ser implementado através de
acionadores (drivers) de periféricos que fornecem uma API
(application programming interface) padrão. A execução
de tarefas pode ser gerenciada por um RTOS, que fornece
serviços para a execução concorrente, gerenciamento de
memória, comunicação interprocessos, entre outros.
A comunicação entre módulos (software/software,
software/hardware e hardware/hardware) de um sistema
embarcado pode ser implementada através de vários
mecanismos, como memória compartilhada, troca de
mensagens ou acesso direto à memória. A exploração do
espaço de projeto para um dado sistema pode ser realizada
neste nível definindo o mecanismo de comunicação mais
adequado e seus parâmetros de configuração. Além disso,
o Sistema Operacional de Tempo Real pode ser
customizado com um conjunto mínimo e ótimo de serviços
de comunicação que são necessários para uma aplicação
particular.
Para melhorar a exploração de espaço de projeto, o
projetista do sistema deverá ter, em um alto nível de
abstração, uma clara indicação do impacto de suas
decisões em relação aos mecanismos de comunicação,
como uma função não somente da aplicação mas também
da plataforma de hardware utilizada.
Em [2,3] a geração de RTOS customizados é apresentada.
A partir da análise da aplicação, um Sistema Operacional
(SO) é gerado, contendo somente os módulos necessários
para a aplicação. Esses trabalhos, contudo, normalmente
tem como objetivo minimizar o tamanho do SO, sem
considerar requisitos particulares como desempenho e
consumo de potência.
Este trabalho analisa o impacto da escolha do mecanismo
de comunicação para um sistema de controle de guindaste
(Sistema Crane), em relação a diversos parâmetros como
desempenho, consumo de potência e área de memória.
Este artigo é organizado da seguinte forma: na seção
realizada uma análise dos trabalhos relacionados, e
seção 3 a plataforma e as ferramentas utilizadas
apresentadas e na seção 4 os resultados obtidos
2é
na
são
no
modelo Crane são apresentados. Finalmente, a seção 5
conclui o artigo.
2. TRABALHOS RELACIONADOS
Sistemas operacionais podem ser utilizadas para o
gerenciamento de processos do software embarcado. Um
RTOS tem características [4] como serviço de interrupção
com limite máximo do tempo de resposta, escalonamento
baseado em prioridades, tarefas preemptivas e
escalabilidade. Tais características os diferenciam de um
SO de propósito geral. Além disso, um sistema operacional
deve considerar restrições como a disponibilidade de
recursos, especialmente área de memória e potência.
Uma questão em aberto considerando a síntese de
sistemas embarcados é a adoção de um RTOS de prateleira
ou a síntese de um RTOS. Em [4], o RTOS eCos{5] é
utilizado para prover um ambiente para execução de
descrições SystemC[6]. Em [2] um método para síntese
automática de um SO de tempo real mínimo a partir de
SystemC é proposto. Em [7], um SO tempo real é gerado
utilizando uma biblioteca de módulos, enfocando os
requisitos de comunicação dos processos. Estes trabalhos
têm o foco principal na minimização do código do SO, e
não consideram o consumo de potência do SO.
Em [8], uma análise do consumo de potência do RTOS
µC/OSII é apresentado. A análise é baseada em 2
exemplos: comunicação interprocessos através de TCP/IP
e um sistema de freios ABS (anti-lock braking system). O
consumo de potência dos diferentes componentes do SO
como semáforos e caixa de mensagens é analisado. Em
ambos os exemplos, diferentes implementações da
aplicação são propostos para minimizar o consumo de
potência.
Como em [8], nosso trabalho realiza uma análise do
consumo de potência do SO é realizado. O foco principal é
a análise de desempenho, consumo de potência e a área de
memória ocupada por diferentes mecanismos de
comunicação em uma aplicação de controle embarcado.
3. PLATAFORMA
3.1 Mi crocontrolador FemtoJava
O SASHIMI(System as Software and Hardware in
Microcontrollers) [9] é um ambiente para o projeto de
aplicações embarcadas e geração de microcontroladores
Java. Neste ambiente o projetista fornece a aplicação Java
a ser analisada e otimizada para ser executada em um ASIP
(Application Specific Instruction Set Processor) Java
chamado FemtoJava, mais ASIC (Application Specific
Integrated Circuit) opcional, ambos sintetizados em um
único FPGA.
estratégia também se aplica
comunicação interprocessos.
O FemtoJava é um microcontrolador com arquitetura
Harvard e execução de bytecodes Java nativamente. O
conjunto de instruções da máquina virtual Java (JVM) é
grande e complexo, composto por 226 instruções. O
FemtoJava implementa apenas 68 instruções da
especificação da JVM, necessárias para realizar operações
de pilha e em números inteiros, manipulação de arrays,
jumps condicionais e incondicionais e execução de
métodos estáticos e acesso a classes.
4. O SISTEMA CRANE
3.2 Simulador CACO-PS
aos
mecanismos
de
O sistema Crane foi proposto por [12] como um benchmark
na área de modelagem e síntese no nível de sistema,
envolvendo modelos heterogêneos de computação. A
planta fís ica é composta de um guindaste com uma carga,
movendo através de um trilho como apresentado na Figura
1. O sistema físico é modelado através de um conjunto de
equações diferenciais, que descrevem o comportamento do
guindaste com a carga devido às forças externas aplicadas.
O controle do sistema é realizado pelo algoritmo de
controle, sendo este monitorado por um processo paralelo
de diagnóstico.
O simulador CACO-PS (Cycle-Accurate Configurable
Power Simulator) [10] com a descrição do
microcontrolador FemtoJava foi utilizado para fornecer as
informações sobre o consumo de potência, memória
utilizada e desempenho. O simulador utiliza uma descrição
arquitetural do microcontrolador, avaliando a potência
consumida de cada bloco funcional que é ativado a cada
ciclo de relógio durante a execução de todas as instruções
de uma dada aplicação.
A dissipação de potência é avaliada em temos de
chaveamento de carga dos capacitores. Como o
microcontrolador tem memória de instruções e dados
separada, a avaliação considerando as memórias RAM e
ROM também é incluída. Desta forma, podemos verificar a
dissipação de potência relativa da CPU, memória de
instrução e memória de dados. Isto é importante para medir
o impacto de cada um destes blocos, para que seja
possível explorar melhor 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 RAM
menor e uma memória de programa maior.
O simulador coleta a quantidade de capacitâncias
chaveadas durante a execução de um programa, bem como
o número de ciclos, a memória de instruções utilizada, e a
memória de dados utilizada. Desta forma, o projetista pode
facilmente ter uma medida do impacto da aplicação nos
aspectos físicos do sistema.
Como as estimativas são obtidas a partir de uma descrição
de alto nível de uma aplicação, diferentes alternativas de
software podem ser rapidamente avaliadas, e esta
Figura 1. Modelo Crane
O software embarcado é composto por três tarefas
principais: leitura dos sensores a cada 2ms, o controle
principal a cada 10ms e o diagnóstico que verifica se o
movimento do guindaste está ocorrendo dentro dos limites
permitidos. Além disso, antes da entrada em
funcionamento do sistema, uma rotina seqüencial é
executada a fim de testar o funcionamento dos sensores.
O algoritmo de controle é baseado em um sistema de
controle linear, sendo constituído basicamente de
multiplicações de matrizes em números de ponto flutuante.
O ambiente pode ser simulado através de equações
diferenciais de 4a ordem, sendo o motor descrito por uma
equação diferencial de 1a ordem, com seu comportamento
influenciado pelo valor VC(em volts) enviado pelo
controlador.
4.1 Avaliação dos mecanismos de comunicação
A síntese do microcontrolador FemtoJava para execução
do modelo Crane foi realizada utilizando o ambiente
SASHIMI [9], sendo as simulações realizadas utilizando o
simulador CACO-PS[10].
A implementação do Crane no FemtoJava exigiu a
implementação de uma biblioteca de operações ponto
flutuante, onde tais operações são utilizadas pelo
controlador. A implementação foi baseada na biblioteca
SofFloat [13] escrita na linguagem C. A biblioteca
Softfloat, opera sobre números ponto flutuante no formato
IEEE754, com todas as possibilidades de arredondamento
providas pela especificação. Além das operações básicas
de soma, subtração, multiplicação e divisão a biblioteca
provê funções de comparação entre números. Outras
funções foram retiradas da implementação pois não eram
necessárias no sistema Crane.
Além da versão padrão de 32 bits, a biblioteca foi adaptada
para executar no FemtoJava 16 bits. Na implementação de
16 bits, adotou-se o formato ponto flutuante composto por
10 bits para a parte fracionária, 5 bits para o expoente e
mais 1 para o sinal. A biblioteca sintetizada pelo Sashimi
ocupa 3.571 bytes de memória de programa em ambas as
implementações e mais 540 bytes de memória de dados na
versão 16 bits e 1.100 bytes para a versão 32 bits. Uma
pequena diferença na memória de dados entre as versões é
ocasionada pela criação de mais constantes na memória
pela biblioteca de 32 bits, enquanto que na versão 16 bits
tais valores podem ser carregados como imediatos através
da instrução sipush.
A implementação foi realizada dividindo a aplicação em
duas classes. A primeira classe denominada Sensor, é
responsável pela leitura dos sensores e também a execução
do procedimento de diagnóstico. A segunda classe
denominada Control, agrega todas as operações
relacionadas ao controlador, como o cálculo da força a ser
aplicada no motor. As duas classes devem se comunicar,
pois o controle deve obter as posições do carro, o ângulo
entre o carro e o cabo além dos sensores de fim de curso.
Três mecanismos de comunicação implementados por [13]
foram avaliados conforme a descrição a seguir:
a)
Comunicação direta: a classe Control acessa
diretamente os atributos da classe Sensor.
b) Comunicação através de memória compartilhada
sem semáforos: a comunicação é realizada através
de uma classe que emula uma memória
compartilhada sem a sincronização através de
semáforos;
c)
Comunicação através de memória compartilhada
com semáforos: a comunicação é realizada através
de uma classe que emula uma memória
compartilhada com a sincronização através de
semáforos;
d) Comunicação através de troca de mensagens: as
informações são repassadas através de
mensagens, com a consistência do buffer
realizada inteiramente pela classe responsável
pela troca de mensagens;
Nas implementações (b, c, d), uma segunda implementação
foi realizada dividindo as tarefas de leitura de sensores e
diagnóstico em duas classes. No caso da troca de
mensagens tal alteração, exigiu que duas portas fossem
utilizadas, uma para comunicação entre a leitura de
sensores e o diagnóstico e outra entre a leitura de
sensores e o controle.
A comunicação através de memória compartilhada é mais
adequada quando não é necessário o controle de acesso
de escrita e leitura. Para que tal controle possa ser
realizado normalmente um semáforo é adotado para
gerenciar o acesso. Na troca de mensagens, além do
gerenciamento do acesso concorrente o buffer de dados
segue uma política FIFO de acesso aos dados, facilitando
ainda mais a comunicação entre processos. No caso do
Crane, como o controle e a leitura dos sensores estão
executando concorrentemente, é necessário o controle de
acesso ao buffer e que a leitura dos dados seja realizado na
ordem correta.
Para a comunicação direta foram necessários 177.402 ciclos
para executar duas vezes o algoritmo de controle,
consumindo uma potência total de 526.600.349 medidos em
chaveamento de carga dos capacitores.
A Figura 2 apresenta os ciclos necessários para realizar
duas execuções do algoritmo de controle nos diferentes
mecanismos de comunicação, bem como a divisão do
tempo gasto entre a computação e a comunicação.
Podemos notar que a comunicação pode ocupar de 1,2%
no caso da comunicação através da memória
compartilhada, até 10% no caso da segunda
implementação da troca de mensagens com 3 classes
compondo a aplicação. Podemos notar a influência do
particionamento no tempo de execução do sistema, onde a
implementação utilizando troca de mensagens consome
menos ciclos que a segunda implementação da
comunicação através de memória compartilhada com
semáforos. Tal cenário ocorre pois existe uma maior
necessidade de comunicação devido ao particionamento
das classes de leitura de sensores e diagnóstico.
Tabela 1- Potência consumida em chaveamento de cargas
de capacitâncias
220000
Ciclos
RAM
ROM
Núcleo
TOTAL
Mem.
Compartilhada
179584
387.106
15.106
129.106
532.106
Mem.
Compartilhada
(2)
181246
391.106
15.106
130.106
537.106
Mem.
Compartilhada
c/ semafóros
180646
389.106
15.106
130.106
534.106
Mem.
186880
Compartilhada
c/ semáforos
(2)
401.106
15.106
134.106
552.106
Troca
de 182170
mensagens
391.106
15.106
131.106
538.106
Troca
de 195559
mensagens(2)
415.106
16.106
140.106
572.106
200000
180000
Comunicação
160000
Computação
140000
Troca de
mensagens
Mem.
Compartilhada
100000
Mem.
Compartilhada
120000
Figura 2 – Ciclos consumidos no sistema Crane com
diferentes mecanismos
A Figura 3 apresente a potência consumida pela aplicação
utilizando os diferentes mecanismos de comunicação. A
Tabela 1 apresenta a potência consumida pela aplicação
pelos dos diferentes componentes do sistema tais como
memória RAM, memória ROM e núcleo do processador.
Podemos notar que a potência é proporcional ao número
de ciclos consumidos pela a aplicação. No caso da
implementação através de troca de mensagens o custo é
muito maior devido a necessidade de acesso aos dados
mas também das variáveis de controle do buffer de
comunicação.
600
500
Comunicação
400
A Tabela 2 apresenta a utilização da memória de programa
e de dados nas 6 diferentes implementações. A diferença
na ocupação da memória de dados é ocasionada
principalmente devido à necessidade de mais variáveis de
controle quanto maior a complexidade do mecanismo de
comunicação. Adicionalmente, o particionamento da
aplicação em 2 classes: leitura de sensores e diagnóstico
ocasiona o aumento no tamanho da memória de dados. Em
relação a memória de programa o aumento está relacionado
principalmente ao código de controle do mecanismo de
comunicação adotado.
Tabela 2 – Tamanho da memória de dados e programa de
diferentes programas
CG x 106
Computação
RAM
ROM
300
Mem. Compartilhada (2)
389
5178
100
Mem. Compartilhada c/
semafóros
395
5178
0
Mem. Compartilhada c/
semáforos (2)
390
5231
Troca de mensagens
398
5231
Troca de mensagens(2)
402
5423
Troca de
mensagens (3
200
Mem.
Compartilhada
5120
Mem.
Compartilhada
381
Comunicação
direta
Mem. Compartilhada
Figura 3- Potência total consumida pelos diferentes
mecanismos de comunicação
4. CONCLUSÕES
Este artigo apresenta os diferentes impactos em termos de
desempenho, consumo de potência e memória dos
diferentes mecanismos de comunicação em uma aplicação
de controle embarcado.
Os resultados obtidos mostram que o mecanismo através
de memória compartilhada tem um menor consumo de
potência que a troca de mensagens. O mecanismo de troca
de mensagens devido as suas facilidades em termos de
sincronização e gerenciamento do buffer pode ser a
escolha natural quando é tolerado o aumento do consumo
de potência e menor desempenho. Quando o existe uma
forte restrição quanto a estes parâmetros a comunicação
através memória compartilhada passa a ser a opção
adequada. Tal cenário é válido principalmente em
aplicações intensivas em comunicação onde o impacto é
maior. Em aplicações intensivas em computação como o
Crane, o impacto do mecanismo de comunicação é
relativamente pequeno (entre 1% a 10% do ciclos
consumidos pela aplicação). Porém, podemos notar uma
forte influência no particionamento das tarefas, onde
mesmo utilizando o mecanismo de troca de mensagens,
podemos obter um menor consumo de potência devido ao
melhor particionamento das tarefas e conseqüentemente a
diminuição da comunicação no sistema.
Os trabalhos futuros envolvem o desenvolvimento de
políticas de escalonamento e análise quanto aos custos de
consumo de potência, desempenho e área de memória.
Desta forma, uma biblioteca de componentes devidamente
caracterizados poderá ser utilizada para auxiliar na síntese
de um Sistema Operacional otimizado em termos de
desempenho, consumo de potência e área de memória e
que satisfaça os requisitos da aplicação.
5. REFERÊNCIAS
[1] K.Keutzer,
S.Malik, A.Richard Newton, J.Rabaey,
A.Sangiovanni-Vincentelli.
“System-Level
Design:
Orthogonalization of Concerns and Platform-Based Design”.
In: IEEE Transactions on Computer-Aided Design of
Integrated Circuits, December 2000.
[2] L.Gauthier, S.Yoo, A.Jerraya. “Automatic Generation and
Targeting of Application-Specific Operating Systems and
Embedded Systems Software”. In: Proceedings of the
DATE 2001 (Munich, March 2001). IEEE Computer
Society Press.
[3] F.Herrera, H.Posadas, P.Sánchez, E.Villar. “Systematic
Embedded Software Generation from SystemC”. In:
Proceedings of DATE’03 (Munich, March 2003), IEEE
Computer Society Press.
[4] D.Stepner, N.Rajan, D.Hui. “Embedded Application Design
Using a Real-Time OS”. In: Proceedings of DAC’99 (New
Orleans, June 1999), IEEE Computer Society Press.
[5] Redhat.
eCos
Reference
Manual.
http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.html.
[6] SystemC Specification v2.0. http://www.systemc.org
[7] C.Ditze, C.Böke. “Supporting Software Synthesis of
Communication Infrastructures for Embedded Real-Time
Application”. In: Proceedings of DCCS - 15th IFAC
Workshop on Distributed Computer Control Systems,
Italy, 1998.
[8] R.Dick et al. “Power Analysis of Embedded Operating
Systems”. In: Proceedings of DAC’00 (Los Angeles, June
2000), IEEE Computer Society Press.
[9] S. A. Ito, L. Carro, R. P. Jacobi. “Making Java Work
for Microcontroller Applications”, IEEE Design & Test
of Computers, vol. 18, n. 5, 2001, pp. 100-110
[10] A.C.Beck Filho, F.R.Wagner, L.Carro. “CACO-PS: A
General Purpose Cycle-Accurate Configurable Power
Simulator”. In: SBCCI'03 – 16th Symposium on Integrated
Circuits and Systems Design. São Paulo, Brazil, September
2003.
[11] E.Moser, W.Nebel. “Case Study: System Model of Crane
and Embedded Control”. In: DATE’1999 - Design,
Automation and Test in Europe, Munich, Germany, March
1999.
[12] A.I.GERVINI, E.F.CORREA, L.CARRO, F.R.WAGNER.
“Avaliação de Desempenho, Área e Potência de
Mecanismos de Comunicação em Sistemas Embarcados”. In:
SEMISH'03 – XXX Seminário Integrado de Software e
Hardware. Campinas, Brazil, August 2003.
[13] Softfloat.
Disponível
SoftFloat.html.
em
www.jhauser.us/arithmetic/