Executáveis para o Projeto de Módulos para Sistemas em Chips

Transcrição

1 Geração de Especificações Executáveis para o Projeto de Módulos para Sistemas em Chips Rafael Nunes Linhares Papa Belo Horizonte 2006

2 Rafael Nunes Linhares Papa Geração de Especificações Executáveis para o Projeto de Módulos para Sistemas em Chips Dissertação apresentada ao Curso de Mestrado do Programa de Pós-Graduação em Engenharia Elétrica da Universidade Federal de Minas Gerais, como requisito parcial à obtenção do título de Mestre em Engenharia Elétrica. Área de Concentração: Engenharia de Computação e Telecomunicações Linha de Pesquisa: Sistemas de Computação Orientador: Prof. Dr. Diógenes C. da Silva Jr. Universidade Federal de Minas Gerais Belo Horizonte 2006

3 Dedicatória À minha mãe Sandra e à minha amada namorada Érica

4 Agradecimentos Primeiramente a toda minha família e em todos aqueles que acreditaram em mim, em especial ao meu irmão Daniel Nunes e à minha avó Jutay. Aos professores e funcionários do PPGEE (CPDEE/UFMG), bem como aos colegas do LABSCI (Laboratorio de Sistemas Computacionais Integrados) Ramon, Alair, Adriano e Sandro. Ao colega Breno Rocha de Almeida pelos comentários, críticas e sugestões que ajudaram enriquecer este trabalho. Ao CNPq e ao Projeto BRAZILIP pelo suporte financeiro. Um agradecimento mais do que especial ao meu orientador, Professor Diógenes C. da Silva Jr., por sua dedicação e competência fundamentais na concretização deste trabalho.

5 O mar não é um obstáculo: é um caminho Amyr Klink

6 Resumo A crescente demanda por componentes eletrônicos esta fazendo com que o mercado destinado a circuitos integrados cresça a uma velocidade alarmante. Chegou-se a tal ponto que, em no máximo dois ou quatro anos, será possível encontrar circuitos compostos por até um bilhão de transistores. Essa capacidade de integração é a responsável pelo surgimento de um novo conceito, o de Sistema on chip (SoC ), no qual um sistema computacional completo é abrigado dentro de um único circuito integrado. A alta complexidade no processo de integração e interconexão dos módulos que compõem um SoC, chamados de propriedade intelectual (IP - Intellectual Property), faz com que os fabricantes desses componentes invistam cada vez mais nos setores destinados à produção e ao desenvolvimento de novas tecnologias de projeto. O tempo desperdiçado durante o processo de desenvolvimento do projeto de SoC também é um dos fatores que contribuem para que novas metodologias de desenvolvimento de projeto sejam continuamente propostas. Este trabalho apresenta a proposta de uma nova metodologia de desenvolvimento de SoC s que possibilitará uma diminuição no tempo de desenvolvimento e teste do projeto por meio da geração de uma especificação executável que será utilizada como modelo de referência. A metodologia utiliza diagramas da linguagem UML para a modelagem e descrição do sistema. Para descrição dos módulos em seus diversos níveis de abstração, a metodologia faz uso do ambiente de desenvolvimento da linguagem de descrição de hardware SystemC. Palavras-chave: Projeto de Sistemas Embutidos; Descrição UML; Modelo de Referência; System-on-a-chip (SoC); SystemC.

7 Abstract The increasing demand for electronic components is driving the integrated circuit market to an unexpected growth. In the about two to four years it will be possible to find circuits composed of a billion transistors. This capacity of integration is the responsible for the emergence of a new concept, System-on-a-chip (SoC), in which a complete computational system is embedded into an single integrated circuit. The high complexity of the process of integration and the interconnection of the modules, named Intellectual Property (IP), that composes a SoC, are demanding that the designers of these modules to invest more and more time in the search of new design methodologies. The time spent in the development process of SoC design is also one of the main factors that contribute to the need of new design methodologies. This work presents the proposal of a new SoC design methodology that will make possible a considerable reduction in the time of development and test of the SoC design process through the generation of an executable specification that will be used as a reference model. The methodology utilizes UML diagrams for the system description. For the description of the modules in their levels of abstraction, the methodology makes use of the hardware description language SystemC environment. keywords: Embedded System Design; UML Description; Reference Models; System-on-a-chip (SoC); SystemC Design.

8 Sumário 1 Introdução Motivação Objetivo Organização do Documento Revisão da Literatura 8 3 Metodologia Ferramentas Associadas A Linguagem UML Umbrello UML Modeller SystemC Níveis de Abstração Concepção Especificação Descrição UML Especificação Executável Fluxo de Dados (Data Flow - DF) Descrição Comportamental RTL Fluxo de Projeto Análise de Requisitos Modelagem UML Descrição UML (Umbrello) para SystemC Implementação da funcionalidade do processo Módulo funcional executável viii

9 4 Estudo de Caso Gerador de Caracteres - Visão Geral Análise de Requisitos Visão Global Especificação Modelagem UML Diagrama de Casos de Uso Diagrama de Seqüência Diagrama de Classes Geração do Código Modelo Executável Teste e Validação Resultados Conclusão 78 A Anexos 85 A.1 Código Esqueleto A.2 Código Funcional A.3 Diagrama de Classes - Todos os módulos A.4 Desenvolvimento do plug-in SystemC A.4.1 Linux Fedora Core A.4.2 Umbrello A.4.3 Estrutura de Pastas do Umbrello A.4.4 Plug-in SystemC A.4.5 Detalhes de Implementação

10 Lista de Figuras 1.1 Aumento da capacidade de integração de transistores representado pela evolução dos processadores Intel [27] Níveis de Abstração Propostos por Arnout [2] Níveis de Abstração Propostos pela Synopsys [26] Fluxo de Projeto SLOOP - Proposto por Zhu [28] Fluxo de Projeto em Y - Proposto por Dumoulin [5] Fluxo de Projeto utilizando MDA - Proposto por Riccobene [22] Fluxo de Projeto utilizando MDA - Proposto por Nguyen [18] Comparação do tempo de simulação entre SystemC e VHDL [17] Comparação entre a área efetiva gasta na síntese de código VHDL e SystemC em LUTs [17] Níveis de Abstração alvo da Metodologia Fluxo de Projeto proposto pela Metodologia Exemplo da organização das informações identificadas Exemplo de Caso de Uso Detalhado Estereótipo interface criado para representar uma entidade padrão SystemC Equivalência entre as representações das classes do Umbrello - Módulo (SystemC) x Classe (UML) Caso de Uso Detalhado Diagrama de Caso de Uso - Representação Gráfica Interface - Exemplo de Modelagem Exemplo de um Diagrama de Seqüência Exemplo de um Diagrama de Classes Tipos Padrão do SystemC no Umbrello Menu de Seleção de linguagem ativa x

11 3.16 Menu de Seleção de Classes do Code Generation Wizard Gerador de Caracteres - Visão Geral Gerador de Caracteres - Cenário necessário a modelagem e a simulação Classificação dos Requisitos em funcionais e não-funcionais Requisito Funcional Requisito Funcional Requisito Funcional Requisito Funcional Detalhamento dos Casos de Uso Caso de Uso - Obter Caracteres Caso de Uso - Converter Código ASCII em Matriz de Pontos Caso de Uso - Gerar Seqüência de Pixels Caso de Uso - Gerar Sinais de Controle Gerador de Caracteres - Diagrama de Caso de Uso Gerador de Caracteres - Diagrama de Seqüência Gerador de Caracteres - Diagrama de Classes Exemplo de msg no Diagrama de Seqüência - A Orientação da seta pode indicar o tipo de interface entre módulos Umbrello - Adicionando interfaces aos módulos Representação do caractere ASCII u na ROM Diagrama de Classes - Definição das interfaces Umbrello - Acesso ao gerador de código ( Code Generation Wizard ) Umbrello - Seleção de Módulos para a Geração de código SystemC Umbrello - Indicação do local de gravação dos arquivos fonte e leitura do cabeçalho Umbrello - Aguardando a confirmação para gerar o código Umbrello - Código gerado com sucesso Teste e validação do Modelo de Referência Resultados - Diagrama de Caso de Uso Resultados - Diagrama de Seqüência Resultados - Diagrama de Classes Resultado - Quadro gerado pelo simulador de vídeo Resultado - Formas de onda referente aos sinais de sincronismo do vídeo. 76 xi

12 A.1 Diagrama de Classes Completo e Funcional A.2 Estrutura de pastas do software Umbrello

13 Lista de Códigos Fonte 3.1 Código Esqueleto - Indicação de onde deve ser implementada a funcionalidade do Processo Gerador de Caracteres - Código Esqueleto gerado pela ferramenta Gerador de Caracteres - Implementação da funcionalidade do processo Como construir um Programa principal main.cpp em SystemC A.1 Código Esqueleto - Gerador de Caracteres A.2 Código Esqueleto - Memória A.3 Código Esqueleto - ROM de Caracteres A.4 Código Funcional - Gerador de Caracteres A.5 Código Funcional - Memória A.6 Código Funcional - ROM de Caracteres A.7 Código Funcional - Makefile A.8 Código Funcional - Módulo Controlador (envia os endereços a memória). 90 A.9 Código Funcional - Gerador de Sinais de Video A.10 Código Funcional - Buffer de armazenamento e atualização de quadros.. 93 A.11 Código Funcional - Simulador de Video A.12 Código Funcional - Programa Principal ( Main ) A.13 Umbrello - codegenfactory.cpp A.14 Umbrello - Makefile.am da pasta codegenerators A.15 Umbrello - Makefile.am da pasta headings

14 Lista de Abreviaturas SoC RAM ROM LUT CI SIA DFT NoC OCP-IP IP RTL CAD UML HDL OSCI FPGA ISP ISS FIFO TLM UDF TDF OMG CRT ASCII VCD GNU GPL System on a Chip Random Access Memory Read Only Memory Look-Up Table Circuito Integrado Semiconductor Industry Association Design for Testability Network on a Chip Open Core Protocol International Partnership Intelectual Property (core) Register Transfer Level Computer Aided Design Unified Modeling Language Hardware Description Language Open SystemC Initiative Field Programmable Gate Array Intensive Signal Processing Instruction Set Simulator First In First Out Transaction Level Modeling Untimed Data Flow Timed Data Flow Object Management Group Cathode Ray Tube American Standard Code for Information Interchange Value Change Dump General Public License

15 Capítulo 1 Introdução O constante avanço tecnológico observado por Gordon E. Moore na década de 1960 [24] e o aumento da demanda do mercado por dispositivos eletrônicos, têm contribuído cada vez mais para que as atividades rotineiras realizadas pelo homem sejam automatizadas. Os sistemas computacionais, formados por meio da união entre hardware e software, constituem uma forma moderna de prover essa automatização e são chamados de SoCs - System on a Chip. Os SoCs são sistemas computacionais completos que, apesar de possuírem uma estrutura interna similar ao de um computador, formados por microprocessadores, memórias RAM (Random Access Memory) e ROM (Read Only Memory), barramentos e dotados de software, são caracterizados pela sua capacidade de não serem percebidos como tal pelo o usuário final [7]. A título de exemplo, podemos citar como uma de suas aplicações, a verificação em tempo real da pressão dos pneus de um veículo, um processo totalmente automatizado que já é realizado pela maioria dos sistemas de controle dos veículos considerados de luxo. Atualmente, conforme foi previsto por Moore, estes sistemas são compostos por milhões de transistores embutidos em um único circuito integrado (CI ). A FIG. 1.1 abaixo representa, através da evolução dos processadores do fabricante Intel, o aumento dessa capacidade de integração ao longo dos anos. 1

16 Figura 1.1: Aumento da capacidade de integração de transistores representado pela evolução dos processadores Intel [27]. Nos últimos vinte anos, o avanço da tecnologia de fabricação de CIs continua sendo impulsionada pela lei de Moore que mantém a afirmacão de que o número de transistores por área de chip dobra a cada 18 meses [25]. Estima-se que em menos de 4 anos estarão disponíveis no mercado, circuitos integrados compostos por mais de um bilhão de transistores [19] [10], que se comparado ao estado atual, tornará ainda mais complexa a tarefa de integração e interconexão dos módulos que compõem um sistema dessa grandeza, incluindo os SoCs. Além disso, o tempo entre o desenvolvimento de um produto e seu lançamento no mercado (Time-to-Market), tende a ser cada vez menor [21]. Todos os fatores citados contribuem para a diminuição do tempo disponível para a equipe na concepção e validação de um projeto de SoC. As etapas compreendidas entre a concepção e os testes de SoCs são as que demandam a maior parte do tempo estimado durante o planejamento [20]. Qualquer tipo de erro pode gerar custos e atrasar o cronograma. Isso faz com que cada vez mais, este se torne um problema de responsabilidade das equipes integrantes do projeto. A Semiconductor Industry Association (SIA) prevê que em torno de 2015, o custo para se testar um CI com essa complexidade irá exceder o custo necessário para desenvolvê-lo, caso não sejam empregadas novas metodologias voltadas para seu desenvolvimento [25]. 2

17 Esse fator justifica a necessidade de estar constantemente desenvolvendo novas metodologias que auxiliem as fases de especificação e teste de projetos de SoCs [3]. Novos fluxos de desenvolvimento de projeto também estão sendo pesquisados e aplicados. A maior parte deles visando combater o desperdício de tempo e baseando-se no conceito de projeto voltado para testes, ou Design for Testability (DFT). A própria utilização efetiva de SoCs tem se mostrado útil na tentativa de minimizar alguns desses problemas. Porém, o tempo empregado no desenvolvimento e concepção do seu projeto continua sendo um de seus fatores críticos. As suas principais vantagens sobre as demais tecnologias são: diminuição da área efetiva total gasta pelo hardware e a diminuição no tempo de comunicação entre diferentes módulos. Várias técnicas estão sendo empregadas com o propósito de maximizá-las. Dentre as mais comuns podemos listar: 1. padronização e melhoramento dos meios de interconexão entre módulos do projeto; 2. reuso de módulos ou reutilização; 3. aumento nos níveis de abstração do projeto; A padronização das interconexões busca melhorar a eficiência na troca de dados e informações entre os módulos. A medida que o número de módulos contidos em um SoC aumenta, crescem também os problemas para interconectá-los. A utilização de barramentos simples já não é tão eficiente. Além de ser um meio compartilhado, existem sérias restrições relacionadas a sua forma de comunicação, que se resume a uma mensagem a cada instante. Barramentos hierárquicos e aplicação do conceito de redes de computadores vem sendo utilizados como tentativa de solução. Uma Network on a Chip (NoC), como são chamadas essas redes de comunicação, tende a ser mais eficiente [15] por evitarem situações bloqueantes na comunicação entre dois módulos. Ela os trata como se fossem objetos reais de uma rede, gerenciando a comunicação entre eles por meio de camadas de protocolos. O reuso de módulos que possuem uma funcionalidade previamente definida, chamados de propriedade intelectual (Intellectual property - IP), também tendem a reduzir o tempo 3

18 gasto no projeto. Porém na maioria dos casos, esses módulos ainda não dispõem de uma interface padronizada. Como foi visto anteriormente, o avanço na produção e o aumento na capacidade dos CIs está permitindo que um maior número de módulos ou núcleos IP sejam agregados em um único SoC. A grande quantidade e a falta de interfaces de conexão padronizadas, tornam a reutilização em novos projetos uma tarefa bastante complexa. O aumento nos níveis de abstração também é um dos meios utilizados para tentar diminuir o tempo gasto na concepção de projetos. Além disso, é visto como uma das formas de aumentar a sua eficiência. A complexidade de se desenvolver ou alterar qualquer módulo no nível de transferência de registradores (Register Transfer Level - RTL) é alta. Quando se eleva os níveis a um patamar onde o projetista não precisa mais se preocupar com determinados tipos de detalhes de implementação, a tarefa de descrever as funcionalidades de um módulo, bem como suas conexões e interfaces, torna-se muito mais fácil. Atualmente não existe uma definição ou padronização para determinar os níveis que devem estar compreendidos entre a descrição no nível de sistema e o RTL. A escolha correta das ferramentas de CAD (Computer Aided Design) também se tornou um fator importante durante o processo de desenvolvimento de SoCs. Veremos no decorrer dos capítulos que este trabalho utiliza-se dos recursos de apenas duas ferramentas. O Umbrello UML Modeller, que dá suporte a linguagem de modelagem UML, e SystemC, uma linguagem de descrição de hardware. A Unified Modeling Language(UML) é uma linguagem de modelagem de propósito geral que já vem sendo amplamente utilizada pela comunidade de engenharia de software como framework para documentação de software. Ela provê suporte a projetos orientados a objetos, o qual indiretamente, encoraja a reutilização de componentes, pois apresenta diversas visões do sistema que está sendo projetado com uma grande diversidade de diagramas estruturais e comportamentais. Anteriormente pensava-se que ela havia sido desenvolvida única e exclusivamente para atender as demandas da comunidade de engenharia 4

19 de software. Hoje, UML está se tornando atrativa também para a descrição de sistemas embutidos e de tempo real [14]. SystemC é uma linguagem de descrição de hardware (Hardware Description Language - HDL) de código aberto, baseada em C++. Ela vem sendo desenvolvida por um grupo de empresas que formam a Open SystemC Initiative (OSCI), reconhecida recentemente como novo padrão, IEEE P1666 ( SystemC Language Reference Manual ). Foi criada com a finalidade de atender as necessidades anteriormente descritas de elevação dos níveis de abstração de um projeto de SoC. Além disso SystemC permite que hardware e software sejam descritos simultaneamente em um ambiente homogêneo, proporcionando ao projetista a capacidade de verificação de erros funcionais ainda nas etapas iniciais de desenvolvimento e uma maior compreensão do projeto como um todo. 1.1 Motivação O nível de integração e o número de funcionalidades embutidos em um único circuito integrado está tornando muito complexa a tarefa de desenvolvimento de SoCs. Conseqüentemente o tempo gasto e os custos empregados no decorrer do projeto estão aumentando. Sendo assim, para cada novo projeto de SoC, devemos buscar novos métodos para tentar diminuir o esforço empregado nas suas etapas de concepção e validação. Além de levar em consideração a possibilidade do reuso de módulos em projetos futuros, deve-se preocupar principalmente em garantir a sua qualidade e a confiabilidade. As técnicas de modelagem são utilizadas para garantir estes quesitos e juntamente com a metodologia proposta pode trazer diversas vantagens: Um melhor entendimento do projeto; Facilidade de detecção de erros logo nas primeiras etapas; 5

20 Facilidade de alteração sem custos elevados; Diminuição do tempo gasto compreendido entre o período de concepção e validação da primeira descrição executável; Facilidade de documentação, facilitando o reuso de módulos. 1.2 Objetivo O objetivo deste trabalho é elaborar uma metodologia de desenvolvimento de SoCs que minimize os esforços gastos pelos projetistas no decorrer das etapas de concepção e validação do projeto. A proposta é partir de uma especificação do SoC em alto nível, em conjunto com a sua descrição UML, e chegar a um modelo de referência executável. Inicialmente, pretende-se gerar código esqueleto para SystemC com a finalidade de facilitar o trabalho do projetista durante os diversos refinamentos sucessivos dos módulos até a sua implementação. Em conseqüência deste trabalho foi desenvolvida uma ferramenta para tradução automatizada de descrições UML (de SoCs) em código SystemC. Ela é um plug-in que deve ser instalado juntamente com a ferramenta Umbrello 1 de modelagem UML. Não é objetivo deste trabalho explorar os detalhes de implementação do projeto na ferramenta SystemC em seus diversos níveis de abstração. 1.3 Organização do Documento O texto deste trabalho esta organizado da seguinte forma: No capitulo 2 é apresentada uma revisão da literatura contendo as diversas propostas de metodologias e fluxos de projeto para o desenvolvimento de SoCs ao longo dos 1 6

21 últimos 4 anos. O capitulo 3 apresenta a metodologia. Nela são apresentados os níveis de abstração no qual o projetista deve focalizar para a correta aplicação dos métodos e o fluxo de projeto que deve ser seguido. As ferramentas também são brevemente apresentadas. O capitulo 4 mostra a aplicação da metodologia em um estudo de caso. Nele é apresentado o desenvolvimento de um gerador de caracteres para um display de video. No capitulo 5 é feita uma avaliação dos resultados obtidos. O capitulo 6 apresenta as considerações finais do trabalho e sugestões sobre possíveis trabalhos futuros 7

22 Capítulo 2 Revisão da Literatura Uma das primeiras propostas a apresentar alguma mudança no processo de desenvolvimento de SoCs, utilizando SystemC como linguagem de descrição de hardware, foi descrita por Arnout [2] em Ele propôs dois novos níveis de abstração intermediários entre a especificação e o RTL (Register Transfer Level). O nível não temporizado buscava a descrição funcional do projeto sem a precisão temporal e não havia separação entre hardware e software, enquanto que o transacional descrevia a funcionalidade de cada módulo de forma abstrata e a comunicação entre eles era baseada em ciclos de transações. Arnout tinha como objetivo a diminuição do tempo total gasto no desenvolvimento do projeto. Nesse mesmo ano, uma outra proposta de elevação nos níveis de abstração foi apresentada pela Synopsys [26]. Foram propostos dois novos níveis de abstração além daqueles apresentados por Arnout. Essa nova abordagem proporcionava ao projetista uma visão de quatro níveis de abstração superiores ao RTL: o não temporizado, o temporizado, o de transação e o comportamental. O nível de abstração não temporizado proposto é utilizado para a captura, verificação e otimização dos algoritmos que representam a funcionalidade do sistema. O nível temporizado 8

23 Figura 2.1: Níveis de Abstração Propostos por Arnout [2] descreve esses mesmos algoritmos, mas com uma pequena diferença. Eles passam a ser dotados de atraso, computacionais ou de comunicação, e são utilizados para analisar quais serão as conseqüências causadas pelo impacto da temporização no comportamento e na arquitetura do sistema. O nível de transação descreve o comportamento do módulo em termos de transações e o tempo pode ser representado com precisão de ciclos de relógio ou não. Ainda não existe o detalhamento no nível de porta como no RTL. O nível Figura 2.2: Níveis de Abstração Propostos pela Synopsys [26] 9

24 comportamental descreve o modelo funcional, mas agora composto pela suas interfaces de comunicação (clock, reset, dados e linhas de comandos). Internamente ele ainda não se parece com a implementação estrutural final do RTL, mas já pode se tornar sintetizável. Para transformar um modelo no nível comportamental em blocos totalmente sintetizáveis, é necessário alterar o código para que o mesmo esteja de acordo com o atual conjunto de regras de codificação necessárias para a síntese na ferramenta que será utilizada. Segundo a Synopsys [26], os ganhos na produtividade do projeto de SoC por meio da síntese do código no nível comportamental são maiores do que no nível RTL. O grande número de propostas de elevação nos níveis de abstração fez com que os projetistas encontrassem novas formas de tentar reduzir ainda mais a complexidade e o tempo gasto no desenvolvimento de projetos de SoC. A maioria das pesquisas voltaram suas atenções para propostas de novos fluxos de projeto e novas metodologias. Zhu et al. [28] propuseram uma metodologia de projeto de SoC baseada no conceito de orientação a objetos. SLOOP (System Level Design with Object-Oriented Process), como foi chamada, emprega técnicas de modelagem, avaliação de desempenho de sistemas e metodologia de exploração de arquitetura para descrever o sistema. 10

25 Figura 2.3: Fluxo de Projeto SLOOP - Proposto por Zhu [28] A metodologia propõe quatro modelos para o desenvolvimento de SoC que são utilizados nas etapas anteriores à implementação do software e do hardware, são eles: o conceitual, o funcional, o de arquitetura e o de desempenho. Cada um detalha três aspectos do sistema alvo: funcionalidade, estrutura e temporização. O modelo conceitual descreve o resultado da análise dos requisitos que foi feita com cliente por meio de uma descrição UML. O funcional utiliza redes de processos Kahn 1 para criar um modelo capaz de descrever a estrutura da funcionalidade sem se preocupar com a arquitetura física ou temporização. O modelo de arquitetura representa os recursos físicos da arquitetura, como barramentos, 1 Uma rede de processos Kahn, ou apenas redes de processos, é um modelo de compução que foi originalmente desenvolvido para a modelagem de sistemas distribuidos. Mostrou-se útil também para a modelagem de sistemas de processamento de sinais. Consiste em um conjunto de processos que podem se comunicar apenas através de canais de comunicação unidirecional, formando uma rede. Simplificando, poderíamos pensar em um grafo direcionado onde os nós representam os processos e os arcos o meio de comunicação entre eles. Kahn foi o primeiro a introduzir este conceito em sua tese em 1974 ( The semantics of a simple language for parallel programming ) 11

26 memórias e processadores. O modelo de desempenho organiza os processos descritos no modelo funcional em forma de recursos de processamento dentro do modelo de arquitetura, ou seja, gera um modelo executável que servirá de base para a avaliação do sistema. Segundo os autores o modelo executável gerado auxilia os projetistas a encontrar possíveis gargalos e problemas da arquitetura que foi escolhida, além de melhorar o sistema para que ele satisfaça os requisitos de desempenho especificados no projeto. Dumoulin [5] propôs uma nova abordagem para o desenvolvimento de projeto de SoC utilizando os recursos da arquitetura dirigida a modelo (MDA 2 ) [16] e do Y-chart proposto por Gajski [8]. O trabalho apresenta uma proposta de modelo de desenvolvimento de projeto em forma de Y conforme FIG Figura 2.4: Fluxo de Projeto em Y - Proposto por Dumoulin [5] A partir de dois metamodelos independente de plataforma 3 (PIM 4 ) previamente descritos, 2 MDA foi inicialmente proposta pela OMG [1] com a finalidade de auxiliar no desenvolvimento de softwares. Ela é composta basicamente por modelos que descrevem o sistema a ser desenvolvido. Cada um representa um nível de abstração diferente. Essa arquitetura promove a separação entre a lógica fundamental do sistema, que é descrita na especificação, e suas operações, que serão implementadas em uma determinada tecnologia. Sua principal meta é aumentar a reutilização e reduzir o tempo no desenvolvimentos de novos componentes de software. 3 Plataforma é um conjunto de subsistemas e tecnologias que prevêem um conjunto coerente de funcionalidades através de interfaces. 4 PIM ( Platform Independent Model ) é uma visão do sistema a partir de um ponto de vista inde- 12

27 o de aplicação e o da arquitetura de hardware, é proposto o desenvolvimento de um terceiro que fará a união entre eles. O modelo no nível de aplicação descreve uma maneira de representar as dependências de dados do sistema (funcionalidade), enquanto que o modelo no nível de arquitetura de hardware apresenta uma descrição voltada para sua estrutura. O metamodelo de associação, como foi chamado, fará a importação de ambos os modelos previamente descritos. O modelo resultante será um metamodelo de plataforma especifica (PSM 5 ) capaz de se transformar automaticamente em um modelo de qualquer plataforma de desenvolvimento de SoC. Como estudo de caso os autores utilizaram um profile UML 6 já pronto de um ISP ( intensive signal processing ) [6]. A ferramenta para a tradução automática de modelos encontra-se em fase de desenvolvimento e o resultado do trabalho se resume na proposta de utilização da MDA como forma de modelagem. Outra abordagem para o desenvolvilmento de SoCs utilizando os conceitos da MDA foi apresentada em 2004 por Riccobene [22]. O trabalho propõe um novo fluxo de projeto e apresenta o UML profile para SystemC que foi desenvolvido. pendente de plataforma. Descreve o sistema, mas não apresenta detalhes sobre a sua implementação em determinada plataforma. 5 PSM ( Platform Specific Model ) é uma visão do sistema a partir do ponto de vista de uma plataforma especifica. Combina a descrição do PIM com os detalhes de implementação de uma plataforma em particular. 6 UML Profile - é uma forma especifica de utilizar a linguagem UML (utilizando mecanismos como estereótipo e restrições) para definir um metamodelo UML para um proposito em particular 13

28 Figura 2.5: Fluxo de Projeto utilizando MDA - Proposto por Riccobene [22] O fluxo de projeto utiliza uma especificação descrita em linguagem natural para gerar um representação algorítmica do sistema, que pode ser implementada em uma linguagem de programação de software (como C/C++) ou em uma ferramenta de modelagem (como simulink[ por exemplo). O segundo estágio consiste na separação entre os requisitos de hardware e software, que são desenvolvidos paralelamente ao longo do projeto. O software é compilado para a plataforma que foi definida e gera como resultado um código objeto, enquanto o hardware é apenas descrito em RTL. A partir desses resultados é feita uma co-simulação entre o hardware (em RTL) e as partes do software que estão rodando no simulador (Instruction Set Simulator - ISS) para a verificação dos possíveis erros causados pelo código RTL na tradução para o nível de portas lógicas. O UML profile para SystemC foi baseado na especificação da versão 2.0 da linguagem UML e foi organizado em quatro partes. A primeira parte, de estrutura e comunicação, 14

29 define os estereótipos do núcleo SystemC, ou camada 0 (zero), que podem ser utilizados nos diagramas estruturais UML, responsáveis pelos elementos de estrutura e comunicação (módulos, interfaces, portas e canais). A segunda parte é responsável pela definição dos tipos de dados, representados através dos diagramas de classes, enquanto que a terceira parte descreve o comportamento e a sincronização entre os módulos através dos diagramas comportamentais. A última parte prove conceitos para a definição de canais, interfaces e portas que são pré-definidos na linguagem. Como exemplo podemos citar os canais do tipo first in first out(fifo). Os resultados se resumem nos benefícios de se utilizar UML Profiles para especificar, analisar, projetar, construir, visualizar e documentar sistemas tanto em hardware quanto em software para o projeto de SoC. O trabalho de Nguyen et al. [18] apresenta um mecanismo de descrição no nível de sistema, baseado em notações UML, que é capaz de gerar código SystemC no nível transacional (Transaction Level Modeling - TLM). Esta referência utiliza dois dos diversos diagramas UML para representar o sistema, o diagrama de classes e o diagrama de transição de estados. A ferramenta escolhida para a especificação do sistema através dos diagramas, foi o Rhapsody 7, plataforma de colaboração, desenvolvimento de aplicação e projeto de sistemas, compatível com UML. Os autores tiveram que incorporar estereótipos na ferramenta Rhapsody para que ela conseguisse capturar algumas das primitivas de comunicação da linguagem SystemC, como interfaces e canais. Também foi necessário a utilização de uma outra ferramenta, chamada Velocity 8, para a tradução dos modelos gerados em código SystemC. A FIG. 2.6 abaixo resume o fluxo de projeto proposto

30 Figura 2.6: Fluxo de Projeto utilizando MDA - Proposto por Nguyen [18] Na modelagem UML, o diagrama de classes é responsável pela descrição da estrutura dos componentes, enquanto que o diagrama de transição de estados é um dos diagramas usados para representar comportamento. Esse modelo inicial, deve ser dotado de estereótipos para suprir a necessidade de representação de algumas entidades SystemC. Para a geração do documento XMI é necessário a utilização de um toolkit da ferramenta Rhapsody. A função dele é transformar as informações contidas no modelo gráfico e no conjunto de estereótipos em um documento padrão XMI. Os autores também desenvolveram um parser XMI que agrega mais informações ao documento gerado e o transforma em uma árvore abstrata. Ela servirá como modelo de entrada para a ferramenta Velocity. Só assim o código será gerado. Os autores afirmam que, após todos esses passos e ferramentas que foram utilizadas, para qualquer alteração ou refinamento que se deseja fazer para um 16

31 nível de abstração mais detalhado, será necessário apenas fazer alterações nos modelos (ou templates) gerados como entrada para a ferramenta Velocity. 17

32 Capítulo 3 Metodologia A presente metodologia tem como principal objetivo diminuir o tempo e os esforços gastos pelos projetistas na geração da primeira especificação executável. No desenvolvimento de SoCs, problemas de funcionalidade e de comunicação, dificilmente são detectados logo nas primeiras etapas do projeto e os testes, geralmente são realizados em um ponto onde as alternativas para prováveis correções são poucas e de custo elevado. Na maioria dos casos, as decisões que são tomadas durante estas etapas, compreendidas entre a concepção e validação do projeto, podem gerar um impacto grande na adequação daquilo que foi especificado ao que será efetivamente implementado. Um planejamento inicial mínimo, daquilo que se está projetando, faz-se necessário. É por meio dele que o projetista consegue obter um melhor entendimento do projeto e conseqüentemente pode evitar alterações desnecessárias, diminuindo custos e evitando desperdício de tempo. A metodologia propõe um fluxo de projeto que favorece a visão geral do sistema. Possíveis erros, antes só detectados nos níveis de abstração que já possuíam um considerável nível de detalhamento, como o RTL, poderão ser previstos. Para tanto, a metodologia faz uso de alguns recursos disponíveis nas técnicas de modelagem UML, como documentos e diagramas. Esses fatores não só contribuem com a diminuição do tempo gasto no decorrer 18

33 do desenvolvimento do projeto como também favorecem a reutilização de módulos. Ao final do fluxo proposto, o projetista terá disponível uma especificação funcional SystemC, executável, para utilizar como modelo de referência ao longo dos sucessivos refinamentos que terá que fazer durante os níveis de abstração. A metodologia também apresenta um plug-in SystemC desenvolvido especialmente para a ferramenta Umbrello. Ele é capaz de gerar código SystemC a partir da modelagem do SoC em diagramas UML. Para aplicar a metodologia de forma eficiente é importante que se compreenda todas as etapas e seus respectivos objetivos, a importância de cada uma delas e como trabalham em conjunto para garantir que os resultados esperados sejam alcançados da melhor maneira possível. Um bom conhecimento das ferramentas, UML e SystemC, também garantem um melhor resultado. A próxima seção apresenta um breve resumo de cada uma das ferramentas. A seção 3.2 descreve os níveis de abstração e a seção 3.3 apresenta o fluxo de projeto proposto que é a própria representação da metodologia. Para um melhor entendimento, o capitulo 4 apresenta um estudo de caso com a aplicação da metodologia. 3.1 Ferramentas Associadas A Linguagem UML A UML é uma linguagem de modelagem de propósito geral utilizada para representar sistemas orientados a objetos que surgiu no final da década de UML 1.x é uma combinação de elementos de Booch [4], OOSE [12] e OMT [23]. A versão 2.0 se encontra em fase final de aprovação pela OMG (Object Management Group) e inclui melhoramentos em todas as áreas. Ela possui treze tipos de diagramas capazes de descrever vários aspectos estruturais, comportamentais e físicos de um sistema. Cada diagrama possui um propósito diferente durante o processo de desenvolvimento, por isso é importante ter em mente que os diagramas por si só apenas provêem uma notação e que deve ser acompanhada por uma 19

34 metodologia de projeto. A especificação comportamental em UML, em alto nível, geralmente se inicia a partir da identificação dos casos de uso para um sistema e dos atores envolvidos. Estes são denominados Diagramas de Casos de Uso. Porém, para uma descrição comportamental detalhada, costuma-se usar os Diagramas de Transição de Estado [11], que são capazes de representar máquinas de estado finitas. O Diagrama de Classes é provavelmente o mais conhecido dentro da modelagem UML. Ele descreve os aspectos estruturais de um sistema em termos de classes e como essas classes se relacionam entre si através de associações. Uma classe pode ou não possuir atributos e/ou operações. Além disso, interfaces e generalizações podem ser utilizadas para introduzir hierarquia entre os objetos criados. A ferramenta atualmente mais utilizada para este tipo de modelagem é o Rational Rose da IBM 1, também existem outras ferramentas, dentre as quais podemos citar: Rhapsody da I-logix (voltado para sistemas de tempo real); Together (comprado recentemente pela Borland para incorporar-se no seu ambiente de desenvolvimento); Enterprise Architect (de custo mais acessível); Umbrello (livre distribuição e código aberto); Umbrello UML Modeller O Umbrello UML Modeller 2 é uma ferramenta de modelagem de diagramas UML que foi desenvolvida em 2001 por Paul Hensgen em um de seus projetos universitários. Originalmente foi criada para auxiliar no processo de desenvolvimento de software e seu nome original era Modelador UML. Como era conhecido apenas por UML, um nome muito genérico, causou problemas com algumas distribuições de software que possuíam o mesmo nome e teve que ser mudado. A mudança ocorreu em Setembro de O projeto

35 foi todo revisado pela Universidade onde Paul estudava e passou a ser de livre distribuição e de código aberto. A versão 1.0 já oferecia muitas funcionalidades, mas com as diversas contribuições passou a ter suporte a um número maior de diagramas UML, o formato de arquivo passou de binário para XML, o aplicativo agregou funcionalidades como geração de código automatizada e importação de código. Paul retirou-se da equipe de desenvolvimento em meados de 2002, mas o software está sendo mantido por um grupo de desenvolvedores de diferentes partes do mundo e continua em constante desenvolvimento SystemC SystemC é uma linguagem de descrição de hardware (HDL), código aberto, baseada em C++, que vem sendo desenvolvida por um grupo de empresas que formam a Open SystemC Initiative (OSCI - IEEE P1666). Além de possuir uma estrutura de programação simples e intuitiva, uma das principais características desta ferramenta é que ela possui um núcleo exclusivo para a simulação e provê suporte à concorrência e à hierarquia de módulos. Sua principal vantagem em relação às outras linguagens de descrição de hardware é que ela permite a descrição e teste de módulos em vários níveis de abstração [9]. O projetista não precisa aprender, nem ao menos precisa utilizar mais de um ambiente de programação à medida que prossegue nas etapas de desenvolvimento de seu modulo. Testes realizados por Moreno [17] mostraram que SystemC obteve ganhos consideráveis na velocidade de simulação se comparada a uma das principais linguagens de descrição de hardware, VHDL. Utilizou-se para o teste o algoritmo de ordenação bubble sort. O tamanho da memória de valores a serem ordenados, tamanho do vetor, foi alterado gradativamente como mostra a FIG

36 Figura 3.1: Comparação do tempo de simulação entre SystemC e VHDL [17] Este ganho de velocidade na simulação se deve ao fato de que o simulador padrão da linguagem SystemC permite a simulação em diferentes níveis de abstração. SystemC também favorece a programação intuitiva, permitindo a programação em alto nível por meio da linguagem C/C++. VHDL, por outro lado, necessita de uma programação na qual o projetista tem de se preocupar com o alto nível de detalhamento imposto pela linguagem. Abaixo podemos observar outros resultados, ainda do mesmo trabalho, de testes obtidos através da síntese em FPGA de código VHDL e SystemC. Eles demonstraram que SystemC obteve praticamente o mesmo desempenho (ocupou aproximadamente a mesma quantidade de LUTs 3 na síntese) que a linguagem VHDL(FIG. 3.2). 3 O LUT (Look-Up Table) é uma unidade de memória pré-programada que fornece um resultado de saída de acordo com um conjunto de variáveis de entrada. O LUT, ou Look-Up Table não realiza operação lógica, ele apenas consulta a tabela verdade de uma determinada função que lhe foi programada e fornece o resultado. 22

37 Figura 3.2: Comparação entre a área efetiva gasta na síntese de código VHDL e SystemC em LUTs [17] 3.2 Níveis de Abstração Nível de abstração é a descrição do projeto com uma determinada quantidade de detalhamento. O aumento (ou elevação) nos níveis de abstração também é um dos meios utilizados para tentar diminuir o tempo gasto na concepção de projetos. Além disso, é visto como uma das formas de aumentar a sua eficiência. A complexidade de se desenvolver ou alterar qualquer módulo no nível de transferência de registradores é alta. Quando se eleva os níveis a um patamar onde o projetista não precisa mais se preocupar com determinados tipos de detalhes de implementação, a tarefa de descrever as funcionalidades de um módulo, bem como suas conexões e interfaces, torna-se muito mais fácil. A FIG. 3.3 apresenta a divisão dos níveis de abstração de um projeto de SoC e destaca aqueles onde a metodologia irá auxiliar o projetista no desenvolvimento da primeira especificação executável do sistema. 23

38 Figura 3.3: Níveis de Abstração alvo da Metodologia Concepção É o conjunto de idéias que determinam o escopo (objetivo) do sistema a ser desenvolvido no projeto Especificação A especificação é o nível onde estão detalhadas as características e funcionalidades dos módulos do sistema. Não existe distinção entre hardware e software, e a temporização 24

39 não é representada. Todos os requisitos do projeto bem como os detalhes relacionados a custos, riscos e restrições são cuidadosamente documentados. O diagrama de casos de uso é muito utilizado nesse nível de detalhamento. O que se descreve é uma representação quase algorítmica de como os módulos do sistema se comportam (casos de uso) e com quais outros módulos (atores) se relacionam Descrição UML A descrição UML é praticamente um detalhamento dos requisitos apresentados no nível de especificação, geralmente com o auxílio de uma ferramenta de modelagem com suporte a linguagem UML. O sistema é modelado a partir de um conjunto de diagramas comportamentais e estruturais que representam a sua funcionalidade e o comportamento. Neste nível o que se obtém é um refinamento da especificação que proporciona uma visão geral e uma representação mais detalhada do comportamento sistema. Por meio dessa descrição é possível identificar prováveis erros de concepção e conflitos futuros. A divisão entre hardware e software, e a temporização também não são representados Especificação Executável A especificação executável é a implementação da descrição UML na linguagem de descrição de hardware SystemC. O resultado obtido neste nível é um modelo funcional e executável dessa descrição que pode ser simulado. Esse nível de detalhamento permite que problemas de execução e de comportamento sejam identificados e solucionados. Este é um nível de grande relevância, pois é utilizado como base para o refinamento dos demais e pode ser utilizado como referência em qualquer plataforma de desenvolvimento adotada. 25

40 3.2.5 Fluxo de Dados (Data Flow - DF) Neste nível de abstração também se descreve as funcionalidade dos módulos do sistema, porém, o que o difere dos demais vistos anteriormente é que o modelo agora apresenta de forma clara a troca de mensagens entre módulos. Ele está dividido em dois estágios. O primeiro, caracterizado como Untimed Data Flow (UDF) descreve a funcionalidade do módulo sem a noção de temporização e o segundo, Timed Data Flow (TDF), descreve o módulo em relação ao tempo, com a inserção de atrasos temporais na sua implementação. Abaixo estão descritos em detalhes os dois estágios: UDF - Este estágio não se utiliza de nenhum tipo de sinal de sincronismo ou qualquer tipo de atraso temporal para sincronizar o módulo. O modelo de fluxo de dados é completamente orientado a eventos e o comportamento do módulo é verificado de maneira assíncrona, ou seja, cada ação dentro do mesmo ocorre apenas em decorrência de estímulos gerados por eventos. Essa abordagem facilita a validação do melhor algoritmo funcional devido a eliminação da preocupação desnecessária com detalhes de temporização. O projetista é obrigado a sincronizar os módulos somente com ações (eventos), favorecendo (ou destacando) questões diretamente ligadas à funcionalidade. TDF - O modelo de fluxo de dados temporizado tem capacidade para representar a noção de tempo. Agora existe a preocupação com o sincronismo dos eventos e das operações realizadas pelo módulo no espaço de tempo, bem como os respectivos atrasos de processamento e de comunicação. Por meio dela torna-se possível analisar como os efeitos de latência poderiam influenciar no comportamento final do módulo, se realmente ele esta gerando as respostas de acordo com a especificação dada e se os resultados esperados estão sendo realmente gerados em tempo hábil para sua validação Descrição Comportamental O nível Comportamental é uma descrição algorítmica do comportamento do sistema. Ele geralmente é descrito na forma de precisão de ciclos e ainda não apresenta a estrutura RTL esperada para a implementação final. A principal diferença entre esses dois níveis, Comportamental e RTL, está relacionada com a temporização. Enquanto o RTL tem sua sincronização definida em termos de ciclos de clock, o Comportamental é geralmente 26

41 sincronizado através da utilização de passos computacionais. Como exemplo, a sincronização entre os processos de um sistema no nível Comportamental pode ser feita utilizando o comando wait, cuja a função é aguardar até que um evento (ou processo) seja concluído antes de se passar ao próximo, ou inserindo atrasos temporais. As descrições no nível Comportamental são compactas e mais fáceis de entender do que descrições em RTL. As simulações também são mais rápidas, devido ao nível de abstração ser mais alto RTL Segundo Jerraya [13] este nível de abstração é visto como o último na descrição do projeto de hardware. É nele onde a maioria das ferramentas de síntese trabalham. O nível de detalhamento do módulo corresponde à sua sincronização através de sinais de clock. Toda a comunicação entre processos ocorre única e exclusivamente através de sinais. O comportamento, ou funcionalidade, é representado pelo fluxo dos dados através de blocos funcionais ( datapath ) habilitados por sinais gerados pela unidade de controle, geralmente implementada por máquina de estado finitas. 3.3 Fluxo de Projeto A FIG. 3.4 abaixo resume o fluxo de projeto que representa a metodologia proposta Análise de Requisitos Inspirada nos conceitos utilizados no desenvolvimento de software, a análise de requisitos tem como objetivo descrever o que o cliente espera que o sistema faça. Requisitos são os objetivos e as restrições relacionados ao sistema que se pretende desenvolver. O projetista deve ter em mente que esse conjunto de informações pode ser definido como uma condição ou uma função do SoC que será responsável pela resolução de problemas previamente 27

42 Figura 3.4: Fluxo de Projeto proposto pela Metodologia especificados. A análise de requisitos está dividida em dois grandes estágios. O primeiro apresenta os métodos utilizados para se construir uma visão global do sistema enquanto que o segundo especifica, detalha e prioriza as informações obtidas. Visão Global O objetivo desse estágio é a identificação dos requisitos do SoC que se deseja desenvolver, fornecendo todas as informações necessárias para o entendimento do projeto por parte do desenvolvedor. Abaixo estão enumeradas a seqüência de atividades que o projetista deve seguir a fim de obter este documento: 28

43 1. Capturar o máximo de informações relevantes ao projeto por meio da entrevista com o cliente; 2. Revisar e verificar se algum ponto deixou de ser identificado; 3. Classificar as informações em requisitos funcionais e não-funcionais; 4. Organizar as informações em um documento relacionando os requisitos funcionais às suas respectivas restrições; O responsável pela entrevista deve ter em mente, ou em forma de questionário, uma lista de perguntas necessárias para se extrair o maior número de informações possíveis do projeto com o cliente. Deve-se preocupar em não induzir o mesmo a tomar decisões influenciadas pelo conhecimento prévio do entrevistador em relação à implementação do projeto e às ferramentas que serão utilizadas. O responsável deve fazer ainda uma rápida revisão das questões que foram abordadas e verificar se algum ponto importante para a documentação deixou de ser contemplado. A classificação das informações obtidas deve ser feita considerando os aspectos funcionais e não-funcionais dos requisitos segundo as descrições abaixo: Requisitos Funcionais - descrevem a funcionalidade desejada do SoC. Deve-se determinar o que se espera que o SoC faça sem a preocupação de detalhar como isso deve ser feito: o SoC deve ser capaz de gerar imagens ; o SoC deve ser capaz de comunicar com a interface do LCD ; o SoC deve possibilitar a entrada de dados através de um teclado ; o SoC deve possibilitar o cálculo da soma de dois números reais ; Requisitos Não-Funcionais - descrevem as restrições impostas para a realização de um requisito funcional: a imagem deve ser do tipo bmp ; a imagem não deve ultrapassar a resolução máxima de 800x600 ; 29

44 a interface com o LCD deve utilizar o protocolo OCP-IP para comunicação ; o tempo de resposta do SoC ao teclado não deve ultrapassar 10 ms ; o SoC deve permitir a representação de números reais com um máximo de 4 casas decimais ; o cronograma de desenvolvimento não deve ultrapassar doze meses ; A visão global é a etapa da análise de requisitos onde se definem exatamente quais são as principais funcionalidades do sistema. Conforme apresentado anteriormente, o documento resultante desse estágio é composto pelo conjunto de requisitos funcionais e suas respectivas restrições. Cada funcionalidade deve ser descrita de acordo com o modelo. (Ver FIG. 3.5) Figura 3.5: Exemplo da organização das informações identificadas 30

45 Especificação Após a etapa de visão global deve-se analisar os requisitos a fim de refiná-los e estruturá-los em um modelo que defina precisamente os atores e os casos de uso do sistema. Por meio deste modelo é feita uma análise para identificar quais são os pontos considerados críticos no desenvolvimento do projeto. O resultado é um documento composto pela análise detalhada dos casos de uso e a descrição dos pontos críticos do projeto. Para a geração do documento desta etapa o projetista deverá seguir a seqüência de tarefas a seguir: 1. Identificar os atores O ator é qualquer entidade que interaja com o sistema na realização de uma tarefa ou função. (módulos, interfaces, componentes e outros sistemas) Exemplos: LCD, NoC, teclado, interface OCP-IP. 2. Identificar os casos de uso O caso de uso é um documento narrativo que descreve uma seqüência de eventos (ações) que representa uma funcionalidade, ou seja, descreve uma tarefa a qual o sistema dará suporte. A maioria dos requisitos funcionais listados na visão global são candidatos a se tornarem casos de uso. Exemplos: Gerar Imagem bmp e Calcular Soma de Números Reais 3. Detalhar os casos de uso O projetista deve fazer uma análise e definir quais atores se relacionam com cada caso. A partir dessa análise é possível descrever o fluxo de eventos do caso de uso (FIG. 3.6). Os requisitos funcionais atendidos pelo caso também devem ser referenciados. Essa é uma forma de verificar se os requisitos solicitados pelo cliente estão sendo atendidos. Figura 3.6: Exemplo de Caso de Uso Detalhado 4. Identificar os pontos críticos Por meio do detalhamento dos casos de uso e da experiência do projetista é possível selecionar (mensurar) quais são aqueles com a pior relação entre custo, tempo gasto 31

46 e benefício em seu desenvolvimento. Esses casos terão prioridade sobre os outros no decorrer do projeto e demandam atenção especial. O projetista deve descrever um documento apontando todas essas características. O objetivo deste documento é auxiliar os projetistas a tomarem decisões nos refinamentos futuros tais como: (1) Utilizar ou não um módulo pronto para determinada funcionalidade? (2) O desenvolvimento deste módulo realmente vale o investimento? Todas essas observações deverão ser feitas a título de comparação Modelagem UML Como SoCs são projetados para terem utilidade em algo presente no mundo real, é importante que se compreenda a necessidade da modelagem UML descrita nesta etapa. Ela é uma ferramenta capaz de representar, através de diagramas, um cenário muito próximo da realidade, o que favorece um melhor entendimento do sistema. Nesta fase o projetista deverá utilizar a ferramenta Umbrello para a modelagem. O plug-in SystemC para Umbrello utiliza a notação UML descrita na ferramenta, porém foi necessária a construção, através de estereótipo 4, de uma nova entidade para representar a interconexão entre os módulos 3.7. Figura 3.7: SystemC Estereótipo interface criado para representar uma entidade padrão Em SystemC, a entidade interface faz parte da linguagem e é representada por meio dos sinais de hardware ( signals ) e das filas ( FIFO, LIFO, message queues, etc.). A estrutura de um módulo SystemC foi representada através da própria classe UML, porém com notação diferente. A FIG. 3.8 abaixo apresenta as principais diferenças entre 4 Estereótipos são utilizados em UML para acrescentar novas construções à linguagem. 32

47 um módulo SystemC e uma Classe UML modelados no Umbrello. O projetista deve ficar atento a esta comparação. Figura 3.8: Equivalência entre as representações das classes do Umbrello - Módulo (SystemC) x Classe (UML) Apenas três dos diagramas da linguagem UML serão usados na modelagem proposta na metodologia: 1. Casos de uso: Definição da Funcionalidade e das Interfaces Partindo dos documentos que foram obtidos na análise de requisitos o projetista deverá modelar primeiro o diagrama de casos de uso. Cada caso de uso descrito textualmente no estágio especificação, da fase de análise de requisitos(figs. 3.9), equivale a um caso de uso do diagrama UML(3.10). Os atores que foram identificados anteriormente também devem ser representados. Figura 3.9: Caso de Uso Detalhado 33

48 Figura 3.10: Diagrama de Caso de Uso - Representação Gráfica Posteriormente o diagrama deve ser refinado até que o projetista identifique com clareza a funcionalidade do sistema. As interfaces de comunicação também devem ser modeladas como atores, evitando problemas com a falta de padronização entre os módulos e facilitando a sua visualização. A figura FIG abaixo apresenta um exemplo de como as interfaces devem ser modeladas no diagrama. Figura 3.11: Interface - Exemplo de Modelagem Identificado o Caso de Uso, o projetista deverá descrever seus respectivos diagramas de seqüência e de classes, conforme veremos a seguir. 2. Diagrama de Seqüência: Definição da seqüência de eventos O diagrama de seqüência é necessário porque o diagrama de casos de uso não é capaz de representar nenhum tipo de temporalidade. Não existe regra para a modelagem deste diagrama. A única restrição é a obrigatoriedade da descrição dos atores que representam interfaces no diagrama. O projetista deve se basear nas informações obtidas por meio da descrição e da modelagem previa do diagrama de casos de uso para representar a troca de mensagens e dados entre os módulos. Tanto atores 34

49 quanto casos podem se transformar em componentes do diagrama. A FIG abaixo apresenta a troca de mensagens entre duas entidades, Rede on-chip e Gerar Imagem. Figura 3.12: Exemplo de um Diagrama de Seqüência As mensagens representadas entre os objetos definem uma cronologia de eventos através da numeração, em ordem crescente, e através da posição da mensagem. As mensagens nas posições inferiores do diagrama ocorrem posteriormente as mensagens superiores. 3. Diagrama de Classes: Definição da Estrutura Diagrama de Classes é responsável pela representação e descrição da arquitetura (ou estrutura) do sistema. Similar ao diagrama de blocos, ele consegue demonstrar de forma intuitiva, como os módulos estão distribuídos e como eles se relacionam. No entanto ele não implica em um tipo específico de implementação final do SoC. A FIG apresenta um exemplo de diagramas de classes retirado do próprio estudo de caso. Figura 3.13: Exemplo de um Diagrama de Classes 35

50 3.3.3 Descrição UML (Umbrello) para SystemC O plug-in SystemC para Umbrello suporta todos os tipos de dados padrão da linguagem. Esse suporte é habilitado assim que a opção de linguagem SystemC é ativada no menu Code/Active Language. A FIG apresenta a tela de definição de ports e interfaces na qual o tipo de dado deve ser selecionado. Figura 3.14: Tipos Padrão do SystemC no Umbrello 36

51 Após a modelagem, o projetista deverá primeiramente selecionar a linguagem padrão, no caso SystemC (Ver FIG. 3.15), por meio do menu Code/Active Language. Figura 3.15: Menu de Seleção de linguagem ativa Para a geração do código esqueleto ele deverá acessar o menu Code/Code Generation Wizard e selecionar as classes (módulos) que ele deseja converter (FIG. 3.16). Note que a linguagem padrão continua sendo a selecionada (SystemC) Implementação da funcionalidade do processo Como a metodologia não prevê a geração automática da funcionalidade do processo, o projetista deverá implementar todos os processos que foram definidos na modelagem. Para isso ele deverá acessar o arquivo com a extensão (.h ) e preencher a lacuna entre as chaves do processo definido abaixo das interfaces, conforme o trecho de código apresentado abaixo CÓD Código Fonte 3.1: Código Esqueleto - Indicação de onde deve ser implementada a funcionalidade do Processo 1 #ifndef CONTROLADOR H 2 #define CONTROLADOR H 37

52 Figura 3.16: Menu de Seleção de Classes do Code Generation Wizard 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Controlador ) { 6 7 s c f i f o o u t <T> end ; 8 9 void p r o c e s s ( ) { // Implemente a f u n c i o n a l i d a d e do processo aqui! } SC CTOR( Controlador ) { SC THREAD( p r o c e s s ) ; } 16 } ; 17 #endif //CONTROLADOR H 38

53 3.3.5 Módulo funcional executável Embora não apresente qualquer tipo de funcionalidade, o código apresentado na seção anterior (CÓD 3.1) é executável. Isso é possível devido à ferramenta gerar uma estrutura de código correta capaz de ser interpretada pelo compilador sem erros. O projetista deverá implementar as funcionalidades dos processos definidos, construir as ligações dos módulos no main e simular o modelo de acordo com as instruções da linguagem SystemC, ou seja, fazendo uso de benchmarking 5 para validação dos módulos. Os módulos que estão sendo avaliados necessitam de uma carga inicial de entrada de dados para serem estimulados. Durante a simulação utiliza-se um módulo monitor para a visualização e armazenamento dos resultados. Terminada a simulação é feita uma comparação dos resultados obtidos com os resultados esperados. Se os resultados obtidos estiverem de acordo com os esperados o módulo é validado como funcional. O estudo de caso a seguir apresenta detalhes para a interconexão dos módulos no arquivo main. 5 Processo sistemático e contínuo de avaliação dos produtos, serviços e processos de trabalho 39

54 Capítulo 4 Estudo de Caso O presente estudo de caso tem como finalidade demonstrar a maneira correta da aplicação da metodologia. As seções deste capitulo apresentam a sua aplicação no projeto de concepção e validação de um gerador de caracteres para um display de vídeo. O produto final deste estudo de caso apresenta uma especificação executável e funcional em SystemC da modelagem do SoC. No decorrer do capítulo o projetista deve ficar atento a cada uma das etapas, pois elas representam a visão da metodologia proposta para o projeto de SoCs. Essas fases estão divididas de acordo com a descrição apresentada no capítulo 3. Nelas estão descritas informações de como utilizar a metodologia, em conjunto com as ferramentas adequadas, para se obter um melhor resultado. A seção 4.1 apresenta uma visão geral do sistema e o cenário necessário ao desenvolvimento e teste do módulo Gerador de Caracteres. A seção 4.2 apresenta o detalhamento da Análise de Requisitos do Gerador de Caracteres. A seção 4.3 apresenta como deve ser feita a modelagem UML de acordo com a descrição da metodologia e utilizando os recursos dos diagramas UML apresentados, na seção 4.4 é apresentada a maneira correta para se fazer a tradução destes modelos (em UML) para o código SystemC utilizando o plug-in que foi desenvolvido. A seção 4.5 descreve como gerar o modelo funcional executável do SoC e como devemos 40

55 interconectar seus módulos. A seção 4.6 apresenta a maneira correta para validação e teste do módulo. Na seção 4.7 são apresentados os resultados. 4.1 Gerador de Caracteres - Visão Geral Esta seção é necessária para o entendimento do projeto como um todo. Conforme apresentado na FIG. 4.1, o módulo Gerador de Caracteres que será desenvolvido, faz parte de um sistema maior composto por outros módulos. Figura 4.1: Gerador de Caracteres - Visão Geral Esse sistema recebe os dados provenientes de uma Rede on-chip ( Network on a chip - NoC) processa as informações e as envia para um display de vídeo. O Gerador de Caracteres é o módulo responsável pela tradução das informações referentes a texto provindas da NoC em caracteres. Esses caracteres devem ser transformados no formato necessário à sua visualização no vídeo. Para que o módulo possa ser simulado de acordo com seu ambiente real de funcionamento, é necessário que algumas entidades 41

56 externas (módulos) sejam modeladas em conjunto com o próprio módulo. O cenário proposto está modelo na FIG Figura 4.2: Gerador de Caracteres - Cenário necessário a modelagem e a simulação Neste caso, a ROM de Caracteres e a Memória representam estas entidades (externas ou internas, dependendo da situação) e fazem parte do cenário que é necessário aos testes e a simulação futura do módulo. A ROM de Caracteres é onde estão armazenados todos os caracteres ASCII no formato visível ao display. Cada código ASCII representa uma matriz de pixels que será apresentada na seção 4.4. A memória apenas armazena os caracteres que deverão ser mostrados na tela no formato ASCII propriamente dito. Cada código deverá estar armazenado em um endereço físico da memória para ser lido pelo módulo. 42

57 4.2 Análise de Requisitos Conforme visto na descrição da metodologia, a etapa de Análise de Requisitos é a responsável pela captura das funcionalidades e das restrições do projeto de sistema que se deseja desenvolver, no caso deste trabalho, um Gerador de Caracteres. Dividida em duas etapas, Visão Global e Especificação, a Análise de Requisitos procura resumir em documentos, todas as características funcionais e não-funcionais do projeto, além de identificar os principais atores do sistema Visão Global Em um primeiro momento, o projetista responsável (ou a equipe) deve se preocupar em reunir o maior número de informações relevantes sobre o SoC com o cliente ou mesmo através de pesquisas. As informações contidas no documento devem estar diretamente ligadas a todo e qualquer tipo de requisito, sendo ele funcional ou não. A ordem em que a captura é feita não tem relevância. O objetivo principal desta etapa é detalhar, através dos requisitos, todas as funcionalidades do SoC que se deseja desenvolver. Uma vez capturadas, as informações devem estar organizadas de forma ordenada e numerada. Abaixo podemos ver o primeiro documento da Analise de Requisitos, uma lista contendo todos os requisitos capturados e que possuem relação direta com o projeto do Gerador de Caracteres. Gerador de Caracteres - Requisitos capturados: 1. O módulo deve ser capaz de enviar caracteres para um display de vídeo; 2. O módulo deve ser capaz de converter um código ASCII para o padrão de visualização do display de vídeo; 3. O display deverá receber dados dos caracteres da linha de forma serial; 4. O módulo deve permitir a visualização de caracteres maiúsculos e minúsculos; 43

58 5. O módulo deve permitir a visualização de espaços (incluído após a revisão); 6. Os caracteres deverão ser armazenados em memória; 7. Os caracteres serão representados através do código ASCII; 8. Cada endereço de memória equivalerá a um código ASCII em particular; 9. O módulo deve ser capaz de ler um caractere armazenado memória; 10. O display ou monitor terá a resolução padrão de uma imagem no formato QCIF(176Cx144L) - Detalhado no padrão H.261 de compressão de vídeo; 11. O memória deve ser capaz de armazenar uma tela completa; 12. O módulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do display ; 13. O módulo deverá controlar os sinais de vídeo necessários para o funcionamento do display ; 14. O módulo deverá gerar o sinal de sincronismo horizontal (incluído após a revisão); 15. O módulo deverá gerar o sinal de sincronismo vertical (incluído após a revisão); 16. O módulo deverá gerar o sinal de retraço horizontal (incluído após a revisão); 17. O módulo deverá gerar o sinal de retraço vertical (incluído após a revisão); 18. O módulo deverá formar uma linha de caracteres por vez (incluído após a revisão); 19. O módulo deverá ser capaz de transformar um código ASCII em uma matriz de pontos (pixels) 8x8 (incluído após a revisão); No primeiro documento obtido nem sempre se consegue alcançar o objetivo, que é descrever todas as funcionalidades e restrições. Após uma rápida revisão foi possível identificar que alguns requisitos não haviam sido abordados. Esses requisitos foram incluídos apenas para conhecimento do leitor, mesmo sendo uma informação desnecessária ao projeto. Os requisitos relevantes devem constar nesta lista, mesmo que o projetista somente os identifique algumas etapas adiante. A tarefa após a definição da lista de requisitos é a de classificação. Todo e qualquer requisito foi classificado como requisito funcional ou não-funcional. A seção descreve as informações necessárias para auxiliar o projetista durante esta tarefa. 44

59 O segundo documento é praticamente a mesma lista apresentada no primeiro, porém com a adição de um campo contendo a classificação de cada requisito (FIG. 4.3). Gerador de Caracteres - Classificação dos Requisitos Figura 4.3: Classificação dos Requisitos em funcionais e não-funcionais Após a classificação deve-se separar cada requisito de acordo com a sua caracterização, formando dois grandes grupos, o primeiro contendo os requisitos classificados como funcionais e o outro contendo os não-funcionais. Deve-se também colocar um identificador para diferenciar futuramente cada requisito, sendo ele funcional ou não. No caso do Gerador de Caracteres foram utilizados os códigos RF-xxx para identificar os requisitos funcionais (ex. RF Requisito Funcional 1) e RNF-xxx para identificar os não-funcionais (ex. RNF Requisito Não-Funcional 1). Essa é a descrição que caracteriza as informações contidas no terceiro documento da visão global, veja classificação abaixo: Gerador de Caracteres - Separação e Identificação Funcionais: RF-001: O módulo deve ser capaz de ler um caractere armazenado ; 45

60 RF-002: O módulo deve ser capaz de converter um código ASCII para o padrão de visualização do display de vídeo ; RF-003: O módulo deve ser capaz de enviar caracteres para um display de vídeo ; RF-004: O módulo deverá controlar os sinais de vídeo necessários para o funcionamento do display ; Não-funcionais: RNF-001: Os caracteres deverão ser armazenados em memória ; RNF-002: Os caracteres serão representados através do código ASCII ; RNF-003: Cada endereço da memória equivalerá a um código ASCII em particular ; RNF-004: O display de vídeo terá a resolução padrão de uma imagem no formato CIF(352Cx288L) - Detalhado no padrão H.261 de compressão de vídeo ; RNF-005: O memória deve ser capaz de armazenar uma tela completa ; (Requisito Extra) RNF-006: O display deverá receber dados dos caracteres da linha de forma serial ; RNF-007: O módulo deve permitir a visualização de caracteres maiúsculos e minúsculos ; RNF-008: O módulo deve permitir a visualização de espaços ; RNF-009: O módulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do display ; RNF-010: O módulo deverá gerar o sinal de sincronismo horizontal ; RNF-011: O módulo deverá gerar o sinal de sincronismo vertical ; RNF-012: O módulo deverá gerar o sinal de retraço horizontal ; RNF-013: O módulo deverá gerar o sinal de retraço vertical ; RNF-014: O módulo deverá enviar uma linha de caracteres por vez ; RNF-015: O módulo deverá ser capaz de transformar um código ASCII em uma matriz de pontos (pixels) 8x8 ; Classificados e devidamente identificados, o projetista deve relacionar os requisitos não-funcionais e funcionais entre eles. Uma restrição, ou requisito não-funcional, pode estar diretamente relacionada com uma funcionalidade (requisito funcional). Isso não é regra, algumas restrições podem estar relacionadas a outros fatores, como por exemplo o tempo de projeto. 46

61 O quarto e último documento da visão global deve descrever essas relações de forma clara. Dependendo do projeto, deve-se construir o modelo ou o documento que será utilizado para essa relação. A metodologia sugere um modelo de fichas, pois é bastante funcional e simples. Cada ficha é responsável pela descrição de uma funcionalidade e suas respectivas restrições. O projetista, no ato de preenchimento das fichas com as relações, deve identificar o impacto gerado por cada restrição no projeto. As FIGs. 4.4, 4.5, 4.6 e 4.7 compõem o documento final desta etapa. Gerador de Caracteres - Organização final (Visão Global): Figura 4.4: Requisito Funcional

62 Figura 4.5: Requisito Funcional 002 Figura 4.6: Requisito Funcional

63 Figura 4.7: Requisito Funcional Especificação A especificação consiste na análise do documento que foi obtido na Visão Global. Esta etapa tem com o objetivo de identificação dos atores e dos casos de uso que farão parte do sistema. Como dica, pode-se afirmar que os requisitos funcionais são grandes candidatos a se tornarem casos de uso e suas restrições podem conter indícios dos prováveis atores. Os conceitos e detalhes a respeito de atores e casos de uso estão descritos na metodologia, seção O primeiro documento deste estágio é uma lista com a descrição dos atores e dos casos de uso identificados para o projeto do Gerador de Caracteres. Gerador de Caracteres - Atores identificados: Memória Display Interface ROM de caracteres 49

64 Gerador de Caracteres - Casos de uso identificados: Obter caractere da memória Converter código ASCII em uma matriz de pontos Gerar seqüência de pixels para cada linha Gerar sinais de controle A tarefa de detalhamento dos casos de uso consiste na descrição da seqüência de eventos, realizada pelo caso e seus atores, que descreve determinada funcionalidade. Neste documento, um pouco mais elaborado, deve-se relacionar os casos de uso identificados com os respectivos atores, além de apontar quais requisitos funcionais foram atendidos. Este segundo documento da especificação deve estar organizado como demonstra a FIG. 4.8 abaixo. Gerador de Caracteres - Casos de uso detalhados: Figura 4.8: Detalhamento dos Casos de Uso Dentre todos os casos de uso descritos, o projetista deve selecionar aqueles considerados críticos para o desenvolvimento do projeto. Deve-se analisar a viabilidade da implementação destes casos, tanto em relação ao custo quanto à sua complexidade e o tempo gasto para 50

65 implementá-lo. Quanto maior a experiência do responsável em projetos dessa grandeza, maiores as possibilidades de sucesso na escolha dos casos realmente críticos. Os dois casos considerados críticos no projeto do Gerador de Caracteres foram escolhidos devido à sua complexidade de implementação. Ainda assim, eles são considerados viáveis para o seu desenvolvimento no projeto. Gerador de Caracteres - Casos de uso considerados críticos: Gerar seqüência de Pixels para cada linha Gerar sinais de controle 4.3 Modelagem UML A próxima etapa no projeto é a modelagem UML do Gerador de Caracteres na ferramenta Umbrello. Deve-se fazer uso dos diagramas UML apontados na metodologia (Diagrama de Casos de Uso, de Seqüência e de Classes) Diagrama de Casos de Uso O diagrama de casos de uso será modelado utilizando como referência os documentos da Especificação contidos na Análise de Requisitos. A primeira etapa consiste na modelagem dos casos identificados. Eles são representados na ferramenta através de um círculo com o nome do respectivo caso de uso. Se necessário, pode-se resumir os nomes de cada um, desde que não altere o seu sentido. Na segunda etapa deve-se modelar os atores, representados pela linguagem UML por meio bonecos. A última etapa a ser modelada são os relacionamentos, também chamados de associação. O projetista deve relacionar os atores a seus respectivos casos. Deve-se ficar atento ao que foi descrito no documento de detalhamento dos casos de uso (neste projeto representado pela FIG. 26 da sessão 4.1.2). 51

66 Nota-se que em cada relacionamento do diagrama apresentado abaixo (FIGs. 4.9, 4.10, 4.11 e 4.12), existe um ator chamado interface. Ele representa o tipo de comunicação que será implementada. Mesmo que ela ainda não esteja definida, é obrigatória a sua representação, pois além de facilitar a visualização do projeto será útil nos níveis de abstração inferiores, no qual são implementadados os meios de comunicação. Figura 4.9: Caso de Uso - Obter Caracteres Figura 4.10: Caso de Uso - Converter Código ASCII em Matriz de Pontos 52

67 Figura 4.11: Caso de Uso - Gerar Seqüência de Pixels Figura 4.12: Caso de Uso - Gerar Sinais de Controle Quanto maior o projeto, maior as chances de os casos de uso possuírem atores em comum em seus relacionamentos. Esses casos devem ser analisados cuidadosamente. Se existir alguma relação entre eles, deve-se agrupá-los em único caso, conforme é demonstrado no diagrama de caso de uso abaixo do Gerador de Caracteres (FIG. 4.13). 53

68 Figura 4.13: Gerador de Caracteres - Diagrama de Caso de Uso Diagrama de Seqüência O Diagrama de Seqüência deve ser descrito com o objetivo de demonstrar a possível comunicação entre o SoC (Gerador de Caracteres) e os sistemas ou módulos que se relacionam com ele. Todos os atores devem estar representados, inclusive as interfaces de comunicação. A troca de informações entre eles deve ser representada através de mensagens e elas devem estar numeradas em ordem cronológica de acontecimento, pois esta é a forma utilizada pelo diagrama para representar o momento em que uma determinada mensagem ocorre em relação às outras. O projetista deve rever este diagrama quantas vezes forem necessárias, tentando representar da melhor maneira a funcionalidade que se deseja atingir. 54

69 Figura 4.14: Gerador de Caracteres - Diagrama de Seqüência Diagrama de Classes Tendo como base os diagramas anteriores, deve-se representar a estrutura final do módulo. O diagrama de classes, muito parecido com o diagrama de blocos, deve ser utilizado para esta finalidade. O projetista não deve se preocupar ainda com os atributos e operações que deveriam estar complementando as classes deste diagrama, pois isso será detalhado na próxima seção. 55

70 Figura 4.15: Gerador de Caracteres - Diagrama de Classes 4.4 Geração do Código Para este trabalho, desenvolveu-se um simulador de um display de vídeo contendo todos os sinais de sincronismo de um monitor CRT (Cathode Ray Tube) padrão o qual será apresentado na próxima seção (4.4), porém o escopo deste trabalho é o desenvolvimento de um gerador de caracteres. Para a implementação dos demais módulos, o projetista deve ter em mãos a referência que informa quais serão os sinais e os tipos de dados que o SoC em desenvolvimento irá controlar. A ferramenta de tradução de código necessita que o projetista informe nos módulos descritos no diagrama de classes quais serão as interfaces de comunicação. Por mais simples que possa parecer, está é uma das tarefas mais complexas. Além de utilizar todo o conceito do projeto, que pode ser abstraído dos diagramas descritos nas etapas anteriores, deve-se ter um mínimo de conhecimento prévio da estrutura da linguagem (SystemC ) e dos processos de desenvolvimento de SoC. Como a metodologia abrange o nível de abstração onde toda e qualquer informação 56

71 (dados) é sincronizada por meio de eventos, deve-se utilizar somente FIFO s (sc fifo in e sc fifo out) como canais de comunicação ( channels ) entre os módulos. A maneira mais simples de identificá-los é através das informações contidas no diagrama de seqüência, porém é aconselhável que o projetista também faça um pequeno esboço, contendo o diagrama de blocos referente ao projeto, descrevendo passo a passo a funcionalidade do SoC como um todo. A orientação de cada mensagem no diagrama de seqüência pode informar o tipo de interface que deve ser utilizada (entrada/saída). Quando se identifica que uma mensagem do diagrama é realmente um provável channel a ser utilizado no projeto, deve-se observar o sentido de orientação das mensagens. O início de uma seta indica que o módulo de onde ela partiu possui uma interface de saída (sc fifo out). A extremidade final da seta indica que o módulo apontado possui uma interface do mesmo tipo de dados, porém de entrada (sc fifo in), conforme podemos observar na FIG Figura 4.16: Exemplo de msg no Diagrama de Seqüência - A Orientação da seta pode indicar o tipo de interface entre módulos O nome representado da mensagem no diagrama pode ajudar a definir o nome de um channel que irá interconectar dois módulos. Para evitar erros em uma futura interconexão destes módulos dentro do arquivo main é recomendado que se utilize o mesmo nome de interface (reveja FIG. 4.16), lembrando que uma será de entrada e a outra de saída. 57

72 Conforme foi visto, as etapas descritas nos parágrafos abaixo descrevem os passos utilizados no estudo de caso para a definição das interfaces dos módulos por meio da análise do diagrama de seqüência (FIG. 4.14) da seção A primeira mensagem do diagrama, 1: Endereço,, esta indicando um fluxo de dados que vai do gerador de caracteres para a memória. O projetista experiente logo irá questionar onde e como esses endereços serão gerados e/ou armazenados. Como não foi informado na especificação o formato da entrada de dados, definiu-se que os endereços ficarão armazenados em outro módulo que será definido na próxima seção (4.4). Isso elimina a possibilidade de uma interface de saída com este nome para o módulo gerador de caracteres. Mesmo que não seja o gerador de caracteres o responsável pelo envio dos endereços, eles ainda deverão ser recebidos na memória. Conforme a descrição, ela é a responsável pelo armazenamento dos códigos ASCII que serão representados no display. A partir dessa informação obtém-se a primeira interface de entrada, chamada de end (abreviação de endereço ). Ela deverá ser incluída no módulo que representa a memória no diagrama de classes como sc fifo in<t>end. Para inserir uma interface em um módulo do diagrama de classes basta clicar com o botão direito do mouse e acessar propriedades. Clique em atributos na tela à esquerda e insira um novo atributo. Selecione a interface sc fifo in<t> em tipo e forneça o nome end no formulário (FIG. 4.17). 58

73 Figura 4.17: Umbrello - Adicionando interfaces aos módulos A mensagem 2: ASCII - indica uma funcionalidade que foi descrita na especificação. Após o fornecimento de um endereço, a memória envia uma mensagem contendo o código ASCII de um caractere para que o gerador de caracteres construa sua matriz de pixels. Esta mensagem caracteriza um channel entre a memória e o gerador de caracteres. As interfaces que constituem este channel são: ASCII de saída na memória e ASCII de entrada no gerador de caracteres ( sc fifo out<t>ascii, sc fifo in<t>ascii ). Mensagem 3: ASCII - Como a ROM de caracteres armazenas todos os códigos que constituem a tabela ASCII, o gerador de caracteres necessita transformar o código recebido da memória (ASCII ) em um endereço válido que possa ser lido na ROM. Além disso, se fosse utilizado o nome ASCII para representar este channel, teríamos duas interfaces de mesmo nome no módulo gerador de caracteres, uma de entrada, recebendo dados da memória e outra de saída, enviando dados para a ROM. Por esse motivo utilizou-se address ao invés de ASCII para representar este channel. Ele é composto pelas seguintes 59

74 interfaces: address de saída do gerador de caracteres e address de entrada na ROM de caracteres. Mensagens 4: Matriz de Pontos, 5: Armazena Linha de Caracteres e 6: Seqüência de Pixels - O gerador de caracteres, segundo a especificação, é o responsável pela formação da linha a ser enviada ao display. Para manter essa afirmação o módulo deveria ser capaz de armazenar uma grande quantidade de linhas a serem mostradas. Isso somente seria possível se fosse introduzido um buffer (área de armazenamento) dentro do próprio módulo, e ele deveria ser capaz de realizar escrita e leitura simultâneas, aumentando a complexidade de implementação. Para facilitar o desenvolvimento e evitar erros, optou-se pelo desenvolvimento de um módulo com esta função de armazenamento de linhas e quadros separadamente. A funcionalidade da ROM foi mantida, porém ela não retornará a linha de pixels para o gerador de caracteres e sim para um módulo de armazenamento. Para este estudo de caso definiu-se que a representação de cada código ASCII será realizada por meio de uma matriz de pixels 8x8 de zeros(0) e um(1). Estes valores são responsáveis pela representação da forma, ou seja, desenho de cada caractere no display como mostra a FIG Figura 4.18: Representação do caractere ASCII u na ROM Para este módulo o nome dado a interface de saída foi character line. Como cada linha de um caractere possui 8 pontos e cada ponto pode representar apenas 0 (zero) ou 1 (um), o tipo escolhido foi o sc bv<8>(bit value de tamanho 8). Este tipo armazena 60

75 apenas zeros e 1(um) e permite operações com outros tipos padrão do SystemC. A última mensagem restante, 6: Sinais de Controle, acontece simultaneamente com a mensagem 6: Seqüência de Pixels já apresentada. Devido a complexidade e quantidade de sinais de controle necessários ao funcionamento correto do display, chegou-se a decisão que este também deveria ser um módulo a parte. Esta mensagem não representa um tipo isolado de interface, mas diversas. A memória por si mesma não define automaticamente uma área de armazenamento. Para armazenar os caracteres ASCII que serão lidos através da interface end criou-se um buffer unidimensional de inteiros de 32 bits, de tamanho ainda a ser definido no main (sc int<32>buffer[tambuffer]). Em cada módulo adicionou-se um processo. Ele é o responsável pela descrição da funcionalidade de cada módulo em particular. O método de implementação dessa funcionalidade será descrita na próxima seção. Para adicionar um processo ao módulo, acesse propriedades e clique em operations. Preencha o formulário com o nome do processo e clique em OK. Este processo é similar a adição de interfaces. Utilize como referência a FIG A FIG abaixo apresenta o resultado do diagrama de classes contendo todos os módulos e suas respectivas interfaces. 61

76 Figura 4.19: Diagrama de Classes - Definição das interfaces Esta etapa deve ser refeita quantas vezes forem necessárias. Para gerar o código SystemC por meio da ferramenta acesse o code generation wizard no menu code. Antes, verifique se a linguagem SystemC está configurada como padrão no menu code/active language. Figura 4.20: Umbrello - Acesso ao gerador de código ( Code Generation Wizard ) 62

77 Selecionar as classes que contem interfaces para a geração do código e clicar em next. Figura 4.21: Umbrello - Seleção de Módulos para a Geração de código SystemC Indicar o caminho onde o código SystemC será gravado em write all generated files to folder. Indicar o caminho do cabeçalho dos arquivos fontes include heading files from folder. Clicar em next. Figura 4.22: Umbrello - Indicação do local de gravação dos arquivos fonte e leitura do cabeçalho 63

78 Os módulos selecionados serão mostrados com a informação de que ainda não foram gerados ( Not Yet Generated ). Figura 4.23: Umbrello - Aguardando a confirmação para gerar o código Clicar em Generate. A tela irá confirmar a geração do código com Code Generated. Figura 4.24: Umbrello - Código gerado com sucesso 64

79 Na pasta onde os fontes foram gravados, deve-se descartar os arquivos com a extensão *.sc. Para cada um dos módulos haverá um arquivo de extensão *.h contendo o código SystemC. 4.5 Modelo Executável O código gerado pela ferramenta encontra-se nos anexos deste trabalho com o título de código esqueleto. O projetista deve acessar cada módulo e implementar o código na área definida, linha número 12 do CÓD. 4.1 abaixo. Código Fonte 4.1: Gerador de Caracteres - Código Esqueleto gerado pela ferramenta 1 #ifndef GERADOR DE CARACTERES H 2 #define GERADOR DE CARACTERES H 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Gerador de Caracteres ) { 6 s c f i f o i n <T> ASCII ; 7 s c f i f o o u t <T> address ; void p r o c e s s ( ) { // Implemente a f u n c i o n a l i d a d e do processo aqui! } 15 SC CTOR( Gerador de Caracteres ) { SC THREAD( p r o c e s s ) ; } 16 } ; 17 #endif //GERADOR DE CARACTERES H 65

80 Todas as informações descritas na seção anterior (4.3) auxiliaram na definição da funcionalidade dos processos dos módulos. Será apresentado apenas uma explicação linha a linha da definição da funcionalidade do processo do gerador de caracteres (CÓD. 4.2). A implementação completa do projeto pode ser encontrada para consulta no apêndice, com o nome de código funcional. Código Fonte 4.2: Gerador de Caracteres - Implementação da funcionalidade do processo 1 void p r o c e s s ( ) { 2 3 while ( 1 ) { 4 wait (CB CLOCK) ; 5 T ASCII value = ASCII. read ( ) ; 6 T a d d r e s s v a l u e ; 7 for (T s c a n l i n e v a l u e = 0 ; s c a n l i n e v a l u e < 8 ; s c a n l i n e v a l u e++) { 8 a d d r e s s v a l u e = ASCII value 8 + s c a n l i n e v a l u e ; 9 cout << "tempo = " << sc time stamp ( ) ; 10 cout << " address = " << a d d r e s s v a l u e << endl ; 11 address. w r i t e ( a d d r e s s v a l u e ) ; 12 CG CLOCK. n o t i f y ( ) ; 13 } 14 } } Abaixo temos a descrição, linha por linha, das funções e comandos utilizados para a implementação do processo: 1. Linha 3 O sincronismo dos módulos acontece somente através da notificação de eventos. O while(1) garante que o processo vai executar durante todo o processo de simulação, 66

81 mas ele apenas será ativado com a notificação da ocorrência de um evento. 2. Linha 4 O comando wait está aguardando o evento, CB CLOCK, ser notificado por outro módulo. Neste caso, a memória é a responsável pela informação de que o dado, ASCII, está pronto para ser lido. Todos os eventos estão definidos no arquivo main.cpp. 3. Linha 5 Lê a informação da interface e armazena localmente no módulo. 4. Linha 6 É uma variável local que foi criada para armazenar o address que será enviado a ROM de caracteres. 5. Linha 7 A ROM de caracteres armazena uma matriz de pontos 8x8 de cada caractere. Para cada ASCII recebido, o gerador de caracteres precisa ler as oito linhas que estão armazenadas. 6. Linha 8 Os endereços na ROM estão alocados unidimensionalmente e linha a linha, ou seja, cada caractere ocupa oito posições. A equação permite a leitura exata de cada linha. Ex.: O ASCII 85, caractere u. Ocupa as posições 680 a 687 da ROM. 7. Linha 9 Função para verificar em que tempo esta ocorrendo a leitura (Debug). 8. Linha 10 Função para verificar se o address esta sendo passado corretamente (Debug). 67

82 9. Linha 11 Escreve o address na interface de saída para a ROM de caracteres. 10. Linha 12 Linha 12: Utiliza este evento para notificar que o dado agora está disponível. A ROM utiliza este evento para saber que o dado está pronto para leitura. 4.6 Teste e Validação Para que um SoC seja simulado em SystemC é preciso definir um módulo para a geração de dados de entrada (E. - Estimulo ) e outro para a visualização dos resultados(m. - Monitor ). A FIG abaixo apresenta a forma correta para se validar um módulo quando não se tem uma referência, para fins comparativos, do próprio modelo. Figura 4.25: Teste e validação do Modelo de Referência 68

83 Primeiramente cria-se um vetor de teste onde as saídas são conhecidas. No projeto do gerador de caracteres foi criado um vetor de números inteiros, contendo 4 posições para abrigar os seguintes caracteres ASCII: 85 ( u ), 70 ( f ), 77( m ) e 71( g ). Posteriormente o projetista deve implementar no monitor a visualização dos dados de forma que se possa comparar com o resultado esperado, caracterizando assim um benchmark, onde os dados (ou cargas) de entrada e de saída são conhecidos. Para o SoC em desenvolvimento utilizou-se um simulador de display e o GTKWave para a visualização dos sinais em forma de onda. Por este motivo definiu-se que os endereços enviados para memória seriam gerados por um outro módulo que não fosse o próprio gerador de caracteres. Não é aconselhável que o módulo principal do projeto seja também seu próprio fornecedor de dados. A este módulo deu-se o nome de controlador (ver anexos). Os demais módulos citados anteriormente (seção 4.3) estão na descrição seguinte: Refresh Mem - Módulo responsável pelo armazenamento das linhas e dos quadros a serem mostrados no display. Gerador de Sinais de Vídeo - Módulo responsável pela geração dos sinais de sincronismo do vídeo Simulador de Vídeo - Módulo responsável pela simulação do display O arquivo para interconexão dos módulos foi chamado de main.cpp. Como o foco deste trabalho não é o aprendizado da programação em linguagem SystemC, a implementação do mesmo, juntamente com os demais módulos, pode ser conferida nos anexos. No entanto, formulou-se o CÓD. 4.3 abaixo como referência para o projetista. Código Fonte 4.3: Como construir um Programa principal main.cpp em SystemC 1 //INCLUIR A BIBLIOTECA PADRÃO DO SYSTEMC 69

84 2 #include <systemc. h> 3 4 //INCLUIR AS DECLARAÇÕES DOS MÓDULOS 5 #include " modulo1.h" 6 7 //INCLUIR AS DEFINIÇÕES 8 #define DEFINICAO , SC NS 9 10 //DECLARAR AS CONSTANTES 11 const int constante1 = 100; //DECLARAR A FUNÇÃO PRINCIPAL MAIN 14 int sc main ( int argc, char agv [ ] ) 15 { //DECLARAÇÕES DOS CANAIS ( Channels > s c f i f o and s c s i g n a l ) //DECLARAÇÕES DE VARIAVÉIS ( s c b i t, s c i n t,..., e t c. ) //DECLARAÇÕES DAS INSTÂNCIAS DOS MÓDULOS //CONEXÕES DAS PORTAS DOS MÓDULOS //DEFINIÇÃO DO TEMPO DE SIMULAÇÃO //CONFIGURAÇÃO DO ARQUIVO TRACEFILE 22 //INICIAR A SIMULAÇÃO ( s c s t a r t (TEMPO SIMUL) ) 23 return 0 ; 24 } 4.7 Resultados Os resultados finais e os mais relevantes de cada etapa estão descritos novamente abaixo como forma de simplificar a visualização do projeto. Identificação e Classificação dos Requisitos 70

85 Funcionais: RF-001: O módulo deve ser capaz de ler um caractere armazenado ; RF-002: O módulo deve ser capaz de converter um código ASCII para o padrão de visualização do display de vídeo ; RF-003: O módulo deve ser capaz de enviar caracteres para um display de vídeo ; RF-004: O módulo deverá controlar os sinais de vídeo necessários para o funcionamento do display ; Não-funcionais: RNF-001: Os caracteres deverão ser armazenados em memória ; RNF-002: Os caracteres serão representados através do código ASCII ; RNF-003: Cada endereço da memória equivalerá a um código ASCII em particular ; RNF-004: O display de vídeo terá a resolução padrão de uma imagem no formato CIF(352Cx288L) - Detalhado no padrão H.261 de compressão de vídeo ; RNF-005: O memória deve ser capaz de armazenar uma tela completa ; (Requisito Extra) RNF-006: O display deverá receber dados dos caracteres da linha de forma serial ; RNF-007: O módulo deve permitir a visualização de caracteres maiúsculos e minúsculos ; RNF-008: O módulo deve permitir a visualização de espaços ; RNF-009: O módulo deve ser capaz de gerar um quadro completo (ou varredura vertical) do display ; RNF-010: O módulo deverá gerar o sinal de sincronismo horizontal ; RNF-011: O módulo deverá gerar o sinal de sincronismo vertical ; RNF-012: O módulo deverá gerar o sinal de retraço horizontal ; RNF-013: O módulo deverá gerar o sinal de retraço vertical ; RNF-014: O módulo deverá enviar uma linha de caracteres por vez ; RNF-015: O módulo deverá ser capaz de transformar um código ASCII em uma matriz de pontos (pixels) 8x8 ; Identificação dos Casos e dos Atores Gerador de Caracteres - Atores identificados: 71

86 Memória Display Interface ROM de caracteres Gerador de Caracteres - Casos de uso identificados: Obter caractere da memória Converter código ASCII em uma matriz de pontos Gerar seqüência de pixels para cada linha Gerar sinais de controle 72

87 Descrição do Diagrama de Caso de Uso Figura 4.26: Resultados - Diagrama de Caso de Uso 73

88 Descrição do Diagrama de Seqüência Figura 4.27: Resultados - Diagrama de Seqüência 74

89 Descrição do Diagrama de Classes Figura 4.28: Resultados - Diagrama de Classes A visualização dos resultados é feita de duas maneiras. A primeira é por meio do próprio simulador de vídeo que foi implementado e pode ser encontrado nos anexos (simulador video). A segunda, é através da visualização das formas de ondas geradas pelo arquivo tracefile definido no main. O arquivo com extensão *.vcd ( Value Change Dump ) gerado pode ser visualizado no programa GTKWave, de licença publica ( GNU - General Public License ). A FIG abaixo apresenta a tela resultado da simulação do gerador de caracteres em conjunto com o simulador de vídeo. 75

90 Figura 4.29: Resultado - Quadro gerado pelo simulador de vídeo Observe que o caractere - no simulador representa o pixel apagado e o caracter w representa o pixel aceso. A memória do gerador de caracteres foi preenchida com os caracteres ASCII que formam a palavra ufmg. Para fins de teste, definiu-se que a tela suportaria 4 linhas x 8 colunas de caracteres. Como cada caractere é representado por uma matriz de pontos 8x8, então o simulador de vídeo implementa um quadro que contem 32x64 pontos. O sincronismo de cada quadro do display pode ser conferido na FIG abaixo. Figura 4.30: Resultado - Formas de onda referente aos sinais de sincronismo do vídeo A varredura horizontal ( HSYNC ) somente é ativada após a varredura de todas as colunas da linha ( PX COL ), 64 pontos. A varredura vertical( VSYNC ) somente é 76

91 ativada após a varredura horizontal de todas as 32 linhas de pontos ( PX LINE ), formando assim um quadro completo para a visualização na tela. 77

92 Capítulo 5 Conclusão O presente trabalho apresentou uma visão geral (overview) das mais recentes pequisas em desenvolvimento de projeto de SoC s, das propostas de novas metodologias de projeto e das ferramentas de geração de código SystemC. Demonstrou também a necessidade e a importância de novas metodologias serem continuamente propostas. A contribuição científica deste trabalho pode ser resumida em dois aspectos principais: a proposta de uma nova metodologia de desenvolvimento de SoC s a partir de descrições UML e a ferramenta para tradução de código executável para SystemC, ambas validadas funcionalmente por meio do estudo de caso apresentado (capítulo 4). A metodologia proposta (capítulo 3) teve como fator principal de motivação a necessidade de diminuição no tempo gasto durante as fases de concepção e validação do projeto. O desenvolvimento do plug-in UML-SystemC foi motivado, além da importância da documentação e organização das informações, pela necessidade de criação de uma ferramenta que desse suporte ao projetista desde a fase de concepção ao primeiro modelo executável do projeto. Não menos importante dos que os fatores citados é o fato dela ter sido desenvolvida a partir de um software livre e de código aberto, o que permitirá o seu aprimoramento por meio do auxilio da comunidade, podendo até surgir uma versão livre para outros sistemas 78

93 operacionais disponíveis. O autor, por meio da experiência adquirida como monitor da linguagem SystemC no Laboratório de Sistemas Computacionais Integrados (LABSCI) do CPDEE, afirma que existe uma grande dificuldade por parte dos novos projetistas de SoC em desenvolver especificações executáveis para novos projetos. A maioria parte diretamente para programação, sem qualquer tipo de documentação e/ou esboço do que se pretende implementar. Freqüentemente refazem o mesmo trabalho várias vezes até conseguir resultados na simulação, isso quando realmente conseguem. Embora o trabalho não apresente resultados com fins comparativos, o objetivo principal, de diminuição no tempo gasto até a primeira especificação executável foi alcançado. A ferramenta que foi desenvolvida, além de diminuir o tempo de desperdiçado por um projetista de SoC s na programação do código, diminui também o tempo gasto no aprendizado da linguagem. A geração de código automatizado diminui os riscos de erros de sintaxe na compilação do código gerado. Pode-se dizer também que a metodologia proposta obriga o projetista a trabalhar no nível mais alto de abstração suportado pela linguagem, bem acima do RTL, facilitando a implementação e conseqüentemente diminuindo mais uma vez o tempo de programação. As limitações da ferramenta foram os fatores principais de motivação para a listagem de trabalhos futuros abaixo: Avaliação da metodologia proposta em um número maior de projetos relacionados ao desenvolvimento de SoC ; Avaliação e comparação do desempenho da ferramenta em diferentes tipos de projetos de SoC ; Acrescentar novos recursos à ferramenta: (i) automatizar o processo de interconexão entre os módulos dentro de um arquivo main.cpp ; (ii) permitir a descrição comportamental 79

94 dos módulos; (iii) permitir que a simulação SystemC seja iniciada no próprio Umbrello; (iv) automatizar o processo de geração de vetores de teste; (v) utilizar o diagrama de transição de estados para tentar abstrair a funcionalidade dos processos; Como contribuição final, podemos pensar ainda em uma ferramenta capaz de gerar descrições RTL sintetizáveis diretamente para FPGA partindo de uma modelagem em alto nível. Porém, o contexto de projeto de hardware ainda precisa estar bem definido em uma ferramenta de modelagem visual que tenha robustez suficiente para representar toda e qualquer estrutura e/ou comunicação entre hardware e software de forma transparente para o projetista. 80

95 Referências Bibliográficas [1] OMG Architecture Board. Model Driven Architecture (MDA). Technical Report ormsc/ , OMG, (2001). [2] Arnout, G. Eda moving up, again! 6th European SystemC Users Group (2002). [3] Bhasker, J. A SystemC Primer. Star Galaxy Publishing, [4] Booch, G. Object-Oriented Analysis and Design with Applications (3rd Edition). Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, [5] Dumoulin, C., Boulet, P., Dekeyser, J., and Marquet, P. Mda for soc design, intensive signal processing experiment. Forum on Design Languages (FDL 03), Frankfurt am Main, Germany (2003). [6] Dumoulin, C., Boulet, P., Dekeyser, J., and Marquet, P. Uml 2.0 structure diagram for intensive signal processing application specication. Tech. rep., INRIA, March Research Report RR [7] Edwards, S., Lavagno, L., Lee, E. A., and Vincentelli, A. S. Design of embedded systems: Formal models, validation and synthesis. Proceedings of the IEEE (1997), pages [8] Gajski, D. D., and Kuhn, R. Guest editor introduction: New vlsi-tools. IEEE Computer (December 1983). 81

96 [9] Grötker, T., Liao, S., Martin, G., and Swan, S. System Design with SystemC. Kluwer Academic Publishers, [10] Hammond, L., Nayfeh, B. A., and Olukotun, K. A single-chip multiprocessor. IEEE Computer (September 1997), pages [11] Harel, D., and Naamad, A. The statemate semantics of statecharts. ACM Trans. Softw. Eng. Methodol. 5, 4 (1996), [12] Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, [13] Jerraya, A. A., Svarstad, K., Ben-Fredj, N., and Nicolescu, G. A higher level system communication model for object-oriented specification and design of embedded systems. In: Conference on Asia South Pacific Design Automation Conference - ASPDAC (2001), [14] Lavagno, L., Martin, G., and Selic, B. UML for Real: Design Embedded Real- Time Systems. Kluwer Academic Publishers, Norwell, MA, [15] Micheli, G. D., and Benini, L. Network on chips: A new soc paradigm. IEEE Computer vol (2002), pages [16] Miller, J., and Mukerji, J. (editors). MDA Guide (Draft Version 0.2) - Captured at (2003). [17] Moreno, E. I., Rodolfo, T. A., and Calazans, N. L. V. Modelagem e descrição de socs em diferentes níveis de abstração. In: X WORKSHOP IBERCHIP - Cartagena 1 (2004),

97 [18] Nguyen, K. D., Sun, Z., Thiagarajan, P. S., and Wong, W. Model-driven soc design via executable uml to systemc. Real-Time Systems Symposium. Proceedings. 25th IEEE International (December 2004), [19] Patt, Y. N., Patel, S. J., Evers, M., Friendly, D. H., and Stark, J. One billion transistors, one uniprocessors, one chip. IEEE Computer (September 1997), pages [20] Rajsuman, R. System on a Chip Design and Test, 1st ed. Artech House, Inc Norwood, MA, USA, [21] Rauscher, T. G. Time to market problems - the organiza-tion is the real cause. Proceedings of the IEEE Interna-tional Engineering Management Conference (1994), pages [22] Riccobene, E., Rosti, A., and Scandurra, P. Improving soc design flow by means of mda and uml profiles. 3rd Workshop on Software Model Engineering (WiSME)@UML (October 2004). [23] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. Object-oriented modeling and design. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, [24] Schaller, R. R. Moore s law: past, present and future. IEEE Spectrum vol (1997), pages [25] SIA. International techology roadmap for semiconductors. World Semiconductor Council, Edition 1999, Captured at (1999). (Semiconductor Industry Association). 83

98 [26] Synopsys. Cocentric system studio enables verification at multiple levels of abstraction with systemc. Captured at studio/cocentric studi wp.pdf (January 2002). [27] Yu, A. The future of microprocessors: Intel s head of microprocessor products looks 10 years ahead to IEEE MICRO (1996). [28] Zhu, Q., Matsuda, A., Kuwamura, S., Nakata, T., and Shoji, M. An object-oriented design process for system-on-chip using uml. 15th International Symposium on System Synthesis (ISSS), Kyoto, Japan (2002), pages

99 Apêndice A Anexos A.1 Código Esqueleto Código Fonte A.1: Código Esqueleto - Gerador de Caracteres 1 #ifndef GERADOR DE CARACTERES H 2 #define GERADOR DE CARACTERES H 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Gerador de Caracteres ) { 6 s c f i f o i n <T> ASCII ; 7 s c f i f o o u t <T> address ; void p r o c e s s ( ) { // Implemente a f u n c i o n a l i d a d e do processo aqui! } 15 SC CTOR( Gerador de Caracteres ) { SC THREAD( p r o c e s s ) ; } 16 } ; 85

100 17 #endif //GERADOR DE CARACTERES H Código Fonte A.2: Código Esqueleto - Memória 1 #ifndef MEMORIA H 2 #define MEMORIA H 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Memoria ) { 6 s c f i f o i n <T> end ; 7 s c f i f o o u t <T> ASCII ; 8 s c i n t <32> b u f f e r [TAMBUFFER] ; 9 10 void p r o c e s s ( ) { // Implemente a f u n c i o n a l i d a d e do processo aqui! } 15 SC CTOR( Memoria ) { SC THREAD( p r o c e s s ) ; } 16 } ; 17 #endif //MEMORIA H Código Fonte A.3: Código Esqueleto - ROM de Caracteres 1 #ifndef ROM DE CARACTERES H 2 #define ROM DE CARACTERES H 3 #include <systemc. h> 4 5 template <c l a s s T> SC MODULE( ROM de Caracteres ) { 6 s c f i f o i n <T> address ; 7 s c f i f o o u t <sc bv <8> > c h a r a c t e r l i n e ;

101 10 void p r o c e s s ( ) { // Implemente a f u n c i o n a l i d a d e do processo aqui! } 15 SC CTOR( ROM de Caracteres ) { SC THREAD( p r o c e s s ) ; } 16 } ; 17 #endif //ROM DE CARACTERES H A.2 Código Funcional Código Fonte A.4: Código Funcional - Gerador de Caracteres 1 #ifndef GERADOR DE CARACTERES H 2 #define GERADOR DE CARACTERES H 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Gerador de Caracteres ) { 6 7 s c f i f o i n <T> ASCII ; 8 s c f i f o o u t <T> address ; 9 10 void p r o c e s s ( ) { while ( 1 ) { 13 wait (CB CLOCK) ; 14 T ASCII value = ASCII. read ( ) ; 15 T a d d r e s s v a l u e ; 16 for (T s c a n l i n e v a l u e = 0 ; s c a n l i n e v a l u e < 8 ; s c a n l i n e v a l u e++) { 87

102 17 a d d r e s s v a l u e = ASCII value 8 + s c a n l i n e v a l u e ; 18 cout << "tempo = " << sc time stamp ( ) ; 19 cout << " address = " << a d d r e s s v a l u e << endl ; 20 address. w r i t e ( a d d r e s s v a l u e ) ; 21 CG CLOCK. n o t i f y ( ) ; 22 } 23 } } 26 SC CTOR( Gerador de Caracteres ) { SC THREAD( p r o c e s s ) ; } 27 } ; 28 #endif //GERADOR DE CARACTERES H Código Fonte A.5: Código Funcional - Memória 1 #ifndef MEMORIA H 2 #define MEMORIA H 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Memoria ) { 6 s c f i f o i n <T> end ; 7 s c f i f o o u t <T> ASCII ; 8 9 s c i n t <32> b u f f e r [TAMBUFFER] ; void p r o c e s s ( ) { b u f f e r [ 0 ] = 8 5 ; //u 14 b u f f e r [ 1 ] = 7 0 ; // f 15 b u f f e r [ 2 ] = 7 7 ; //m 88

103 16 b u f f e r [ 3 ] = 7 1 ; // g 17 while ( 1 ) { 18 wait (CRT CLOCK) ; 19 T end value = end. read ( ) ; 20 T ASCII value = b u f f e r [ end value ] ; 21 cout << "tempo = " << sc time stamp ( ) ; 22 cout << " end = " << end value << " ASCII = " << ASCII value << endl ; 23 ASCII. w r i t e ( ASCII value ) ; 24 CB CLOCK. n o t i f y ( ) ; 25 } 26 } 27 SC CTOR( Memoria ) { SC THREAD( p r o c e s s ) ; } 28 } ; 29 #endif //MEMORIA H Código Fonte A.6: Código Funcional - ROM de Caracteres 1 #ifndef ROM DE CARACTERES H 2 #define ROM DE CARACTERES H 3 #include <systemc. h> 4 5 #include "8x8. txt" 6 7 template <c l a s s T> SC MODULE( ROM de Caracteres ) { 8 9 s c f i f o i n <T> address ; 10 s c f i f o o u t <sc bv <8> > c h a r a c t e r l i n e ; void p r o c e s s ( ) { while ( 1 ) { 89

104 15 wait (CG CLOCK) ; 16 T a d d r e s s v a l u e = address. read ( ) ; 17 sc bv <8> c h a r a c t e r l i n e v a l u e = c h a r s e t [ a d d r e s s v a l u e ] ; 18 cout << "tempo = " << sc time stamp ( ) ; 19 cout << " character_line = " << c h a r a c t e r l i n e v a l u e << endl ; 20 c h a r a c t e r l i n e. w r i t e ( c h a r a c t e r l i n e v a l u e ) ; 21 CR CLOCK. n o t i f y ( ) ; 22 } 23 } 24 SC CTOR( ROM de Caracteres ) { SC THREAD( p r o c e s s ) ; } 25 } ; 26 #endif //ROM DE CARACTERES H 1 TARGET ARCH = l i n u x Código Fonte A.7: Código Funcional - Makefile 2 3 CC = / usr / l o c a l / gcc295 / bin /g++ 4 OPT = O3 5 DEBUG = g 6 OTHER = Wall 7 CFLAGS = $ (OPT) $ (OTHER) 8 # CFLAGS = $ (DEBUG) $ (OTHER) 9 10 MODULE = Modelo de Referencia 11 SRCS = main. cpp 12 OBJS = $ (SRCS :. cpp=.o ) i n c l u d e. / Makefile. d e f s 90

105 Código Fonte A.8: Código Funcional - Módulo Controlador (envia os endereços a memória) 1 #ifndef CONTROLADOR H 2 #define CONTROLADOR H 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Controlador ) { 6 7 s c f i f o o u t <T> end ; 8 9 void p r o c e s s ( ) { cout << endl ; 12 for (T end value = 0 ; end value < TAMBUFFER; end value++) { 13 end. w r i t e ( end value ) ; 14 CRT CLOCK. n o t i f y ( 2, SC NS) ; 15 } } SC CTOR( Controlador ) { SC THREAD( p r o c e s s ) ; } 20 } ; 21 #endif //CONTROLADOR H Código Fonte A.9: Código Funcional - Gerador de Sinais de Video 1 #ifndef GERADOR DE SINAIS VIDEO H 2 #define GERADOR DE SINAIS VIDEO H 3 #include <systemc. h> 4 5 #include <s t d i o. h> 6 7 template <class T> SC MODULE( G e r a d o r d e S i n a i s V i d e o ) { 91

106 8 9 s c i n <s c b i t > r e f r e s h b i t ; 10 sc out <s c b i t > linha, quadro, enable ; 11 sc out <T> pxline, pxcol ; void p r o c e s s ( ) { s c b i t e n a b l e v a l u e ; 16 s c b i t pxclk, hsynk, vsynk ; 17 wait (DELAY VIDEO) ; while ( 1 ) { vsynk = 0 ; for (T p x l i n e v a l u e = 0 ; p x l i n e v a l u e < NUMLINES 8 ; p x l i n e v a l u e++) { 24 hsynk = 0 ; for (T p x c o l v a l u e = 0 ; p x c o l v a l u e < NUMCOLS 8 ; p x c o l v a l u e++) { 27 pxclk = 0 ; 28 p x l i n e. w r i t e ( p x l i n e v a l u e ) ; 29 pxcol. w r i t e ( p x c o l v a l u e ) ; 30 wait (DELAY PIXEL) ; 31 e n a b l e v a l u e = r e f r e s h b i t. read ( ) ; pxclk = 1 ; 34 wait (DELAY PIXEL) ; enable. w r i t e ( e n a b l e v a l u e ) ; 92

107 37 l i n h a. w r i t e ( hsynk ) ; 38 VSG CLOCK. n o t i f y ( ) ; } 41 hsynk = 1 ; 42 l i n h a. w r i t e ( hsynk ) ; 43 wait (DELAY HSYNK) ; 44 quadro. w r i t e ( vsynk ) ; } 47 vsynk = 1 ; 48 quadro. w r i t e ( vsynk ) ; 49 wait (DELAY VSYNK) ; 50 } 51 } 52 SC CTOR( G e r a d o r d e S i n a i s V i d e o ) { SC THREAD( p r o c e s s ) ; } 53 } ; 54 #endif //GERADOR DE SINAIS VIDEO H Código Fonte A.10: Código Funcional - Buffer de armazenamento e atualização de quadros 1 #ifndef REFRESH MEM H 2 #define REFRESH MEM H 3 #include <systemc. h> 4 5 template <class T> SC MODULE( Refresh Mem ) { 6 7 s c f i f o i n <sc bv <8> > c h a r a c t e r l i n e ; 8 9 s c i n <T> pxline, pxcol ; 10 sc out <s c b i t > r e f r e s h b i t ; 11 93

108 12 s c b i t MEM[NUMLINES 8 ] [NUMCOLS 8 ] ; void w r i t e p r o c e s s ( ) { sc bv <8> c h a r a c t e r l i n e v a l u e ; while ( 1 ) { 19 for (T l i n = 0 ; l i n < NUMLINES; l i n ++) { 20 for (T c o l = 0 ; c o l < NUMCOLS; c o l++) { 21 for (T i = 0 ; i < 8 ; i ++) { 22 wait (CR CLOCK) ; 23 c h a r a c t e r l i n e v a l u e = c h a r a c t e r l i n e. read ( ) ; 24 for (T j = 0 ; j < 8 ; j++){ 25 MEM[ l i n 8 + i ] [ c o l 8 + j ] = c h a r a c t e r l i n e v a l u e [ 7 j ] ; 26 cout << "tempo = " << sc time stamp ( ) ; 27 cout << " MEM[" << l i n 8+ i << "][" ; 28 cout << c o l 8+ j << " ] = " ; 29 cout << MEM[ l i n 8+ i ] [ c o l 8+ j ] << endl ; 30 } 31 } 32 } 94

109 33 } 34 } 35 } void r e a d p r o c e s s ( ) { wait( 3+DELAY VIDEO) ; while ( 1 ) { 42 wait (DELAY READ) ; 43 T p x l i n e v a l u e = p x l i n e. read ( ) ; 44 T p x c o l v a l u e = pxcol. read ( ) ; 45 s c b i t r e f r e s h b i t v a l u e = MEM[ p x l i n e v a l u e ] [ p x c o l v a l u e ] ; 46 r e f r e s h b i t. w r i t e ( r e f r e s h b i t v a l u e ) ; 47 } 48 } SC CTOR( Refresh Mem ) { SC THREAD( w r i t e p r o c e s s ) ; 53 SC THREAD( r e a d p r o c e s s ) ; } 56 } ; 57 #endif //REFRESH MEM H Código Fonte A.11: Código Funcional - Simulador de Video 1 #ifndef SIMULADOR VIDEO H 2 #define SIMULADOR VIDEO H 3 #include <systemc. h> 95

110 4 5 // B i b l i o t e c a padrao para entrada e s a i d a 6 #include <s t d i o. h> 7 8 template <class T> SC MODULE( Simulador Video ) { 9 10 s c i n <s c b i t > e nable value, hsync, vsync ; void p r o c e s s ( ) { s c b i t enable px ; 15 s c b i t muda linha, muda quadro ; muda linha = 0 ; 18 muda quadro = 0 ; while ( 1 ) { while ( muda quadro == 0) { while ( muda linha == 0) { 25 wait (VSG CLOCK) ; 26 enable px = e n a b l e v a l u e. read ( ) ; 27 muda linha = hsync. read ( ) ; i f ( enable px == 0) 30 cout << "-" ; 31 else i f ( enable px == 1) 32 cout << "W" ; 33 } 34 96

111 35 cout << endl ; 36 muda linha = hsync. read ( ) ; 37 muda linha = 0 ; 38 muda quadro = vsync. read ( ) ; 39 } cout << "Novo refresh!" << endl ; 42 muda quadro = 0 ; 43 } 44 } 45 SC CTOR( Simulador Video ) { SC THREAD( p r o c e s s ) ; } 46 } ; 47 #endif //SIMULADOR VIDEO H Código Fonte A.12: Código Funcional - Programa Principal ( Main ) 1 / / 2 / DEFINICOES / 3 / / 4 #define TEMPO SIMUL , SC NS 5 #define DELAY PIXEL 2, SC NS 6 #define DELAY READ 2 DELAY PIXEL 7 #define DELAY VIDEO 1 0 0, SC NS 8 #define DELAY HSYNK 2 0, SC NS 9 #define DELAY VSYNK 1 0, SC NS / / 12 / BIBLIOTECAS / 13 / / 14 #include <systemc. h> / Modulos do Controlador / 97

112 17 #include " controlador.h" 18 #include " memoria.h" 19 #include " gerador_de_caracteres.h" 20 #include " rom_de_caracteres.h" 21 #include " refresh_mem.h" 22 #include " gerador_de_sinais_video.h" #include " simulador_video.h" // Simulador / / 27 / CONSTANTES / 28 / / 29 const int TAMBUFFER = 4 ; // tamanho do b u f f e r de c a r a c t e r e s 30 const int NUMLINES = 4 ; // numero de l i n h a s do d i s p l a y 31 const int NUMCOLS = 8 ; // numero de colunas do d i s p l a y 32 / / // V a r i a v e i s g l o b a i s e ventos 35 s c e v e n t CRT CLOCK; 36 s c e v e n t CB CLOCK; 37 s c e v e n t CG CLOCK; 38 s c e v e n t CR CLOCK; 39 s c e v e n t VSG CLOCK; int sc main ( int argc, char agv [ ] ) 42 { // I n s t a n c i a s dos Modulos 45 Controlador<int> Controlador ( "Controlador" ) ; 46 Memoria<int> Memoria ( " Memoria" ) ; 47 Gerador de Caracteres <int> Gerador de Caracteres ( " 98

113 Gerador_de_Caracteres" ) ; 48 ROM de Caracteres<int> ROM de Caracteres ( " ROM_de_Caracteres" ) ; 49 Refresh Mem<int> Refresh Mem ( " Refresh_Mem" ) ; 50 Gerador de Sinais Video <int> G e r a d o r d e S i n a i s V i d e o ( " Gerador_de_Sinais_Video" ) ; 51 Simulador Video<int> Simulador Video ( "Simulador_Video" ) ; // I n t e r f a c e s 54 s c f i f o <int> END( "END", 1) ; 55 s c f i f o <int> ASCII ( "ASCII", 1) ; 56 s c f i f o <int> ADDRESS( "ADDRESS", 1) ; 57 s c f i f o <sc bv <8> > CHARACTER LINE( "CHARACTER_LINE", 1) ; // S i n a i s de c o n t r o l e 60 s c s i g n a l <int> PXLINE; 61 s c s i g n a l <int> PXCOL; 62 s c s i g n a l <s c b i t > REFRESH BIT ; 63 s c s i g n a l <s c b i t > ENABLE PX; 64 s c s i g n a l <s c b i t > HSYNC; 65 s c s i g n a l <s c b i t > VSYNC; // Conexao dos Modulos 69 Controlador. end (END) ; 70 Memoria. end (END) ; 71 Memoria. ASCII ( ASCII ) ; 72 Gerador de Caracteres. ASCII ( ASCII ) ; 73 Gerador de Caracteres. address (ADDRESS) ; 74 ROM de Caracteres. address (ADDRESS) ; 75 ROM de Caracteres. c h a r a c t e r l i n e (CHARACTER LINE) ; 76 Refresh Mem. c h a r a c t e r l i n e (CHARACTER LINE) ; 99

114 77 G e r a d o r d e S i n a i s V i d e o. p x l i n e (PXLINE) ; 78 Refresh Mem. p x l i n e (PXLINE) ; 79 G e r a d o r d e S i n a i s V i d e o. pxcol (PXCOL) ; 80 Refresh Mem. pxcol (PXCOL) ; 81 Refresh Mem. r e f r e s h b i t (REFRESH BIT) ; 82 G e r a d o r d e S i n a i s V i d e o. r e f r e s h b i t (REFRESH BIT) ; 83 G e r a d o r d e S i n a i s V i d e o. enable (ENABLE PX) ; 84 G e r a d o r d e S i n a i s V i d e o. l i n h a (HSYNC) ; 85 G e r a d o r d e S i n a i s V i d e o. quadro (VSYNC) ; 86 Simulador Video. e n a b l e v a l u e (ENABLE PX) ; 87 Simulador Video. hsync (HSYNC) ; 88 Simulador Video. vsync (VSYNC) ; // Criacao do arquivo. vcd s c t r a c e f i l e t f i l e = s c c r e a t e v c d t r a c e f i l e ( " Modelo_de_Referencia" ) ; 93 // s c t r a c e ( t f i l e, END, Endereco ) ; 94 // s c t r a c e ( t f i l e, ASCII, ASCII ) ; 95 // s c t r a c e ( t f i l e, ADDRESS, Address ) ; 96 // s c t r a c e ( t f i l e, CHARACTER LINE, Linha de Caracteres ) ; 97 // s c t r a c e ( t f i l e, ENABLE PX, ENABLE PX ) ; 98 // s c t r a c e ( t f i l e, REFRESH BIT, REFRESH BIT ) ; 99 s c t r a c e ( t f i l e, PXLINE, "PXLINE" ) ; 100 s c t r a c e ( t f i l e, PXCOL, "PXCOL" ) ; 101 s c t r a c e ( t f i l e, HSYNC, "HSYNC" ) ; 102 s c t r a c e ( t f i l e, VSYNC, "VSYNC" ) ; // I n i c i a a simulacao 105 s c s t a r t (TEMPO SIMUL) ;

115 107 cout << endl ; // Fecha arquivo. vcd / 110 s c c l o s e v c d t r a c e f i l e ( t f i l e ) ; return 0 ; 113 } 101

116 A.3 Diagrama de Classes - Todos os módulos Figura A.1: Diagrama de Classes Completo e Funcional A.4 Desenvolvimento do plug-in SystemC Abaixo estão descritas as informações e detalhes de implementação do plug-in, gerador de código SystemC, para o software Umbrello UML Modeler desenvolvido neste trabalho. O sistema operacional utilizado foi o Linux Fedora Core 2 e a versão do software Umbrello foi a para Linux. 102