BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO
JOÃO CARLOS NUNES BITTENCOURT
PROJETO DE IP-CORES PARA APLICAÇÕES GRÁFICAS COM PROTOTIPAÇÃO EM FPGA UTILIZANDO O IPPROCESS
FEIRA DE SANTANA 2012
PROJETO DE IP-CORES PARA APLICAÇÕES GRÁFICAS COM PROTOTIPAÇÃO EM FPGA UTILIZANDO O IPPROCESS
Trabalho de Conclusão de Curso apresentado ao Colegiado do curso de Engenharia de Computação como requisito parcial para obtenção do grau de Bacharel em Engenharia de Computação pela Universidade Estadual de Feira de Santana.
Orientador: Dr. Anfranserai Morais Dias
FEIRA DE SANTANA 2012
João Carlos Nunes Bittencourt
Trabalho de Conclusão de Curso apresentado ao Colegiado do curso de Engenharia de Computação como requisito parcial para obtenção do grau de Bacharel em Engenharia de Computação pela Universidade Estadual de Feira de Santana, e julgada em _____/_____/_____ perante a banca examinadora:
Universidade Estadual de Feira de Santana Dr. Anfranserai Morais Dias
Universidade Estadual de Feira de Santana Dr. Wagner Luiz Alves Oliveira
Universidade Estadual de Feira de Santana Dr. João Batista Rocha Junior
estar sempre presente nos momentos mais importantes da minha vida.
Agradeço primeiramente à minha amada companheira Claudia Asevedo Mattos Bittencourt, por aproveitar cada pedaço das minhas conquistas; por me levantar quando não tinha forças; por me guiar e me completar.
Ao Dr. Aristóteles Matos, por seus conselhos e conversas de fim de semana que me faziam refletir e lembrar que existe vida além da universidade; a Marcia Matos, por apoiar todas as minhas decisões e por acreditar na minha competência; a Eric Mattos, por ser este grande companheiro, e pelo apoio indispensável na fase do cursinho e na adaptação à realidade feirense; à Renata e Everaldo Mattos, por acreditarem em mim e me apoiar ao longo deste tempo de formação.
Agradeço à minha família, em especial aos meus pais, Manoel e Eunice Bittencourt, pelos anos de dedicação, apoio, perseverança e pelo esforço em garantir a minha formação. Por serem um exemplo de trabalho e dedicação, que me fizeram enxergar o que de bom e ruim que a vida pode proporcionar. À minha irmã, por estar ao meu lado durante toda a infância e adolescência, vivendo junto os momentos mais importantes desta fase.
Em especial ao meu (mais que) orientador Prof. Dr. Delmar Broglio Carvalho, por ser a minha referência ao longo de todo o processo de formação; por me ensinar (quase) tudo o que me fez galgar tantas conquistas dentro e fora da Universidade; por me fazer permitir, de forma tão plena, viver todas as experiências possíveis e imagináveis no contexto da formação superior.
Ao Prof. Dr. Anfranserai Morais Dias, por ter me dado a honra de trabalhar ao seu lado e por ajudar a fazer deste projeto uma grande realidade.
Ao meu amigo, irmão e companheiro de todas as batalhas Jody Maick Araujo de Matos, pelos momentos que vivemos e conquistas que partilhamos, desde a primeira semana da graduação; e à minha eterna madrinha Joseane de Matos (matriarca do Fantastic Four ), pelo completo apoio durante esta etapa final.
Agradeço aos amigos Fernando Alberto Correia dos Santos Jr., Thayane Brito de Santana e Jhielson Montino Pimentel, pelas conquistas e aprendizados que começaram no PET, e pela amizade que se construiu desde o primeiro semestre.
A todos os meus colegas de curso, em especial Isabela Gonçalves e Fladmy Alves pelo apoio no início do curso, Anderson Marques pela admiração e companheirismo, Anderson Rocha pelas conversas no trajeto semanal (Feira de Santana/Cruz das Almas) e àqueles que não estão listados aqui, mas que fizeram parte, de alguma forma desta conquista.
A busca por novos modelos de processos que atendam as demandas por sistemas embarcados, cada vez mais sofisticados, tem se refletido em esforços para o desenvolvimento de IP-cores (Intelectual Property) reutilizáveis baseado no RUP (Rational Unifed Process). Dentre as alternativas de processo, destaca-se o ipPROCESS, uma iniciativa brasileira para padronizar e intensificar iniciativas com vistas ao desenvolvimento de projetos de Circuitos Integrados (CI) no país. Dentre as principais vertentes apoiadas por este modelo, destacam-se os mecanismos de reuso de IP-cores propostos por iniciativas como o RMM (Reuse Methodology Manual). Este trabalho apresenta o processo de concepção de um conjunto de soft IP-cores para projeto de aplicações gráficas com prototipação em FPGA, baseado no ipPROCESS. O desenvolvimento deste projeto apresenta-se ainda como uma inserção do ipPROCESS como alternativa metodológica no desenvolvimento de projetos de pequeno porte. Com vistas à validação dos componentes, foram propostas duas análises. A primeira consiste na adoção dos IP-cores na disciplina de Sistemas Digitais, componente curricular PBL do curso de Engenharia de Computação da Universidade Estadual de Feira de Santana, visando ainda o incentivo a propostas de reuso de componentes no contexto da disciplina. A segunda consiste na realização do projeto de um sistema gráfico, com prototipação em FPGA, inspirado nos jogos da década de 70. Este processo permitiu a validação da aplicabilidade de todos os componentes, integrando-os em um projeto real.
Searching for new process models which satisfy the embedded systems demands, has been reflected in efforts to develop reusable IP-cores based on the RUP (Rational Unified Process). Among the alternative process, highlight the ipPROCESS, a Brazilian initiative in order to create a standard and enhance the development of Integrated Circuit design in the country. Among the most important areas supported by this model, it is possible to highlight the mechanisms of reuse of IP-cores proposed by initiatives such as the RMM (Reuse Methodology Manual). This monography presents the design of a set of soft IP-cores focused in graphic based applications with FPGA prototyping using the ipPROCESS model. The development is presented as a further insertion ipPROCESS as a methodological alternative in developing small projects. To validate the components two analyzes are proposed. The first one is to adopt of the IP-cores in the Digital Systems curricular component of Computer Engineering undergraduate couse from Universidade Estadual de Feira de Santana, aiming to encourage proposals focused in components reuse. The second part is the design of a graphic based system, with prototyping in FPGA, inspired by the games of the 70’s. This process allowed the validation of the applicability of all components, integrating them into a real project.
Figura 1 Modelo conceitual de um SoC e IP-core. 15
Figura 2 Modelo de arquitetura de um FPGA. 18
Figura 3 Distribuição de esforços dentro da arquitetura do ipPROCESS. 21
Figura 4 Ciclo de vida de um projeto no ipPROCESS. 21
Figura 5 Estrutura dos componentes de teste para os IP-cores. 27
Figura 6 Exemplo de especificação de um caso de uso. 29
Figura 7 Exemplo de diagrama de classes. 30
Figura 8 Diagrama de tempo do processo de varredura horizontal e vertical. 36
Figura 9 Representação do sinal de sincronismo horizontal. 37
Figura 10 Representação do sinal de sincronismo vertical. 38
Figura 11 Perspectiva ilustrada do jogo de corrida de carros. 49
Figura 12 Perspectiva ilustrada do carro e suas partes. 50
Figura 13 Modelo de casos de uso inicial do projeto. 52
Figura 14 Diagrama de caso de uso da exibição ta tela inicial do jogo. 54
Figura 15 Perspectiva ilustrada da pista e seus elementos. 54
Figura 18 Plano de integração no conjunto ACEX1K. 58
Figura 19 Plano de integração com a placa ALTERA DE-2. 59
Figura 20 Resultado dos testes de unidade para os componentes gráficos. 61
Figura 21 Diagrama de integração dos IP-cores. 61
Figura 22 Distribuição da arquitetura dos IP-cores do jogo. 62
Tabela 1 Definições de parâmetros de resolução da tela. 37
Tabela 2 Código de cores no padrão RGB de 8 cores. 39
Tabela 3 Códigos de tamanho dos caracteres. 39
Tabela 4 Resultados da disciplina Implementação RTL. 41
Tabela 5 Resultados da disciplina Prototipação em FPGA. 42
Tabela 6 Conjunto de siglas e terminologias apresentadas ao longo do documento. 48
Tabela 7 Elementos da especificação de requisitos. 50
Tabela 8 Parâmetros de dimensões para diagramação do carro. 51
Tabela 9 Realização do caso de uso de controle de movimento da pista. 57
Tabela 10 Resultados da disciplina Implementação RTL. 60
Tabela 11 Resultados da síntese de cada componente em FPGA. 63
Tabela 12 Resultados da disciplina Prototipação em FPGA. 63
CIs Circuitos Integrados
VLSI Very Large-scale Integration
SoC System-on-Chip
IP Intelectual Property
VC Virtual Core ou Virtual Component
VSIA Virtual Socket Interface Alliance
RMM Reuse Methodology Manual
RUP Rational Unifed Process
FPGA Field-Programable Gate Array
OCP-IP Open Core Protocol International Partnership
UML Unified Modeling Language
MI Módulo Integrador
SD Sistemas Digitais
UEFS Universidade Estadual de Feira de Santana
OASIS Open Artwork System Interchange Standard
ASIC Application-Specific Integrated Circuit
PI Propriedade Intelectual
RTL Register-Transfer Level
HDL Hardware Description Language
DUV Design Under Verification
MVC Model View Control
FR Requisitos Funcionais
NFR Requisitos não Funcionais
CRT Cathode Ray Tube
VGA Video Graphics Array
HTP Total de Pixels Horizontais
HRES Resolução Horizontal
HF Front-porch Horizontal
HB Back-porch Horizontal
HR Retraço Horizontal
VTP Total de Pixels Verticais
VRES Resolução Vertical
VF Front-porch Vertical
VB Back-porch Vertical
VR Retraço Vertical
XP eXtreme Programming
UC Use Case
1 INTRODUÇÃO . . . 14
1.1 OBJETIVOS DO TRABALHO . . . 16
1.1.1 OBJETIVOS ESPECÍFICOS DO TRABALHO . . . 16
1.2 ESTRUTURA DO TRABALHO . . . 17
2 CONCEITOS FUNDAMENTAIS . . . . 18
2.1 VISÃO GERAL DE UM DISPOSITIVO FPGA . . . 18
2.2 IP-CORE DIGITAL . . . 18
2.3 VISÃO GERAL DO IPPROCESS . . . 20
2.3.1 FASES DO IPPROCESS . . . 20
2.3.2 DISCIPLINAS DO IPPROCESS . . . 22
2.4 CONSIDERAÇÕES FINAIS . . . 23
3 DESCRIÇÃO DO MODELO DE DESENVOLVIMENTO . . . 25
3.1 ORGANIZAÇÃO DO TRABALHO . . . 25
3.2 DISCIPLINAS E ATIVIDADES . . . 25
3.2.1 DISCIPLINA REQUISITOS . . . 26
3.2.2 DISCIPLINA ANÁLISE & PROJETO . . . 26
3.2.3 DISCIPLINA IMPLEMENTAÇÃO RTL . . . 26
3.2.3.1 ESTRUTURAÇÃO DOS COMPONENTES DE TESTE . . . 27
3.2.4 DISCIPLINA VERIFICAÇÃO FUNCIONAL . . . 27
3.2.5 DISCIPLINA PROTOTIPAÇÃO EM FPGA . . . 28
3.3 ESPECIFICAÇÕES DA MODELAGEM . . . 28
3.3.1 CASOS DE USO . . . 29
3.3.2 DIAGRAMAS DE CLASSES . . . 30
3.4 CRITÉRIOS PARA ANÁLISE DE ESFORÇO . . . 31
4 DESENVOLVIMENTO DO CONJUNTO DE SOFT IP-CORES . . . 32
4.1 DESCRIÇÃO DOS IP-CORES . . . 32
4.1.1 CONTROLADOR DE VÍDEO PARA O PADRÃO VGA . . . 33
4.1.2 CONTROLADOR DE MOVIMENTAÇÃO DE OBJETOS EM UMA REGIÃO DA TELA . . . 33
4.1.3 DETECTOR DE COLISÃO ENTRE DOIS OBJETOS NA TELA . . . 33
4.1.4 MODELO DE DIAGRAMAÇÃO DE OBJETOS RETANGULARES . . . 33
4.2 ALOCAÇÃO DE PAPÉIS . . . 33
4.3 FASE CONCEPÇÃO . . . 34
4.3.1 LEVANTAMENTO DE REQUISITOS . . . 34
4.3.1.1 ESPECIFICAÇÕES DE RESOLUÇÃO DA TELA . . . 35
4.3.1.2 VALOR LIMITE PARA O CONTADOR DA VARREDURA HORIZONTAL 35 4.3.1.3 VALOR LIMITE PARA O CONTADOR DA VARREDURA VERTICAL 36 4.3.1.4 PERÍODO DE ACIONAMENTO DO SINAL DE SINCRONISMO HORIZONTAL . . . 37
4.3.1.5 PERÍODO DE PERMANÊNCIA DO SINAL DE SINCRONISMO HORIZONTAL . . . 37
4.3.1.6 PERÍODO DE ACIONAMENTO DO SINAL DE SINCRONISMO VERTICAL . . . 38
4.3.1.7 PERÍODO DE PERMANÊNCIA DO SINAL DE SINCRONISMO VERTICAL . . . 38
4.3.1.8 ÁREA VISÍVEL DA TELA . . . 38
4.3.1.9 PADRÃO DE CORES RGB . . . 38
4.3.1.10 TAMANHO DOS CARACTERES . . . 39
4.3.1.11 POSICIONAMENTO DOS CARACTERES . . . 39
4.3.1.12 CONJUNTO DE CARACTERES ASCII SUPORTADOS . . . 39
4.4 FASE ARQUITETURA . . . 40
4.4.1 DEFINIÇÃO DA ARQUITETURA E DETALHAMENTO DOS CASOS DE USO . . . 40
4.5 PROJETO RTL . . . 40
4.6 PROTOTIPAÇÃO FÍSICA . . . 41
4.7 CONSIDERAÇÕES FINAIS . . . 42
5 VALIDAÇÃO DO CONJUNTO DE SOFT IP-CORES . . . . 44
5.1 UTILIZAÇÃO DOS SOFT IP-CORES NO MÓDULO INTEGRADOR DE SISTEMAS DIGITAIS . . . 44
5.2 INCORPORANDO O CONJUNTO DE IP-CORES NO PROJETO DE UM JOGO DE CORRIDA DE CARROS . . . 47
5.2.1 FASE CONCEPÇÃO . . . 47
5.2.1.1 ATIVIDADE CAPTURA DE VOCABULÁRIO USUAL . . . 47
5.2.1.2 ATIVIDADE DESENVOLVER VISÃO . . . 47
5.2.2 FASE ARQUITETURA . . . 53
5.2.2.1 ATIVIDADES ANÁLISE DA ARQUITETURA E PROJETO DE CASOS DE USO . . . 53
5.2.2.2 ATIVIDADE PROJETO DE COMPONENTES . . . 56
5.2.2.3 ATIVIDADE PLANEJAR INTEGRAÇÃO E PLANEJAR INTEGRAÇÃO EM FPGA . . . 58
5.2.3 FASE IMPLEMENTAÇÃO RTL . . . 59
5.2.3.1 ATIVIDADE IMPLEMENTAR COMPONENTES . . . 59
5.2.3.2 ATIVIDADE IMPLEMENTAR COMPONENTES DE TESTE . . . 60
5.2.3.3 ATIVIDADE EXECUTAR OS TESTES . . . 60
5.2.3.4 ATIVIDADE INTEGRAÇÃO DOS IP-CORES . . . 61
5.2.4 FASE PROTOTIPAÇÃO FÍSICA . . . 62
5.3 CONSIDERAÇÕES FINAIS . . . 64
5.3.1 APLICAÇÃO DOS SOFT IP-CORES COMO FERRAMENTA DE AUXÍLIO AO APRENDIZADO . . . 64
5.3.2 ANÁLISE DO PROJETO GRANDPRIX-FPGA . . . 64
6 CONCLUSÃO . . . 66
6.1 PRINCIPAIS CONTRIBUIÇÕES . . . 67
6.2 DIFICULDADES ENFRENTADAS . . . 67
6.3 TRABALHOS FUTUROS . . . 68
REFERÊNCIAS . . . 70
Apêndice A DOCUMENTO DE VISÃO: SOFT IP-CORES . . . 72
Apêndice B ESPECIFICAÇÃO DE REQUISITOS: SOFT IP-CORES . . . 83
Apêndice C MODELOS DE CASOS DE USO: SOFT IP-CORES . . . 95
Apêndice D DIAGRAMA DE CLASSES: SINCRONISMO VGA . . . 111
Apêndice E DIAGRAMA DE CLASSES: MULTIPLEXADOR RGB . . . . 118
Apêndice F DIAGRAMA DE CLASSES: CONTROLE DE POSIÇÃO . . 124
Apêndice G DIAGRAMA DE CLASSES: CONTROLE DE COLISÃO . . 131
Apêndice H DIAGRAMA DE CLASSES: DEBOUNCER . . . 139
Apêndice I DIAGRAMA DE CLASSES: GESTOR DE STRING . . . 145
Apêndice L MODELOS DE CASOS DE USO: GRANDPRIX-FPGA . . . 179
Apêndice M DIAGRAMAS DE CLASSES: GRANDPRIX-FPGA . . . 198
Anexo A PROBLEMA 1: SISTEMAS DIGITAIS T.2012.1 . . . 210
Anexo B PROBLEMA 1: SISTEMAS DIGITAIS T.2012.2 . . . 212
1 INTRODUÇÃO
Com os recentes avanços tecnológicos, o desenvolvimento de microprocessadores cresceu de forma exponencial nas últimas décadas, tornando-os cada vez menores, e embarcando um número cada vez maior de transistores. Este ritmo de crescimento foi previsto a partir da Lei de Moore (SCHALLER, 1997) e verificado pela inserção periódica no mercado de novos CIs (Circuitos Integrados) com grande capacidade de processamento. Esta lei é devida a Gordon E. Moore, que em 1965 observou que a densidade de componentes em CI dobrava em intervalos regulares, inferindo que este comportamento perduraria por muito tempo. O intervalo medido por Moore para que a densidade média de CIs dobrasse foi de 18 meses, o que ainda hoje permanece uma taxa estável (CAVIN; LUGLI; ZHIRNOV, 2012).
O aumento da competitividade das indústrias produtoras de CI, aliado à elevada taxa de crescimento resulta em um curto espaço de tempo para que novos projetos cheguem ao mercado. Aliado a isso, o surgimento da demanda por dispositivos de densidade cada vez menores, e circuitos VLSI (Very Large-scale Integration), com altos níveis de integração. Exemplos comuns são os smart phones, tablets e MP3 players, que atualmente fornecem, além das funcionalidades essenciais, uma série de recursos, como GPS, conexão Wi-fi, bluetooth, dentre outros.
Tendo em vista manter este ritmo acelerado de produção de novos componentes, e reduzir os custos de manter os altos níveis de integração em chip, foram desenvolvidas novas metodologias de projeto e de reuso para o desenvolvimento de circuitos VLSI. Uma das técnicas que mais tem se destacado nos últimos anos é o projeto de SoC (System-on-Chip), no qual blocos pré-existentes e pré-verificados são conectados em um único CI. Estes blocos são comumente chamados de IP (Intelectual Property) cores, desenvolvidos internamente, ou obtidos a partir de empresas terceirizadas (SALEH et al., 2006). Estes IP-cores reutilizáveis podem ser, por exemplo, processadores, blocos de memória ou de interface, responsáveis por uma aplicação específica dentro do sistema. O objetivo desta técnica é reduzir o tempo e o esforço de projeto e, consequentemente, os custos associados. Na Figura 1 observa-se uma estrutura SoC composta por um conjunto de IP-cores.
Destacando-se da face superior do CI, observa-se o IP ou VC (Virtual Core ou Virtual Component), que corresponde ao módulo de funcionalidade específica, capaz de ser agregado ao CI. O SoC apresenta ainda um conjunto de IP-cores combinados no intuito de agregar funcionalidades ao sistema. São eles: memória ROM, DRAM, cache, circuito analógico, USB e lógica do microprocessador.
Figura 1: Modelo conceitual de um SoC e IP-core. Fonte: (SALEH et al., 2006)
O crescimento da demanda por estes CIs, e o tempo reduzido para que os mesmos estejam circulando no mercado, permite verificar a necessidade que os produtores de IP-cores têm de desenvolver produtos de qualidade, tendo em vista a capacidade de integração e funcionalidade dos mesmos em projetos SoC. Falhas na implementação dessas funcionalidades ou no atendimento dos requisitos de desempenho podem ocasionar grandes prejuízos para uma empresa produtora de CI.
Visando atender a demanda por IP-cores com requisitos cada vez mais complexos e variados, foram desenvolvidas metodologias e técnicas de especificação e implementação baseadas nos padrões de qualidade de software. Dentre elas destacam-se a VSIA (Virtual Socket Interface Alliance), voltada para técnicas de especificação e avaliação de produtos, o RMM (Reuse Methodology Manual), que propõe mecanismos de descrição de IP-cores baseado em reuso. Recentemente, sob a perspectiva de desenvolvimento do consórcio Brazil-IP (BRAZIL-IP, 2012) foi proposto um modelo de processo, baseado no RUP (Rational Unifed Process) (KRUCHTEN, 2003), com prototipação em FPGA (Field-Programable Gate Array), chamado de ipPROCESS (LIMA, 2005). O ipPROCESS visa decompor o projeto em fases bem definidas, atendendo aos requisitos estabelecidos na fase inicial, utilizando técnicas de descrição de software no projeto de módulos de propriedade intelectual. Seu objetivo principal é reduzir o tempo de projeto, dividindo os esforços necessários para a concepção de um IP-core. Sob esta perspectiva, o projeto de um IP-core passa a ser um processo interdisciplinar, abrangendo áreas distintas como especificação, modelagem, verificação funcional, síntese e prototipação. A VSIA encerrou suas atividades em 2008, e atualmente os padrões de qualidade para produção e distribuição de IP-cores são mantidas pela OCP-IP (Open Core Protocol International Partnership) (OCP-IP, 2012).
Como forma de manter a evolução e garantir a integridade dos IP-cores, é preciso também estabelecer novos paradigmas para transferência de conhecimentos associados
aos processos. Esta abordagem de transferência tecnológica implica em alguma forma de aprendizagem e adaptação por parte dos atores receptores da tecnologia. A aprendizagem, neste caso, pode ser processada pela especificação dos IP-cores, concebida e refatorada ao longo das fases do processo. No projeto de CI, além de constituir-se como o alicerce para um desenvolvimento bem-sucedido, a especificação dos IP-cores é usada como um guia para a tarefa de construção e manutenção dos sistemas, além de servir de instrumento norteador no processo de verificação funcional. Assim como no processo de desenvolvimento de software (PRESSMAN, 2006), IP-cores bem documentados reduzem o tempo de refatoração e favorecem o desenvolvimento de novos recursos e modificações em sua estrutura.
1.1 OBJETIVOS DO TRABALHO
Sob a perspectiva de processos definida a partir do ipPROCESS, e com vistas à concepção de um ambiente de aprendizagem baseado no reuso de IP-cores, este trabalho consiste no projeto e desenvolvimento de um conjunto de soft IP-cores para aplicações gráficas, com prototipação em FPGA. Os objetivos específicos do trabalho são descritos a seguir.
1.1.1 Objetivos Específicos do Trabalho
Os objetivos específicos para este trabalho consistem em:
1. Documentar o conjunto de soft IP-cores para aplicações gráficas, prototipadas em FPGA - O processo de desenvolvimento consiste no ciclo de vida de desenvolvimento proposto pelo ipPROCESS. Um dos elementos principais, na fase de especificação de requisitos é a documentação do produto. Neste contexto, este trabalho apresenta as especificações de todos os IP-cores desenvolvidos, sob a forma de diagramas UML (Unified Modeling Language).
2. Utilizar o ipPROCESS como modelo de processos em um ambiente de desenvolvimento - O ipPROCESS é um modelo de processos que já vem sendo utilizado dentro do programa Brazil-IP, no qual, ao todo foram identificados 27 projetos, concluídos e em andamento (BRAZIL-IP, 2012). Dessa forma, tendo em vista compor um elemento que visa corroborar com o processo de validação do ipPROCESS, este trabalho propõe a utilização deste modelo no desenvolvimento de trabalhos acadêmicos de pequeno porte. Em consequência desta característica, este estudo não tem o objetivo de cumprir com todas as atividades previstas pela
definição do processo, mas sim de identificar quais delas podem ser cumpridas e de que forma é possível lidar com as dificuldades encontradas.
3. Validar a implantação dos módulos sob a perspectiva educacional - Lima et al. (2005) propôs em seu trabalho, a utilização do ipPROCESS como um meio para contribuir com a aprendizagem do processo de desenvolvimento de IP-cores. Tendo em vista analisar o processo sob outras perspectivas, este trabalho visa implantar os IP-cores no MI (Módulo Integrador) da disciplina SD (Sistemas Digitais) na UEFS (Universidade Estadual de Feira de Santana), com vistas ao processo de avaliação da aplicabilidade e mantenabilidade dos IP-cores.
4. Validar a aplicabilidade dos módulos com o desenvolvimento de um jogo de corrida de carros - Para compor o processo de validação de IP-cores, este trabalho apresenta ainda o ciclo de projeto e desenvolvimento de um jogo de corrida de carros, construído a partir do conjunto de soft IP-cores.
5. Avaliar a eficácia do reuso de IP-cores dentro do escopo de projeto de Circuitos Integrados - Com a implantação dos modelos SoC, e a utilização de IP-cores em sua estrutura, fica clara a necessidade de implantação de metodologias de reuso, tendo em vista a redução de custos de projeto. Este trabalho apresenta uma avaliação dos resultados obtidos ao desenvolver uma aplicação baseada em reuso de componentes.
1.2 ESTRUTURA DO TRABALHO
Além deste capítulo introdutório, este trabalho se encontra estruturado da seguinte forma: no Capítulo 2 são apresentados os conceitos fundamentais para o entendimento do mesmo; no Capítulo 3 é delineada a abordagem utilizada para o desenvolvimento do projeto; no Capítulo 4 é apresentada a descrição do desenvolvimento do conjunto de soft IP-cores. A análise dos resultados do trabalho se encontra no Capítulo 5 e, por fim, as conclusões e trabalhos futuros estão presentes no Capítulo 6.
2 CONCEITOS FUNDAMENTAIS
Este capítulo apresenta alguns conceitos pertinentes ao entendimento do processo de desenvolvimento de IP-cores digitais sob a perspectiva do ipPROCESS, tais como a estrutura fundamental de um dispositivo FPGA, definição de classificação de IP-cores, e os princípios fundamentais do modelo de processos.
2.1 VISÃO GERAL DE UM DISPOSITIVO FPGA
O FPGA (Field-Programmable Gate Array) é um dispositivo lógico composto por um arranjo bidimensional de células lógicas e chaves programáveis genéricas. Nesta configuração, uma célula lógica pode ser configurada (programada) para executar uma função e as chaves são utilizadas para realizar a conexão entre as células (CHU, 2008). Essa configuração permite ao projetista desenvolver sua lógica no intuito de dar funcionalidades ao seu circuito, obtendo um modelo de circuito flexível e totalmente reconfigurável. Um diagrama da arquitetura interna de um dispositivo FPGA é apresentado na Figura 2.
Canais de Roteamento
Entrada/ Saída
Bloco lógico Figura 2: Modelo de arquitetura de um FPGA.
Fonte: OpenCliparts.org.
2.2 IP-CORE DIGITAL
O desenvolvimento de IP-cores tem sido a forma mais comum de desenvolvimento de SoC com base em componentes reutilizáveis dentro da indústria de semicondutores (SALEH et al., 2006). Um core digital pode ser definido como a descrição de um sistema digital. Quanto à disponibilização, um core digital pode ser classificado como licenciável, quando o fornecedor disponibiliza um projeto e um conjunto de ferramentas, conferindo a tarefa de projeto do sistema e sua fabricação ao cliente. Um core pode também ser definido como proprietário. Neste caso, a preocupação principal do fornecedor é proteger
sua propriedade intelectual. Segundo a VSIA, quanto à flexibilidade, um core pode ser classificado em três categorias: hard, firm e soft (VSIA, 2012).
• Hard core: Possui organização pré-definida, é modelado como um elemento de biblioteca e não pode ser modificado pelo projetista. Suas especificações de temporização são bem definidas e garantidas pelo fornecedor. Além disso, possui alto índice de proteção de propriedade intelectual, sendo disponibilizados, em alguns casos, como uma black-box, no formato GDSII1, ou OASIS (Open Artwork System Interchange Standard), na qual a descrição corresponde normalmente à um layout. • Firm core: A combinação entre o código fonte e sua netlist pode variar de acordo
com a tecnologia utilizada, e sua modelagem é concebida a partir da combinação de blocos sintetizáveis fixos. Em outras palavras, antes do processo de síntese do circuito, é possível modelar os componentes de acordo com a tecnologia e as ferramentas fornecidas pela ferramenta de síntese. A personalização de funções específicas é dependente da tecnologia, e apenas os caminhos críticos possuem temporização fixa. Em geral, neste modelo de IP-core, é possível inserir design constrains de tempo e consumo de área, de acordo com as características da tecnologia utilizada.
• Soft core: Apresenta um código fonte comportamental independente da tecnologia de projeto, podendo ser sintetizado em diversas plataformas distintas. Apesar de ser possível modificar o seu projeto, as restrições de tempo não são garantidas, podendo não atender aos requisitos do projeto. Em geral são módulos disponibilizados sob a forma de código fonte aberto.
A classificação dos IP-cores considera que um hard-core será prototipado fisicamente em ASIC (Application-Specific Integrated Circuit), de acordo com a tecnologia a partir do qual o mesmo foi gerado. A principal diferença, em termos de prototipação reside na flexibilidade em termos do processo pré-síntese presente nas classes firm e soft core, nas quais é possível realizar modificações antes de gerar o layout físico. Do ponto de vista do desenvolvedor, os modelos soft-core e firm-core implicam em um aspecto a mais a ser considerando durante o desenvolvimento, no que se refere à proteção da PI (Propriedade Intelectual), uma vez que o código fonte RTL (Register-Transfer Level) é entregue ao usuário final (LIMA, 2005). Dessa forma, é importante que o desenvolvedor esteja atento aos mecanismos de PI, tendo em vista manter a integridade dos seus projetos, dentro ou fora do contexto empresarial.
1GDSII: Conhecido como Poligon Level Layout Format, consiste no arquivo que é enviado para uma
2.3 VISÃO GERAL DO IPPROCESS
A necessidade de modelos de processos para desenvolvimento de SoC sofisticados implicou no surgimento de novas metodologias de desenvolvimento de IP-cores. Na maioria dos casos, estes métodos utilizam paradigmas comumente utilizados no desenvolvimento de software, tais como modelagem através de diagramas, extensa documentação e testes de funcionalidade.
O ipPROCESS é um modelo de processo para desenvolvimento de IP-cores com prototipação em FPGA, baseado no RUP (KRUCHTEN, 2003), dividindo sua execução em fases e disciplinas. Cada disciplina é definida como uma coleção de atividades relacionadas a uma determinada área de concentração ou domínio (SANTOS, 2009). Este processo visa, por meio de um conjunto de atividades atribuídas a papéis especializados na organização, transformar os requisitos em um IP-core, cumprindo restrições de prazo, custo, qualidade e manutenção.
Apresentando atualmente a arquitetura descrita na Figura 3, o ipPROCESS visa, através de um ciclo de vida iterativo incremental, desenvolver e entregar marcos (builds) incrementais para o cliente (LIMA, 2005). Além disso, o ipPROCESS cobre também todo o fluxo de pré-projeto, desde o contato com o cliente, identificação das necessidades, negociação, assim como a manutenção do IP-core distribuído (SANTOS, 2009).
De acordo com a Figura 3 é possível observar que a arquitetura do ipPROCESS é subdividida em dois eixos. O eixo vertical representa as disciplinas, propostas de acordo com o ciclo de desenvolvimento de IP-cores proposto pelo RMM (KEATING; BRICAUD, 2002). O eixo horizontal (timeline) apresenta o ciclo de vida do processo, representando como as cargas sobre as disciplinas estão distribuídas ao longo do tempo.
Ao combinar as informações presentes nos dois eixos observa-se que as disciplinas apresentam alturas diferentes ao longo do tempo. Esta altura representa o nível de esforço que deve ser alocado para cada disciplina ao longo do projeto. Deste modo, a equipe de desenvolvimento deve ser capaz de desenvolver um conjunto incremental de funcionalidades do IP-core, através da construção de casos de uso, em cada disciplina do processo com esforços diferentes (SANTOS, 2009). Por este motivo, é dito que o ipPROCESS é incremental e centrado em casos de uso.
2.3.1 Fases do ipPROCESS
O ciclo de vida implementado pelo ipPROCESS é decomposto em quatro fases sequenciais. Para cada fase são definidas as atividades a serem executadas e, ao final de cada fase, um processo de avaliação verifica se os critérios de requisitos foram atendidos e
Iterações
Fases
Disciplinas
Requisitos Análise e Projeto Implementação Verificação Prototipação em FPGA DistribuiçãoFigura 3: Distribuição de esforços dentro da arquitetura do ipPROCESS. Fonte: Adaptado de (SANTOS, 2009).
se o marco que representa a sua conclusão foi atingido (LIMA, 2005). Somente após esta validação é possível seguir para a próxima fase.
A Figura 4 apresenta a modelagem das fases do ipPROCESS, com sua descrição, a sequência com que estas são executadas, e o marco (milestone) que deve ser atingido em cada uma delas.
Concepção Arquitetura Projeto RTL Prototipação
Especificação Funcional Arquitetura do IP-core RTL do IP-core Protótipo do IP-core Tempo Marco
Figura 4: Ciclo de vida de um projeto no ipPROCESS. Fonte: Adaptado de (LIMA, 2005).
A seguir são descritas cada umas das fases presentes na Figura 4, seus objetivos, as estimativas de esforço e os marcos a serem atingidos.
1. Concepção - etapa de planejamento, onde são identificados e definidos escopo e requisitos do IP-core e as necessidades do usuário. Como resultado, espera-se um
documento de Especificação Funcional, contendo os requisitos do projeto. Estima-se que nesta fase se encontre um dos menores índices de esforço, uma vez que o projeto encontra-se em fase inicial, e nem todos os membros da equipe de desenvolvimento se encontram em atividade.
2. Arquitetura - etapa onde é projetada uma arquitetura estável para o IP-core, servindo de base para o processo de implementação RTL do mesmo. O esforço estimado é o segundo maior do ciclo de vida do ipPROCESS.
3. Projeto RTL - o objetivo desta fase é desenvolver e verificar o código RTL do IP-core, baseado na arquitetura definida na fase Arquitetura. Esta etapa concentra o maior nível de esforço dentro do processo, e o marco de passagem para a próxima fase é a apresentação do código RTL do IP-core.
4. Prototipação - o principal objetivo nesta fase é o a criação de um protótipo do IP-core e a finalização da documentação do usuário. O esforço estimado nesta fase pode variar, mas estima-se que seja maior quando comparado àquele desprendido na fase Concepção.
2.3.2 Disciplinas do ipPROCESS
Incorporando os conceitos utilizados no modelo RUP, o ipPROCESS também utiliza a estrutura operacional na forma de distribuição por disciplinas. Cada disciplina do processo apresenta um fluxo macro, definindo as atividades a serem executadas, bem como a sua ordem de execução (SANTOS, 2009). Estas atividades, por sua vez, são classificadas em termos de tarefas a serem executadas, definindo os papéis exercidos pelos respectivos responsáveis e os artefatos gerados ou reutilizados ao longo do projeto.
Seguindo este modelo, as atividades relacionadas ao contexto de desenvolvimento de IP-cores foram agrupadas sob um conjunto de seis disciplinas, listadas abaixo.
• Requisitos - disciplina onde o escopo do IP-core é estabelecido, com atividades de levantamento de requisitos, termos e necessidades do usuário. O objetivo desta fase é fornecer aos desenvolvedores um melhor entendimento das funcionalidades que devem ser implementadas pelo IP-core.
• Análise & Projeto - nesta disciplina os requisitos são transferidos para o projeto do IP-core, determinando a arquitetura a partir da qual o core será implementado. As atividades relacionadas a este contexto contemplam a descrição da modelagem do sistema na forma de casos de uso, de acordo com os requisitos funcionais, a partir do refinamento do modelo de caso de uso especificado na primeira fase do projeto. O projeto dos casos de uso, representa a descrição dos componentes e suas
funcionalidades por meio de diagramação. Os modelo descritos nesta disciplina serão transformados em componentes durante o processo de implementação RTL. • Implementação RTL - etapa onde os componentes RTL do IP-core são
implementados, de acordo com os modelos de arquitetura previamente definidos. Nesta fase também são realizados testes de unidade, assim como a integração dos componentes. A implementação RTL é feita através de uma HDL (Hardware Description Language), como Verilog, VHDL ou SystemC. Nesta disciplina, o ipPROCESS recomenda a utilização da prática XP, denominada Pair Programming (BECK, 2004), a qual sugere que a implementação seja realizada em pares. Esta prática visa obter códigos de melhor qualidade, permitindo que mais de uma pessoa possua o domínio sobre o código-fonte produzido. O ipPROCESS adota, também extraído da XP, a prática denominada Coding Standards, a qual determina que todos os componentes devem seguir um mesmo padrão de codificação (BECK, 2004). • Verificação Funcional - o objetivo desta disciplina é avaliar e estimar a qualidade
do IP-core, a partir da verificação das funcionalidades implementadas a partir das descrições RTL e o atendimento aos requisitos de forma a validar:
– As restrições de projeto e da especificação de requisitos funcionais.
– Se os requisitos funcionais estão implementados em conformidade com a arquitetura, e as funcionalidades do IP-core atendem ao propósito para o qual foi projetado.
• Prototipação em FPGA - é nesta disciplina que ocorre a prototipação do IP-core em FPGA, a partir da síntese dos componentes RTL desenvolvidos, testes unitários e, por fim, os testes de integração dos mesmos em FPGA, tendo em vista a geração de um protótipo físico do IP-core.
• Distribuição - esta disciplina tem por objetivo produzir, reunir e fornecer os artefatos e informações necessárias para caracterizar o IP-core desenvolvido e diminuir o esforço de integração do VC em um SoC (SANTOS, 2007). Para que isso seja possível, ao longo de todo o desenvolvimento é produzida a documentação do usuário (SANTOS, 2006).
2.4 CONSIDERAÇÕES FINAIS
Este capítulo apresentou alguns conceitos fundamentais para a construção deste trabalho. Foram apresentados conceitos inerentes ao projeto de IP-core digitais, e ao modelo de processo ipPROCESS.
ipPROCESS é inspirada em processos de software, justificando assim a sua proposta e as especificações de distribuição de atividades em disciplinas e fases específicas e bem definidas. A utilização deste modelo, baseado nos alicerces apresentados na sua primeira versão, são identificados como instrumento metodológico capaz de instrumentalizar o processo de desenvolvimento de IP-cores sob o contexto da pesquisa acadêmica.
Nos capítulos seguintes serão apresentadas duas aplicações do ipPROCESS, objetivando a implementação de um conjunto de IP-cores destinados à aplicações que operam em modo gráfico. O trabalho destaca ainda a estrutura da metodologia aplicada, tendo em vista a sua adaptação para o contexto da pesquisa, definindo o processo de desenvolvimento da proposta, as restrições associadas a sua implementação e análise dos resultados por meio de estudos de caso em aplicações reais.
3 DESCRIÇÃO DO MODELO DE DESENVOLVIMENTO
A metodologia adotada neste projeto baseia-se nas atividades definidas pelo ipPROCESS, incluindo sua estrutura em fases de disciplinas. As sessões a seguir apresentam uma descrição das características específicas adotadas para o desenvolvimento deste projeto, justificando as adaptações e restrições impostas durante a fase de planejamento.
3.1 ORGANIZAÇÃO DO TRABALHO
A organização deste trabalho foi estabelecida a partir de duas grandes fases, constituídas, cada qual, por um conjunto restrito de atividades adotadas pelo ipPROCESS.
1. Implementação dos soft IP-cores - Esta fase consistiu na especificação, implementação, testes e prototipação do conjunto de soft IP-cores para aplicações gráficas, com prototipação em FPGA.
2. Validação & Avaliação - Após implementados, os módulos foram submetidos a uma série de testes de integração. Nesta etapa foram realizadas implementações e testes sob a perspectiva da construção de um protótipo de jogo de corrida de carros em FPGA e na avaliação dos resultados da utilização dos IP-cores no Módulo Integrador de Sistemas Digitais1.
Durante as duas grandes fases do projeto foi utilizada a mesma estrutura da metodologia de processo, com base nas especificações e restrições descritas nas seções seguintes. É válido ressaltar que a versão adotada do ipPROCESS não contempla as atividades referentes à disciplina Distribuição, motivo pela qual ela não está sendo tratada neste trabalho.
3.2 DISCIPLINAS E ATIVIDADES
Baseado nos modelos de documentação do ipPROCESS (LIMA, 2005), este projeto consistiu na elaboração de um conjunto de artefatos estruturados de acordo com as atividades determinadas dentro do contexto do processo. Por possuir características estritamente acadêmicas, diferente de um ambiente empresarial e devido a sobrecarga imposta pela concepção dos mesmos, certos artefatos de documentação foram eliminados da lista de componentes. As subseções a seguir apresentam as definições acerca destes 1Disciplina do quinto período do curso de Engenharia de Computação da Universidade Estadual de Feira de Santana
artefatos, delineando as atividades sob o escopo de cada disciplina e justificando a adoção dos mesmos, quando necessário.
3.2.1 Disciplina Requisitos
Para esta disciplina foram realizadas as atividades de Captura de Vocabulário Comum, Desenvolver Visão e Definir Requisitos (LIMA, 2005). Como resultado desta disciplina espera-se obter os artefatos Documento de Visão e Especificação de Requisitos.
• Documento de Visão - Apresenta uma visão geral da proposta de construção do conjunto de soft IP-cores. Foi utilizado como um meio de aproximação do processo de concepção de IP-cores com o meio externo, haja vista que este artefato apresenta descrições voltadas para o cliente;
• Especificação de Requisitos - Especifica os requisitos, funcionais e não funcionais do projeto. Este artefato é de extrema importância para definir a arquitetura e desenvolver os casos de uso para os componentes;
• Modelo de Casos de Uso - Apresenta uma visão inicial da arquitetura do sistema, utilizada como referência e é aprimorada nas fases posteriores;
3.2.2 Disciplina Análise & Projeto
Nesta disciplina foram realizadas as atividades de Análise Arquitetural, Projeto de Caso de Uso e Projeto de Componentes (LIMA, 2005). Como resultado desta disciplina espera-se obter os artefatos Diagramas de Caso de Uso e Diagramas de Classe.
• Diagramas de Caso de Uso - Documento que especifica os casos de uso dos sistemas e sub-sistemas envolvidos no projeto;
• Diagramas de Classe - Representa uma análise dos casos de uso, com vistas à implementação do modelo RTL (Register-Transfer Level).
3.2.3 Disciplina Implementação RTL
Nesta disciplina, diante daquelas sugeridas por (LIMA, 2005), o projeto limitou-se às seguintes de atividades: Implementar Componentes, Implementar Componentes de Teste e Realizar Testes. Diante desta característica, foram obtidos os artefatos Componente, Componente de Teste e IP-core. Esta restrição refere-se a ausência do artefato plano de integração, descartado na primeira fase do projeto e substituído pelo modelo de componentes, baseado em diagramas de classe.
3.2.3.1 Estruturação dos Componentes de Teste
O plano de verificação e testes de funcionalidades foi definido individualmente para cada IP-core, de acordo com sua classificação. Para módulos de diagramação foi utilizado o modelo apresentado na Figura 5a.
Para compor a implementação dos testes dos elementos de controle, foi utilizada a estrutura descrita na Figura 5b, a qual difere da estrutura anterior na adição do módulo de diagramação de primitivas. A adoção deste modelo se deu a partir da identificação da necessidade de se apresentar modelos gráficos para realização dos testes de forma correta.
(a) Módulos gráficos. (b) Unidades de controle. Figura 5: Estrutura dos componentes de teste para os IP-cores.
Dado o critério de dependência associado a este plano, o IP-core para controle de sinais de sincronismo VGA foi classificado como de prioridade essencial para o desenvolvimento dos outros componentes do conjunto. Consequentemente, este componente foi escolhido como o primeiro IP a ser implementado.
3.2.4 Disciplina Verificação Funcional
Sob a perspectiva de projeto de um IP-cores, a verificação funcional consiste em desenvolver modelos de referência, baseados nos requisitos funcionais, tendo em vista garantir o atendimento dos mesmos (BERGERON, 2003). Os modelos de referência, em geral, são estruturas de simulação em software projetadas de modo a corresponder com as funcionalidades especificadas. Durante as atividades da disciplina Verificação Funcional, o IP-core passa a ser chamado também de DUV (Design Under Verification). O processo de verificação das funcionalidades do IP-core é realizado a partir da geração de um conjunto de estímulos de entrada esperados pelo componente a ser testado. Os mesmos estímulos são apontados para as entradas do modelo de referência, haja vista comparar os resultados esperados e aqueles obtidos a partir do DUV. O ambiente utilizado para
desenvolvimento das verificações funcionais é denominado de testbench (BERGERON, 2003).
A verificação funcional pode demonstrar que o projeto atende aos requisitos funcionais, no entanto não pode se usada como instrumento de garantia de equivalência entre a implementação e as especificações. Durante os procedimentos de verificação é possível encontrar falhas (bugs) no sistema, as quais devem ser reportadas e devidamente corrigidas antes da etapa de prototipação. Apesar disso, nada pode-se dizer quanto a inexistência de outras falhas, mesmo que todos os estímulos tenham sido verificados.
No contexto de desenvolvimento de IP-cores, existe uma distinção entre os termos Verificação Funcional e Teste. Enquanto o objetivo da verificação funcional é demonstrar que a implementação do projeto reflete a funcionalidade desejada, o teste visa garantir que o projeto foi manufaturado corretamente em meio físico, seja como ASIC ou FPGA (LIMA, 2005). No ipPROCESS, os testes são realizados com prototipação em FPGA, tendo em vista garantir o funcionamento do sistema, antes da prototipação ASIC.
Visando reduzir a sobrecarga de trabalho imposta pela pelas atividades referentes à disciplina Verificação Funcional, destacando-se também o fato da equipe ser composta por apenas um desenvolvedor, foi definido que esta disciplina seria suprimida durante a execução deste projeto. Entretanto, parte da verificação funcional passou a fazer parte da etapa de prototipação, uma vez que, além dos testes, foram realizadas verificações baseadas em prototipação em FPGA.
3.2.5 Disciplina Prototipação em FPGA
As atividades realizadas ao longo desta disciplina consistem no processo definido como Integração do IP-core. O marco de finalização deste estágio foi baseado na finalização do IP-core (Prototipação).
3.3 ESPECIFICAÇÕES DA MODELAGEM
Tendo em vista o desenvolvimento de modelos de fácil compreensão para auxílio a implementação dos IP-cores, o ipPROCESS propõe a modelagem da arquitetura com base em casos de uso. Como uma forma de acelerar o processo de implementação RTL foram desenvolvidos também diagramas de classe, descrevendo as interfaces de E/S e funcionalidades de cada componente.
As subseções a seguir descrevem a estrutura de diagramação proposta por este trabalho, dando um significado específico ao formato utilizado, bem como detalha as especificidades de cada estrutura de modelagem.
3.3.1 Casos de Uso
Casos de uso representam partes distintas da funcionalidade de um sistema ou componente. Cada caso de uso é identificado por uma função ou ação, descrevendo a funcionalidade requerida em poucas palavras. Para melhor especificar um caso de uso, utilizam-se rótulos que descrevem o escopo da descrição do conjunto de casos de uso. Além disso, casos de uso podem ser inicializados por um componente, dentro ou fora do escopo do mesmo, através de entidades conhecidas como Atores (PILONE; PITMAN, 2005). Neste contexto, os atores representam os componentes do sistema responsáveis por estimular ou controlar um caso de uso. Um ator pode também ser afetado pela ação de um caso de uso.
O processo de construção de um caso de uso para o desenvolvimento de um IP-core consiste na identificação dos atores como componentes do IP, e os casos de uso, como as funcionalidades que o mesmo deve desempenhar. Para auxiliar o processo de desenvolvimento, identificando IP-cores reutilizados, na modelagem de componentes que reutilizam IP-cores do conjunto, os atores correspondentes à estes IP-cores são identificados por um retângulo, descrevendo o escopo e o nome do mesmo. A presença de mais de uma instância é representada por dois retângulos sobrepostos, como apresentado na Figura 6. Speedway Display Background Static Elements Dinamic Elements «extend» «extend» Object Draw «Controller» «extend» «extend» Speedway Draw
3.3.2 Diagramas de Classes
Para incrementar o suporte à descrição RTL dos IP-cores, o projeto propõe a realização dos casos de uso sob a forma de diagramas de classes. Uma classe é representada como um módulo, ou componente do IP-core. Métodos e atributos públicos representam, respectivamente, as suas funcionalidades e portas de entrada e saída. Além disso, é possível identificar instâncias de módulos ou componentes que fazem parte da estrutura interna do IP-core. Estes elementos são representados como atributos privados. Registradores e elementos de ligação internos que mereçam destaque na modelagem devem ser representadas como atributos de implementação. A Figura 7 apresenta um exemplo de diagrama de classes, no qual para cada classe é possível identificar o escopo e especificações de entrada e saída, além das relações que existem entre os componentes.
Figura 7: Exemplo de diagrama de classes.
A modelagem de classes adota o padrão de desenvolvimento de software MVC (Model-View-Control) (GAMMA et al., 1994), distribuindo as classes a partir da identificação do seu escopo dentro do sistema. Dessa forma, elementos de diagramação
e primitivas de modelagem de pixel são classificadas como classes Model, enquanto as classes responsáveis pela manipulação das informações e gestão do fluxo de operações são inseridas na camada Control. Por fim, as interfaces de E/S são caracterizadas sob o escopo da camada View.
Da mesma forma que nos diagramas de casos de uso, os componentes reutilizados são representados por retângulos devidamente associados às classes que os utilizam. No exemplo da Figura 7, a classe SquareDraw é utilizada para compor a diagramação dos elementos que compõem o carro de corrida, tais como, a roda, a carenagem e o piloto.
3.4 CRITÉRIOS PARA ANÁLISE DE ESFORÇO
A equipe de desenvolvimento foi formada por um desenvolvedor, responsável por realizar todas as fases do ipPROCESS. As análises de esforço realizadas neste trabalho utiliza as medidas de trabalho em função da quantidade de semanas necessárias para produzir cada artefato, ou atingir um marco. A carga horária desprendida considerada por este trabalho corresponde a 5 horas por semana.
4 DESENVOLVIMENTO DO CONJUNTO DE SOFT IP-CORES
Este capítulo apresenta os resultados obtidos a partir do desenvolvimento do conjunto de soft IP-cores, sob o qual o ipPROCESS foi aplicado como metodologia de processo. Durante esta primeira fase do projeto, o ciclo de vida do ipPROCESS foi realizado de forma completa para cada um dos IP-cores, tendo em vista manter o foco das atividades desenvolvidas, uma vez que nem todos os módulos possuem relação de integração direta.
Esta etapa do projeto, composta pelo desenvolvimento dos componentes sem integração formal, teve duração total de seis meses. As seções a seguir apresentam uma descrição do processo de desenvolvimento dos soft IP-cores.
4.1 DESCRIÇÃO DOS IP-CORES
Apesar dos avanços tecnológicos e a crescente adoção de sistemas de interface gráfica com o usuário em software, o desenvolvimento de aplicações que operam em modo gráfico ainda ocupam um lugar de importância no desenvolvimento de SoC. Além de serem utilizadas em um vasto conjunto de sistemas de monitoramento e controle digital, nos quais uma interface com um computador pessoal não se faça viável, este tipo de aplicação serve também como elemento motivador no processo de aprendizagem, quando aplicado ao ensino de Arquitetura de Computadores, por exemplo (OLIVEIRA; ARRUDA; BITTENCOURT, 2007).
Um dos principais problemas que podem ser verificados em grandes projetos que usam módulos gráficos acontece ainda nas etapas iniciais. Observa-se que os projetistas gastam muito tempo definindo as especificações e implementando componentes básicos da interface gráfica, como por exemplo os sinais de sincronismo para monitores VGA, ou a diagramação correta de objetos na tela.
Em linhas gerais, o produto gerado nesta primeira fase do projeto consiste de um conjunto de soft IP-cores, baseados em reuso, com vistas ao desenvolvimento de aplicações que operam em modo gráfico, e com prototipação em FPGA. O conjunto é formado por módulos básicos para a construção destas aplicações, focando sua aplicação nas interfaces de entrada e saída, bem como definindo um escopo estrutural para a implementação do controle geral. As subseções a seguir apresentam uma breve descrição dos IP-cores que compõem este conjunto.
4.1.1 Controlador de Vídeo para o Padrão VGA
Este controlador e formado pelo conjunto de componentes responsáveis por disponibilizar uma interface de visualização do vídeo em um monitor compatível com o padrão VGA. O IP-core é capaz de gerar os sinais de sincronismo horizontal e vertical, além de ser capaz de codificar as cores que serão exibidas na tela para cada um dos elementos, de acordo com as especificações do produto final.
4.1.2 Controlador de Movimentação de Objetos em uma Região da Tela
Controle destinado a manipulação de um objeto ao longo de uma região limitada da tela. A partir de comandos em um controle digital, o usuário deve ser capaz de interagir com um dos elementos gráficos, movimentando-os ao longo da tela.
4.1.3 Detector de Colisão Entre Dois Objetos na Tela
Controle voltado para a identificação de colisão entre dois objetos.
4.1.4 Modelo de Diagramação de Objetos Retangulares
Modelo responsável por “desenhar” um objeto retangular (ou uma linha) ao longo da tela, de acordo com as especificação de requisitos. O objetivo deste IP-core é servir de base para a diagramação de objetos complexos a partir do uso de formas primitivas retangulares.
4.1.5 Controle de Entrada dos Botões
Circuito necessário para controlar a interface de entrada por meio de botões do tipo push-button. Em função das características deste tipo de botão, este circuito faz-se necessário de modo a garantir a integridade dos sinais de entrada. Seu funcionamento consiste em desprezar pulsos “falsos” na entrada do circuito devido aos pulsos elétricos gerados a partir dos contatos dos botões, mesmo quando não pressionado.
4.1.6 Controle de Diagramação de Strings
Utiliza módulos primitivos para compor elementos de uma string baseando-se no modelo de display de sete segmentos.
4.2 ALOCAÇÃO DE PAPÉIS
O projeto foi desenvolvido sob a forma de Trabalho de Conclusão de Curso, na UEFS, consistindo de uma equipe formada por três membros. A equipe de
desenvolvimento era formada por um aluno de graduação sem experiência prévia no desenvolvimento de IP-cores sob o contexto do ipPROCESS. Os demais membros da equipe formam o grupo de gestão formado por um coordenador (orientador), responsável por definir o escopo e analisar os resultados, e um consultor ad-hoc, coordenador do projeto Brazil-IP na instituição.
Com base nesta estrutura, o desenvolvedor teve a oportunidade de conhecer o funcionamento de todos os módulos do conjunto e, além disso, foi possível a este atuar em diferentes papéis e passar por todas as fases do processo de desenvolvimento de um IP-core.
4.3 FASE CONCEPÇÃO
No ipPROCESS, esta é a primeira fase do desenvolvimento de um IP-core e tem como objetivo identificar os requisitos do projeto, fechar o escopo, e compreender as funcionalidades dos IP-cores (LIMA, 2005). Esta fase consistiu na criação dos artefatos Especificação de Requisitos e Diagramação de Caso de Uso.
4.3.1 Levantamento de Requisitos
O processo de elaboração dos artefatos ao longo desta fase foram executadas a partir das seguintes atividades:
• Atividade Captura de Vocabulário Usual, Disciplina Requisitos -constituída a partir da pesquisa acerca dos módulos mais importantes, em termos de reuso de IP-cores, apresentando um conjunto de termos e definições que foram utilizadas ao longo do projeto.
• Atividade Desenvolver Visão, Disciplina Requisitos - criação de um documento de visão, no qual são levantados os aspectos de motivação e justificativa para o desenvolvimento do projeto.
• Atividade Definição de Requisitos, Disciplina Requisitos - análise das necessidades do projeto, pesquisa sobre as características dos circuitos a serem implementados, e levantamento dos FR (Requisitos Funcionais) e NFR (Requisitos não Funcionais) para os soft IP-cores.
Ao final desta disciplina, foram definidos 12 requisitos para a versão final do conjunto, sendo oito deles FR e quatro NFR. As subseções a seguir apresentam estas especificações.
4.3.1.1 Especificações de Resolução da Tela
Em monitores do tipo CRT (Cathode Ray Tube) a imagem é formada pela emissão de elétrons através de um ‘canhão de elétrons’ sob uma superfície fosfórica, gerando um ponto na tela (pixel). Em cada etapa é desenhado um novo ponto na tela até que se realize uma varredura completa na tela. A intensidade do brilho do ponto exibido é controlada pelo nível de tensão introduzido pelo sinal de vídeo. O controle do caminho percorrido pelo feixe de elétrons é feito através de placas defletoras, horizontal e vertical, que produzem um campo magnético determinando o caminho que o elétron deve percorrer.
Um controlador de vídeo é responsável por gerar os sinais de sincronismo e as saídas de dados para cada pixel de forma serial. O sincronismo horizontal (hsync) especifica o tempo requerido para percorrer uma linha, o vertical (vsync) controla o tempo necessário para percorrer toda a tela (CHU, 2008). Sendo assim, um circuito digital de controle dos sinais de sincronismo requer que sejam definidas, de forma objetiva, a porção visível da tela no monitor.
Monitores CRT, durante o sincronismo horizontal, apresentam uma pequena borda preta ao redor da imagem, definidas a partir dos valores de back porch (borda da esquerda) e front portch (borda da direita). Durante o sincronismo vertical também são verificadas regiões onde o sinal de vídeo deve ser desativado, regiões estas chamadas de bottom border e top border (IBM, 1992). Estes dados, além de todos os elementos que compõem uma varredura horizontal e vertical, são descritos na Figura 8. Nela é apresentado um diagrama dos ciclos de sincronismo horizontal e vertical para dispositivos CRT com resolução de 640x480 pixels, baseado no padrão VGA (Video Graphics Array).
Analisando os sinais de sincronismo de um controlador VGA, existe ainda, além dos sinais de sincronismo hsync e vsync, o retraço horizontal e vertical. Assim como nas bordas, durante o retraço o sinal de vídeo deve ser desativado. No retraço horizontal, o sinal de vídeo deve ser desativado na região onde o feixe de elétrons retorna para a borda esquerda. No retraço vertical, o sinal deve ser desligado na região em que o feixe retorna para o topo da tela.
As informações contidas nestes requisitos (Tabela 1) basearam-se também padrão VGA estabelecido pela VESA/IBM (IBM, 1992). As siglas adotadas nesta Tabela serão consideradas ao longo deste documento.
4.3.1.2 Valor Limite para o Contador da Varredura Horizontal
Este requisito refere-se ao padrão utilizado para definição do parâmetro do contador responsável por representar os controles de varredura da tela no sentido horizontal. O
fundo de Tela região de borda sinal de defleção contador de linha (vsync)
top_border bottom border
front porch
retraço
top border back porch área visível (vertical)
contador de pontos (hsync)
left_border
área visível (horizontal)
left border back porch retraço horizontal right border front porch
Figura 8: Diagrama de tempo do processo de varredura horizontal e vertical. Fonte: Adaptado de (CHU, 2008).
valor máximo de contagem horizontal é limitado pelo HTP (Total de Pixels Horizontais), o qual pode ser expresso matematicamente como:
HP T = HRES + HF + HB + HR (1)
4.3.1.3 Valor Limite para o Contador da Varredura Vertical
Este requisito refere-se ao padrão utilizado para definição do parâmetro do contador responsável por representar o controle de varredura da tela no sentido vertical. Defini-se o valor máximo de contagem do mesmo como o VTP (Total de Pixels Verticais), e este pode ser expresso matematicamente como:
Tabela 1: Definições de parâmetros de resolução da tela.
Elemento Sigla Pixels
Tamanho Horizontal HRES 640
Front Porch Horizontal HF 16 Back Porch Horizontal HB 48
Retraço Horizontal HR 96
Total de Pixeis Horizontal HPT 800
Tamanho Vertical VRES 480
Front Porch Vertical VF 10 Back Porch Vertical VB 33
Retraço Vertical VR 2
Total de Pixeis Vertical VPT 525
V P T = V RES + V F + V B + V R (2)
4.3.1.4 Período de Acionamento do Sinal de Sincronismo Horizontal
O sinal de sincronismo horizontal deve ser acionado quando o contador horizontal (hCounter) atender à seguinte condição:
hCounter = HB + HRES + HF (3)
4.3.1.5 Período de Permanência do Sinal de Sincronismo Horizontal
O sinal de sincronismo horizontal indica que o canhão percorreu todo o eixo horizontal da tela do monitor. Este sinal deve permanecer ativo por um período suficiente para que o raio percorra a porção correspondente ao retraço horizontal, como representado na Figura 9.
4.3.1.6 Período de Acionamento do Sinal de Sincronismo Vertical
O sinal de sincronismo vertical deve ser acionado assim que o contador vertical (vCounter) atender à seguinte condição:
vCounter = V H + V RES + V F (4)
4.3.1.7 Período de Permanência do Sinal de Sincronismo Vertical
O sinal de sincronismo horizontal indica que o canhão percorreu todo o eixo vertical da tela do monitor. Este sinal deve permanecer ativo por um período suficiente para que o raio percorra a porção correspondente ao retraço vertical, como representado na Figura 10.
Figura 10: Representação do sinal de sincronismo vertical.
4.3.1.8 Área Visível da Tela
A área visível representa a região da tela onde o conteúdo será exibido. Para determiná-la é preciso ter uma visão geral do controle de sincronismo. Esta área é determinada como sendo a região delimitada pelos intervalos de front porch e back porch vertical e horizontal. Dessa forma, área visível pode ser determinada a partir da relação booleana abaixo.
(HT P = 800) ∧ (vCounter < V RES) (5)
4.3.1.9 Padrão de Cores RGB
A Tabela 2 apresenta o conjunto de códigos correspondentes a cada cor no padrão de 3 bits que deve ser utilizado para codificar a apresentação das cores dos objetos na tela.
Tabela 2: Código de cores no padrão RGB de 8 cores.
Cor Código Binário
Preto 000 Azul 001 Verde 010 Ciano 011 Vermelho 100 Magenta 101 Amarelo 110 Branco 111
4.3.1.10 Tamanho dos Caracteres
A exibição de uma cadeia de caracteres pode assumir cinco tamanhos diferentes. A codificação da Tabela 3 determina os tamanhos que este conjunto pode assumir. Cada caractere é representado por sete segmentos, dispostos de forma quadrada.
Tabela 3: Códigos de tamanho dos caracteres. Código Tamanho (px) 001 16 x 16 010 32 x 32 011 64 x 64 100 128 x 128 101 256 x 256
4.3.1.11 Posicionamento dos Caracteres
A posição inicial da String, é definida por espaçamentos, horizontal (a partir da esquerda) e vertical (a partir do topo). Este valor deve ser, preferencialmente, múltiplo do tamanho da fonte.
4.3.1.12 Conjunto de Caracteres ASCII Suportados
A aplicação deve ser capaz de decodificar os caracteres do alfabeto maiúsculo (A .. Z) e o conjunto numérico (0 .. 9).
4.4 FASE ARQUITETURA
Na fase de Arquitetura é onde a modelagem do IP-core é definida, com os casos de uso detalhados por meio da Disciplina Análise & Projeto do ipPROCESS (LIMA, 2005).
4.4.1 Definição da Arquitetura e Detalhamento dos Casos de Uso
A partir da definição dos requisitos, e da visão geral dos componentes do conjunto de soft IP-cores, foram definidos os elementos de arquitetura de cada um deles. Por se tratar de um conjunto de IP-cores concebido de forma desacoplada, não foi projetada uma arquitetura geral, sob a forma de sistema. O projeto da arquitetura consistiu em um conjunto de diagramas de caso de uso e classes para cada IP-core. Dessa forma, a concentração maior de esforço nesta fase foi dada à atividade Projeto de Casos de Uso, na qual, a partir das especificações da arquitetura, cada IP-core foi descrito sob a forma de casos de uso, incorporando suas funcionalidades e relações entre componentes. Os diagramas de caso de uso obtidos durante esta etapa são apresentados no Apêndice C. Nesta fase são definidos também os planos de implementação RTL e verificação funcional (LIMA, 2005). Dessa forma, foi estabelecido que, por se tratar de IP-cores para aplicações em modo gráfico, estes processos seriam realizado sob a forma de prototipação em FPGA, como descrito na Seção 3.2.3.1. Ao final desta etapa, em termos de artefatos, foram obtidos 11 casos de uso e 6 diagramas de classes.
4.5 PROJETO RTL
Nesta fase, os componentes descritos na fase Arquitetura foram implementados e testados, visando atender aos requisitos e planejamentos definidos ao longo das fases anteriores.
Os módulos foram descritos em linguagem Verilog e sintetizados a partir da ferramenta de síntese, projeto e simulação Altera Quartus II v11.0 (ALTERA, 2011), com testes de prototipação realizados no CI FPGA ALTERA Cyclone II EP2C35F672C6N. Utilizando o mesmo critério de análise estabelecido por Lima (2005), a Tabela 4 apresenta o número de linhas de código para cada IP-core do conjunto.
Tabela 4: Resultados da disciplina Implementação RTL.
Componente Linhas %
Controlador VGA/RGB 159 24
Modelo de Objetos Retangulares 20 3
Controle de Colisão 91 13
Controle de Exibição de Strings 263 39
Controlador de posição 107 16
Circuito Debouncer 36 5
Total 676 100
Além da implementação RTL, esta etapa consistiu no desenvolvimento e realização de testes funcionais. Tendo em vista validar a sua funcionalidade, além da análise em software, os IP-cores foram testados a partir de prototipação em FPGA. Os testes foram realizados, as falhas foram identificadas e os módulos foram validados quando não foram encontrados mais erros. Ao mesmo tempo em que os módulos foram implementados, foram verificadas e corrigidas inconsistências na documentação e falhas de implementação, uma vez que estes problemas são, na maioria dos casos, identificados durante o processo de teste.
4.6 PROTOTIPAÇÃO FÍSICA
Para o ipPROCESS esta é a última fase do desenvolvimento de um IP-core, na qual o objetivo é criar um protótipo físico do IP-core em FPGA tendo em vista validar o modelo de simulação criado na fase Implementação RTL (LIMA, 2005).
Esta fase do projeto de construção dos soft IP-cores foi por vezes confundida com a verificação funcional realizada na fase anterior, uma vez que parte dos testes foram realizados a partir de síntese e prototipação em um FPGA. Diante disso, o processo de prototipação física foi transferido para a segunda fase do projeto, uma vez que esta consiste na validação dos IP-cores a partir da construção de uma aplicação capaz de integrar todos os IP-cores implementados.
Durante esta fase do projeto não foram realizadas integrações entre os módulos, haja vista que o mesmo consistiu na concepção de IP-cores na forma de componentes individuais. A Tabela 5 apresenta os resultados em termos de utilização de células lógicas (slices). Os dados referentes à síntese destes IP-cores pode ser utilizada como ferramenta de análise de requisitos de um novo projeto baseado na composição destas estruturas,
servindo de ferramenta de auxílio no processo de tomada de decisão.
Tabela 5: Resultados da disciplina Prototipação em FPGA.
Componente Slices %
Controlador VGA/RGB 43 < 1
Modelo de Objetos Retangulares 58 < 1
Controle de Colisão 104 < 1
Controle de Exibição de Strings 449 1
Controlador de posição 45 < 1
Circuito Debouncer 24 < 1
Os dados da Tabela 5 foram obtidos a partir do síntese física no componente FPGA ALTERA Cyclone II EP2C35F672C6N (ALTERA, 2008), com otimização definida para melhor consumo de área em chip.
4.7 CONSIDERAÇÕES FINAIS
Este capítulo apresentou os resultados da aplicação do ipPROCESS ao desenvolvimento de um conjunto de IP-cores para aplicações que operam em modo gráfico, com prototipação em FPGA.
Um dos principais fatores agravantes no processo de desenvolvimento dos IP-cores foi identificado no fato da equipe ser formada por apenas um desenvolvedor. Uma das lições que o ipPROCESS destaca é que o desenvolvimento pode ser otimizado com uso de técnicas como o XP (eXtreme Programming). Com apenas um desenvolvedor o processo de descrição dos requisitos e projeto RTL pode ser conduzido de forma polarizada, aumentando os riscos de falhas durante a verificação funcional, uma vez que esta característica reduz o poder de cítica e a antecipação da identificação de possíveis falhas.
No que diz respeito ao uso do ipPROCESS, apesar da dificuldade de adaptação inicial, o processo de desenvolvimento ao longo das fases do processo se deu de forma natural, constatando que a metodologia é de fato coerente, também no que diz respeito a trabalhos desenvolvidos em IES (Instituições de Ensino Superior). Esta fase do projeto foi concluída em 6 meses, incluindo o período de adaptação ao método do ipPROCESS, tempo este que foi considerado satisfatório pela equipe. A principal deficiência da execução do processo foi dada pela dificuldade na realização das atividades relacionadas à disciplina Verificação Funcional. Durante a etapa de planejamento, não foi possível identificar, de
