3.1
Metodologia
Esta se¸c˜ao trata das metodologias utilizadas nesse projeto, a saber, o ipProcess e a metodologia de verifica¸c˜ao BVM (Metodologia de Verifica¸c˜ao do Brazil-IP – Brazil-IP Verification Methodology), assim como a ferramenta eTBc utilizada no BVM.
3.1.1
ipProcess
O ipProcess ´e um processo para desenvolvimento de IP-Core com implementa¸c˜ao em FPGA, elaborado pela rede Brazil-IP, como resultado do projeto Fˆenix (BARROS et al., 2005). A meta desse processo ´e garantir a qualidade do projeto de cada componente do sistema no decorrer do processo de desenvolvimento de um IP-Core.
Seus principais pilares s˜ao:
• Projeto iterativo e incremental, diagramas UML-RT (Linguagem de Modelagem Unificada para Tempo Real) (OMG, 2009);
• Uso de diretrizes (guidelines) de codifica¸c˜ao;
• Verifica¸c˜ao; e
• Programa¸c˜ao em pares5.
A vers˜ao atual do ipProcess, conforme (BARROS et al., 2005), ´e definida por cinco principais fluxos de trabalho (workflow ), conforme Figura 7. Cada fluxo ´e descrito a seguir:
5Pr´atica utilizada na metodologia ´agil XP (eXtreme Programming – Programa¸c˜ao Extrema), a qual
sugere que todo e qualquer c´odigo produzido no projeto seja sempre implementado por duas pessoas juntas.
Requisitos – Estabelece e documenta as necessidades do cliente e de outros usu´arios, consoante ao que o IP-Core deve fazer, de forma a fornecer `a equipe de desen- volvimento melhor entendimento sobre os requisitos funcionais e n˜ao funcionais do sistema;
An´alise & Projeto – De acordo com os documento de requisitos, cria-se um projeto de IP-core, compatibilizando-o ao ambiente de implementa¸c˜ao;
Implementa¸c˜ao – Define a organiza¸c˜ao da codifica¸c˜ao, implementa os elementos do projeto e, ap´os, realiza teste de unidade nos m´odulos desenvolvidos;
Verifica¸c˜ao – Avalia a qualidade do IP-Core no sentido de verificar se os requisitos foram implementados como especificado, al´em de procurar e descrever defeitos na implementa¸c˜ao e validar as funcionalidades do mesmo; e
Prototipa¸c˜ao em FPGA – Sintetiza a implementa¸c˜ao em um FPGA e valida os requi- sitos como especificados no fluxo de trabalho Requisitos.
Figura 7: Fluxograma do ipProcess
Cada fluxo de trabalho mencionado acima ´e definido em termos de fun¸c˜oes, atividades e cria¸c˜ao de artefatos (diagramas UML, documentos, linhas de c´odigo, etc), estes artefatos podem ser reutilizados como entrada em um fluxo de trabalho subseq¨uente, respeitando a ordem das fases apresentadas na Figura 8, a qual tamb´em apresenta a evolu¸c˜ao temporal de cada fluxo. Os artefatos s˜ao importantes, pois definem o escopo do projeto, fornecendo de forma clara o objetivo do projeto e como execut´a-lo, al´em de permitir que todo o desenvolvimento esteja de acordo com os anseios do cliente. Como n˜ao ´e escopo desse trabalho delinear minuciosamente o ipProcess, mais detalhes podem ser obtidos em (LIMA, 2005).
Figura 8: Fases do ipProcess
Esse processo tem sido utilizado no treinamento de estudantes de gradua¸c˜ao em pro- jetos de sistemas, aprovados pelo Brazil-IP. Uma vez que ao utilizar uma metodologia de projeto bem definida, em termos de atividades, facilita e acelera o aprendizado de projetos de IP para os estudantes.
3.1.2
Verifica¸c˜ao
Segundo Bergeron (BERGERON, 2003), verifica¸c˜ao ´e um processo usado para demons-
trar que o objetivo do projeto ´e preservado em sua implementa¸c˜ao. Para Mintz e Ekendahl (MINTZ; EKENDAHL, 2007), verifica¸c˜ao funcional ´e o emprego de software para assegurar que o DUT (Dispositivo sob Teste - Device Under Test ) opera como especificado, antes de ser montado e produzido em escala comercial. Para Spear (SPEAR, 2008), o prop´osito
de um engenheiro de verifica¸c˜ao ´e ter a certeza que o dispositivo pode cumprir satisfato- riamente a tarefa, isto ´e, que o projeto reflete fielmente a especifica¸c˜ao, de forma que a ocorrˆencia de erros (bugs) significa a existˆencia de discrepˆancias. Portanto, pode-se con- cluir que o objetivo da verifica¸c˜ao ´e comprovar se a implementa¸c˜ao seguiu corretamente a especifica¸c˜ao (ipProcess – ver subse¸c˜ao 3.1.1).
A verifica¸c˜ao ´e importante na redu¸c˜ao dos custos e do tempo de projeto, como tamb´em ao assegurar a qualidade do mesmo, visto que o custo de corre¸c˜ao de uma falha do sistema aumenta ao longo do fluxo do projeto - veja Figura 9. Com o aumento crescente da complexidade de projetos de circuitos integrados (basta verificar, na Figura 10, a validade da Lei de Moore (MOORE, 2000) nos circuitos atuais) a verifica¸c˜ao desempenha papel
importante nesses projetos, despendendo, normalmente, cerca de 70% do esfor¸co total (BERGERON, 2003).
Figura 9: Evolu¸c˜ao do custo em um projeto de CI (BERGERON et al., 2005)
Figura 10: Lei de Moore (PRADO, 2007)
3.1.2.1 Tecnologias de Verifica¸c˜ao
De acordo com Bergeron (BERGERON, 2003) as principais tecnologias de verifica¸c˜ao s˜ao:
Linting – As ferramentas lint realizam an´alise sint´atica em busca de erros de pro- grama¸c˜ao comuns, relatando potenciais problemas e pr´aticas question´aveis. Essas ferramentas s˜ao limitadas, devido `a natureza est´atica da an´alise, a qual n˜ao verifica o algoritmo ou o fluxo dos dados.
Simula¸c˜ao – Tenta criar um universo artificial que imite o futuro universo real do projeto, portanto, ´e uma aproxima¸c˜ao da realidade. O problema desta t´ecnica reside na corretude funcional e precis˜ao do modelo, j´a que n˜ao pode provar que erros n˜ao existam. Al´em disso h´a o problema do custo computacional e a inviabilidade, para circuitos complexos, de testar todos os padr˜oes de entrada ao longo do tempo.
Diagramas de forma de ondas – T´ecnica bastante utilizada em conjunto com a si- mula¸c˜ao. Permite a visualiza¸c˜ao de diversas transi¸c˜oes de sinais no tempo, al´em de suas rela¸c˜oes com outras transi¸c˜oes. ´E pratica para um conjunto de pouco sinais e transa¸c˜oes, com a crescente complexidade dos projetos, seu uso torna-se desvanta- joso e pass´ıvel de erros.
Cobertura de c´odigo – Identifica qual c´odigo foi ou n˜ao executado na verifica¸c˜ao. Co- leta um conjunto de m´etricas que objetiva facilitar a an´alise de verifica¸c˜ao, dentre elas: cobertura de declara¸c˜oes (bloco), cobertura de caminho, cobertura de ex- press˜oes e cobertura de MEF (M´aquina de Estados Finitos).
Verifica¸c˜ao funcional – Assegura que a verifica¸c˜ao estimulou o projeto por uma faixa de valores mais vantajosa, quer dizer, de interesse da equipe de verifica¸c˜ao. Enquanto a cobertura de c´odigo avalia o quanto da implementa¸c˜ao foi exercitada, a verifica¸c˜ao funcional examina o quanto da especifica¸c˜ao do projeto original foi exercitado.
O termo testbench se refere ao c´odigo de simula¸c˜ao usado para gerar est´ımulos para a verifica¸c˜ao de funcionalidades espec´ıficas do projeto, o que permite criar cen´ario de verifica¸c˜ao mais realistas (VIJAYARAGHAVAN; RAMANTHAN, 2005). Segundo o mesmo
autor, os testbenches s˜ao respons´aveis por trˆes tarefas:
1. Gera¸c˜ao de est´ımulos.
2. Mecanismos de auto verifica¸c˜ao.
3. Mensura¸c˜ao da cobertura funcional.
3.1.2.2 BVM
No contexto do Brazil-IP, foi desenvolvida a metodologia de verifica¸c˜ao BVM, a qual ´e formada pelas melhores pr´aticas da metodologia VeriSC unidas `a metodologia OVM (Metodologia de Verifica¸c˜ao Aberta - Open Verification Methodology).
O VeriSC ´e uma metodologia de verifica¸c˜ao funcional, desenvolvida usando bibliotecas do SystemC, com o objetivo de reduzir o tempo do processo de verifica¸c˜ao e encontrar erros, t˜ao logo quanto poss´ıvel, nas fases iniciais do fluxo desse processo (SILVA et al., 2006). Ela permite a constru¸c˜ao de um testbench completamente funcional, antes da implementa¸c˜ao do DUV ( Projeto sob Verifica¸c˜ao - Design Under Verification) iniciar. Desta forma, o testbench n˜ao precisa ser adaptado ao DUV, uma vez que enquanto este est´a sendo implementado, aquele j´a o foi. Al´em disso, essa metodologia permite o re´uso dos elementos que comp˜oem o testbench, para executar um auto-teste e assegurar que o mesmo n˜ao contenha erros. Para isso, utiliza-se um mecanismo para simular a presen¸ca do DUV unicamente com os elementos do testbench, sem usar nenhum artif´ıcio extra (MELCHER, 2008).
O OVM ´e uma metodologia de verifica¸c˜ao funcional, n˜ao propriet´aria, baseada no padr˜ao IEEE 1800 SystemVerilog. Foi criada pelas empresas Mentor Graphics e Cadence (desenvolvedoras de solu¸c˜oes EDA - Automa¸c˜ao de Projetos Eletrˆonicos - Eletronic Design Automation), com base em metodologias de verifica¸c˜ao origin´arias das duas corpora¸c˜oes (DOULOS LTDA, 2008), a saber: AVM (Metodologia Verifica¸c˜ao Avan¸cada - Advanced Verification Methodology) e URM (Metodologia de Re´uso Universal - Universal Reuse Methodology). Ambas corpora¸c˜oes trabalham juntas para desenvolver o OVM.
A metodologia OVM ´e sofisticada, sendo capaz de criar testbenches de ponta, asse- gurar interoperabilidade e promover o re´uso na verifica¸c˜ao (MENTOR; CADENCE, 2007). Mais especificamente, ela fornece uma biblioteca de classes b´asicas, servi¸cos ´uteis e outra facilidades de suporte para concentrar os esfor¸cos na aplica¸c˜ao do SystemVerilog ao pro- blema de verifica¸c˜ao. Para facilitar o re´uso de c´odigo dos componentes de verifica¸c˜ao e do testbench, a OVM emprega uma arquitetura de verifica¸c˜ao que fornece um consistente conjunto de interfaces bem definidas, atrav´es das quais componentes interagem uns com os outros e com o ambiente de verifica¸c˜ao (FITZPATRICK; ANDERSON, 2008). Al´em disso, a comunica¸c˜ao entre os componentes do testbench ocorre atrav´es do padr˜ao de interface TLM (Modelagem em N´ıvel de Transa¸c˜oes - Transaction-Level Modeling), enfatizando o aspecto do re´uso de c´odigo. TLM ´e uma t´ecnica de alto n´ıvel para modelar sistemas digitais, na qual os detalhes da comunica¸c˜ao entre os m´odulos s˜ao separados dos detalhes da implementa¸c˜ao das unidades funcionais ou da arquitetura de comunica¸c˜ao. Nesse con- texto, uma transa¸c˜ao ´e uma opera¸c˜ao que se inicia num determinado momento no tempo e termina em outro. ´E caracterizada pelo conjunto de instru¸c˜oes e dados necess´arios para realizar uma opera¸c˜ao (MELCHER, 2008). Exemplos: transmiss˜ao de um pacote ethernet, recep¸c˜ao de uma imagem, uma escrita num barramento, entre outros.
Figura 11: Metodologias BVM e OVM – Fluxo de projeto
Uma das principais mudan¸cas entre BVM e OVM ocorre no fluxo do projeto, conforme Figura 11: no fluxo da OVM a implementa¸c˜ao do RTL ocorre antes da implementa¸c˜ao do testbench; j´a no fluxo do BVM, origin´ario do VeriSC, essa ordem foi invertida, de forma que a implementa¸c˜ao do testbench ´e realizada antes da implementa¸c˜ao do RTL. Por outro lado, a BVM utiliza o padr˜ao IEEE 1800 SystemVerilog do OVM, uma vez que o VeriSC ´e baseado no SystemC.
3.1.2.3 eTBc
A metodologia BVM utiliza uma ferramenta para gerar templates6 para o processo de verifica¸c˜ao, reduzindo o esfor¸co, o tempo do processo de verifica¸c˜ao e a taxa de erros. Essa ferramenta ´e o eTBc, a qual foi inicialmente criada para a metodologia VeriSC (SILVA et al., 2004), sendo posteriormente adaptada ao SystemVerilog, atual base da metodologia BVM. Tal ferramenta gera todos os templates dos m´odulos que comp˜oe o testbench, adaptando- os ao DUV - tais m´odulos s˜ao apresentados na Figura 12, exceto o DUV que ´e o projeto a ser testado em si. Na sequˆencia, s˜ao explicadas as funcionalidades de cada m´odulo, os quais s˜ao apresentados com o nomes originais do padr˜ao, sem tradu¸c˜ao.
Reference Model – Modela a funcionalidade do DUV, possuindo o mesmo comporta- mento que esse. Deve ser implementado pelo engenheiro de verifica¸c˜ao em uma
Figura 12: M´odulos do testbench gerados pelo eTBc.
abstra¸c˜ao diferente do RTL, assim, tende a ser escrita em qualquer linguagem de alto n´ıvel. O n´ıvel RTL deve ser evitado, pois o engenheiro poderia cometer erros que cometeria com o DUV. O modelo de referˆencia ´e indispens´avel para a execu¸c˜ao da verifica¸c˜ao.
Source – Envia transa¸c˜oes de entrada para o driver e para o reference model ;
Checker – Compara as transa¸c˜oes de sa´ıda recebidas do monitor com as de um reference model ;
Driver – Recebe transa¸c˜oes de entrada e as converte em transi¸c˜oes de sinais da interface de entrada do DUV;
Monitor – Observa sinais da interface de sa´ıda do DUV e gera transa¸c˜oes de sa´ıda que ele repassa para o checker ; e
Ator – Observa sinais da interface de sa´ıda do DUV e implementa, caso necess´ario, protocolo de handshake7. N˜ao existe comunica¸c˜ao entre o Ator e o Monitor.
Por produzir somente os templates, boa parte do trabalho ainda deve ser efetu- ada pelo engenheiro de verifica¸c˜ao, como defini¸c˜oes de handshake de sinal, m´etricas de cobertura e distribui¸c˜ao dos sinais de entrada, dentre outras configura¸c˜oes. Na metodologia BVM, o eTBc auxilia e acelera a produ¸c˜ao do ambiente do testbench, inclusive na fase de teste dos seus componentes, auxiliando na gera¸c˜ao de um am- biente de verifica¸c˜ao livre de erros e j´a adaptado ao DUV.