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