Verificao 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
Laboratrio 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 vm ganhando uma complexidade exponencial. Deste modo, metodologias de verificao funcional comearam a se destacar no ambiente da arquitetura digital. Com isso, a Verificao Funcional torna-se uma ferramenta indispensvel para a construo e implementao de hardware dedicado, denominados de IP core (semiconductor intellectual property core). Por fim, a principal contribuio e relevncia desta pesquisa apresentar a maneira mais eficiente de se realizar Verificao Funcional de Sistemas Digitais utilizando ferramentais computacionais, visando o aumento da eficincia de execuo de unidades dedicadas, a fim de identificar erros durante a fase de implementao do projeto. PalavrasChave IP core; sistemas digitais; verificao funcional

Diante do exposto, o objetivo do estudo apresentado neste artigo apresentar metodologia de verificao funcional baseada em BVM (Brazil IP Verification Methodology) [7] aplicvel a sistemas digitais, em especial, s unidades lgicas de processamento. Para tanto, sero apresentadas as fases necessrias verificao de unidades de processamento como, por exemplo, a DUV (Design Under Verification). II.
FUNDAMENTAO TERICA

Nesta seo so definidos os conceitos que formam parte do embasamento terico necessrio para a compreenso da proposta de pesquisa apresentada na introduo. A. Noes de Verificao Funcional Costuma-se confundir verificao com outros termos. Sendo assim, utilizar-se- a definio da bibliografia da rea que, segundo Bergeron [1], Verificao Funcional o processo utilizado para demonstrar que o objetivo do projeto foi preservado em sua implementao. Ressalta-se que, Verificao Funcional realizada por meio de simulaes e, consiste em inserir estmulos na entrada do componente que ser verificado, os quais sero recolhidos na sada, e, a partir disso, h uma comparao para verificar se ocorreram perdas no momento em que o projeto esteve em execuo. Esse ambiente de verificao denomina-se de Testbench. Esses estmulos so cuidadosamente selecionados, para que se possa executar a funo desejada. Exemplos desses estmulos so sinais, transaes, dados randomizados, entre outros. Nessa perspectiva, s se consegue o trmino da Verificao quando todas as funes que foram estabelecidas alcanam um funcionamento livre de erros. A tcnica utilizada neste trabalho para realizar a Verificao no DUV foi diviso em blocos dessa unidade de processamento, possibilitando reduzir complexidade para a deteco dos erros. B. A linguaguem System Verilog Em meados de 1990, Verilog tornou-se a linguagem de descrio de hardware mais utilizada para simulao e sntese [2]. No entanto, era utilizada apenas para pequenos testes. Em 2005, o IEEE [10] adotou System Verilog como um padro de linguagem desenvolvida em RTL (Register Transfer Level) direcionada Verificao. Dessa forma, System Verilog se torna um excelente artifcio para implementao de Testbench

I.

INTRODUO

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 verificao funcional comearam a se destacar no ambiente da arquitetura digital. Deste modo, a verificao se torna uma ferramenta fundamental para o desenvolvimento, implementao e construo do hardware. Com essa ferramenta, o engenheiro de verificao 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 construo do hardware so gastos na verificao funcional [1][2].

e criao de modelos de referncia. Outras funcionalidades de System Verilog devem ser destacadas, como: Permite a chamada de funes C/C++ em DPI (Direct Programming Interface); Incorpora diversas tecnologias como randomicidade, assertions e cobertura funcional; Permite criao de ambientes de verificao confiveis e repetveis e uma sintaxe consistente.

gravao de dados, para que se possam armazenar esses valores at o prximo envio. Para se gravar essa ao, 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 Verificao exato e eficiente, fazse uso de assert, que uma ferramenta de System Verilog capaz de verificar se a varivel randmica declarada est sendo randomizada [3]. Utilizando a Randomicidade Direcionada, o ambiente Testbench desenvolvido encontrar erros previstos, pois os estmulos foram descritos na especificao do projeto em um intervalo bem definido, como apresenta a descrio em System Verilog supracitada. D. Cobertura Funcional Ao se utilizar dados randmicos deve-se atentar para o uso da Cobertura Funcional, para se medir o progresso da Verificao. A Cobertura Funcional uma medida de quais funcionalidades do projeto foram executadas durante os testes [2]. As funcionalidades que no foram devidamente testadas durante a simulao, so denominadas usualmente de buracos de cobertura. Se a Cobertura no alcanar 100% de Verificao, isso vai permitir passar certos erros e implicar em um prejuzo para o desenvolvimento do projeto. Para se desenvolver uma cobertura, inicialmente deve-se traar um Plano de Cobertura, que consiste em capturar todos os requisitos do componente que est sendo verificado. Como nesse caso, foi definido que sero enviados nmeros randmicos no intervalo entre - 8 a 7, deve-se traar um Plano de Cobertura que recolha dados que possam sair desse intervalo. Esse mtodo 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 definio de cobertura covergroup cover_driver, declara o intervalo usado da classe packet como variveis bins. Em seguida, so definidos os bins ilegais, que so valores que esto 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 execuo, utiliza-se o mtodo de interface, acessando o Plano de Cobertura covergroup cover_driver, produzindo uma cobertura de Verificao para valores ilegais. importante destacar que, se o plano de Verificao for mal descrito, a cobertura funcional realizada no verificar todas as funcionalidades desejadas. Por exemplo, se o plano de

Com essas caractersticas, System Verilog se torna uma linguagem atraente para Engenheiros de Verificao, visto que, grandes empresas na rea de desenvolvimento de projetos, como a Cadence [4][9], Mentor e Synopsys, lanaram tecnologias com enfoque nessa linguagem. Conforme apresentado, essa linguagem utilizada no trabalho ora apresentado para que se possa realizar uma implementao tpica de Verificao Funcional. C. Randomicidade Direcionada Segundo Spear [2], estmulos randmicos so cruciais para exercitar projetos complexos. No entanto, aconselha-se que esses estmulos no sejam totalmente randmicos, que tenham algumas restries, como quantidade de bits, distribuio de probabilidade e faixa de valores. Diante disso, tem-se a Randomicidade Direcionada. O gerador de estmulos ser responsvel no projeto por produzir os dados que sero inseridos no componente a ser verificado. Vale ressaltar que, esses estmulos randomizados devem ter a capacidade de repetio quantas vezes for necessria, para que o Engenheiro de Verificao possa ter uma simulao de diferentes caractersticas. No contexto dessa pesquisa foi desenvolvido um arquivo que ser responsvel em inserir estmulos na entrada do DUV, a esse arquivo denominou-se de packet.svh que, inicialmente, possui a seguinte declarao: class packet extends ovm_transaction; Nesta linha de cdigo, declara-se uma classe packet herdada da biblioteca OVM (Open Verification Methodology) [3][7]. Utiliza-se a biblioteca OVM, pois essa oferece uma verificao dirigida por Cobertura. Vale primar que, ao se usar OVM, pode-se desenvolver um Testbench usando ambientes de Verificao OVC (OVM Verification Component) [7]. OVC consiste em um ambiente configurado e pronto para uso [7]. Logo aps a declarao 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 varivel inteira do tipo randmica, e a distribuio de probabilidade uniforme para o intervalo de -8 a 7. Nessa perspectiva, a funo data_range ao ser chamada, estimular nmeros randmicos de 4 bits. Com isso, ao se inserir dados randmicos nas transaes, deve-se ocorrer

Verificao abrange 80% das funcionalidades que deveriam ser testadas, ento, 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 Verificao seja revisto e modificado quando necessrio, j que reflete o estado atual do projeto. E. Protocolo de Comunicao AMBA AXI Protocol Nesse contexto de comunicao entre unidades de processamento, firmou-se o Protocolo de Comunicao AMBA AXI [8], por ser um protocolo direcionado para alto desempenho, sistemas de altas frequncias, suporte para transferncias de dados e inclui uma srie de caractersticas que o tornam apropriado para uma alta velocidade de interconexo. Os objetivos mais recentes de gerao da interface AMBA AXI so: Ser adequado para projetos de largura de banda alta e de baixa latncia; Permitir alta frequncia de operao sem a necessidade de utilizao de pontes complexas; Satisfazer os requisitos de interface de uma ampla gama de componentes; Fornecer flexibilidade na arquiteturas de interconexo. implementao de

Suporte para concluso das transaes.

A seguir, apresenta-se a arquitetura ilustrativa desse protocolo:

Figura 2.1. Arquitetura do canal de leitura [8]

As principais caractersticas do Protocolo AMBA AXI so: Separar, ler e escrever canais de dados para permitir baixo custo; Capacidade de emitir mltiplos endereos pendentes; Concluso de transao fora de ordem. III.
Figura 2.2. Arquitetura do canal de escrita [8]

Bem como o protocolo de transferncia de dados, o protocolo AXI inclui extenses opcionais que cobrem a sinalizao para baixa potncia de operao. Com todas essas caractersticas, o protocolo possui cinco canais independentes que consiste em um conjunto de sinais de informao e utiliza um mecanismo two-way Valid e Ready [8]. A fonte de informao usa o sinal Valid para mostrar quando os dados vlidos ou a informao est disponvel no canal. O destino usa o sinal Ready para mostrar quando pode aceitar os dados [8]. A arquitetura desse protocolo consiste em que cada transao tem informaes de endereo e controle, que descreve a natureza dos dados a serem transferidos. Os dados so transferidos entre o mestre e o escravo, usando uma gravao de canal de dados para o escravo, ou uma leitura do canal de dados para o mestre. Em operaes de gravao, no qual todos os fluxos de dados a partir do mestre para o escravo, o protocolo AXI tem um canal de resposta adicional de gravao para permitir que o escravo informe ao mestre a concluso da operao de gravao. Com isso, pode-se chegar concluso de que o protocolo permite: A informao de endereo a ser emitido frente da transferncia de dados reais; Suporte para mltiplas transaes pendentes;

DESENVOLVIMENTO DO AMBIENTE DE VERIFICAO TESTBENCH

O ambiente de Verificao, 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 Verificao dessa unidade.

Figura 3.1. Modelo usual de Testbench [7]

Vale primar no ambiente de Verificao, certas ferramentas necessrias para simulao, tais como: Ambiente de Compilao 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 verificao. No entanto, segundo Bergeron [1], existem observaes fundamentais para que se possa obter um Testbench de qualidade, destaca-se: O ambiente de verificao deve ser dirigido por uma Cobertura Funcional, para isolar e definir os valores que se deve analisar no momento da transferncia de dados; O ambiente deve ser autoverificvel, os dados da sada do DUV devem ser automaticamente comparados com os dados inseridos; A comunicao dos blocos deve ser baseada em transaes; No ambiente no deve existir entradas e sadas.

modelagem proposta ser aplicada para realizar Verificao Funcional, como apresentado na seguinte ilustrao:

Figura 3.2. Componente a ser verificado DUV Emulation

Toda a comunicao do Testbench feita atravs de um componente denominado FIFO (First in First out). A FIFO tem um papel fundamental na implementao do Testbench, pois se faz o sequenciamento e sincronismo dos dados de entrada e sada. Com essa funcionalidade, a comunicao dos blocos pr-definidos acontece por meio de transaes. Esses blocos so classificados por: source, driver, monitor, checker, actor e reference model. Esses blocos possuem funes especficas, que interligados formam o ambiente de verificao e executam a operao desejada. Na seo seguinte apresentam-se as caractersticas desses blocos. A. Componentes e suas configuraes A seguir so apresentados alguns componentes bsicos do Testbench com suas respectivas funes. O Source o componente responsvel em criar estmulos para simulao. Esses estmulos so transaes e devem ser cuidadosamente escolhidos para satisfazer a cobertura; O Driver tem como funcionalidade converter as transaes do Source em sinais, mantendo um protocolo de comunicao com o DUV a partir desses sinais; O papel do Monitor inverso do Driver, pois transforma os sinais do Driver em transaes e repassa para o Checker via FIFO; A funo do Checker de comparar os dados oriundos do Reference Model e do Monitor; O Reference Model tem a especificao do projeto, sendo assim, ao se receber estmulos, espera-se produzir respostas coerentes; Um novo componente foi inserido, o Actor, que o responsvel em monitorar e controlar a comunicao entre o Testbench e o DUV.

Este modelo de Testbench uma melhoria da Metodologia VeriSC denominado de Metodologia BVM [7]. Esses componentes descritos so bsicos para a construo de um ambiente de Verificao Funcional. E com isso, ser possvel, gerar estmulos e observar as respostas. Assim sendo, automatiza muitas das tarefas de construo do Testbench, proporcionando a reduo do tempo de Verificao sem comprometer a sua eficincia. B. Metodologia BVM Continuando a construo do Testbench, consolidou-se no mbito desse trabalho, a utilizao da Metodologia BVM, uma Metodologia desenvolvida no mbito do projeto do Brazil IP (Programa Federal Brazil Semiconductor Intellectual Property) que consiste em uma sequncia de passos para que se alcance uma Verificao Funcional livre de equvocos. Para que se possa verificar o sistema em questo, o DUV Emulation, representado pela Figura 3.2, necessrio analisar dois subpassos, o Single Refmod e Double Refmod, pois BVM se caracteriza como uma metodologia voltada para criao de Testbench de forma incremental, ou seja, o componente a ser verificado separado e analisado em etapas. Com isso, BVM se torna uma ferramenta indispensvel para Engenheiros de Verificao, pois reduz o tempo de identificao de erros. Ao final, efetuam-se simulaes 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 gerao de estmulos do Source e a capacidade do Reference Model interagir com o Testbench. Ao final dessa comunicao, verificam-se as transaes recebidas pelo Sink. A ferramenta utilizada para que se possa verificar essa comunicao o Simvision. Esse visualizador de formas de onda ir representar as transaes que esto sendo executadas no ambiente de verificao desenvolvido. A representao usual do Single Refmod descrita a seguir, visto que so definidas duas FIFO, para que se possa

Assim sendo, com as configuraes j apresentadas, podese por fim, ter uma representao do ambiente em que a

realizar a comunicao do Reference Model com os demais blocos.

2) Double Refmod Nesse subpasso da Metodologia BVM verifica-se as sadas do Reference Model, pois so feitas duas instncias, como mostra a ilustrao:

Figura 3.3. Representao em blocos lgicos do Single Refmod

Sendo assim, inseridos estmulos no Source utilizando dados randomizados, o Reference Model interagindo com o Testbench e o Sink recebendo as transaes, verifica-se a visualizao das transaes em forma de onda. Vale primar linha de cdigo em System Verilog necessria para o Simvision [4] reconhecer e apresentar as transaes. recording_detail = OVM_FULL; Ao efetuar a simulao, surgem alguns arquivos indesejados para a Verificao. Com isso, a mtrica utilizada para esse problema, a criao de um arquivo denominado Makefile, pois uma maneira muito conveniente de gerenciar grandes programas ou grupos de programas. Esse arquivo faz a manuteno de programas observando quais foram mudados desde a ltima compilao e recompilando apenas essas partes. Usando o artifcio supracitado, o ambiente fica livre de flags, e dessa maneira a simulao do Single Refmod se apresenta da seguinte maneira:

Figura 3.5. Representao em blocos lgicos do Double Refmod

O elemento Sink do Single Refmod ser substitudo pelo Checker, que ser responsvel em analisar a sada do Reference Model. O Source o mesmo utilizado no Single Refmod, ir gerar estmulos e ser repassado atravs de uma FIFO de suas sadas, este artifcio utilizado foi desenvolvido no Laboratrio de Arquiteturas Dedicadas (LAD). O principal objetivo desse subpasso testar se o Source e o Checker esto funcionando de modo adequado. Observa-se que necessria a criao de trs FIFO, sendo que uma dessas de duas sadas, assim segue a declarao de uma FIFO em System Verilog: tlm_fifo#(packet) my_first_fifo=new("myfifo",null,3); Nesse subpasso deve-se ocorrer um sincronismo de sada do Reference Model, pois sero 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 comunicao, pois sua funcionalidade construda com uma flexibilidade na implementao de arquiteturas de interconexo. Efetuada a simulao do Double Refmod, verificou-se a eficincia da execuo da Cobertura Funcional e, obteve-se a seguinte curva caracterstica:

Figura 3.4. Funcionamento do Single Refmod no Simvion

As seguintes representaes de onda so simulaes das transaes que so executadas no Single Refmod. Inicialmente so inseridos estmulos, representados na figura, no entanto, o segundo envio desses dados feito somente depois de um tempo que foi estabelecido pelo cdigo escrito em System Verilog. Com isso, verifica-se que o segundo envio de estmulos feito em momento sncrono aps 800 ns, concluindo que a comunicao do Testbench com o DUV est de forma coerente. Como foi desenvolvida uma randomicidade direcionada, as transaes so repassadas repetidamente no mesmo instante de tempo.

Figura 3.6. Curva caracterstica da Cobertura do Double Refmod

Conforme apresenta o grfico, a cobertura atinge 100% para trs estmulos diferentes, representados pelas trs curvas em destaque. IV. VERIFICAO FUNCIONAL DO DUV EMULATION

Realizados e devidamente testados os dois subpassos anteriores, nesse ltimo momento realizou-se a simulao 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 simulao, o Driver transformou transaes em sinais e o Monitor, sinais em transaes. Porm 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 no estava implementado. Para resolver esse problema, foi desenvolvido o seguinte artifcio:

Com a cobertura em um patamar livre de erros, o recebimento de dados do Checker foi satisfatrio em um mesmo instante de tempo. Os resultados revelaram que a Verificao Funcional permitiu uma rapidez no desenvolvimento do sistema DUV Emulation, pois a verificao incremental possibilitou a deteco de erros. V. CONSIDERAES FINAIS

Diante do que foi apresentado, o processo de construo de hardware no um exerccio simples de se resolver, e que a fase de verificao funcional se faz necessria para reduzir os custos que certos erros trs ao desenvolvimento de Hardware, e que atualmente tem uma fundamental importncia na construo de IP core (Semiconductor Intellectual Property core). Por fim, a principal contribuio e relevncia dessa pesquisa apresentar a forma mais eficiente de se realizar Verificao Funcional de Sistemas Digitais, utilizando ferramentas computacionais, metodologia BVM e System Verilog, que implicaram diretamente em um aumento de 20% na produtividade da verificao [7]. Com isso, todos esses fatos, trouxeram resultados considerados no ambiente da Engenharia da Computao, como por exemplo, na implementao de um prottipo de IP core de Identidade Vocal [11], desenvolvido no Laboratrio de Arquiteturas Dedicadas (LAD) da Universidade Federal de Campina Grande (UFCG). REFERNCIAS BIBLIOGRFICAS
[1] Janick Bergeron. Writing Testbenches: Functional Verification of HDL Models, Second Edition. Kluwer Academic Publishers, Norwell, MA, USA, 2003. [2] Chris Spear. System Verilog for Verification, A guide to Learning the Testbench Language Features, Second Edition, Springer, USA, 2006, pp. 79 - 124, 161 - 216, 295 - 332. [3] I. M. Pessoa. Gerao semi-automatica de testbenches para circuitos integrados digitais. Master's thesis, Universidade Federal de Campina Grande, Av. Aprigio Veloso, Campina Grande, 2007. [4] CADENCE DESIGN SYSTEMS, INC; MENTOR GRAPHICS. Open verification methodology user guide. Technical report, EUA, 2008. [5] I. Wagner, Valeria Bertacco, and Todd Austin. Stresstest: An automatic approach to test gener-ation via activity monitors. In DAC 05: Proceedings 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 Arajo Oliveira (2010). BVM: Reformulao da Metodologia de Verificao Funcional VeriSC. Dissertation - Federal University of Campina Grande. [8] 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., Paixo, L. L. SPVR: An IP core for Real-Time Speaker Verification. In: IP Based SoC Design Conference & Exhibition, 2010, Grenoble.

Figura 4.1. Implementao do DUV

Um Monitor e um Driver so acoplados a um segundo Modelo de Referncia, fazendo com que esse sistema tenha entrada e sada em nvel de sinal. Para monitorar o protocolo de comunicao entre o DUV e o Testbench utiliza-se o Actor. Esse elemento evita a escrita de cdigo adicional para o controle de sinais entre o Driver e a tripla que emula o DUV. Efetuando-se esse artifcio verificou-se a emulao do DUV e, de imediato, analisou-se o desempenho da Cobertura Funcional nesse ambiente de comunicao e, a partir disso, obteve-se a seguinte curva caracterstica com relao a trs estmulos gerados:

Figura 4.2. Curva caracterstica da Cobertura do DUV Emulation