UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

MILLENA DE ANDRADE ALMEIDA GOMES

PDesigner Framework

Monografia apresentada no curso de

graduação em Engenharia da

Computação na disciplina de Iniciação

Científica 1.

Orientadora: Patrícia Tedesco

Recife

2006

Resumo

O PDesigner Framework consiste em um conjunto de ferramentas baseadas em

ArchC e SystemC integradas ao workbench do Eclipse, que possibilita a modelagem,

simulação e análise de plataformas multiprocessadas SoC (System on Chip) descritas em

diferentes níveis de abstração. O PDesigner permite a modelagem da plataforma completa,

desde a descrição de um componente até a geração do simulador utilizado na análise da

mesma, em um único ambiente gráfico, integrado e configurável ao perfil do usuário,

garantindo ao projetista uma maior flexibilidade e diminuição no espaço de exploração de

diversas configurações e modelagens de plataformas com mínimo esforço. O PDesigner é

baseado em biblioteca e composto por plugins integrados através de arquivos XML,

baseados em um padrão de distribuição de IP Cores, tornando a ferramenta apta a importar

e exportar componentes de outras ferramentas ou projetistas.

Índice

1 Introdução____________________________________________________________________________5

2 Ferramentas de Modelagem e Análise de Plataforma__________________________________________6

3 PDesigner Framework__________________________________________________________________9

3.1 Views___________________________________________________________________________9

3.2 Perspectivas_____________________________________________________________________11

4 Arquitetura___________________________________________________________________________12

4.1 SPIRIT 1.2______________________________________________________________________13

4.2 ArchC__________________________________________________________________________14

4.3 SystemC________________________________________________________________________15

5 Modelagem de Componentes_____________________________________________________________15

6 Modelagem e Simulação de MPSoC_______________________________________________________16

6.1 Fluxo de Design no PDesigner______________________________________________________17

7 Biblioteca de Componentes______________________________________________________________18

8 Análise de Cache______________________________________________________________________18

9 Conclusão____________________________________________________________________________20

10 Referências________________________________________________________________________21

Índice de Figuras

Perspectiva ArchC, composta pelas views: Navigator, PArchC Editor e Console_________________________10Platform Perspective. Composta pelas views: navigator, Outline (Platform View)., PEditor e Properties View_11Perspectiva Platform Simulation. Composta pelas views: Outline (Instane View), Propertiese Console._______12Arquitetura do PDesigner____________________________________________________________________13Ambiente de Projeto do SPIRIT________________________________________________________________14Metodologia de Projeto de Processadores_______________________________________________________14Exemplo de Plataforma MPSoC_______________________________________________________________16Fluxo de Projeto____________________________________________________________________________17Resultado da Análise de Cache pelo Plugin PCacheAnalyzer_________________________________________19

1 Introdução

Os sistemas embarcados são tipicamente projetados para executar uma aplicação

específica e única em um sistema cujos recursos são extremamente restritos. Neste

contexto, plataformas multiprocessadas (MPSoCs) passaram a ser amplamente utilizadas

em sistemas que necessitam de alta performance, obtido com a combinação do paralelismo

do processamento com o nível de integração proporcionado pela tecnologia system-on-

chip(SoC)[18].

A performance dos MPSoCs não são exclusivamente definidas pela característica dos

processadores utilizados, mas também pela rede utilizada para interconectá-los com a

memória. Baseado nisto, é indispensável uma fase prévia de modelagem e análise da

plataforma multiprocessada, passo responsável pela validação da mesma, que pode ser

obtida através do uso de ferramentas, diminuindo o tempo de projeto e consequentemente o

tempo de mercado da mesma.

A análise de um MPSoC pode ser realizada mapeando a aplicação ao modelo da

plataforma, que deve dar suporte à análise funcional e não funcional dos requisitos da

aplicação.

Um método muito utilizado para realizar este tipo de análise de plataformas, é a

simulação, que permite avaliar corretamente o comportamento da aplicação embutida na

plataforma, não somente no ponto de vista do processamento como também na avaliação

do comportamento da rede de comunicação da plataforma. Porém sua utilização não é

trivial, já que necessita de simuladores de instruções específicas(ISS) para cada

processador e que os mesmos estejam em sincronismo com os protocolos de comunicação

implementados na plataforma.

Baseado neste contexto, esta monografia apresenta o PDesigner, framework que

possibilita a modelagem e análise de componentes e plataformas multiprocessadas dentro

de um ambiente gráfico e unificado, proporcionando ao projetista um aumento significativo

de produtividade e uma análise eficiente de exploração de espaço da arquitetura da

plataforma e de performance através de simulações.

Os demais capítulos desta monografia são estruturados como a seguir.

2 Ferramentas de Modelagem e Análise de Plataforma

ConvergenSC [8,9,20] é uma ferramenta para projetos baseados em plataformas em

domínios genéricos de aplicação, composto por uma biblioteca de modelos que inclui os

modelos dos processadores ARP e MIPS além de modelos de barramentos como o AMBA.

Caso o componente não exista na biblioteca, o projetista pode cria-lo separadamente

utilizando o LISATek[21] e encapsula-lo como componente.

STepNT [6,7] é uma ferramenta de exploração de plataforma, que restringe o projetista

a utilizar um conjunto pré-definido de processadores e seus simuladores, entre eles ARM,

PowerPC e DLX.

Na Metodologia de Projetos Baseados em Componentes [3, 4, 8], simuladores de

processadores são encapsulados nos componentes. Um geração de ad hoc de wrappers é

construída e os parâmetros de configuração dos processadores instanciados são definidas.

Numa segunda fase, os projetistas modificam os valores dos parâmetros de configuração

para gerar o modelo para simulação da plataforma.

EXPRESSION [22] é uma linguagem de descrição de arquitetura utilizado para

descrição de diferentes tipos de arquiteturas: VLIW (Very Long Instruction Word), ASIP

(Application Specific Instruction Set Processor), DSP (Digital Signal Processor) e

arquiteturas de processadores convencionais, como RISC (Reduced Instruction Set

Computer), funcional e simuladores compilados que podem ser gerados pela descrição

EXPRESSION. Simuladores baseados em EXPRESSIOn são basicamente utilizados em

conjuntos de ferrramentas para geração de processadores e não para descrever

plataformas multiprocessadas.

A metodologia SpecC foca na especificação de sistemas sem fazer referência a

arquitetura final. Seu objetivo é permitir um refinamento gradual de uma descrição a nível de

sistema até um descrição sintetizável. A interface automática de síntese é descrita em [23],

e foca no refinamento automático da comunicação a nível de sistema, que é baseada em

canais através de modelos funcionais de barramentos da arquitetura final.

Sesame é um ambiente de modelagem e simulação de projetos em nível de sistema,

baseados no Y-chart [24], onde aplicação e arquitetura do sistema são descritos

independentemente. Sua principal característica é possibilitar uma rápida avaliação de

performance do sistema no início do projeto. Duas principais características distinguem a

simulação no ambiente Sesame. A primeira é ter aplicação e arquitetura simuladas em

diferentes simuladores. Durante a execução da aplicação ele gera traces das operações e

comunicações que são utilizadas na arquitetura. Atualmente a aplicação não é executada na

arquitetura final. Os traces com as ações executadas pelos processos da aplicação funciona

como um estímulo para o modelo de arquitetura.

SPADE foi a base do Sesame e tem basicamente as mesmas características. A

principal diferença vem do fato dele utilizar uma biblioteca C++ chamada YAPI [25] para

descrever os processos de comunicação que implementam as funcionalidades da aplicação.

Para comparar os projetos mencionados acima, algumas características foram

cuidadosamente analisadas: suporte a integração automática de processadores;

disponibilidade de mecanismos para mapeamento de aplicação na plataforma; suporte a

descrição e modificação de processadores; disponibilidade de um mecanismo de análise em

diferentes níveis de abstração; linguagem de especificação a nível de sistema; linguagem de

especificação de arquitetura; suporte a aplicações genéricas; suporte a simulação. Os

resultados da análise destas características estão resumidas na Tabela 1, onde “X” significa

suporte completo; “P” suporte parcial; “?” informações não estão claras; e “-“ significa que a

característica não é suportada.

  ConvergenSC StepNP CBD SpecC SPADE Sesamesimulação X X X X P Panálise alto nível - X - X X Xdomínio genérico de aplicação X - X X - - integração de processador P P P P - -modificação de processador - - - - - - especificação a nível de sistema SystemC Click heterogêneo SpecC - YMLespecificação da arquitetura SystemC SystemC SystemC SpecC ? YML

Tabela 1 Comparação de Ferramentas

As ferramentas da tabela acima podem ser divididas em dois grupos. O primeiro,

incluindo StepNP, Projetos Baseados em Componentes e SpecC, usam simulação ou co-

simulação para avaliação de sistema. Isso mostra que a simulação continua a ser o

mecanismo de avaliação mais utilizado para sistemas digitais. Além disso, o uso da

simulação StepNP um mecanismo de análise de alto nível para verificar a comunicação a

nível de sistema e o comportamento da arquitetura final, tendo como limitação um

mecanismo de análise que não é genérico.

As ferramentas do segundo grupo, SPADE e Sesame, fornecem um suporte parcial

para simulação, visto que a execução da aplicação na arquitetura é dirigida pelo trace.

Nestas ferramentas o projetista pode analisar a comunicação na arquitetura final a nível de

sistema e a mesma falta de flexibilidade do StepNP é observado. Elas são utilizadas para

domínios específicos de aplicações: multimídia e de processamento digital de sinais.

Observando a Tabela 1, fica claro que falta um mecanismo de análise de alto nível para

comunicação em ferramentas de domínio de aplicação genérica, baseada em simulação.

Outro ponto relevante na tabela é a falta de suporte a descrição/modificação e

integração automática de especificações de processadores. As ferramentas do primeiro

grupo fornecem um suporte parcial a integração. Já as ferramentas do segundo grupo não

fornecem nem mesmo um suporte limitado. Esta é uma característica muito interessante e

importante, visto que processadores são componentes cruciais de quase todos os projetos

de sistemas embarcados. Se projetistas não podem modificar as características dos

processadores, como configuração de cache, eles são severamente limitados para otimizar

toda a arquitetura do sistema embarcado.

Observando melhor primeiro grupo, percebe-se que são utilizadas duas linguagens

para descrição de arquitetura: SystemC e SpecC. Projetos Baseados em Componentes

aceita diversas linguagens, porém possui como linguagem base o SystemC. As ferrametas

da SpecC utilizam SpecC para especificação de sistema e arquitetura. Assim, uso de

apenas uma linguagem em todas as partes do sistema é uma tendência que vem

gradualmente se consolidando. Linguagens heterogêneas são utilizadas principalmente para

compatibilidade e reuso. Apesar de estar no Segundo grupo Sesame usa a mesma

linguagem para especificação de sistema e modelo de arquitetura.

3 PDesigner Framework

O PDesigner é um framework baseado no workbench do Eclipse focado em

modelagem e simulação de componentes e plataformas MPSoCs, além de análise de tipos

de componentes específicos dentro de uma plataforma, reunindo em um único framework,

de forma transparente para o usuário, diversas ferramentas que possibilitam realizar todos

os passos necessários para modelagem, geração e simulação de um projeto de plataforma

no mesmo framework e projeto.

Ele permite a utilização de componentes descritos em linguagens diferentes para

compor a arquitetura da plataforma que são armazenados na biblioteca da ferramenta. Esta

biblioteca é dinâmica, possibilitando a inserção e remoção de componentes, desde que os

mesmo estejam distribuídos utilizando o padrão SPIRIT 1.2. Os componentes adicionados

podem ser desenvolvidos pelo próprio projetista utilizando o PDesigner.

O PDesigner facilita o desenvolvimento de projetos de plataformas através da

utilização de um editor gráfico, onde os componentes são representados por diferentes

formas geométricas e podem ser selecionados de uma paleta de componentes, que reflete o

conteúdo da biblioteca da ferramenta. Através deste editor, o usuário está hábil a adicionar

componentes e conectá-los apenas inserindo um fio de conexão entre as portas dos

componentes, compondo a arquitetura. Para possibilitar a conexão, a ferramenta reconhece

as interfaces dos componentes e seus protocolos de comunicação inserindo, se necessário,

wrappers que possibilitem a conexão.

3.1 Views

Com o intuito de auxiliar a manipulação do projeto de componentes e de plataformas,

o PDesigner disponibiliza views específicas que permitem uma melhor visualização e

manipulação dos componentes e dados do projeto.

Durante um projeto de componente, o projetista dispõe do PArchC Editor, um editor de

texto que reconhece as linguagem ArchC, destacando suas palavras reservadas e

identificando a estrutura básica da mesma como pode ser visto na Figura1. Além do editor

para ArchC, o projetista também dispõe de editores para C/C++ disponibilizados pelo plugin

CDT [CDT home page] do projeto Eclipse.

O PEditor possibilita a modelagem gráfica da plataforma, representando os

componentes como figuras geométricas como mostrado na Figura 2, que são adicionados

através de uma paleta de componentes.

Figura 1 Perspectiva ArchC, composta pelas views: Navigator, PArchC Editor e Console

Toda a imagem da plataforma modelada também pode ser vista em miniatura na

Platform View, uma view de saída que não pode ser editada. A Instance View, view

composta pela lista de componentes instanciados na plataforma, também pode ser utilizada

para navegar entre os componentes da plataforma, através da sua conexão com o PEditor,

possibilitando que um componente selecionado em uma view também apareça selecionado

nas demais. As configurações dos componente selecionado são mostradas e hábeis de

serem modificadas na Properties View.

Para visualização de todos os resultados e informações sobre compilação, simulação

e análise dos componentes e plataformas são visualizadas na Console View em forma de

texto. Para visualização de resultados de análise, o PDesigner também dispõe da view

PBrowser, que mostrar o resultado como texto HTML.

Figura 2 Platform Perspective. Composta pelas views: navigator, Outline (Platform View)., PEditor e Properties View

3.2 Perspectivas

Além das views, o PDesigner dispõe de perspectivas, conjunto de views que compõem

o workbench do Eclipse, que facilitam os projetistas, dispondo as views necessárias e

auxiliares nas posições ideais para a concepção do projeto, dependendo do seu foco e/ou

necessidade no momento.

A perspectiva ArchC como vista na Figura1 tem foco na modelagem de componentes,

dispondo para isto do PArchC Editor, em destaque na parte central, para codificação do

componente, a Navigator View, onde os arquivos do projeto são visualizados e podem ser

navegados e a Console View, apresentando abaixo do PArchC Ediotr todas as informações

sobre a compilação e simulação do projeto.

A perspectiva PDesigner foca na modelagem de plataformas, possuindo o PEditor na

parte central em destaque; a sua esquerda a Navigator View, possibilitando a navegação

entre os arquivos gerados para a plataforma, e a Outline View que pode ser alternada entre

a Platform View e a Instance View; e na parte inferior a Properties View para configuração

da plataforma e a Console View, com os resultados de compilação, simulação e análise.

Por fim, a perspectiva Platform Simulation, descrita na Figura 3, foca na simulação da

plataforma, sendo composta, então, pela Console View em destaque na parte central e à

sua esquerda a Platform e a Instance Views.

Figura 3 Perspectiva Platform Simulation. Composta pelas views: Outline (Instane View), Propertiese Console.

4 Arquitetura

Esta seção descreve a arquitetura do PDesigner que é composto por um conjunto de

ferramentas baseadas na IDE do Eclipse, composta por quatro principais plugins que

permitem a modelagem de componentes e plataformas, a edição de uma biblioteca e

análise de cache. Uma principal característica da arquitetura da ferramenta é ser formada

por módulos representado por plugins que se comunicam por arquivos XML, o que significa

que novos plugins podem ser inseridos facilmente.

O framework é construído em cima de quatro importantes padrões: SystemC para

modelagem e simulação de MPSoC; ArchC, utilizado para modelagem de componentes, em

especial processadores; SPIRIT que provém o padrão para integração de IPs em sistemas

digitais; e Eclipse, framework base dos plugins do PDesigner.

O PDesigner possui uma arquitetura dividida em camadas. As duas principais

camadas são formadas pela Eclipse e Suporte, nível mais inferior. Estas camadas por sua

vez, são dividida em subcamadas. A do IDE do Eclipse em camadas que representam os

plugins, que possuem vários níveis como mostrados na Figura 4, e a de Suporte é formada

pelas ferramentas que geram a base para o PDesigner, estando todas no mesmo nível.

Figura 4 Arquitetura do PDesigner

A camada de suporte é composta por uma camada SystemC/ArchC representando as

linguagens e compiladores das duas linguagens utilizadas para a criação dos componentes

e plataformas, além da camada XML, representado toda a configuração do sistema que é

realizada por arquivos XMLs baseados no padrão de distribuição SPIRIT 1.2.

A camada Eclipse é composta pelos plugins que formam o PDesigner: PArchC,

PBuilder, PDLibrary e PCacheAnalyzer. O PArchC encontra-se no mesmo nível que o

PDLibrary, mas não se comunica diretamente com o PBuilder, apenas através do PDLibrary,

que se encontra também um pouco acima do PArchC. Estes dois formam a base para o

PBuilder, acima do qual os demais plugins serão adicionados, o que no momento

corresponde ao PCacheAnalyzer.

4.1 SPIRIT 1.2

O SPIRIT é um padrão definido por um consórcio de empresas para distribuição de

IPs. Este padrão é todo baseado em XML e descreve toda a arquitetura do IP (SPIRIT

Compliant IP), independente da linguagem que o mesmo foi implementado, possibilitando

sua utilização em outras ferramentas.

A descrição do IP é realizada através de diversos arquivos denominados Schemas

modularizando as informações, como pode ser visto na Figura 5. Estes arquivos são

utilizados por uma ferramenta que os interpreta (SPIRIT Compliant SoC Design Tool), no

caso do PDesigner, o plugin PBuilder, representando-os na maneira desejada para serem

posteriormente utilizados, através das informações contidas nos arquivos de geração

(SPIRIT Compliant Generator) que permitem a utilização do IP original.

Figura 5 Ambiente de Projeto do SPIRIT

4.2 ArchC

ArchC é uma Linguagem de Descrição de Arquitetura(ADL) open-source [ArchC]

projetada para possibilitar a descrição de processadores. ArchC suporta diferentes níveis de

abstração, possibilitando o projetista iniciar no nível funcional e refiná-lo até alcançar o

modelo cycle-accurate. Um conjunto de ferramentas pode ser gerada utilizando o ArchC:

simuladores interpretados de SystemC e simuladores compilados de C++, GNU assembly

(gas), interface de suporte GNU GDB e coverificação entre dois modelos ArchC.

Cada processador descrito em ArchC pode seguir um plano estrito de projeto, como

na Figura 6, (por número de versão) indicando os milestones alcançados no modelo de

implementação.

Figura 6 Metodologia de Projeto de Processadores

4.3SystemC

SystemC é uma linguagem de descrição de hardware e software baseado em C++,

orientada a hardware através de uma biblioteca própria implementada no padrão de C++.

SystemC provê modelagem de plataformas e componentes em a nível de sistema de forma

rápida, sendo muito utilizado para descrição de barramentos e dispositivos, além de

aplicações específicas para plataformas, aumentando performance.

Através do conjunto de ferramentas desmobilizadas, possibilita a criação de

simuladores utilizados para verificação e teste dos componentes/plataformas.

5 Modelagem de Componentes

Um passo importante na modelagem de plataformas é a escolha dos componentes

que irão compor a mesma. São eles que irão garantir o perfeito funcionamento da aplicação

embarcada seguindo os requisitos funcionais e não funcionais definidos previamente. Estes

requisitos podem não ser obtidos dependendo da implementação e restrições dos

componentes utilizados. Por outro lado, pode-se optar por utilizar componentes de uso

específico para o sistema integrado a ser implementado, ganhando com isso performance e

diminuindo espaço e/ou potência consumida.

Dependendo da abordagem escolhida pelo projetista do sistema, o mesmo pode ter a

necessidade de criar um componente específico ou modificar um já existente. Para isto o

PDesigner disponibiliza um plugin de modelagem de componentes, denominado PArchC,

composto pelas ferramentas necessárias para modelagem de componentes, especialmente

processadores, utilizando a linguagem ArchC.

O PArchC possibilita o projetista a modelar o componente definindo sua estrutura e

comportamento, compilar o mesmo e gerar um simulador para testá-lo em um único

ambiente integrado.

Com o projeto finalizado, o PArchC possibilita a criação do pacote de distribuição do

componente baseado no padrão SPIRIT 1.2, gerando todos os schemas XMLs necessários

para utilização do componente por diversas ferramentas, em especial o PDesigner, através

de sua conexão direta com a biblioteca de componentes, que permite a exportação direta do

componente para a biblioteca da ferramenta.

6 Modelagem e Simulação de MPSoC

Plataformas multiprocessadas apresentam certas particularidades em seus projetos e,

em especial, simulação. Para modelagem de plataformas, como no exemplo da Figura 7

(uma típica plataforma multiprocessada, com dois processadores RISC diferentes, que

rodam aplicações embarcadas que se comunicam através da estrutura de comunicação da

plataforma, neste caso, o barramento AMBA), é necessário, além da definição dos

componentes utilizados, definir como eles estarão interligados, preocupando-se com o

protocolo de comunicação de cada um, além do endereçamento dos mesmos no

barramento e na memória.

Figura 7 Exemplo de Plataforma MPSoC

A conexão entre os componentes deve possuir o mesmo protocolo. Como estes

protocolos são normalmente diferentes em cada um, há a necessidade de inserir wrappers

entre estes componentes, que possibilitem a comunicação através da conversão entre os

protocolos.

Um dos focos do PBuilder na modelagem de plataformas é simplificar ao máximo o

trabalho do projetista, com isto, deixa transparente para o usuário os protocolos de

comunicação, inserindo os wrappers necessários desde que os mesmo existam no

PDLibrary.

Com a plataforma modelada e configurada, o PDesigner gera o modelo SystemC da

plataforma, que possibilitará a criação de simuladores da mesma. Para isto, primeiramente,

é necessário integrar um simulador de instruções (Instruction Set Simulator - ISS) para cada

instância de processador na plataforma. A primeira dificuldade em implementar um modelo

de simulação para uma plataforma multiprocessada é achar o ISS adequado para cada

processador. O PBuilder usa simuladores ISA gerados a partir da descrição de

processadores do ArchC.

A descrição da plataforma com a aplicação embarcada, então, pode ser compilada

resultando em um arquivo executável, o simulador da plataforma. Durante a execução deste

arquivo (simulador) com o código da aplicação, algumas métricas podem ser extraídas,

permitindo o projetista analisar os resultados e modificar a estrutura, configuração e/ou

mapeamento da plataforma.

1.1 Fluxo de Design no PDesigner

O PDesigner, em especial seu plugin PBuilder, possibilita o usuário modelar a

plataforma sem preocupar-se com alguns detalhes importantes que dificultam a modelagem

do sistema seguindo o fluxo de projeto representado na Figura 8.

Através da biblioteca do PDesigner, o projetista pode selecionar o componente

desejado, ou utilizar o PArchC para modelá-lo, exportando-o posteriormente para a

biblioteca do sistema, em uma paleta gráfica de componentes, inserindo-o(s) no editor de

plataformas. Com os componentes inseridos, o projetista conecta-os da maneira desejada e

configura seus parâmetros e o mapeamento de memória dos mesmos.

Figura 8 Fluxo de Projeto

Com a plataforma configurada, o PBuilder gera um modelo SystemC da plataforma

baseada na sua representação alto nível, que será a base para que seja gerado o

simulador. Porém, antes de gerar o simulador, o projetista estará apto para mapear

aplicações na plataforma, indicando em que processador cada uma irá ser executada. Com

a aplicação mapeada, é gerada um modelo completo da plataforma MPSoC, a partir do qual

um simulador realmente funcional e executável será gerado, permitindo o projetista analisar

a plataforma gerada.

7 Biblioteca de Componentes

Focando na modelagem de plataformas baseada nos componentes, o PDesigner

disponibiliza uma biblioteca de componentes descritos em ArchC e SystemC, possibilitando,

porém a inserção de componentes em descritos em outras linguagem com VHDL desde que

sejam distribuídos utilizando o padrão SPIRIT 1.2 reconhecido pelo gerenciador da

biblioteca.

A PDLibrary é composta por componentes desenvolvidos, inicialmente, pelos delo

grupo do ArchC, como é o caso do processadores MIPS, SPARC e POWERPC, do

barramento SimpleBus e do dispositivo FastMemory, estes últimos descritos integralmente

em SystemC. Componentes estes que serviram como base para validação da ferramenta. E

por componentes SystemC desenvolvidos pelo grupo PDesigner, como os barramentos

AMBA, AVALON e uma cache, todos implementados em três níveis de abstração: TL1,

desenvolvimento mais baixo nível, a nível de transferência, baseado em ciclos de relógio;

TL2, implementação intermediária, a nível de transação, com sincronismo estimado, sem

utilização de ciclos de relógio; e TL3, implementação mais elevada, a nível de mensagens,

baseado em comunicação ponto-a-ponto sem noção de tempo (ciclo de relógio).

A PDLibrary, entretanto, encontra-se apta a modificações, possibilitando a adição e

remoção de componentes a qualquer momento.

8 Análise de Cache

Um dos principais focos na modelagem de qualquer sistema embarcado é a

performance da aplicação no mesmo. Esta pode ser obtida através da utilização de

processadores de propósito específico, do paralelismo de processamento, adaptando a

aplicação embarcada e melhorando a taxa de comunicação entre os dispositivos que o

compõem.

Um ponto crucial nesta comunicação deve-se especialmente a diferença na taxa de

processamento dos dados no processador e nos demais dispositivos, especialmente

memória e demais dispositivos de entrada e saída. Para minimizar esta perca de

performance, são utilizadas cachês, memórias mais rápidas, porém caras, que ficam mais

próximas ao processador, diminuindo o tempo entre solicitação e obtenção dos dados

durante o processamento, pois armazena as informações mais utilizadas. Escolher a melhor

cache, portanto, é uma tarefa decisiva na modelagem de plataformas onde o tempo de

resposta é o fator mais importante.

A escolha da melhor cache, porém, depende do foco do projeto e necessidades ou

limitações, técnicas e de custo do projeto. Baseado nisto, o PDesigner possui um plugin de

análise de cache (PCacheAnalyzer), onde o projetista pode adicionar um analisador de

cache no local onde pretende adicioná-la, levando também em consideração o nível da

cache. Simulando apenas uma vez a plataforma, o plugin disponibilizará um relatório,

identificando as diversas configurações possíveis de caches e suas taxas de erro e de

números de acesso, como pode ser visto na Figura 9.

Figura 9 Resultado da Análise de Cache pelo Plugin PCacheAnalyzer

Com as informações obtidas no relatório, o projetista pode escolher e configurar a

cache a ser utilizada de acordo com suas necessidades, trocando graficamente no PEditor o

analisador de cache por uma cache real, configurando-a adequadamente utilizando as

informações geradas no relatório.

9 ConclusãoResultados e trabalhos futuros

10 Referências

[1] AZEVEDO, R.; RIGO, S.; BARTHOLOMEU, M.; ARAÚJO, G.; ARAÚJO, C.; BARROS, E. The ArchC architecture description language and tools. International Journal of Parallel Programming. Vol. 33, No. 5, out, 2005.

[2] VIANA, P.; GORDON-ROSS, A.; KEOGH, E.; BARROS, E.; VAHID, F. Configurable Cache Subsetting for Fast Cache Tunning. In Proceedings of the 43rd Design Automation Conference DAC 2006.

[3] CESÁRIO, W.; BAGHDADI, A.; GAUTHIER, L.; LYONNARD, D.; NICOLESCU, G.; PAVIOT, Y.; YOO, S.; JERRAYA, A.; DIAZ-NAVA, M. Component-based Design Approach for Multicore SoCs. In Proceedings of the 39th Conference on Design Automation, pages 789–794. ACM Press, 2002.

[4] DZIRI, M.-A.; CESÁRIO, W.; WAGNER, F.; JERRAYA, A. Unified Component Integration Flow for Multi-Processor SoC Design and Validation. In Proceedings of DATE, pages 1132–1137, 2004.

[5] BRUNEL, J.-Y.; KRUIJTZER, W.; KENTER, H.; P´ETROT, F.; PASQUIER, L.; KOCK, E.; SMITS, W. COSY Communication IP’s. In Proceedings of the 37th Conference on Design Automation, pages 406–409. ACM Press, 2000

[6] PAULIN, P.; PILKINGTON, C.; BENSOUDANE, E. StepNP: A System-Level Exploration Platform for Network Processors. IEEE Design & Test of Computers, pages 17–26, 2002.

[7] PAULIN, P.; PILKINGTON, C.; BENSOUDANE, E.; LANGEVIN, M.; LYONNARD, D. Application of a Multi-Processor SoC Platform to High-Speed Packet Forwarding. In Proceedings of DATE, pages 58–63, 2004.

[8] WIEFERINK, A.; KOGEL, T.; LEUPERS, R.; ASCHEID, G.; MEYR, H.; BRAUN, G.; NOHL, A. A System Level Processor/Communication Co-Exploration Methodology for Multi-Processor System-on-Chip Platform. In Proceedings of DATE, pages 1256–1263, 2004.

[9] WIEFERINK, A.; LEUPERS, R.; ASCHEID, G.; MEYR, H.; MICHIELS, T.; NOHL, A.; KOGEL, T. Retargetable Generation of TLM Bus Interfaces for MP-SoC Platforms. In Proceedings of CODES+ISSS, pages 249–254, 2005

[10] CESÁRIO, W.; GAUTHIER, L.; LYONNARD, D.; NICOLESCU, G.; JERRAYA, A. Object-based Hardware/Software Component Interconnection Model for Interface design in System-on-a-Chip Circuits. Journal of Systems and Software, 70(3):229–244, 2004.

[11] AZEVEDO, R.; RIGO, S.; BARTHOLOMEU, M.; ARAUJO, G.; ARAUJO, C.; BARROS, E. The ArchC Architecture Description Language. International Journal of Parallel Programming, 33(5):453–484, out, 2005.

[12] VINCENTELLI, A. Defining platform-based design. EE Times. mai, 2002. Disponível

em:

<http://www.eetimes.com/news/design/showArticle.jhtml;jsessionid=BVJCPM15IQNYKQSN

DLRSKH0CJUNN2JVN?articleID=16504380>. Acesso em: 26 jun. 2006.

[13] http://www.archc.org. The ArchC Resource Center.

[14] http://www.eclipse.org. Eclipse Open Source Community.

[15] http://www.spiritconsortium.org. SPIRT consortium.

[17] http://www.systemc.org. SystemC Community.

[18] AMBA Specification Rev(2.0).

[19] http://www.tensilica.com. Tensilica Company.

[20] Coware company. available at http://www.coware.com, February 2006.

[21] HOFFMANN, A., KOGEL, T., NOAH, A., BRAUN, G., SCHLIEBUSH, O., WAHLEN, O.,WIEFERINK, A., MEYER, H. A Novel Methodology for the Design of Application Specific Instruction Set Processors (ASIP) Using a Machine Description Language. In IEEE Transactions on Computer- Aided-Design, pages 1338–1354, nov, 2001.

[22] HALAMBI, A., GRUN, P., GANESH, V., KHARE, A., DUTT, N., NICOLAU, A. EXPRESSION: a Language for Architecture Exploration through Compiler/Simulator Retargetability. In Proceedings of the Conference on Design, Automation and Test in Europe, page 100. ACM Press, 1999.

[23] ABDI, S., SHIN, D., GAJSKI, D. Automatic Communication Refinement for System Level Design. In Proceedings of the 40th conference on Design automation, pages 300–305. ACM Press, 2003.

[24] VAHID, F., GIVARGIS, T. Platform tuning for embedded systems design. IEEE Computer, Vol. 34(3):112 – 114, March 2001.

[25] KOCK, E., SMITS, W., WOLF, P. , BRUNEL, J., KRUIJTZER, W., LIEVERSE, P., VISSERS, K., ESSINK, G.. YAPI: application modeling for Signal Processing Systems. In Proceedings of the 37th Conference on Design Automation, pages 402–405. ACM Press, 2000.