Pós-Graduação em Ciência da Computação
“OTIMIZAÇÃO DE INTERCONEXÕES EM
PLATAFORMAS VIRTUAIS”
Por
Adelmario Douglas Leite Cabral Junior
Dissertação de Mestrado
Universidade Federal de Pernambuco
[email protected]
www.cin.ufpe.br/~posgraduacao
RECIFE, AGOSTO/2010
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
ADELMARIO DOUGLAS LEITE CABRAL JUNIOR
“Otimização de Interconexões em Plataformas Virtuais"
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA
UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO
PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA
COMPUTAÇÃO.
ORIENTADOR(A): EDNA NATIVIDADE DA SILVA BARROS
RECIFE, AGOSTO/2010
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
Cabral Junior, Adelmario Douglas Leite
Otimização de interconexões em plataformas virtuais /
Adelmario Douglas Leite Cabral Junior - Recife: O Autor, 2010.
61 folhas : il., fig., tab.
Orientador: Edna Natividade da Silva Barros.
Dissertação
(mestrado)
Universidade
Federal
Pernambuco. CIn. Ciência da computação, 2010.
de
Inclui bibliografia.
1. Engenharia da computação. 2. Sistemas embarcados . 3.
Otimização. 4. Análise de comunicação. I. Barros, Edna
Natividade da Silva (orientadora). II. Título.
621.39
CDD (22. ed.)
MEI2011 – 037
Agradecimentos
A todos que me ajudaram dando suporte ou palavra de apoio durante o
desenvolvimento do projeto.
Aos meus pais, “Seu” Douglas e Dona Suely, e outros parentes que me
apoiaram como minha irmã Clara, minha Tia Luciene e primos, Renato e Dudu.
E ainda meu tio Mario e sua família.
Aos meus amigos de trabalho, e da vida, do LINCS e da UFPE, os quais são
tantos que para não ser injusto e esquecer o nome de algum não citarei nomes.
E por fim, mas não menos importante, a minha orientadora Edna Barros e ao
Professor Cristiano pelo incentivo e conhecimento cedidos durante anos.
Obrigado.
Resumo
Este trabalho apresenta uma abordagem para a geração de uma plataforma
virtual com otimização da comunicação de um SoC a partir de sua descrição
UML. A modelagem do sistema é feita em UML 2.0 utilizando o profile UMLESL, que permite ao desenvolvedor descrever as relações entre os módulos
internos de um sistema sem precisar se preocupar com informações sobre a sua
comunicação, como protocolos e sinais das portas. Além dessa abstração da
comunicação, o UML-ESL permite que o desenvolvedor descreva características
temporais destas comunicações, como quando e quais delas acontecem. Estas
informações são utilizadas como entrada para o trabalho apresentado aqui, que
a partir do formato intermediário SLIF (XML bem definido e estruturado que
guarda as informações de um sistema modelado em UML-ESL) gera uma
plataforma que emula o funcionamento do SoC. A otimização da comunicação é
feita a partir das informações temporais descritas pelo desenvolvedor durante a
modelagem do sistema, com base nessas informações o algoritmo procura
utilizar o menor número de barramentos possíveis para interconectar os
módulos que compõem um SoC, levando-se em conta as requisições que podem
ocorrer em paralelo. Para isso o algoritmo escolhe se a comunicação entre dois
módulos ocorre via um barramento ou conexão ponto a ponto. Para validar o
trabalho apresentado à abordagem foi aplicada a arquitetura de um USB Host,
produzindo a sua arquitetura de comunicação.
Palavras-chave: microeletrônica, análise e projeto, circuitos integrados, geração
de código, geração de interfaces, UML, SystemC.
Abstract
This work presents an approach for the generation of a virtual platform of a
SoC with optimization of communication from its description in UML. The
modeling of the system is made in UML 2.0 using the UML-ESL profile, which
allows the developer to describe the relationship between the internal modules
of a system without having to worry about its communication protocols such as
ports and signals. Besides the abstraction of communication, the UML-ESL
allows the developer to describe the temporal characteristics of these
communications, as when and how they occur. This information about the
system is used as input to the work presented, that come from the intermediate
format SLIF (XML well defined and structured that stores the information of a
system modeled in UML-ESL) creates a platform that emulates the behavior of
the SoC. The optimization of the communication is made from the temporal
information described by the developer during the system modeling. Based on
this information the algorithm aims to use the smallest possible number of
buses to interconnect the modules that form a SoC, considering the requests
that may occur in parallel. For this, the algorithm chooses if the communication
between two modules occurs across a bus or a peer to peer connection. To
validate the work the presented approach was applied to the architecture of a
USB Host, producing its communication architecture.
Keywords: microelectronic, analysis & design, integrated circuits, code
generation, interface generation, UML, SystemC.
Sumário
Resumo .................................................. ................................................... ................................... 5
Abstract .................................................. ................................................... .................................. 6
1.
INTRODUÇÃO .................................................. ................................................... .................. 1
2.
TRABALHOS RELACIONADOS .................................................. .......................................... 6
A UML-BASED APPROACH FOR HETEROGENEOUS IP INTEGRATION ............... 7
2.2.
2.3.
AN UML-DRIVEN INTERFACE GENERATION APPROACH FOR SOC DESIGN
WITH SYNTHESIZABLE SYSTEMC CODE GENERATION .................................................. ... 9
2.4.
DEFINITION OF AN UML SERVICE LEVEL COMMUNICATION PROFILE FOR
THE SYNTHESIS OF SOC ARCHITECTURES .................................................. ..................... 11
ANÁLISE COMPARATIVA .................................................. ........................................ 13
2.5.
3.
UMA TÉCNICA PARA A GERAÇÃO DE COMUNICAÇÃO DE UM SOC .......................... 17
3.1.
VISÃO GERAL .................................................. ................................................... ........ 17
3.2. MODELAGEM DO SISTEMA EM UML-ESL E INFORMAÇÕES SOBRE O FORMATO
SLIF. 19
3.2.1.
DESCRIÇÃO DE ARQUITETURA SOC COM UML-ESL ...................................... 19
3.2.2.
FORMATO INTERMEDIÁRIO SLIF .................................................. ..................... 23
3.3.
OTIMIZAÇÃO DA ESTRUTURA DE COMUNICAÇÃO ................................................. 26
3.4.
GERAÇÃO DA PLATAFORMA VIRTUAL.................................................. ................... 30
3.4.1.
ARQUITETURA DO MÓDULO.................................................. ............................... 32
3.4.2.
ARQUITETURA DE COMUNICAÇÃO .................................................. .................... 34
3.4.3.
PROTOCOLO DE INTERCONEXÃO .................................................. ...................... 36
3.5.
TEMPLATES .................................................. ................................................... .......... 40
3.6.
IMPLEMENTAÇÃO .................................................. ................................................... 41
4.
RESULTADOS .................................................. ................................................... ............ 45
4.1.
ESTUDO DE CASO – USB HOST .................................................. ............................ 45
4.2.
EXPLORAÇÃO DO ESPAÇO DE PROJETO .................................................. ............... 53
5.
5.1.
CONCLUSÃO................................................... ................................................... ............. 57
TRABALHOS FUTUROS .................................................. ............................................ 58
BIBLIOGRAFIA .................................................. ................................................... ...................... 59
Lista de Figuras
Figura 1 Diagramas UML.................................................. ................................................... ..... 7
Figura 2 Fluxo de desenvolvimento do trabalho [2] .................................................. ........... 9
Figura 3 Fluxo de desenvolvimento do trabalho [3] .................................................. ......... 10
Figura 4 Fluxo de desenvolvimento do trabalho [4] .................................................. ......... 12
Figura 5 Fluxo do trabalho desenvolvido .................................................. ........................... 18
Figura 6 Modelagem de um mesmo sistema com UML profile for SoC (a) e UML-ESL
(b). .................................................. ................................................... .......................................... 21
Figura 7 Diagramas de seqüência em UML profile for SoC (a) e UML-ESL (b).............. 22
Figura 8 Formato do arquivo SLIF .................................................. ....................................... 24
Figura 9 Trecho de arquivo SLIF .................................................. .......................................... 25
Figura 10 Grafo gerado a partir do diagrama de seqüência............................................... 27
Figura 11 Exemplo do algoritmo de coloração de grafo. .................................................. .. 28
Figura 12 Arquitetura gerada a partir da coloração do grafo ............................................ 30
Figura 13 Fluxo de geração de código .................................................. ................................. 31
Figura 14 O módulo é composto por três elementos.................................................. ......... 32
Figura 15 do módulo com a interface e comunicação. .................................................. ...... 34
Figura 16 Interfaces de interconexão. .................................................. .................................. 35
Figura 17 Transmissão de uma requisição pelo barramento ............................................. 37
Figura 18 Pacotes de requisição e retorno.................................................. ........................... 38
Figura 19 Pacotes de requisição para barramentos de tamanhos diferentes ................... 39
Figura 20 Esquema simplificado do USB Host .................................................. .................. 46
Figura 21 Diagrama de classes do USB Host.................................................. ...................... 47
Figura 22 Diagrama de seqüência do USB Host .................................................. ................ 48
Figura 23 Grafos gerados a partir da modelagem UML do USB Host ............................. 49
Figura 24 Arquitetura gerada pela técnina apresentada .................................................. .. 49
Figura 25 Trecho de arquivo editado .................................................. .................................. 51
Figura 26 Simulação sendo executada.................................................. ................................. 52
Figura 27 Diagramas de seqüência que geram plataformas diferentes ............................ 54
Figura 28 Diferentes arquiteturas para o USB Host. .................................................. ......... 55
1. INTRODUÇÃO
Hoje em dia a eletrônica está presente em praticamente em todos os lugares. Em
uma rápida análise, é fácil perceber a grande quantidade de aparelhos
eletrônicos sendo utilizados e já integrados ao dia a dia das pessoas, como
microcomputadores, celulares e câmeras digitais. A grande oferta no mercado
destes aparelhos tem facilitado o acesso às novas tecnologias por parte da
população que aos poucos substituem seus antigos equipamentos analógicos
por digitais ou utilizam novos dispositivos que antes não existiam como GPS e
Set-Top Box.
Além de estar presente nos dispositivos de uso pessoal a microeletrônica é cada
vez mais utilizada em áreas como medicina, automobilismo, no uso espacial,
militar etc. Um levantamento feito pelo iNEMI (International Electronics
Manufacturing Initiative) revelou que em 2007 a produção de dispositivos
eletrônicos portáteis envolveu o valor de 300 Bilhões de dólares [1].
Para ganhar uma fatia deste mercado as empresas tendem a se tornar mais
competitivas, oferecendo novos produtos em intervalos de tempo reduzidos e
com custos menores. Porém, para levar vantagem no mercado, os novos
produtos devem apresentar novas funcionalidades, ou melhor eficiência em
relação aos aparelhos já existentes, o que geralmente significa um dispositivo
mais complexo, e conseqüentemente um tempo de desenvolvimento mais longo
e um custo maior do produto final.
Duas restrições que possuem impacto no tempo de desenvolvimento de um
produto são a janela de mercado e o time-to-market. A janela de mercado pode
ser definida como o período de tempo em que um produto deverá estar no
mercado para que se obtenha o maior lucro, e o time-to-market o tempo
necessário para que um produto em desenvolvimento esteja pronto.
1
O preço de um produto pode ser relacionado a muitos fatores, mas em geral o
preço final é calculado a partir de dois parâmetros: o custo de produção e o
custo de engenharia. O primeiro está atrelado ao preço dos materiais utilizados
na confecção do produto, ao volume de produção, ou ainda ao modo de
produção, se produzido em escala ou montado manualmente etc. O segundo, e
não menos importante, é custo de engenharia que é a parte intelectual do
desenvolvimento, geralmente é medido pelo número de engenheiros e o tempo
gasto por eles em um projeto. Onde um termo bastante utilizado para medir o
esforço é o homem/hora, que significa horas trabalhadas por um engenheiro.
Devido à alta concorrência, o time-to-market para que um produto eletrônico
atinja a janela de mercado é geralmente bastante curto. Se for necessário manter
o mesmo número de homens/hora num projeto mais complexo é preciso o uso
de novas técnicas que permitam o aumento da produtividade.
Ultimamente o que se tem tentado em relação ao desenvolvimento de novos
dispositivos é tirar a complexidade das mãos dos desenvolvedores, deixando-os
responsáveis somente pela arquitetura em alto nível de abstração, e passá-la a
ferramentas de síntese, que se encarregam de gerar o código final. Com isso
procura-se diminuir o tempo de desenvolvimento de uma nova funcionalidade
(um novo core, que é um bloco lógico utilizado na construção de circuitos
integrados) devido à implementação em alto nível ser mais rápida, por parte do
desenvolvedor que não precisa ficar atento a muitos detalhes, e também
diminuir o número de erros de implementação, já que a código fonte é gerado
de maneira automática.
Um bom exemplo do aumento da produtividade devido o aumento do nível de
abstração são as linguagens de programação: a adoção da linguagem ANSI C
no lugar da Assembly, e mais tarde o uso da linguagem C++, no lugar da ANSI
C trouxeram grandes ganhos no desenvolvimento de sistemas.
2
Em desenvolvimento de hardware nota-se também um aumento do nível de
abstração nas linguagens de programação: as mais antigas como VHDL [20] e
Verilog [21] dando espaço a linguagens como SystemC [22] e MyHDL [23]
(Python [24]). Neste cenário o uso da linguagem UML tem surgido como uma
alternativa para a modelagem de sistemas em um nível ainda mais abstrato.
Unified Modeling Language, ou UML, é uma linguagem de modelagem que provê
uma melhor visualização lógica de um sistema a partir de vários diagramas
especializados. Os diagramas são definidos como elementos gráficos que
representam objetos e seus relacionamentos dentro de um sistema. Em UML é
permitida a especialização de diagramas, que permite dar significado aos
objetos e seus relacionamentos, o que deu margem ao surgimento de profiles
UML especializados para o desenvolvimento de SoCs [19], System on Chip.
SoCs são sistemas inteiros, compostos por vários módulos em um único circuito
integrado (Chip), onde um módulo é uma unidade funcional digital, analógica
ou mista implementada em hardware, FPGA ou em ASIC, por exemplo.
A interconexão entre esses módulos de um SoC tem um grande impacto no
custo e no desempenho do sistema devendo ser escolhida com muito cuidado.
Uma solução utilizada para se reduzir a área ocupada pelas interconexões em
um SoC é o compartilhamento da interconexão, onde por exemplo mais de dois
módulos se comunicam através de um mesmo barramento. De fato esta solução
ocupa uma menor área, porém pode reduzir o desempenho devido à contenção
do barramento, que é quando um módulo precisa se comunicar com outro
através do barramento e ele se encontra ocupado.
Uma abordagem que evita o problema da contenção é a interconexão ponto a
ponto dos módulos; esta solução garante que o meio de comunicação entre dois
módulos nunca vai estar ocupado por outro módulo, pois existe uma
interconexão exclusiva entre eles. Por outro lado esta solução apresenta a
3
desvantagem de aumentar a área ocupada com interconexão no SoC e o custo
de roteamento dos sinais que interconectam os módulos.
Além do que foi citado, um SoC precisa ter seu funcionamento verificado antes
de entrar no mercado, e quanto mais tarde um erro é encontrado mais caro se
torna o custo para resolver o problema. Para se detectar mais cedo os possíveis
erros em um SoC uma abordagem utilizada tem sido a simulação de
plataformas virtuais. Uma plataforma virtual é um sistema desenvolvido em
um alto nível de abstração que permite simular o comportamento do SoC, com
isso é possível ter uma idéia do funcionamento do sistema e detectar com
antecedência possíveis problemas. Outras vantagens de uma plataforma virtual
são a velocidade de simulação e a rapidez com que essa plataforma pode ser
modificada, o que facilita a exploração das várias possíveis arquiteturas do SoC.
Existem trabalhos que buscam aumentar a produtividade no desenvolvimento
de SoCs utilizando a geração automática de código a partir de modelagens em
alto nível de sistemas. Na abordagem proposta por [2] as interfaces entre os
módulos são modeladas em UML e partir desta modelagem são gerados
adaptadores que permitem a interconexão dos módulos.
Na abordagem apresentada por [3] um sistema é modelado em UML utilizando
um profile para SoC, de onde é gerada uma plataforma virtual simulável e
sintetizável em que os módulos são conectados ponto a ponto. Já o trabalho [4]
propõe um novo profile UML para a modelagem de sistemas onde as
informações
sobre
as
interconexões
entre
os
módulos
são
bastante
simplificadas. O trabalho também apresenta uma ferramenta que gera uma
plataforma simulável do sistema a partir da sua descrição em UML.
A respeito da modelagem das interconexões em UML, os trabalhos propostos
em [2] e [3] precisam receber informações adicionais sobre a comunicação, como
protocolos, portas e etc. Enquanto que na abordagem proposta em [4] estas
4
informações não são necessárias. Por fim, os trabalhos [3] e [4] não permitem a
utilização de conexões ponto a ponto e por barramento num mesmo SoC, em [3]
só são geradas conexões ponto a ponto e em as interconexões são feitas por um
único barramento [4].
O trabalho proposto neste mestrado apresenta uma nova abordagem para a
geração automática de uma plataforma virtual a partir da modelagem UML do
sistema. Tendo como principal diferença em relação aos outros trabalhos a
geração de uma arquitetura de comunicação mais flexível, permitindo
interconexões por meio de barramento ou ponto a ponto. Essa arquitetura de
comunicação mais flexível permite uma melhor exploração das possibilidades
de interconexões, o que tem como vantagem, a obtenção de um SoC com menor
área de silício e tem menor esforço de roteamento dos sinais de interconexão.
A modelagem do sistema na abordagem proposta é feita utilizando-se a
especificação UML-ESL, definida no trabalho [4]. A escolha do profile UML-ESL
baseou-se na maior abstração da comunicação na modelagem do sistema, onde
as escolhas referentes à comunicação são feitas de maneira automática pela
ferramenta.
O resultado da abordagem proposta é uma plataforma virtual que fornece um
ambiente simulável do sistema, permitindo reduzir esforço na implementação
da plataforma virtual.
Esta dissertação está estruturada da seguinte forma. No capítulo 2 são
apresentados alguns trabalhos que estão relacionados com a geração automática
de código a partir de descrições UML. No capítulo 3 explica-se passo a passo
como as informações são extraídas do UML até a geração da plataforma
simulável. No capítulo 4 são apresentados os resultados obtidos com a
utilização da abordagem proposta em um estudo de caso. E finalmente as
conclusões e trabalhos futuros são apresentados no capítulo 5.
5
2. TRABALHOS RELACIONADOS
Neste capítulo são apresentadas algumas soluções para a geração automática de
interfaces de comunicação em um SoC. Todos os trabalhos partem da
modelagem UML do sistema, apresentam soluções para a conexão dos módulos
e então o código fonte é gerado.
2.1.
INTRODUÇÃO A UML E UML-ESL
A UML, Unified Modeling Language [25], é uma linguagem de modelagem
orientada a objeto composta por diagramas que representam a arquitetura e
(ou) o comportamento de um sistema. Sendo um diagrama é uma representação
visual de um determinado conceito.
Um primeiro esboço da linguagem UML surgiu em 1994 quando os
pesquisadores Grady Booch e James Rumbaugh juntaram alguns aspectos de
seus
métodos
de
modelagem
(OMT
[5]
e
Metodologia
Booch
[6],
respectivamente) em uma linguagem chamada Unified Method. Em 1996 com a
contribuição do pesquisador Ivar Jacobson com sua metodologia OOSE [7] a
linguagem UML surgiu.
A versão 2.0 da UML define treze tipos de diagramas que podem ser utilizados
para se modelar um sistema. Estes diagramas são divididos três grupos que
definem estrutura, comportamento e informações temporais do sistema. A
Figura 1 mostra dois exemplos de diagramas UML:
6
Figura 1 Diagramas UML
O diagrama de seqüência reflete informações temporais do sistema, a figura
1(a) representa o método serviceA sendo executado e logo após o método
serviceB. Já a figura 1(b) representa um diagrama de classes, que representa a
estrutura e as relações entre os objetos (módulos) de um sistema.
Adicionalmente, a versão 2.0 do UML permite a customização de seus
diagramas por meio de estereótipos e tags, o que dá ao usuário a possibilidade
modelar sistemas para um domínio especifico. Essas customizações permitiram
o surgimento de profiles UML com foco na modelagem de SoCs.
Dois exemplos de profile para a modelagem de SoC são o UML profile for SoC
e o UML-ESL. No UML profile for SoC são incluídos estereótipos que
representam vários elementos de uma arquitetura SoC, como processos,
módulos, protocolos, etc. Enquanto no UML-ESL é possível a modelagem do
sistema com menos estereótipos.
2.2.
A UML-BASED APPROACH FOR HETEROGENEOUS
IP INTEGRATION
Na abordagem proposta por [2] foi apresentada uma solução para a modelagem
em alto nível de abstração das intercomunicações de um SoC utilizando UML.
Adicionalmente, os problemas de módulos que possuem interfaces diferentes
7
(módulos que possuem protocolos ou portas incompatíveis) são resolvidos por
meio de adaptadores que também são modelados em UML.
A descrição do sistema é feita utilizando-se diagramas de objeto, de estrutura, e
diagramas de estados que contém informações sobre os protocolos utilizados
pelos módulos. A partir da informação extraída destes diagramas são geradas
interfaces que permitem a interconexão dos módulos por meio do uso do
protocolo OCP-IP [8].
A modelagem do sistema é dividida em três passos:
1. Formalização das interfaces dos módulos: informar (modelar no UML)
que protocolos e que portas um módulo utiliza.
2. Definição dos módulos adaptadores: informar como o módulo adaptador
irá transformar as requisições de um protocolo de comunicação qualquer
para o protocolo OCP-IP.
3. Definição do comportamento para interfaces incompatíveis: definir o
comportamento do módulo adaptador quando as interfaces dos módulos
que ele conecta possuem portas de tamanhos diferentes.
O fluxo de desenvolvimento do trabalho é mostrado na Figura 2.
8
Figura 2 Fluxo de desenvolvimento do trabalho [2]
O sistema é modelado em UML utilizando a ferramenta de modelagem
Rhapsody, onde as informações sobre o sistema são salvas no arquivo de
formato sbs. O arquivo sbs gerado pela ferramenta Rhapsody possuí todas as
informações do sistema que foram modeladas, e que são recuperadas para a
geração do código através de do SBS Parser. Por fim, as informações obtidas do
arquivo sbs juntamente com a biblioteca de templates, que possui informações
sobre como o código deve ser implementado, são utilizados para a criação do
código fonte.
No trabalho apresentado apenas o código fonte das interfaces são geradas, ou
seja, os módulos que serão conectados já devem existir previamente. Após a
geração do código (Adapter and Glue Logic) os módulos, os quais suas
interfaces foram modeladas em UML-ESL, poderão se comunicar permitindo
assim a simulação do sistema.
Apesar de resolver os problemas de incompatibilidade entre cores e apresentar
uma modelagem em alto nível o trabalho [2] apresenta uma desvantagem no
modelo proposto para a modelagem das conexões entre os módulos, pois é
preciso especificar o comportamento de cada módulo adaptador do sistema, o
que pode se tornar bastante custoso se houver muitas interconexões em um
SoC.
2.3.
AN UML-DRIVEN INTERFACE GENERATION
APPROACH FOR SOC DESIGN WITH SYNTHESIZABLE
SYSTEMC CODE GENERATION
No trabalho [3] é proposta uma técnica de geração automática de uma
plataforma virtual descrita em código SystemC, sintetizável, a partir da
descrição do sistema feita em UML 2.0 utilizando o profile para SoC. O trabalho
segue a metodologia ipProcess [10], que é um processo de desenvolvimento de
9
IP-Cores dividido em disciplinas, que vão desde a concepção do projeto até sua
implementação em FPGA.
A modelagem do sistema é feita utilizando-se três diagramas: diagramas de
casos de uso, diagramas de classes e diagrama de seqüência. Estes diagramas
definem as classes, seus relacionamentos (como estão ligados) e, ainda, o
protocolo utilizado em cada interconexão.
O código é gerado a partir das informações obtidas da especificação UML do
sistema, utilizando o profile UML for SoC. A interconexão entre os módulos é
feita ponto a ponto, com o a troca de informações podendo ocorrer por
protocolos que utilizam portas paralelas ou seriais.
O trabalho apresenta a vantagem de gerar código pronto para ser sintetizado
por uma ferramenta de síntese lógica. A Figura 3 mostra o fluxo de
desenvolvimento do trabalho.
Figura 3 Fluxo de desenvolvimento do trabalho [3]
O sistema é modelado em UML utilizando o profile para SoC. A geração de
código utiliza como uma das entradas as informações sobre o sistema, que foi
modelado em UML profile para SoC, e que devem ser armazenadas num
arquivo no formato XMI. Dependendo da ferramenta utilizada para a
10
modelagem do sistema, o parser precisa ser modificado para que possa
reconhecer a estrutura dos dados gerada pela ferramenta de modelagem UML,
neste trabalho a ferramenta utilizada foi a Visual Paradigm e o arquivo XMI
gerado por ela. O núcleo de geração de código utiliza as informações obtidas a
partir do XMI Parser e a biblioteca de templates para gerar a plataforma virtual.
Os códigos fonte da plataforma virtual gerada implementam tanto os módulos
quanto a comunicação entre eles, que é feita por meio de conexões ponto-aponto. O código fonte também é gerado utilizando diretivas da ferramenta
Forte da Altera, com objetivo de permitir a síntese lógica do código.
A abordagem proposta reduz o tempo de desenvolvimento por gerar código
automaticamente e permitir que este código seja utilizado como entrada em
outra ferramenta de síntese. Porém, assim como em [2], durante a modelagem o
usuário precisa indicar informações sobre a comunicação de cada conexão entre
módulos. Outro ponto negativo é a inflexibilidade da arquitetura da
comunicação, onde todos os módulos são conectados ponto a ponto, o que não
permite uma exploração da comunicação.
2.4.
DEFINITION OF AN UML SERVICE LEVEL
COMMUNICATION PROFILE FOR THE SYNTHESIS OF
SOC ARCHITECTURES
O trabalho proposto em [4] define uma novo modelo (profile) para a
modelagem de SoCs utilizando UML 2.0. O novo profile permite uma maior
abstração na modelagem do sistema ao mesmo tempo em que permite
expressar paralelismo entre as comunicações.
O novo profile apresentado utiliza dois diagramas UML para modelar o
sistema: diagrama de classes e o diagrama de seqüencia, e foi batizado UMLESL. O diagrama de classes é utilizado para definir os serviços que são
11
oferecidos e utilizados pelo módulo, enquanto o diagrama de seqüencia
expressa as informações temporais sobre as comunicações. Para evitar que o
trabalho fique preso a uma única ferramenta de modelagem UML, e permitir
uma distribuição mais fácil do sistema modelado em UML-ESL, também foi
definido um formato intermediário de distribuição, o SLIF.
O SLIF (acrônimo para System Level Intermediate Format) é uma estrutura no
formato XMI onde as informações sobre a arquitetura estão organizadas numa
árvore. Este formato intermediário dá ao desenvolvedor uma maior liberdade
em relação a que ferramenta de modelagem UML utilizar, pois o arquivo que
deve conter as informações do sistema é bem definido e não está atrelado a
nenhuma ferramenta de modelagem UML especifica. Por outro lado é
necessária a criação de um novo parser que transforme a informação do sistema
modelado pelas ferramentas para o formato SLIF.
A Figura 4 mostra o fluxo de desenvolvimento do trabalho.
Figura 4 Fluxo de desenvolvimento do trabalho [4]
O sistema é modelado em UML utilizando o profile UML-ESL, onde o arquivo
gerado pela ferramenta de modelagem UML (UML Tool export file (XMI)), que
contém as informações sobre a modelagem do sistema, é então transformado
para o formato SLIF através do XMI Parser. O arquivo SLIF é utilizado como
12
entrada para a ferramenta de geração de código, onde suas informações são
recuperadas através do SLIF Parser, e utilizadas junto com a biblioteca de
templates de código para a geração do código da plataforma virtual.
A plataforma gerada contém os módulos e sua comunicação, que é feita por
meio de um único barramento. Além disso, a plataforma é gerada com um
pacote de distribuição que segue o padrão IP-XACT [11], onde estão os códigos
fonte, scripts para a plataforma de simulação e arquivos de configuração do
sistema.
A utilização do UML-ESL consiste num ótimo modelo de abstração da
comunicação, o fato do desenvolvedor não precisar se preocupar em como os
módulos estão conectados implica num ganho de tempo na descrição do
sistema e a diminuição de erros de implementação, devido ao fato do código ser
gerado automaticamente. Porém a plataforma gerada pela ferramenta é pouco
flexível devido à intercomunicação dos módulos, onde as suas conexões são
feitas por meio de um único barramento, não havendo a possibilidade de
escolha no tipo de conexão entre os módulos. Além disso, o uso de um único
barramento para a comunicação entre todos os módulos pode gerar problemas
de contenção.
2.5.
ANÁLISE COMPARATIVA
As abordagens apresentadas se baseiam na modelagem de SoCs usando UML
com síntese de código para comunicação, com exceção do último trabalho [4],
que propõe uma solução mais completa incluindo a descrição de processadores
de propósito geral (sw) e processadores de propósito especifico (hw).
A abordagem proposta por [2] foca no desenvolvimento de módulos
adaptadores que permitem dois módulos, que possuem interfaces de
comunicações diferentes, se comunicarem. Para que dois módulos com
13
interfaces diferentes se comuniquem o desenvolvedor precisa fornecer
informações comportamentais sobre como os módulos adaptadores devem
funcionar. Isto é feito durante a modelagem UML do sistema por meio de
diagramas de estado, o que é desvantajoso, pois requer um esforço maior na
modelagem da comunicação.
Na abordagem [3] o sistema é modelado utilizando o profile padrão para
desenvolvimento de SoC definido pela OMG, o UML profile for SoC. No UML
profile for SoC as comunicações entre os módulos são definidas com vários
elementos UML que representam elementos da intercomunicação de um SoC,
como portas, protocolos e interfaces. Logo o usuário precisa fornecer
informações sobre a comunicação durante a modelagem do sistema, isto
permite um maior controle sobre a plataforma que irá ser gerada, porém
também aumenta as chances de erros por parte do desenvolvedor, além de
consumir tempo de projeto.
Um modelo mais simples de modelagem da comunicação é proposto no
trabalho [4], o UML-ESL. Com o uso do UML-ESL a informação modelada
sobre a intercomunicação dos módulos é feita apenas indicando informações
em alto nível (comunicação síncrona ou assíncrona e paralela ou seqüencial)
sobre uma comunicação entre dois módulos. Ou seja, não é preciso especificar
nenhuma informação de protocolo, porta ou interface. Além disso, o UML-ESL
permite extrair informações de paralelismo nas comunicações entre os módulos,
o que permite fazer uma melhor análise do comportamento do sistema.
Considerando a arquitetura gerada, o trabalho [4] gera o código baseado numa
plataforma base que implementa as comunicações através de um único
barramento. Em [3] todas as comunicações são implementadas por conexões
ponto a ponto. No [2] a comunicação é especificada durante a modelagem
14
UML, podendo ser via barramento ou ponto a ponto, e utiliza o protocolo OCPIP.
A modelagem UML nos trabalhos [2] e [3] permitem uma maior escolha de
como a comunicação ocorrerá entre os módulos que compõem um SoC ao custo
de aumentar a complexidade da modelagem do sistema, enquanto em [4] a
modelagem é feitas de maneira mais simples. As plataformas geradas por [3] e
[4] utilizam um mesmo tipo de comunicação para todos os módulos do sistema,
o que não permite uma maior exploração da comunicação do sistema.
O trabalho [4] apresenta uma vantagem adicional que é a formalização da
informação da modelagem UML do sistema em um formato intermediário. Isto
permite uma maior liberdade em relação a que ferramenta de modelagem UML
o desenvolvedor pode usar, já que as informações contidas no modelo do
sistema são armazenadas em estruturas bem definidas.
Levando-se em consideração os critérios a seguir, a Tabela 1 apresenta a
comparação entre os três trabalhos apresentados.
•
Nível de abstração da comunicação na modelagem:
1. Informação sobre a conexão, o protocolo e o funcionamento.
2. Informação sobre a conexão e sobre o protocolo.
3. Informação sobre a conexão.
•
Arquitetura de comunicação gerada.
1. Ponto a ponto
2. Barramento
3. Ponto a ponto e barramento
•
Geração da plataforma virtual
1. Manual
2. Semi-Automática
3. Automática
15
Tabela 1. Comparação entre os trabalhos.
ABSTRAÇÃO
ARQUITETURA
AUTOMAÇÃO
CHENG
1
3
2
AZIZ
2
1
3
MILLENA
3
2
2
O trabalho apresentado nesta dissertação utiliza-se da facilidade da modelagem
UML-ESL, definida no trabalho [4], para a modelagem de SoC com a geração do
código fonte de uma plataforma virtual simulável, incluindo os módulos e a
comunicação entre eles.O diferencial entre o trabalho proposto e os
apresentados neste capítulo está na geração otimizada da estrutura da
comunicação entre os módulos, onde as informações sobre o paralelismo nas
comunicações são levadas em consideração na hora da escolha da conexão entre
os módulos, que pode ser via barramento ou ponto a ponto. Com isso espera-se
que o impacto da interconexão dos módulos sobre a área total do SoC seja
diminuído, devido ao compartilhamento da comunicação, sem existir perdas na
eficiência do sistema causados pelo problema de contenções.
16
3. UMA TÉCNICA PARA A GERAÇÃO DE COMUNICAÇÃO
DE UM SOC
Neste capitulo é apresentado o trabalho proposto neste mestrado. Primeiro a
abordagem é mostrada de maneira superficial, para se ter uma noção inicial do
funcionamento da técnica proposta, em seguida é explicado o passo a passo que
vai da modelagem UML até a geração da plataforma virtual.
3.1.
VISÃO GERAL
Estudos mostram que as interconexões em soluções em FPGA (Field
Programable Gate Array), são responsáveis por 70% a 80% da área total [12] e
75% a 85% da potência total consumida [13], estima-se que nas implementações
em ASIC o problema deva ser parecido. Uma boa prática para diminuir o
impacto das interconexões no SoC é promover o compartilhamento do canal de
comunicação, ou seja, compartilhar o barramento.
A idéia do compartilhamento de barramento é fazer com que a comunicação
dos módulos de um SoC ocorram em um único barramento, com isso é possível
diminuir a quantidade de vias de comunicação entre os módulos,
economizando área do SoC e proporcionando um menor esforço no roteamento
dos sinais. Porém, apesar das vantagens apresentadas, o uso de um único canal
de comunicação por mais de um módulo pode levar a uma redução no
desempenho devido à contenção no barramento, que é o barramento
permanecer ocupado com uma transação enquanto outro módulo precisa
transmitir um dado.
Uma abordagem que evita o problema de contenção é a interconexão ponto a
ponto de cada módulo que se comunica, porém essa solução gera uma maior
17
área do SoC e torna o roteamento dos módulos mais difícil, devido ao grande
número de sinais entre os módulos.
A proposta apresentada neste trabalho é utilizar uma arquitetura de
comunicação mista, com o uso mínimo de barramentos e conexões ponto a
ponto. A princípio se deseja utilizar um único barramento para a conexão entre
os módulos, mas detectando-se a ocorrência de comunicação concorrente que
pode levar a contenção, serão usadas conexões ponto a ponto para evitar
contenção de barramento. A Figura 5 mostra o fluxo do trabalho desenvolvido.
Figura 5 Fluxo do trabalho desenvolvido
Primeiro o sistema é modelado em UML-ESL, então as informações são
exportadas para o formato intermediário SLIF. Do SLIF são extraídas
informações sobre os módulos e sobre as comunicações, onde as informações
temporais sobre as comunicações entre os módulos são representadas em um
grafo de comunicação que otimiza a comunicação por meio de um algoritmo de
coloração. Por fim o grafo colorido, as informações sobre os módulos obtidas do
SLIF e um conjunto de templates são então utilizados para a geração da
plataforma simulável.
18
Nas próximas seções cada passo da Figura 5 é explicado com mais detalhes.
3.2.
MODELAGEM DO SISTEMA EM UML-ESL E
INFORMAÇÕES SOBRE O FORMATO SLIF.
O trabalho apresentado utiliza-se da modelagem UML-ESL do sistema e o
formato intermediário SLIF apresentados no capitulo 2.4, e desenvolvidos por
[4]. Nesta seção serão apresentadas explicações mais aprofundadas sobre o
UML-ESL e o formato SLIF, com o intuito de aumentar o entendimento sobre o
trabalho desenvolvido nesta dissertação.
3.2.1.
DESCRIÇÃO DE ARQUITETURA SOC COM
UML-ESL
UML-ESL é um profile UML 2.0 para SoC orientado pelos preceitos ESL. A
definição de ESL é dada por: “a utilização de abstração apropriada visando o
aumento da compreensão de um sistema e o aumento da probabilidade de
sucesso na implementação de uma funcionalidade de uma maneira custo
eficiente” [14].
O UML-ESL é bem recente, tendo surgido em 2010 no trabalho desenvolvido
por GOMES [4], porém consta numa representação bastante simples e eficiente
para a descrição de SoCs. Em UML-ESL a descrição da comunicação entre os
módulos é feita em nível de serviços, permitindo a abstração do protocolo e da
estrutura de comunicação do sistema. Os tipos de comunicações em UML-ESL
foram baseados em [15], e são divididas em síncrona ou assíncrona e paralela
ou seqüencial como mostrado na Tabela 2.
19
Tabela 2 Tipos de comunicação em UML-ESL
Característica
Classificação
Tipo
Síncrono
Assíncrono
Modo
Seqüencial
Paralelo
Em uma comunicação do tipo síncrona o módulo solicitante ocupa a
interconexão esperando por uma resposta do módulo solicitado, enquanto no
tipo assíncrono é feita uma requisição ao modulo solicitado e o modulo que
solicitou não ocupa a interconexão. O modo de comunicação seqüencial
significa que as comunicações ocorrem em tempos distintos e de maneira
ordenada, enquanto no modo paralelo as comunicações ocorrem ao mesmo
tempo.
O UML-ESL utiliza dois diagramas para modelagem do sistema: o diagrama de
classes e o diagrama de seqüência. O diagrama de classes possui informações
sobre os módulos e como eles se relacionam uns com os outros, e o diagrama de
seqüencia representa informações sobre quando e como são feitas as
comunicações entre os módulos.
A justificativa da escolha do profile UML-ESL ao UML profile for SoC foi
basicamente a simplicidade na modelagem do sistema. No diagrama de classes
o profile UML-ESL permite uma maior abstração da comunicação em relação ao
UML profile for SoC. Enquanto no UML for SoC é preciso definir os protocolos,
portas, canais e interfaces entre cada módulo, no UML-ESL isso é feito apenas
indicando que existe uma comunicação utilizando-se de um relacionamento,
símbolo UML representado por uma seta.
A modelagem de um sistema em UML profile for SoC torna-se poluída e
custosa se o número de módulos que compõe o sistema for grande. Isto porque
para cada interconexão entre dois módulos é preciso definir vários elementos
UML que representam portas, interfaces e canal de dados.
20
A diferença entre modelagens dos diagramas de classes nos dois profiles pode
ser vista na Figura 6, que apresenta a descrição UML de um mesmo sistema
utilizando UML profile for SoC e UML-ESL.
Figura 6 Modelagem de um mesmo sistema com UML profile for SoC (a) e UML-ESL (b).
Os diagramas de classes apresentados na Figura 6 representam um mesmo
sistema que é composto por cinco módulos, A, B, C, D e E. O módulo A acessa
os serviços dos módulos C (serviceC), B (serviceB) e D (serviceD), e o módulo D
acessa o serviço fornecido pelo módulo E (serviceE).
Enquanto no UML profile for SoC é necessária a criação de mais classes que
representam a comunicação entre os módulos em UML-ESL basta apenas
indicar que existe um relacionamento entre elas (indicado pela seta pontilhada
que une os módulos na figura 6(b)). Ainda na descrição UML-ESL existe a
possibilidade de se modelar software (que é representado por meio do
estereótipo <<sw_module>>, ao contrário do mostrado na figura 6(b) onde só
21
são mostrados módulos de hardware, <<hw_module>>), o que não ocorre com o
UML profile for SoC, que só modela hardware. Em contrapartida, no UML
profile for SoC o desenvolvedor tem a liberdade de especificar alguns
parâmetros de interconexão entre dois módulos, como protocolo e largura do
barramento, enquanto em UML-ESL essa escolha é feita em um nível mais baixo
no mapeamento para uma plataforma base.
Comparando ainda os dois profiles, as duas representações usam de diagramas
de seqüencia para indicar que serviços são utilizados entre módulos, porém
somente em UML-ESL existe a informação temporal de quando e como isso
pode ocorrer, indicando comunicações paralelas e seqüenciais, síncronas e
assíncronas no sistema.
Os diagramas de seqüências em UML-ESL e UML profile for SoC do sistema
modelado na Figura 6 são apresentados na Figura 7.
Figura 7 Diagramas de seqüência em UML profile for SoC (a) e UML-ESL (b)
A descrição UML-ESL suporta a indicação dos serviços que são utilizados entre
os módulos com a adição da informação temporal por meio de labels SEQ e
22
PAR, que indicam se os acessos são seqüenciais ou paralelos, respectivamente.
Essa informação é necessária para resolver os problemas de paralelismo na
comunicação, explicados posteriormente. Além disso, no UML-ESL é informado
se a comunicação é síncrona ou assíncrona.
Este trabalho está baseado em UML-ESL pelos motivos discutidos a seguir:
1. Consiste uma maneira mais simplificada da descrição do sistema, que não
exige que o desenvolvedor represente os detalhes da interconexão dos
módulos em um SoC na descrição do sistema. Essa escolha será feita
posteriormente por ocasião do mapeamento para a plataforma como
proposto neste trabalho.
2. Suporta a descrição de informações temporais a respeito de quando as
comunicações ocorrem, descrevendo se são seqüenciais ou paralelas.
3. Inclui um formato intermediário bem definido e estruturado, que será
utilizado como entrada para o trabalho.
No trabalho apresentado, a partir da descrição do sistema em UML-ESL
utilizou-se o parser implementado no trabalho desenvolvido por [4] para gerar
o formato intermediário SLIF, como explicado a seguir.
3.2.2.
FORMATO INTERMEDIÁRIO SLIF
Para facilitar processamento do sistema descrito em UML-ESL por outras
ferramentas foi utilizado o formato de representação intermediária que
especifica de uma maneira organizada as informações modeladas no profile
UML-ESL definido em [4]. Este formato é denominado SLIF, que significa
System Level Intermediate Format. O SLIF é um formato baseado em XMI que
organiza as informações em uma estrutura de árvore, como mostrado na Figura
8.
23
Figura 8 Formato do arquivo SLIF
Cada retângulo na figura representa uma tag no arquivo SLIF. Uma tag é uma
marcação que armazena uma informação como será explicado posteriormente.
O formato SLIF é composto de várias tags que representam as informações do
profile UML-ESL e está dividido em dois grupos principais, System Architecture
e Transactions Ordering.
O System Architecture é composto de vários elementos do tipo Module, que
representam as classes definidas no diagrama de classes com algumas
informações do diagrama de seqüencia. É no elemento Module que são
armazenadas as informações sobre os serviços que os módulos fornecem e
utilizam de outros módulos, bem como os detalhes destes serviços, incluindo
tipo de parâmetros, tipo de retorno e código fonte.
No ramo Transactions Ordering são listados elementos que capturam
informações sobre a comunicação dos módulos através dos serviços. Entre as
informações capturadas destacam-se informações sobre acessos paralelos e
seqüenciais e se a comunicação é síncrona ou assíncrona. Além disso, estes
24
elementos capturam informações sobre que módulos utilizam que serviços de
outros módulos.
Na Figura 9 é mostrado um trecho de arquivo SLIF, o exemplo mostra como as
informações
contidas
no
ramo
“module”
são
armazenas.
Figura 9 Trecho de arquivo SLIF
O modulo representado na Figura 9 é chamado ALU (atributo “name” na tag
“modulo”) e fornece o serviço “soma” (atributo “name” na tag “service”) que
recebe dois parâmetros do tipo char (tags “entries” e “entry”) e retorna um
inteiro (tag “result”), código se encontra entre duas tags, “<sourceCode> e
</sourceCode>”. O módulo ALU também utiliza serviços de um módulo
chamado DEST (tag “usedModule”), porém os detalhes estão descritos no ramo
Transactions do SLIF.
O arquivo XMI do SLIF é composto de tags que representam as informações
exportadas do modelo UML-ESL. Essas tags estão alinhadas seguindo a
hierarquia mostrada na árvore da Figura 8, com a tag “<system>” sendo a de
maior nível. O fim da tag é marcado com uma “/” antes do seu nome, sendo
25
assim uma tag que comece por “<entries>” tem obrigatoriamente que terminar
por “</entries>”, por exemplo.
Para extrair as informações da descrição SLIF foi desenvolvido um parser que
recupera essas informações e transforma em uma estrutura de dados que possa
ser trabalhada pela ferramenta proposta.
O parser varre todos os campos da estrutura XMI recuperando as informações
contidas na descrição SLIF. A varredura dos campos do SLIF ativa funções de
análise cada vez que uma tag é encontrada ou fechada (marcada com o
caractere “/”). Essas funções de análise recuperam as informações contidas
dentro da tag e armazenam em estruturas de dados da ferramenta de geração
de código.
São definidas duas estruturas de dados para capturar as informações do SLIF,
uma possui informações dos módulos e a outra das comunicações. As
informações de cada módulo e de cada comunicação são armazenadas em duas
listas. A lista que contém a informação sobre as comunicações é usada para
representar o grafo de comunicações e lista com as informações sobre os
módulos é utilizada na geração de código da plataforma virtual.
3.3.
OTIMIZAÇÃO DA ESTRUTURA DE COMUNICAÇÃO
Para escolher se a conexão dos módulos será feita por barramento ou se será
conexão ponto a ponto, as informações sobre quando e como os módulos se
comunicam são mapeadas em um grafo não direcionado como definido a
seguir.
Sendo G(V, A) o grafo formado a partir das interconexões entre os módulos que
são definidos pela modelagem do sistema em UML-ESL, G(V, A) é definido
pelo par de conjuntos V e A, onde:
26
•
V é o conjunto
o de
d vértices do grafo com V ∅ ; onde
nde cada vértice
representa uma comunicação
co
entre dois módulos.
•
A é o conjunto de pares ordenados a = (v, w), onde v e w ∈ V, cada aresta
do grafo. Liga vertices
vert
que tenham comunicação em parale
alelo.
A Figura 10 representa
nta o grafo gerado a partir do exemplo
lo de
d arquitetura
modelada em UML-ESL
SL apresentada
a
na Figura 7 (b).
Figura 10 Grafo
G
gerado a partir do diagrama de seqüência
Cada comunicação entre
ntre dois módulos é representada porr um vértice. Na
Figura 10(b) o vértice “A
“A->B” representa a comunicação entree o módulo A e o
módulo B; o vértice “D-->E” representa a comunicação entre o m
módulo D e o
module E, respectivamen
ente.
As comunicações entre
tre o módulo A e o módulo C e a comu
municação entre
módulo A com o módulo
ulo B são definidas como comunicações em paralelo, logo
as duas comunicaçõess não
n
podem compartilhar a mesma cone
onexão, devido à
27
possibilidade de conte
ntenção no recurso compartilhado. Esta
Est restrição é
representada pela aresta
sta que liga os dois vértices “A->B” e “A->C”
>C”.
Para determinar como
o os
o módulos serão conectados é utilizado
do um algoritmo
de coloração de grafoss [17],
[17 onde o seu resultado é interpretado
o como:
co
1. Vértices (que repre
epresentam a comunicação entre dois módu
dulos) de mesma
cor representam as conexões que serão ligadas a um mesm
esmo barramento,
permitindo o comp
ompartilhamento da comunicação.
2. Vértices com uma
ma cor única representam conexões que serão
serã feitas ponto
a ponto, ou seja, com
co uma conexão exclusiva entre os dois
is módulos.
m
Com o objetivo de tentar
tar diminuir o número de cores utilizadoss na
n coloração do
grafo
(e
conseqüentem
ntemente
prover
um
maior
comparti
artilhamento
da
comunicação) foi utilizad
izada uma heurística para diminuir o número
núm
de cores
utilizadas, onde antess de
d se criar uma nova cor tenta-se utiliz
tilizar de uma já
existente. A Figura 11 mostra
m
o algoritmo de coloração sendo
o aplicado
a
a um
grafo com quatro vértices
ices.
Figura 11 Exemplo do algoritmo de coloração de grafo.
28
O grafo do exemplo é composto por quatro vértices (A, B, C e D) onde
inicialmente eles são descoloridos, ou seja, coloridos com a cor (zero), Figura 11
(a). Em seguida escolhe-se o vértice A como o primeiro a ser colorido, como não
existe nenhuma cor criada ainda, cria-se a cor 1 e aplica-se ao vértice, Figura 11
(b). O próximo vértice a ser colorido é o B, nota-se que não é possível utilizar a
cor 1, já que ele possui um vértice adjacente com essa cor, então cria-se a cor 2 e
colore-se o vértice B com ela, Figura 11 (c). O vértice C é próximo a ser colorido,
nele não é possível utilizar a cor 1 nem a cor 2, devido aos vértices adjacentes A
e C respectivamente, logo uma terceira cor é criada e aplicada ao vértice C,
Figura 11 (d). Por fim aplica-se a cor 1 ao vértice D, já que ele não possui a
restrição para utilizar esta cor, Figura 11 (e).
O algoritmo possui três passos que são descritos a seguir:
1. Inicialização: todos os vértices que formam o grafo são marcados como
sem cor.
2. Escolhe-se um vértice e o colore com a primeira cor.
3. Todos os vértices do grafo são visitados verificando se algum dos seus
nós adjacentes já possui a cor com que se deseja colorir o vértice atual. Se
sim, tenta-se utilizar outra cor que já foi utilizada no grafo, caso não seja
possível cria-se uma nova cor e o vértice é colorido com ela.
No exemplo apresentado na Figura 10 o grafo colorido e a arquitetura de
interconexão gerada são mostrados na Figura 12.
29
Figura 12 Arquitetura
Ar
gerada a partir da coloração do grafo
afo
A arquitetura de interco
rconexão gerada possui uma conexão excl
xclusiva entre os
módulos A e C enquant
anto possui um barramento para a comun
unicação entre o
resto dos módulos. A conexão
con
ponto a ponto permite que o módu
ódulo A acesse os
serviços dos módulos C e D sem gerar o problema de contenção
ção, já que agora
existem duas conexões
es para o modulo A acessar os módulos
los C e D, uma
conexão para cada modu
dulo.
Apesar do baixo custo
to computacional,
c
a heurística utilizada no algoritmo de
coloração não apresenta
nta uma solução ótima, o problema de encontrar um
número mínimo de cores
res que colorem um grafo é NP-Completo
to [16].
[1
3.4.
GERAÇÃO
ÃO DA PLATAFORMA VIRTUAL
Após a coloração do grafo
gra obtêm se a arquitetura de intercone
onexão necessária
para a geração da
a plataforma
p
virtual (implementada em
e
SystemC).
Considerando a arquitet
itetura de interconexão obtida a partir do grafo colorido
juntamente com as infor
formações sobre os módulos descritas no
o arquivo
a
SLIF e
da biblioteca de templat
plates, a plataforma virtual que implemen
enta o sistema é
gerada.
O código fonte gerado
do da plataforma virtual é dividido em três grupos:
módulos, comunicação
ão e auxiliar. Antes da geração de código
có
toda a
30
informação obtida sobre os módulos e a comunicação do sistema precisa ser
organizada, como mostrado na Figura 13.
Figura 13 Fluxo de geração de código
A partir do grafo colorido as arestas são organizadas de acordo com sua cor,
que representam a comunicação que será utilizada. Em seguida cria-se uma
lista com informações sobre todos os serviços, incluindo quem os solicitam e
quem os oferecem. É neste ponto também que os serviços recebem uma
identificação única que é utilizada durante a transmissão pelo barramento. Por
fim os endereços dos módulos que utilizam barramento são gerados.
O código é gerado em três fases, primeiro os módulos, em seguida a
comunicação e por fim os outros arquivos auxiliares, como arquivos de
definições. A informação sobre um módulo específico é organizada e
armazenada em uma estrutura de dados baseada em objetos que é utilizada
juntamente com os templates para produzir o código fonte.
31
Na geração dos módulos são utilizadas informações do grafo colorido e do
SLIF, com isso são gerados três arquivos fonte que juntos representam um
módulo, como explicado posteriormente. Enquanto a geração da comunicação
só precisa da informação do grafo e dos endereços dos módulos.
Os arquivos são gerados seguindo uma nomenclatura padrão, com isso evitamse erros de compilação e de bind (ligação entre os módulos), além de tornar o
código gerado mais legível.
A arquitetura dos elementos gerados para a plataforma é apresentada a seguir.
3.4.1.
ARQUITETURA DO MÓDULO
Um módulo de hardware é representado na plataforma gerada como a junção
de três submódulos: behaviour, service e interface, onde cada um é responsável
por parte do funcionamento do módulo inteiro. A Figura 14 mostra como os
submódulos se relacionam.
Figura 14 O módulo é composto por três elementos
O submódulo Service possui a implementação dos serviços oferecidos pelo
módulo, é onde estão as funcionalidades oferecidas aos outros módulos que se
comunicam com ele. Esses serviços são definidos no diagrama de classes do
UML-ESL
e
posteriormente
representados
no
SLIF
no
elemento
32
SystemArchitecture->Module->Services. Um serviço é mapeado em uma função
que pode possuir parâmetros e valores de retorno. A requisição de um serviço é
feita através da interface de comunicação do canal, que recebe as requisições
vindas de outros módulos.
O submódulo Interface fornece ao módulo um meio de comunicação com os
outros módulos por meio de funções, ele possui uma lista de serviços que são
oferecidos por outros módulos (desde que haja conexão entre o módulo que
requisita o serviço e o módulo requisitado). As funções podem possuir
parâmetros e valor retorno ou não, tudo depende do tipo do serviço requisitado
(caso o serviço fosse uma adição, por exemplo, os parâmetros poderiam ser as
parcelas e o retorno o resultado da soma). O submódulo interface implementa
as funções que podem ser chamadas a partir do submódulo behavior, que
utilizam serviços de outros módulos. Dentro da função de acesso a outros
módulos a informação é quebrada em pacotes e são transmitidos para a
interface de comunicação do canal, que se encarrega de transmitir a mensagem.
No submódulo behavior o desenvolvedor irá descrever o comportamento do
módulo. É neste módulo que ocorrem as requisições de serviços de outros
módulos. Estes serviços são requisitados através da interface por meio de
chamadas de funções, sem a necessidade da manipulação de sinais de
comunicação. A Figura 15 mostra como o módulo se relaciona com a interface
de comunicação.
33
Figura 15 do módulo com a interface e comunicação.
As setas 1a e 2a representam o submódulo behavior solicitando o serviço
“serviceE”, do módulo E. O submódulo behavior chama a função
request_serviceE() (1a) do submódulo interface, que adiciona informações sobre
a requisição e envia requisição a interface de comunicação (2a). No caso do
módulo responder a uma solicitação de serviço, primeiro a interface do módulo
é ativada pela interface de comunicação (1b) que verifica o pacote, e se tudo
estiver correto, executa o serviço chamando a função do submódulo service
(serviceD()) (2b). Em ambos os casos há um retorno da requisição, mesmo
quando há erro é enviada uma informação indicando que a solicitação não foi
executada.
3.4.2.
ARQUITETURA DE COMUNICAÇÃO
COMUNICAÇÃO
A comunicação entre os módulos pode ser feita de duas maneiras diferentes,
usando conexão ponto a ponto e através de barramentos. A escolha pelo tipo de
comunicação é feita levando-se em conta os acessos paralelos. Para a conexão
ponto a ponto são definidas duas interfaces (p2p_interface) enquanto que para
a comunicação através de barramento são definidos duas interfaces
(bus_interface) e um barramento (bus_core).
34
Ambas as interfaces de comunicação, p2p_interface e bus_interface, tem como
principal objetivo receber as requisições dos módulos (chamadas de função) e
implementá-las usando o barramento, considerando sinais e protocolo. Se um
sinal for maior que a largura do barramento de dados ele é quebrado em
pacotes menores, que podem ser enviados pelo barramento, quando estes
pacotes chegam à interface destino eles são recuperados. Nos casos em que há a
quebra do pacote em pedaços menores, o tamanho do pacote também é
modificado para que ele possa ser corretamente interpretado pela interface de
destino.
Quando a conexão é ponto a ponto são utilizados um número menor de sinais
na interface, pois não existe a necessidade de um endereço. No caso da conexão
ser feita por meio de um barramento a interface do barramento é responsável
por resolver o endereço do módulo que possui o serviço requisitado.
Ainda se tratando de conexão através de barramento, as interfaces são
conectadas a um barramento, o bus_core. O bus_core simplesmente transmite
os dados recebidos para o endereço solicitado na transação. Os sinais e
protocolos desta conexão são explicados com mais detalhes posteriormente.
Para um melhor entendimento, a Figura 16 mostra a ligação entre as interfaces
de conexão, utilizando o barramento e a ligação ponto a ponto.
Figura 16 Interfaces de interconexão.
35
A comunicação entre os módulos ocorre a partir de chamadas de funções
vindas do submódulo Interface do módulo, que acessam a interface de conexão,
onde as informações são transmitidas por meio de sinais. As funções possuem
os tipos de dados dos parâmetros e retorno de tamanhos bem definidos (char,
int e long), onde são enviados pela interface, que pode ser p2p (ponto a ponto)
ou bus (barramento). Na conexão ponto a ponto os dados são transmitidos
diretamente entre as interfaces, enquanto que no uso da interface bus existe um
barramento entre as interfaces que é o responsável por transmitir o pacote ao
módulo desejado.
3.4.3.
PROTOCOLO DE INTERCONEXÃO
O protocolo utilizado para a comunicação entre os módulos foi baseado no
protocolo Avalon, onde as informações são transmitidas por meio de sinais,
onde nas comunicações ponto a ponto existe um número inferior de sinais,
devido ao fato de não ser preciso utilizar um canal para determinar o endereço
do módulo destino. A interface do protocolo de interconexão é apresentada na
Tabela 3.
Tabela 3. Tipo e tamanho das portas do barramento
Sinal
Entrada / Saída
Tipo / Tamanho
P2p
Bus
Clk
entrada
boolean / 1 bit
X
X
Writein
entrada
boolean / 1 bit
X
X
Writeout
saída
boolean / 1 bit
X
X
Address
saída
sc_uint / 8 bits
entrada
sc_uint / 8, 16
Datain
X
X
X
X
X
ou 32 bits
dataout
saída
sc_uint / 8, 16
ou 32 bits
bus_stat
busy
entrada
boolean / 1 bit
X
X
saída
boolean / 1 bit
X
X
36
Os sinais clk, writein e writeout são responsáveis, respectivamente, por receber
o sinal de clock, receber uma requisição de escrita e enviar um pacote. O sinal
address contém o endereço do módulo que se deseja enviar o pacote. Os sinais
datain e dataout são as portas por onde o dado é enviado, o sinal bus_stat
indica se o barramento está ocupado ou não, e sinal busy indica o status do
módulo.
O protocolo utilizado para a comunicação entre os módulos é apresentado na
Figura 17, onde é mostrada como é a transmissão de um pacote entre dois
módulos utilizando um barramento.
Figura 17 Transmissão de uma requisição pelo barramento
Os pacotes são enviados pelo barramento seguindo um protocolo simples de
comunicação que utiliza o sinal de controle stat. Este sinal representa o status
da interface, quando stat = true indica que a interface está ocupada, e stat = false
indica que a interface se encontra livre. A Figura 17 ilustra a transmissão
através de um barramento, por isso a necessidade do sinal address e o sinal de
status se chamar bus_stat.
No inicio de uma transmissão o módulo requerente espera que o barramento
esteja livre (bus_stat = false) e então começa a enviar a informação escrevendo
nas portas dataout, address e writeout. Nos próximos ciclos de clock o restante
do dado é enviado e a porta writeout é desativada. Ao receber a requisição de
37
transmissão a interface
ace de comunicação muda seu statuss para
p
ocupado
(bus_stat = true). Quand
ando o sinal de ocupado da interface de comunicação
muda para livre (bus_sta
_stat = false) o módulo que solicitou o serv
erviço pode ler a
informação da interface.
Os dados são transmitido
tidos pelo barramento no formato de pacote
cotes, que podem
ser de dois tipos: pacot
cotes de retorno e pacotes de requisição.
ção. O pacote de
requisição é composto
o por
p três campos: tamanho, comando e parâmetros.
p
O
campo tamanho indica o tamanho dos dados a serem transmit
mitidos, isto é, a
soma dos tamanhos doss campos comando e parâmetro. No cam
ampo comando é
informado o código do
d serviço solicitado e no campo parâmetro
p
são
armazenados os parâmet
metros do serviço requisitado. O pacote de retorno possui
apenas dois campos, o tamanho
ta
e a informação de retorno. A Figura
Fig
18 mostra
o formato dos pacotes de requisição e de retorno.
Fig
Figura
18 Pacotes de requisição e retorno
Os pacotes de requisição
ção e retorno têm tamanho definido pelo primeiro
pr
campo:
TAMANHO, que indic
ndica a quantidade de dados (campo
pos) que serão
transmitidos.
O tamanho do campo
o de
d um pacote tem o mesmo tamanho
ho da largura do
barramento de dados,, isto
ist é feito para que um campo possa ser transmitido a
cada ciclo. Se um dado
o precisa
p
ser transmitido pelo barramento
nto e ele possui o
tamanho maior que o campo do pacote ele é quebrado em vários blocos
menores que podem ser
se transmitidos pelo barramento e é recomposto
r
no
modulo destino da requis
quisição.
38
A manipulação de dado
dos para que possa ser enviado pelo barr
arramento é feita
pelas interfaces de comun
unicação dos módulos de origem e destino
tino da solicitação
do serviço. A interfacee d
de comunicação de origem quebra os dados
da
em blocos
menores, e a interfacee destino
d
recompõe o dado original a partir
par dos blocos
menores. As informaçõe
ções sobre o tamanho dos parâmetross é associada ao
serviço solicitado, logo, quando
q
a interface de comunicação no
o destino
de
recebe o
pacote que indica qual
al o comando solicitado ela sabe que tiposs de dados irão
ser recebidos, pois corres
rrespondem aos parâmetros do serviço solic
olicitado, e assim
consegue recuperar infor
formação.
Tomando como exemp
mplo um serviço que possua a seguin
uinte assinatura:
service(char a, unsigned
ned b), na Figura 19 é mostrado como
o o pacote que
requisita este serviço
o é transmitido por três barramentos
os de tamanhos
diferentes.
Figura 19 Pacotess d
de requisição para barramentos de tamanhos diferentes
dife
O tamanho do pacote
te pode
p
variar dependendo do serviço solicitado
so
ou da
largura do barramento.
o. P
Para a solicitação de um mesmo serviço,
ço, mostrados nas
figuras acima, os taman
anhos do pacote variam de acordo com
om a largura do
barramento.
39
3.5.
TEMPLATES
A geração de código faz uso de templates. Templates são modelos sem
conteúdo, com instruções sobre onde e qual tipo de conteúdo deve entrar em
cada parcela do arquivo. Ou seja, os templates são modelos de arquivos que
possuem campos variáveis que podem ser modificados por informações
passadas como parâmetros, como, por exemplo, o tipo de um dado.
Para este trabalho foram definidos oito templates descritos na linguagem
SystemC. Cada template corresponde a um dos elementos apresentados nas
seções anteriores. A Tabela 4 mostra os templates e os módulos eles geram,
respectivamente.
Tabela 4 Templates de geração de código
Template
jetmodulebehavior.hjet
Grupo
Modulo Gerado
Módulo
module_behavior
jetmoduleinterface.hjet
module_interface
jetmoduleservices.hjet
module_services
jetbusnncore.hjet
Comunicação
bus_core
jetbusinterface.hjet
bus_interface
jetp2pinterface.hjet
module_interface
jetdefinitions.hjet
jet00_top.cppjet
Auxiliar
definitions
top
Durante a geração dos módulos o nome dos arquivos gerados vai depender de
que nomes foram utilizados na modelagem do sistema. No caso dos módulos os
arquivos gerados terão nome da classe que define o módulo seguido do sinal
“_” e o nome do seu tipo (behavior, interface ou services).
Nas interfaces, os nomes variam dependendo do tipo de comunicação. No caso
do barramento o nome da interface de comunicação terá o prefixo “bus” depois
sua identificação seguida do nome do módulo que utiliza aquela interface em
seguida a palavra “_interface”, enquanto no barramento terá o sufixo “_core”.
40
No caso da interface ser ponto a ponto, são geradas duas interfaces com a
formação do nome obedecendo a seguinte ordem: prefixo “p2p_” , mais o nome
do primeiro modulo, nome do segundo módulo e por fim o sufixo “_interface”.;
a segunda interface obedece as mesmas regras só que com os nomes dos
módulos trocados.
Por fim os dois últimos módulos possuem nomes fixos que são o definitions e o
00_top. O nome 00_top foi criado para que o arquivo seja fácil da achar quando
se gera muitos arquivos.
3.6.
IMPLEMENTAÇÃO
A ferramenta de geração de código foi implementada utilizando-se a linguagem
Java. O trabalho foi dividido em três fases: parser SLIF, grafos e geração de
código.
O parser foi criado para recuperar e organizar as informações de modelagens
armazenadas no arquivo de formato SLIF, de forma que a ferramenta
implementada possa interpretar seus dados. Para recuperar as informações do
arquivo SLIF foi utilizada a biblioteca SAX (Simple API for XML), que possui
métodos que entendem a estrutura do XML e retornam estruturas que podem
ser entendidas pela linguagem Java. A partir destas estruturas foram criadas
classes que armazenam as informações dos módulos e conexões. O
mapeamento das informações dos módulos e conexões para classes Java é
mostrado na Tabela 5 abaixo.
Tabela 5. Mapeamento das informações SLIF para classes.
Tags no SLIF
System Architecture
Classe
SlifModule
Service
SlifServices
Atributos que possuí
String name
String type
Vector<String> usedModules
Vector<SlifService> services
String name
41
Data (entry)
SlifEntry
Transactional Ordering
SlifNode
Vector<SlifEntry> entries
String resultType
String sourceCode
String name
String dataType
String service
String caller
String callee
String type
String igGroup
Todas as informações são mapeadas para dados do tipo String, e quando uma
classe possui mais de um atributo do mesmo tipo (como services, por exemplo)
a informação é armazenada em vetores (listas), que são representadas pela
notação em Java “Vector<tipo>”.
A classe SlifModule armazena informações sobre o módulo definidas no
diagrama de classes, as informações incluem o nome, o tipo (se hardware ou
software), os módulos usados e os serviços disponibilizados. Para representar
os serviços foi definida a classe SlifService, que possui o nome do serviço uma
lista de parâmetros de entrada (classe SlifEntry), o tipo do resultado é o código
fonte.
A última classe definida para armazenar as informações do SLIF é a SlifNode,
que contém informações sobre como e quando ocorrem as transações entre os
módulos. Esta é classe de onde são extraídas as informações para a criação do
grafo.
O grafo é implementado em uma classe Java definida como GraphGraph, que
possui uma lista de elementos GraphVertex, que representam os vértices do
grafo. A estrutura dessas Classes é apresentada na Tabela 6.
Tabela 6. Classes que representam o grafo
GraphGraph
GraphVertex
Integer usedColors
Vector<GraphVertex>
Integer color
SlifNode slifNode
42
Vector<SlifNode> adjacentNodes
A classe GraphGraph possui dois atributos, o primeiro (usedColors) representa
o número de cores que foram utilizados para colorir o grafo, e a lista de vértices
(Vector<GraphVertex>) representa o grafo. A classe GraphVertex possui um
atributo color, que representa a cor do vértice, SlifNode, que representa é a
identificação do vértice e representa as ligações entre os módulos e uma lista de
vértices adjacentes (adjacentNodes).
A geração de código foi feita utilizando-se templates. Os templates podem ser
definidos como informações estruturais sobre o código fonte que se deseja
gerar, tendo alguns elementos de sua construção variáveis. O formato dos
templates segue o modelo JET (Java Emitter Template), que é uma ferramenta
de geração de código do Eclipse [20], e foram definidos para gerar código
SystemC.
Para a geração do código fonte foram encontradas duas soluções, ambas
utilizando ferramentas do eclipse, o JET e o JMerge. A escolha pelo JET para a
geração do código foi devido à sintaxe do template ser mais simples e devido à
maior disponibilidade de documentação.
Para a geração da plataforma de simulação em SystemC foram definidos oito
templates que são mostrados na Tabela 7.
Tabela 7. Templates implementados no trabalho
Template
jetmodulebehavior.hjet
jetmoduleinterface.hjet
jetmoduleservices.hjet
jetbusnncore.hjet
jetbusinterface.hjet
jetp2pinterface.hjet
jetdefinitions.hjet
jet00_top.cppjet
Tipo
modulo
Descrição
Templates para a geração
dos módulos.
comunicação
Templates que geram os
canais de comunicação.
geral
Templates necessários para a
organização do código.
43
Os templates apresentados geram o código fonte de todo o sistema. Eles podem
ser divididos em três grupos: código de módulos, código de conexão e código
geral.
O grupo módulo possui os templates para a geração do código do módulo de
hardware, que por sua vez é tasmbém composto por três sub-módulos:
bahavior, interface (do módulo) e services. O grupo comunicação possui os
templates referentes à geração do código de toda a comunicação que ocorre
entre os módulos e também são três: bus, responsável pelo código do
barramento; p2p, para ligações ponto a ponto; e interface, que se comunica com
a interface do módulo.
Por fim o grupo geral possui os templates para a geração do código fonte dos
arquivos completam o sistema. Que são o arquivo de definições e o arquivo top.
O arquivo de definições contém informações sobre os endereços dos módulos,
os códigos dos serviços, o tamanho dos tipos de dados em bytes e algumas
definições de estruturas utilizadas pelo sistema. O arquivo top além de conectar
os elementos da plataforma contém a função main, que inicializa a plataforma.
Como resultado da implementação foram implementadas 34 classes Java, sem
contar os templates. Com o número total de 4374 linhas de código.
44
4. RESULTADOS
Neste capitulo são apresentados alguns dos resultados obtidos com o uso da
abordagem apresentada neste trabalho. Para isso primeiro se explicará o
funcionamento de um USB Host, que foi usado como caso de uso, e em seguida
serão mostrados alguns números referentes a simulações com diferentes tipos
de conexões.
4.1.
ESTUDO DE CASO – USB HOST
Para validação da abordagem proposta, a implementação de alguns módulos de
um controlador USB Host foi considerada como estudo de caso.
A USB, Universal Serial Bus, é uma especificação para a comunicação entre
dispositivos e um controlador. Basicamente ela é uma porta serial de alta
velocidade utilizada para a transmissão de dados entre dispositivos eletrônicos.
Um sistema USB é composto por dois elementos, o USB host e o device. O USB
host é o elemento responsável por gerenciar as transferências de dados que
ocorrem utilizando o protocolo USB e por funcionar como uma interface entre o
sistema operacional e o dispositivo (o USB host é geralmente encontrado em
PCs). O dispositivo é o módulo que se conecta ao USB host para a troca de
informações, como por exemplo, um pen-drive ou webcam.
No papel de interface entre o sistema operacional e o dispositivo, o USB Host
utiliza uma região de memória compartilhada e um banco de registradores para
transmitir informações. Para este estudo de caso focaremos na comunicação dos
módulos internos do USB host e o banco de registradores que serve de interface
para comunicação com o sistema.
A Figura 20 mostra um esquema simplificado dos módulos que compõem o
USB Host.
45
Figur
gura 20 Esquema simplificado do USB Host
A figura acima represen
senta a arquitetura simplificada de um controlador
con
USB
Host. Os módulos Root
ot Hub
H e Avalon Slave fazem a comunicação
ção com o device
e o sistema operacional,
al, respectivamente. Os outros módulos cuidam
cui
do status
interno do sistema, com
omo interrupções (Interrupt Trigger), estad
stado do sistema
(States Control) e contro
ntrole da transmissão dos dados (Execute
ute Transaction e
Frame Management).
). Todos
T
os módulos acessam os registradores
reg
do
Operational Registers,, qu
que contém informações sobre o sistema.
O estudo de caso é focado
fo
nas comunicações entre alguns módulos que
compõem o USB Host,
st, mais precisamente nas comunicaçõess com
c
o módulo
Operational Registers.
bordagem proposta, foi modelada a parte
rte do sistema de
Para a validação da abor
um USB Host que permite
per
o driver controlar e receber informações
in
do
controlador USB Host,, e ainda alguns módulos de contro
trole interno. A
comunicação entre o controlador
con
USB Host e o driver é feita
ta a partir de um
banco de registradores,
s, que
q contém informações sobre o funciona
onamento do USB
Host e contém algunss registradores
r
operacionais que permite
ite o controle do
controlador USB Host.
O sistema possui sete módulos,
mó
sendo um deles o Operational
al Registers
R
que é
responsável pelo control
trole do módulo. Os outros são: Avalon Slave,
Sla
Root Hub,
Frame Management, States
Stat Control, Execute Transaction e Interr
terrupt Trigger. A
funcionalidade destes módulos
mó
pode ser abstraída neste estudo
do de
d caso, pois a
46
informação aqui é focada apenas na comunicação destes módulos com o
Operational Registers.
O módulo Operational Registers possui 64 registradores de 32 bits, que podem
ser acessados tanto pelos módulos internos quanto pelo driver, através do
módulo Avalon Slave (barramento avalon).
Os módulos foram especificados usando o profile UML-ESL com a ferramenta
Visual Paradigm. Da especificação UML-ESL foi extraído o formato
intermediário SLIF, que serviu como entrada para a ferramenta que implementa
a abordagem proposta. Na modelagem foram definidos os módulos
mencionados e como eles estão interconectados. Os diagramas de classe e de
seqüência do módulo USB Host são mostrados nas Figura 21 e Figura 22,
respectivamente.
Figura 21 Diagrama de classes do USB Host
O módulo Operational Registers (OR) oferece aos outros módulos os serviços
de escrita e leitura de registradores. O tipo de dado do registrador é inteiro, o
que significa que ele possui 32 bits, enquanto o endereço é do tipo char, que
possui apenas 8 bits. O retorno da função também é um dado do tipo inteiro (32
bits).
47
Figura 22 Diagrama de seqüência do USB Host
As comunicações que podem ocorrer em paralelo são: o módulo Avalon Slave
acessando o módulo Operational Register, o módulo Interrupt Ttrigger
acessando módulo Operatinal Registers e o Rott Hub acessando também o
Operational Register. As demais comunicações não podem ocorrer em paralelo.
A Tabela 8 mostra as siglas utilizadas na demonstração do grafo e da
arquitetura gerada.
Tabela 8 Siglas dos módulos USB
Nome do módulo
Avalon Slave
Execute Transaction
Frame Management
Interrupt Trigger
Root Hub
States Control
Sigla
AS
ET
FM
IT
RH
SC
As informações do arquivo SLIF que representam a modelagem UML-ESL da
Figura 21 e Figura 22 acima resulta no grafo e sua coloração mostrados na
Figura 23.
48
Figura 23 Grafos
afos gerados a partir da modelagem UML do USB
B Host
H
O grafo representa ass co
conexões entre os módulos do USB Host
ost. As conexões
“AS->OR”, “RH->OR”” e “IT->OR” são representadas na Figura
Fig
22 como
paralelas, logo os vértice
tices que as representam no grafo são unid
nidos por arestas,
que indicam restrição.. Após
A
a coloração, cada cor representa
ta um
u recurso de
conexão e os vértices que
qu possuem a mesma cor são conectados
dos a um mesmo
meio de conexão. Vértice
tices com uma única cor são conectados ponto
pon a ponto. A
Figura 24 apresenta a arquitetura
ar
de comunicação obtida para
ara a USB host a
partir da abordagem prop
roposta.
Figura 24 Arquitetura gerada pela técnina apresentada
Como resultado a plata
lataforma possui duas conexões ponto a ponto entre o
Interrupt Trigger e o Operational
O
Registers e uma entre o R
Root Hub e o
Operational Registers,, en
enquanto os demais módulos são conectad
ctados através de
um barramento.
49
Em relação ao código fonte, foram gerados 33 arquivos que compõem o sistema.
O tempo para gerar estes arquivos foi cerca de 2 segundos em um AMD Athlon
64 X2 Dual Core 5000+ 2.60 Ghz com 4GB de memória RAM. Os arquivos
gerados e o número de linhas de cada um são mostrados na Tabela 9.
Tabela 9. Arquivos gerados pela ferramenta
Arquivo
avalon_slave_services.h
avalon_slave_interface.h
avalon_slave_behavior.h
frame_management_interface.h
frame_management_behavior.h
frame_management_services.h
interrupt_trigger_services.h
interrupt_trigger_interface.h
interrupt_trigger_behavior.h
execute_transaction_services.h
execute_transaction_interface.h
execute_transaction_behavior.h
operational_registers_services.h
operational_registers_interface.h
operational_registers_behavior.h
root_hub_services.h
root_hub_interface.h
root_hub_behavior.h
states_control_services.h
states_control_interface.h
states_control_behavior.h
bus0_core.h
bus0_states_control_interface.h
bus0_operational_registers_interface.h
bus0_interrupt_trigger_interface.h
bus0_execute_transaction_interface.h
p2p_frame_management2operational_registers_interface.h
p2p_root_hub2operational_registers_interface.h
p2p_operational_registers2root_hub_interface.h
p2p_operational_registers2frame_management_interface.h
00_top.cpp
definitions.h
Grupo
modules
comunication
outros
N. de Linhas
26
41
36
41
41
26
26
37
37
26
37
36
59
30
36
26
37
36
26
37
36
1106
300
300
339
300
303
301
309
309
311
28
No total foram geradas 3502 linhas de código, sendo 733 linhas de código dos
módulos, 2430 linhas de código para estrutura de interconexão e 339 para os
outros módulos.
50
Num teste onde os módulos
mó
Frame Management e Root Hub
Hu acessam o
Operational Registers
rs foi preciso uma pequena edição
o nos arquivos
frame_management_beha
ehavior.h,
root_hub_behavior.h
or.h
e
operational_registers_ser
services.h, devido ao fato do UML-ESL guardar
gu
somente
informações temporais
is entre
e
as comunicações, e não a seqüên
üência inteira de
chamadas entre os mód
ódulos – o que define o funcionamento
to do sistema. A
Figura 25 mostra as linh
inhas adicionadas no módulo frame_manag
nagement para a
simulação do sistema.
Figura 25 Trecho de arquivo editado
anagement utiliza os serviços de escrita
ita e leitura nos
O módulo Frame Mana
registradores do Operatio
ational Registers, para isto ele utiliza as fun
funções definidas
em sua interface (frame_m
e_managementint) que se comunica com o barramento. A
função wait_sync serve
ve para
p
sincronizar o funcionamento do
o módulo
m
com os
outros que compõe a plataforma. A adição de código
igo no arquivo
root_hub_behavior.h
é
bastante
similar
as
modi
odificações
do
frame_management_beha
ehavior.h e se referem a leitura de um regis
gistrador.
No módulo Operational
nal Registers – operational_registers_servi
ervices.h – foram
adicionadas informações
ções referentes a inicialização do sistem
tema, no caso o
preenchimento do array
ay que representa os registradores. Essa adição
ad
de código
é necessária porque o SLI
LIF guarda apenas informações estruturais
rais dos módulos,
como serviços utilizados
os e oferecidos, e não informações de imple
plementação.
Após a edição dos arqu
rquivos, a plataforma pode ser compilada
da e utilizada. A
compilação e execução
o da
d plataforma, neste estudo de caso, foram
fora feitas num
51
ambiente Linux, com a compilação
co
sendo feita com o g++ utilizan
zando a biblioteca
SystemC. Na Figura 26 é mostrado um exemplo da execução dee uma
u
simulação
na plataforma gerada pela
pel ferramenta, com o estudo de caso apres
presentado.
F
Figura
26 Simulação sendo executada
Na simulação o Frame
me Management escreve e lê em um registrador
r
do
Operational Registers.. Pr
Primeiro é escrito o valor 18300 no registr
istrador 13, onde
os dados referentes a esta
est requisição são enviados por um paco
acote que contém
tamanho 6. Em data[1]
a[1]: 1 é informado qual a operação que
qu está sendo
requisitada, neste caso
o o 1 representa o serviço de escrita. Em
m data[2]: 13 é
passado o primeiro parâ
arâmetro, que se refere ao endereço do registrador,
reg
e nos
outros pacotes é enviado
do o valor a ser salvo no registrador. Note
te que o valor do
último parâmetro é divid
ividido em quatro partes para que possa
a ser
s transmitido
pelo barramento, no caso
aso 18300 foi enviado byte a byte, a saber:
r: 1124, 71, 0 e 0. O
RETRUN 1 significa que
ue não houve problema na execução do serviço.
serv
Ainda no mesmo exempl
plo mostrado na Figura 26, o Frame Manag
nagement solicita
a leitura do mesmo regis
egistrador que foi escrito. Este serviço possu
ossui apenas dois
52
campos, o data[1]: 0 que representa o serviço, e o data[2]: 13 que representa o
endereço. Novamente o RETURN indica o resultado da operação, que neste
caso, foi o valor do registrador escrito anteriormente, isto é 18300.
4.2.
EXPLORAÇÃO DO ESPAÇO DE PROJETO
A seguir é discutido o suporte da abordagem proposta para exploração do
espaço de projeto.
Como já explicado, a ferramenta apresentada transforma as conexões entre os
módulos apresentadas no modelo UML-ESL em um grafo. No grafo os vértices
representam a comunicação entre dois módulos e são conectados a outros
dependendo da informação temporal obtida no diagrama de seqüência.
Comunicações paralelas no diagrama de seqüência são mapeadas para
conexões ponto a ponto e as comunicações seqüenciais são mapeadas em
barramento. Sabendo disto é fácil utilizar a ferramenta para explorar as opções
de conexões entre os módulos, bastando para isso alterar as informações
temporais sobre as comunicações no diagrama de seqüência do modelo UMLESL.
Exemplo: se o desenvolvedor deseja verificar o comportamento do sistema
quando todas as conexões entre os módulos são ponto a ponto, basta que ele
altere o diagrama de seqüência para que todas as conexões ocorram em paralelo
(utilizando a label PAR), com essas restrições o programa irá gerar a plataforma
virtual com todas as conexões ponto a ponto. Por outro lado, se é desejo obter
uma plataforma com um único barramento que interconecte todos os módulos,
basta que o desenvolvedor no diagrama de seqüência marque todas conexões
como seqüenciais (label SEQ). A Figura 27 (a) mostra o diagrama de seqüência
do estudo de caso apresentado para que seja gerada uma plataforma com um
53
único barramento. Na Figura 27 (b) o diagrama de seqüência é modelado de
forma que seja gerada uma plataforma apenas com conexões ponto a ponto.
Figura 27 Diagramas de seqüência que geram plataformas diferentes
Na Figura 27 (a) todas as conexões são marcadas com a label seq (seqüêncial),
enquanto na Figura 27 (b) todas as conexões estão sob a label par (paralelo).
Utilizando os diagramas de seqüência apresentados na Figura 27 foram obtidas
mais duas arquiteturas para o USB Host, uma utilizando um único barramento
para a comunicação e outra conectando os módulos ao Operational Registers
por conexões ponto a ponto, como mostrado na Figura 28.
54
Figura 28
2 Diferentes arquiteturas para o USB Host.
Arquiteturas de comunic
nicação obtidas a partir das modelagenss apresentadas
ap
na
Figura 28. Em (a) a arquitetura
ar
gerada pela Figura 28 (b), onde
o
todas as
conexões acontecem através
atra
de um barramento, em (b) a arqu
rquitetura gerada
pela Figura 28 (a) com todas
tod as conexões ponto a ponto.
Antes da execução da ferramenta,
fer
que irá gerar a plataforma é po
possível escolher
entre três larguras de barramento
ba
(8, 16 ou 32 bits) para a plata
lataforma gerada.
Isto é feito por meio de parâmetro,
p
passado por linha de comand
ando. Com isso é
possível avaliar o comp
omportamento do sistema com diferente
ntes larguras de
barramento.
Juntando a plataforma
a apresentada
a
no capítulo 4.1 e às duas
as mostradas na
Figura 28 foram feitas
as simulações e seus resultados foram comparados.
co
A
plataforma virtual simula
ula a escrita de três módulos (Frame Man
anagement, Root
Hub e Avalon Slave)) num quarto (Operational Registers
ers) em tempos
predeterminados. Foram
ram encontrados os tempos de simulação
ão mostrados na
Tabela 10.
Tabela 10. Resultados
R
das simulações em ciclos de máquina
ina
8 bits
16 bits
32 bits
Somente ponto a ponto
416
336
296
Um único barramento
1103
856
736
Abordagem proposta
476
396
356
55
Na comparação entre as simulações das plataformas em 8 bits as conexões
ponto a ponto foram mais rápidas levando 416 ciclos de máquina enquanto na
abordagem com um único barramento a mesma simulação demorou 1103 ciclos.
Na abordagem proposta, que usa conexões ponto a ponto e barramento, o
tempo de simulação foi de 476 ciclos, ou seja, 14% de ciclos a mais que a
plataforma apenas com conexões ponto a ponto, que obteve o melhor resultado.
Essa diferença se dá devido ao tempo gasto para o barramento resolver o
endereço destino do pacote sendo enviado e por transmitir esse pacote, que
passa pelo barramento, o que não acontece nas conexões ponto a ponto.
Levando–se em consideração todas as simulações obtivemos o melhor resultado
com as conexões ponto a ponto, em seguida tivemos a plataforma gerada com a
ferramenta utilizada que rodou a simulação com 17% a mais de ciclos, e por fim
com o pior resultado tivemos a plataforma somente com um barramento que
levou a média de 157% a mais de ciclos para rodar a mesma simulação, em
relação às conexões ponto a ponto e 119% a mais de ciclos em relação à
abordagem proposta.
A vantagem da plataforma gerada pela ferramenta desenvolvida em relação a
plataforma gerada apenas com conexões ponto a aponto é um maior
compartilhamento da estrutura de comunicação, o que diminui o esforço no
roteamento dos sinais na etapa de desenvolvimento do circuito, e permite uma
menor área do chip.
56
5. CONCLUSÃO
Neste trabalho foi apresentada uma técnica para geração da arquitetura de
comunicação de um sistema descrito em UML-ESL. Além da otimização de
interconexão a técnica proposta permite a geração automática da plataforma
virtual.
A geração automática da plataforma virtual código apresentada neste trabalho
permite ao desenvolvedor obter de uma maneira mais rápida um ambiente
funcional, onde várias implementações do sistema possam ser testadas e
validadas. O algoritmo de otimização da estrutura de interconexão gera uma
arquitetura de comunicação que foca no compartilhamento de interconexão
entre os módulos o canal de comunicação levando em consideração o
paralelismo das comunicações que podem ocorrem durante a execução do
sistema.
A descrição do sistema é feita em um alto nível de abstração utilizando-se
UML-ESL, onde o desenvolvedor pode abstrair quase toda a informação sobre
detalhes da comunicação entre módulos, deixando esta tarefa para a técnica
proposta de geração de estrutura de conexão. Porém, se for necessário, é
possível que desenvolvedor escolher a largura do barramento de dados por
meio de parâmetro passado na hora da geração de código.
Para simular a plataforma basta ao desenvolvedor descrever o comportamento
dos módulos em seus arquivos de comportamento e para acessar serviços de
outros módulos basta utilizar chamadas de funções, sem se preocupar como a
comunicação entre módulos será implementada.
A alta velocidade com que as plataformas são geradas permite a exploração de
novas arquiteturas de comunicação entre os módulos sem causar muito impacto
no tempo de desenvolvimento do projeto. A exploração da arquitetura permite
57
ao desenvolvedor encontrar uma melhor arquitetura que se adéqüe aos
requisitos do projeto.
5.1.
TRABALHOS FUTUROS
Visando a continuidade do desenvolvimento do SoC serão feitas modificações
na plataforma base do trabalho proposto para que a arquitetura de
comunicação possa ser sintetizável.
Quanto à comunicação dos módulos, serão adicionados mais protocolos para
que o desenvolvedor possa ter uma maior gama de opções, e assim escolher um
protocolo que se assemelhe mais a arquitetura que se deseja simular. Além
disso, serão feitas mais algumas otimizações nas interconexões em relação ao
tamanho do barramento de endereço.
O uso de templates neste trabalho permitiu o desenvolvimento rápido de uma
ferramenta que gerasse código SystemC, o próximo passo neste sentido será
gerar templates para a geração de código Verilog e/ou VHDL.
Por fim haverá um esforço no sentido de integrar a técnica descrita neste
trabalho a ferramenta de modelagem de SoCs PDesigner [18].
58
BIBLIOGRAFIA
[1] iNEMI (International Electronics Manufacturing Initiative). Highlights Executive Summary - 2009 iNEMI Roadmap.
[2] ZHENXIN, Sun e WENG-FAI, Wong. (2009). An UML-based approach for
heterogeneous IP integration. In Proc. Of Asia and South Pacific Design
Automation Conference.
[3] AZIZ, A. An UML-Driven Generation Approach for SoC Design with
Synthetizable SystemC Code Generation. IP-SOC. 2008.
[4] ALMEIDA, M. Síntese de comunicação de sistemas modelados a nível de
serviços para plataformas baseadas em barramento. Recife: Centro de
Informática, UFPE, 2010.
[5] RUMBAUGH, J. et al. Object-Oriented Modeling and Design. Prentice Hall,
1990.
[6] BOOCH, G. Object-oriented Analysis and Design with Applications.
Redwood City: Benjsmin Cummings, 1993.
[7] JACOBSON, I. Object-oriented Software Engineering: A Use Case Driven
Approach. Addison-Wesley Professional, 1992.
[8] OCP International Partnership. Open Core Protocol Intellectual Property
(OCP-IP).
Disponivel
em:
http://www.ocpip.org/welcome_to_ocpip.php.
Ultimo acesso em: 12 de Abril de 2010.
[10] LIMA, Marília. ipProcess: Um Processo de Desenvolvimento de Módulos
de Propriedade Intelectual com Implementação em FPGA´s. Recife : Centro de
Informática, UFPE, 2005.
59
[11] LENNARD, C. Et al. Industrially proving the SPIRIT consortium
specifications for design chain integration. In Proc. of the conference on Design,
automation and test in Europe DATE '06, Munich, Germany, 2006.
[12] SINGH, A; PARTHASARATHY, G; MAREK-SADOWSKA, M. Efficient
circuit clustering for area and power reduction in FPGAs. ACM Trans. Design
Automation of Electronic Systems, vol. 7, no. 4, pp. 643–663. 2002.
[13] KUSSE, E.; RABAEY, J. Low-energy embedded FPGA structures. In Proc.
of the 1998 International Symposium on Low Power Electronics and Design
(ISLPED’98), New York, pp. 155–160. 1998.
[14] BAILAY, B; MARTIN, G; PIZIALI, A. ESL Design and Verification: A
Prescription for Electronic System Level Methodology. Morgan Kaufmann.
2007.
[15] GOGNIAT, G.; AUGUIN, M.; BIANCO, L.; PEGATOQUET, A.
Communication Synthesis and hw/sw Integration for Embedded System
Design. In Proc. of International Conference on Hardware Software Co-Design.
Seattle, Washington. 1998.
[16] JAEGER, F.; VERTIGAN, D. L.; WELSH, D. J. A. On the computational
complexity of the Jones and Tutte polynomials. Mathematical Proceedings of
the Cambridge Philosophical Society. 1990.
[17] MICHELI, G. Synthesis and optimization of digital circuits. Hightstown:
Mcgraw-hill Inc, 1994. ALGORITHM 2.4.6.
[18] PDesigner. Disponível em: http://www.pdesigner.org. Último acesso: 09 de
Junho de 2010.
60
[19]
UML
Profile
for
SoC,
OMG.
Disponível
http://www.omg.org/technology/documents/formal/profile_soc.htm.
em
Último
acesso em 03 de Julho de 2010.
[20] The Institute of Electrical and Electronics Engineers, Inc. IEEE Standard
VHDL Language Reference Manual. 2000.
[21] The Institute of Electrical and Electronics Engineers, Inc. IEEE Standard
Verilog® Hardware Description Language. Revision of IEEE Std 1364-1995.
2005.
[22] The Institute of Electrical and Electronics Engineers, Inc. IEEE Standard
SystemC® Language Reference Manual. 2006.
[23] DECALUWE, J. MyHDL Manual. Release 0.7. 2010.
[24] Rossum, G. Introduction to Python. Disponível em:
http://www.python.org/doc/essays/ppt/lwnyc2002/intro22.pdf. Último acesso
em: 24/01/2011.
[25] Object Modeling Group. OMG Unified Modeling LanguageTM (OMG
UML), Infrastructure. Version 2.3. 2010.
61