Você está na página 1de 6

Verificação Funcional para Sistemas Digitais utilizando System Verilog

Elton B. Costa ¹ ,2 , Victor A. Perone ¹ ,2 , Thayse L. A. Barbosa ², Elmar U. K. Melcher ¹ ,2 e Joseana M. Fechine ¹ ,2

¹ Laboratório de Arquiteturas Dedicadas LAD, ² Universidade Federal de Campina Grande - UFCG Campina Grande PB, Brasil {elton, victor, thayse}@ee.ufcg.edu.br, {elmar, joseana}@dsc.ufcg.edu.br

Abstract With the growth of new technologies, there was a need to verify the operation of these digital systems, which are gaining an exponential complexity. In order to that, functional verification methodologies have started to detach in the environment of digital architecture. Thus, the Functional Verification became an indispensable tool for the construction and implementation of dedicated hardware, called IP core (semiconductor intellectual property core). Finally, the main contribution and relevance of this research is to present the most efficient way to perform Functional Verification of Digital Systems using tooling computing, aiming to increase efficiency and performance of dedicated units, in order to identify errors during the implementation phase the project.

Keywords IP core; digital systems; functional verification

Resumo Com o crescimento de novas tecnologias, houve a necessidade de se verificar o funcionamento de sistemas digitais, que vêm ganhando uma complexidade exponencial. Deste modo, metodologias de verificação funcional começaram a se destacar no ambiente da arquitetura digital. Com isso, a Verificação Funcional torna-se uma ferramenta indispensável para a construção e implementação de hardware dedicado, denominados de IP core (semiconductor intellectual property core). Por fim, a principal contribuição e relevância desta pesquisa é apresentar a maneira mais eficiente de se realizar Verificação Funcional de Sistemas Digitais utilizando ferramentais computacionais, visando o aumento da eficiência de execução de unidades dedicadas, a fim de identificar erros durante a fase de implementação do projeto.

PalavrasChave

funcional

IP

I.

core;

sistemas

INTRODUÇÃO

digitais;

verificação

Com o surgimento de novas tecnologias, houve a necessidade de se verificar o funcionamento de sistemas digitais, os quais a complexidade dos sistemas aumenta exponencialmente. Sendo assim, metodologias de verificação funcional começaram a se destacar no ambiente da arquitetura digital. Deste modo, a verificação se torna uma ferramenta fundamental para o desenvolvimento, implementação e construção do hardware.

Com essa ferramenta, o engenheiro de verificação tem uma probabilidade maior de encontrar erros durante o desenvolvimento do projeto. Segundo alguns autores, estima-se que cerca de 70% dos recursos destinados ao processo de construção do hardware são gastos na verificação funcional

[1][2].

Diante do exposto, o objetivo do estudo apresentado neste artigo é apresentar metodologia de verificação funcional baseada em BVM (Brazil IP Verification Methodology) [7] aplicável a sistemas digitais, em especial, às unidades lógicas de processamento. Para tanto, serão apresentadas as fases necessárias à verificação de unidades de processamento como, por exemplo, a DUV (Design Under Verification).

II. FUNDAMENTAÇÃO TEÓRICA

Nesta seção são definidos os conceitos que formam parte do embasamento teórico necessário para a compreensão da proposta de pesquisa apresentada na introdução.

A. Noções de Verificação Funcional

Costuma-se confundir verificação com outros termos. Sendo assim, utilizar-se-á a definição da bibliografia da área que, segundo Bergeron [1], Verificação Funcional é o processo utilizado para demonstrar que o objetivo do projeto foi preservado em sua implementação. Ressalta-se que, Verificação Funcional é realizada por meio de simulações e, consiste em inserir estímulos na entrada do componente que será verificado, os quais serão recolhidos na saída, e, a partir disso, há uma comparação para verificar se ocorreram perdas no momento em que o projeto esteve em execução. Esse ambiente de verificação denomina-se de Testbench.

Esses estímulos são cuidadosamente selecionados, para que se possa executar a função desejada. Exemplos desses estímulos são sinais, transações, dados randomizados, entre outros. Nessa perspectiva, só se consegue o término da Verificação quando todas as funções que foram estabelecidas alcançam um funcionamento livre de erros.

A técnica utilizada neste trabalho para realizar a Verificação no DUV foi à divisão em blocos dessa unidade de processamento, possibilitando reduzir complexidade para a detecção dos erros.

B. A linguaguem System Verilog

Em meados de 1990, Verilog tornou-se a linguagem de descrição de hardware mais utilizada para simulação e síntese [2]. No entanto, era utilizada apenas para pequenos testes. Em 2005, o IEEE [10] adotou System Verilog como um padrão de linguagem desenvolvida em RTL (Register Transfer Level) direcionada à Verificação. Dessa forma, System Verilog se torna um excelente artifício para implementação de Testbench

e criação de modelos de referência. Outras funcionalidades de System Verilog devem ser destacadas, como:

Permite a chamada de funções C/C++ em DPI (Direct Programming Interface);

Incorpora diversas tecnologias como randomicidade, assertions e cobertura funcional;

Permite criação de ambientes de verificação confiáveis e repetíveis e uma sintaxe consistente.

Com essas características, System Verilog se torna uma linguagem atraente para Engenheiros de Verificação, visto que, grandes empresas na área de desenvolvimento de projetos, como a Cadence [4][9], Mentor e Synopsys, lançaram tecnologias com enfoque nessa linguagem. Conforme apresentado, essa linguagem é utilizada no trabalho ora apresentado para que se possa realizar uma implementação típica de Verificação Funcional.

C. Randomicidade Direcionada

Segundo Spear [2], estímulos randômicos são cruciais para exercitar projetos complexos. No entanto, aconselha-se que esses estímulos não sejam totalmente randômicos, que tenham algumas restrições, como quantidade de bits, distribuição de probabilidade e faixa de valores. Diante disso, tem-se a Randomicidade Direcionada.

O gerador de estímulos será responsável no projeto por produzir os dados que serão inseridos no componente a ser verificado. Vale ressaltar que, esses estímulos randomizados devem ter a capacidade de repetição quantas vezes for necessária, para que o Engenheiro de Verificação possa ter uma simulação de diferentes características.

No contexto dessa pesquisa foi desenvolvido um arquivo

que será responsável em inserir estímulos na entrada do DUV,

a esse arquivo denominou-se de packet.svh que, inicialmente, possui a seguinte declaração:

class packet extends ovm_transaction;

Nesta linha de código, declara-se uma classe packet herdada da biblioteca OVM (Open Verification Methodology) [3][7]. Utiliza-se a biblioteca OVM, pois essa oferece uma verificação dirigida por Cobertura. Vale primar que, ao se usar OVM, pode-se desenvolver um Testbench usando ambientes de Verificação OVC (OVM Verification Component) [7]. OVC consiste em um ambiente configurado e pronto para uso [7]. Logo após a declaração da classe packet, tem-se a seguinte

estrutura:

rand shortint data;

constraint data_range{

data dist{[-8:-4]:/18,[-3:3]:/66,[4:7]:/18};

}

 

Esse trecho declara uma variável inteira do tipo randômica,

e

a distribuição de probabilidade uniforme para o intervalo de

-8 a 7. Nessa perspectiva, a função data_range ao ser chamada, estimulará números randômicos de 4 bits. Com isso, ao se inserir dados randômicos nas transações, deve-se ocorrer à

gravação de dados, para que se possam armazenar esses valores até o próximo envio. Para se gravar essa ação, descreve-se a devida sintaxe:

function void do_record (ovm_recorder recorder) ;

recorder.record_field ("data", data, $bits(data),

OVM_DEC);

endfunction

Para tornar o processo de Verificação exato e eficiente, faz- se uso de assert, que é uma ferramenta de System Verilog capaz de verificar se a variável randômica declarada está sendo randomizada [3]. Utilizando a Randomicidade Direcionada, o ambiente Testbench desenvolvido encontrará erros previstos, pois os estímulos foram descritos na especificação do projeto em um intervalo bem definido, como apresenta a descrição em System Verilog supracitada.

D. Cobertura Funcional

Ao se utilizar dados randômicos deve-se atentar para o uso da Cobertura Funcional, para se medir o progresso da Verificação. A Cobertura Funcional é uma medida de quais funcionalidades do projeto foram executadas durante os testes [2]. As funcionalidades que não foram devidamente testadas durante a simulação, são denominadas usualmente de “buracos de cobertura”.

Se a Cobertura não alcançar 100% de Verificação, isso vai permitir passar certos erros e implicará em um prejuízo para o desenvolvimento do projeto. Para se desenvolver uma cobertura, inicialmente deve-se traçar um Plano de Cobertura, que consiste em capturar todos os requisitos do componente que está sendo verificado. Como nesse caso, foi definido que serão enviados números randômicos no intervalo entre - 8 a 7, deve-se traçar um Plano de Cobertura que recolha dados que possam sair desse intervalo. Esse método descrito em System Verilog é estruturado da seguinte maneira:

covergroup cover_driver;

coverpoint data_at.data{

bins b1[] = {[-8:7]};

illegal_bins ill_data = {[$:-9], [8:$]};

option.at_least = 100;

}

Essa definição de cobertura covergroup cover_driver, declara o intervalo usado da classe packet como variáveis bins. Em seguida, são definidos os bins ilegais, que são valores que estão fora do intervalo definido. Isso consiste em analisar os valores que devem ser analisados durante a cobertura.

Para usar a Cobertura Funcional em algum momento da execução, utiliza-se o método de interface, acessando o Plano de Cobertura covergroup cover_driver, produzindo uma cobertura de Verificação para valores ilegais.

É importante destacar que, se o plano de Verificação for mal descrito, a cobertura funcional realizada não verificará todas as funcionalidades desejadas. Por exemplo, se o plano de

Verificação abrange 80% das funcionalidades que deveriam ser testadas, então, mesmo que a cobertura funcional seja realizada

de maneira adequada, chegando aos 100% de cobertura, estará

testando apenas 80% das funcionalidades que deveriam ser testadas. Por este motivo, é importante que o plano de Verificação seja revisto e modificado quando necessário, já que reflete o estado atual do projeto.

E. Protocolo de Comunicação AMBA ® AXI Protocol

Nesse contexto de comunicação entre unidades de processamento, firmou-se o Protocolo de Comunicação AMBA AXI [8], por ser um protocolo direcionado para alto desempenho, sistemas de altas frequências, suporte para transferências de dados e inclui uma série de características que o tornam apropriado para uma alta velocidade de interconexão. Os objetivos mais recentes de geração da interface AMBA AXI são:

Ser adequado para projetos de largura de banda alta e de baixa latência;

Permitir alta frequência de operação sem a necessidade de utilização de pontes complexas;

Satisfazer os requisitos de interface de uma ampla gama de componentes;

Fornecer flexibilidade na implementação de arquiteturas de interconexão.

As principais características do Protocolo AMBA AXI são:

Separar, ler e escrever canais de dados para permitir baixo custo;

Capacidade de emitir múltiplos endereços pendentes;

Conclusão de transação fora de ordem.

Bem como o protocolo de transferência de dados, o protocolo AXI inclui extensões opcionais que cobrem a sinalização para baixa potência de operação. Com todas essas características, o protocolo possui cinco canais independentes que consiste em um conjunto de sinais de informação e utiliza um mecanismo two-way Valid e Ready [8]. A fonte de informação usa o sinal Valid para mostrar quando os dados

válidos ou a informação está disponível no canal. O destino usa

o sinal Ready para mostrar quando pode aceitar os dados [8].

A arquitetura desse protocolo consiste em que cada transação tem informações de endereço e controle, que descreve a natureza dos dados a serem transferidos. Os dados são transferidos entre o mestre e o escravo, usando uma gravação de canal de dados para o escravo, ou uma leitura do canal de dados para o mestre. Em operações de gravação, no

qual todos os fluxos de dados a partir do mestre para o escravo,

o protocolo AXI tem um canal de resposta adicional de

gravação para permitir que o escravo informe ao mestre a

conclusão da operação de gravação. Com isso, pode-se chegar

à conclusão de que o protocolo permite:

A informação de endereço a ser emitido à frente da transferência de dados reais;

Suporte para múltiplas transações pendentes;

Suporte para conclusão das transações.

A seguir,

apresenta-se

a

arquitetura

ilustrativa

protocolo:

desse

apresenta-se a arquitetura ilustrativa protocolo: desse Figura 2.1. Arquitetura do canal de leitura [8] Figura 2.2.

Figura 2.1.

Arquitetura do canal de leitura [8]

desse Figura 2.1. Arquitetura do canal de leitura [8] Figura 2.2. Arquitetura do canal de escrita

Figura 2.2.

Arquitetura do canal de escrita [8]

III.

DESENVOLVIMENTO DO AMBIENTE DE VERIFICAÇÃO

TESTBENCH

ambiente de Verificação, Testbench, possui alguns

elementos fundamentais para seu funcionamento. Na seguinte figura apresenta-se um modelo usual desse ambiente, composto pelo componente a ser verificado, DUV, e todo o campo que envolve para se realizar a Verificação dessa unidade.

O

envolve para se realizar a Verificação dessa unidade. O Figura 3.1. Modelo usual de Testbench [7]

Figura 3.1.

Modelo usual de Testbench [7]

Vale primar no ambiente de Verificação, certas ferramentas necessárias para simulação, tais como:

Ambiente de Compilação da Cadence [4];

Visualizador de formas de onda, Simvision [4];

Biblioteca OVM [7];

AMBA AXI Protocol [8].

Com essas ferramentas supracitadas já se pode iniciar um ambiente de verificação. No entanto, segundo Bergeron [1], existem observações fundamentais para que se possa obter um Testbench de qualidade, destaca-se:

O ambiente de verificação deve ser dirigido por uma Cobertura Funcional, para isolar e definir os valores que se deve analisar no momento da transferência de dados;

O ambiente deve ser autoverificável, os dados da saída do DUV devem ser automaticamente comparados com os dados inseridos;

em

A

comunicação

dos

blocos

deve

ser

baseada

transações;

No ambiente não deve existir entradas e saídas.

Toda a comunicação do Testbench é feita através de um componente denominado FIFO (First in First out). A FIFO tem um papel fundamental na implementação do Testbench, pois se faz o sequenciamento e sincronismo dos dados de entrada e saída. Com essa funcionalidade, a comunicação dos blocos pré-definidos acontece por meio de transações. Esses

blocos são classificados por: source, driver, monitor, checker, actor e reference model. Esses blocos possuem funções específicas, que interligados formam o ambiente de verificação

e executam a operação desejada. Na seção seguinte apresentam-se as características desses blocos.

A. Componentes e suas configurações

A seguir são apresentados alguns componentes básicos do Testbench com suas respectivas funções.

O Source é o componente responsável em criar estímulos para simulação. Esses estímulos são transações e devem ser cuidadosamente escolhidos para satisfazer a cobertura;

O Driver tem como funcionalidade converter as transações do Source em sinais, mantendo um protocolo de comunicação com o DUV a partir desses sinais;

O papel do Monitor é inverso do Driver, pois transforma os sinais do Driver em transações e repassa para o Checker via FIFO;

A função do Checker é de comparar os dados oriundos do Reference Model e do Monitor;

O Reference Model tem a especificação do projeto, sendo assim, ao se receber estímulos, espera-se produzir respostas coerentes;

Um novo componente foi inserido, o Actor, que é o responsável em monitorar e controlar a comunicação entre o Testbench e o DUV.

Assim sendo, com as configurações já apresentadas, pode-

se por fim, ter uma representação do ambiente em que a

modelagem proposta será aplicada para realizar Verificação Funcional, como é apresentado na seguinte ilustração:

Funcional, como é apresentado na seguinte ilustração: Figura 3.2. Componente a ser verificado – DUV Emulation

Figura 3.2.

Componente a ser verificado DUV Emulation

Este modelo de Testbench é uma melhoria da Metodologia VeriSC denominado de Metodologia BVM [7]. Esses componentes descritos são básicos para a construção de um ambiente de Verificação Funcional. E com isso, será possível, gerar estímulos e observar as respostas. Assim sendo, automatiza muitas das tarefas de construção do Testbench, proporcionando a redução do tempo de Verificação sem comprometer a sua eficiência.

B. Metodologia BVM

Continuando a construção do Testbench, consolidou-se no âmbito desse trabalho, a utilização da Metodologia BVM, uma Metodologia desenvolvida no âmbito do projeto do Brazil IP (Programa Federal Brazil Semiconductor Intellectual Property) que consiste em uma sequência de passos para que se alcance uma Verificação Funcional livre de equívocos. Para que se possa verificar o sistema em questão, o DUV Emu- lation, representado pela Figura 3.2, é necessário analisar dois subpassos, o Single Refmod e Double Refmod, pois BVM se caracteriza como uma metodologia voltada para criação de Testbench de forma incremental, ou seja, o componente a ser verificado é separado e analisado em etapas.

Com isso, BVM se torna uma ferramenta indispensável para Engenheiros de Verificação, pois reduz o tempo de identificação de erros. Ao final, efetuam-se simulações desses subpassos para que em seguida o DUV Emulation possa ser simulado e verificado.

1)

Single Refmod

O Single Refmod é um subpasso da Metodologia BVM, composto por Source, Reference Model e Sink, que se caracteriza como um simples teste que verifica a geração de estímulos do Source e a capacidade do Reference Model interagir com o Testbench. Ao final dessa comunicação, verificam-se as transações recebidas pelo Sink. A ferramenta utilizada para que se possa verificar essa comunicação é o Simvision. Esse visualizador de formas de onda irá representar as transações que estão sendo executadas no ambiente de verificação desenvolvido.

A representação usual do Single Refmod é descrita a seguir, visto que são definidas duas FIFO, para que se possa

realizar a comunicação do Reference Model com os demais blocos.

a comunicação do Reference Model com os demais blocos. Figura 3.3. Representação em blocos lógicos do

Figura 3.3.

Representação em blocos lógicos do Single Refmod

Sendo assim, inseridos estímulos no Source utilizando dados randomizados, o Reference Model interagindo com o Testbench e o Sink recebendo as transações, verifica-se a visualização das transações em forma de onda. Vale primar à linha de código em System Verilog necessária para o Simvision [4] reconhecer e apresentar as transações.

recording_detail = OVM_FULL;

Ao efetuar a simulação, surgem alguns arquivos indesejados para a Verificação. Com isso, a métrica utilizada para esse problema, é a criação de um arquivo denominado Makefile, pois é uma maneira muito conveniente de gerenciar grandes programas ou grupos de programas. Esse arquivo faz a manutenção de programas observando quais foram mudados desde a última compilação e recompilando apenas essas partes.

Usando o artifício supracitado, o ambiente fica livre de flags, e dessa maneira a simulação do Single Refmod se apresenta da seguinte maneira:

do Single Refmod se apresenta da seguinte maneira: Figura 3.4. Funcionamento do Single Refmod no Simvion

Figura 3.4.

Funcionamento do Single Refmod no Simvion

As seguintes representações de onda são simulações das transações que são executadas no Single Refmod. Inicialmente são inseridos estímulos, representados na figura, no entanto, o segundo envio desses dados é feito somente depois de um tempo que foi estabelecido pelo código escrito em System Verilog. Com isso, verifica-se que o segundo envio de estímulos é feito em momento síncrono após 800 ns, concluindo que a comunicação do Testbench com o DUV está de forma coerente. Como foi desenvolvida uma randomicidade direcionada, as transações são repassadas repetidamente no mesmo instante de tempo.

2)

Double Refmod

Nesse subpasso da Metodologia BVM verifica-se as saídas do Reference Model, pois são feitas duas instâncias, como mostra a ilustração:

são feitas duas instâncias, como mostra a ilustração: Figura 3.5. Representação em blocos lógicos do Double

Figura 3.5.

Representação em blocos lógicos do Double Refmod

O elemento Sink do Single Refmod será substituído pelo Checker, que será responsável em analisar a saída do Reference Model. O Source é o mesmo utilizado no Single Refmod, irá gerar estímulos e será repassado através de uma FIFO de suas saídas, este artifício utilizado foi desenvolvido no Laboratório de Arquiteturas Dedicadas (LAD). O principal objetivo desse subpasso é testar se o Source e o Checker estão funcionando de modo adequado.

Observa-se que é necessária a criação de três FIFO, sendo que uma dessas é de duas saídas, assim segue a declaração de uma FIFO em System Verilog:

tlm_fifo#(packet) my_first_fifo=new("myfifo",null,3);

Nesse subpasso deve-se ocorrer um sincronismo de saída do Reference Model, pois serão dois valores que o Checker deve receber em um mesmo instante de tempo. Para isso, o protocolo AXI é utilizado como uma importante ferramenta de sincronismo de comunicação, pois sua funcionalidade é construída com uma flexibilidade na implementação de arquiteturas de interconexão.

Efetuada a simulação do Double Refmod, verificou-se a eficiência da execução da Cobertura Funcional e, obteve-se a seguinte curva característica:

Funcional e, obteve-se a seguinte curva característica: Figura 3.6. Curva característica da Cobertura do Double

Conforme apresenta o gráfico, a cobertura atinge 100% para três estímulos diferentes, representados pelas três curvas em destaque.

IV. VERIFICAÇÃO FUNCIONAL DO DUV EMULATION

Realizados e devidamente testados os dois subpassos anteriores, nesse último momento realizou-se a simulação do DUV Emulation, que é o ambiente a ser verificado nesse trabalho. Verificou-se inicialmente o comportamento do Driver e do Monitor, e ao realizar a simulação, o Driver transformou transações em sinais e o Monitor, sinais em transações. Porém ao se introduzir esses dois elementos surge a necessidade de se ter um DUV, para receber os dados vindos do Driver e enviá-los para o Monitor, o problema encontrado foi que o DUV não estava implementado.

Para resolver esse problema, foi desenvolvido o seguinte artifício:

esse problema, foi desenvolvido o seguinte artifício: Figura 4.1. Implementação do DUV Um Monitor e um

Figura 4.1.

Implementação do DUV

Um Monitor e um Driver são acoplados a um segundo Modelo de Referência, fazendo com que esse sistema tenha entrada e saída em nível de sinal. Para monitorar o protocolo de comunicação entre o DUV e o Testbench utiliza-se o Actor. Esse elemento evita a escrita de código adicional para o controle de sinais entre o Driver e a tripla que emula o DUV.

Efetuando-se esse artifício verificou-se a emulação do DUV e, de imediato, analisou-se o desempenho da Cobertura Funcional nesse ambiente de comunicação e, a partir disso, obteve-se a seguinte curva característica com relação a três estímulos gerados:

característica com relação a três estímulos gerados: Figura 4.2. Curva característica da Cobertura do DUV

Figura 4.2.

Curva característica da Cobertura do DUV Emulation

Com a cobertura em um patamar livre de erros, o recebimento de dados do Checker foi satisfatório em um mesmo instante de tempo. Os resultados revelaram que a Verificação Funcional permitiu uma rapidez no desenvolvimento do sistema DUV Emulation, pois a verificação incremental possibilitou a detecção de erros.

V. CONSIDERAÇÕES FINAIS

Diante do que foi apresentado, o processo de construção de hardware não é um exercício simples de se resolver, e que a fase de verificação funcional se faz necessária para reduzir os custos que certos erros trás ao desenvolvimento de Hardware, e que atualmente tem uma fundamental importância na construção de IP core (Semiconductor Intellectual Property core).

Por fim, a principal contribuição e relevância dessa pesquisa é apresentar a forma mais eficiente de se realizar Verificação Funcional de Sistemas Digitais, utilizando ferramentas computacionais, metodologia BVM e System Verilog, que implicaram diretamente em um aumento de 20% na produtividade da verificação [7]. Com isso, todos esses fatos, trouxeram resultados considerados no ambiente da Engenharia da Computação, como por exemplo, na implementação de um protótipo de IP core de Identidade Vocal [11], desenvolvido no Laboratório de Arquiteturas Dedicadas (LAD) da Universidade Federal de Campina Grande (UFCG).

REFERÊNCIAS BIBLIOGRÁFICAS

[1]

Janick Bergeron. Writing Testbenches: Functional Verification of HDL

[2]

Models, Second Edition. Kluwer Academic Publishers, Norwell, MA, USA, 2003. Chris Spear. System Verilog for Verification, A guide to Learning the

[3]

Testbench Language Features, Second Edition, Springer, USA, 2006, pp. 79 - 124, 161 - 216, 295 - 332. I. M. Pessoa. Geração semi-automatica de testbenches para circuitos

[4]

integrados digitais. Master's thesis, Universidade Federal de Campina Grande, Av. Aprigio Veloso, Campina Grande, 2007. CADENCE DESIGN SYSTEMS, INC; MENTOR GRAPHICS. Open

[5]

verification methodology user guide. Technical report, EUA, 2008. I. Wagner, Valeria Bertacco, and Todd Austin. Stresstest: An automatic approach to test gener-ation via activity monitors. In DAC ’05: Pro- ceedings of the 42nd annual conference on De-sign automation, pp. 783788, New York, NY, USA, 2005. ACM Press. 97.

[6] Ana Karina Rocha, Patricia Lira, Yang Yun Ju, Edna Barros, Elmar Melcher, and Guido Araujo. Sili-con validated ip cores designed by the brazil-ip network. In IP/SOC 2006, June 2006.

[7]

Helder Fernando de Araújo Oliveira (2010). BVM: Reformulação da

[8]

Metodologia de Verificação Funcional VeriSC. Dissertation - Federal University of Campina Grande. AMBA ® AXI Protocol Specification.

[9]

2012. Cadence Design Systems Testbuilder. http://www.cadence.com.

Último acesso em Junho 2012. [10] IEEE STANDARDS. IEEE Standard for SystemVerilog - Unified Hardware Design, Specification, and Verification Language. Institute of Electrical and Electronics Engineers, Inc., USA, 2005 b. [11] Fechine, J. M., Texeira Junior, A. G., Melo, F. G. L., Espinola, S., Paixão, L. L. SPVR: An IP core for Real-Time Speaker Verification. In:

IP Based SoC Design Conference & Exhibition, 2010, Grenoble.