Captulo

2
Sistemas Computacionais Embarcados
Luigi Carro e Flvio Rech Wagner
Abstract This chapter discusses the modeling and design of computational embedded systems, which are nowadays extensively used in products of our everyday's life, such as eletronic equipments and vehicles. Since they involve more complex restrictions than traditional computational systems, such as power limitations, cost, and very tight time-to-market, but without compromising performance, these systems create a new study subject. Architectures, models of computation and software support for the development of such systems are covered in this chapter, and open research subjects are identified. Resumo Este captulo discute a modelagem e o projeto de sistemas computacionais embarcados, encontrados cada vez mais em produtos utilizados nas atividades cotidianas, como equipamentos eletrnicos e veculos. Por envolver restries mais complexas que um sistema computacional tradicional, como limite de potncia, custo e baixssimo tempo de projeto, mas sem comprometer o desempenho final, estes sistemas so um objeto de estudo per se. Uma reviso das arquiteturas, modelos de computao e suporte de software necessrios ao desenvolvimento de tais sistemas apresentada neste captulo, assim como so identificados pontos de pesquisa ainda em aberto.

2.1. Introduo
Os sistemas computacionais embarcados esto presentes em praticamente todas as atividades humanas e, com os baixos custos tecnolgicos atuais, tendem a aumentar sua presena no cotidiano das pessoas. Exemplos de tais sistemas so os telefones celulares com mquina fotogrfica e agenda, o sistema de controle dos carros e nibus, os computadores portteis palm-top, os fornos de microondas com controle de temperatura inteligente, as mquinas de lavar e outros eletrodomsticos. O projeto deste tipo de sistema computacional extremamente complexo, por envolver conceitos at agora pouco analisados pela computao de propsitos gerais. Por exemplo, as questes da portabilidade e do limite de consumo de potncia sem perda de desempenho, a baixa disponibilidade de memria, a necessidade de segurana e confiabilidade, a possibilidade de funcionamento em uma rede maior, e o curto tempo de projeto tornam o desenvolvimento de sistemas computacionais embarcados uma rea em si [Wolf 2001]. O projeto de sistemas eletrnicos embarcados enfrenta diversos grandes desafios, pois o espao de projeto arquitetural a ser explorado muito vasto. A arquitetura de hardware de um

SoC embarcado pode conter um ou mais processadores, memrias, interfaces para perifricos e blocos dedicados. Os componentes so interligados por uma estrutura de comunicao que pode variar de um barramento a uma rede complexa (NoC network-on-chip) [De Micheli e Benini 2002]. Os processadores podem ser de tipos diversos (RISC, VLIW, DSP, at ASIPs processadores integrados para aplicaes especficas), conforme a aplicao. No caso de sistemas contendo componentes programveis, o software de aplicao pode ser composto por mltiplos processos, distribudos entre diferentes processadores e comunicando-se atravs de mecanismos variados. Um sistema operacional de tempo real (RTOS) [Burns e Wellings 1997], oferecendo servios como comunicao e escalonamento de processos, pode ser necessrio. Alm do grande tempo que pode ser gasto com uma explorao sistemtica deste espao de projeto, deve-se considerar ainda o tempo necessrio para o projeto e validao individual de todos os componentes dedicados do sistema processadores, blocos de hardware, rotinas de software, RTOS assim como o tempo de validao de sua agregao dentro de um mesmo sistema. Por outro lado, a grande presso mercadolgica num mercado mundial globalizado, somada contnua evoluo tecnolgica, impe s empresas a necessidade de projetarem novos sistemas embarcados dentro de janelas de tempo cada vez mais estreitas, de poucos meses. Alm disto, novos produtos tm uma vida cada vez mais curta, de modo que o retorno financeiro de seu projeto deve ser obtido tambm em poucos meses. Conforme mostrado na Figura 2.1, atrasos de poucas semanas no lanamento de um produto podem comprometer seriamente os ganhos esperados de um novo produto no mercado.

Figura 2.1. Retorno financeiro e janelas de tempo

Um terceiro problema diz respeito aos custos de engenharia no-recorrentes (NRE, em ingls). O projeto de um sistema embarcado de grande complexidade bastante caro para uma empresa, envolvendo equipes multidisciplinares (hardware digital, hardware analgico, software, teste) e a utilizao de ferramentas computacionais de elevado custo. So especialmente elevados os custos de fabricao de sistemas integrados numa pastilha. Um conjunto de mscaras de fabricao est alcanando o custo de um milho de dlares, o que obriga as

empresas ao projeto de componentes que tenham garantidamente muito alto volume de produo, de forma a amortizar os custos de fabricao. Em muitas aplicaes, adequada a integrao do sistema em uma nica pastilha (SoC system-on-a-chip). Em situaes onde requisitos de rea, potncia e desempenho sejam crticos, o projeto do SoC na forma de um ASIC (circuito integrado para aplicao especfica) pode ser mandatrio, elevando bastante os custos de projeto e fabricao. Em muitas outras situaes, no entanto, mais indicada a implementao do sistema em FPGA, alternativa de customizao mais econmica para baixos volumes, ou atravs de sistemas baseados em famlias de microprocessadores, componentes que so fabricados em grandes volumes e integram milhes de transistores. Na atual situao de competitividade industrial, seguindo-se a lei de Moore, tem-se disposio o dobro de transistores a cada 18 meses [Moore 1965]. Consequentemente, sistemas dedicados com milhes de transistores devem ser projetados em poucos meses [Magarshack 2002]. Para isto, tem sido adotado o paradigma de projeto baseado em plataformas [Keutzer 2000]. Uma plataforma uma arquitetura de hardware e software especfica para um domnio de aplicao [Dutta 2001, Demmeler e Giusto 2001, Paulin 1997], mas altamente parametrizvel (no nmero de componentes de cada tipo, na estrutura de comunicao, no tamanho da memria, nos tipos de dispositivos de E/S, etc.). Esta estratgia viabiliza o reuso [Keating e Bricaud 2002] de componentes (ou ncleos) [Bergamaschi 2001] previamente desenvolvidos e testados, o que reduz o tempo de projeto. O reuso pode ser ainda reforado pela adoo de padres [VSIA 2003] na arquitetura e projeto dos sistemas. A Figura 2.2 apresenta um grfico retirado do roadmap ITRS [ITRS 2001], que ilustra que as metodologias tradicionais de projeto tm um custo crescente que no consegue acompanhar a evoluo tecnolgica permitida pela lei de Moore. Como mostrado na figura, estes custos de projeto podem ser sensivelmente reduzidos pelo reuso de plataformas e componentes. O projeto de um SoC embarcado consiste ento em se encontrar um derivativo da plataforma que atenda aos requisitos da aplicao, como desempenho e consumo de potncia. Partindo-se de uma especificao de alto nvel da aplicao, feita uma explorao das solues arquiteturais possveis, estimando-se o impacto de diferentes particionamentos de funes entre hardware e software. Feita a configurao da arquitetura, necessria a sntese da estrutura de comunicao que integrar os componentes de hardware [Lyonnard 2001]. Tambm vital a existncia de uma metodologia adequada ao teste de sistemas complexos integrados numa nica pastilha [Zorian e Marinissen 2000]. Neste estilo de projeto, cada vez mais a inovao de uma aplicao depende do software. Embora a plataforma de hardware de um celular possa ser similar de um controle de freios ABS, definitivamente o software no o mesmo. Com a automao do projeto de hardware encaminhada pelo reuso de plataformas e componentes, a automao do projeto do software se torna o principal objetivo a ser alcanado para a diminuio do tempo de projeto, sem sacrifcio na qualidade da soluo. Esta automao deve idealmente cobrir o software aplicativo, o RTOS [Gauthier 2001], as interfaces entre os processos [Bke 2000] e os acionadores dos perifricos. Tambm aqui essencial o reuso de componentes de software [Shandle e Martin 2002] previamente desenvolvidos, de modo que o projeto do sistema embarcado concentre-se apenas na configurao e integrao dos mesmos.

Figura 2.2. Custos no projeto tradicional e no projeto com reuso [ITRS 2001]

2.2. Arquitetura
Nesta seo so revisadas as arquiteturas clssicas de processadores e as tendncias modernas, discutindo-se a adequao de cada estilo de projeto para um dado sistema alvo; discute-se tambm o impacto das memrias em sistemas embarcados, assim como as estruturas de comunicao hoje disponveis, luz de seu impacto em futuros sistemas constitudos de milhes de componentes heterogneos. 2.2.1. Microprocessadores e seu espao de projeto O projeto de sistemas embarcados toma sempre como base um ou mais processadores. Embora esta soluo parea extremamente conservadora do ponto de vista de inovao, ela traz enormes vantagens do ponto de vista operacional. Primeiro, o fator de escala. Como os microprocessadores so encontrados em milhares de projetos, seu custo dilui-se entre muitos clientes, as vezes at competidores entre si. Mais ainda, uma vez que uma plataforma baseada em processador esteja disponvel dentro de uma empresa, novas verses de produtos podem ser feitas pela alterao do software da plataforma. A personalizao do sistema d-se atravs do software de aplicao, que toma atualmente a maior parte do tempo de projeto. Alm destas vantagens competitivas, h ainda o fator treinamento de engenheiros, j que estes geralmente se formam com conhecimentos de programao de microprocessadores. claro que o projeto usando microprocessadores no vantajoso em todo aspecto. A questo da potncia, cada vez mais valorizada nos tempos atuais, crtica. Como so projetados para executar qualquer programa, existem estruturas de hardware dentro dos processadores que consomem muitos recursos, mas que so muitas vezes sub-utilizadas. Por exemplo, o sistema de predio de saltos de processadores complexos tem um custo de rea e potncia enorme para aplicaes tipo processamento de sinais, onde um preditor mais simples mas eficiente pode ser feito em tempo de compilao. Tambm para este tipo de aplicaes, caches tornam-se

extremamente ineficientes, j que os dados so consumidos muito rapidamente, sem obedecer ao princpo da localidade espacial ou temporal. Para uma aplicao extremamente especfica, um projeto usando lgica programvel como FPGAs ou ASICs pode ter um desempenho muito melhor que usando um processador, ou mesmo uma potncia mais baixa. O problema que sistemas reais possuem diversos comportamentos (modelos de computao) e o atendimento simultneo dos mesmos tende a diminuir o desempenho do hardware dedicado. Alm disto, preciso considerar que se encontram processadores nas mais diversas combinaes de preo, desempenho e potncia. Os processadores tambm contam com grupos de projeto imensos, que chegam s centenas de projetistas, e com tecnologias do estado-da-arte para sua fabricao. Tudo isto torna o uso de processadores extremamente interessante para o projeto de sistemas embarcados. H contudo uma srie de questes a serem respondidas, mesmo que o projetista decida usar um microprocessador. Por exemplo, se o projeto tem limitaes de potncia, famlias de processadores que trabalham com freqncias mais baixas podem no possuir desempenho suficiente. Nestas situaes, preciso escolher processadores com controle de potncia embutido, onde partes do processador possam ser desligadas, ou utilizar tcnicas como processadores e multiprocessadores de mltipla voltagem [Zhang 2002]. Uma alternativa mais interessante escolher a arquitetura adequada para o projeto em questo, pois os ganhos em potncia e desempenho podem ser maiores, conforme ser discutido a seguir. Para um projeto embarcado, no s a CPU importante. O quanto de memria estar disposio impacta a potncia do sistema (memrias rpidas so grande fonte de consumo) e a sua possibilidade de reuso, j que pouca memria limita expanses, ainda obrigando a codificao em assembler, sem muito espao para o uso de compiladores. Isto, por sua vez, aumenta o tempo de projeto, varivel sempre crtica. 2.2.2. Arquiteturas clssicas e tendncias modernas Explorar o paralelismo possvel a soluo natural para se diminuir o tempo de execuo de um certo programa. Contudo, devido a seus custos, as primeiras verses de paralelismo dentro de um processador foram limitadas ao uso de pipeline, ou seja, execuo simultnea de estgios distintos de instrues diversas. A Figura 2.3 ilustra esta situao, onde executado um pipeline de 5 estgios em uma mquina de registradores, assim dividido: B - busca instruo; D decodifica instruo e l os operandos; O - opera sobre os registradores, M - escreve ou l da memria; e finalmente E - escreve de volta no banco de registradores.
instruo i i+1 i+2 i+3 I+4 B D B O D B M O D B E M O D B E M O D E M O E M E

Ciclos de relgio Figura 2.3. Pipeline clssico

A mquina da Figura 2.3 executa bem instrues do tipo rd = rf1 op rf2, onde rd o registrador destino, rf1 e rf2 so os registradores fonte da operao, e op uma operao lgica ou aritmtica. As memrias de programa e de dados encontram-se separadas, sendo que esta ltima pode ser acessada em instrues do tipo carga (rd = MEM [rf1 op rf2]) ou armazenamento (MEM [rd] = rf1 op rf2). O mximo desempenho da arquitetura proposta na Figura 2.3 corresponde execuo de 5 instrues ao mesmo tempo, e a cada ciclo uma instruo completada. Infelizmente, nem todas as instrues necessrias ao funcionamento de um programa podem ser assim executadas. Existem as dependncias de dados, como se pode observar na Figura 2.4.
Instruo I I+1 I+2 I+3 I+4 I+5 (a) cdigo original ld r6, 36(r2) add r5, r6, r4 sub r9, r12, r8 st r5, 200(r6) add r3, r9, r9 and r11, r5, r6 (b) cdigo alterado ld r6, 36(r2) sub r9, r12, r8 add r5, r6, r4 add r3, r9, r9 st r5, 200(r6) and r11, r5, r6

Figura 2.4. Dependncias de dados

As dependncias de dados podem ser resolvidas de diversas maneiras, por exemplo atravs do compilador, pela reodernao da sequncia de instrues, ou atravs do uso de um mecanismo de deteco de dependncia e antecipao do clculo. Embora a reordenao atravs do compilador implique em custo zero de hardware, nem sempre o compilador encontra instrues suficientes para serem trocadas de lugar. Consequentemente, praticamente todas as mquinas possuem estruturas de forwarding, isto , estruturas para antecipar os operandos em caso de dependncia. Por exemplo, o trecho da Figura 2.4 (a) possui uma dependncia de dados pois o operando que deve ser lido no estgio D da instruo i+3 (registrador r6), calculado pela instruo i e escrito nos respectivo estgio E, ainda no est disponvel. Neste caso, uma troca de ordem de instrues pode resolver a dependncia, conforme sugerido na Figura 2.4 (b), ou um multiplexador na entrada da unidade aritmtica necessrio para redirecionar a sada da prpria unidade sua entrada, economizando-se os ciclos de relgio que seriam gastos espera da leitura do dado escrito no registrador. Instrues de salto condicional ou incondicional tambm apresentam problemas para a boa sequncia do pipeline. Uma instruo do tipo bne r3,r2,r1 deve carregar o contador de programa PC com o contedo de r3, se os registradores r2 e r1 no forem iguais. O problema advm do fato que somente no final do terceiro estgio a condio de salto estar disponvel. Neste meio tempo, mais instrues j esto no pipeline, e portanto, no caso de um salto, devero ser descartadas. Pode-se contornar o problema pela insero de uma bolha, isto , uma interrupo parcial no pipeline, at que as dependncias estejam resolvidas, ou promover a limpeza do pipeline, isto , a remoo de todas as instrues que haviam entrado no pipeline depois da instruo de salto. Ambas as solues podem parecer pouco custosas, ainda mais em se tratando de um pipeline de poucos estgios como o apresentado. Contudo, para programas teste de aplicaes escalares, a cada 5 instrues em mdia tem-se um salto [Hennessy 1996]. Consequentemente, o pipeline seria constantemente esvaziado, e tendo-se em conta o tempo

necessrio para que de novo enchesse, a mdia de instrues executadas em paralelo cairia para 2 ou 3. O problema torna-se ainda maior para arquiteturas com vrios estgios de pipeline, como 10 ou 12, o que muito comum em processadores de alto desempenho. A soluo para o problema da dependncia em saltos que esvaziam o pipeline obtida atravs de um mecanismo de predio de saltos. Basicamente, pode-se apostar que, em um programa contendo muitos laos, um salto ser sempre tomado, por exemplo. Ento, ao invs de carregar no pipeline as instrues que seguem o salto, carrregam-se aquelas no destino do salto. Este mecanismo funcionaria bem para programas compostos apenas de grandes laos, mas evidente que, para programas de propsito geral, a soluo peca pela excessiva simplicidade. Uma mquina de predio de saltos mais refinada encontra-se na Figura 2.5. A predio somente muda sua sada caso cometa erros duas vezes. Desta maneira, os arquitetos de computadores esto tendo benefcios da estatstica de execuo de um programa, prevendo o seu comportamento futuro como uma reproduo do passado. Para que a mquina de estados da Figura 2.5 funcione, preciso saber em que ponto o contador de programa se encontra, e necessita-se de uma memria extra para guardar o valor da predio e o endereo destino. Este hardware extra pode ser facilmente suportado pela enorme quantidade de transistores disponveis para fabricao, mas o preo a pagar a dissipao extra de potncia e a rea maior do processador.

Figura 2.5. Predio de saltos atravs de mquina de estados

Pode-se aumentar ainda mais o desempenho do processador pela adoo do paralelismo explcito, por exemplo pela execuo de mais instrues em paralelo atravs de arquiteturas superescalares, como se pode ver na Figura 2.6, onde uma mquina com pipeline de 5 estgios possui superescalaridade 2, isto , duas mquinas iguais trabalham em paralelo. Infelizmente, programas de vida real nem sempre possuem muito paralelismo a ser explorado. Na verdade, tcnicas de compiladores como desenrolamento de laos (loopunrolling) podem aumentar o paralelismo disponvel, mas o preo a pagar muitas vezes o aumento da dependncia de dados. Os arquitetos de processadores rapidamente reagiram, atravs do desenvolvimento de mecanismos de resoluo de dependncias em hardware. Os principais so a execuo fora de ordem de instrues, junto com a renomeao de registradores. O primeiro mecanismo busca, numa fila de instrues, todas aquelas cujas dependncias de dados estejam resolvidas. Desta maneira, no necessria a interveno do

compilador. A segunda tcnica procura esconder a dependncia de dados, pois muitas vezes um registrador escrito para logo depois ser re-escrito, de maneira que um registrador alias pode ser usado antes de seu contedo ser efetivamente destrudo.

Figura 2.6. Arquiteturas superescalares com pipeline

As mquinas superescalares so as mais utilizadas hoje em dia em processadores de uso geral. A grande vantagem destas arquiteturas a descoberta do mximo de paralelismo disponvel sem interveno do programador ou compilador. O maior problema o excesso de potncia, j que os mecanismos de predio de saltos, fila de instrues, execuo fora de ordem e renomeao de registradores trabalham apenas para manter as unidades aritmticas do processador ocupadas a maior parte do tempo. Uma alternativa s mquinas superescalares so as mquinas VLIW (Very Large Instruction Word). Nestas mquinas a palavra de instruo controla todos os bits da parte operativa, como exemplificado na Figura 2.7. As unidades operativas possuem registradores prprios, e o paralelismo mximo decidido a priori, em tempo de compilao.

Figura 2.7. Mquina VLIW

Apesar de no possuir todo o sistema de predio de saltos e de deteco de paralelismo no fluxo corrente de instrues, e portanto ser potencialmente mais econmica que uma mquina superescalar em termos de consumo de potncia, uma desvantagem da mquina VLIW que, devido dependncia de dados, muitas unidades podem ficar esperando instrues, e portanto a memria extra de instrues est sendo desperdiada junto com as unidades operativas. As mquinas VLIW, por outro lado, dependem drasticamente de um compilador eficiente, e so muito mais interessantes se a quantidade de paralelismo puder ser descoberta a priori.

2.2.3. Modificaes arquiteturais para suporte ao processamento digital de sinais Presentemente, muitos sistemas embarcados precisam possuir a capacidade de processar sinais digitalmente. Um exemplo clssico o telefone celular, onde quase todo o processamento das informaes que chegam e saem da antena feito no domnio digital, para permitir maior repetitibilidade e facilidade de projeto em relao ao processamento analgico. Arquiteturas para processamento digital de sinais tornaram-se muito populares na ltima dcada e, impulsionadas pelo mercado de modems e outros equipamentos de comunicao, chegam ao mercado sob forma de processadores especializados para execuo de algoritmos especficos de processamento de sinais, com alto desempenho e baixo custo de potncia. Para melhor discutir as otimizaes arquiteturais, importante entender a famlia de algoritmos para a qual os processadores DSP se adaptaram. Na Figura 2.8 tem-se a realizao de um filtro digital. A memria de dados (barra longa) deve ser varrida, e para cada posio temse um conjunto de coeficientes que deve ser multiplicado a cada dado e acumulado para produo de uma nica sada. patente o grande nmero de operaes aritmticas.

y ( n) =

M 1 k =0

x (n k )

Figura 2.8. Filtro FIR

Como so feitas tantas tantas multiplicaes e somas quanto o tamanho do filtro, ao invs de se utilizar duas instrues (multiplicao seguida de acumulao) e os vrios registradores envolvidos, a estratgia mais interessante o uso de uma nica instruo, a instruo MAC (multiplica e acumula). Contrariamente ao mostrado na Figura 2.8, muitas operaes de processamento de sinais raramente so feitas em batch, mas sim tem de responder em tempo real. Isto significa que os dados a serem processados esto sempre chegando, a uma taxa fixa. A memria utilizada no ser infinita, e em algum momento os dados que chegam devero ocupar a posio daqueles j utilizados e no mais necessrios. Isto pode ser visto na Figura 2.9, que mostra o cdigo Java de um buffer circular. evidente que a gerncia deste buffer consome muitas instrues, que servem apenas para otimizar o acesso memria. Em hardware, um buffer circular apenas um contador de mdulo, isto , um contador que, ao chegar ao seu limite, volta a seu endereo inicial e prossegue incrementando. Praticamente todos os processadores DSP possuem esta otimizao em hardware. interessante observar que esta otimizao geralmente s est disponvel em assembler, j que difcil construir-se um compilador apto a reconhecer um buffer circular.

Pela prpria natureza dos algoritmos de filtragem, o acesso memria um grande gargalo. Para um filtro bsico, como o da Figura 2.8 (filtro FIR) so necessrios, para cada multiplicao, um acesso aos coeficientes do filtro e um acesso aos dados. Consequentemente, muitos processadores possuem bancos de memrias separados, para que o acesso possa ser feito simultaneamente em cada banco. Alm disto, muitos algoritmos, como a transformada rpida de Fourier (FFT) e a transformada discreta do cosseno (DCT), utilizam modos de endereamento no ortodoxos, como endereamento de bit-reverso, onde uma parcela dos bits menos significativos do endereo deve ter sua ordem revertida. Em software esta uma operao custosa, pois so muitas as instrues necessrias em comparao com aquelas teis ao lao. J em hardware, o bit-reverso significa apenas uma inverso de fios a custo prximo de zero.
1 Public static void initSystem() { Entry = 0; 2 size = coef.length; 3 for (int i=0;i<51;i++) coef[i] = coef1[i]; 4 while(true){ // infinite loop through inputs 5 //write new input to the buffer 6 buffer[entry] = FemtoJavaIO.read(0); 7 //update buffer pointer 8 if (entry<(size-1)) entry++; 9 else entry = 0; 10 //reset sum to make a new output 11 sum = 0; 12 for (j=0;j<size; j++) {//coefficient control loop 13 if (entry+j>(size-1)) { 14 sum = sum + (coef[j]*buffer[entry+j-size]);} 15 else { 16 sum = sum + (coef[j]*buffer[entry+j]);} 17 }//end for 18 FemtoJavaIO.write( sum , 1 ); 19 i++; 20 }//end while 21 22 }//end initSystem Figura 2.9. Buffer circular

Como a maior parte dos algoritmos de processamento digital de sinais baseada em laos curtos, com poucas instrues dentro do lao, o controle do lao em software significa instrues extras que pesam no total de instrues a serem executadas no lao. Ao prover-se controle de laos em hardware, estas instrues extras so eliminadas, com grande acelerao do algoritmo a um mnimo custo de hardware. A cada vez que uma interrupo deve ser atendida, o status do processador deve ser salvo, o que significa um longo tempo de salvamento de registradores e status do pipeline do processador. Em aplicaes DSP, muitas vezes a interrupo apenas sinaliza que um novo dado chegou, e que uma simples leitura de uma porta do processador e uma escrita do dado na memria sero suficientes. Processadores DSP possuem ento a possibilidade do programador escolher interrupes mais simples, cujo tempo de atendimento de realmente poucos ciclos, sem envolver pesado chaveamento de contexto. Muitas das funes de processamento digital de sinais agora esto sendo migradas para arquiteturas convencionais, pois os benchmarks utilizados para projeto destas arquiteturas antes no traziam este tipo de problema. Nos sistemas embarcados, mdulos com co-processadores DSP ou com processadores VLIW adaptados ao processamento digital de sinais so cada vez

mais disponveis [Madisseti 1995, Lapsley 1997, Texas 2002]. Krapf (2002, 2003) sugere que o uso de algumas das otimizaes acima mencionadas conseguiu acelerar o processamento de sinais em Java em at 50%, com um custo de rea extra de apenas 5% no processador. 2.2.4. Hierarquia de memrias Uma vez resolvido o problema do paralelismo em processadores, o gargalo passa a outro ponto. Neste caso, o sistema de memrias crtico. Por problemas de fabricao, no podem existir memrias ao mesmo tempo rpidas e de grande capacidade. Memrias estticas podem ser rpidas, funcionando no mesmo ciclo de relgio da CPU (e portanto, dentro do pipeline), mas apenas se seu tamanho for bem limitado. Alm disto, por envolverem grandes capacitncias parasitas de linhas de bit, memrias rpidas tendem a possuir um enorme consumo de potncia, o que somente agrava o problema. Para resolver o problema de velocidade de memria prxima da CPU, h muitos anos os arquitetos inventaram as memrias cache. A idia surgiu na poca em que as memrias de ncleo de ferrite de grande capacidade eram lentas, enquanto que a tecnologia de fabricao de semicondutores no permitia a integrao de um grande nmero de bits de memria. As caches eram memrias rpidas, fabricadas no mesmo processo da CPU, mas que obviamente possuiam uma capacidade limitada de armazenamento. Fortunadamente, para a maioria dos programas aplicam-se a localidade temporal (uma posio visitada ser visitada novamente em pouco tempo), tima para laos, e a localidade espacial (a posio visitada a seguir ser prxima da atual), que permitem o reuso intenso dos dados e instrues armazenados na cache.. Com o avano das tecnologias de memria, podem-se fabricar memrias de grande capacidade (as memrias dinmicas atuais de muitos Mbits), mas infelizmente vrias ordens de grandeza mais lentas que as CPUs. Consequentemente, quase todos os processadores utilizam caches hoje em dia. No domnio de sistemas embarcados, as caches tm seu uso questionado. Embora efetivamente permitam ao processador aumentar seu desempenho, a gerncia das caches e seu consumo so pontos muito desfavorveis, j que a questo da portabilidade est sempre presente. Outro aspecto desfavorvel ao uso de caches que as memrias grandes so dinmicas, o que torna seu custo baixo em termos de rea, mas alto em termos de potncia gasta para um acesso e recuperao do estado da cache. Existe ainda a dificuldade de predio do tempo de resposta em caso de sistemas de tempo real, j que a gerncia da cache e das memrias dinmicas pode tornar a previso excessivamente pessimista, implicando em potncia extra. Por outro lado, os avanos tecnolgicos so rpidos, e usar uma memria lenta implica em no tomar proveito do estado da arte da tecnologia. Nem sempre as caches auxiliam a execuo rpida de um programa. Quando as regras de localidade no se aplicam, as caches estaro consumindo potncia sem nada contribuir. Um exemplo tpico a filtragem de imagens, onde um dado carregado na cache pode ser usado em poucas computaes e depois removido, pois somente ser novamente instanciado na prxima varredura. Isto provoca um contnuo esvaziamento da cache, aumentando a latncia do algoritmo e a potncia consumida. Por serem memrias mais rpidas, as caches consomem enorme quantidade de energia, chegando a 75% da energia de um processador [Kin 2000]. Diversos trabalhos tentam diminuir o impacto de potncia das caches atravs, basicamente, da reduo do tamanho da cache quanto

mais prxima ela esteja da CPU, confiando que a localidade maior para aplicaes modernas [Herbert 2000, Tomiyama 98, Kin 2000, Shiue e Chakrabarty 1999]. No domnio dos sistemas embarcados, alguns trabalhos pressupem que o uso de caches impor uma restrio sria de consumo. Assim, vrios trabalhos otimizam tcnicas para reduo de consumo, como a compresso de instrues, na esperana que o nmero de misses na cache diminua [Lekatsas e Wolf 1999, Benini, 1999]. Outra alternativa o agrupamento de instrues, transformando um processador RISC em um CISC, para diminuir a quantidade de acessos memria, como proposto por Ishihara e Yasuura (2000). Solues alternativas s caches tambm tm sido propostas, por exemplo, atravs da colocao de cdigo muito usado em uma memria dedicada junto ao processador [Benini 2000]. A questo da execuo mais rpida do cdigo crtico resolvida, ao mesmo tempo em que o controle da cache e sua potncia excessiva ficam minimizados. Uma pequena memria rpida de 1024 posies poderia ter uma taxa de acessos chegando a 75% do total de acessos necessrios para executar um decodificador MP3. Para este mesmo tamanho de memria, a economia de potncia chegou a 44% em comparao com uma cache de mesmo tamanho, com poltica write-through de escrita. Presentemente, as aplicaes embarcadas utilizam quantidades de memria impensveis h pouco tempo, como por exemplo nas cmeras fotogrficas digitais. Estas memrias so baseadas em tecnologia EEPROM, isto , so memrias estticas no volteis. So contudo lentas, o que significa que no podem ser usadas para processamento puro, pois so ordens de grandeza mais lentas que as estticas. O avano tecnolgico porm no est paralisado, e outras memrias como a FRAM (ferromagnetic RAM) j so realidade comercial [Inomata 2001]. Estas memrias possuem a velocidade e a densidade das memrias DRAM, mas so estticas, o que significa muito menos potncia gasta, pois no h necessidade de refresh. Ainda, elas possuem a enorme vantagem de poderem ser fabricadas no mesmo processo que as CPUs convencionais, como uma SRAM. Portanto, o uso de caches para manter a velocidade da CPU alta pode ser pensado quando estas novas memrias estiverem sendo usadas para memria de massa de sistemas embarcados. 2.2.5. Estruturas de comunicao: barramentos e redes em um chip At o final desta dcada os projetistas estaro trabalhando com sistemas em silcio (SoCs) de at 4 bilhes de transistores, usando um processo com transistores de 50-nm de canal [De Micheli e Benini 2002]. evidente que esta abundncia de transistores permitir a integrao de centenas de ncleos de propriedade intelectual, cada um com sua centena de milhares de transistores per se. Contudo, pela quantidade de elementos envolvidos e pelo custo das mscaras de fabricao para estas tecnologias, provvel que o reuso de blocos seja mandatrio. Comunicaes ponto-a-ponto so aquelas mais rpidas, pois o tamanho do fio e o nmero de bits usados na comunicao so projetados sob medida. Por outro lado, esta forma de comunicao a menos reusvel de todas, j que a cada projeto um novo conjunto de terminais deve ser analisado. Quando centenas de ncleos tem de se comunicar, o projeto da comunicao do sistema tende a ser problemtico. Barramentos so reusveis, mas permitem apenas uma transao por ciclo, o que serializa completamente a comunicao. Como todos os ncleos do sistema estaro conectados ao mesmo barramento, e este deve passar por todo o circuito integrado, a capacitncia de carga (devida aos ncleos e ao comprimento do fio) ser elevada, limitando excessivamente a mxima

frequncia que se poderia obter com a comunicao. Alguns destes problemas foram resolvidos pelo uso de barramentos hierrquicos como o Core Connect [IBM 2003] e o AMBA [ARM 1999]. Nestas solues, porm, o mximo paralelismo restrito, e uma comunicao entre ncleos mapeados para sub-barramentos diferentes provocar a paralisao de diversos recursos de comunicao ao mesmo tempo. Este modelo de comunicao adequado a um processador central com vrios perifricos, no a um modelo com vrios processadores complexos executando diferentes tarefas. Embora j existam hoje conceitos de reuso quanto funcionalidade (processadores, memrias, processadores DSP, tocadores de MP3 e outros blocos), os recursos de comunicao somente recentemente mereceram ateno da comunidade internacional. Devido complexidade das funes, heterogeneidade dos blocos e multitude de tarefas que estes SoCs realizaro, provvel que o modelo de computao seja distribudo, isto , no mais centrado em um processador e perifricos. Exemplos de tais sistemas j existem hoje na rea de entretenimento [Paulin 1997, Dutta 2001]. Nesta situao, a comunicao entre os diferentes blocos no pode ter o mesmo paradigma atual (barramentos com ou sem prioridade e multi-nvel). Primeiro, pela escalabilidade. Ao agregar-se mais um ncleo de hardware a um conjunto j existente, o reuso do mesmo barramento implicar em: maior consumo, pelo aumento da capacitncia parasita; menor frequncia disponvel para comunicao, tambm pelo aumento da capacitncia parasita; menor taxa de comunicao, pelo efeito combinado da diminuio de banda (no barramento, quando um mdulo fala os outros devem escutar) e pela diminuio de frequncia.

Alm de se manter a comunicao em altas taxas e escalvel, deseja-se que os mecanismos de comunicao sejam tambm eles reusveis [Zeferino 2002a]. Portanto, os mecanismos de comunicao no futuro devero ser escalveis, oferecer paralelismo para que vrios ncleos conversem ao mesmo tempo, e reusveis, para diminuio do custo de desenvolvimento. Os mecanismos de comunicao baseados em comunicao ponto-a-ponto no so genricos, tendo de ser redimensionados a cada nova verso do sistema. Barramentos, por outro lado, provm um padro, mas no o paralelismo e a escalabilidade necessrios [Guerrier e Greiner 2000, Dally e Towles 2001]. Para atender aos requisitos dos SoCs feitos com centenas de ncleos, alguns trabalhos recentes propem o uso de uma rede em um chip (NoC Networkon-Chip) [De Micheli e Benini 2002]. As origens destes trabalhos encontram-se nas redes de comunicao de arquiteturas paralelas. Aparentemente, Guerrier e Greiner (2000) foram dos primeiros a propor o uso de uma rede de chaveamento para comunicao dentro de um circuito integrado. A rede proposta (Spin Scalable programmable interconnection Network) chaveada a pacotes e tem arquitetura de rvore gorda. Uma NoC composta por um conjunto de canais e de roteadores, que podem ser vistos como ncleos do SoC dedicados comunicao. Cada roteador est conectado a um ou mais ncleos, e possui um conjunto de canais para se comunicar com outros roteadores. A Figura 2.10 apresenta trs topologias bastante utilizadas de NoCs, onde os parmetros acima tambm

podem ser variveis. A mensagem dever passar por tantos roteadores quantos existirem no caminho entre o ncleo origem e o ncleo destino, pelo menos. Como cada roteador possui um tempo diferente de zero para processar a mensagem e decidir o caminho a ser usado, quanto mais longe um ncleo estiver de outro, maior o tempo de comunicao envolvido. Este aparente prejuzo largamente compensado por outros fatores: a NoC pode transmitir uma mensagem numa freqncia maior, pois a capacitncia parasita das conexes menor que a do barramento. Como as conexes entre roteadores so conexes ponto-a-ponto, a incluso de mais ncleos no aumenta a carga capacitiva do fio, e portanto a frequncia de transmisso da informao em um fio maior [Zeferino 2002b]; a NoC permite um paralelismo no presente no barramento. Mesmo que um roteador esteja ocupado, outros roteadores podem estar transmitindo vrias mensagens em paralelo; uma NoC facilmente escalvel, basta colocar-se mais roteadores.

U3 D3

U2 U1 D2 D1

U0 D0

U3 D3

U2 U1 D2 D1

U0 U3 D0 D3

U2 U1 D2 D1

U0 D0

U3 U2 D3 D2

U1 D1

U0 D0

U3 D3

U2 U1 D2 D1

U0 D0

U3 D3

U2 U1 D2 D1

U0 U3 D0 D3

U2 U1 D2 D1

U0 D0

U3 U2 D3 D2

U1 D1

U0 D0

Arvore gorda
Figura 2.10. Diferentes topologias de NoC

A eficincia de uma NoC depende porm de vrios fatores. O tamanho do canal de roteamento (ou seja, quantos fios fazem parte do mesmo), a poltica de prioridade de mensagens, a topologia da prpria NoC (grelha, rvore gorda ou torus, por exemplo) e a estratgia de chaveamento devem ser escolhidas em funo da aplicao [Zeferino 2002b, Karim 2002]. Alm disto, a posio dos ncleos ao redor da NoC pode ser crtica, j que ncleos distantes tero latncia de comunicao aumentada. Como centenas de ncleos devem ser colocados na NoC, o problema de posicionamento logo torna-se crtico. Por fim, importante ressaltar que o custo de um roteador no pequeno. Partindo-se de pelo menos 2000 portas [Zeferino 2002b], a rea extra provocada pelo uso da NoC implica no uso de tecnologias onde os transistores realmente

tenham um baixo custo, embora o fator potncia ainda no tenha sido levado em conta nas publicaes recentes. Uma NOC uma rede de interconexo, e portanto pode ser descrita por sua topologia, poltica de roteamento e controle de fluxo. A topologia diz respeito ao ordenamento dos ns da rede no espao, o roteamento determina como uma mensagem toma um certo caminho no grafo topolgico. O controle de fluxo, por sua vez, trata da alocao de canais e buffers para que uma mensagem percorra o caminho necessrio da fonte at o destino [Dally 1990]. Existem ainda outros parmetros, como a arbitragem e implementao de hardware [Duato 1997]. 2.2.6. Arquiteturas especializadas para sistemas embarcados Das tendncias modernas em arquiteturas de computadores, somente algumas das idias acima discutidas sero efetivamente usadas para sistemas embarcados. O problema da potncia dissipada parece definir que, com os recursos tecnolgicos atuais, o uso de caches de alto desempenho, o sistema de predio de saltos e a execuo fora de ordem das instrues parecem no ser viveis. Mquinas VLIW, como o Cruso [Klaiber 2000], parecem oferecer a combinao correta de desempenho e potncia, com paralelismo descoberto em tempo de compilao, j que a maioria das aplicaes embaracdas so estticas, isto , no so alteradas pelo usurio final. A reconfigurao de hardware [Hartenstein 2001] estar cada vez mais presente nos sistemas embarcados. Embora os FPGAs clssicos tenham alto consumo de potncia, arquiteturas de mais baixa potncia esto sendo estudadas para serem embarcadas em plataformas. A enorme vantagem de se incluir a reconfigurao de hardware a possibilidade extra de personalizao de um chip, e a atenuao do enorme custo de mscaras que as tecnologias nano-mtricas apresentam.

2.3. Modelagem e projeto de alto nvel de sistemas embarcados

Devido possvel complexidade da arquitetura de um sistema embarcado, contendo mltiplos componentes de hardware e software em torno de uma estrutura de comunicao, e grande variedade de solues possveis visando o atendimento de requisitos de projeto, como desempenho, consumo de potncia e rea ocupada, essencial o projeto do sistema em nveis de abstrao elevados e utilizando ferramentas que automatizem ao mximo as diversas etapas de uma metodologia consistente com os desafios existentes. 2.3.1. Metodologia de projeto A Figura 2.11 mostra uma metodologia completa de projeto de um sistema eletrnico embarcado. Esta metodologia ideal, segundo a perspectiva do estado-da-arte da pesquisa na rea, embora na prtica ainda no existam ambientes comerciais de software de projeto que a implementem inteiramente. O projeto de um sistema embarcado iniciado usualmente por uma especificao da funcionalidade desejada, feita atravs de uma linguagem ou formalismo adequado. Idealmente, esta especificao deve ter um alto nvel de abstrao, no qual ainda no tenham sido tomadas decises em relao implementao desta funcionalidade em termos da arquitetura-alvo a ser adotada, nem sobre os componentes de hardware ou software a serem selecionados. Esta especificao deve ser preferencialmente executvel, para fins de validao.

Figura 2.11. Metodologia de projeto

Deve a seguir ser feita uma explorao do espao de projeto arquitetural, de modo a se encontrar uma arquitetura que implemente as funes contidas na especificao inicial e que atenda aos requisitos de projeto, em termos de custo, desempenho, consumo de potncia, rea, etc. O resultado final desta etapa uma macro-arquitetura (ou arquitetura abstrata), contendo um ou mais processadores de determinados tipos (DSP, microcontroladores) e outros componentes necessrios (memrias, interfaces, blocos dedicados de hardware), todos interconectados atravs de uma infra-estrutura de comunicao (um ou mais barramentos ou uma NoC). Entre a especificao funcional e a macro-arquitetura estabelece-se um mapeamento, atravs do qual cada funo do sistema atribuda a um processador ou a um bloco dedicado de hardware. Este mapeamento estabelece um determinado particionamento de funes entre hardware (blocos dedicados) e software (funes implementadas por um processador de instrues). A explorao do espao de projeto deve encontrar uma soluo tima para trs questes bsicas: 1) Quantos e quais so os processadores e blocos dedicados de hardware necessrios? 2) Qual o mapeamento ideal entre funes e componentes de hardware? 3) Qual a estrutura de comunicao ideal para conectar os componentes entre si, tendo em vista as trocas de informaes que devem ser realizadas entre as funes mapeadas para os componentes? Para que esta explorao seja efetuada rapidamente, fundamental a existncia de estimadores que, a partir da especificao funcional do sistema, sejam capazes de informar, com um grau de

preciso adequado, os valores de mtricas importantes de projeto (desempenho, consumo de potncia, rea) que iro resultar de cada alternativa arquitetural (uma macro-arquitetura e um mapeamento de funes). Tendo em vista um espao quase infindvel de solues arquiteturais possveis, com uma correspondente complexidade computacional para explorao do mesmo em busca de uma soluo tima ou mesmo sub-tima, esta etapa usualmente simplificada pela escolha prvia de uma plataforma arquitetural conhecida e adequada ao domnio da aplicao, contendo um ou mais processadores de tipos conhecidos, alm de outros componentes necessrios, todos interconectados atravs de uma estrutura de comunicao tambm pr-definida. Esta opo ser discutida em detalhes na Seo 2.4. Usualmente, diversas funes sero mapeadas para um mesmo processador, sendo ento implementadas como tarefas concorrentes que precisaro ser escalonadas e gerenciadas por um sistema operacional, e caso a aplicao assim o requisite, este dever ser um sistema operacional de tempo real (RTOS). Alm da funo de escalonamento de tarefas, o RTOS deve oferecer recursos para comunicao entre as tarefas, considerando que elas podero estar distribudas entre diversos processadores e mesmo blocos dedicados de hardware. Estes recursos devem oferecer uma abstrao adequada ao software aplicativo, escondendo detalhes de mais baixo nvel da infra-estrutura de comunicao. Tambm acionadores (drivers) dos perifricos devem ser oferecidos, igualmente escondendo detalhes das interfaces e da infra-estrutura de comunicao. Uma vez definida a macro-arquitetura, necessria a gerao do software para a mesma, a partir da especificao funcional do sistema. Idealmente, seria desejvel uma sntese automtica do software, incluindo tanto o software aplicativo como o RTOS. Esta gerao do software bastante facilitada se a especificao funcional inicial tiver sido feita sobre uma interface de programao da aplicao (API application programming interface) padronizada, que oferea recursos para comunicao entre as tarefas e para a qual exista uma implementao sobre a plataforma arquitetural (processadores e RTOS) selecionada. tambm necessrio um compilador, que traduza a especificao funcional para uma linguagem de programao adequada a cada processador adotado (a menos que a especificao funcional j tenha sido feita em uma tal linguagem). Componentes de hardware e software selecionados para a macro-arquitetura podem ter interfaces heterogneas, implementando diferentes protocolos de comunicao. Neste caso, necessria a sntese da comunicao entre os componentes. Esta sntese deve gerar adaptadores (wrappers) que fazem a converso entre os diferentes protocolos. Adaptadores de software podem ser considerados como elementos de um RTOS dedicado gerado para a aplicao, enquanto que adaptadores de hardware so componentes dedicados que ajustam as interfaces dos componentes ao protocolo da infra-estrutura de comunicao (embora conexes ponto-aponto tambm sejam possveis). Uma vez definidos os componentes de hardware da macro-arquitetura, incluindo a infraestrutura de comunicao e os eventuais adaptadores, pode ser feita a sntese do hardware. Numa primeira etapa, a macro-arquitetura pode ser expandida para uma micro-arquitetura (ou arquitetura RT), contendo o detalhamento de todos os componentes e suas interconexes, pinoa-pino e considerando o funcionamento do circuito com preciso de ciclo de relgio. Numa segunda etapa, podem ser usadas ferramentas convencionais de sntese de hardware, que a partir da micro-arquitetura iro gerar o layout final do circuito. Para tanto, necessrio que a micro-

arquitetura esteja descrita numa linguagem apropriada para estas ferramentas, como VHDL ou Verilog. A existncia prvia de layouts para os componentes de hardware selecionados facilita bastante esta sntese, que se limita ento ao posicionamento e roteamento de clulas. Em todas as etapas da metodologia de projeto, necessria uma validao das descries funcionais e arquiteturais geradas. Normalmente, esta validao se d por simulao, sendo portanto necessria a existncia de simuladores adequados para o tratamento das linguagens utilizadas no processo de projeto. Embora ferramentas de verificao formal, que dispensam simulaes exaustivas, sejam bastante atraentes, tais recursos ainda so incipientes no que se refere a sua utilizao extensiva em determinados nveis de abstrao. 2.3.2. Nveis de abstrao Como introduzido na seo anterior, o projeto de um sistema eletrnico embarcado passa por uma seqncia de nveis de abstrao. Como no existe uma padronizao destes nveis, a definio dos mesmos depende de metodologias e ferramentas particulares de projeto. Cada nvel permite a validao de determinadas propriedades de projeto e serve de partida para o processo de sntese para um nvel inferior subseqente. Um esforo de padronizao recente est sendo patrocinado por diversas empresas, divergindo parcialmente da apresentao a seguir [Haverinen 2002]. A especificao inicial de um sistema usualmente feita de uma forma puramente funcional, na qual no h nenhuma informao estrutural ou dependente da arquitetura-alvo sobre a qual o sistema ser implementado. Esta descrio deve ser neutra em relao a possveis implementaes das funes em software ou em hardware, no necessitando conter informaes detalhadas de como implementar os requisitos temporais. O sistema descrito como um conjunto de funes (tarefas ou objetos, dependendo da linguagem adotada), que se comunicam atravs de primitivas de comunicao de alto nvel, por exemplo na forma de mensagens ou de requisies de servios e respostas aos mesmos. Cada transferncia pode transportar diversos itens de dados simultaneamente. Este nvel de abstrao permite a validao da especificao funcional do sistema e serve como entrada para o processo de explorao arquitetural. Uma vez que so tomadas decises em relao arquitetura-alvo do sistema, este descrito no nvel de macro-arquitetura (ou arquitetura abstrata). Apesar da ausncia de muitos detalhes, uma descrio neste nvel de abstrao j permite a obteno de estimativas (de desempenho, potncia, rea) com um grau de preciso suficiente para que sejam tomadas decises no processo de explorao arquitetural. Esta descrio j contm os componentes principais da arquitetura (processadores, blocos dedicados de hardware, memria, interfaces, estrutura de comunicao), assim como o mapeamento entre as funes do sistema e os processadores e blocos dedicados de hardware. No entanto, ainda no esto includos diversos componentes acessrios que sero necessrios, tais como adaptadores de protocolos (wrappers), decodificadores de endereo, gerenciadores de interrupo e temporizadores, que dependem de decises de projeto tomadas posteriormente. A descrio j temporizada, mas no tem a preciso de ciclos de relgio. Tarefas executadas pelos componentes no nvel de macro-arquitetura comunicam-se atravs de mecanismos que j refletem recursos especficos includos na infra-estrutura de comunicao. Exemplos podem ser DMA, memria compartilhada, FIFO's de tamanho finito, escrita direta em registradores, etc., cuja diversidade reflete alternativas possveis para tarefas mapeadas para componentes de hardware ou software. Embora em cada comunicao apenas

um item de dados seja transferido, ainda no h a escolha de um protocolo de comunicao particular. Software j pode ser descrito atravs da linguagem de mquina de cada processador envolvido. No entanto, pela ausncia de preciso temporal, o software tipicamente simulado no nvel de instrues (ISS - instruction-set simulation), e no no nvel do ciclo de relgio. Com isto, os processadores podem estar descritos de forma apenas a refletir o efeito das instrues sobre contedos de memria e de registradores. Uma descrio no nvel de macro-arquitetura pode ser usada como entrada para os processos de sntese de comunicao, de software e de hardware. O resultado deste conjunto de snteses ser a descrio do sistema no nvel de micro-arquitetura (ou nvel RT), no qual o hardware estar inteiramente detalhado em termos de todos os blocos funcionais necessrios, com informao a respeito de todos os seus pinos e das interconexes entre os mesmos. O software estar descrito na linguagem de mquina de cada processador contido na arquitetura, sendo simulado com preciso de ciclo de relgio, o que exige uma descrio detalhada dos processadores, em termos de pipelines e memria cache, por exemplo. A comunicao estar descrita atravs de sinais especficos de determinados protocolos, e cada transferncia transportar um nico item de dados. A descrio serve de entrada para a sntese do layout do circuito integrado, atravs do uso de ferramentas comercialmente disponveis. Outros nveis de abstrao de hardware mais detalhados (portas lgicas, transistores) no so relevantes no contexto do projeto de sistemas embarcados. Usualmente, o sistema projetado pela interconexo de componentes j previamente projetados e validados, e estes nveis de abstrao so relevantes apenas no projeto interno destes componentes. O nvel final de projeto, que o layout do circuito, relevante apenas do ponto de vista do posicionamento dos componentes e do roteamento de suas interconexes, e no do projeto do layout interno de cada componente. 2.3.3. Linguagens de especificao e projeto O projeto de um sistema embarcado passa por diversos nveis de abstrao e orientado a um determinado domnio de aplicao (aplicaes orientadas a dados ou controle, por exemplo). Para a representao de cada domnio, existe um modelo de computao [Edwards 1997] mais adequado. Diferentes linguagens de especificao e de projeto tm sido adotadas para tratamento destes nveis de abstrao e modelos de computao. Para a especificao funcional inicial, importante que a linguagem seja executvel, para fins de validao. Seria tambm desejvel que a linguagem permitisse a descrio de funes de forma neutra em relao a sua implementao em software ou hardware e que pudesse ser utilizada como entrada para um processo de sntese automtica do software sobre a plataforma arquitetural adotada. Por outro lado, poderia ser tambm interessante a adoo de uma linguagem neutra em relao aos domnios de aplicao, requisito que no entanto parece conflitante com a possibilidade de sntese automtica do software, j que este processo altamente dependente da plataforma arquitetural e do domnio de aplicao (modelo de computao). As descries da macro-arquitetura e da micro-arquitetura devem ser feitas em linguagens que possam ser utilizadas como entrada para processos de sntese automtica de hardware, alm de serem evidentemente simulveis.

Linguagens de programao tm sido bastante utilizadas, aproveitando sua popularidade. Este o caso evidente de C e C++. Se, por um lado, C no uma linguagem ideal do ponto de vista do conjunto de requisitos anteriormente estabelecidos para linguagens de especificao, especialmente em relao ao grau de abstrao e generalidade dos domnios de aplicao, ela tem a vantagem de permitir a gerao de software para um grande nmero de processadores utilizados no contexto de sistemas embarcados. A adoo da orientao a objetos, como em C++, se por um lado vantajosa do ponto de vista de especificaes de alto nvel onde reuso e especializao de componentes so caractersticas muito interessantes, por outro lado causa problemas para a sntese de hardware ou tamanho do software. Para a descrio de hardware, as linguagens mais populares so VHDL [VHDL 2002] e Verilog [Verilog 2003]. Sua grande vantagem a possibilidade de serem utilizadas como entrada para simulao e sntese automtica de circuitos descritos no nvel da micro-arquitetura, atravs da utilizao de ferramentas comerciais bastante difundidas. VHDL, no entanto, uma linguagem mais orientada para simulao, de tal modo que algumas de suas construes no so sintetizveis, o que fora ferramentas de sntese a aceitarem apenas um determinado subconjunto da linguagem e/ou estilo de descrio. VHDL e Verilog tm uma semntica orientada apenas para a descrio de hardware, no sendo apropriadas para descries de software nem para especificaes funcionais de alto nvel. C e C++ apresentam um evidente prejuzo quando consideradas como linguagens de projeto no nvel da macro ou da micro-arquitetura, tendo em vista sua inadequao semntica para a descrio de aspectos de hardware. A introduo de SystemC [SystemC 2003] visa justamente sanar este defeito, combinando as vantagens da popularidade de C++ e sua adequao ao processo de gerao de software com uma semntica adicional (na forma de uma biblioteca de funes) apropriada para a descrio de hardware, atravs de construes como portas, sinais, relgios (que sincronizam processos), etc. SystemC 1.0 apresentava uma semntica de hardware muito prxima de VHDL, e portanto mais adequada para descries no nvel RT, exigindo por exemplo a descrio da comunicao entre processos atravs de sinais de um protocolo especfico, o que j reflete uma determinada implementao do hardware. SystemC 2.0, por outro lado, introduziu construes de comunicao e sincronizao de mais alto nvel (canais, interfaces e eventos), permitindo a modelagem de mecanismos mais abstratos de comunicao e, portanto, o uso da linguagem em nveis de abstrao superiores ao nvel RT. Na tentativa de aumentar as possibilidades de modelagem e abstrao, Java tambm tem sido utilizada como ferramenta de descrio e simulao de sistemas [Mulchandani 1998, Mrva 1998, Ito 2000, Ito 2001]. Contudo, o nvel de abstrao oferecido equivalente quele utilizado em C++. Outras linguagens como Matlab [Mathworks 2003] podem ser usadas, devido facilidade de modelagem de fenmenos fsicos e pela possibilidade de descries mistas analgico-digitais. Em especial, Matlab possui mecanismos de resoluo internos que permitem a fcil descrio de aplicaes stream, isto , aquelas em que uma grande quantidade de dados chega a intervalos regulares e conhecidos para processamento. Nenhuma destas linguagens (C, C++, Java, Matlab, VHDL, Verilog, SystemC), no entanto, atende simultaneamente os requisitos de cobertura de mltiplos domnios e nveis de abstrao e de abstrao em relao a implementaes de software e hardware. Rosetta [Alexander e Kong 2001] um esforo recente, ainda no implementado comercialmente, que procura oferecer esta cobertura completa atravs de uma abordagem distinta. Rosetta oferece

uma base sinttica e semntica comum, a partir da qual podem ser descritos e combinados diferentes modelos de computao, cada um deles implementados por uma linguagem especfica. Finalmente, deve ser salientado que as linguagens aqui consideradas so essencialmente destinadas descrio do comportamento e/ou estrutura de um sistema, seja em software e/ou em hardware, e no especificao funcional e/ou de requisitos, o que poderia ser feito com uma linguagem como UML [Fowler 2000]. Esforos recentes tm procurado investigar a utilizao de UML na especificao funcional e de requisitos de sistemas embarcados [Lavagno 2001]. 2.3.4. Compiladores e suas amarras com o modelo arquitetural Os compiladores tm um papel fundamental no desenvolvimento de sistemas embarcados. Como a complexidade dos sistemas cresce continuamente, suportada pela lei de Moore, a gerao de cdigo deve ser numa linguagem o mais abstrata possvel, para diminuir o tempo de projeto. Por outro lado, muitas vezes deve-se programar diretamente em assembler, para melhor atingir os objetivos de projeto de menor consumo e maior desempenho. Esta contudo uma soluo muito custosa, pelo tempo de projeto envolvido. O custo de compiladores adequados para mquinas VLIW, por exemplo, muitas ordens de grandeza maior que o custo de um compilador para uma arquitetura tradicional. Isto se explica no somente pelo volume de vendas, mas tambm pela complexidade do compilador em si, j que ele o responsvel por obter os dados de paralelismo que podero gerar cdigo eficiente. Segundo Paulin (1997), nos domnios de aplicao de sistemas embarcados no mercado de comunicao, 75% dos aplicativos que executam em CPUs tradicionais e 90% daqueles que executam em arquiteturas DSP so escritos em assembler. Isto porque, at o compilador de uma nova arquitetura ficar pronto, j houve mudanas na arquitetura para suportar novas funes requeridas. Para atender a esta necessidade j existem muitas pesquisas em compiladores multialvo (retargeting compilers) [Bhattacharyya 2000, Halambi 1999], que na prtica so geradores de compiladores. A entrada de tais programas uma aquitetura de hardware, descrita em nvel estrutural, relativa ao conjunto de instrues suportado. Ao gerador de compiladores cabe ento re-escrever o compilador, de maneira a tirar o mximo proveito das novas instrues ou das variaes arquiteturais propostas. Infelizmente, o nvel de abstrao no qual os geradores de compiladores trabalham no permite o real reuso de funes. Por exemplo, para que um buffer circular esteja visvel ao conjunto de funes, ele deve ter no apenas instrues equivalentes de assembler, mas definitivamente construes correspondentes de alto nvel na prpria linguagem a ser compilada, sob pena de no ser usado. Este problema repete-se continuamente, j que estratgias de alto nvel so sempre mais eficientes que estratgias mais tardias. Consequentemente, provvel que somente quando o modelo de computao, e consequentemente a linguagem usada para descrever o comportamento do sistema, levar em conta as caractersticas da arquitetura de suporte que ser possvel ter-se uma gerao de cdigo adequada. Tcnicas como pipeline de software, desenrolamento de laos e reordenamento de laos so constantemente utilizadas, j que se o hardware de suporte tem possibilidade de paralelismo, este deve ser explorado ao mximo. 2.3.5. Particionamento entre software e hardware O particionamento de funes entre software e hardware realizado como parte da explorao do espao de projeto arquitetural. A entrada para este processo a especificao funcional do

sistema, idealmente desenvolvida numa linguagem e num estilo de descrio tais que no privilegiem determinados particionamentos. A sada do processo um mapeamento entre cada funo da especificao e um componente da macro-arquitetura (um processador ou um bloco dedicado de hardware). O processo de particionamento evidentemente dependente da macro-arquitetura selecionada. Idealmente, um espao de solues muito mais amplo seria explorado se a prpria definio da macro-arquitetura (nmero e tipos de componentes) fosse resultante de um processo automtico de particionamento, conforme sugerido na Figura 2.12(a). Esta abordagem, no entanto, teria uma complexidade computacional bastante maior, motivo pelo qual usualmente uma macro-arquitetura definida e ento particionamentos diversos so explorados sobre a mesma, como mostrado na Figura 2.12(b). Esta abordagem aceitvel num grande nmero de situaes, onde o projeto na verdade apenas uma variao de um projeto anterior para o qual j foi encontrada uma macro-arquitetura aceitvel.

Figura 2.12. Relao entre particionamento e definio da macro-arquitetura

H uma enorme literatura a respeito do particionamento automtico entre hardware e software [Edwards 1997]. Uma abordagem clssica supe inicialmente que o sistema ser inteiramente desenvolvido em software, sobre um processador conhecido. Uma avaliao de desempenho, atravs de um estimador adequado ou de um simulador, permite identificar partes crticas da aplicao, que comprometem restries temporais. Estas partes so movidas para blocos dedicados de hardware. O processo repetido at que uma soluo aceitvel seja encontrada. Um problema destas abordagens de particionamento automtico, no atual contexto de sistemas embarcados, que elas so geralmente direcionadas ao atendimento de restries de desempenho, desconsiderando a potncia. A maioria delas restrita explorao de plataformas arquiteturais contendo um nico processador, de tipo previamente conhecido. A metodologia pragmtica atualmente adotada prev uma explorao manual, como em ferramentas comerciais como CoCentric System Studio, da Synopsys [Synopsys 2003], onde o prprio projetista faz uma alocao de funes a um ou mais processadores e a blocos dedicados de hardware, todos previamente definidos, interconectados atravs de uma dada infra-estrutura de comunicao, sendo o resultado deste mapeamento avaliado atravs de estimadores (de

desempenho e de consumo de potncia, por exemplo). Assim, a busca de uma soluo aceitvel feita por tentativas sucessivas, processo que evidentemente no garante que uma soluo tima ser encontrada. No entanto, caso os estimadores tenham suficiente preciso e sejam executados com bastante rapidez, o projetista pode encontrar uma soluo sub-tima num curto espao de tempo. Caso a explorao no alcance nenhuma soluo aceitvel, uma nova macro-arquitetura deve ser definida e um novo processo de explorao manual deve ser iniciado. O particionamento de funes entre hardware e software tambm pode ser aplicado na gerao do RTOS, como proposto por Mooney III e Blough (2000), onde uma funo crtica como o escalonamento de tarefas pode ser implementada em hardware em um co-processador dedicado. 2.3.6. Adaptao automtica de cdigo binrio O avano da capacidade computacional dos processadores modernos tal que se podem realizar aplicaes onde se pode permitir uma certa perda de desempenho, para ganho em outros aspectos do projeto. Compatibilidade de software um deles. Como uma larga parte do tempo de desenvolvimento dos sistemas embarcados gasto em software, todo novo avano arquitetural deve manter a herana do software j desenvolvido. Isto evidentemente impe limites nos avanos que os projetistas de arquitetura conseguem alcanar. Contudo, com a lei de Moore seguindo vlida, a quantidade de transistores tamanha que algumas solues comerciais baseadas na traduo binria automtica comeam a aparecer [Altman 01]. A idia central da traduo binria realizar uma arquitetura de CPU otimizada para uma certa funo, capaz de executar um conjunto de instrues livre da necessidade de compatibilidade com o software mais antigo. Assim, pode-se aproveitar todos os avanos de arquitetura disponveis. Resta o problema da herana de software. Para tal, as novas mquinas traduzem, durante a execuo, um cdigo binrio em outro, do software original para a nova arquitetura. Evidentemente, haver uma perda de desempenho, compensada pela enorme capacidade da nova mquina, e pelo fato que, em muitos domnios de aplicao, somente o desempenho bruto no suficiente, devendo-se atentar tambm para a potncia consumida. Este , por exemplo, o caso do processador Cruso [Klaiber 2000], que capaz de executar cdigo nativo para mquinas da famlia x86, mas internamente possui um outro conjunto de instrues, baseado numa arquitetura VLIW. Estes processadores so hoje utilizados em PDAs, por exemplo, pois seu consumo muito mais adequado a aplicaes portteis que os modelos mais recentes da linha x86. Central ao uso de traduo binria est o conceito de escreva uma vez, execute em qualquer lugar. Com a traduo binria, a arquitetura de uma mquina puramente virtual, isto , uma camada de software, e portanto, otimizaes recentes de hardware podem ser compartilhadas por cdigos mais antigos. Como a arquitetura uma camada de software, podese imaginar um cenrio onde se poderia obter via internet o cdigo de uma aplicao, que originalmente somente executaria em estaes de trabalho de uma certa marca, e seria possvel execut-lo numa mquina local, aps o carregamento nesta do modelo de arquitetura desejado. Exemplos de mquinas comerciais que utilizam a traduo binria so a Daisy [Ebcioglu e Altman 1997] e o Cruso [Klaiber 2000]. Daisy uma mquina virtual capaz de executar de 3 a 4 instrues do PowerPC por ciclo. Ela foi projetada para atender ao mercado de servidores, possuindo uma arquitetura VLIW que capaz de executar 8 a 16 instrues nativas por ciclo. A mquina capaz de enderear gigabytes de memria, mas ao menos 100 Mbytes so consumidos

pela mquina interpretadora. O Cruso um processador voltado a outro segmento de mercado, os PDAs. Executa 2 a 4 instrues por ciclo da famlia x86, capaz de enderear entre 64 e 128 Mbytes e consome 16 Mbytes para a mquina virtual. Um Cruso a 667 MHz equivalente a um Pentium III a 500 MHz, mas consome apenas uma frao da potncia, utilizando apenas 7 milhes de transistores. Evidentemente, uma mquina de traduo binria jamais ser mais rpida que uma mquina de execuo nativa, mas, do ponto de vista de sistemas embarcados, a herana de software e a facilidade de troca de plataforma (basta carregar uma nova mquina virtual na arquitetura real) tornam o conceito de traduo binria interessante. Existem no entanto outros problemas alm do desempenho. O sistema de interrupo, para tratamento de sistemas de tempo real, pode ser muito diferente entre a mquina herdada e a mquina real que executa o cdigo. A camada de traduo, por outro lado, introduz mais um fator complicador para a correta previsibilidade do tempo de resposta para um sistema de tempo real. Outro ponto que todas as otimizaes que o compilador possa ter feito para a mquina original sero perdidas, o que pode ter impacto no tempo total de execuo, adicionando mais perda de desempenho interpretao. Aliada aos desenvolvimentos de hardware reconfigurvel [Hartenstein 2001], a traduo binria transforma o software e o hardware em commodities, isto , blocos bsicos gerais que podem ser facilmente adaptados para novos domnios de aplicao. A personalizao e o fato de haver reuso extensivo dos recursos de hardware mais modernos favorecem o projeto baseado em plataformas. Pode-se imaginar um cenrio onde as inovaes de hardware, como uso de FPGAs ou de tecnologias mais modernas com maior capacidade de integrar memrias, possam ser usadas para fazer o hardware mais eficiente, mas mantendo todo o conjunto de aplicaes, sem que se tenha de adaptar o software nova plataforma. 2.3.7. Sntese de comunicao Numa situao ideal, componentes selecionados para uma dada macro-arquitetura teriam interfaces compatveis e poderiam ser conectados diretamente uns aos outros, ou ento atravs de uma estrutura de comunicao tambm consistente. Isto vale tanto para componentes de hardware, por exemplo conectados atravs de um barramento padronizado, como para componentes de software, comunicando-se atravs de funes padronizadas disponveis numa API. Numa situao mais genrica, no entanto, o projetista pode desejar reusar componentes j disponveis que foram desenvolvidos em projetos anteriores, dentro de contextos diferentes, e que podem portanto apresentar interfaces inconsistentes. Este o caso de reuso de componentes de propriedade intelectual (IP), oferecidos por fornecedores externos empresa dentro de um contexto de comrcio eletrnico, ou mesmo desenvolvidos por outras equipes dentro da empresa. Componentes IP de hardware podem ser oferecidos de duas maneiras distintas. Componentes hard j esto sintetizados para uma dada tecnologia-alvo e seu layout que comercializado, j caracterizado quanto aos resultados obtidos em termos de rea, potncia e desempenho. Sua restrio, no entanto, a quase impossibilidade de adaptao para outra situao (outra arquitetura e/ou tecnologia). Componentes soft, por outro lado, so ofertados atravs de descries de mais alto nvel (tipicamente nvel RT), podendo ter suas interfaces e comportamentos adaptados, se necessrio, e sintetizados para diferentes tecnologias-alvo. No entanto, sua caracterizao precisa em termos das mtricas de projeto ter que ser feita pelo projetista do sistema. Componentes IP de software tambm podem ser divididos em

componentes hard, j compilados para um determinado processador e oferecidos atravs de seu cdigo executvel, e soft, descritos numa linguagem de alto nvel. A adaptao de componentes IP a um novo projeto pode ser feita de duas maneiras. No caso de componentes soft, descries de alto nvel esto disponveis e podem ser modificadas de modo que as interfaces de componentes a serem conectados passem a ser consistentes entre si. A adaptao pode tambm afetar a prpria funcionalidade do componente, caso isto seja necessrio no contexto do novo projeto. No caso de componentes hard, no entanto, interfaces heterogneas no podem ser adaptadas atravs de modificaes nas descries dos componentes. Neste caso, imprescindvel o desenvolvimento de adaptadores de comunicao (ou wrappers). Solues para a sntese automtica de adaptadores entre componentes IP de hardware com interfaces heterogneas dependem da existncia de uma descrio formal destas interfaces, como expresses regulares [Passerone 1998] ou mquinas de estados finitos [Smith e DeMicheli 1998]. Mas estas abordagens no se aplicam a componentes de software. A ferramenta TEReCS [Bke 2000] sintetiza software de comunicao entre tarefas, dada uma especificao da estrutura de comunicao e uma alocao de tarefas a processadores. De modo geral, as abordagens de sntese de adaptadores para componentes de software esto associadas gerao de um sistema operacional mnimo e dedicado para uma aplicao, como em TEReCS, ou de pelo menos um escalonador de tarefas dedicado, como em IPChinook [Chou 1999]. Abordagens mais recentes propem o desenvolvimento uniforme de adaptadores de software e hardware. No ambiente COSY [Brunel 2000], existe uma biblioteca de adaptadores de hardware e software previamente desenvolvida e caracterizada em termos de desempenho, oferecendo diferentes esquemas de comunicao (DMA, memria compartilhada, FIFO, escrita e leitura em registradores, etc.). A aplicao descrita inicialmente atravs de um mecanismo abstrato de comunicao. Na medida em que funes so mapeadas para processadores ou blocos dedicados de hardware, selecionados numa macro-arquitetura, o projetista pode escolher manualmente os esquemas de comunicao que julga mais apropriados, realizando a seguir uma avaliao do desempenho global do sistema resultante desta escolha. No ambiente ROSES [Cesario 2002], adaptadores de hardware e software so sintetizados automaticamente a partir da composio de elementos bsicos disponveis em bibliotecas expansveis, tambm a partir de uma seleo de mecanismos de comunicao feita manualmente pelo projetista. A abordagem ROSES tambm est associada gerao de um sistema operacional mnimo e dedicado [Gauthier 2001]. Note-se que, mesmo que um componente de hardware tenha sido desenvolvido com uma interface consistente com algum padro de barramento, ainda assim a integrao deste componente a um sistema construdo em torno deste barramento exigir a incluso de alguma lgica adicional. A ferramenta Coral [Bergamaschi 2001], por exemplo, que permite a integrao de componentes consistentes com o padro de barramento CoreConnect da IBM, d suporte a tarefas como as definies de mapas de memria acessados pelos diferentes componentes e de prioridades de componentes num sistema de interrupo e num esquema de arbitramento do barramento. 2.3.8. Estimadores A explorao do espao de projeto num alto nvel de abstrao depende da existncia de estimativas suficientemente precisas dos resultados finais a serem obtidos na implementao do

sistema para cada alternativa de projeto considerada. So necessrias estimativas para mtricas relevantes de cada projeto, como desempenho, consumo de potncia e rea no silcio. A obteno destas estimativas deve atender dois requisitos principais: preciso e velocidade. Se por um lado deseja-se alta preciso, esta por outro lado s pode ser obtida com estimativas feitas em nveis de abstrao mais baixos, que usualmente dependem de uma sntese de software e hardware que pode ser demorada e exigir diversas outras decises de projeto mais detalhadas. Compromete-se assim uma rpida explorao dos potenciais impactos causados por decises arquiteturais de alto nvel. evidente que, em qualquer caso, as estimativas devem considerar a plataforma arquitetural sobre a qual o sistema embarcado ser implementado. Uma estimativa de desempenho pode ser usualmente obtida atravs de simulao num nvel de abstrao que considere aspectos temporais. O nvel de abstrao a ser escolhido, no entanto, depende da preciso desejada para a estimativa. Se a estimativa for feita no nvel da micro-arquitetura, isto exigir que o software aplicativo seja compilado para o processador adotado na plataforma e que exista uma descrio detalhada do hardware no nvel RT. Isto exigir uma sntese de software e hardware bastante demorada, o que inviabiliza a idia da rpida explorao do espao de projeto. Como alternativa num nvel de abstrao mais alto, pode-se anotar o cdigo fonte da aplicao (por exemplo escrito em C) com atrasos estimados para cada comando ou grupo de comandos. Isto exige obviamente uma caracterizao prvia do tempo consumido por estes comandos quando executados sobre o processador desejado. No se pode desprezar nesta anlise o efeito do compilador sobre a qualidade do cdigo gerado. Tambm o efeito da implementao do sistema operacional pode ser considerado, desde que existam estimativas razoveis sobre o custo de funes importantes como o escalonamento de tarefas e a comunicao entre tarefas. Bacivarov (2002), por exemplo, anota uma descrio funcional da aplicao, incluindo o RTOS, com estimativas de desempenho, e compila esta descrio para a linguagem nativa do computador hospedeiro da simulao, o que garante processamento muito rpido. Estimativas de desempenho so tambm necessrias para a anlise de escalonabilidade de tarefas em sistemas operacionais, assunto que abordado na Seo 2.4. Uma estimao de alto nvel da potncia consumida por uma aplicao embarcada pode ser baseada na soma das potncias consumidas nas instrues executadas pelo processador durante a aplicao [Tiwari 1994]. Cada instruo tem um consumo que definido, a partir de experimentaes prvias, pela mdia da corrente eltrica requerida na execuo repetida daquele tipo de instruo, conforme ilustrado na Tabela 2.1 para diferentes instrues do processador 486DX2. Este mtodo pode ser refinado com modelos especficos de consumo de potncia para diferentes componentes arquiteturais, como unidades funcionais, bancos de registradores, barramentos, memrias e unidades de controle, que so afetados pelas instrues do programa [Dalal e Ravikuman 2001, Choi e Chaterjee 2001, Chen 2001, Givargis 2001]. Estes modelos consideram o tipo de atividade (variaes de valores de sinais) ocorrido na entrada de cada componente, assim como propriedades fsicas de cada componente. Outras abordagens [Landman e Rabaey 1996, Simuni 1999] propem uma estimativa de potncia mais precisa a partir da simulao no nvel dos ciclos de relgio, tambm considerando a potncia consumida por cada bloco funcional. A implementao de simuladores de cdigo compilado permite compensar o maior tempo de processamento exigido por este nvel de abstrao. Embora simuladores de potncia no nvel de instruo tenham a velocidade como maior vantagem, eles produzem resultados menos acurados e eventualmente at incorretos. Deve-se

notar sua incapacidade de considerar bolhas em pipelines, causadas por dependncias de dados e de controle, assim como falhas em caches, TLB's (Translation Look-aside Buffers) e BTB's (Branch Table Buffers). A desvantagem dos simuladores no nvel de ciclo de relgio, alm do maior tempo de processamento, a necessidade de se dispor de uma descrio detalhada da arquitetura, usualmente no nvel RT. Enquanto a maioria dos simuladores deste tipo est restrito arquitetura de um processador em particular, Beck Filho et alii [2003] apresentam um simulador que aceita como entrada a descrio de uma arquitetura qualquer, a partir da interconexo de componentes arquiteturais quaisquer, para os quais no entanto devem ser providos modelos adequados de consumo de potncia.
Tabela 2.1. Corrente exigida em instrues do processador 486DX2 [Tiwari 1994]

2.3.9. Validao Ao longo do processo de projeto, inmeras descries do sistema embarcado so geradas, em diferentes nveis de abstrao (especificao funcional, macro-arquitetura, micro-arquitetura), cobrindo diferentes aspectos (software e hardware) e eventualmente com a utilizao combinada de diferentes linguagens (p.ex. Java e VHDL). Estas descries precisam ser validadas, o que exige a execuo das descries, no caso de linguagens de programao como Java e C, ou sua simulao, no caso de linguagens de descrio de hardware ou de sistemas como VHDL e SystemC. Conforme j discutido na Seo 2.3.3, nenhuma das linguagens consegue cobrir simultaneamente todos os domnios de aplicao, nveis de abstrao e aspectos de hardware e software. Assim, bastante comum a necessidade de validao de descries multi-linguagem em determinados passos do projeto. Um exemplo evidente a validao combinada da microarquitetura, descrita por exemplo em VHDL, e do software que ir rodar sobre um processador. Outro exemplo a validao de um sistema embarcado contendo partes de hardware digital, descritas em VHDL, hardware analgico, descrito por equaes diferenciais em Matlab, e software, descrito em C. Por outro lado, a validao de um sistema muito complexo pode ser bastante facilitada por um processo de refinamentos sucessivos, no qual apenas partes selecionadas do sistema so descritas num nvel de abstrao mais detalhado (p.ex. micro-arquitetura), enquanto o restante do sistema permanece descrito de forma mais abstrata (p.ex. como macro-arquitetura ou mesmo como componente puramente funcional). Esta abordagem, que permite melhor focalizar as decises de projeto que precisam ser validadas a cada novo passo de refinamento, tambm pode resultar em descries multi-linguagem. Exemplos de co-simulao entre VHDL e C so encontrados nos simuladores VCI [Valderrama 1998] e SIMOO [Oyamada e Wagner 2000]. Ferramentas de co-simulao atuais,

como CoCentric System Studio, da Synopsys [Synopsys 2003], e Seamless CVE, da Mentor [Mentor 2003], permitem a integrao de SystemC, C, simuladores de software no nvel de instrues de mquina de um processador e HDLs diversas, como VHDL e Verilog. MCI [Hessel 1999] um exemplo de soluo genrica, que permite a gerao de modelos de cosimulao a partir de uma especificao multi-linguagem do sistema. No entanto, a co-simulao d-se atravs de um mecanismo de comunicao proprietrio, como nas solues comerciais. O ambiente Ptolemy [Davis II 2001] adota uma abordagem orientada a objetos na modelagem do sistema, e oferece um reportrio de classes explicitamente orientado co-simulao de diferentes modelos de computao. No contexto de reuso de componentes IP, torna-se interessante o desenvolvimento de simulaes distribudas, nas quais componentes IP sejam simulados remotamente, no site de seus fornecedores, visando a proteo da propriedade intelectual. O ambiente JavaCAD [Dalpasso 1999] oferece este recurso, mas est restrito a componentes descritos em Java, assim como o ambiente proposto por Fin e Fummi (2000) est restrito a componentes VHDL e Verilog. Solues mais genricas, abertas a diversas linguagens, so propostas pelos ambientes WESE [Dhananjai 2000], baseado em CORBA, e DCB [Mello e Wagner 2002], inspirado no padro HLA [HLA 2000] de simulao distribuda. A validao por simulao apresenta duas grandes restries. Em primeiro lugar, o nmero de casos de testes para uma validao exaustiva da descrio do sistema grande demais, obrigando os projetistas na prtica a limitarem-se a uma cobertura parcial dos mesmos. Em segundo lugar, quanto mais baixo o nvel de abstrao, maior o nmero de casos de teste e mais demorada a simulao, pelo maior detalhamento da descrio. Tcnicas de verificao formal [Edwards 1997], que realizam uma validao simblica do sistema, e no numrica, prometem resolver este problema por cobrirem todos os possveis casos de teste atravs de um nico processamento. No entanto, tais tcnicas ainda no atingiram um grau de maturidade suficiente que permita sua aplicao em larga escala em todo o processo de projeto, estando limitadas a determinadas combinaes de linguagens, estilos de descrio, domnios de aplicao e nveis de abstrao.

2.4. Projeto baseado em plataforma

O grande espao de solues arquiteturais possveis para a implementao de uma determinada aplicao embarcada torna o processo de explorao arquitetural computacionalmente muito complexo. O reuso de plataformas de hardware e software, padronizadas e previamente validadas, orientadas para determinados domnios de aplicao, permite uma grande reduo no espao de solues e portanto no tempo de projeto de um novo sistema. 2.4.1. Plataformas, derivativos e componentes IP Uma plataforma uma base comum de hardware e software que pode ser reutilizada em projetos de diferentes sistemas embarcados [Sangiovanni-Vincentelli e Martin 2001, Keutzer 2000]. Esta base comum pode ser composta, do lado de hardware, por uma micro-arquitetura praticamente fixa, com ou mais processadores e outros componentes complementares, interconectados atravs de uma estrutura de comunicao, e, do lado de software, por um RTOS (incluindo acionadores de perifricos) acessvel atravs de uma API (Application Programming Interface). Esta base padronizada, de tal modo que seus componentes principais no precisam ser novamente revalidados a cada novo projeto. No entanto, tendo em vista necessidades especficas de cada

nova aplicao, esta plataforma precisa oferecer um grau adequado de parametrizao e configurao. Assim, como exemplos, a plataforma pode estar aberta incluso de novos blocos dedicados de hardware, a capacidade de sua memria pode ser definida para cada aplicao e o RTOS pode ser configurado apenas com os servios indispensveis aplicao. Chama-se de derivativo o projeto de um novo sistema a partir da configurao ou parametrizao da plataforma bsica. No projeto de um derivativo, o maior esforo reside no desenvolvimento (especificao, projeto, depurao) do software aplicativo, j que a configurao do hardware e do RTOS pode ser feita de forma quase automtica, com uma razovel certeza quanto ao correto funcionamento dos mesmos. a API, que oferece ao software aplicativo os servios bsicos implementados pela micro-arquitetura e pelo RTOS, que abstrai os detalhes de baixo nvel da plataforma e permite o projeto de um derivativo baseado quase exclusivamente no desenvolvimento do software aplicativo. Esta API pode ser considerada como uma plataforma de software, que, junto com a plataforma de hardware (a micro-arquitetura), forma uma plataforma de sistema. O projeto baseado em plataformas depende da existncia de componentes de hardware e software reusveis e compatveis com os padres estabelecidos pela plataforma. Uma plataforma pode estar por exemplo baseada em um microcontrolador ARM conectado a outros componentes atravs de um barramento AMBA [ARM 1999], incluindo um RTOS VxWorks [WindRiver 2003] configurvel e dedicado a este processador. Para o projeto de um derivativo desta plataforma, novos componentes de hardware cujas interfaces sejam compatveis com o barramento AMBA podem ser includos. Da mesma forma, componentes de software compatveis com os servios oferecidos pelo RTOS podem ser utilizados no desenvolvimento da aplicao. Este estilo de projeto incentiva o surgimento de fornecedores de componentes reusveis, ditos de propriedade intelectual (IP) [Design&Reuse 2003]. Igualmente desejvel no projeto baseado em plataformas e no reuso de componentes IP a possibilidade de caracterizao prvia, com alto grau de preciso, dos componentes arquiteturais bsicos (hardware e RTOS), de modo que possvel a obteno de estimativas precisas do impacto do derivativo de uma plataforma desenvolvido para uma dada aplicao. 2.4.2. Plataformas de software Sistemas operacionais (SO) possuem quatro funes principais: gerncia de processos (ou tarefas), comunicao entre processos, gerncia de memria e gerncia de E/S. A gerncia de processos inclui aspectos como criao, carga e controle da execuo de processos. Na funo de comunicao entre processos devem ser consideradas questes como sincronizao entre processos, deteo e tratamento de deadlocks e mecanismos de troca de dados. A gerncia de memria inclui a criao, remoo e proteo de arquivos. Finalmente, a gerncia de E/S responsvel pelo controle de comunicao com os perifricos, incluindo tratamento de interrupes. Um sistema operacional de tempo real (RTOS) [Burns e Wellings 1997] um SO cujo funcionamento adequado, alm de cobrir as funes acima, depende do atendimento correto de requisitos temporais associados execuo dos processos, tais como deadlines (tempos mximos de execuo) e perodos de processos peridicos (intervalos de tempo entre incios sucessivos de execuo de um processo). A principal conseqncia das restries temporais incide sobre o escalonamento de tarefas, funo associada gerncia de processos. Num RTOS, tarefas sempre tm uma prioridade associada, definida de acordo com critrios que podem

variar, como forma de garantir o atendimento das restries temporais, e devem ser preemptivas, ou seja, devem poder ser interrompidas por tarefas de maior prioridade. Uma tarefa em um RTOS nunca tem sua execuo iniciada apenas porque ela est pronta para executar, como ocorre em um SO convencional, mas sim porque tem prioridade mxima naquele instante de tempo. Um RTOS utiliza temporizadores que permitem programar interrupes para execuo de funes como o escalonamento de tarefas. Algoritmos de escalonamento de tarefas podem ser divididos em estticos e dinmicos. Em algoritmos estticos, que apresentam menor overhead em tempo de execuo, a prioridade das tarefas definida estaticamente. O algoritmo esttico mais conhecido o RMS (Rate Monotonic Scheduling), que atribui a cada tarefa uma prioridade inversamente proporcional ao deadline da mesma. Este algoritmo garante a escalonabilidade das tarefas caso a utilizao da CPU no ultrapasse 69%. A perda de 30% no tempo til do processador pode levar exigncia de um processador operando a uma freqncia mais alta (e portanto consumindo mais potncia) para atender os requisitos temporais do conjunto de tarefas da aplicao. Nos algoritmos dinmicos, a prioridade das tarefas pode ser alterada dinamicamente pelo prprio RTOS. O algoritmo dinmico mais conhecido o EDF (Earliest Deadline First), no qual a tarefa que, num dado momento, deve concluir mais rapidamente sua execuo recebe a mxima prioridade. Algoritmos dinmicos garantem a escalonabilidade das tarefas at 100% de utilizao da CPU, mas apresentam maior overhead em tempo de execuo. A Figura 2.13 mostra um exemplo de escalonamento de tarefas segundo os algoritmos RMS e EDF.

Figura 2.13. Algoritmos de escalonamento

Um problema associado ao escalonamento das tarefas a necessidade de utilizao de estimativas de tempo de execuo das tarefas que correspondem ao pior caso (WCET WorstCase Execution Time), como forma de se garantir que os deadlines sero atendidos mesmo em situaes extremas. Esta exigncia mais forte em sistemas de tempo real hard, onde a perda de deadlines pode levar a efeitos inaceitveis (por exemplo em termos de segurana). Como conseqncia de um escalonamento baseado em WCET, pode-se tambm criar a necessidade de um processador operando a uma freqncia bem mais alta do que seria exigido considerando-se apenas os tempos tpicos de execuo da tarefa, que podem ser bastante inferiores ao WCET. Mtricas para a avaliao de RTOS incluem, entre outras, a latncia das interrupes (tempo decorrido entre o pedido de interrupo e seu atendimento completo), o tempo de chaveamento de contexto, a resoluo do relgio dos temporizadores e o tempo de execuo das diversas chamadas do sistema. RTOS dedicados a aplicaes embarcadas [Li 1997, Stepner 1999] precisam atender outros requisitos, alm daqueles naturalmente j exigidos por sistemas operacionais de tempo real. Em primeiro lugar, eles devem ser escalveis, ou seja, no devem oferecer um conjunto completo de servios de forma monoltica, mas sim como uma biblioteca de mdulos, a serem facilmente selecionados no momento da gerao da aplicao de acordo com as suas necessidades especficas. Em segundo lugar, eles devem atender restries de projeto da aplicao. Uma destas restries justamente o tamanho da memria exigida, restrio esta j parcialmente atendida pela caracterstica de escalabilidade. No entanto, adicionalmente o RTOS embarcado deve tambm considerar restries de desempenho e consumo de potncia. Existe grande nmero de sistemas operacionais de tempo real comerciais, alguns deles desenvolvidos especificamente para sistemas embarcados, tais como VxWorks [WindRiver 2003], RTLinux [2003], Virtuoso [Transtech 2003] e eCos [Red Hat 2003]. A diversidade de produtos comerciais reflete claramente a grande diversidade de aplicaes de tempo real e embarcadas, sem que exista uma grande padronizao de requisitos que conduza predominncia de poucos produtos no mercado. 2.4.3. Reuso de software Conforme j introduzido previamente, a gerao do software aplicativo de uma aplicao embarcada seria extremamente facilitada caso fosse oferecida uma API (Application Programming Interface) padronizada, que abstrasse da aplicao todos os detalhes de mais baixo nvel, no apenas do hardware, mas tambm do RTOS, conforme ilustrado na Figura 2.14. Esta API deve incluir todos os servios oferecidos ao programa do usurio pelo RTOS, por exemplo para gerncia de E/S e para comunicao entre processos. A existncia desta API promove o reuso de todo o software aplicativo desenvolvido sobre a mesma, tornando-o independente das implementaes possveis desta API atravs de diferentes RTOS e plataformas de hardware. O software aplicativo torna-se assim automaticamente portvel para diferentes plataformas. Alm disto, esta API permite o projeto concorrente do software aplicativo e da plataforma do sistema, encurtando enormemente o tempo de projeto em relao abordagem convencional, na qual o software aplicativo s pode ser desenvolvido e validado depois do projeto da plataforma.

Figura 2.14. Interfaces padronizadas de software

A implementao do sistema embarcado, portanto, passa a corresponder ao projeto do RTOS e da plataforma de hardware de forma a implementar a API, atendendo simultaneamente aos requisitos da aplicao. Evidentemente, apenas os servios disponibilizados pela API que so necessrios para a aplicao especfica precisam ser implementados. Existem esforos de padronizao da especificao dos servios a serem oferecidos no contexto de RTOS para sistemas embarcados. Como a padronizao feita sobre uma especificao, isto permite o desenvolvimento de um SO dedicado para cada situao, j que ele no precisa implementar toda a especificao, atendendo-se assim a exigncia de escalabilidade. Exemplos so as especificaes OSEK [OSEK 2003], orientada ao domnio automotivo, e ITRON [Itron 2003], para produtos eletrnicos de pequeno porte, como cmeras digitais e aparelhos de fax. No entanto, tambm na implementao do RTOS pode-se promover o reuso de software. O RTOS pode ser dividido em duas partes, uma delas dependente da plataforma de hardware (HdS Hardware-dependent Software) e outra independente da mesma. Estas duas partes podem ser explicitamente separadas atravs de uma HAL (Hardware Abstraction Layer) [Yoo e Jerraya 2003], conforme mostrado na Figura 2.14. A HAL uma API que oferece ao RTOS uma abstrao do hardware, promovendo assim o reuso, para diferentes plataformas, do cdigo do RTOS que independente de hardware. Exemplos de HdS incluem cdigo para inicializao (boot) do sistema, para chaveamento de contexto e para configurao e acesso a recursos de hardware, como MMU, barramentos, interfaces e temporizadores. Os acionadores (drivers) de dispositivos perifricos so em grande parte dependentes do hardware, sendo assim tipicamente oferecidos no nvel da HAL. De forma similar API no nvel do software aplicativo, a HAL permite o projeto concorrente do hardware e de um RTOS mnimo e dedicado que atende aos requisitos da aplicao embarcada. O conceito de HAL tem sido utilizado por diferentes RTOS, como WindowsCE (atravs dos BSP's board support packages) [Microsoft 2003], eCos e RT-Linux. Mas no existem ainda padres para a HAL. Recentemente, a VSIA [Shandle e Martin 2002] criou um grupo de trabalho visando o estudo de HdS e a padronizao da HAL. 2.4.4. Sntese automtica do RTOS No projeto de um sistema embarcado, deve ser feita uma deciso entre o uso de um sistema operacional genrico ou sintetizado a partir das necessidades especficas de uma aplicao.

Conforme j mencionado, existe um grande nmero de sistemas operacionais de tempo real comerciais desenvolvidos especificamente para sistemas embarcados. Eles so de modo geral modulares, podendo portanto ser configurados de acordo com as necessidades de uma determinada aplicao. Sua flexibilidade permite que sejam portados para diferentes plataformas. Ainda assim, apesar desta configurabilidade, sua generalidade e a granularidade dos mdulos resultam na gerao de um SO com tamanho que pode ser excessivo em aplicaes onde a rea ocupada pela memria um fator crtico. Alm disto, o mtodo de gerao privilegia apenas uma certa diminuio no tamanho do cdigo do SO, sem considerar a otimizao de outros fatores crticos no projeto de sistemas embarcados, como desempenho e consumo de potncia. Outro problema crucial a necessidade de adaptao do SO para cada nova arquiteturaalvo, alm da adaptao do software aplicativo para esta combinao de SO e arquitetura (questo j discutida na Seo 2.3.6). No contexto de sistemas embarcados, cada sistema pode ter por exemplo diferentes organizaes de memria (com diferentes mapas de endereo) e sistemas de E/S (diferentes estruturas de barramentos e tipos de perifricos, com diferentes endereos e nveis de interrupo), o que exige reconfigurao do SO. Usualmente, tanto a adaptao do SO como o mapeamento do software aplicativo so feitos manualmente, num processo demorado e propenso a erros. Os motivos acima expostos justificam esforos para o desenvolvimento de mtodos de sntese automtica de um SO dedicado e que atenda requisitos da aplicao, em termos de desempenho e/ou consumo de potncia e/ou rea de memria. A ferramenta TEReCS [Bke 2000] objetiva a sntese de um RTOS mnimo e dedicado, com nfase nas estruturas de comunicao. O SO construdo a partir de uma biblioteca prdefinida de servios denominada DREAMS. Os servios disponveis esto organizados nesta biblioteca atravs de relaes de dependncia. A partir de uma anlise das necessidades de comunicao da aplicao, a ferramenta TEReCS seleciona os servios imediatamente necessrios para implementar esta comunicao, alm dos demais servios dos quais aqueles dependem, adicionando-os a um kernel mnimo (o zeroDREAMS). No ambiente ROSES [Gauthier 2001], est disponvel uma biblioteca de elementos bsicos, descritos numa linguagem de macros, que podem ser configurados e compostos para a gerao automtica de um RTOS. Esta abordagem tambm est fortemente voltada para a sntese automtica da comunicao entre processos que podem estar alocados a diferentes processadores. Mas a ferramenta tambm gera automaticamente um escalonador de tarefas para cada processador. No projeto de um sistema de pequeno porte, relatada a gerao de SO com apenas 1,86 Kbytes de tamanho. As abordagens TEReCS e ROSES, no entanto, no consideram a otimizao de desempenho e de potncia. Outra idia que comea a ser explorada a implementao em hardware de funes crticas de um RTOS [Mooney III e Blough 2002], visando aumento de desempenho ou atendimento de restries temporais severas. Uma funo que boa candidata a uma implementao em hardware o escalonador de tarefas, especialmente em aplicaes crticas no tempo que apresentem um nmero grande de chaveamentos de contexto. Na UFRGS, iniciou-se recentemente um trabalho de explorao do espao de projeto de um RTOS dedicado, considerando restries de desempenho, consumo de potncia e ocupao de memria. Primeiros experimentos visaram a avaliao do impacto de diferentes mecanismos de comunicao [Gervini 2003] e escalonadores sobre estas mtricas. 2.4.5. Reuso de componentes IP

Existe uma contradio no mercado atual de semicondutores, pois ao mesmo tempo em que a indstria de semicondutores possibilita a criao de sistemas completos em silcio (SoC Systems-on-Chip) atravs do avano tecnolgico, os projetistas no tm como lidar com a complexidade destes sistemas. Por exemplo, em 2001 a produtividade dos projetistas, medida em transistores por homem-ms, era de aproximadamente 2 mil. Os recursos tecnolgicos, contudo, permitiam a integrao de 100 milhes de transistores com a mesma tecnologia do perodo [Magarshack 2002]. Um circuito de um milho de transistores levaria 500 homens-ms para ser implementado, ou aproximadamente 42 homens trabalhando durante um ano. A soluo para o problema de projeto passa pelo reuso de componentes pr-projetados, j testados em outro projetos. O reuso, alm de possibilitar um menor tempo de projeto (j que a maioria dos mdulos estaria pronta a ser usada), possibilitou um mercado de vendas de ncleos de hardware para serem utilizados por diferentes clientes, mantendo a propriedade intelectual do fornecedor do ncleo. Estes mdulos so chamados de blocos IP (Intellectual Property). Nos ltimos tempos houve portanto um deslocamento do problema de projeto. Se antes a validao de um bloco e a automao do projeto do mesmo passavam por uma descrio no nvel de transferncia de registradores (RTL) e posterior sntese, hoje os grandes projetos so feitos atravs da escolha adequada dos componentes que devero fazer parte do SoC. A escolha adequada de quais componentes utilizar no no entanto suficiente. A integrao de diversas partes feitas por diferentes fabricantes um problema conhecido da comunidade de engenharia, j que o projeto de placas vem sendo feito com este estilo h muito tempo. Contudo, ao se colocar um conjunto de blocos pr-projetados em uma mesma pastilha de silcio, os problemas de projeto em nvel sistema tornam-se mais prementes. Em especial, a arquitetura final do sistema, o desempenho e a potncia que se devem obter, os tipos de interface, a comunicao entre os mdulos, o floorplanning global que permita a correta distribuio de sinais eltricos importantes como o relgio e ainda outras questes passam a ser fundamentais para o projeto de SoCs. Por exemplo, a Figura 2.15 apresenta uma arquitetura de SoC possvel de ser encontrada em vrias aplicaes, desde um telefone porttil at o controle de um sistema automotivo. Portanto, do ponto de vista do sistema, muito importante no somente o reuso dos blocos, mas o que esperar de cada um, como coloc-lo no sistema de modo a manter o desempenho global, como garantir este desempenho global e a possibilidade de alteraes a posteriori, j que quanto mais complexo um sistema, maiores as chances que ele tenha de ser adequado a diferentes contextos. ROM microprocessador RAM

Interface externa

DMA

DSP

Flash

Figura 2.15. Arquitetura facilmente encontrvel em mltiplos projetos

No sistema descrito atravs da Figura 2.15 pode-se observar a presena de ao menos dois microprocessadores, j que a maioria dos sistemas tem de executar comportamentos muito diferentes, dependendo do modelo de computao adequado. certo tambm que sistemas em silcio faro uso abundante de memrias, para que estas forneam cdigo e dados para os diferentes processadores presentes no sistema. Circuitos de acesso a perifricos como controladores de DMA, controladores de disco em memrias flash e interfaces com o mundo real (analgico) devem tambm estar presentes. 2.4.6. Projeto baseado em padres de barramentos e de interfaces de ncleos A integrao de componentes IP em uma plataforma arquitetural extremamente facilitada se esta plataforma for baseada em padres para diversos de seus aspectos. Uma padronizao importante diz respeito infra-estrutura de comunicao, em torno da qual devem estar conectados os componentes de hardware. Numa abordagem de projeto baseado em barramentos, os componentes esto interconectados por um ou mais barramentos, os quais esto por sua vez conectados entre si atravs de pontes. Como a especificao funcional, fsica e eltrica de um barramento pode ser padronizada, bibliotecas de componentes IP cujas interfaces se ajustam diretamente a este padro podem ser desenvolvidas, permitindo que o projeto da micro-arquitetura do sistema seja feita facilmente atravs da conexo direta dos componentes ao barramento. Esta abordagem tem sido adotada por diversas empresas que oferecem solues para o projeto de sistemas embarcados, tais como IBM, com o padro CoreConnect [IBM 2003], ARM, com o padro AMBA [ARM 1999], e Sonics, com o padro Silicon Backplane MicroNetwork [Sonics 2003]. Cada uma destas empresas oferece, alm do barramento padronizado, tambm ricas bibliotecas de componentes e ambientes de desenvolvimento de sistemas baseados nestes barramentos. Mesmo componentes cujas interfaces no sejam compatveis com o padro podem ser reutilizados no projeto, desde que sejam desenvolvidos adaptadores de interfaces, conforme j discutido na Seo 2.3.7. A Figura 2.16 mostra a arquitetura tpica de um sistema construdo em torno do padro AMBA (Advanced Microcontroller Bus Architecture). Trs barramentos distintos so definidos no padro. O barramento AHB (Advanced High-performance Bus) o principal, ao qual esto conectados o processador central do sistema, memria on-chip e dispositivos de acesso direto memria (DMA), e que sustenta a largura de banda exigida para transferncias de dados de/para uma memria externa de grande capacidade. Usualmente, o processador principal do sistema o microcontrolador ARM, bastante utilizado em aplicaes embarcadas e consistente com o padro AMBA. Um processador secundrio tambm poderia ser conectado a este barramento. Para atingir alto desempenho, este barramento apresenta caractersticas como transferncias de dados em rajada, transaes split e larguras de dados de 64 ou 128 bits. Ele permite um ou vrios mestres (processadores e dispositivos de DMA). Escravos tpicos so as memrias e uma ponte para um barramento APB (Advanced Peripheral Bus). Um arbitrador garante que apenas um mestre poder iniciar transferncias de dados a cada momento. Um decodificador de endereos gera um sinal de seleo para o escravo endereado por uma transferncia. O APB um barramento secundrio destinado a conectar um nmero arbitrrio de perifricos que exijam pequena largura de banda para transferncia de dados. Aproveitando sua simplicidade, ele tambm projetado para baixo consumo de potncia. O terceiro padro do barramento, ASB (Advanced System Bus), uma verso anterior do AHB, com menor nmero de funcionalidades.

Figura 2.16. Arquitetura tpica de sistema baseado no padro de barramento AMBA

Numa abordagem distinta, interfaces de componentes podem seguir um padro que independente de barramentos e que permite a conexo direta de um componente a outro. Esta abordagem seguida pelos padres VCI (Virtual Component Interface), da VSIA (Virtual Socket Interface Alliance) [VSIA 2003], um consrcio de empresas cujo objetivo a definio de padres em diversas reas do projeto de sistemas embarcados, e OCP (Open Core Protocol), originalmente desenvolvido pela empresa Sonics e agora promovido pela organizao OCP-IP [OCP 2003]. Esta abordagem de projeto baseada em ncleos (ou, do ingls, cores), por oposio abordagem baseada em barramentos. Componentes consistentes com um destes padres de interface tambm podem ser conectados atravs de um barramento, numa situao que exige a incluso de adaptadores entre a interface do componente e o barramento. Esta a abordagem adotada pela empresa Sonics, por exemplo, onde componentes com interfaces OCP so conectados a um barramento Silicon Backplane MicroNetwork atravs de adaptadores padronizados. O padro OCP, por exemplo, prev um amplo espectro de funcionalidades, que podem ser agregadas seletivamente a um componente, de modo que este ter a interface com a complexidade estritamente necessria para a aplicao especfica. Assim, na sua forma mais simples o padro prev unicamente os sinais de interface necessrios para leituras e escritas isoladas de dados, atravs de um protocolo simples de tipo handshake. Em cada conexo um componente considerado mestre e outro escravo. Um componente que opere como mestre e como escravo precisar sinais duplicados. Extenses neste protocolo bsico permitem transferncias em rajada, transferncias em pipeline e at transferncias concorrentes de mltiplas threads. Extenses complementares so definidas para interrupes, teste e reinicializao de componentes. Note-se que este tipo de padro orientado para conexes ponto-a-ponto entre componentes, no dispondo de funcionalidades para conexes mltiplas, como arbitramento e decodificao de endereos. Estes recursos precisam ser adicionados pelo projetista no caso de conexo de componentes OCP a um barramento. 2.4.7. Exemplo de plataforma de hardware A Philips Semiconductors desenvolveu a plataforma Nexperia-DVP (Digital Video Processor) para o projeto de sistemas destinados ao mercado de set-top boxes e televiso digital. O SoC Viper (ou PNX8500) [Dutta 2001], desenvolvido sobre esta plataforma, ilustrado na Figura 2.17. Contendo at 5 processadores, alm de diversos blocos de hardware especializados, conectados em torno de dois barramentos, ele permite o controle de interaes com o usurio e o processamento concorrente de fluxos de dados multi-mdia contendo udio e vdeo. Os dois processadores principais so um MIPS PR3940, de tipo RISC, e um TriMedia TM32, de tipo DSP-VLIW, ambos de 32 bits. O TM32 foi desenvolvido na prpria Philips, tem sido utilizado desde 1996 em diversos sistemas multi-mdia e dispe de um pequeno kernel de

RTOS. Seu conjunto de instrues otimizado para um SoC que deva processar fluxos de udio e vdeo. At 5 operaes podem ser executadas em paralelo pelo TM32, graas a sua filosofia VLIW. O PR3940 um processador de baixo consumo de potncia e alto desempenho, destinado a executar o sistema operacional e o software aplicativo do provedor de servios, alm de tratar diversas tarefas de controle do Viper e de realizar algum processamento grfico. Cabe a ele solicitar tarefas de tratamento de imagens do processador TM32. Existem diversos sistemas operacionais portados para o processador MIPS, como VxWorks, Linux e WindowsCE. Ambos os processadores principais possuem caches internas de dados e de instrues.

Figura 2.17. Arquitetura do Viper [Dutta 2001]

O Viper tambm contm at 3 processadores RISC de 16 bits, dedicados para filtragem, decodificao e demultiplexao de fluxos MPEG-2. Alm dos processadores, o Viper possui diversos blocos de hardware para processamento dedicado, tais como um acelerador grfico para rendering 2D, um processador capaz de combinar imagens, um decodificador de vdeo MPEG-2 de alta definio e dois processadores de entradas de vdeo em padres NTSC e PAL. Afora estes processadores dedicados, o Viper inclui um amplo repertrio de interfaces analgicas e digitais. Exemplos so um controlador USB, 3 interfaces UART, duas interfaces I2C multi-mestre, uma interface serial sncrona, uma interface para recepo de comandos em infra-vermelho e 3 entradas e 3 sadas de udio. Finalmente, a arquitetura ainda contm outros blocos necessrios, como um controlador do barramento PI, um controlador de interrupo para cada processador principal e um mdulo padro EJTAG para oferecer portas de depurao do processador MIPS. O sistema est organizado em torno de dois barramentos PI, associados aos dois processadores principais e destinados principalmente a operaes de controle. Uma ponte conecta os dois barramentos e permite que diversos blocos dedicados e interfaces sejam acessados tambm pelo outro processador, mas em mais baixa prioridade. Alm destes, existe

ainda um barramento MMI, destinado a conexes DMA entre perifricos de alta velocidade e a memria principal externa pastilha do Viper. Apesar do reuso de grande nmero de componentes IP internos prpria Philips, foi necessrio o projeto de diversos novos componentes, para o que foi definido um padro de desenvolvimento, visando facilitar o trabalho de validao. O circuito final contm 35 milhes de transistores, em tecnologia 0.18 m, com 6 camadas de metal, e consome 4.5 W.

2.5. Estudo de caso

As propostas ad -hoc tradicionais utilizadas no desenvolvimento de sistemas embarcados no tm sido suficientes para tratar o crescimento da complexidade das novas aplicaes. O desejvel realizar a descrio do sistema no mais alto nvel de abstrao possvel, seguida de passos de validao e com posterior sntese automtica da especificao em alto nvel. Algumas necessidades como rea do circuito, desempenho, baixo consumo de potncia e tamanho de software devem ser consideradas para se obter um bom resultado final. Por outro lado, em alguns casos o tempo necessrio para o produto atingir o mercado torna-se mais importante que os itens tecnolgicos. Assim, o projetista deseja obter um bom equilbrio entre os fatores mencionados acima e tambm reduzir tempo de projeto. Recentemente, a linguagem Java tornou-se uma alternativa s linguagens tradicionais no desenvolvimento de sistemas embarcados. O projetistas adotaram Java devido, principalmente, portabilidade e reuso de cdigo que a linguagem fornece s suas aplicaes [Mulchandani 1998]. O desenvolvimento de aplicaes Java para sistemas embarcados uma questo ainda em aberto. A maioria das solues propostas visa um ambiente no qual existem recursos suficientes para acomodar um sistema operacional de tempo real, uma implementao especfica da mquina virtual Java (MVJ) [Lindholm e Yellin 1997], suporte a mltiplas linhas de execuo e mecanismo de garbage collection [Barr 1998, Mrva 1998]. Porm, existe uma carncia de metodologias que tornem a tecnologia disponvel a ambientes com apenas algumas dezenas de Kbytes de memria e restries de consumo de potncia. Processadores como o PicoJava [McGhan 1998] foram projetados para obter alto desempenho, no podendo competir no mercado de aplicaes com restries de recursos e potncia, nas quais os microcontroladores so a melhor opo. Sendo assim, para o desenvolvimento de aplicaes embarcadas simples foi introduzida a metodologia baseada em um ambiente para gerao de aplicaes especficas baseadas em software e hardware para microcontroladores, denominado SASHIMI [Ito 2001] (Systems as Software and Hardware In Microcontrollers), que utiliza a linguagem Java como tecnologia fundamental para o projeto. Neste ambiente, o projetista fornece uma aplicao Java que ser analisada e otimizada para execuo em um microcontrolador denominado FemtoJava, capaz de executar instrues Java nativamente, exibindo ainda caractersticas de um ASIP (Java Application Specific Instruction Set Processor), adicionalmente podendo-se incluir um ASIC (Application Specific Integrated Circuit), onde ambos sero sintetizados em um nico FPGA. Esta abordagem caraterizada por uma alta integrao, um ambiente simples de execuo, nenhum desenvolvimento de compiladores, compatibilidade de software e um reduzido tempo de projeto.

2.5.1. O ambiente SASHIMI SASHIMI um ambiente destinado sntese de sistemas microcontrolados especificados em linguagem Java. O ambiente SASHIMI utiliza as vantagens da tecnologia Java e fornece ao projetista um mtodo simples, rpido e eficiente para obter solues baseadas em hardware e software para microcontroladores. O conjunto de ferramentas disponvel no SASHIMI tambm foi desenvolvido inteiramente em Java, tornando-o altamente portvel para diversas plataformas. O fluxo de projeto definido para o SASHIMI, desde o cdigo fonte da aplicao at o chip do microcontrolador sintetizado [Ito 2000] apresentado na Figura 2.18. No ambiente SASHIMI o usurio inicia o projeto atravs da modelagem da aplicao utilizando a linguagem Java. Durante esta fase do processo, o desenvolvimento segue o ciclo tradicional de implementao-compilao- execuo em um sistema convencional (computador pessoal ou estao de trabalho) utilizando o ambiente JDK correspondente.
Java app ASIC Generation

Src Code Adapter

Java Compiler

Java byte code

Application Validation Java Interpreter Parser

User test inputs

Software Generation Operation Scheduler Critical routines Code Analyser instrs to change

ASIP Generation Bytecode Adapter ASIP Attrib Bytecode Validation adapted SW

Input & results of test

ASIC Generator

MCU Generator

Java Interpreter

VHDL model (ASIP)

SASHIMI Library

Linker

VHDL model (ASIC)

Simulation Tool

ROM w/ app SW

Synthesis Tool

Timers Intr. Ctrl IO Ports Java ASIP

RAM ASIC

ROM (code)

Figura 2.18. Fluxo de Projeto SASHIMI

Neste contexto, a execuo equivalente simulao da aplicao no hardware ainda no disponvel, emulado pelo interpretador Java e pelas classes adicionais do ambiente. Durante a fase de simulao, o projetista pode usar classes pr-definidas (na qual threads e outros recursos so permitidos) para modelar o comportamento de dispositivos perifricos necessrios. Atualmente esto disponveis classes que simulam o comportamento de dispositivos como LCDs, teclados, displays de 7 segmentos, conversores AD/DA, etc. Durante o processo de sntese, tais classes sero substitudas pelo cdigo responsvel por prover a interface entre o microcontrolador e os componentes reais especificados. Quando o projetista considera que a aplicao atende s especificaes funcionais, os vetores de teste fornecidos pelo usurio durante a simulao e os resultados obtidos durante este processo so armazenados para serem utilizados pela etapa de validao de bytecodes. A ferramenta de anlise de cdigo tem como entrada o cdigo binrio executvel (arquivos class) e realiza anlises para extrair informaes de desempenho e rea ocupada pelo hardware. necessrio ter em mente que o conjunto de instrues Java no suportado de forma completa, e a anlise da aplicao deve prover informaes necessrias gerao do ASIP e adaptao de cdigo. A adaptao de bytecodes envolve transformaes nos arquivos class da aplicao, mantendo as propriedades semnticas da mesma. Este processo deve transformar instrues complexas (e.g. tableswitch, lookupswitch) em uma seqncia de instrues suportadas pelo microcontrolador. Bytecodes desnecessrios aplicao (e.g. chamadas ao mtodo System.out.println usados durante a simulao) podem ser descartados, de acordo com as informaes fornecidas pelo analisador de cdigo. Para validar as modificaes efetuadas uma nova fase de simulao necessria. Entretanto, a disponibilidade do conjunto de dados armazenados durante a primeira execuo da aplicao possibilita que este processo possa ser realizado de forma automatizada. Os critrios que guiam a modificao de bytecodes so as instrues suportadas pelo FemtoJava, os requisitos de rea e desempenho, a taxa de utilizao de cada instruo e o tamanho da memria disponvel para armazenar o software da aplicao. O produto obtido neste ponto do fluxo de projeto constitui-se apenas de um conjunto de arquivos class adaptados para serem compatveis com um conjunto de instrues especfico que ser implementado no microcontrolador FemtoJava. A prxima etapa remove todas as informaes desnecessrias (p.ex. estruturas que armazenam informaes de depurao), realiza a resoluo da hierarquia de classes, efetua a ligao e converte o cdigo da aplicao e o cdigo de sistema (bibliotecas para ter acesso aos recursos de hardware e para execuo de instrues complexas) em uma nica descrio de ROM. 2.5.2. Regras de modelagem No ambiente SASHIMI a modelagem do sistema deve ser feita em linguagem Java, respeitando as restries que sero apresentadas. Dentre as tarefas automatizadas disponveis no ambiente SASHIMI est a verificao da aplicao com vistas s regras de modelagem. O domnio das aplicaes atualmente sintetizveis pelo ambiente restrito a aplicaes embarcadas clssicas como controle de portas automticas, sistemas de segurana e identificao, etc. A natureza das aplicaes-alvo induz a algumas restries no estilo de

codificao. Tais restries servem a propsitos similares queles que tornam o subconjunto sintetizvel de VHDL menor do que a linguagem completa, originalmente concebida com propsitos de simulao. Portanto, uma aplicao Java para ser sintetizvel no ambiente SASHIMI deve respeitar as seguintes condies: o operador new no permitido, pois seria necessrio prover servios de gerenciamento de memria virtual; apenas mtodos e variveis estticas so permitidos, salvo os mtodos das interfaces providas pela API do ambiente SASHIMI e implementadas pela classe sendo modelada; mtodos recursivos no so permitidos, pois seriam necessrios mecanismos para gerenciamento dinmico de memria; interfaces no so suportadas, dado que associaes dinmicas (binding) representam um custo adicional em tempo de execuo; dados do tipo ponto-flutuante no podem ser utilizados na verso atual. Contudo, o suporte a esse tipo de dados pode ser obtido atravs da disponibilidade de FPGAs de maior capacidade ou atravs de uma biblioteca adequada; mltiplas threads no so sintetizadas, visto que grande parte das aplicaes microcontroladas podem ser implementadas em um nico fluxo de execuo, minimizando custos de projeto e hardware; o comportamento da aplicao modelado a partir do mtodo initSystem, sendo o mtodo main e o construtor utilizados para efeito de inicializao de outros componentes do sistema.

O modelo de simulao obtido observando-se as regras descritas acima permite que o mapeamento para o modelo de implementao seja amplamente simplificado. As transformaes realizadas na aplicao estaro restritas quelas dependentes dos parmetros de sntese, como a complexidade das instrues que podem determinar a rea em FPGA e a freqncia de operao. O modelo de simulao pode conter todo o comportamento do sistema, incluindo a comunicao atravs de portas de E/S, temporizadores e tratamento de interrupo, encapsulados em classes disponveis no ambiente. Ao projetista no necessrio o conhecimento da estrutura desses mecanismos, da programao ou da linguagem de montagem necessria para construir o cdigo de interface entre a aplicao e o restante do sistema. 2.5.3. Anlise e gerao de estimativas O processo de anlise da aplicao serve a mltiplos propsitos no presente trabalho, englobando a verificao da consistncia do modelo do sistema em relao s regras estabelecidas para a modelagem, a identificao de instrues no suportadas pelo microcontrolador e estimao de resultados de sntese. Dentre as estimativas geradas se incluem a rea ocupada em FPGA, freqncia mxima de operao do microcontrolador, tamanho do cdigo da aplicao e quantidade de RAM utilizada pela aplicao. A anlise dos bytecodes da aplicao pode se processar de forma esttica ou dinmica (profiling), servindo basicamente verificao das regras de modelagem e obteno de estimativas de resultados mais precisos, respectivamente. O produto do processo de anlise deve ser suficiente para dirigir o processo de adaptao e sntese do software da aplicao e do microcontrolador. Quando as estimativas de desempenho no satisfazem os requisitos determinados para a aplicao, partes crticas do cdigo podem ser

identificadas pela ferramenta de anlise de cdigo, e o projetista pode optar por efetuar uma substituio de instrues mais ou menos agressiva. Alternativamente, o projetista pode prover a especificao de um ASIC, ou efetuar a sua gerao diretamente a partir de Java utilizando as ferramentas do SASHIMI, para ser integrado ao hardware do sistema e obter os resultados desejados. 2.5.4. Adaptao e sntese do software da aplicao A adaptao do cdigo da aplicao reflete o conjunto de instrues suportado pelo microcontrolador FemtoJava e as opes de sntese especificadas pelo projetista. O produto da adaptao de cdigo compe-se de um conjunto de arquivos class Java vlidos, que virtualmente devem oferecer a mesma funcionalidade do cdigo original. Basicamente, o processo de adaptao bastante flexvel, permitindo a substituio de seqncias de instrues, remoo e insero de mtodos e cpia de mtodos de uma classe outra. O ajuste das referncias de cdigo (instrues de desvio) realizado de forma automtica a cada modificao, e as informaes de crescimento da pilha referentes a cada mtodo so devidamente atualizadas. A adaptao da aplicao mantendo sua consistncia com a MVJ permite realizar a simulao do software adaptado validando a funcionalidade do novo modelo. O processo descrito somente possvel graas disponibilidade de um pacote de classes especificamente desenvolvido para o ambiente SASHIMI (porm no limitadas utilizao neste projeto), cujas principais bibliotecas so ClassFile, ClassFileInputStream e ClassFileOutputStream. A sntese do software da aplicao a fase imediatamente posterior validao do modelo modificado do sistema. O processo de sntese do software relativamente simples. Ao final do processo, o cdigo da aplicao convertido pela ferramenta de sntese de software em um modelo de ROM descrito em linguagem VHDL ou outro formato de arquivo adequado ferramenta de simulao e/ou sntese. 2.5.5. Gerao do microcontrolador O hardware resultante do sistema SASHIMI composto essencialmente por um microcontrolador Java (FemtoJava) dedicado aplicao modelada, cuja operao compatvel com a operao da Mquina Virtual Java. As informaes extradas na etapa de anlise de cdigo permitem determinar um conjunto de instrues, quantidade de memria de programa e de dados, tamanho da palavra de dados, e demais componentes adequados aos requisitos da aplicao alvo, podendo o projetista interferir nos resultados desse processo. O modelo do microcontrolador resultante descrito em linguagem VHDL e sintetizvel por ferramentas como Maxplus-II da Altera Corporation [Altera 2003]. A principal adaptao da arquitetura do microcontrolador consiste em modificar o mecanismo de decodificao de forma a reconhecer apenas o subconjunto de instrues contidas na aplicao. Em funo dos diferentes formatos e da complexidade de algumas instrues Java, o hardware de decodificao se torna proporcionalmente complexo, de forma que um menor nmero de instrues suportadas permite uma economia significativa de recursos (clulas lgicas em FPGA), possibilitando ainda a integrao de outros componentes no mesmo chip. A gerao de ASICs uma alternativa que fornece ainda mais flexibilidade ao mtodo proposto, pois possibilita a incluso de circuitos especficos que permitam acelerar a execuo da aplicao. Neste processo, o prprio projetista pode fornecer o modelo VHDL do ASIC ou

optar pela gerao automtica, a partir da identificao dos mtodos cuja execuo contribua significativamente para o tempo total de execuo da aplicao. Os modelos do microcontrolador, do cdigo da aplicao e dos ASICs gerados podem ser simulados conjuntamente e depurados utilizando ferramentas de simulao comercialmente disponveis, e posteriormente sintetizados. Entretanto, importante ressaltar ainda que os componentes utilizados durante a simulao e modelados como parte do sistema externo ao microcontrolador so removidos pelas ferramentas do ambiente SASHIMI. Contudo, so includas todas as rotinas que implementam a interface com tais componentes, de acordo com o comportamento modelado. Portanto, o projetista pode facilmente dispor de componentes reais e realizar a montagem final do sistema. 2.5.6. O microcontrolador FemtoJava O microcontrolador FemoJava [Ito 1999] um microcontrolador baseado na arquitetura de pilha com capacidade de execuo nativa de bytecodes Java. Suas principais caractersticas so um reduzido conjunto de bytecodes, arquitetura Harvard (memrias separadas de dados e instrues), pequeno tamanho e facilidade de incluso e remoo de instrues. A arquitetura do microcontrolador FemtoJava foi concebida mediante um detalhado estudo do conjunto de instrues Java e da arquitetura da MVJ [Lindholm e Yellin 1997, Venners 1998, Meyer e Downing 1997]. A Figura 2.19 apresenta a microarquitetura do FemtoJava. Alm do microcontrolador ser composto por uma unidade de processamento baseada em arquitetura de pilha, possui memrias RAM e ROM integradas, portas de entrada e sada mapeadas em memria e um mecanismo de tratamento de interrupes com dois nveis de prioridade. A arquitetura da unidade de processamento implementa um subconjunto de 66 instrues da Mquina Virtual Java, e seu funcionamento consistente com a especificao da MVJ. A utilizao de registradores para armazenar elementos da pilha possibilita ainda ganho de desempenho, reduo na rea ocupada em FPGA e o processamento realizado simultaneamente aos acessos memria. importante ter-se em mente que alguns detalhes da micro-arquitetura foram projetados considerando justamente o FPGA como o componente alvo para sntese. Portanto, possivelmente os resultados obtidos no processo de sntese podem sofrer sensvel impacto se forem realizadas otimizaes na micro-arquitetura, visando outra tecnologia como standard-cell ou mesmo FPGAs de outros fabricantes. A execuo de apenas uma aplicao com uma nica thread no microcontrolador permite que diversas simplificaes sejam efetuadas. A carga dinmica de classes pode ser substituda por ferramentas que realizam a resoluo das referncias contidas no cdigo em tempo de projeto. Tais ferramentas identificam todas as classes da aplicao, armazenando-as na memria de programa juntamente com as bibliotecas especficas para o acesso ao hardware. Grande parte das reas de memria definidas pela arquitetura da MVJ no so utilizadas, restando apenas a rea de mtodos (memria de programa) e uma nica pilha Java para execuo da aplicao. A interface com mtodos nativos utilizada pela tecnologia Java tambm desnecessria, desde que tal funo realizada pelas bibliotecas armazenadas juntamente com a aplicao. O ltimo e principal componente deste modelo o microcontrolador Java como mecanismo de

execuo de bytecodes em hardware, contendo instrues adicionais para realizao de funes no definidas pela especificao da MVJ.

PC

RAM
0

MUX

1 MUX MUX Const

ROM

Data Mem Address Bus

Prg Mem Address Bus

Intruction Bus

MAR

Data Bus

IMM

Input Ports

+/SP

VAR

Timer

A ALU B

Interrupt Handler

IR

Control

Figura 2.19. Microcontrolador FemtoJava

2.5.7. Resultados prticos Nesta seo so apresentados os resultados de sntese para algumas aplicaes especificadas em Java e sintetizadas utilizando a Ferramenta SASHIMI. As aplicaes so as seguintes: Biquad um filtro biquadrtico; ECS corresponde a Elevator Control System e implementa um algoritmo para o controle de um elevador simples; Podos um algoritmo utilizado em um dispositivo eletrnico capaz de medir a distncia percorrida por um pessoa caminhando ou correndo; Tradutor um algoritmo de busca implementado atravs de uma tabela hash que realiza tradues de palavras da lngua inglesa para portuguesa; Caneta um dispositivo porttil usado como uma caneta tradutora. composto por um algoritmo que implementa uma rede neural que reconhece um conjunto de caracteres e um algoritmo de busca que executa tradues de palavras da lngua inglesa para a portuguesa.

MUX

Output Ports

FRM

A Tabela 2.2 apresenta os resultados de rea, em termos de clulas lgicas, e freqncia para os microcontroladores obtidos a partir das diferentes aplicaes. Todos os processadores foram sintetizados no mesmo FPGA, o EPF10K30R240-4 (Flex 10K30) da Altera Corporation [Altera 2003]. A tabela apresenta os resultados, tanto para o microcontrolador FemtoJava completo (com todo o seu conjunto de 68 instrues implementado), como tambm para as diferentes aplicaes nas verses de 8 bits e 16 bits. Pela Tabela 2.2 pode-se observar, para cada aplicao, que o nmero necessrio de diferentes instrues sensivelmente menor que o nmero de instrues disponvel no FemtoJava. Assim, eliminando-se as instrues desnecessrias para determinada aplicao, obtm-se uma significativa reduo na rea ocupada pelo microcontrolador e tambm um aumento de freqncia.
Tabela 2.2. Resultados de sntese dos microcontroladores para as diferentes aplicaes.

controlador Aplicao Completo 8 bits Biquad Completo ECS 16 bits PODOS Tradutor Caneta

rea FPGA (L.C.) 1481 991 1979 1556 1465 1253 1698

Freq (MHz)

Mem. Prg. (bytes)

Mem. Dados (bytes) 30 74 90 118 310

Instr 68 22 69 31 29 32 35

4,85 7,97 3,93 5,65 5,55 5,13 6,19

49 612 246 280 815

A Tabela 2.2 tambm apresenta os resultados de software para as diversas aplicaes, apresentados em termos de memria de dados e memria de programa necessrias para cada aplicao. Atualmente, a ferramenta vm recebendo diversas melhorias, com a incluso de novas facilidades para modelagem, simulao e sntese, como tambm com relao interao com o usurio. Trabalhos atuais comprendem a realizao do microcontrolador FemtoJava para suportar multithreading e alocao dinmica de objetos, como tambm a implementao de caractersticas de baixo consumo de potncia no microcontrolador, entre outras modificaes arquiteturais.

Referncias bibliogrficas
Alexander, P. e Kong, C. (2001). Rosetta: Semantic Support for Model-Centered Systems-Level Design. IEEE Computer, Vol. 34, No. 11, Nov. 2001. pp 64-70. Altera (2003). "Maxplus-II". http://www.altera.com. Altman, E., Ebcioglu, K., Gschwind, M. e Sathaye, S. (2001). "Advances and Future Challenges in Binary Translation and Optimization". IEEE Proceedings, Vol. 89, No. 11, Nov. 2001. pp 1710-22. ARM (1999). AMBA Specification Rev2.0. ARM Limited, Mar. 1999. Disponvel em: www.arm.com/armwww.nsf/

Bacivarov, I., Yoo, S. e Jerraya, A.A. (2002). "Timed HW-SW Cosimulation Using Native Execution of OS and Application SW". HLDVT'02 7th IEEE International High-Level Design Validation and Test Workshop, Cannes, Frana, Out. 2002. Proceedings, 2002. Barr, M. (1998). "Free Java Virtual Machine for Embedded Systems". Embedded System Conference, San Francisco, 1998. Proceedings, Miller Freeman, pp 277-288. Beck Filho, A.C., Wagner, F.R. e Carro, L. (2003). CACO-PS: A General Purpose Cycle-Accurate Compiled-Code Power Simulator. 16th Symposium on Integrated Circuits and Systems Design. So Paulo, Brasil, Set. 2003. Proceedings, IEEE Computer Society Press, 2003. Benini, L., Macii, E. e Poncino, M. (1999). "Selective Instruction Compression for Memory Energy Reduction in Embedded Systems". International Symposium on Low Power Electronics and Design, San Diego, EUA, Ago. 1999. Proceedings, ACM, 1999. pp 206-211. Benini, L., Macii, A., Macii, E. e Poncino, M. (2000). "Increasing Energy Efficiency of Embedded Systems by Applicationspecific Memory Hierarchy Generation". IEEE Design & Test of Computers, Vol. 17, No. 2, Abr/Jun. 2000. pp 74-85. Bergamaschi, R.A. et alii (2001). "Automating the Design of SOCs Using Cores". IEEE Design & Test of Computers, Vol. 18, No. 5, Set/Out. 2001. pp 32-45. Bhattacharya, S., Leupers, R. e Marwedel, P. (2000). "Software Synthesis and Code Generation for Signal Processing Systems". IEEE Transactions on Circuits & Systems, Vol. 47, No. 9, Set. 2000. pp 849-875. Bke, C. (2000). Combining Two Customization Approaches: Extending the Customization Tool TEReCS for Software Synthesis of Real-Time Execution Platforms. AES'2000 Workshop on Architectures of Embedded Systems, Karlsruhe, Alemanha, Jan. 2000. Brunel, J.-Y. et alii (2000). COSY Communication IPs. DAC2000 Design Automation Conference, Los Angeles, EUA, Jun. 2000. Proceedings, ACM Press, 2000. Burns, A. e Wellings, A. (1997). Real-Time Systems and Programming Languages. Addison-Wesley, 1997. Cesario, W. et alii (2002). Multiprocessor SoC Platforms: A Component-Based Design Approach. IEEE Design & Test of Computers. Vol. 19, No. 6., Nov/Dez. 2002. pp 44-51 Chen, R., Irwin, M.J. e Bajwa, R. (2001). Architecture-Level Power Estimation and Design Experiments. ACM Transactions on Design Automation of Electronic Systems, Vol. 6, No. 1, Jan. 2001. pp 50-66. Choi, K. e Chatterjee, A. (2001). "Efficient Instruction-Level Optimization Methodology for Low-Power Embedded Systems". International Symposium on System Synthesis, Montreal, Canada, Out. 2001. Proceedings, ACM, 2001. pp 147-152. Chou, P. et alii (1999). IPChinook: An Integrated IP-Based Design Framework for Distributed Embedded Systems. DAC99 Design Automation Conference, New Orleans, EUA, Jun. 1999. Proceedings, ACM Press, 1999. Dalal, V. e Ravikumar, C.P. (2001). "Software Power Optimizations in an Embedded System". VLSI Design Conference, Bangalore, India, Jan. 2001. Proceedings, IEEE Computer Science Press. 2001, pp 254-259 Dally, W.J. e Towles, B. (2001). Route Packets, Not Wires: On-Chip Interconnection Networks, DAC2001 Design Automation Conference, New Orleans, EUA, Jun. 2001. Proceedings, ACM Press, 2001. Dally, W. J. (1990). "Network and Processor Architecture for Message-Driven Computing". Computation. Morgan Kaufmann, Los Altos, 1990. In: VLSI and Parallel

Dalpasso, M., Bogliolo, A. e Benini. L. (1999). Virtual Simulation of Distributed IP-Based Designs. DAC99 Design Automation Conference, New Orleans, EUA, Jun. 1999. Proceedings, ACM Press, 1999. Davis II, J. et alii (2001). Overview of the Ptolemy Project. Technical Memorandum UCB/ERL M01/11, University of California at Berkeley, Department of Electrical Engineering and Computer Science, Mar. 2001. Disponvel em http://ptolemy.eecs.berkeley.edu Design & Reuse (2003). http://www.us.design-reuse.com Dhananjai, R., Chernyakhovsky, V. e Wilsey, P.A. (2000). WESE: A Web-based Environment for Systems Engineering. WEBSIM2000 - International Conference on Web-Based Modelling & Simulation. Jan. 2000. Proceedings, SCS, 2000 Demmeler, T. e Giusto, P. (2001) "A Universal Communication Model for an Automotive System Integration Platform". DATE01 Design, Automation and Test in Europe, Munich, Alemanha, Mar. 2001. Proceedings, IEEE Computer Society Press, 2001.

Duato, J. et alii. (1997). Interconnection Networks: an Engineering Approach. IEEE Computer Society Press, Los Alamitos, CA, 1997. Dutta, S., Jensen, R. e Rieckmann, A. (2001). "Viper: A Multiprocessor SoC for Advanced Set-Top Box and Digital TV Systems". IEEE Design & Test of Computers, Vol. 18, No. 5, Set/Out. 2001. pp 21-31 Ebcioglu, K. e Altman, E. (1997). "DAISY: Dynamic Compilation for 100% Architectural Compatibility". 24th Annual Symposium on Computer Architecture, Denver, EUA, Jun. 1997. Proceedings, IEEE, 1997. pp 26-37. Edwards, S., Lavagno, L., Lee, E.A. e Sangiovanni-Vincentelli, A. (1997). "Design of Embedded Systems: Formal Models, Validation, and Synthesis". Proceedings of the IEEE, Vol. 85, No. 3, Mar. 1997. pp 366-390 Fin, A. e Fummi, F. (2000). A Web-CAD Methodology for IP-Core Analysis and Simulation. DAC2000 Design Automation Conference, Los Angeles, EUA, Jun. 2000. Proceedings, ACM Press, 2000. Fowler, M.; Scott, K. (2000). UML Distilled, Second Edition, Addison-Wesley, 2000. Gauthier, L., Yoo, S. e Jerraya, A.A. (2001). "Automatic Generation and Targeting of Application Specific Operating Systems and Embedded Systems Software". DATE01 Design, Automation and Test in Europe, Munich, Alemanha, Mar. 2001. Proceedings, IEEE Computer Society Press, 2001. Gervini, A.I., Corra, E.F., Carro, L. e Wagner, F.R. (2003). "Avaliao de Desempenho, rea e Potncia de Mecanismos de Comunicao em Sistemas Embarcados". SEMISH2003 XXX Seminrio Integrado de Software e Hardware. Campinas, Ago. 2003. Anais, SBC, 2003. Givargis, T., Vahid, F. e Henkel, J. (2001). System-Level Exploration for Pareto-optimal Configurations in Parameterized Systems-on-a-chip. IEEE/ACM International Conference on Computer-Aided Design, San Jose, EUA, Nov. 2001. Proceedings, 2001. Guerrier, P. e Greiner, A. (2000). A Generic Architecture for On-Chip Packet-Switched Interconnections. DATE00 Design, Automation and Test in Europe, Paris, Frana, Mar. 2000. Proceedings, IEEE Computer Society Press, 2000. Halambi, A. et alii (1999). "EXPRESSION: A Language for Architecture Exploration through Compiler/Simulator Retargetability". DATE99 Design, Automation and Test in Europe, Munich, Alemanha, Mar. 1999. Proceedings, IEEE Computer Society Press, 1999. Hartenstein, R. (2001). "A Decade of Reconfigurable Computing: a Visionary Retrospective". DATE01 Design, Automation and Test in Europe, Munich, Alemanha, Mar. 2001. Proceedings, IEEE Computer Society Press, 2001. Haverinen, A. et alii (2002). "SystemC based SoC Communication Modeling for the OCP Protocol". White paper, Out. 2002. Disponvel em http://www.synopsys.org Hennessy, J.L., Patterson, D.A. e Goldberg, D. (1996). Computer Architecture: A Quantitative Approach. Second Edition. San Francisco, California, Morgan Kaufmann. Herbert, O., Kraljic, I.C. e Savaria, Y. (2000). "A Method to Derive Application-Specific Embedded Processing Cores". CODES'2000 8th International Workshop on Hardware / Software Codesign, San Diego, EUA, Mai. 2000. Proceedings, ACM, 2000. pp 88-92. Hessel, F. et alii (1999). MCI: Multilanguage Distributed Cosimulation Tool. In: F.J.Rammig (ed.), Distributed and Parallel Embedded Systems. Kluwer Academic Publishers, 1999. HLA (2000). IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - IEEE Standard No. 1516-2000. IEEE, 2000. IBM (2003). IBM CoreConnect Bus http://www3.ibm.com/chips/products/coreconnect/index.html Architecture. Disponvel em

Inomata, K. (2001). "Present and Future of Magnetic RAM Technology". IEICE Transactions on Electronics. Vol. E84-C, No. 6 (2001). pp 740-746 Ishihara, T. e Yasuura, H. (2000). "A Power Reduction Technique with Object Code Merging for Application Specific Embedded Processors". DATE00 Design, Automation and Test in Europe, Paris, Frana, Mar. 2000. Proceedings, IEEE Computer Society Press, 2000. Ito, S., Carro, L. e Jacobi, R. (2000). "System Design Based on Single Language and Single-Chip Java ASIP Microcontroller". DATE00 Design, Automation and Test in Europe, Paris, Frana, Mar. 2000. Proceedings, IEEE Computer Society Press, 2000. Ito, S., Carro, L. e Jacobi, R. (2001). "Sashimi and FemtoJava: Making Java Work for Microcontroller Applications". IEEE Design & Test of Computers. Vol. 18, No. 5, Set-Out 2001. pp 100-110.

ITRON (2003). ITRON. Disponvel em: http://www.itron.gr.jp ITRS (2001). International Technology Roadmap for Semiconductors, verso 2001. Disponvel em http://public.itrs.net/, Karim, F., Nguyen, A. e Dey, S. (2002). "An Interconnect Architecture for Networking Systems on Chips". IEEE Micro, Vol. 22, No. 5, Set-Out. 2002. pp 36-45. Keating, M. e Bricaud, P. (2002). Reuse Methodology Manual for System-on-a-Chip Designs. Kluwer Academic Publishers, 2002 (terceira edio). Keutzer, K. et alii (2000). System-Level Design: Orthogonalization of Concerns and Platform-Based Design. IEEE Transactions on Computer-Aided Design of Integrated Circuits, Vol. 19, No. 12, Dez. 2000. pp 1523-1543. Kin, J., Gupta, M. e Mangione-Smith, W. (2000). "Filtering Memory References to Increase Energy Efficiency". IEEE Transactions on Computers, Vol. 49, No. 1, Jan. 2000, pp 1-15. Klaiber, A. (2000). "The Technology Behind Crusoe Processors". Technical Report Trasnmeta Corp., Santa Clara, CA. Krapf, R., Mattos, J., Spellmeier, G. e Carro, L. (2002). "A Study on a Garbage Collector for Embedded Applications". SBCCI'02 15th Symposium on Integrated Circuits and System Design, Porto Alegre, Brasil, Set. 2002. Proceedings, IEEE Computer Society Press, 2002. Krapf, R. e Carro, L. (2003). "Efficient Signal Processing in Embedded Java". ISCAS'2003 IEEE International Symposium on Circuits & Systems, Bangkok, Tailndia, Mai. 2003. Proceedings, IEEE, 2003. Landman, P. e Rabaey, J. (1996). Activity-Sensistive Architectural Power Analysis. IEEE Transactions on CAD of Integrated Circuits, Vol. 15, No. 6, Jun. 1996, pp 571-587 Lapsley, P., Bier, J., Shoham, A. e Lee, E. (1997). DSP Processor Fundamentals: Architectures and Features. IEEE Press, New York, 1997. Lavagno, L., Martin, G. e Selic, B. (2001). UML for Real: Design of Embedded Real-Time Systems. Kluwer Academic Press, 2001. Lekatsas, H. e Wolf, W. (1999). "SAMC: A Code Compression Algorithm for Embedded Processors". IEEE Transactions on CAD of Integrated Circuits, Vol. 18, No. 12, Dez. 1999. pp 1689-1701. Li, Y., Potkonjak, M. e Wolf, W. (1997). Real-time Operating Systems for Embedded Computing. International Conference on Computer Design, Austin, EUA, Out. 1997. Proceedings, IEEE Computer Society Press, 1997. Lindholm, T. e Yellin, F. (1997). The Java Virtual Machine Specification. The Java Series. Addison-Wesley, Reading, 1997. Lyonnard, D. et alii (2001). Automatic Generation of Application-Specific Architectures for Heterogeneous Multiprocessor System-on-Chip. DAC'2001 Design Automation Conference. New Orleans, EUA, Jun. 2001. Proceedings, ACM Press, 2001. Madisetti, V. K. (1995). VLSI Digital Signal Processors. IEEE Press, Butterworth-Heinemann, 1995. Magarshack, P. (2002). "Improving SOC Design Quality through a Reproducible Design Flow". IEEE Design & Test of Computers, Vol. 19, No. 1, Jan-Fev. 2002, pp 76-83. Mathworks (2003). Disponvel em http://www.mathworks.com McGhan, H. e O'Connor, M. (1998). "Picojava: A Direct Execution Engine For Java Bytecode". IEEE Computer, Vol. 31, No. 10, Out. 1998. pp 2230. Mello, B.A. e Wagner, F.R. (2002). A Distributed Co-Simulation Backbone. In: M.Robert et al. (eds), SOC Design Methodologies. Kluwer Academic Publishers, 2002. Mentor (2003). Seamless CVE. Disponvel em: http://www.mentor.com/seamless Meyer, J. e Downing, T. (1997). Java Virtual Machine. OReilly & Associates, Inc., Sebastopol, EUA, 1997. De Micheli, G. e Benini, L. (2002). "Networks-on-Chip: A New Paradigm for Systems-on-Chip Design". DATE02 Design, Automation and Test in Europe, Paris, Frana, Mar. 2002. Proceedings, IEEE Computer Society Press, 2002. Microsoft (2003). WindowsCE. http://www.microsoft.com/windows/embedded Mooney III, V. e Blough, D.M. (2002). "A Hardware-Software Real-Time Operating System Framework for SoCs". IEEE Design & Test of Computers. Vol. 19, No. 6., Nov/Dez. 2002. pp 44-51 Moore, G.E. (1965). "Cramming More Components Onto Integrated Circuits". Electronics Magazine, Vol. 38, Abr. 1965. pp 114-117.

Mrva, M., Buchenrieder, K. e Kress, R. (1998). "A Scalable Architecture for Multi-threaded JAVA Applications". DATE98 Design, Automation and Test in Europe, Paris, Frana, Mar. 1998. Proceedings, IEEE Computer Society Press, 1998. Mulchandani, D. (1998). "Java for Embedded Systems". Internet Computing, Vol. 31, No. 10, Maio 1998. pp 3039 OCP (2003). Open Core Protocol. OCP-IP, 2003. Disponvel em: http://www.ocpip.org OSEK (2003). OSEK. Disponvel em: http://www.osek-vdx.org/osekvdx_OS.html Oyamada, M. e Wagner, F.R. (2000). Co-simulation of Embedded Electronic Systems. 12nd European Simulation Symposium. Hamburgo, Alemanha, Out. 2000. Proceedings, SCS, 2000. Paulin, P. et alii (1997). "Embedded Software in Real-time Signal Processing Systems: Application and Architecture Trends". Proceedings of the IEEE, Vol. 85, No. 3, Mar. 1997. pp 419-435. Passerone, R., Rowson, J.A. e Sangiovanni-Vincentelli, A. (1998). Automatic Synthesis of Interfaces between Incompatible Protocols. DAC98 Design Automation Conference, San Francisco, EUA, Jun. 1998. Proceedings, ACM Press, 1998. Red Hat (2003). "eCos". Disponvel em: http://sources.redhat.com/ecos/ RTLinux (2003). RTLinux. Disponvel em: http://fsmlabs.com/community Sangiovanni-Vincentelli, A. e Martin, G. (2001). Platform-Based Design and Software Design Methodology for Embedded Systems. IEEE Design & Test of Computers, Vol. 18, No. 6, Nov/Dez. 2001. pp 23-33. Shandle, J. e Martin, G. (2002). Making Embedded Software Reusable for SoCs. EEDesign, Mar. 1, 2002. Shiue, W.-T. e Chakrabarti, C. (1999). "Memory Exploration for Low Power, Embedded Systems". ISCAS'1999 IEEE International Symposium on Circuits & Systems. Proceedings, Vol. 1, pp 250-253 Simuni, T., Benini, L. e De Micheli, G. (1999).Cycle-Accurate Simulation of Energy Comsumption in Embedded Systems. DAC99 Design Automation Conference, New Orleans, EUA, Jun. 1999. Proceedings, ACM Press, 1999. Smith, J. e De Micheli, G. (1998). Automated Composition of Hardware Components. DAC98 Design Automation Conference, San Francisco, EUA, Jun. 1998. Proceedings, ACM Press, 1998. Sonics (2003). Sonics SiliconBackplane MicroNetwork. Sonics, 2003. Disponvel em: www.sonicsinc.com Stepner, D., Rajan, N. e Hui, D. (1999). Embedded Application Design Using a Real-time OS. DAC99 Design Automation Conference, New Orleans, EUA, Jun. 1999. Proceedings, ACM Press, 1999. Synopsys (2003). CoCentric System Studio. http://www.synopsys.com/products/cocentric_studio/cocentric_studio.html SystemC (2003). SystemC. Disponvel em: http://www.systemc.org Tomiyama, H., Ishihara, T., Inoue, A. e Yasuura, H. (1998). "Instruction Scheduling for Power Reduction in Processor-Based System Design". DATE98 Design, Automation and Test in Europe, Paris, Frana, Mar. 1998. Proceedings, IEEE Computer Society Press, 1998. Texas Instruments Inc. (2002). "TMS320C6000 CPU and Instruction Set Reference Guide". Texas Instruments, 2000. Disponvel em: http://www-s.ti.com/sc/psheets/spru189f/spru189f.pdf Tiwari, V., Malik, S. e Wolfe, A. (1994). "Power Analysis of Embedded Software: a First Step Towards Software Power Minimization". IEEE Transactions on Very Large Scale Integration (VLSI) Systems. Vol. 2, No. 4, Abr. 1994, pp 437445. Transtech (2003). "Virtuoso 4.1 Real Time Operating System". Transtech DSP, 2003. Disponvel em: http://www.transtechdsp.com/software/virtuoso.htm Valderrama, C. et alii (1998). "Automatic VHDL-C Interface Generation for Distributed Cosimulation: Application to Large Design Examples". Journal on Design Automation for Embedded Systems, Vol. 3, No. 2/3, Mar. 1998. Verilog (2003). Verilog. Disponvel em: http://www.accellera.org Venners, B. (1998). Inside the Java Virtual Machine. McGraw-Hill, New York, USA, 1998. VHDL (2002). IEEE Standard VHDL Language Reference Manual. IEEE Standard No. 1076-2002. IEEE, 2002. VSIA (2003). Virtual Socket Interface Alliance. Disponvel em: http://www.vsi.org WindRiver (2003). VxWorks. Disponvel em http://www.windriver.com/products/vxworks5. Disponvel em:

Wolf, W. (2001). Computers as Componentes. McGraw-Hill, 2001. Yoo, S. e Jerraya, A.A. (2003). "Introduction to Hardware Abstraction Layers for SoC". DATE'2003 Design, Automation and Test in Europe. Munich, Alemanha, Mar. 2003. Proceedings, IEEE Computer Society Press, 2003. Zeferino, C., Kreutz, M., Carro, L. e Suzim, A.A. (2002a). "A Study on Communication Issues for Systems-on-Chip". SBCCI'02 15th Symposium on Integrated Circuits and System Design, Porto Alegre, Brasil, Set. 2002. Proceedings, IEEE Computer Society Press, 2002. Zeferino, C., Kreutz, M., Carro, L. e Suzim, A.A. (2002b). "Models for Comunication Tradeoffs on Systems-on-Chip". IFIP WG 10.5 International Workshop on IP-Based SOC Design, Grenoble, Frana, Out. 2002. Proceedings, 2002. pp 395400. Zhang, Y., Hu, X. e Chen, D. (2002). "Task Scheduling and Voltage Selection for Energy Minimization". DAC'2002 Design Automation Conference, New Orleans, EUA, Jun. 2002. Proceedings, ACM Press, 2002. Zorian, Y. e Marinissen, E. (2000). "System Chip Test - How will it Impact your Design". DAC'2000 Design Automation Conference, Las Vegas, EUA, Jun. 2000. Proceedings, ACM Press, 2000.

Biografias Luigi Carro professor adjunto do Deptartamento de Engenharia Eltrica da Universidade Federal do Rio Grande do Sul (UFRGS) e orientador dos Programas de Ps-graduao em Computao (PGCC) e Ps-graduao em Engenharia Eltrica (PGEE) da mesma universidade Em 2001 realizou seu ps-doutorado junto University of California, San Diego, Computer Science Dept.. Participou de diversos projetos de pesquisa, bolsista CNPq II-B e j publicou mais de 50 trabalhos em conferncias internacionais, tendo orientado 9 dissertaes de mestrado. Atualmente orienta 4 alunos de mestrado e 6 de doutorado (3 em co-orientao).

Flvio Rech Wagner professor titular do Instituto de Informtica da UFRGS e orientador do Programa de Psgraduao em Computao (PGCC) da mesma universidade. Tem doutorado em Informtica pela Universidade de Kaiserslautern, Alemanha (1980-1983) e ps-doutorados junto ao Laboratrio TIMA de Grenoble, Frana (1992 e 2002). bolsista pesquisador I-C do CNPq. J publicou um total de 41 trabalhos internacionais e 45 trabalhos nacionais. Publicou ainda 2 livros-texto na Escola de Computao. J orientou ou co-orientou 4 teses de doutorado e 21 dissertaes de mestrado, e atualmente orienta outras 4 teses de doutorado (uma em co-orientao) e 5 dissertaes de mestrado. J participou de comits de programa de 18 conferncias internacionais, sendo duas vezes na qualidade de coordenador. o atual coordenador do Grupo de Trabalho 10.5 da IFIP, que rene especialistas internacionais na rea de "Design and Engineering of Electronic Systems". J foi membro do Comit Assessor de Cincia da Computao do CNPq e ocupou diversas funes na diretoria da Sociedade Brasileira de Computao, da qual o atual presidente, em segundo mandato.