Verifica¸ c˜ ao Funcional

Esta se¸c˜ao descreve as principais classes geradas pelo eTBc, que formam o testbench, assim como o arquivo TLN, o qual informa ao eTBc dados sobre a interface do DUV. Inicialmente ser´a detalhado o TLN e, ent˜ao como resultado da execu¸c˜ao do eTBc, as principais classes.

A Figura 19 apresenta de forma resumida o esquema de opera¸c˜ao do eTBc. Os moldes ou templates s˜ao apenas para leitura - o engenheiro de verifica¸c˜ao n˜ao os altera, apenas o gerente de verifica¸c˜ao pode alter´a-los. O TLN ´e o arquivo gerado pelo engenheiro de verifica¸c˜ao, contendo informa¸c˜oes em n´ıvel de transa¸c˜oes, as quais s˜ao utilizadas pelo eTBc para a gera¸c˜ao correta das interfaces. A partir de linha de comando, o eTBc gera os arquivos em SystemVerilog que formam o testbench.

No apˆendice C.1 est´a o arquivo “ddr ctrl.tln”. Esse arquivo ´e composto por structs e modules, os quais representam, respectivamente, opera¸c˜oes/resultados e m´odulos (no caso o CMS). A struct ”in op”representa uma opera¸c˜ao de escrita, leitura ou auto-refresh solicitada `a mem´oria; por outro lado, a struct ”out op”representa o resultado de uma opera¸c˜ao solicitada. Cada struct possui dados tanto no n´ıvel de transa¸c˜oes (trans), como no n´ıvel de sinais para o RTL (signals).

Figura 19: Opera¸c˜ao eTBc

A estrutura do TLN foi baseada no documento 256Mb DDR SDRAM Specification (POWERCHIP, 2004).

Os principais produtos do eTBc s˜ao: “tb.sv”, “refmod ddr ctrl.svh” e “trans.svh”. O “tb.sv” ´e respons´avel por inicializar os m´odulos que comp˜oem o testbench, al´em de conectar os m´odulos atrav´es de canais FIFO10, pelos quais s˜ao enviadas as transa¸c˜oes. O arquivo “trans.svh” ´e importante, por conter a classe que gera os est´ımulos direcionados. A mesma ´e constru´ıda de acordo com as informa¸c˜oes do TLN, respeitando a interface das transa¸c˜oes. A aleatoriedade direcionada desejada ´e obtida ao modificar “trans.svh”: essa modifica¸c˜ao ´e obrigat´oria, j´a que, o eTBc gera uma classe padr˜ao, sem aleatoriedade. Por fim, o “refmod ddr ctrl.svh” cont´em o modelo de referˆencia. A metodologia obriga que o modelo de referˆencia seja desenvolvido em um n´ıvel de abstra¸c˜ao maior que no n´ıvel RTL, assim essa classe, atrav´es de t´ecnicas do SystemVerilog, permite importar fun¸c˜oes em C e C++, de forma que ´e poss´ıvel e aconselh´avel utilizar outras linguagens de alto n´ıvel para criar o modelo de referˆencia. Esse arquivo, ainda cont´em a l´ogica respons´avel pela cobertura, utilizando t´ecnicas do SystemVerilog como covergroup, de forma a automatizar a tarefa de verifica¸c˜ao, pois quando a cobertura desejada for atingida a simula¸c˜ao ´e encerrada. Al´em disso, o dados gerados pela cobertura podem ajudar a inspecionar a qualidade da verifica¸c˜ao e direcionar os est´ımulos de forma a alcan¸car as funcionalidades n˜ao cobertas, evitando os buracos de cobertura.

10_{FIFO (First-In First-Out ) ´e um tipo especial de fila, na qual os ´ıtens s˜ao colocados de um lado (atr´as)}

4.5

Resumo

Os artefatos gerados pelo ipProcess, s˜ao importantes, na medida que guia a equipe de desenvolvimento na constru¸c˜ao de um IP-Core com qualidade. Alguns documentos s˜ao de dif´ıcil desenvolvimento, devido `a alta abstra¸c˜ao, principalmente para os desenvolvedores que nunca utilizaram essa metodologia.

A verifica¸c˜ao ´e uma disciplina bastante trabalhosa e dif´ıcil - nesse sentido, o BVM tende a facilitar esse trabalho. Todavia, por natureza, a verifica¸c˜ao ´e um processo com- plexo, variando, ´e claro, para cada projeto de IP-Core. O eTBc ´e feliz ao reduzir o trabalho mon´otono e propenso a erro de cria¸c˜ao do testbench - al´em disso, a t´ecnica de gera¸c˜ao do mesmo permite verificar as corretude dos m´odulos internos do testbench. No entanto, o eTBc, para alguns casos de verifica¸c˜ao, se torna complexo e mon´otono, como ocorreu no caso do CMS. Quer dizer, o BVM sup˜oe que a equipe de desenvolvimento pos- sua um modelo de referˆencia em outro n´ıvel de abstra¸c˜ao, n˜ao no n´ıvel RTL. Entretanto, alguns m´odulos s˜ao t˜ao comuns e frequentes que n˜ao s˜ao desenvolvidos em outro n´ıvel de abstra¸c˜ao, como tamb´em podem ser propriedade intelectual fechada, e nem mesmo serem vendidos. Outra quest˜ao reside na funcionalidade do checker, o qual verifica se a resposta do modelo de referˆencia ´e igual `a resposta do DUV. Nesse ponto, um m´odulo como o CMS precisa mais que verificar os resultados das opera¸c˜oes: necessita verificar se a temporiza¸c˜ao dos sinais est´a correta. Para tratar casos assim, uma op¸c˜ao seria modificar o checker para suportar temporiza¸c˜ao; outra op¸c˜ao seria modificar o DUV e o modelo de referˆencia, para trabalharem como m´aquinas de estado e verificar os respectivos estados - esta op¸c˜ao ´e perigosa, devido `a interferˆencia no modelo de referˆencia. Para o CMS, a op¸c˜ao adotada foi a de um modelo de referˆencia em RTL, conforme apˆendice C.2 e C.3. Em outros projetos, a equipe de desenvolvimento pode encontrar formas que gerem menos interferˆencia no testbench.

5

Discuss˜ao

Conforme o cap´ıtulo 4, esta monografia abordou as seguintes fases do ipProcess, bem como os respectivos documentos:

• Requisitos: Documento de Especifica¸c˜ao de Requisitos e o documento de Casos de Uso.

• An´alise & Projeto: Documento de An´alise e o documento de Arquitetura

• Verifica¸c˜ao: Plano de Verifica¸c˜ao e o documento de Casos de Teste.

Tanto a disciplina de Implementa¸c˜ao em RTL, quanto a Prototipa¸c˜ao n˜ao foram descritas. Isto ocorreu devido `a defasagem do cronograma do projeto Decodificador de

´

Audio MPEG-2 AAC-LC, do Brazil-IP/UEFS, em rela¸c˜ao ao cronograma deste trabalho. Al´em disso, o cronograma do TCC, que foi inicialmente adequado ao cronograma do Brazil-IP/UEFS, sofreu mudan¸cas, j´a que, ao seguir a metodologia BVM, a implementa¸c˜ao da verifica¸c˜ao funcional antecede a implementa¸c˜ao RTL (o que n˜ao ocorria no cronograma inicial, o qual seguia um fluxo de projeto mais tradicional).

A Implementa¸c˜ao (RTL) ´e respons´avel por gerar o modelo de simula¸c˜ao sintetiz´avel em n´ıvel RTL, com base nas defini¸c˜oes da arquitetura. Nessa fase ´e produzido o plano de Implementa¸c˜ao, o qual descreve um detalhado plano de implementa¸c˜ao e integra¸c˜ao de componentes, al´em de apresentar a ordem que os componentes devem ser implemen- tados e integrados. A meta da Prototipa¸c˜ao ´e, baseada nos componentes implementados, prototipar o IP-Core em FPGA. Para isso, utiliza o plano de Prototipa¸c˜ao, o qual for- nece um plano detalhado da ordem de implementa¸c˜ao dos componentes, como tamb´em da intera¸c˜ao entre os mesmos.

No escopo do Brazil-IP/UEFS, o qual ´e bem amplo (a ser executado em 2 anos), tanto a verifica¸c˜ao, como as fases restantes do ipProcess ser˜ao executadas pelo autor, a saber, Implementa¸c˜ao (RTL) e Prototipa¸c˜ao. Ao que, ap´os essas fases, o autor estar´a em contato com o fluxo referente ao projeto ASIC.