UNIVERSIDADE FEDERAL DE PERNAMBUCOmaag/ic/PDesigner_Monografia(2).doc · Web viewO PDesigner é...
Transcript of UNIVERSIDADE FEDERAL DE PERNAMBUCOmaag/ic/PDesigner_Monografia(2).doc · Web viewO PDesigner é...
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.
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.