ipProcess: um processo para desenvolvimento de IP-Cores com implementação em FPGA

Texto

(1)Pós-Graduação em Ciência da Computação. “ipPROCESS: UM PROCESSO PARA DESENVOLVIMENTO DE IP-CORES COM IMPLEMENTAÇÃO EM FPGA” Por. MARÍLIA SOUTO MAIOR DE LIMA Dissertação de Mestrado. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, AGOSTO/2005.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. MARÍLIA SOUTO MAIOR DE LIMA. “ipPROCESS: Um processo para desenvolvimento de IPcores com implementação em FPGA". ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.. ORIENTADOR(A): EDNA NATIVIDADE DA SILVA BARROS. RECIFE, AGOSTO/2005.

(3) Lima, Marília Souto Maior de “ipProcess: um processo para desenvolvimento de IP-Cores com implementação em FPGA” / Marília Souto Maior de Lima. – Recife: O autor, 2005. xiv, 99 folhas: il., fig., tab. Dissertação (mestrado) – Federal de Pernambuco. CIN. Computação, 2005.. Universidade Ciência da. Inclui bibliografia e apêndices. 1. Microeletrônica. 2. Engenharia de software – Processo de desenvolvimento. 3. Modelagem – Linguagem SPEM ((Software Process Engineering Metamodel). I. Título. 621.381. CDD (22.ed.). MEI2007-044.

(4) AGRADECIMENTOS. Meu agradecimento especial a Marcelo Clemente pelo apoio e incentivo em todos os momentos desta caminhada. A professora Edna Barros, pela orienta¸cão, pela credibilidade no meu trabalho, pelas cr´ıticas e sugestões valiosas, e pela paciência nos momentos dif´ıceis. A equipe do projeto BRAZIL-IP, pela fundamental contribui¸cão dada durante o desenvolvimento deste trabalho. Gostaria de agradecer especialmente a: André Aziz, Bruno Piedade, Diogo Alves, Fernando Bione, Francielle Santos, Patr´ıcia Lira, Tiago Lins e Vitor Schwambach. Sem vocês esse trabalho não teria sido poss´ıvel. Por fim, gostaria de agradecer a todos os meus amigos e familiares que de alguma forma fizeram parte desta conquista.. iii.

(5) Cuide de seus pensamentos, porque se tornam palavras; escolha suas palavras, porque se tornam a¸ c˜ oes; entenda suas a¸ co ˜es, porque se tornam h´ abitos; estude seus h´ abitos, porque se tornam seu car´ ater; desenvolva seu car´ ater, porque ele se torna o seu destino. —BOB MARLEY.

(6) RESUMO. A demanda cada vez maior por produtos eletrônicos e a crescente capacidade de integra¸cão dos chips direcionaram a metodologia de projeto de sistemas embarcados para sua completa integra¸cão em um u ´ nico chip (System-on-Chip, ou SoC). Essa metodologia baseia-se cada vez mais em componentes previamente projetados e verificados (IP-core) como uma alternativa de disponibilizar os sistemas dentro dos prazos esperados, sem perder o time-to-market do mercado consumidor de eletrônicos. Neste trabalho, é proposto um processo de desenvolvimento de IP-cores baseado em técnicas de engenharia de software chamado ipPROCESS, como um mecanismo de facilitar e promover o desenvolvimento de IP-cores de alta qualidade. Tendo o foco na cria¸cão de componentes de qualidade, o ipPROCESS foi definido com base em técnicas de verifica¸cão funcional, de modelagem visual da arquitetura, de interface de comunica¸cão e de documenta¸cão seguindo os padrões da ind´ ustria. O processo foi descrito utilizando o meta-modelo UML denominado SPEM com o objetivo de facilitar e acelerar o seu entendimento, assim como permitir altera¸cões futuras e facilitar o gerenciamento de projetos baseados no processo proposto. Palavras-chave: IP-core, Soc, Processos, UML-RT, Verifica¸cão Funcional, Prototipa¸cão em FPGA, Interface OCP-IP.. v.

(7) ABSTRACT. The silicon capacity continues to increase along Moore’s Law allowing us to build comples chips consisting of hundreds of millions transistors. Furthermore, there are a nwe consumer market including more information appliances ins small, mobile and ergonomic devices that provide information, entertainment and communications capabilities to consumer electronics, industrial automation and medical markets. These devices require complex electronic design and system integration, which must be delivered in the short time-to-market frames of consumer electronics. The integration technology supports nowadays the integration of a complete system in silicon (System-on-chip - SoC) and design methodologies are more and more based on pre-defined and pre-designed Intellectual Property blocks (IP-core). The reusing of IP-cores has been an alternative to reduce the increasing gap between design productivity and chip complexity of emerging SoC designs. To keep these efforts in check, a design methodology that favors reuse and early error detection is essential. Both reuse and error detection imply that the design activity must be defined rigorously, so that all phases are clearly identified and appropriate checks are enforced. The design of an IP-core involves different ’area of concerns’ like specification, implementation by using hardware description language (HDL), simulation, functional verification, synthesis, prototyping and intellectual property protection. All these design aspects demand from designer teams various abilities in distinct expertise, as well as mechanisms to support teamwork. In order to cope with some challenges of IP-core design, we propose, in this work, a development process, called ipPROCESS, for Soft IPs with implementation in FPGA. The ipPROCESS approach defines the IP-core design task as a set of activities, where each activity determines ’what should be done, when and for whom’, i.e. the process assigns activities and reposibilities to the right person at a right moment of the design lifecycle. The ipPROCESS modeling is based on the UML metamodel called SPEM. Keywords:. IP-core, Soc, Process, UML-RT, Functional Verification, FPGA Prototy-. ping, OCP-IP Interface.. vi.

(8) ´ SUMARIO. Cap´ıtulo 1—Introdu¸c˜ ao 1.1 1.2 1.3. 1. Proposta do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 2—Processos de Desenvolvimento: Estado da Arte 2.1. 2.2. 2.3. 6. Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 2.1.1 2.1.2. Rational Unified Process (RUP) . . . . . . . . . . . . . . . . . . . eXtreme Programming (XP) . . . . . . . . . . . . . . . . . . . . .. 6 9. Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Reuse Methodology Manual (RMM) . . . . . . . . . . . . . . . . 2.2.2 Virtual Socket Interface Alliance (VSIA) . . . . . . . . . . . . . .. 12 12 14. 2.2.3. Modelagem UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3.1 Gera¸cão de Código SystemC a partir de Modelos UML .. 15 15. 2.2.3.2. SystemC e UML 2.0: Novas Metodologias de Projeto . . 2.2.3.2.1 STMicroelectronics - . . . . . . . . . . . . . . . 2.2.3.2.2 Fujitsu - . . . . . . . . . . . . . . . . . . . . . .. 17 17 17. 2.2.3.2.3 SysML Partners - . . . . . . . . . . . . . . . . . Considera¸cões Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19 19. Cap´ıtulo 3—Desenvolvimento de IP-core: Conceitos B´ asicos 3.1. 3 4 5. 21. Conceitos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21. 3.1.1 3.1.2 3.1.3. Classifica¸cão de IP-core . . . . . . . . . . . . . . . . . . . . . . . Taxonomia de Desenvolvimento: N´ıveis e Dom´ınios de Descri¸cão . Verifica¸cão Funcional . . . . . . . . . . . . . . . . . . . . . . . . .. 21 22 24. 3.1.4. 3.1.3.1 Estratégia de Verifica¸cão Funcional do BRAZIL IP . . . Descri¸cão de FPGA . . . . . . . . . . . . . . . . . . . . . . . . . .. 25 27. vii.

(9) viii. ´ SUMARIO. 3.2. 3.3. Contextualiza¸cão do Ciclo de Vida de Desenvolvimento de IP-cores . . .. 27. 3.2.1 3.2.2. Fase Define Key Features . . . . . . . . . . . . . . . . . . . . . . Fase Planning and Specification . . . . . . . . . . . . . . . . . . . 3.2.2.1 Functional Specification . . . . . . . . . . . . . . . . . .. 27 28 28. 3.2.2.2 3.2.2.3. Verification Specification . . . . . . . . . . . . . . . . . . Packaging Specification . . . . . . . . . . . . . . . . . .. 28 28. 3.2.3. 3.2.2.4 Development Plan . . . . . . . . . . . . . . . . . . . . . 3.2.2.5 Executable Specification . . . . . . . . . . . . . . . . . . Fase Design and Verification . . . . . . . . . . . . . . . . . . . . .. 28 29 29. 3.2.4 3.2.5. Fase Productization . . . . . . . . . . . . . . . . . . . . . . . . . . Fase Alpha Test and Release . . . . . . . . . . . . . . . . . . . . .. 31 32. Considera¸cões Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. Cap´ıtulo 4—ipPROCESS 4.1 4.2. Etapas de Defini¸cão do ipPROCESS . . . . . . . . . . . . . . . . . . . . Modelagem Conceitual do ipPROCESS . . . . . . . . . . . . . . . . . . . 4.2.1 As Fases do ipPROCESS . . . . . . . . . . . . . . . . . . . . . . . 4.2.1.1 4.2.1.2. 33 35 36. Primeira Fase: Conception . . . . . . . . . . . . . . . . . Segunda Fase: Architecture . . . . . . . . . . . . . . . .. 37 38. 4.2.1.3 Terceira Fase: RTL Design . . . . . . . . . . . . . . . . ´ 4.2.1.4 Quarta e Ultima Fase: Physical Prototying . . . . . . . . As Disciplinas do ipPROCESS . . . . . . . . . . . . . . . . . . . .. 38 39 39. 4.2.2.1 4.2.2.2 4.2.2.3. Disciplina Requirements . . . . . . . . . . . . . . . . . . Disciplina Analysis & Design . . . . . . . . . . . . . . . Disciplina RTL Implementation . . . . . . . . . . . . . .. 41 46 50. 4.2.2.4 4.2.2.5. Disciplina Functional Verification . . . . . . . . . . . . . Disciplina FPGA Prototyping . . . . . . . . . . . . . . .. 55 62. Distribui¸cão das Atividades por Fase . . . . . . . . . . . . . . . . . . . . Considera¸cões Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67 67. 4.2.2. 4.3 4.4. 33. Cap´ıtulo 5—Estudo de Caso: Aplicando o ipPROCESS no Desenvolvimento de um IP-core 70 5.1. Descri¸cão do IP-core: Microcontrolador 8051 . . . . . . . . . . . . . . . .. 70. 5.2. Organiza¸cão do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Aloca¸cão de Papéis . . . . . . . . . . . . . . . . . . . . . . . . . .. 71 71.

(10) ix. ´ SUMARIO. 5.2.2 5.3. Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . .. 72. Aplicando o ipPROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Fase Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1.1 Defini¸cão dos Requisitos . . . . . . . . . . . . . . . . . .. 73 73 73. 5.3.2. 5.3.1.1.1 5.3.1.1.2. Memória . . . . . . . . . . . . . . . . . . . . . . Fun¸cão de Timer . . . . . . . . . . . . . . . . .. 74 74. 5.3.1.1.3 5.3.1.1.4 5.3.1.1.5. Interface Serial . . . . . . . . . . . . . . . . . . Fun¸cão de Interrup¸cão . . . . . . . . . . . . . . Porta Paralela de Entrada/Sa´ıda . . . . . . . .. 74 75 75. 5.3.1.1.6 5.3.1.1.7. Unidade Central de Processamento . . . . . . . Interface Externa: Padrão OCP-IP . . . . . . .. 75 75. 5.3.1.1.8 Frequência / Clock / Voltagem . . . . . . . . . 5.3.1.2 Descri¸cão Inicial dos Casos de Uso . . . . . . . . . . . . Fase Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .. 76 76 77. 5.3.2.1 5.3.2.2. 5.4 5.5 5.6. Defini¸cão da Arquitetura e Detalhamento dos Casos de Uso 77 Planos de Integra¸cão e Verifica¸cão Funcional . . . . . . . 78. 5.3.3. Fase RTL Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3.1 Modelo de Simula¸cão . . . . . . . . . . . . . . . . . . . . 5.3.3.2 Componentes de Verifica¸cão (Testbench) . . . . . . . . .. 81 81 83. 5.3.4. Fase Physical Prototyping . . . . . . . . . . . . . . . . . . . . . . 5.3.4.1 Protótipo do 8051 em FPGA . . . . . . . . . . . . . . .. 83 84. Incorporando o Microcontrolador 8051 a um Projeto de SoC . . . . . . . Li¸cões Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Considera¸cões Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85 87 88. Cap´ıtulo 6—Conclus˜ oes. 90. 6.1. Principais Contribui¸cões . . . . . . . . . . . . . . . . . . . . . . . . . . .. 90. 6.2 6.3. Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 91 92. Apˆ endice A—O Meta Modelo SPEM A.1 Modelo Conceitual do SPEM. 97 . . . . . . . . . . . . . . . . . . . . . . . .. Apˆ endice B—Documento de Requisitos. 97 100.

(11) ´ SUMARIO. Apˆ endice C—Plano de Verifica¸c˜ ao Funcional. x 101.

(12) LISTA DE FIGURAS. 1.1. Conceitos de SoC e IP-core [vsi02] . . . . . . . . . . . . . . . . . . . . . .. 2. 1.2. Plataforma Fenix [fen] . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 2.1. Arquitetura Geral do RUP [Kru00] . . . . . . . . . . . . . . . . . . . . .. 7. 2.2 2.3 2.4. Fases de Desenvolvimento de IP-cores segundo o RMM [KB02] . . . . . . Ferramenta RT2SystemC: Processo de Tradu¸cão [W+ 04] . . . . . . . . . Nota¸cão UML para os conceitos de SystemC [RS+ 05] . . . . . . . . . . .. 14 16 18. 2.5. Fujitsu: Incorporando UML ao seu processo de Projetos de SoC [Z+ 05] .. 19. 3.1. Y-Chart: Dom´ınios e N´ıveis de Descri¸cão de Funcionalidade [MLD92] . .. 22. 3.2 3.3 3.4. Y-Chart: Transi¸cões Definindo Atividades [MLD92] . . . . . . . . . . . . Intera¸cão entre Testbench e DUV . . . . . . . . . . . . . . . . . . . . . . Estratégia de Verifica¸cão Funcional, Ferramenta VeriSC [SM+ 04] . . . . .. 23 25 26. 3.5. Fase Design and Verification, Etapa 1: Implementa¸cão e teste dos subblocos [KB02] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. 3.6. Fase Design and Verification, Etapa 2: Integra¸cão dos sub-blocos [KB02]. 31. 4.1 4.2. Etapas de Defini¸cão do ipPROCESS . . . . . . . . . . . . . . . . . . . . Fases versus Disciplinas do ipPROCESS . . . . . . . . . . . . . . . . . .. 34 36. 4.3 4.4. Fases do ipPROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diciplinas do ipPROCESS: Diagrama de Pacotes . . . . . . . . . . . . . .. 36 40. 4.5 4.6 4.7. Disciplina Requirements, Diagrama de Pacotes . . . . . . . . . . . . . . . Disciplina Requirements: Fluxo das Atividades . . . . . . . . . . . . . . . Disciplina Analysis & Design, Diagrama de Pacotes . . . . . . . . . . . .. 41 43 46. 4.8 4.9. Disciplina Analysis & Design: Fluxo das Atividades . . . . . . . . . . . . Disciplina RTL Implementation, Diagrama de Pacotes . . . . . . . . . . .. 47 50. 4.10 Disciplina RTL Implementation: Fluxo das Atividades . . . . . . . . . . 4.11 Disciplina Functional Verification, Diagrama de Pacotes . . . . . . . . . . 4.12 Disciplina Functional Verification: Fluxo das Atividades . . . . . . . . .. 52 55 57. 4.13 Disciplina FPGA Prototyping, Diagrama de Pacotes . . . . . . . . . . . .. 62. xi.

(13) LISTA DE FIGURAS. xii. 4.14 Disciplina FPGA Prototyping: Fluxo das Atividades . . . . . . . . . . . .. 64. 4.15 Distribui¸cão das Atividades por Fase . . . . . . . . . . . . . . . . . . . . 4.16 Website do ipPROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . .. 68 69. 5.1. Diagrama de Blocos de um Microcontrolador[Mac99] . . . . . . . . . . .. 71. 5.2 5.3. Microcontrolador 8051: Diagrama de Casos de Uso . . . . . . . . . . . . Interface OCP-IP: Diagrama de Classes . . . . . . . . . . . . . . . . . . .. 76 78. 5.4 5.5 5.6. Componente OCP-IP: Diagrama de Classe . . . . . . . . . . . . . . . . . Componente OCP-IP Master: Diagrama de Estado . . . . . . . . . . . . Componente OCP-IP Slave: Diagrama de Estado . . . . . . . . . . . . .. 79 80 80. 5.7 5.8. Microcontrolador 8051: Diagrama de Blocos . . . . . . . . . . . . . . . . Robô Jubinha: integrado o 8051 a um SoC para controle de um robô . .. 82 86. 5.9. Robô Jubinha: IP-cores do SoC . . . . . . . . . . . . . . . . . . . . . . .. 86. A.1 Modelo Conceitual do SPEM [spe02] . . . . . . . . . . . . . . . . . . . .. 97.

(14) LISTA DE TABELAS. 4.1. Detalhamento da Atividade Develop Vision, Disciplina Requirements. . .. 44. 4.2. Detalhamento da Atividade Capture a Common Vocabulary, Disciplina Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detalhamento da Atividade Elicit User Needs, Disciplina Requirements .. 44 45. 4.3 4.4 4.5. Detalhamento da Atividade Define Requirements, Disciplina Requirements Detalhamento da Atividade Architectural Analysis, Disciplina Analysis & Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45 48. 4.6 4.7. Detalhamento da Atividade Use Case Analysis, Disciplina Analysis & Design 48 Detalhamento da Atividade Component Design, Disciplina Analysis & De-. 4.8 4.9. sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Detalhamento da Atividade Use Case Design, Disciplina Analysis & Design 49 Detalhamento da Atividade Plan IP-core Integration, Disciplina RTL Im-. plementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Detalhamento da Atividade Implement Components, Disciplina RTL Im-. 51. plementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Detalhamento da Atividade Implement Test Components, Disciplina RTL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52 53. 4.12 Detalhamento da Atividade Perform Tests, Disciplina RTL Implementation 54 4.13 Detalhamento da Atividade Integrate IP-core, Disciplina RTL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14 Detalhamento da Atividade Plan Functional Verification, Disciplina Functional Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54 58. 4.15 Detalhamento da Atividade Define Test Cases, Disciplina Functional Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 58. 4.16 Detalhamento da Atividade Implement Reference Model, Disciplina Functional Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.17 Detalhamento da Atividade Implement Verification Components, Disci-. 59. plina Functional Verification . . . . . . . . . . . . . . . . . . . . . . . . .. 60. xiii.

(15) xiv. LISTA DE TABELAS 4.18 Detalhamento da Atividade Perform Functional Verification, Disciplina Functional Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19 Detalhamento da Atividade Analyze Verification Failure, Disciplina Functional Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.20 Detalhamento da Atividade Plan FPGA Integration, Disciplina FPGA Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 60 61 63. 4.21 Detalhamento da Atividade Back Annotation, Disciplina FPGA Prototyping 65 4.22 Detalhamento da Atividade Implement FPGA Test Components, Disciplina FPGA Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.23 Detalhamento da Atividade Perform Tests in FPGA, Disciplina FPGA Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 66. 4.24 Detalhamento da Atividade Integrate IP-core in FPGA, Disciplina FPGA Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 66. 5.1. Microcontrolador 8051: Resultados da Disciplina RTL Implementation. .. 82. 5.2 5.3. Microcontrolador 8051: Resultados da Disciplina Functional Verification Microcontrolador 8051: Resultados da Disciplina FPGA Prototyping . . .. 84 85. A.1 Estereótipos do Meta Modelo SPEM . . . . . . . . . . . . . . . . . . . .. 99.

(16) CAPÍTULO 1. ˜ INTRODUC ¸ AO. Um novo mercado de produtos eletrônicos tem surgido em fun¸cão de uma demanda cada vez maior por dispositivos embarcados que sejam pequenos, portáteis e ergonômicos, bem como capazes de fornecer, quase sempre ao mesmo tempo, informa¸cão, entretenimento e comunica¸cão aos seus diferentes consumidores (ind´ ustria automobil´ıstica, área médica, automa¸cão industrial etc). Esses novos dispositivos, com diversas funcionalidades embutidas, possuem caracter´ısticas que demandam um projeto complexo e uma integra¸cão de sistemas, devendo ser disponibilizados em curtos intervalos de tempo aos seus consumidores. Aliado a este novo e exigente mercado consumidor, existe também o fator tecnológico. Atualmente, a evolu¸cão nas técnicas de integra¸cão em sil´ıcio permitem a constru¸cão de chips com centenas de milhares de transistores, permitindo assim a integra¸cão de sistemas complexos em um u ´ nico chip [C+ 99]. Esse crescimento explosivo da capacidade de integra¸cão em sil´ıcio e a demanda por produtos cada vez mais diversificados e complexos provocaram uma mudan¸ca no desenvolvimento de projetos de sistemas embarcados em dire¸cão a um novo paradigma de desenvolvimento denominado System on Chip (SoC), onde todo o sistema embarcado pode agora ser integrado e implementado num u ´ nico chip. Porém a capacidade de integrar rapidamente novos produtos ao mercado consumidor não tem acompanhado o crescente aumento na capacidade de integra¸cão de sistemas complexos em um u ´ nico chip, gerando dessa forma uma gap entre a produtividade das equipes de desenvolvimento e a capacidade de integra¸cão dos chips. Consequentemente, o projeto de um SoC assumiu uma abordagem baseada no reuso de componentes préexistentes e pré-verificados, denominados Intellectual Property Core (IP-core), com o objetivo de reduzir tempo e esfor¸co de projeto. A Figura 1.1 ilustra de forma visual os conceitos de SoC e IP-core. Tipicamente, um SoC possui um ou mais processadores, uma grande quantidade de memória, dispositivos periféricos, co-processadores e canais de entrada/sa´ıda para comunica¸cão (como USB, Bluetooth, Rádio Frequência etc). Para que esta nova tendência de projetos seja poss´ıvel é essencial o desenvolvimento de metodologias que suportem: 1.

(17) 2. ˜ INTRODUC ¸ AO. Figura 1.1 Conceitos de SoC e IP-core [vsi02]. • Promover o reuso de componentes previamente testados. • Estimular práticas de desenvolvimento que promovam a deteçcão de erros nas fases iniciais do projeto. Quanto mais tarde os erros forem detectados, maior será o tempo e o custo necessários para corrig´ı-los [VG02]. Tanto o aspecto de facilitar o reuso quanto a deteçcão prévia de erros implicam na necessidade de atividades bem definidas, de forma que todas as fases do desenvolvimento sejam claramente identificadas [C+ 99]. O projeto em si de um IP-core envolve diferentes áreas de conhecimento, como: especifica¸cão funcional, implementa¸cão através de linguagens de descri¸cão de hardware (HDL), simula¸cão, verifica¸cão funcional, s´ıntese, prototipa¸cão e prote¸cão de propriedade intelectual. Todos esses aspectos de projeto demandam das novas equipes de projetistas habilidades em diferentes áreas, assim como mecanismos que suportem o trabalho em equipe. Dessa forma, uma estratégia para lidar com projetos complexos é divid´ı-lo em vários módulos ou componentes, de maneira que cada módulo venha a ser desenvolvido por equipes distintas. Como consequência, devem existir mecanismos de comunica¸cão corretos e eficientes capazes de integrar as pessoas e coordenar suas atividades a fim de que o projeto seja finalizado com sucesso. Além disso, o projeto de IP-cores possue desafios próprios como: portabilidade, reusabilidade, interfaces de integra¸cão padronizadas,.

(18) 1.1 PROPOSTA DO TRABALHO. 3. documenta¸cão de fácil entendimento e bem definida e facilidades de integra¸cão com os demais componentes de um SoC [KB02]. Dentro desse contexto, foi criado um consórcio entre institui¸cões brasileiras, chamado BRAZIL IP, com o objetivo de formar recurso humano especializado no projeto de IPcores com qualidade e de acordo com os padrões industriais [bra]. Um primeiro projeto deste consórcio foi o Projeto Fenix, cujo propósito principal é definir uma metodologia para projetos de IP-core de forma que os membros das institui¸cões participantes se tornem conscientes de todos os aspectos, ou área de conhecimento, que acompanham o desenvolvimento de um IP-core [fen]. Essa metodologia deveria ser definida considerando a utiliza¸cão de ferramentas profissionais e técnicas modernas de especifica¸cão, verifica¸cão funcional e prototipa¸cão rápida. Como forma de viabilizar a defini¸cão dessa metodologia, o Projeto Fenix tem como meio o desenvolvimento de um estudo de caso real onde o produto final é a cria¸cão de plataforma para o desenvolvimento de aplica¸cões wireless compostas pelos IP-cores ilustrados na Figura 1.2.. Figura 1.2 Plataforma Fenix [fen]. 1.1. PROPOSTA DO TRABALHO. A proposta deste trabalho é definir um processo para o desenvolvimento de IP-cores, chamado ipPROCESS, que tem como objetivo facilitar e direcionar o projeto de IP-cores de alta qualidade, promovendo a deteçcão de erros nas primeiras fases do projeto, bem como o fornecimento de documenta¸cão e interfaces adequadas. Dessa forma, esperamos contribuir no processo de sistemas embarcados implementados como SoC. Num primeiro momento será realizada uma análise de alguns processos de desenvolvimento de software com o objetivo de colher boas práticas quanto a defini¸cão de processos.

(19) 1.2 OBJETIVOS DO TRABALHO. 4. de desenvolvimento. Além do conceito de processo, esta etapa visa levantar aspectos positivos e negativos de cada um desses processos com o intuito de agregar ao ipPROCESS práticas de desenvolvimento que levem à gera¸cão de produtos de qualidade, com poucos erros e interfaces bem definidas. Num segundo momento, foi feito um levantamento sobre o estado da arte no desenvolvimento de IP-core’s cujo objetivo é unir conceitos de processos às práticas de desenvolvimento que promovam a cria¸cão de produtos de qualidade. Baseada nestas análises foi então definida uma nova abordagem de processo de desenvolvimento de IP-core’s com o objetivo de apoiar e orientar a produ¸cão de novos componentes cujo foco é seu reuso em projetos de SoC’s. Os conceitos e a estrutura deste processo foram desta forma baseados nas práticas mais atuais e consolidadas no que se refere a desenvolvimento de componentes de qualidade para serem integrados a projetos de SoC’s. Ao final, o processo proposto foi avaliado quanto a sua aplicabilidade e eficiência a partir de sua utiliza¸cão no projeto de um IP-core desenvolvido no contexto do Projeto Fenix. A partir deste estudo de caso foi poss´ıvel identificar pontos positivos e pontos falhos que precisam ser ajustados e melhorados para atender aos padrões da ind´ ustria. 1.2. OBJETIVOS DO TRABALHO. Nesse sentido, o objetivo deste trabalho é modelar um processo para orientar e basear o desenvolvimento de Ip-core’s, capaz de promover a cria¸cão de componentes de qualidade e que sejam facilmente integráveis a projetos de SoC’s. Como consequência, o ipPROCESS inclui as seguintes caracter´ısticas: • As fases do desenvolvimento são claramente definidas, assim como os marcos a serem atingidos em cada uma delas • As atividades a serem realizadas são bem definidas e distribu´ıdas ao longo das fases • Os papéis e respectivas responsabilidades são bem definidos para cada atividade • O resultado a ser produzido por cada atividade é claro e bem definido • As atividades devem ser suportadas por Templates e Guias • Est´ımulo ao uso de boas práticas de desenvolvimento Dessa forma, as principais contribui¸cões deste trabalho são:.

(20) 1.3 ESTRUTURA DO TRABALHO. 5. • A formaliza¸cão de um processo prático e eficaz para a cria¸cão de IP-core’s, que suporte o projeto de IP-cores de qualidade e que possuam facilidade de integra¸cão. • Disponibilizar um guia de processo que seja genérico o suficiente para atender a diversos dom´ınios de componentes e que contemple necessidades como: interfaces de integra¸cão com outros IP-cores e documenta¸cão que facilite seu reuso. 1.3. ESTRUTURA DO TRABALHO. Os demais cap´ıtulos do trabalho estão estruturados da seguinte maneira: • Cap´ıtulo 2: apresenta uma breve descri¸cão do estado da arte em termos de processos de desenvolvimento e de tendências no desenvolvimento de IP-cores. • Cap´ıtulo 3: apresenta o contexto e introduz os conceitos relacionados ao desenvolvimento de IP-cores’s que estão sendo discutidos e praticados atualmente na ind´ ustria e na academia. • Cap´ıtulo 4: descreve o ipPROCESS, sua estrutura e conceitos. Descreve os fluxos de trabalho em termos de fases e atividades. • Cap´ıtulo 5: relata a experiência da aplica¸cão do ipPROCESS no desenvolvimento de um IP-core do Microcontrolador 8051. • Cap´ıtulo 6: apresenta a conclusão deste trabalho, onde são descritas as principais contribui¸cões e poss´ıveis trabalhos a serem desenvolvidos no futuro..

(21) CAPÍTULO 2. PROCESSOS DE DESENVOLVIMENTO: ESTADO DA ARTE. Este cap´ıtulo tem como objetivo descrever o estado da arte em rela¸cão a processos de desenvolvimento. Além disso, são também apresentados os u ´ ltimos estudos e trabalhos mais especificamente relacionados a atividades do desenvolvimento de IP-cores. A seguir serão apresentados os dois processos de desenvolvimento que serviram como referência para o desenvolvimento deste trabalho. Ambos foram utilizados como referência enquanto processos: conceitos e princ´ıpios a serem definidos para modelar e caracterizar um processo, ou seja ”como modelar um processo”. Maiores detalhes sobre o porquê dessas escolhas estão descritos na se¸cão 4.1. 2.1. ESTADO DA ARTE. 2.1.1. Rational Unified Process (RUP). O Rational Unified Process, ou RUP, é um processo de engenharia de software. Possui uma abordagem baseada em disciplina para atribuir tarefas e responsabilidades dentro de uma organiza¸cão de desenvolvimento. Seu objetivo é garantir a produ¸cão de software de alta qualidade que atenda às necessidades de seus usuários dentro do prazo e or¸camento previstos [Kru00]. A Figura 2.1 apresenta uma visão geral da arquitetura do RUP, enquanto processo, em duas dimensões: • O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo: as fases do desenvolvimento de software. • O eixo vertical representa as disciplinas, as quais agrupam atividades relacionadas entre si. A primeira dimensão representa o aspecto dinâmico do processo, o qual é expresso em termos dos conceitos de : 6.

(22) 7. 2.1 ESTADO DA ARTE. Figura 2.1 Arquitetura Geral do RUP [Kru00]. • Fases (Phases): tempo entre dois marcos importantes do projeto durante o qual um conjunto bem definido de objetivos deve ser atingido, e decisões devem ser tomadas para decidir seguir para próxima fase ou não; • Itera¸cões (Iterations): sequências de atividades que resultam em um subconjunto do produto final; e • Marcos (Milestone): pontos que determinam a finaliza¸cão de um subconjunto de produtos. A segunda dimensão representa os aspectos estáticos do processo: como o mesmo é descrito em termos de: • Disciplinas (Disciplines): cole¸cão de atividades relacionadas a uma determinda área do conhecimento; • Artefatos (Artifacts): informa¸cão utilizada ou produzida durante o desenvolvimento de software, podendo ser por exemplo um modelo, uma descri¸cão ou código. • Papéis (Roles): defni¸cão de um comportamento e responsabilidades atribu´ıdas a um indiv´ıduo em particular; e.

(23) 2.1 ESTADO DA ARTE. 8. • Atividades (Activities): unidades de trabalho realizada por um dado papel. O gráfico da Figura 2.1 mostra como a ênfase sobre as atividades é feita no decorrer do tempo. Por exemplo, nas primeiras itera¸cões gasta-se mais tempo em requisitos, enquanto que nas u ´ ltimas itera¸cões mais tempo é dedicado à implementa¸cão. Do ponto de visto gerencial o ciclo de vida do desenvolvimento de software definido pelo RUP é composto por quatro fases em sequência, as quais estão brevemente descritas a seguir: • Inception: primeira fase definida pelo RUP e tem como principais atividades formular o escopo do projeto, planejamento do projeto, análise dos riscos, custos e prazos de desenvolvimento. Também envolve atividades de preparo do ambiente como sele¸cão de ferramentas a serem utilizadas no projeto. O marco desta fase consiste na avalia¸cão da viabilidade do projeto. • Elaboration: tem como objetivo defnir uma primeira arquitetura para o sistema e envolve atividades como detalhamento dos requisitos, detalhamento dos casos de uso1 mais cr´ıticos e elabora¸cão do plano do projeto. Tem como marco o desenvolvimento de um prótipo executável da arquitetura do sistema para validar os casos de uso mais cr´ıticos. • Construction: tem como objetivo detalhar as demais funcionalidades do sistema e complementar o desenvolvimento do sistema. As atividades essenciais envolvem gerenciamento dos recursos e controle de opera¸cões com o objetivo de reduzir custos e respeitar os prazos, implementa¸cão dos demais componentes e teste. Tem como marco a constru¸cão da primeira versão do sistema. • Transition: o foco desta fase é garantir aos usuários um versão estável do produto final. Envolve atividades de implanta¸cão do sistema, elabora¸cão de material para treinamento e consulta, colher feedback dos usuários e realizar os ajustes necessários. Tem como marco a entrega do produto final. O RUP foi definido de forma a valorizar as melhores práticas comumente utilizadas na ind´ ustria por organiza¸cões de sucesso, como as listadas a seguir: • Gerência de Requisitos: abordagem sistemática para encontrar, documentar, organizar e encontrar dependência na mudan¸cas de requisitos. 1. Caso de Uso: funcionalidade que pode ser executada.

(24) 2.1 ESTADO DA ARTE. 9. • Desenvolvimento Iterativo: ciclo de vida do desenvolvimento baseado em várias itera¸cões o que permite que os erros de projeto sejam encontrados antes do produto final estar conclu´ıdo. • Desenvolvimento de Arquitetura Baseada em Componentes: defini¸cão ou reutiliza¸cão de componentes autocontidos e com interfaces bem definidas com o objetivo de diminuir a complexidade e o tamanho da solu¸cão final. • Modelagem Visual: utiliza¸cão de nota¸cão gráfica e textual , rica semanticamente, capaz de capturar aspectos de projeto de software como por exemplo UML; tendo como objetivo aumentar a eficiência da comunica¸cão dentro da equipe e prover uma base não amb´ıgua para o desenvolvimento. • Verifica¸cão Cont´ınua da Qualidade: verificar a qualidade dos artefatos produzidos ao final de cada fase de forma a eliminar defeitos o quanto antes. • Gerência de Mudan¸ca: controle das mudan¸cas de requisitos e manuten¸cão da integridade dos artefatos produzidos no projeto. O RUP defende a estratégia de atacar as funcionalidades de maior risco durante o in´ıcio do projeto, na fase Inception, e aposta na gerência de projeto como uma forma de garantir a entrega de um produto de alta qualidade, de forma que os objetivos dos usuários finais sejam alcan¸cados tanto em termos de prazo quanto de or¸camento. Como o RUP é um framework de desenvolvimento genérico, o mesmo pode ser ajustado ao desenvolvimento de diferentes produtos de software em diferentes tamanhos e áreas de aplica¸cão [Kru00]. Este fato é facilitado pelo fato do mesmo estar definido em torno de três conceitos básicos: papéis, atividades e ciclo de vida do desenvolvimento organizado em fases. 2.1.2. eXtreme Programming (XP). A metodologia denominada eXtreme Programming, ou XP, foi projetada com o objetivo de entregar produtos de software como desejado e quando esperado pelo cliente, focando sempre na satisfa¸cão do mesmo [Bec99, xp]. XP encoraja os seus desenvolvedores a responder com seguran¸ca à mudan¸cas de requisitos por parte do cliente, mesmo que isso aconte¸ca no final do ciclo de vida do desenvolvimento do projeto. XP enfatiza o trabalho em equipe, onde todos as pessoas da equipe devem estar engajados em entregar softwares de qualidade..

(25) 2.1 ESTADO DA ARTE. 10. Seguindo este propósito, a metodologia XP propõem-se a a aperfei¸coar o desenvolvimento de software através de quatro valores básicos: • Comunica¸cão: baseado no fato de grandes problemas no desenvolvimento acontecerem por falha de comunica¸cão entre as partes envolvidas no projeto, XP dissemina a cultura da comunica¸cão oral como forma de fortalecer a intera¸cão entre as pessoas. • Simplicidade: defende o fato de projetar o sistema da maneira mais simples poss´ıvel, desde que atenda aos requisitos do cliente. Além disso, devem ser projetados e implementados apenas os requisitos previstos pelo cliente até o momento. • Feedback : a equipe de desenvolvimento deve estar colhendo o feedback sempre e ao final de cada itera¸cão, para que dessa forma o processo seja otimizado e que as próximas itera¸cões preencham a expectativa do cliente. • Coragem: valor de grande importância por garantir que a equipe do projeto estará sempre pronta para tomar as decisões necessárias ao longo do projeto, respondendo de forma eficiente às mudan¸cas. XP enfatiza o trabalho em equipe, de forma que tanto gerentes e desenvolvedores quanto os próprios clientes sejam todos parte de uma mesma equipe e focados ne entrega de um produto final de qualidade. Além disso, a distribui¸caõ das responsabilidades no projeto acontece de forma que as decisões relacionadas a decisões do projeto (como datas, escopo e prioridades) fiquem a cargo da área de negócios, enquanto que as decisões técnicas (como estimativas) são de responsabilidade da equipe técnica. Diferentemente do RUP, XP não define um conjunto de papéis, atividades e artefatos a serem produzidos. Ao invés disso, XP define um conjunto de regras e práticas de apoio em conformidade com os quatro valores citados anteriormente. As regras e práticas foram definidas com o objetivo de eliminar os riscos do projeto e aumentar as chances de sucesso dos projetos. As regras, listadas abaixo, são simples e podem levar a mudan¸cas significativas quando executadas [xp]: • Programa¸cão em Pares: defende a idéia de que todo o código deve ser produzido por duas pessoas trabalhando juntas num u ´ nico computador. O par deve ser formado por um condutor, que digita o trabalho, e por um navegador, que observa o trabalho do condutor visando identificar problemas e dando sugestões. Deve haver rota¸cão entre os papéis para que haja dissemina¸cão do conhecimento entre os membros da equipe..

(26) 2.1 ESTADO DA ARTE. 11. • Jogo do Planejamento: define que as estimativas de prazo e prioridades sejam feitas numa sessão ou reunião onde tanto o cliente quanto os desenvolvedores devem discutir as atividades da próxima itera¸cão. • Teste: sugere a cria¸cão de testes de unidade antes mesmo da funcionalidade. Além disso, os testes devem estar automatizados. • Cliente On Site: o cliente está sempre dispon´ıvel não apenas para ajudar a um membro da equipe, mas fazendo parte desta. Em todas as fases de um projeto que segue XP existe uma comunica¸cão com o cliente, preferencialmente ’face a face’ e on site. • Padrão de Codifica¸cão: todo código produzido deve seguir um padrão pré-definido, tornando assim fácil e rápido sua leitura e entendimento. • Posse Coletiva do Código: encoraja qualquer um a contribuir com novas idéias a todos os segmentos do projeto. Qualquer desenvolvedor pode alterar o código ou corrigir bugs. Esta prática evita gargalos que podem se causados caso o ’dono’ do código (aquele que o produziu) não esteja dispon´ıvel para realizar alguma mudan¸ca necessária. • Integra¸cão Cont´ınua: os desenvolvedores devem atualizar o repositório com as versões mais recentes sempre que poss´ıvel, não passando mais que um dia para fazê-lo. Esta prática evita que os outros desenvolvedores trabalhem com versões desatualizadas e poss´ıveis imcompatibiliddes entre elas. Porém, o repositório deve ser atualizado apenas quando os testes unitários forem executados com sucesso ou quando uma pequena parte da funcionalidade estiver completa. • Projeto Simples: como projetos simples sempre são implementados em menor tempo que os complexos, XP encoraja os desenvolvedores a projetar apenas o que está previsto até o momento e da maneira mais simples poss´ıvel. • Refactoring: também conhecido como melhoria cont´ınua da arquitetura, esta prática torna-se necessária em fun¸cão da prática do Projeto Simples. E para que seja efetiva, os testes unitários devem ser robustos o suficiente para que o refatoramento seja feito de forma segura. • Metáforas: com o objetivo de melhorar a comunica¸cão e o entendimento sobre a arqitetura do projeto, XP prega que sejam utilizadas metáforas (uma história de.

(27) 2.2 TRABALHOS RELACIONADOS. 12. como o sistema deve funcionar) para uniformizar o entendimento do sistema entre desenvolvedores, gerentes e cliente. • Releases Curtos: uma pequena versão do sistema deve ser entregue ao final de cada itera¸cão. Esta prática permite receber um feedback cont´ınuo do cliente e minimiza o impacto de mudan¸cas. • Semana de 40 Horas: o limite de trabalho semanal não deve exceder 40 horas, pois longas jornadas de trabalho levam a equipe ao cansa¸co, e consequentemente, mais suscet´ıvel a erros. Ao invés de aumentar a carga de trabalho semanal, o escopo e os prazos devem ser revistos. O uso de XP é adequado e recomendado a projetos de risco e que possuem requisitos dinâmicos, como por exemplo quando o cliente não tem certeza do que o sistema deve fazer. Além disso XP melhor se adequa a pequenas equipes: 2 a 12 pessoas [Bec99]. 2.2. TRABALHOS RELACIONADOS. Nesta se¸cão são apresetados trabalhos relacionados ao desenvolvimento de IP-core. Este trabalhos não definem processos de desenvolvimento em si, mas são iniciativas recentes e interessantes de muita contribui¸cão no assunto. São apresentados dois trabalhos relacionados a praticas de desenvolvimento e documenta¸cão: Reuse Methodology Manual e VSI Alliance. Em seguida são apresentados trabalhos que utilizam a linguagem UML como ferramenta de modelagem no desenvolvimento de IP-cores. 2.2.1. Reuse Methodology Manual (RMM). O reuso de projetos - cores pré-definidos e pré-verificados - é uma das atuais alternativas para viabilizar projetos de chips grandes e complexos dentro de um custo aceitável, tanto em rela¸cão a tamanho de equipe e prazos quanto a qualidade do produto final. Neste sentido, o Reuse Methodology Manual, também conhecido por RMM, foca num conjunto de boas práticas para criar IP-cores de fato reusáveis no contexto de uma metodologia de projeto de SoC baseada em reuso de cores [KB02]. As práticas adotadas pelo RMM foram baseadas na experiência dos autores no desenvolvimento de projetos de IP-core reusáveis, assim como na experiência de muitas empresas ao redor do mundo como: Alcatel, Atmel, Infineon Technologies, LSI Logic, Philips Semiconductor e STMIcroelectronics [KB02]. O RMM tem como objetivo definir técnicas para:.

(28) 2.2 TRABALHOS RELACIONADOS. 13. • projetar IP-cores reusáveis; • reutilizar IP-cores em projeto de SoC’s; • integrar IP-cores em projetos de SoC; • verificar timing e funcionalidades em projetos de grandes SoC´s. Dessa forma, o RMM trata problemas relacionados a dois p´ ublicos distintos: os projetistas de IP-cores reusáveis e os projetistas de chips que integram esses IP-cores em seus projetos de SoC. Considerando o p´ ublico dos projetistas, o RMM prega que um IP-core reusável deve ter as seguintes caracter´ısticas: • Configurabilidade: o IP-core produzido deve ser configurável de tal forma que possa atender a diferentes necessidades de diferentes projetos de SoC • Interface Padrão: ado¸cão de interface com padrão industrial de forma que o IP-core seja facilmente integrado a um SoC. • Compat´ıbilidade com Práticas de Projeto: seguir práticas comuns de projeto que tornem o IP-core fácil de ser verificado e distribu´ıdo, como por exemplo guia de implementa¸cão RTL, guia de s´ıntese, guia de verifica¸cão e guia de distribui¸cão. • Conjunto Completo de Deliverables: dispoinibilizar um conjunto completo de informa¸cões para que o IP-core seja reutilizado com facilidade como Código RTL Sintetizável, Componentes de Verifica¸cão, Scripts de S´ıntese e Documenta¸cão. Essas práticas devem guiar as fases do desenvolvimento do IP-core. A Figura 2.2 apresenta as fases de desenvolvimento consideradas no RMM. A seguir é apresentada uma breve descri¸cão das fases citadas na Figura 2.2: • Definir Caracter´ısticas Chave (Define Key Features): primeiro passo do desenvolvimento onde devem ser definidas as funcionalidades básicas e os parâmetros de configura¸cão. • Planejamento e Especifica¸cão(Planning and Specification): o segundo passo é desenvolver uma especifica¸cão detalhada tanto para a implementa¸cão quanto para a verifica¸cão e um planejamento para o restante do projeto. • Projeto e Verifica¸cão(Design and Verification): uma vez que a especifica¸cão e o planejamento estão conclu´ıdos, a equipe passa então para a fase de detalhamento do projeto (implementa¸cão) e verifica¸cão do IP-core..

(29) 14. 2.2 TRABALHOS RELACIONADOS. DEFINE key features. PLANNING and SPECIFICATION. DESIGN and VERIFICATION. PRODUCTIZATION. ALPHA TEST and RELEASE. Figura 2.2 Fases de Desenvolvimento de IP-cores segundo o RMM [KB02]. • Cria¸cão de Produto(Productization): uma vez que o projeto está completo, testes adicionais são executados a documenta¸cão para os usuários finais é criada (deliverables) e empacotada de forma que o produto possa ser entregue ao cliente. • Teste e Libera¸cão de Versão(Alpha Test and Release): a versões finais dos deliverables são testados para certificar-se que estão completos e prontos para serem utilizados pelo usuário final (integradores e projetistas de SoC). Estas fase serão descritas em maiores detalhes no Cap´ıtulo 3. 2.2.2. Virtual Socket Interface Alliance (VSIA). O VSI Alliance, também chamado de VSIA, é um grupo de trabalho formado pela ind´ ustria que tem como objetivo facilitar o reuso de componentes através da defini¸cão de interfaces padrão para ferramentas e padrões de documenta¸cão. Em outras palavras o objetivo do VSIA é desenvolver e manter um conjunto de padrões de reuso de IP-cores que torne poss´ıvel o aumento da produtividde de projetos de SoC [vsi02, vsi]. O VSIA foi formado em setembro de 1996 pelas principais empresas da ind´ ustria de semicondutores e de automa¸cão de projetos (EDA) com dois objetivos principais. O primeiro era desenvolver uma visão unificada para a ind´ ustria de chips e, o segundo, desenvolver padões técnicos que permitissem a utiliza¸cão da propriedade intelectual oriunda de diferentes fontes. Mais tarde, a visão do VSIA expandiu-se em fun¸cão da crescente necessidade da ind´ ustria de circuitos integrados (IC) incluindo trabalhos na área de software.

(30) 2.2 TRABALHOS RELACIONADOS. 15. e hardware IP-cores para projetos de System-on-Chip (SoC). Recentemente a organiza¸cão foi reestruturada através da cria¸cão de um novo tipo de grupo de trabalho, chamado de Pilar (Pillars). Cada pilar direciona padroniza¸cões para aumentar a produtividade dos desenvolvedores e usuários de SoC e IP-cores. Atualmente existem quatro Pilares, que estão descritos brevemente abaixo: • IP Quality: responsável por definir atributos essenciais de qualidade para qualquer IP de modo tal que o torne funcional e eficientemente reusável em SoCs. • IP Protection: responsável por definir, desenvolver e documentar solu¸cões abertas e padronizadas para balancear o n´ıvel de seguran¸ca necessário à prote¸cão da propriedade intelectual e sua usabilidade. • IP Infrastructure: responsável por promover a interoperabilidade entre os participantes do ecossistema de IP-core. O objetivo deste pilar é aumentar o valor agregado no reuso de IP-cores. • Research & Development: tem como objetivo estudar e direcionar novos desafios encarados pela ind´ ustria como avalia¸cão de IP-core, reuso de blocos muito grandes e projeto baseado em plataforma entre outros. A se¸cão a seguir apresenta estudos recentes que relacionam a linguagem de modelagem UML e projetos de IP-cores e SoC’s. 2.2.3. Modelagem UML. Esta subse¸cão agrupa trabalhos relacionados a utiliza¸cão da linguagem UML como mecanismo de modelagem de projetos de IP-cores e SoCs, tendo como objetivo relatar novas técnicas utilizadas nas atividades de especifica¸cão e implementa¸cão. A seguir estão descritos alguns destes trabalhos. 2.2.3.1 Gera¸c˜ ao de C´ odigo SystemC a partir de Modelos UML Este trabalho foi divulgado em 2004 na conferencia UML-SoC por [W+ 04], o qual apresenta uma ferramenta para gera¸cão automática de código SystemC a partir de modelos UML, chamada de RT2SystemC. Esta ferramenta gera código SystemC a partir de modelos UML descritos na ferramenta Rational Rose RT, sendo o código gerado aceito pelo compilador da ferramenta Synopsys CoCentric. O RT2SystemC permite ao usuário descrever modelos utilizando.

(31) 16. 2.2 TRABALHOS RELACIONADOS. o profile UML de Tempo Real (UML-RT). Este profile inclui os conceitos de capsulas, protocolos e portas. A modelagem em UML do comportamento deve ser feita através de diagramas de classe e de máquinas de estado. SystemC foi escolhida como linguagem alvo pelas seguintes caracter´ısticas: • SystemC é uma linguagem que permite a descri¸cão de comportamento de hardware e software em alto n´ıvel de abstra¸cão • SystemC é definido como um conjunto de bibliotecas C++, sendo naturalmente compat´ıvel com metodologias orientada a objetos. • E por u ´ ltimo, SystemC possui grande similaridade com os conceitos de UMLRT. Uma capsula em UML corresponde a um m´ odulo em SystemC. Capsulas comunicam-se via portas e protocolos da mesma maneira que módulos comunicamse via portas e canais em SystemC. A Figura 2.3 apresenta o fluxo de execu¸cão da ferramenta RT2SystemC. Rose RT UML. Synthesizable SystemC. C++ Code Generation with Rose RT. Post-processign with Synthesis Options. Convert C++ to XML with GCC_XML. Translate into SystemC Coded. Pre-processing With Our Own Tags. Parsing XML using JDOM. Figura 2.3 Ferramenta RT2SystemC: Processo de Tradu¸c˜ ao [W+ 04]. O pré-processamento é necessário apenas se o objetivo é gerar código SystemC sintetizável, sendo dispensável quando o objetivo for gerar código SytemC no n´ıvel de transa¸cão (TLM). Desta forma, o usuário pode gerar código SystemC em dois n´ıveis: RTL Sintetizável e TLM. Este trabalho pode ser extremamente u ´ til para gerar especifica¸cões executáveis e, consequentemente, modelos de referência na verifica¸cão funcional.

(32) 2.2 TRABALHOS RELACIONADOS. 17. diminuindo o tempo de projeto. Além disso, o autor [W+ 04] ressalva que este trabalho pode ser extendido, para que a partir dos mesmos modelos UML, sejam gerados automaticamente também casos de teste (o conjunto de est´ımulos utilizados na verifica¸cão funcional). 2.2.3.2 SystemC e UML 2.0: Novas Metodologias de Projeto Esta subse¸cão agrupa algumas iniciativas de empresas que estão utilizando e pesquisando sobre o uso de UML 2.0 e SystemC como uma nova abordagem de projeto de SoCs. Todos os trabalhos foram apresentados em 2005 na conferência Design, Automation and Test in Europe (DATE ’05). 2.2.3.2.1 STMicroelectronics - este trabalho mostra a experiência da STMicroelectronics na utiliza¸cão de UML em sua metodologia de projeto de SoC’s [RS+ 05]. O referido trabalho sugere um profile UML 2.0 para SystemC capaz de capturar aspectos comportamentais e estruturais da linguagem, com o objetivo de permitir a modelagem de System-on-Chips (SoCs) em alto n´ıvel de abstra¸cão e gera¸cão de código [RS+ 05]. Este trabalho aposta na utiliza¸cão de UML como uma forma de aperfei¸coar o fluxo do projeto de SoC da sequinte maneira [RS+ 05]: • UML é independente de plataforma, dessa forma pode ser adotado como modelo executável da funcionalidade do sistema. • O profile UML para SystemC permite descrever comportamento de hardware no n´ıvel RTL • UML pode ser utilizado para modelar comportamento e gerar código de software A Figura 2.4 apresenta o profile UML 2.0 para SystemC, na coluna da esquerda são listados os elementos de SystemC e na coluna da direita as respectivas representa¸cões em UML. 2.2.3.2.2 Fujitsu - este trabalho mostra a experiência da incorpora¸cão da linguagem UML como um modelo formal de especifica¸cão em projetos de SoC. O trabalho foca na utiliza¸cão de UML como um mecanismo para aumentar a qualidade da especifica¸cão e da implementa¸cão, reduzindo assim o n´ umero de erros no projeto. [Z+ 05]. A Figura 2.5 mostra a estratégia de introdu¸cão de UML ao processo de desenvolvimento de SoCs da Fujitsu..

(33) 2.2 TRABALHOS RELACIONADOS. 18. Figura 2.4 Nota¸c˜ ao UML para os conceitos de SystemC [RS+ 05]. Esta nova abordagem tornou-se efetiva não só para validar a especifica¸cão como também para implementar a verifica¸cão [Z+ 05]. A incorpora¸cão da linguagem UML foi realizada da seguinte maneira: • Para reduzir o impacto do fluxo corrente, UML foi integrado ao processo de verifica¸cão sem modificar o estilo de projeto corrente. • Foram utilizados apenas diagramas de classe, diagramas de sequência e diagramas de casos de uso para modelar fun¸cões, tipos de dados e comportamento da especifica¸cão. • Foi introduzido o CWL (Component Wrapper Language) para modelar a interface do protocolo de comunica¸cão no n´ıvel de sinal..

(34) ˜ 2.3 CONSIDERAC ¸ OES FINAIS. 19. Figura 2.5 Fujitsu: Incorporando UML ao seu processo de Projetos de SoC [Z+ 05]. • UMl foi utilizado para analisar e modelar a especifica¸cão escrita em linguagem natural, assim como para eliminar erros de especifica¸cão validando a completude e consistência dos modelos UML. • Os cenários de teste foram derivados dos modelos UML para validar a implementa¸cão (RTL source code) através de testes black box. 2.2.3.2.3 SysML Partners - Iniciativa conjunta da OMG e do International Council on Systems Engineering (INCOSE) com parceria entre empresas e organiza¸cões (como Boeing, Motorola, Mentor Graphics e I-Logix). Esta iniciativa tem como objetivo refinar a linguagem UML 2.0 para criar uma linguagem de modelagem, chamada System Modeling Language (SysML). A linguagem SysML vem sendo utilizada para modelagem de sistemas incluindo: especifica¸cão, análise e verifica¸cão de sistemas complexos com componentes de hardware e software [VD05, sys]. 2.3. ˜ CONSIDERAC ¸ OES FINAIS. Este cap´ıtulo apresentou os principais trabalhos relacionados ao desenvolvimento de IPcores e seu reuso em projetos de SoC. Foram descritos dois processos de desenvolvimento de software, RUP e XP, cujos conceitos podem ser vistos como um modelo para defini¸cão de processos de desenvolvimento em geral..

(35) ˜ 2.3 CONSIDERAC ¸ OES FINAIS. 20. Mais especificamente no contexto de IP-cores foram descritos os trabalhos do manual de reuso e a iniciativa para padroniza¸cão de documenta¸cão, RMM e VSIA respectivamente. Além destes, foram apresentados trabalhos recentes que ilustram novas tendendências no projeto de IP-cores e SoCs como a utiliza¸cão de UML como linguagem de modelagem de alto n´ıvel. Onde o foco destes trabalhos é criar uma especifica¸cão e implementa¸cão de maior qualidade, reduzindo assim o n´ umero de erros no projeto. Estes trabalhos apresentam uma visão geral das etapas da metodologia, sem no entanto detalhar os passos do processo em termos de atividade, papéis e produtos a serem gerados a cada passo. O próximo cap´ıtulo apresenta os conceitos básicos relacionados ao contexto de desenvolvimento de IP-cores..

(36) CAPÍTULO 3. DESENVOLVIMENTO DE IP-CORE: CONCEITOS ´ BASICOS. Este cap´ıtulo tem como objetivos apresentar alguns conceitos básicos relacionados ao contexto de projetos de IP-cores, assim como apresentar uma visão geral da fases de desenvolvimento e atividades envolvidas. ´ CONCEITOS BASICOS. 3.1. Esta se¸cão agrupa a descri¸cão de conceitos básicos relacionados ao projeto de IP-cores como s´ıntese, verifica¸cão funcional, prototipa¸cão rápida e classifica¸cão de IP-cores. 3.1.1. Classifica¸c˜ ao de IP-core. Segundo o VSIA [vsi02], o produto final de um IP-core pode ser classificado de acordo com o conjunto de deliverables entregue ao usuário final, o que representa o quanto o desenvolvimento foi dirigido para um processo de fabrica¸cão em particular. Segundo esse critério, um IP-core pode ser classificado como: ´ entregue o código fonte, ou seja, o código RTL sintetizável. Sob o • Soft IP - E ponto de vista do usuário, o Soft IP é mais flex´ıvel, porém não existe precisão em termos de performance (área, potência, timing etc). • Hard IP - O Hard IP foi otimizado em termos de performance e mapeado para uma tecnologia espec´ıfica. Geralmente são entregues no formato GDSII1 , e inclui um modelo comportamental de ”alto-n´ıvel”, uma lista de testes e os modelos temporais e f´ısicos completos. Possui a vantagem de ser mais previs´ıvel, mas consequentemente é menos flex´ıvel em fun¸cão de ser dependente de tecnologia. • Firm IP - O Firm IP é um meio termo entre o Hard IP e o Soft IP. O Firm IP inclui RTL sintetizável, sendo considerado uma tecnologia f´ısica genérica. Dessa 1. GDSII : Polygon Level Layout Format. 21.

(37) ´ 3.1 CONCEITOS BASICOS. 22. forma, o Firm IP é mais previs´ıvel em termos de performance, assim como também mais flex´ıvel e portável. Essa classifica¸cão considera que o Hard IP será prototipado fisicamente em um ASIC (chip). Do ponto de vista do desenvolvedor, os modelos Soft IP e Firm IP implicam em uma aspecto a mais a ser considerado durante o desenvolvimento que é a prote¸cão da propriedade intelectual, uma vez que o código fonte RTL é entregue ao usuário final. 3.1.2. Taxonomia de Desenvolvimento: N´ıveis e Dom´ınios de Descri¸c˜ ao. O gráfico Y-Chart, ilustrado na Figura 3.1, define uma taxonomia para o desenvolvimento de projetos na área de sistemas eletrônicos, sendo introduzido primeiramente em 1983 por Gajski e Kuhn e ainda hoje mantendo-se como um ponto de referência importante [MLD92]. System Level. Behavioral Domain. Structural Domain. Algorithmic Level. System Spec.. CPU, Memory. RT - Level. Algorithm. Processor, Subsystem. Logic Level. Register-Transfer Spec. Boolean Eqn.. Circuit Differential Eqn. Level. ALU, Reg., MUX Gate, Flip-flop. Transistor. Rectangle / Polygon-Group Standard Cell / Subcell Macrocell Block / Chip Chip / Board. Physical /Geometrical Domain. Figura 3.1 Y-Chart: Dom´ınios e N´ıveis de Descri¸c˜ ao de Funcionalidade [MLD92]. A idéia básica por trás do Y-Chart é que cada elemento de um sistema eletrônico pode ser descrito em três dom´ınios diferentes que representam os eixos do gráfico. A seguir, uma breve descri¸cão de cada dom´ınio:.

(38) ´ 3.1 CONCEITOS BASICOS. 23. • Dom´ınio Comportamental (Behavioral Domain): o comportamento desejado do sistema é especificado, idealmente sem referência de como esse comportamento é atingido por uma implementa¸cão. • Dom´ınio Estrutural (Structural Domain): o sistema é tratado como um conjunto de elementos funcionais e suas interconexões. • Dom´ınio F´ısico (Physical Domain): A estrutura do projeto é mapeado no espa¸co, e não existe qualquer referência para sua funcionalidade. Em cada dom´ınio citado, os elementos podem ser descritos em vários n´ıveis de abstra¸cão. Quanto mais periférico, mais abstrato o n´ıvel, e quanto mais póximo do centro mais baixo é o n´ıvel de descri¸cão. As transi¸cões entre os eixos do Y-Chart definem tarefas no contexto de desenvolvimento de projetos e estão ilustradas na Figura 3.2, Parte A. Behavioral Domain. Synthesis Structural Domain. Analysis. Behavioral Domain. Structural Domain. 2. System Spec. Algorithm. Re fin em en Ab t st ra ct io n. 1. Processor, Subsystem. Optimization Register-Transfer Spec.. 3. Boolean Eqn.. ALU, Reg., MUX Gate, Flip-flop. Differential Eqn.. Generation. CPU, Memory. Transistor Rectangle / Polygon-Group Standard Cell / Subcell. Extraction Macrocell Block / Chip Chip / Board. Physical /Geometrical Domain. (Parte A). Physical /Geometrical Domain. (Parte B). Figura 3.2 Y-Chart: Transi¸c˜ oes Definindo Atividades [MLD92]. No contexto do desenvolvimento de IP-core, a Parte B da Figura 3.2 representa as atividades realizadas desde o in´ıcio do desenvolvimento até a prototipa¸cão em FPGA (passos 1, 2 e 3 da Parte B da figura). A implementa¸cão do projeto se inicia no n´ıvel de.

(39) ´ 3.1 CONCEITOS BASICOS. 24. algoritmo e em seguida a descri¸cão é refinada para o n´ıvel RTL. No passo 2, a descri¸cão RTL é sintetizada e em eguida, no passo 3, é gerada a descri¸cão a n´ıvel de circuito. Atualmente, todas essas transi¸cões podem ser realizadas com o suporte de ferramentas, dependendo da linguagem HDL utilizada no desenvolvimento do projeto. Fazendo um paralelo com o ciclo de vida do desenvolviemento de IP-cores, a descri¸cão algor´ıtmica pode ser utilizada como especifica¸cão executável e/ou modelo de referência na atividade de verifica¸cão funcional. A partir desse modelo é feito um refinamento para o n´ıvel RTL, manualmente ou com suporte de ferramentas. Atualmente, a s´ıntese é feita a partir do n´ıvel RTL em fun¸cão das ferramentas existentes serem melhor otimizadas neste n´ıvel de abstra¸cão, dependendo das restri¸cões de projeto. As atividades de s´ıntese e de gera¸cão do circuito são automatizadas por ferramentas e fazem parte da prototipa¸cão f´ısica do IP-core. 3.1.3. Verifica¸c˜ ao Funcional. A verifica¸cão funcional é um processo utilizado para demonstrar que o comportamento desejado para o projeto foi preservado pela sua implementa¸cão. Ou seja, o propósito da verifica¸cão é garantir que o resultado de uma transforma¸cão preserva o resultado esperado [Ber00]. Nesse contexto, o principal objetivo da verifica¸cão funcional é garantir que o projeto implementa de fato a funcionalidade desejada. A verifica¸caõ funcional pode demonstrar que o projeto atende a especifica¸cão, mas não pode provar a equivalência entre a implementa¸cão e a especifica¸cão. Em outras palavras, através da verifica¸cão funcional, é poss´ıvel provar a existência de bugs, mas não é poss´ıvel provar sua ausência. A verifica¸cão funcional pode ser executada através de três abordagens complementares, listadas a seguir [Ber00]: • Black-Box : a verifica¸cão é realizada sem conhecimento de como foi realizada a implementa¸cão. Toda a verifica¸cão é executada através das interfaces disponibilizadas, sem acessar estados internos da implementa¸cão. Possui a vantagem de ser independente da forma como foi implementado, e a desvantagem de ser dif´ıcil isolar uma funcionalidade particular quando um bug é encontrado. • White-Box : possui total visibilidade do comportamento interno do projeto que está sendo verificado. Possui a vantagem de isolar com facilidade um dado comportamento em particular, e a desvantagem de ser dependente da implementa¸cão onde qualquer mudan¸ca pode invalidar o testbench. Além disso, esta abordagem não.

(40) ´ 3.1 CONCEITOS BASICOS. 25. pode ser implementada em paralelo com a implementa¸cão do projeto, uma vez que a verifica¸cão depende de como a implementa¸cão foi realizada. • Grey-Box : esta abordagem é um meio termo entre as duas anteriores. A estratégia consiste em incluir algumas modifica¸cões que permitam obter uma maior visibilidade do comportamento interno. Como exemplo, incluir acesso a registradores para controlar ou observar estados internos. No contexto de desenvolvimento de IP-cores existe uma clara distin¸cão entre os termos Verifica¸cão Funcional e Teste. O propósito da verifica¸cão funcional é demonstrar que a implementa¸cão do projeto reflete a funcionalidade desejada, enquanto o propósito do teste é garantir que o projeto foi manufaturado corretamente (implementa¸cão em meio f´ısico, seja como ASIC ou FPGA). A expressão Testbench usualmente refere-se à constru¸cão de todo o código utilizado para criar uma sequência predeterminada de entradas (est´ımulos) para um dado projeto, e ocasionalmente observar a sa´ıda. A Figura 3.3 ilustra como o testbench interage com o DUV (Design Under Verification).. Testbench. DUV (Design Under Verification). Figura 3.3 Intera¸c˜ ao entre Testbench e DUV. 3.1.3.1 Estrat´ egia de Verifica¸c˜ ao Funcional do BRAZIL IP Estima-se, hoje em dia, que cerca de 60% do tempo de projeto seja gasto em verifica¸cão funcional [Ber00]. Diferentemente da atividade de s´ıntese, por exemplo, não existe um padrão para a verifica¸cão funcional, nem em termos de estilo de codifica¸cão nem em termos de linguagem de implementa¸cão. No contexto do projeto BRAZIL IP foi definida uma estratégia de verifica¸cão funcional e uma ferramenta de suporte a essa estratégia, denominada VeriSC, onde SystemC foi adotada como a linguagem padrão de implementa¸cão [SM+ 04]. A ferramenta VeriSC gera.

(41) ´ 3.1 CONCEITOS BASICOS. 26. automaticamente templates para os componentes do testbench a partir das interfaces do DUV. Na estratégia proposta pelo VeriSC, o testbench é composto pelos seguintes módulos: souce, driver, reference model, monitor e checker ; como ilustrado na Figura 3.4.. Testbench REFERENCE MODEL S O U R C E. D r I v e r. DUV. M o n it o r. C H E C K E R. Figura 3.4 Estratégia de Verifica¸c˜ ao Funcional, Ferramenta VeriSC [SM+ 04]. Dados de entrada (est´ımulos) são gerados tanto para o DUV quanto para o modelo de referência , e ambas as sa´ıdas são coletadas e comparadas para verificar se são equivalentes. O propósito de cada módulo é descrito a seguir: • Source: gera as transa¸cões de dado (conjunto de sinais que formam o est´ımulo) • Driver : responsável por transformar as transa¸cões de dado de acordo com a interface do DUV. • Reference Model : modelo com comportamento equivalente ao DUV, capaz de gerar a mesma sa´ıda que o DUV para um dada entrada. Considerando-se que o modelo de referência está 100% correto. • Monitor : responsável por receber os sinais do DUV e transformar em transa¸cões de dado. • Checker : responsável por verificar a cobertura funcional e verificar se as transa¸cões oriundas do DUV e do RF são equivalentes. Essa estratégia foi adotada como padrão no ipPROCESS, embora nada impe¸ca que o usuário adote uma outra. O objetivo de adotar o VeriSC como uma estratégia pré-definida é apenas agilizar a implementa¸cão da verifica¸cão funcional..