Disser Tac A Oh Enrique

Universidade Federal de Campina Grande Centro de Engenharia Eltrica e Informtica Coordenao de Ps-Graduao em Informtica
Anlise de Mutao Aplicada Vericao Funcional de IP Core
Henrique do Nascimento Cunha

Dissertao submetida Coordenao do Curso de Ps-Graduao em Informtica da Universidade Federal de Campina Grande - Campus I como parte dos requisitos necessrios para obteno do grau de Mestre em Cincia da Computao.
rea de Concentrao: Cincia da Computao Linha de Pesquisa: Redes de Computadores e Sistemas Distribudos
Joseana Macdo Fechine (Orientadora)
Campina Grande, Paraba, Brasil c Henrique do Nascimento Cunha, 29/08/2008
FICHA CATALOGRFICA ELABORADA PELA BIBLIOTECA CENTRAL DA UFCG C972a 2008 Cunha, Henrique do Nascimento. Anlise de mutao aplicada vericao funcional de IP core / Henrique do Nascimento Cunha. - Campina Grande, 2008. 88 f.: il.
Dissertao (Mestrado em Cincias da Computao) - Universidade Federal de Campina Grande, Centro de Engenharia Eltrica e Informtica.
Referncias. Orientadora: Dra . Joseane Macdo Fechine.
1. Vericao funcional. 2. Teste de Mutao. 3. IP Core. I. Titulo
CDU 004.415.5(043)
Resumo
Existe uma necessidade crescente de aumento da conabilidade dos IP cores produzidos atualmente. Para tanto, faz-se necessrio o uso de uma metodologia de vericao funcional rigorosa para este tipo de produto. Como a vericao consome em mdia 70% dos recursos de um projeto de um IP core, torna-se necessrio o uso das tcnicas de vericao funcional a m de reduzir os custos dos projetos. Entretanto, essas tcnicas ainda no conseguem detectar todos os possveis problemas de um projeto. Surge, ento, a necessidade de construo e/ou aperfeioamento das metodologias de vericao funcional. Uma metodologia de vericao funcional, denominada VeriSC tem por objetivo eliminar algumas lacunas existentes em outras metodologias. Porm, h alguns passos da metodologia que ainda necessitam de renamento. Um deles consiste em determinar como medir a qualidade da cobertura. Existem algumas tcnicas de teste de software que visam a obteno de parmetros de qualidade relacionados cobertura de um conjunto de casos de teste. Dentre essas tcnicas, destacase a anlise de mutao, que possibilita a gerao de uma mtrica relativa qualidade de um conjunto de casos de teste de um dado IP core, a partir da anlise da execuo de mutantes. Estes mutantes so gerados automaticamente com base nos operadores de mutao escolhidos cuidadosamente. Este trabalho tem como meta a aplicao de testes de mutao na vericao funcional de sistemas digitais, para a avaliao da contribuio da tcnica na melhoria da qualidade da cobertura da vericao funcional. Vrias melhorias puderam ser observadas durante os experimentos, dentre estas destacam-se a possibilidade de encontrar defeitos no modelo de referncia. Pde-se tambm, observar um mdulo IDCT, onde se considera que foi realizada uma vericao funcional de qualidade, ainda pde ser melhorada em 11% de acordo com o parmetro de qualidade conhecido como "escore de mutao".
ii
Abstract
There is a growing need to make IP cores more reliable. Hence, it is necessary to use a rigorous functional verication methodology to this kind of product. This process is responsible for 70% of a projects resources, so it becomes important to enhance the functional verication techniques in order to reduce the cost of a project. A functional verication methodology, named VeriSC, is targeted at eliminating some aws in other methodologies. Though there is an aspect in this methodology that needs renement. One of them consists in determining the quality of the coverage achieved. There are some software techniques that try to extract quality parameters from test case sets of a given system. Among them, there is the mutation analysis technique, which proposes the generation of a quality metric by the analysis of mutants generated from the original program. These mutants are automatically created by applying carefully chosen mutation operators to the source code. Therefore, these operators must be chosen very carefully. The objective of this work is the application of mutation analysis within a digital system functional verication methodology, to check the contribution of this tecnique in evaluating the quality of the functional verication coverage. Various contributions could be made while apllying mutation analysis over a functional verication methodology, among them were the possibility to nd defects on the reference model. It was possible to nd out that a IDCT module, that was submitted to a high quality verication process, this process can still be enhanced another 11% according to the test quality parameter called mutation score.
iii
Agradecimentos
Agradeo a Deus pela vida e pela oportunidade de conhecer pessoas to maravilhosas, que sempre me apoiaram nesta caminhada. Agradeo aos meus pais, Ivonete e Nascimento, pelos ensinamentos de vida, coragem e honestidade e por me apoiarem sempre. Agradeo minha esposa Karina por ser companheira, prestativa e atenciosa at nas horas mais difceis. Agradeo aos meus irmos Aida, Ronnie e Neto por serem verdadeiramente irmos. Agradeo aos amigos cafas Wil Wil, Mago, Zambo, Coquim, Silveira e Marginal por toda sorte de situaes que tivemos que lidar juntos, perdermos juntos e ganharmos juntos. Agradeo professora Joseana, minha orientadora e amiga nesta Odissia cientca. Agradeo ao professor Elmar por tantos anos de ensinamentos e amizade desde a poca da graduao. Agradeo aos demais membros da banca por aceitarem avaliar e contribuir com este trabalho. E a tantos outros que encontrei, que contriburam direta ou indiretamente para a realizao deste trabalho. (Na verdade, a lista to grande que co com medo de colocar aqui e esquecer algum)
iv
Contedo
1 Introduo 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.2 Objetivos Especcos . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 3 4 9 13 13 14 14 16 17 18 19 20 21 21 25 25 27 27 28
Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Fundamentao Terica 2.1 2.2 A Metodologia de Vericao Funcional VeriSC . . . . . . . . . . . . . . . Anlise de mutao (Mutation Analysis) . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.3 2.4 Hiptese do Programador Competente . . . . . . . . . . . . . . . . Efeito de acoplamento (Coupling effect) . . . . . . . . . . . . . . . Anlise e Teste de Mutao . . . . . . . . . . . . . . . . . . . . . Operadores de Mutao . . . . . . . . . . . . . . . . . . . . . . . Aplicao da Anlise de Mutao . . . . . . . . . . . . . . . . . .
Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Descrio da Anlise de Mutao Aplicada Metodologia VeriSC 3.1 3.2 3.3 3.4 Vericao das pr-condies . . . . . . . . . . . . . . . . . . . . . . . . . Aplicao de mutao sobre o modelo de referncia . . . . . . . . . . . . . Vericao do modelo de referncia mutado em relao ao original . . . . . Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Apresentao e Anlise de Resultados 4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator . . . . . . . . 4.1.1 Modelo de Referncia . . . . . . . . . . . . . . . . . . . . . . . . v
CONTEDO 4.1.2 4.1.3 4.1.4 4.2 Ambiente de Vericao . . . . . . . . . . . . . . . . . . . . . . . Preparao do Ambiente para Aplicao das Mutaes . . . . . . . Mutaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi 28 29 30 34 34 35 35 43 45 45 46 50 50 50 51 51 51 51 53 64 71
Caso de estudo: IDCT - Inverse Discrete Cosine Transform . . . . . . . . . 4.2.1 4.2.2 4.2.3 Modelo de Referncia . . . . . . . . . . . . . . . . . . . . . . . . Ambiente de Vericao . . . . . . . . . . . . . . . . . . . . . . . Mutaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Consideraes Finais e Sugestes para Trabalhos Futuros 5.1 5.2 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sugestes para Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . .
A Ambiente e Ferramentas A.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . A.2 Sistema Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Linguagem de Programao . . . . . . . . . . . . . . . . . . . . . . . . . A.4 Ferramenta de Mutao . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Ferramenta para gerao semi-automtica de Testbenches . . . . . . . . . . A.6 Controle de verses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B Cdigo Fonte do Testbench Original do mdulo DPCM C Cdigo Fonte do Testbench alterado do mdulo DPCM. D Cdigo Fonte do Modelo de Referncia do mdulo IDCT
Lista de Smbolos
AVC - Advanced Video Coding CETENE - Centro de Tecnologias Estratgicas do Nordeste CI - Circuito Integrado DPCM - Differential Pulse Code Modulation DUV - Design Under Verication FIFO - First-in First-out H.261 - Padro de codicao de vdeo do VCEG H.263 - Padro de codicao de vdeo do VCEG desenvolvido para vdeo conferncia H.263+ - Padro de codicao de vdeo do VCEG verso 2 H.264 - Padro de codicao de vdeo tambm chamado de MPEG-4 Part 10 ou AVC HDL - Hardware Description Language IP-core - Intellectual Property of Hardware Project IDCT - Inverse Discrete Cosine Transform JPEG - Joint Photographic Experts Group JBIG - Joint Bi-level Image Experts Group LINCS - Laboratrio para Integrao de Circuitos e Sistemas MPEG - Moving Picture Experts Group MPEG-l Moving Picture Experts Group Layer 1 MPEG-2 Moving Picture Experts Group Layer 2 MPEG-4 Moving Picture Experts Group Layer 4 OSCI - Open SystemC Initiative LINCS-CETENTE - Laboratrio para Integrao de Circuitos e Sistemas - Centro de Tecnologias Estratgicas do Nordeste RTL - Register Transfer Level SCV - SystemC Verication Library SoC - System on Chip vii
viii TL - Transaction Level TLDS - Transaction Level Data Structure VCEG - Video Coding Experts Group VHDL - VHSIC Hardware Description Language
Lista de Figuras
2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 Vises de um projeto de hardware (IP core). . . . . . . . . . . . . . . . . . Fases de um projeto de hardware (IP core). . . . . . . . . . . . . . . . . . Exemplo hipottico de um DUV. . . . . . . . . . . . . . . . . . . . . . . . Estrutura geral de um testbench segundo a metodologia VeriSC. . . . . . . Primeiro passo para construo de um testbench. . . . . . . . . . . . . . . Segundo passo para a construo do testbench. . . . . . . . . . . . . . . . Terceiro passo para a construo do testbench. . . . . . . . . . . . . . . . . Aplicao da anlise de mutao na metodologia VeriSC. . . . . . . . . . . Aplicao das mutaes sobre o modelo de referncia no passo 2 da metodologia VeriSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Aplicao das mutaes sobre o modelo de referncia no passo 3 da metodologia VeriSC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 4.1 4.2 4.3 23 22 5 5 6 10 11 12 13 20
Aplicao das mutaes sobre o modelo de referncia aps a insero do DUV. 24 Aplicao das mutaes sobre o modelo de referncia do DPCM. . . . . . . Aplicao das mutaes sobre o modelo de referncia do mdulo IDCT. . . Grco da relao entre quantidade de mutantes e tempo de trabalho manual para classicao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 29 35
ix
Lista de Tabelas
4.1 4.2 4.3 Resultados da anlise de mutao sobre a unidade 1. . . . . . . . . . . . . Resultados da anlise de mutao sobre a unidade 2. . . . . . . . . . . . . Resultados da anlise de mutao sobre a IDCT na primeira rodada de anlise de mutao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Resultados da anlise de mutao sobre a IDCT na segunda rodada de anlise de mutao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 40 31 33
Lista de Cdigos Fonte

4.1 Cdigo fonte original da subrotina de subtrao do modelo de referncia do DPCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Cdigo fonte da subrotina de subtrao do modelo de referncia do DPCM com mutao gerada pela ferramenta Proteum, operador SRSR . . . . . . . 4.3 Trecho do cdigo fonte do modelo de referncia do mdulo DPCM que continha uma falta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Trecho do cdigo fonte do modelo de referncia do mdulo DPCM onde a falta foi corrigida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Trecho de cdigo que representa a adio dos parmetros de cobertura que identicariam a falta encontrada com a anlise de mutao. . . . . . . . . . 4.6 Trecho do cdigo fonte do modelo de referncia do IDCT sem aplicao de mutao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Trecho do cdigo fonte do modelo de referncia do IDCT com mutante na linha 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 4.9 Cdigo fonte do exemplo de deslocamento de 8 bits para a direita. . . . . . Cdigo fonte do exemplo de deslocamento de 2408 bits para a direita. . . . 37 38 38 37 33 32 31 30 30
4.10 Cdigo fonte na linguagem Assembly do exemplo de deslocamento de 8 bits para a direita. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Cdigo fonte na linguagem Assembly do exemplo de deslocamento de 2408 bits para a direita. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Trecho do Cdigo Fonte de um mutante vivo no-equivalente ao programa original. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13 Trecho do Cdigo Fonte do programa original onde foi aplicada mutao. B.1 Cdigo fonte do modelo gerador automtico de estmulos do mdulo DPCM xi 41 41 53 39 38
LISTA DE CDIGOS FONTE B.2 Cdigo fonte do modelo de referncia do mdulo DPCM . . . . . . . . . . B.3 Cdigo fonte das subrotinas que executam as funcionalidades do DPCM . . B.4 Cdigo fonte do Checker do mdulo DPCM . . . . . . . . . . . . . . . . . B.5 Cdigo fonte das estruturas de dados das transaes do mdulo DPCM . . . B.6 Cdigo fonte do mdulo que conecta todos os elementos do testbench . . . C.1 Cdigo fonte do modelo de referncia do mdulo DPCM modicado para a mutao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.2 Cdigo fonte das subrotinas que executam as funcionalidades do DPCM modicado para a mutao. . . . . . . . . . . . . . . . . . . . . . . . . . . C.3 Cdigo fonte do checker do mdulo DPCM . . . . . . . . . . . . . . . . . C.4 Cdigo fonte do mdulo que liga todos os elementos do testbench. . . . . . D.1 Cdigo fonte da subrotina que implementa a IDCT . . . . . . . . . . . . .
xii 55 58 58 59 62
64
67 67 69 71
Captulo 1 Introduo
O desenvolvimento de circuitos integrados (CI) levado a efeito por meio de um processo que engloba vrias fases. Cada fase consome recursos do projeto (mo-de-obra, tempo, dinheiro, etc.). O objetivo do projeto desses circuitos a obteno de um produto com qualidade aceitvel pelo mercado, mas que respeite os recursos alocados para a sua execuo. Em geral, o mercado de circuitos integrados no aceita que artefatos de hardware apresentem defeitos que possam ser detectados pelos usurios nais. Por isso, torna-se necessrio o uso de um procedimento que fornea um indicativo da qualidade do artefato que est sendo desenvolvido. Por este motivo, utilizada uma metodologia de vericao funcional. A vericao realizada por meio da simulao de IP core em um ambiente de vericao, denominado testbench. Estima-se que a vericao funcional consome a maior parte dos recursos de um projeto de um CI. Cerca de 70% dos recursos do projeto so gastos nessa fase [3][25]. Por isso, necessrio realiz-la com o mximo de qualidade, pois a mais importante, a mais difcil e a mais onerosa, em termos econmicos, de todo projeto. Dentre as metodologias de vericao funcional de IP core existentes, a metodologia VeriSC [10] tem por objetivo suprir as necessidades de um projeto, eliminando algumas lacunas identicadas em outras metodologias. Esta metodologia ser utilizada neste trabalho e ser descrita mais detalhadamente no Captulo 2. Independentemente da metodologia a ser utilizada, torna-se necessrio saber quando a vericao funcional deve parar, visto os recursos para cada projeto so limitados. Para tanto, ser utilizada, neste trabalho, a cobertura funcional. Entende-se por cobertura fun1
1.1 Objetivos
cional, a maneira pela qual o engenheiro de vericao funcional se posiciona em relao ao trmino da vericao. uma medida de progresso deste processo [3]. Portanto, uma das questes envolvidas no processo de vericao funcional : como denir um bom conjunto de parmetros de cobertura? O termo bom bastante subjetivo. Por isso, importante estabelecer mtricas objetivas que dem um indicativo de que estes parmetros de cobertura - a meta a ser atingida pela vericao - so satisfatrios. No contexto de software, existe uma tcnica de teste capaz de fornecer o tipo de mtrica anteriormente citada. Essa tcnica conhecida como teste de mutao [12], a ser detalhada no Captulo 2, Seo 2.2, deste trabalho. Diante do exposto, pode-se estabelecer os objetivos deste trabalho conforme descrio a seguir.
1.1
Objetivos
O principal objetivo do trabalho avaliar o uso da anlise de mutao na metodologia de vericao funcional VeriSC [10]. Para a aplicao da tcnica devem ser escolhidos testbenches nos quais o engenheiro de vericao tenha conseguido uma cobertura que ele considera adequada, mas que no haja parmetro objetivo para determinar a qualidade da cobertura dos parmetros de cobertura escolhidos.
1.1.1 Objetivos Especcos

Dentre os objetivos especcos, pode-se destacar: Entender e aplicar, de forma prtica, os conceitos de teste de mutao no contexto de hardware; Adaptar a tcnica de anlise de mutao metodologia de vericao funcional VeriSC; Avaliar a qualidade da vericao funcional realizada com base nos resultados obtidos a partir da anlise de mutao.
1.2 Organizao da Dissertao
Para averiguao da tcnica proposta, foram analisados dois casos de estudo, que constituem mdulos importantes no contexto do desenvolvimento de IP core, com diferentes nveis de complexidade, sendo estes: O mdulo DPCM (Differential Pulse Code Modulation), exemplo de aplicao da tcnica em um mdulo cuja principal funo converter um sinal analgico em um sinal digital; O mdulo IDCT (Inverse Discrete Cosine Transform), parte importante de um IP-core decodicador de vdeo em formato MPEG4, cujo objetivo calcular a transformada inversa do cosseno de um sinal.
1.2
Organizao da Dissertao
Os demais captulos desta dissertao esto organizados conforme descrio a seguir. Captulo 2: Concentra-se a fundamentao terica necessria aplicao da tcnica de teste de mutao metodologia VeriSC; Captulo 3: Est contida a descrio das mutaes a serem realizadas sobre o ambiente de vericao; Captulo 4: So apresentados e analisados os resultados obtidos com a aplicao da anlise de mutao sobre os dois casos de estudo escolhidos. Captulo 5: So apresentadas as consideraes nais e as sugestes para trabalhos futuros.
Captulo 2 Fundamentao Terica

Um IP core uma unidade de propriedade intelectual (IP - Intellectual Property). Quando se trata de um IP core digital, este passvel de implementao em HDL (Hardware Description Language). Dentro do contexto do projeto de um IP core, pode-se trabalhar com trs vises (Figura 2.1). A viso que corresponde inteno do projeto, que anterior especicao. Portanto, s existe no pensamento do projetista. A viso que corresponde especicao aquela que o projetista - consciente da inteno do projeto - consegue documentar, de maneira a elaborar uma especicao funcional do sistema a ser implementado. A ltima viso a implementao, que corresponde ao que foi implementado daquilo que foi especicado. O ideal seria que os trs conjuntos fossem iguais, de tal forma que a inteno do projeto fosse preservada em sua implementao [25]. No modelo apresentado na Figura 2.1, existem alguns subconjuntos importantes que devem ser observados: Subconjunto E: a parte da inteno e da especicao do projeto que no foi implementada; Subconjunto F : tudo aquilo que foi especicado e implementado, mas no era a inteno do projeto; Subconjunto G: Representa a parte que inteno do projeto e que foi implementada, porm no fazia parte da especicao;
Figura 2.1: Vises de um projeto de hardware (IP core). Subconjunto H : tudo aquilo que foi implementado e que faz parte da especicao e da inteno do projeto. Existe um esforo para maximizar o tamanho do subconjunto H, de forma que a diferena entre os trs conjuntos seja vazia. Um projeto de IP core consiste de vrias fases dispostas em um processo de desenvolvimento, destacando-se especicao, implementao e vericao. As fases mais comumente realizadas em um projeto de IP core podem ser visualizadas na Figura 2.2 [10].
Figura 2.2: Fases de um projeto de hardware (IP core). As fases acima representadas podem ser resumidas da seguinte forma:
6 Especicao: Nesta fase, elaborada a documentao referente s funcionalidades do projeto. O projetista tenta fazer a inteno do projeto tomar a forma de um documento (ou uma srie de documentos) que possa ser compartilhado por toda a equipe de desenvolvimento. Planejamento da Vericao: Nesta fase, a equipe de vericao planeja como ser desenvolvido o ambiente de vericao, dene os vetores de teste que sero usados, determina os objetivos a serem alcanados pela vericao e estabelece um cronograma para o cumprimento de tais objetivos. Implementao do DUV : Nesta fase, o DUV (Design Under Verication) implementado. Um IP core pode ser um DUV, ou uma combinao de vrios DUV, cada um exercendo uma funo especca dentro do sistema, como mostrado na Figura 2.3. Um DUV uma unidade que implementa uma funcionalidade descrita na especicao. Portanto, deve ser vericada com respeito a esta especicao. Este processo de vericao executado por meio da simulao do DUV.
Figura 2.3: Exemplo hipottico de um DUV. Um DUV descrito, geralmente, no nvel chamado de RTL [16], que uma forma de descrever o IP-core por meio do uso de registradores. Ou seja, o IP-core visto a partir da transferncia de dados entre os seus registradores. Para que um IP-core se transforme em um dispositivo real de hardware se faz necessria a sua implementao no nvel RTL por meio de alguma linguagem de descrio de hardware (HDL).
7 Implementao do testbench: Nesta fase, implementa-se o ambiente de vericao, chamado de testbench, que tem por objetivo a gerao de estmulos e observao das respostas. Um testbench deve conter as seguintes caractersticas [3]: Ser auto-vericvel: No deve haver interveno humana na comparao de estmulos esperados e estmulos recebidos; Especicado no nvel de transao (Transaction Level, ou TL): Interfaces descritas em termos de os e sinais devem ser utilizadas apenas para conectar o DUV; Randmico (Aleatrio): Os estmulos devem ser gerados de forma aleatria dentro de um intervalo bem denido; Dirigido cobertura: A gerao de estmulos e a quantidade de estmulos gerados devem depender apenas dos parmetros de cobertura funcional medidos durante a simulao. Para este trabalho, no so considerados testbenches que no possuam estas caractersticas. Vericao: A vericao trata de determinar se se o IP core em questo est de acordo com os requisitos do projeto [3][25]. Os tipos de vericao podem ser divididos da forma [3]: Vericao formal ou esttica: Est relacionada com a prova de teoremas ou vericao de equivalncia. Pode envolver a anlise do espao de estados do problema o que, em muitos casos, leva a uma complexidade invivel; Vericao funcional ou dinmica: A partir de simulaes de modelos em diferentes nveis de abstrao, busca-se mostrar que o IP core est de acordo com a especicao; Vericao Hbrida: Utilizao das duas tcnicas anteriores sobre os submdulos do IP core onde cada uma for melhor aplicvel; O trabalho ora descrito, concentra-se na vericao funcional. Sntese: Nesta fase, aps ser vericado, o DUV passa por uma traduo do modelo descrito em uma linguagem de descrio de hardware para uma netlist que contm,
8 alm da prpria descrio, informaes sobre os atrasos de portas lgicas necessrias para o funcionamento do DUV em um dispositivo de prototipao pr-determinado. Simulao Ps-sntese: Nesta fase, o DUV passa novamente pela mesma simulao pela qual j passou na fase de Vericao, permitindo determinar se a introduo dos atrasos de portas lgicas altera o funcionamento de tal forma que algum erro seja produzido. Prototipao: O DUV , de fato, prototipado em um dispositivo a partir do qual o seu comportamento possa ser concretamente (e no mais em simulao) analisado. SoC: Aps ser prototipado, o DUV pode ser enviado para a fase de desenho do layout do circuito que se quer colocar em um CI (Circuito Integrado). Considerando o tipo de vericao (funcional) utilizado para este trabalho, a simulao apenas no suciente para assegurar que todas as funcionalidades previstas na especicao foram implementadas. Por isso, torna-se necessrio o uso de mecanismos, como a cobertura funcional, para medir o estado e o progresso da simulao [10]. Estima-se que o processo de vericao funcional requer cerca de 70% dos recursos (tempo, dinheiro, mo de obra) de um projeto de hardware [3][25], pois visa detectar erros em fases iniciais do projeto, minimizando a probabilidade de encontrar erros em fases nas quais estes erros causem maior prejuzo. Isto , na fase de produo do CI. Existe, portanto, a necessidade de tornar o processo de vericao funcional to rpido quanto possvel sem comprometer a sua ecincia, para que os custos com esta fase sejam minimizados. Para este trabalho, ser utilizada a metodologia de vericao funcional VeriSC, pois os testbenches propostos na metodologia atendem aos requisitos anteriormente mencionados. Essa metodologia tambm dispe de um suporte ferramental que automatiza muitas das tarefas de construo dos testbenches, proporcionando a reduo do tempo de vericao. Esta metodologia foi desenvolvida no contexto do projeto Brazil-IP [5]. Este projeto visa a formao de recursos humanos no Brasil para a indstria de microeletrnica. Outro objetivo do projeto o desenvolvimento de IP cores com qualidade de acordo com os padres internacionais. Para atingir esta meta, foram desenvolvidos trs IP cores: Um decodicador de
2.1 A Metodologia de Vericao Funcional VeriSC
MP3, um microcontrolador 8051 e um decodicador de MPEG4 [29]. Para os trs IP cores foi elaborado o layout para fabricao em silcio. Vale destacar que estes chips funcionaram corretamente. Em conferncia realizada na Frana, o IP-SoC 2006 [15], o trabalho apresentado pelos integrantes do Brazil-IP, referente aos resultados do projeto, foi premiado como o melhor artigo do evento. Outro resultado importante obtido pelo Brazil-IP foi a criao do LINCSCETENE [8], uma das seis Design Houses do Brasil, que liderar os esforos do - agora programa do Governo Federal - Brazil-IP.
2.1
A Metodologia de Vericao Funcional VeriSC
As metodologias de vericao funcional existentes apresentam alguns problemas em comum que devem ser observados [10]: Consomem uma quantidade substancial dos recursos de um projeto; O cdigo gerado para o testbench muitas vezes no pode ser reusado; A decomposio hierrquica no considerada no processo de vericao funcional, causando o aparecimento de trabalho extra para a construo de mais testbenches; A vericao funcional s comea quando todo o projeto modelado no nvel RTL; Testbenches so depurados junto com o DUV, de tal forma que quando uma falha encontrada, no se sabe se ela est no DUV ou no testbench; Muitos destes problemas surgem pelo fato das metodologias tradicionais de vericao funcional proporem que o DUV seja implementado antes do testbench. A metodologia de vericao funcional VeriSC prope que o testbench seja feito antes do DUV, de tal forma que ele possa ser testado independentemente, eliminando vrios dos problemas anteriormente expostos. A seguir, uma breve descrio da metodologia, com destaque at o passo a partir do qual ser feita uma proposta de enriquecimento.
10
Para a utilizao da metodologia, necessrio um RM (Reference Model), um modelo que implementa todas as funcionalidades previstas na especicao. No est no escopo da metodologia denir a forma de obteno do modelo de referncia. Na Figura 2.4 apresentada a estrutura geral de um testbench [10].
Figura 2.4: Estrutura geral de um testbench segundo a metodologia VeriSC. A funo do testbench fornecer estmulos ao RM e ao DUV e capturar suas sadas vericando se estas so equivalentes. A sincronizao feita por meio de estruturas de dados que carregam transaes (pode ser, por exemplo do tipo FIFO, ou First-In-First-Out, ou seja, o primeiro elemento a ser inserido o primeiro a ser retirado). Neste trabalho, estas estruturas sero chamadas TLDS (Transaction Level Data Structure). A metodologia foi elaborada para vericao de sistemas digitais sncronos, que so aqueles sistemas digitais regidos (sincronizados) por um sinal de relgio (ou clock). A seguir, uma breve descrio dos componentes do testbench e suas respectivas funes. Source: Responsvel por fornecer dados em TL para o RM e para o DUV atravs do TDriver. O Source se conecta a estes elementos por meio de TLDS. A mesma quantidade de conexes que h com TDrivers h, tambm, com o RM e h uma conexo para cada interface; TDriver: Tem por objetivo receber os dados em TL do Source, gerar sinais referentes ao protocolo utilizado pelo DUV e enviar estes sinais juntamente com os dados recebidos, tambm no nvel de sinais. Existe um TDriver para cada interface do DUV.
11
A vantagem a modularizao, de modo que, se for necessrio mudar uma interface, apenas um TDriver alterado; TMonitor: o anlogo do TDriver para as interfaces de sada do DUV. Recebe os sinais da interface correspondente, os transforma em dados em TL e os envia por meio de uma TLDS para o Checker; Reference Model: O modelo de referncia recebe dados em TL do Source atravs de uma TLDS, realiza as operaes que esto na especicao e envia dados em TL para o Checker, tambm por meio de uma TLDS. De acordo com a metodologia VeriSC, preciso ento construir estes elementos independentemente do DUV e depur-los de maneira simples. A primeira fase da construo de um testbench a gerao de seus elementos para o DUV como um todo [10]. Esta fase pode ser concretizada em trs passos: 1. O RM (Reference Model) deve ser testado de acordo com sua capacidade de interagir com o testbench (receber e produzir dados em TL). Para isso, cria-se um Pre-Source que gera apenas entradas para o RM e um Sink que tambm recebe sadas apenas do RM. A realizao deste passo, tem por objetivo a vericao das ligaes entre os elementos Pre-Source, RM e Sink. Pode-se, por exemplo, ter no Sink uma instruo que imprime na sada padro o resultado enviado pelo RM. Para que o engenheiro de vericao visualize a sada, e verique mediante anlise manual se as ligaes esto corretas. Esta construo pode ser visualizada na Figura 2.5.
Figura 2.5: Primeiro passo para construo de um testbench. 2. O Source e o Checker tambm devem ser testados de acordo com sua capacidade de gerar estmulos vlidos e de vericar a equivalncia da resposta do RM a estes estmulos. Isto pode ser vericado utilizando duas instncias do modelo de referncia. O Source estimula estas duas instncias e o Checker verica se suas sadas so equivalentes. Ao utilizar esta abordagem com todos os estmulos especicados e vericar
12
que o Checker no acusa erros, erros devem ser introduzidos para avaliar se o Checker capaz de acus-los. Esta estrutura mostrada na Figura 2.6.
Figura 2.6: Segundo passo para a construo do testbench. 3. Neste passo, sero testados o(s) TDriver(s) e o(s) TMonitor(s). Para efeito de simplicao, sero considerados apenas um TDriver e um TMonitor, que sero chamados TDriverA e TMonitorA. Este um dos passos mais importantes, pois nele que o testbench pode ser simulado sem a presena do DUV. Analogamente ao passo anterior, o modelo de referncia far o papel do DUV. O problema que o modelo de referncia se comunica em TL, e o DUV no nvel de sinais. Portanto, torna-se necessrio incluir elementos adicionais para interconectar o RM e o TDriverA e o TMonitorA. Desta forma, so criados um TMonitor chamado TMonitor0 que tem a mesma interface do TDriverA e recebe os sinais do TDriverA e repassa os dados recebidos para o RM em TL, e um TDriver chamado TDriver0 que tem a mesma interface do TMonitorA e responsvel por receber as respostas do RM em TL e envi-las para o TMonitorA no nvel de sinais. Em momento posterior, a tripla (TMonitor0, RM, Tdriver0) ser substituda pelo DUV para que seja realizada a sua vericao funcional. Na Figura 2.7, mostrada a estrutura proposta. Neste ponto, foi identicada uma lacuna na metodologia. Fica claro que devem ser introduzidos erros no modelo de referncia para testar a funcionalidade do Checker, mas a metodologia no especica uma forma sistemtica para realizar esta atividade. Tambm foge do escopo da metodologia determinar critrios objetivos para analisar se a cobertura est satisfatria. Prope-se, ento, que seja introduzida na metodologia a tcnica de anlise de mutao (apresentada no Captulo 2, Seo 2.2), para preencher
2.2 Anlise de mutao (Mutation Analysis)
13
Figura 2.7: Terceiro passo para a construo do testbench. estas lacunas. A metodologia VeriSC no prev em que passo devem ser acrescentados os parmetros de cobertura. Para que seja possvel a incluso da tcnica, deve-se acrescent-los no testbench a partir do passo 2, pois para identicar os mutantes, torna-se necessrio ter as duas instncias do modelo de referncia, uma que recebe as mutaes e outra que , de fato, o modelo de referncia. Mais detalhes sobre a aplicao das mutaes podem ser encontrados na Seo 2.2.
2.2
Anlise de mutao (Mutation Analysis)
No contexto dos projetos de software, existe uma busca crescente pela qualidade dos produtos nais. Muitas tcnicas de teste visam assegurar esta qualidade para que os sistemas tenham aceitao do mercado sempre mais exigente. Uma dessas tcnicas que merece destaque a anlise de mutao. Para a descrio da anlise de mutao deve-se considerar a Hiptese do Programador Competente e o Efeito de Acoplamento.
2.2.1 Hiptese do Programador Competente

A hiptese do programador competente arma que programadores tm a tendncia de escrever programas que so prximos de estarem corretos [12]. Eles no escrevem programas ao acaso, mas esto sempre diminuindo a distncia entre o que feito e o programa esperado. Programadores tambm tm uma idia dos erros mais comuns de acontecer e a habilidade e oportunidade de analisar seus programas. Em outras palavras, um programador pode at escrever um programa incorreto, porm este programa difere de um programa correto por
14
faltas relativamente simples. Faltas simples e complexas so denidas da seguinte forma [19]: Falta simples: uma falta que pode ser corrigida fazendo-se uma nica alterao na expresso de origem; Falta complexa: uma falta que no pode ser corrigida fazendo-se uma nica alterao na expresso de origem.
2.2.2 Efeito de acoplamento (Coupling effect)

Sero denominados de mutantes aqueles programas nos quais foi introduzida uma falta simples, e de mutantes de alta ordem aqueles que so gerados ao introduzir mltiplas faltas simples ao programa original. Existem, porm, faltas complexas que no podem ser geradas por mutao de alta ordem. Desta forma, pode-se formular a hiptese do efeito de acoplamento da seguinte forma [19]: Faltas complexas esto acopladas a faltas simples de uma forma tal que um conjunto de casos de teste que detecta todas as faltas simples de um programa, vai detectar um alto percentual das faltas complexas. O efeito de acoplamento foi proposto em 1978 [12], depois foi mostrado empiricamente em 1992 [19] e demonstrado teoricamente em 1995 [34][35]. Restringindo, ento, o efeito de acoplamento para o domnio das mutaes, tem-se que [19]: Mutantes de alta ordem esto acoplados a mutantes simples de uma forma tal que um conjunto de casos de teste que detecta todos os mutantes simples de um programa, vai detectar um alto percentual dos mutantes de alta ordem.
2.2.3 Anlise e Teste de Mutao

Para tornar claro o objetivo deste trabalho, faz-se necessrio a introduo dos conceitos de Anlise de Mutao (Mutation Analysis) e Teste de Mutao (Mutation Testing) [23]. Anlise de Mutao A anlise de mutao a introduo de faltas em programas, criando vrias verses deste mesmo programa, cada um contendo uma nica falta.
15
Casos de teste so ento executados sobre estes programas que contm faltas, com o objetivo de determinar se o conjunto de casos de teste consegue detectar tais faltas. Desta forma, pode-se dizer que estes programas que contm faltas so chamados de mutantes, e um mutante morto quando consegue-se distinguir, a partir dos testes, a resposta de um mutante da resposta do programa original. Apenas mutantes simples so gerados , visto que o efeito de acoplamento garante a deteco de um alto percentual dos mutantes de alta ordem analisando apenas os simples. A medida de qualidade do conjunto de casos de teste, gerada pela anlise de mutao chamada escore de mutao e obtida segundo a relao representada na Equao 2.1. M E
EM =
(2.1)
em que EM o escore de mutao, M a quantidade de mutantes mortos e E a quantidade de mutantes gerados no equivalentes ao programa original. Pode-se, ento, dispor de duas situaes: EM = 1, ou seja, nenhum mutante cou vivo, ou caram vivos apenas os mutantes equivalentes ao programa original. EM < 1, ou seja, h mutantes vivos que no so equivalentes ao programa original e, portanto, a cobertura especicada tem um grau de qualidade proporcional ao escore de mutao. Assim sendo, quanto mais prximo de 1 (um), melhor o escore de mutao, e conseqentemente a cobertura. Quanto mais prximo de 0 (zero), pior o escore de mutao. Teste de Mutao O teste de mutao refere-se gerao de casos de teste visando melhorar o escore obtido pela anlise de mutao. Caso o escore de mutao seja menor do que 1 (um), mais casos de teste devem ser gerados para aproximar este escore de 1 (um). Desta forma, pode-se armar que o teste de mutao uma tcnica mais abrangente do que a anlise de mutao. Este trabalho, porm, concentra-se na anlise de mutao, pois o objetivo a introduo de faltas nos casos de teste dos programas, criando vrias verses destes programas, cada um
16
contendo uma nica falta. Foge do escopo do trabalho, a construo de novos casos de teste visando melhorar o escore obtido pela anlise de mutao.
2.2.4 Operadores de Mutao

As modicaes sintticas que resultam em mutantes so determinadas por um conjunto de operadores de mutao. Este conjunto determinado pela linguagem de programao utilizada e pelo sistema de mutao adotado [20]. Operadores so criados por dois motivos: Induzir mudanas sintticas baseadas em erros que programadores cometem tipicamente, ou forar objetivos de teste comumente requeridos. A seguir, so apresentados alguns operadores de mutao para a linguagem ANSI C, pois os modelos de referncia utilizados neste trabalho so escritos nesta linguagem. Estes operadores podem ser classicados em 4 tipos, de acordo com o elemento da linguagem sobre o qual o operador atua. Assim sendo, os operadores de mutao denidos para a linguagem C atuam sobre instrues, operadores da linguagem, variveis e constantes. Todos os operadores desenvolvidos para esta linguagem podem ser consultados no trabalho desenvolvido por Mathur [1]. STRP (Trap on Statement Execution): Este operador de instruo tem por objetivo revelar cdigo inalcanvel no programa. Para isso, ele substitui cada instruo do programa original pela instruo trap_on_statement() que termina a execuo do mutante. Caso esta instruo seja atingida, o mutante tratado como morto. VTWD (Twiddle Mutations): Valores de variveis e expresses podem comumente diferir do valor desejado por +1 ou -1. Esse operador representa esse erro. Cada varivel x substituda por pred(x) e succ(x), em que cada uma retorna, respectivamente, o predecessor imediato de x e o sucessor imediato de x. CRCR (Required Constant Replacement): Sejam I e R, os conjuntos {0, 1, 1, ui } e {0, 0, 1, 0, 1, 0, ur }, respectivamente. ui e ur denotam valores inteiros e reais utilizados pelo usurio do programa, respectivamente. Este operador modela o uso de uma varivel onde deveria ter sido utilizado um elemento de I ou de R. Como exemplo, pode-se considerar a seguinte expresso k = j + *p, onde k e j so variveis do tipo inteiro e p um ponteiro para um inteiro. Quando aplicado essa expresso, CRCR gerar os seguintes mutantes:
2.2 Anlise de mutao (Mutation Analysis) k = 0 + *p k = 1 + *p k = 1 + *p k = ui + *p k = j + null
17
2.2.5 Aplicao da Anlise de Mutao

Dadas as hipteses do programador competente e o efeito de acoplamento, possvel denir um sistema para determinar a qualidade dos casos de teste de um programa [12]. O objetivo determinar se um conjunto de casos de teste T adequado para testar um programa P . O sistema proposto executado da seguinte forma: 1. executado o conjunto de casos de teste T sobre o programa P . Caso P no passe no conjunto de casos de teste, ento P certamente errneo. Caso contrrio, o programa ainda pode conter erro e o conjunto de casos de teste no sucientemente sensvel para encontrar o erro, ou seja, no adequado; 2. O sistema de mutao, cria ento um conjunto k de mutantes de P que diferem do programa original apenas por uma falta simples. Esses mutantes sero denominados P1 , P2 , ..., Pk ; 3. Para o conjunto de casos testes T anteriormente denido, tem-se que: A sada de Pi mutantes difere da sada de P para algum teste do conjunto de casos de teste. Neste caso, diz-se que o mutante est morto. Ou seja, o erro introduzido pela mutao foi, de fato, detectado pelo conjunto de casos de teste; A sada de Pj mutantes no difere da sada de P para qualquer dos testes do conjunto de casos de teste. Neste caso, diz-se que o mutante est vivo. Este fato pode acontecer por dois motivos: O conjunto de casos de teste no sucientemente sensvel para vericar o erro introduzido pela mutao em Pj ;
2.3 Trabalhos Relacionados
18
Pj e P so, de fato, equivalentes e nenhum conjunto de casos de teste pode distingui-los. Para saber qual dos dois motivos de sobrevivncia de um mutante o correto, o mtodo empregado mais comumente a anlise manual por parte do engenheiro de testes. Pode-se armar, portanto, que um conjunto de casos de teste que mata todos os mutantes, ou deixa vivos apenas os mutantes equivalentes ao programa original dito adequado no seguinte sentido: ou o programa P est correto em relao aos testes realizados, ou existe um erro inesperado em P . Um dos grandes problemas da anlise de mutao o consumo de recursos computacionais. Existem, porm, algumas variantes da tcnica de anlise de mutao que a tornam menos onerosa. Pode-se, dentre elas, destacar a mutao seletiva [23][20]. Esta tcnica visa reduzir a quantidade de mutantes gerados por meio de uma abordagem de aproximao sugerida por Mathur [17]. Outra tcnica a mutao fraca [21][22], que tem por objetivo criar um conjunto de casos de teste mais limitado (mais fraco), que exige menos poder computacional, e quase to completo quanto a anlise de mutao em sua forma original.
2.3
Trabalhos Relacionados
No contexto de hardware, existem outros trabalhos relacionados mutao na vericao funcional de IP core. O primeiro o trabalho de Vado [33], cuja proposta a melhoria sistemtica dos vetores de teste utilizados na validao de circuitos digitais. Em sua abordagem, as mutaes so aplicadas sobre os modelos de circuitos digitais, escritos em linguagens como Verilog ou VHDL. O autor faz uma comparao entre os mtodos utilizados anteriormente com o que ele desenvolveu, obtendo resultados signicativos. Outro trabalho relacionado o desenvolvido por Serrestou [30], no qual so utilizadas mtricas de teste de mutao na vericao de componentes descritos na linguagem VHDL. O autor prope que as mutaes sejam realizadas sobre o DUV e, baseado no escore de mutao, um algoritmo gentico utilizado para melhorar automaticamente os vetores de teste do IP core.
2.4 Discusso
19
As abordagens dos autores desses dois trabalhos diferem do mtodo descrito nesta dissertao por inserir as mutaes no DUV. Para desenvolver testbenches segundo a metodologia VeriSC, no necessria a presena do DUV. Portanto, as mutaes utilizadas neste trabalho so sobre o modelo de referncia. Outro ponto de diferena reside no fato de que os autores propem o melhoramento dos vetores de teste baseando-se no resultado da mutao realizando, portanto, teste de mutao. Neste trabalho, o objetivo utilizar a anlise de mutao como medida de qualidade dos parmetros de cobertura funcional adotados.
2.4
Discusso
Um IP core uma unidade de propriedade intelectual que, ao ser implementada em uma linguagem de descrio de hardware, precisa ser vericada em relao sua especicao. Metodologias de vericao podem ser utilizadas para esse propsito. A cobertura funcional pode ser denida como um mecanismo para medir o estado e o progresso da vericao do IP core. A cobertura um parmetro que permite ao engenheiro de vericao se posicionar em relao ao trmino da vericao. Uma questo que deve ser levada em considerao : Os parmetros de cobertura so adequados?. O termo adequado subjetivo. Portanto, precisa-se de uma mtrica objetiva que fornea uma indicao de quo adequada a cobertura funcional. Para esse propsito, ser utilizada neste trabalho a anlise de mutao. No contexto de software, a aplicao dessa tcnica capaz de produzir um escore de mutao (relao entre mutantes vivos e mutantes mortos) que pode ser utilizado como medida de qualidade de um dado conjunto de casos de teste. Foram encontrados outros trabalhos que utilizam a anlise e o teste de mutao no contexto de hardware, o que demonstra que h interesse em aplicar mutao para auxlio na vericao de sistemas digitais.
Captulo 3 Descrio da Anlise de Mutao Aplicada Metodologia VeriSC

Considerando os objetivos apresentados no Captulo 1 (Introduo) e os conceitos abordados no Captulo 2 (Fundamentao Terica), a aplicao da anlise de mutao na metodologia VeriSC se d de acordo com o modelo apresentado na Figura 3.1.
Figura 3.1: Aplicao da anlise de mutao na metodologia VeriSC. Nas sees a seguir, ser denida cada etapa da aplicao da anlise de mutao.
20
3.1 Vericao das pr-condies
21
3.1
Vericao das pr-condies
Para a aplicao da anlise de mutao, deve-se ter um ambiente de vericao que atenda as seguintes pr-condies: Cobertura: Como a inteno obter uma medida de qualidade dos parmetros de cobertura da vericao funcional, necessrio que estes parmetros estejam estabelecidos antes da aplicao da tcnica. Em VeriSC, estes parmetros so adicionados nos passos 2 ou 3 descritos no Captulo 2 deste trabalho. Simulao: A simulao deve atingir 100% de cobertura e no acusar erros ou travar a execuo. Um erro ou travamento encontrado antes da aplicao da anlise de mutao caracteriza um programa original j morto, o que no faz sentido para esta anlise. Programador Competente: Quem realiza a anlise de mutao um membro da equipe de vericao. De preferncia um engenheiro de vericao que conhea a linguagem de programao do modelo de referncia, mas que no tenha participado do seu desenvolvimento.
3.2
Aplicao de mutao sobre o modelo de referncia
Na metodologia VeriSC, no necessria a presena do DUV para que se possa construir o ambiente de vericao. At mesmo os parmetros de cobertura j tm que estar denidos antes de introduzir o DUV no testbench. Assim sendo, pretende-se obter a medida de qualidade da vericao funcional da mesma forma: sem a necessidade da presena do DUV. Portanto, as mutaes so aplicadas sobre uma das instncias do modelo de referncia como mostrado na Figura 3.2. Para a gerao dos mutantes, foi utilizada a ferramenta Proteum. Esta foi a nica ferramenta encontrada que implementa todos os operadores disponveis para a linguagem C. A Proteum est disponvel mediante solicitao aos seus idealizadores [11]. Mais informaes sobre a Proteum e sobre as outras ferramentas utilizadas (eTBc e Subversion) podem ser encontradas no Anexo A.
3.2 Aplicao de mutao sobre o modelo de referncia
22
Na Figura 3.2, tem-se um testbench que possui Source e Checker completos. Os parmetros de cobertura foram adicionados, e a simulao neste passo atinge as pr-condies estabelecidas na Seo 3.1 do Captulo 3.
Figura 3.2: Aplicao das mutaes sobre o modelo de referncia no passo 2 da metodologia VeriSC. Na Figura 3.2, tem-se um testbench que possui Source, TDriver, Tmonitor, e Checker completos. Os parmetros de cobertura foram adicionados, e a simulao neste passo atinge as pr-condies estabelecidas na Seo 3.1 deste captulo. Apesar de no ser necessria a presena do DUV para a realizao de anlise de mutao em testbenches, est prtica tambm possvel. As mutaes ainda so aplicadas sobre o modelo de referncia como mostrado na gura 3.4.
23
Figura 3.3: Aplicao das mutaes sobre o modelo de referncia no passo 3 da metodologia VeriSC.
24
Figura 3.4: Aplicao das mutaes sobre o modelo de referncia aps a insero do DUV.
3.3 Vericao do modelo de referncia mutado em relao ao original
25
3.3
Vericao do modelo de referncia mutado em relao ao original
Em qualquer um dos casos mostrados nas Figuras 3.2 ou 3.3, a cada mutante gerado executada a simulao at que acontea uma das situaes de nal de simulao, que podem ser quatro. As situaes so as seguintes: 1. O Checker acusa um erro, o que quer dizer que o conjunto de casos de teste consegue diferir o mutante do programa original. Este mutante , ento, marcado como morto. 2. A simulao executa at o m com 100% de cobertura e sem nenhum erro. Neste caso, o mutante marcado como vivo e deve ser avaliado manualmente para determinar se ele equivalente ao programa original. Caso a resposta seja positiva, ele um mutante irrelevante e no entra na equao da mtrica de qualidade descrita no Captulo 2. 3. A simulao trava, a cobertura nunca atingida e, portanto, isto congura um comportamento inesperado. Neste caso, o mutante marcado como morto. 4. A simulao abortada antes de atingir 100% pelo prprio mutante. Neste caso, ele tambm marcado como morto. Um mutante marcado como vivo pode representar um problema na cobertura. Pois, como aquele trecho de cdigo no foi exercitado o suciente para detectar o mutante, consiste em uma funcionalidade que pode conter uma falha. Ao terminar a execuo de um mutante, outro escolhido at que no restem mais mutantes.
3.4
Discusso
Para a aplicao da anlise de mutao na metodologia VeriSC, foram estabelecidas as prcondies e os estgios da metodologia nos quais possvel aplicar a tcnica. Para cada mutante gerado, tambm estabelecida uma srie de situaes que a simulao de cada mutante pode atingir. A grande vantagem desta abordagem a avaliao da cobertura do testbench mesmo antes da introduo do DUV. Caracterstica herdada das prprias prticas
3.4 Discusso
26
existentes na metodologia VeriSC. Uma desvantagem que a simulao de mutantes que travam no detectada automaticamente, forando o engenheiro de vericao a monitorar manualmente os mutantes que tem esse comportamento.
Captulo 4 Apresentao e Anlise de Resultados

Neste captulo, so apresentados os casos de estudo da aplicao da anlise de mutao em vericao funcional. Foram escolhidos dois casos, implementados em ordem de complexidade. O primeiro deles o DPCM (Differential Pulse Code Modulator). O segundo um mdulo que realiza a funo de uma IDCT (Inverse Discrete Cosine Transform). A seguir so apresentados os detalhes dos experimentos.
4.1
Caso de estudo: DPCM - Differential Pulse Code Modulator
Uma das tcnicas bastante utilizadas na rea de compresso de imagem a codicao preditiva, visto que visa eliminar a redundncia interpixels presente na informao original, codicando somente a diferena ou resduo entre o valor do pixel original e o valor predito para este pixel. Como em uma imagem h redundncia de informao entre os pixels vizinhos e, conseqentemente, o valor de cada pixel pode ser predito por sua vizinhana. Nesse contexto, a Modulao por Cdigo de Pulso Diferencial (Differential Pulse Code Modulation - DPCM) o mtodo que utiliza a soma do valor do pixel predito com o valor do resduo para obter o valor do pixel original. Quando o valor predito se aproxima do valor do pixel original, obtm-se um resduo pequeno permitindo uma codicao, por meio de um cdigo de comprimento varivel, com
27
4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator
28
menos bits para o resduo do que se a codicao fosse feita diretamente sobre o valor do pixel original (normalmente 8 bits), possibilitando, assim, o processo de compresso . A DPCM pode ser modelada de forma bastante simples por apresentar apenas as seguintes funcionalidades [26]: Diferena: Realiza a diferena entre duas amostras de valor inteiro, a recebida no instante de tempo anterior e a recebida no instante de tempo atual. Para isso, necessrio armazenar a amostra anterior. Saturao: A amostra resultante da diferena deve estar dentro de uma faixa de valores pr-estabelecida. Caso o resultado da diferena seja maior do que o limite superior, a sada ser o prprio limite superior. Caso o resultado da diferena seja menor do que o limite inferior, a sada ser o prprio limite inferior. A codicao preditiva, mais especicamente a DPCM, tem fundamental importncia nos seguintes padres de compresso para imagens: JPEG, JBIG e MPEG [4]. Apesar da simplicidade na forma de obteno, observa-se, portanto, que a DPCM se constitui uma tcnica bastante relevante para o contexto do Processamento Digital de Imagens.
4.1.1 Modelo de Referncia

As subrotinas que implementam as funcionalidades do DPCM foram escritas na linguagem C e esto representadas no cdigo fonte B.3, constituindo o modelo de referncia. Para realizar a comunicao com o testbench, foi utilizado um mdulo em SystemC que contm as estruturas de dados que se conectam com o Source e o Checker. Este mdulo representado no cdigo fonte B.2.
4.1.2 Ambiente de Vericao

O ambiente de vericao foi escrito em SystemC e de acordo com a metodologia VeriSC at o passo chamado de Testbench Conception [10]. Neste passo, foram adicionados os parmetros de cobertura (ver cdigo fonte B.2, linhas 49 at 80), tornando este estgio da vericao suciente para a aplicao da anlise de mutao de acordo com os pr-requisitos
29
estabelecidos no Captulo 3. Na Figura 4.1, v-se a estrutura do testbench do DPCM com a indicao de onde foram aplicadas as mutaes.
Figura 4.1: Aplicao das mutaes sobre o modelo de referncia do DPCM.
4.1.3 Preparao do Ambiente para Aplicao das Mutaes

Como os modelos de referncia utilizados so instncias do mesmo cdigo, para a aplicao das mutaes utilizando a ferramenta Proteum torna-se necessrio fazer algumas modicaes no cdigo fonte original do testbench. O cdigo fonte completo do testbench original encontra-se no Apndice B. O cdigo fonte, com as devidas alteraes encontra-se no Apndice C, dentre as quais destacam-se: A criao de um arquivo dpcm_api_mut.c que o arquivo que receber as mutaes; O Checker recebe apenas a instruo sc_stop() na linha 28 para interromper a simulao assim que um erro for encontrado;
30
O novo arquivo de ligaes representado no Cdigo Fonte C.4 agora precisa incluir o modelo de referncia que foi alterado (linha 6), instanci-lo (linha 20) e realizar as devidas ligaes no Source e no Checker do testbench (linhas 41 e 48).
4.1.4 Mutaes
Neste caso de estudo, existem duas unidades de trabalho, as subrotinas int subtract(int a, int b) e int saturation(int a) do modelo de referncia, apresentadas no cdigo fonte C.2, no Apndice C. A seguir, os mutantes gerados para cada subrotina sero analisados separadamente. Unidade 1 - subrotina int subtract( int a, int b ) Na Tabela 4.1, so apresentados os resultados da anlise de mutao utilizando todos os operadores possveis para esta unidade. Com a cobertura estabelecida, apenas o mutante nmero 27 cou vivo. Os trechos de cdigo 4.1 e 4.2 representam, respectivamente, a subrotina original e a subrotina com o mutante que cou vivo. Verica-se, portanto, que este mutante equivalente ao programa original. Porque isso acontece? O operador SRSR (Return Replacement) verica quantas instrues de return existem na unidade e gera mutantes trocando cada linha de cdigo por uma operao de return existente no cdigo [1]. Como nesta subrotina existe apenas uma linha de cdigo, o nico mutante gerado o prprio programa original. Descobrir que este programa equivalente ao original no demorou mais do que alguns poucos minutos, portanto teve impacto pequeno no tempo total da anlise de mutao. Cdigo Fonte 4.1: Cdigo fonte original da subrotina de subtrao do modelo de referncia do DPCM
1 2 3 } int subtract_mut ( int a , int b ) { return (a b) ;
Cdigo Fonte 4.2: Cdigo fonte da subrotina de subtrao do modelo de referncia do DPCM com mutao gerada pela ferramenta Proteum, operador SRSR
1 int subtract_mut ( int a , int b ) { return ( a b) ;}
4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator Tabela 4.1: Resultados da anlise de mutao sobre a unidade 1.
Operadores CRCR OAAN OABN OALN OARN OASN SRDL SRSR STRP VDTR VGSR VTWD TOTAL Total de Mutantes 10 4 3 2 6 2 2 1 2 6 2 4 44 Mutantes Vivos 0 0 0 0 0 0 0 1 0 0 0 0 1 Mutantes equivalentes 0 0 0 0 0 0 0 1 0 0 0 0 1
31
Desta forma, o escore de mutao EM apresentado para esta unidade 1 (um), o melhor escore possvel para uma anlise de mutao.
Unidade 2 - subrotina int saturation( int a ) Em uma primeira anlise de mutao sobre esta unidade, vericou-se que todos os mutantes estavam vivos. Este fato pareceu inesperado e no tinha motivo aparente. Porm, vericouse que a anlise de mutao encontrou um problema que foge do escopo da metodologia VeriSC: a presena de faltas no modelo de referncia. A seguir, uma descrio do problema encontrado. No cdigo fonte 4.3, tem-se o trecho de cdigo antigo que contm a falta. Nas linhas 12 a 14, possvel observar que o valor inserido na transao o valor da varivel dif f , quando o valor correto a ser enviado deveria ser o valor da varivel sat, que contm o resultado da saturao. Cdigo Fonte 4.3: Trecho do cdigo fonte do modelo de referncia do mdulo DPCM que continha uma falta
1 / / ####### R e f e r e n c e Model Main F u n c t i o n s #######

2 3 4 5 6 7 8 9 10 11 12 13 14 audio_saida_stim . write ( audio_saida_ptr ) ; a u d i o _ s a i d a _ p t r >a m o s t r a = d i f f ; a u d i o _ s a i d a _ p t r = new s a t _ a u d i o ( ) ; b u f f = a u d i o _ e n t r a d a _ p t r >a m o s t r a ; / / ####### R e f e r e n c e Model Main F u n c t i o n s ####### i n t d i f f = s u b t r a c t ( a u d i o _ e n t r a d a _ p t r >a m o s t r a , b u f f ) ; int sat = saturation ( diff ) ;
32
O cdigo fonte 4.4 contm o trecho de cdigo onde a falta foi corrigida. Cdigo Fonte 4.4: Trecho do cdigo fonte do modelo de referncia do mdulo DPCM onde a falta foi corrigida
1 2 3 4 5 6 7 8 9 10 11 12 13 14 audio_saida_stim . write ( audio_saida_ptr ) ; a u d i o _ s a i d a _ p t r >a m o s t r a = s a t ; a u d i o _ s a i d a _ p t r = new s a t _ a u d i o ( ) ; b u f f = a u d i o _ e n t r a d a _ p t r >a m o s t r a ; / / ####### R e f e r e n c e Model Main F u n c t i o n s ####### i n t d i f f = s u b t r a c t ( a u d i o _ e n t r a d a _ p t r >a m o s t r a , b u f f ) ; int sat = saturation ( diff ) ; / / ####### R e f e r e n c e Model Main F u n c t i o n s #######
Neste caso, o que ocorreu foi que o engenheiro de vericao no testou uma situao: a de vericar se a sada em algum tempo foi maior do que o limite superior ou menor do que o limite inferior. Caso esta situao tivesse sido contemplada como um parmetro de cobertura a ser atingido, este erro teria sido descoberto antes da anlise de mutao. O trecho de cdigo
33
4.5 uma representao da cobertura que descobriria a falta identicada com a anlise de mutao. Cdigo Fonte 4.5: Trecho de cdigo que representa a adio dos parmetros de cobertura que identicariam a falta encontrada com a anlise de mutao.
1 2 3 4 Cv_bucket_illegal_refmod_audio . begin ( ) ; BVE_COVER_ILLEGAL ( C v _ b u c k e t _ i l l e g a l _ r e f m o d _ a u d i o , d i f f < 4) ; BVE_COVER_ILLEGAL ( C v _ b u c k e t _ i l l e g a l _ r e f m o d _ a u d i o , d i f f > C v _ b u c k e t _ i l l e g a l _ r e f m o d _ a u d i o . end ( ) ; 3) ;
Na Tabela 4.2, apresentado um resumo dos resultados da anlise de mutao sobre esta unidade aps a descoberta da falta. Esta nova situao contm apenas quatro mutantes vivos (2,64% do total de mutantes), todos eles equivalentes ao programa original. Esta anlise dos mutantes e a descoberta da equivalncia entre eles e o programa original tambm levou alguns poucos minutos e teve pequeno impacto no tempo total da anlise de mutao. O escore de mutao para este caso 1 (um). Tabela 4.2: Resultados da anlise de mutao sobre a unidade 2.
Operadores CCCR CCSR CRCR OCNG ORAN ORBN ORLN ORRN ORSN SRDL SRSR STRI STRP VDTR VTWD TOTAL Total de Mutantes 4 6 15 2 10 6 4 10 4 6 15 4 6 9 6 107 Mutantes Vivos 1 0 0 0 0 0 0 2 0 0 0 0 0 0 1 4 Mutantes equivalentes 1 0 0 0 0 0 0 2 0 0 0 0 0 0 1 4
4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform
34
4.2
Caso de estudo: IDCT - Inverse Discrete Cosine Transform
Codicao por transformada um dos principais mdulos da maioria dos padres de compactao de vdeo. Este caso de estudo concentra-se na transformao conhecida como DCT (Discrete Cosine Transform), mais especicamente em sua inversa (IDCT) utilizada na decodicao de vdeo. A transformada direta utilizada na codicao. No padro MPEG4, so utilizados blocos 8 x 8 na amostragem da imagem para realizar a codicao em coecientes DCT. Na decodicao, este conjunto de coecientes reconstrudos utilizado para reconstruir a imagem [28]. A equao de reconstruo de amostras de imagem a partir de coecientes DCT dada pela equao 4.1 [28]: (2j + 1) x (2i + 1) x C (x)C (y ) cos Fx,y cos 4 16 16 x=0 y =0
7 7
fi,j =
(4.1)
A DCT a transformada mais utilizada nos padres de codicao de imagem, dentre os quais: JPEG, H.261, H.263, H.263+, H.264, MPEG-l, MPEG-2 e MPEG-4 [28]. A implementao de um artefato de hardware, que faz a funo da IDCT, foi realizada durante o desenvolvimento do IP core MPEG4 citado no Captulo 2 deste trabalho. Esse caso de estudo utilizar o ambiente de vericao, bem como o modelo de referncia e o DUV deste mdulo do decodicador de vdeo MPEG4 para a anlise de mutao. A idia descobrir se a cobertura projetada para este bloco satisfatria, de acordo com o critrio estabelecido no Captulo 2, Seo 2.2 deste trabalho.
4.2.1 Modelo de Referncia

O modelo de referncia faz uso do decodicador de vdeo xvid verso 0.9 patch-20 [36]. O modelo uma implementao na linguagem C do padro de decodicao de vdeo MPEG4 que tem os computadores pessoais como plataforma alvo. No foi realizada nenhuma modicao no modelo de referncia para a aplicao das mutaes com a ferramenta Proteum. O cdigo da subrotina que implementa a funcionalidade da IDCT pode ser visualizada no Anexo D.
35
4.2.2 Ambiente de Vericao

O ambiente de vercao est completo, contendo todos os elementos implementados (Source, TDrivers, TMonitors e Checker). Na Figura 4.2, apresentado o testbench do mdulo IDCT com uma indicao de onde foram inseridas as mutaes.
Figura 4.2: Aplicao das mutaes sobre o modelo de referncia do mdulo IDCT.
4.2.3 Mutaes
Na simulao das primeiras mutaes, foi identicado que a anlise de mutao iria consumir um tempo demasiado. Isto porque a simulao do testbench do mdulo IDCT consome cerca de 32,48 min no computador descrito no Anexo A. Foram gerados ao todo 13.683 mutantes. Obviamente, existia a possibilidade de muitos deles serem mortos e no necessitarem dos 32,48 min de simulao para a morte. Por outro lado, tomando como referncia o caso de estudo anterior no qual 2,64% dos mutantes caram vivos, poder-se-ia esperar cerca de 361
36
mutantes vivos (2,64% de 13.683). Assim, 361 multiplicado por 32,48 min tem como resultado 11725,28 min, ou 195,42 horas, ou ainda 8,14 dias. Aliado a este fato, h mutantes que travam a simulao, forando o engenheiro de vericao a car de olho nas simulaes para prevenir que um mutante desta natureza atrase ainda mais o trabalho. Diante do exposto, foi necessrio buscar uma forma de reduzir o custo computacional dessas simulaes. Vericou-se, que dois dos parmetros de cobertura demoravam cerca de 30,98 min para serem atingidos, enquanto o restante dos parmetros era atingido em 1,5 min. Estes parmetros excessivamente onerosos podem ser visualizados nas linhas 24 e 49 do cdigo fonte ??. Assim, em uma primeira rodada de simulao dos mutantes, esta cobertura no foi utilizada, o que reduziu para 10,25 horas o tempo estimado das simulaes. Foram observados quatro motivos para a sobrevivncia dos mutantes ao realizar a anlise de mutao: 1. Cdigo no exercitado: O mutante est vivo porque a mutao inserida est em um trecho de cdigo que nunca exercitado pelo ambiente de vericao. Pode-se dizer, ento, que a cobertura de cdigo estabelecida poderia ser melhorada para contemplar o exerccio dos trechos de cdigo que nunca so exercitados. 2. Equivalncia: O mutante equivalente ao programa original e no h vericao funcional que consiga distingui-los. 3. Indenido: O testbench no exercita o modelo de referncia mutado de forma que ele produza uma sada diferente da sada do modelo de referncia original. Tambm no foi encontrada uma maneira de mostrar se este conjunto de mutantes equivalente ao programa original. 4. Arquitetura: A arquitetura do computador onde est sendo realizada a simulao interfere na morte/vida do mutante. Este fato foi conrmado por uma srie de mutantes que realizam operaes de deslocamento para a direita de um nmero de bits maior do que 31. A seguir, um exemplo que descreve melhor o problema encontrado. O cdigo fonte 4.6 apresenta a verso original do trecho no qual ser aplicada a mutao. O cdigo fonte 4.7 apresenta o trecho de cdigo onde foi realizada uma mutao
37
de acordo com a regra estabelecida pelo operador Cccr (Constant for constant replacement). Cdigo Fonte 4.6: Trecho do cdigo fonte do modelo de referncia do IDCT sem aplicao de mutao
1 2 3 . . .
4 X2 = ( 1 8 1 ( X4 + X5 ) + 1 2 8 ) >> 8 ; 5 6 7 . . .
Cdigo Fonte 4.7: Trecho do cdigo fonte do modelo de referncia do IDCT com mutante na linha 4
1 2 3 . . .
4 X2 = ( 1 8 1 ( X4 + X5 ) + 1 2 8 ) >> 2 4 0 8 ; 5 6 7 . . .
O testbench no capaz de diferenciar os cdigos 4.6 e 4.7. Assim, foi levada a efeito a depurao deste mutante para identicar os motivos que fazem com que ele que vivo. Depois de analisar as mensagens exibidas durante a compilao, descobriu-se que o compilador emitiu a seguinte mensagem de aviso: teste_2408.c: In function main: teste_2408.c:4: warning: right shift count >= width of type Ou seja, o compilador percebeu que o nmero de bits a serem deslocados para a direita maior do que o tamanho do tipo de dado que est sendo deslocado. Buscando entender melhor o que acontece nesses casos, foram criados dois programas simples que realizam operaes de deslocamento semelhantes s encontradas nos cdigos fonte 4.6 e 4.7. So eles, os programas descritos nos cdigos fonte 4.8 e 4.9.
4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform Cdigo Fonte 4.8: Cdigo fonte do exemplo de deslocamento de 8 bits para a direita.
1 2 3 4 5 6 } i n t main ( i n t a r g c , c h a r a r g v [ ] ) { int a; a = a >> 8 ; return 0;
38
Cdigo Fonte 4.9: Cdigo fonte do exemplo de deslocamento de 2408 bits para a direita.
1 2 3 4 5 6 } i n t main ( i n t a r g c , c h a r a r g v [ ] ) { int a; a = a >> 2 4 0 8 ; return 0;
Vericou-se que a compilao do cdigo fonte 4.9 apresentou a mesma mensagem de aviso anteriormente citada, que mostra que o nmero de bits a serem deslocados para a direita maior do que o tamanho do tipo de dado que est sendo deslocado. Analisouse, ento, o cdigo na linguagem Assembly gerada pelo compilador gcc verso 3.3.2 [13]. Os cdigos fonte em assembly esto representados nos cdigos fonte 4.10 e 4.11, respectivamente. Cdigo Fonte 4.10: Cdigo fonte na linguagem Assembly do exemplo de deslocamento de 8 bits para a direita.
1 2 3 4 5 6 7 8 9 10 11 main : pushl movl subl andl movl subl %ebp %esp , %ebp $8 , %e s p $ 16 , %e s p $0 , %e a x %eax , %e s p . file . text . g l o b l main . type main , @ f u n c t i o n " teste_8 . c"

12 13 14 15 16 17 18 leal sarl movl leave ret . size . ident main , . main "GCC: (GNU) 3 . 3 . 2 " 4(%ebp ) , %e a x $8 , (% e a x ) $0 , %e a x
39
Cdigo Fonte 4.11: Cdigo fonte na linguagem Assembly do exemplo de deslocamento de 2408 bits para a direita.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 main : pushl movl subl andl movl subl leal movb sarl movl leave ret . size . ident main , . main "GCC: (GNU) 3 . 3 . 2 " %ebp %esp , %ebp $8 , %e s p $ 16 , %e s p $0 , %e a x %eax , %e s p 4(%ebp ) , %e a x $104 , %c l %c l , (% e a x ) $0 , %e a x . file . text . g l o b l main . type main , @ f u n c t i o n " teste_2408 . c"
Observando a linha 13, v-se que a operao de deslocamento de 8 bits para a direta na linguagem C traduzida para a instruo sarl, que tem 2 operandos: uma constante e um registrador. A constante o nmero 8 que o nmero de bits a ser deslocado. O problema comea a aparecer quando so observadas as linhas 13 e 14 do cdigo fonte 4.11. Na linha 14, a instruo sarl tem dois operandos, ambos registradores, sendo o primeiro, o registrador %cl, o que determina a quantidade de bits a serem deslocados.
40
Na linha 13, este registrador carregado com o valor 104. Este valor deveria ser 2408, mas o compilador s considera para esta operao os 9 bits menos signicativos do operando, e por isso que ele emite o aviso anteriormente mencionado no momento da compilao. Mesmo com esta descoberta, no se pode justicar a sobrevivncia do mutante, pois 8 diferente de 104 e esse deslocamento deveria ter resultado diferente. Foi ento que partiu-se para uma anlise da instruo sarl da arquitetura do Pentium R [14] e vericou-se que em uma operao de deslocamento para a direita de um nmero de bits maior do que 31, apenas os 5 bits menos signicativos so utilizados para realizar de fato o deslocamento. Portanto, neste caso os 5 bits menos signicativos do nmero introduzido pelo mutante tem o mesmo valor do programa original. Estes mutantes so considerados equivalentes ao programa original apenas para esta arquitetura. No foi encontrado nenhum registro do impacto da arquitetura de um processador na anlise de mutao. Portanto, importante que o engenheiro de vericao que conduz a anlise de mutao conhea no somente a linguagem de desenvolvimento do modelo de referncia, mas tambm a arquitetura do processador onde a simulao ocorre. A anlise deste nico mutante durou 12 horas distribudas em 3 dias. Vericou-se, tambm, que outros 12 mutantes so equivalentes ao programa original pelo mesmo motivo. Os resultados referentes aos mutantes vivos na primeira rodada esto dispostos na Tabela 4.3. Tabela 4.3: Resultados da anlise de mutao sobre a IDCT na primeira rodada de anlise de mutao.
Classicao de Mutantes Vivos Cdigo no exercitado Arquitetura Equivalncia Indenido Total Quantidade 1165 13 56 420 1654 Tempo de trabalho manual < 9,7 horas (0,5 min por mutante) 12 horas 0,93 hora (1 min por mutante) 5,33 horas (1 min por mutante) 29,63
Dos 69 mutantes equivalentes ao programa original, 13 so devido a arquitetura do
41
Pentium R , como citado anteriormente. Os outros 56 mutantes foram identicados em poucos minutos e tiveram impacto mnimo no tempo da anlise de mutao. Foi necessrio, tambm, avaliar os 420 que no foram inicialmente identicados como equivalentes ao programa original. Um destes mutantes o representado no trecho de cdigo no Cdigo Fonte 4.12. O trecho do programa original associado a este mutante est representado no Cdigo Fonte 4.13. Cdigo Fonte 4.12: Trecho do Cdigo Fonte de um mutante vivo no-equivalente ao programa original.
1 2 3 4 5 6 7 8 9 10 11 12 13 . . . X4 = ( X8 + ( 2 8 4 1 5 6 5 ) X4 ) >> 3 ; X5 = ( X8 ( 2 8 4 1 + 5 6 5 ) X5 ) >> 3 ; ( X8 = ( ( 5 6 5 ( X4 + X5 ) ) + 3 ) ) ; . . . X0 = ( b l k [ 8 0 ] << 8 ) + 8 1 9 2 ;
Cdigo Fonte 4.13: Trecho do Cdigo Fonte do programa original onde foi aplicada mutao.
1 2 3 4 5 6 7 8 9 10 11 . X4 = ( X8 + ( 2 8 4 1 5 6 5 ) X4 ) >> 3 ; X5 = ( X8 ( 2 8 4 1 + 5 6 5 ) X5 ) >> 3 ; X8 = ( ( 5 6 5 ( X4 + X5 ) ) + 4 ) ; . . . X0 = ( b l k [ 8 0 ] << 8 ) + 8 1 9 2 ;

12 13 . .
42
Inicialmente, os cdigos parecem iguais, mas justamente esse o problema. A diferena entre eles (localizada na linha 7) to sutil que, com os parmetros de cobertura escolhidos, a diferena se perde em operaes de deslocamento localizadas mais ao nal da subrotina. Estas operaes de deslocamento podem ser visualizadas nas linhas 136 a 146 no Cdigo Fonte D.1, do Anexo D. Os outros 419 mutantes vivos no-equivalentes ao programa original apresentam o mesmo comportamento. De posse dessas informaes, pode-se, ento, calcular o escore de mutao (EM ) da seguinte forma: EM =
12029 13614
= 0, 883. Vale lembrar, que os mutantes equivalentes ao
programa original no so considerados para o clculo do escore de mutao. Aps essa anlise preliminar, foi ento adicionado o parmetro de cobertura que tinha sido retirado anteriormente e aplicado sobre os mutantes que caram vivos. O resultado apresentado na Tabela 4.4. Tabela 4.4: Resultados da anlise de mutao sobre a IDCT na segunda rodada de anlise de mutao.
Classicao de Mutantes Vivos Cdigo no exercitado Arquitetura Equivalncia Indenido Total Quantidade 1165 13 56 320 1554 Tempo de trabalho manual (horas) 9,7 (0,5 min por mutante) 12 0,93 (1 min por mutante) 5,33 (1 min por mutante) 27,96
Foram simulados novamente os 1485 mutantes vivos no-equivalentes ao programa original, cada um com durao de 32,48 min. Assim, a simulao de todos os mutantes demorou 48232,8 min, ou 803,88 horas, ou 13,39 dias. Como as simulaes so independentes, poderse-ia utilizar vrias mquinas para rodar vrias simulaes em paralelo, inclusive com o uso de grids computacionais. O novo escore de mutao , ento, recalculado considerando a diminuio dos mutantes que foram mortos com a cobertura nova: EM =
12129 13614
= 0, 890. Observa-se, ento, que
quando o parmetro de cobertura foi adicionado, mais mutantes foram mortos aumentando o escore de mutao. H espao para melhorar ainda mais a cobertura, j que restaram ainda
4.3 Discusso
43
1485 mutantes vivos no equivalentes ao programa original. Esta tarefa de criar parmetros de cobertura e estmulos que matem mais mutantes chamada de teste de mutao e no est no escopo deste trabalho. importante observar, que a anlise de mutao pode apresentar mutantes que so difceis de matar, ou de se determinar sua equivalncia em relao ao programa original. O grco da Figura 4.3 representa o tempo de trabalho manual necessrio para classicar um conjunto de mutantes, possibilitando uma outra viso da Tabela 4.4.
Figura 4.3: Grco da relao entre quantidade de mutantes e tempo de trabalho manual para classicao. possvel observar na gura 4.3 e na tabela 4.4, que apenas 13 dos 1554 mutante levaram 12 horas para serem classicados, o que representa 42% do tempo de trabalho manual para classicao dos mutantes vivos. Portanto, ao planejar a anlise mutao dentro do contexto de um projeto de IP core, este tipo de dado deve ser levado em considerao. Podem surgir mutantes difceis de serem analisados, que consomem muito tempo e tm potencial de atrasar o andamento da vericao funcional. Portanto, ao planejar o cronograma, o gerente de projeto deve prever que esta situao possvel de acontecer e tomar a deciso de utilizar, ou no, a anlise de mutao, respeitando os prazos estabelecidos para o trmino do projeto.
4.3
Discusso
Dois casos de estudo foram adotados para a validao do trabalho. No primeiro caso (mais simples), o ambiente de vericao foi construdo a partir do incio. Apesar da baixa complexidade do mdulo vericado, foi possvel encontrar problemas com a ajuda da anlise de
4.3 Discusso
44
mutao. No nal, o escore de mutao foi igual a 1 (um), o que quer dizer que a cobertura estabelecida teve grau mximo de qualidade, de acordo com a mtrica estabelecida. O segundo (e mais complexo) caso de estudo, foi a IDCT. Em uma primeira rodada de simulao, vericou-se que o tempo de simulao de cada mutante era demasiado alto. Portanto, foram feitas alteraes na cobertura j estabelecida para diminuir este tempo. Com esta cobertura limitada, foram mortos 12029 (doze mil e vinte e nove) do total de mutantes no equivalentes ao programa original. Ao reintroduzir os parmetros que foram retirados, foram mortos mais 100 (cem) mutantes, mostrando que uma cobertura mais adequada, mata mais mutantes. A partir dos dados avaliados durante a anlise de mutao, observou-se que o tempo de trabalho manual necessrio para a realizao da tarefa de classicao um fator de risco no planejamento do cronograma do projeto.
Captulo 5 Consideraes Finais e Sugestes para Trabalhos Futuros

5.1 Consideraes Finais
Este trabalho visa fornecer um parmetro objetivo ao engenheiro de vericao que auxilie na anlise da qualidade da sua vericao funcional. A idia principal consiste em utilizar a anlise de mutao na metodologia de vericao funcional VeriSC. A anlise de mutao realizada sobre os casos de estudo apresentados no Captulo 4 mostram que o escore de mutao uma boa medida da qualidade dos parmetros de cobertura estabelecidos para a vericao funcional. No exemplo da DPCM, possvel ver que mesmo para um projeto pouco complexo, a anlise de mutao foi capaz de revelar problemas que poderiam afetar o funcionamento do sistema em um ambiente real. J no exemplo da IDCT, um mdulo de um sistema em que se considera que foi feita uma boa vericao funcional, j que este projeto reconhecido inclusive internacionalmente, 11% dos mutantes (1485 mutantes) so vivos e no equivalentes ao programa original. Cada um deles est vivo porque alguma funcionalidade no foi exercitada o suciente para mat-lo. Cada funcionalidade mal exercitada pode conter um erro de programao que afeta a qualidade nal do produto, no caso o mdulo IDCT. Apesar dos benefcios provenientes do uso da anlise de mutao na vericao funcional, o tempo de simulao dos mutantes e o trabalho manual envolvido so fatores de grande impacto para o projeto, e devem ser considerados ao ser aplicada a anlise de mu45
5.2 Sugestes para Trabalhos Futuros
46
tao. A partir do uso da anlise de mutao, foi possvel constatar a importncia do conhecimento da arquitetura do processador em uso, por parte do engenheiro de vericao, para que a tcnica seja aplicada com sucesso. No contexto desse trabalho, a anlise de mutao poderia ter sido realizada em outros tipos de arquitetura, o que permitiria avaliar de forma ainda mais efetiva o impacto de diferentes arquiteturas de hardware.
5.2
Sugestes para Trabalhos Futuros
Os resultados obtidos no trabalho indicam a eccia do uso de operadores de mutao como tcnica auxiliar para melhoria da vericao funcional. Entretanto, foram identicadas algumas limitaes dos resultados que vislumbram possibilidades para trabalhos futuros, destacando-se: Desenvolvimento e/ou adaptao de tcnicas de teste de mutao para utilizao na metodologia VeriSC buscando melhorar o escore de mutao dos ambientes de vericao. Aplicao de tcnicas como a mutao seletiva ou a mutao fraca para a diminuio do tempo da anlise de mutao. Aplicao de anlise de mutao em computadores com arquitetura diferente da utilizada neste trabalho, com o objetivo de avaliar o impacto deste parmetro sobre a anlise.
Bibliograa
[1] Hiralal Agrawal, Richard A. DeMillo, Bob Hathaway, William Hsu, Wynne Hsu, E.W. Krauser, R. J. Martin, Aditya P. Mathur, and Eugene Spafford. Design of mutant operators for the c programming language. Technical report, Department of Computer Science - Purdue University, 2006. [2] C. Michael Pilato Ben Collins-Sussman, Brian W. Fitzpatrick. Version Control with Subversion For Subversion 1.4. TBA, 2007. [3] J. Bergeron. Functional verication of hdl models. Kluwer Academic Publisher, 2003. [4] V. Bhaskaran and K. Konstantinides. Image and Video Compression Standards Algorithmos and Architectures. Kluwer Academic Pub., 1995. [5] 2008. http://www.brazilip.org.br/ - Acessado em Novembro de 2008. [6] 2008. http://www.cadence.com - Acessado em Novembro de 2008. [7] 2008. http://www.centos.org - Acessado em Novembro de 2008. [8] http://www.bergbrandt.com.br/cetene/asp/sobre_ocetene.asp - Acessado em Novembro de 2008. [9] 2007. http://savannah.nongnu.org/projects/cvs/ - Acessado em Novembro de 2008. [10] K. R. G. da Silva, E. U. K. Melcher, I. Maia, and H. do N. Cunha. A methodology aimed at better integration of functional verication and rtl design. Design Automation for Embedded Systems, 2006.
47
BIBLIOGRAFIA
48
[11] Mrcio Eduardo Delamaro and Jos Carlos Maldonado. Proteum - a tool for the assessment of test adequacy for c programs - users guide. Technical report, University of So Paulo (USP), 1996. [12] R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 1978. [13] 2008. http://gcc.gnu.org/ - Acessado em Novembro de 2008. [14] Intel. Pentium Processor Family Developers Manual - Volume 3: Architecture and Programming Manual, 1995. [15] 2007. http://www.us.design-reuse.com/ipsoc2006/ - Acessado em Novembro de 2008. [16] Luciano Lavagno, Grant Martin, and Louis Scheffer. Electronic Design Automation for Integrated Circuits Handbook - 2 Volume Set. CRC Press, Inc., Boca Raton, FL, USA, 2006. [17] A.P. Mathur. Reducing the cost of mutation testing: An empirical study. Journal of Systems and Software archive, 1993. [18] 2008. http://www.mentor.com - Acessado em Novembro de 2008. [19] A. J. Offutt. Investigations of the software testing coupling effect. ACM Transactions on Software Engineering Methodology, 1992. [20] A. J. Offutt, A. Lee, G. Rothermel, R. H. Untch, and C. Zapf. An experimental determination of sufcient mutant operators. ACM Trans. Softw. Eng. Methodol., 1996. [21] A. J. Offutt and S. D. Lee. How strong is weak mutation? In In Proceedings of the symposium on Testing, analysis, and verication, 1991. [22] A. J. Offutt and S. D. Lee. An empirical evaluation of weak mutation. IEEE Trans. Softw. Eng., 1994. [23] A. J. Offutt and R. H. Untch. Mutation 2000: Uniting the orthogonal. In Mutation Testing in the Twentieth and the Twenty First Centuries, 2000.
BIBLIOGRAFIA
49
[24] Isaac Maia Pessoa. Dissertao de mestrado: Gerao semi-automtica de testbenches para circuitos integrados digitais, 2007. [25] A. Piziali. Functional verication Coverage Measurement and Analysis. Kluwer Academic Publisher, 2004. [26] Ken C. Pohlmann. Principles of Digital Audio, 2nd ed. Sams/Prentice-Hall Computer Publishing, Carmel, Indiana., 1985. [27] 2008. http://www.redhat.com - Acessado em Novembro de 2008. [28] Iain E. G. Richardson. Video Codec Design - Devloping Image and Video Compression Systems. JOHN WILEY & SONS, LTD, 2002. [29] A. K. Rocha, P. Lira, Y. Y. Ju, E. Barros, and E. Melcher. Silicon validated ip cores designed by the brazil-ip network. In Proceedings of IP/SOC 2006, 2006. [30] Youssef Serrestou and Vincent Beroulle Chantal Robach. Functional verication of rtl designs driven by mutation testing metrics. In 10th IEEE Euromicro Conference on Digital System Design Architectures, Methods and Tools (DSD 2007), 2007. [31] 2008. http://www.synopsys.com - Acessado em Novembro de 2008. [32] 2008. http://www.systemc.org - Acessado em Novembro de 2008. [33] P. Vado, Yvon Savaria, Yannick Zoccarato, and Chantal Robach. A methodology for validating digital circuits with mutation testing. In IEEE International Symposium on Circuits and Systems, 2000. [34] K. S. H. T. Wah. Fault coupling in nite bijective functions. The Journal of Software Testing, Verication and Reliability, vol 5, pp 3-47, 1995. [35] K. S. H. T. Wah. A theoretical study of fault coupling. The Journal of Software Testing, Verication and Reliability, vol 5, pp 3-47, 2000. [36] 2008. http://www.xvid.org - Acessado em Novembro de 2008.
Apndice A Ambiente e Ferramentas

Para o desenvolvimento dos experimentos relacionados a este trabalho, foram necessrias vrias ferramentas computacionais, descritas a seguir.
A.1 Ambiente de Desenvolvimento

O computador onde foram realizadas as simulaes tem as seguintes caractersticas: Processador: AMD-Opteron 1.6 GHz Memria: 1.5GB DDR Dsico: Serial ATA 140GB
A.2 Sistema Operacional

O Sistema Operacional (S.O.) utilizado para os experimentos foi o CentOS 4 [7]. Este S.O. fornece uma plataforma da classe enterprise compatvel com o RHEL 4 (Red Hat Enterprise Linux 4) [27]. O RHEL 4 o S.O. adotado pelas maiores empresas que desenvolvem ferramentas para a indstria de microeletrnica. So elas, a CADENCE e a Mentor Graphics
R R
[6], a Synopsys
[31]
[18]. Desta forma, o procedimento de mutao apresentado neste
trabalho dever funcionar nesta plataforma para que os problemas de portabilidade sejam mnimos.
50
A.3 Linguagem de Programao
51
A.3 Linguagem de Programao

SystemC uma biblioteca da linguagem C++ destinada elaborao de ambientes de vericao e projeto de circuitos digitais. Esta linguagem particularmente direcionada implementao de blocos de hardware de alto desempenho com vrios nveis de abstrao. Pode-se dizer, portanto, que SystemC uma linguagem unicada para projeto e vericao na forma de uma biblioteca open-source de classes C++ [32].
A.4 Ferramenta de Mutao

A Proteum[11] uma ferramenta de suporte teste de mutao. Essa ferramenta foi utilizada para a gerao dos mutantes aplicados ao ambiente de vericao funcional. A Proteum foi escolhida por ter sido a nica ferramenta encontrada que contm todos os operadores de mutao disponveis para a linguagem C. Na ferramenta, um teste guiado por sees de teste. Em cada seo, o testador pode criar um teste, interromp-lo e retom-lo mais tarde. As funcionalidades so separadas em diversas sub-ferramentas, que podem ser usadas separadamente para proporcionar mxima exibilidade. A sub-ferramenta utilizada chamada "exemuta", que gera os mutantes de acordo com os parmetros fornecidos.
A.5 Ferramenta para gerao semi-automtica de Testbenches

A gerao do testbench do mdulo DPCM foi realizada utilizando a ferramenta eTBc, desenvolvida por Isaac Maia Pessoa [24], que gera automaticamente uma grande parte do ambiente de vericao funcional baseado na especicao do usurio e nos templates da metodologia VeriSC.
A.6 Controle de verses

Para o desenvolvimento do trabalho e desta dissertao, foi utilizada uma ferramenta de controle de verses conhecida como Subversion [2]. Essa ferramenta tem o objetivo de substituir
A.6 Controle de verses
52
outro sistema de controle de verses, chamado CVS (Concurrent Versioning System) [9], que os desenvolvedores do SVN consideram ter muitas limitaes. Dentre as funcionalidades mais importantes do SVN esto: Contm Todas as funcionalidades disponveis para o CVS; A operao de commit realmente atmica. Nenhuma parte da operao executada sem que toda ela tenha sido. Os nmeros de reviso so por operao de commit e no por arquivo. Alm disso, a mensagem associada ao commit anexada reviso e no a cada arquivo relacionado com aquela reviso; Copiar, renomear e apagar so operaes versionadas; As permisses de execuo de cada arquivo so preservadas; Arquivos binrios so tratados ecientemente, tanto quanto os arquivos de texto. Isso porque o SVN tem um algoritmo que resolve a diferena entre arquivos binrios para transmitir e armazenar revises; A resoluo de conitos realizada de forma interativa.
Apndice B Cdigo Fonte do Testbench Original do mdulo DPCM

A seguir, o Cdigo Fonte do testbench do DPCM divido em mdulos de acordo com a diviso do testbench. Cdigo Fonte B.1: Cdigo fonte do modelo gerador automtico de estmulos do mdulo DPCM
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 / / a m o s t r a _ d i s t r i b . push ( p a i r ( ? , ? ) , ? ) ; / / a u d i o _ s p t r >a m o s t r a . s e t _ m o d e ( a m o s t r a _ d i s t r i b ) ; public : scv_smart_ptr <audio > a u d i o _ s p t r ; SCV_CONSTRAINT_CTOR ( a u d i o _ e n t r a d a _ c o n s t r a i n t _ c l a s s ) { a m o s t r a _ d i s t r i b . p u s h ( p a i r ( 10 , 1 0 ) , 1 ) ; a u d i o _ s p t r >a m o s t r a . s e t _ m o d e ( a m o s t r a _ d i s t r i b ) ; scv_bag > a m o s t r a _ d i s t r i b ; class audio_entrada_constraint_class : public scv_constraint_base {
53
54
18 19 20 21 22 23 24 SC_MODULE( s o u r c e ) { 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 / / Random s t i m u l i g e n e r a n t i o n while (1) { audio_entrada_constraint . next ( ) ; audio_entrada_stim = audio_entrada_constraint . audio_sptr . read ( ) ; audio ( audio_entrada_stim ) ) ; audio ( audio_entrada_stim ) ) ; } ifs_audio_entrada . ignore (225 , \n ) ; } void audio_entrada_p ( ) { s t r i n g type ; ifstream ifs_audio_entrada (" audio_entrada . stim ") ; audio audio_entrada_stim ; / / Static stimuli generation w h i l e ( ! i f s _ a u d i o _ e n t r a d a . f a i l ( ) && ! i f s _ a u d i o _ e n t r a d a . e o f ( ) ) { i f s _ a u d i o _ e n t r a d a >> t y p e ; i f ( t y p e == " a u d i o " ) { i f s _ a u d i o _ e n t r a d a >> a u d i o _ e n t r a d a _ s t i m ; a u d i o _ e n t r a d a _ t o _ r e f m o d . w r i t e ( new a u d i o ( a u d i o _ e n t r a d a _ s t i m ) ) ; sc_fifo_out <audio_ptr > audio_entrada_to_refmod ; sc_fifo_out <audio_ptr > audio_entrada_to_driver ; audio_entrada_constraint_class audio_entrada_constraint ; }; // } SCV_CONSTRAINT ( a u d i o _ s p t r >?() > ? ) ;
a u d i o _ e n t r a d a _ t o _ r e f m o d . w r i t e ( new a u d i o _ e n t r a d a _ t o _ d r i v e r . w r i t e ( new
55
55 56 57 58 59 60 61 62 63 64 65 66 67 68 }; } { SC_THREAD( a u d i o _ e n t r a d a _ p ) ; audio_entrada_constraint (" audio_entrada_constraint ") SC_CTOR ( s o u r c e ) : } }
Cdigo Fonte B.2: Cdigo fonte do modelo de referncia do mdulo DPCM

1 2 3 SC_MODULE( refmod_dpcm ) { 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 bve_cover_bucket Cv_bucket_refmod_audio ; bve_cover_bucket Cv_bucket_refmod_diff ; int buff ; sat_audio_ptr audio_saida_ptr ; audio_ptr audio_entrada_ptr ; sc_fifo_out <sat_audio_ptr > audio_saida_stim ; sc_fifo_in <audio_ptr > audio_entrada_stim ; # i n c l u d e " dpcm_api . c "
56
22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 C v _ b u c k e t _ r e f m o d _ a u d i o . end ( ) ; Cv_bucket_refmod_audio . begin ( ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f == 0 , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f == LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f == LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f > LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f < LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f > LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f < LIM_INF , 1 0 0 0 ) ; / / Coverage delete ( audio_entrada_ptr ) ; audio_saida_stim . write ( audio_saida_ptr ) ; a u d i o _ s a i d a _ p t r >a m o s t r a = d i f f ; a u d i o _ s a i d a _ p t r = new s a t _ a u d i o ( ) ; b u f f = a u d i o _ e n t r a d a _ p t r >a m o s t r a ; / / ####### R e f e r e n c e Model Main F u n c t i o n s ####### i n t d i f f = s u b t r a c t ( a u d i o _ e n t r a d a _ p t r >a m o s t r a , b u f f ) ; int sat = saturation ( diff ) ; / / ####### R e f e r e n c e Model Main F u n c t i o n s ####### audio_entrada_ptr = audio_entrada_stim . read ( ) ; while (1) { void p ( ) { bve_cover_bucket Cv_bucket_refmod_sat ;
57
59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 { buff = 0; SC_THREAD( p ) ; Cv_bucket_refmod_audio (" Cv_bucket_refmod_audio ") , Cv_bucket_refmod_diff (" Cv_bucket_refmod_diff ") , Cv_bucket_refmod_sat (" Cv_bucket_refmod_sat ") SC_CTOR ( refmod_dpcm ) : } } C v _ b u c k e t _ r e f m o d _ s a t . end ( ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t == LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t == LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t > LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t < LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t == 0 , 1 0 0 0 ) ; Cv_bucket_refmod_sat . begin ( ) ; C v _ b u c k e t _ r e f m o d _ d i f f . end ( ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f > LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f < LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f == LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f == LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f > LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f < LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f == 0 , 1 0 0 0 ) ; Cv_bucket_refmod_diff . begin ( ) ;
58
96 97 98 }; }
Cdigo Fonte B.3: Cdigo fonte das subrotinas que executam as funcionalidades do DPCM
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 } # endif # i f d e f GEN_MUT i n t main ( i n t a r g c , c h a r a r g v [ ] ) { return 0; } int saturation ( int unsat_data ) { i f ( u n s a t _ d a t a < LIM_INF ) r e t u r n LIM_INF ; i f ( u n s a t _ d a t a > LIM_SUP ) r e t u r n LIM_SUP ; return unsat_data ; } int subtract ( int a , int b ) { return a b; # d e f i n e LIM_SUP 3 # d e f i n e LIM_INF 4
Cdigo Fonte B.4: Cdigo fonte do Checker do mdulo DPCM

1 2 3 4 5 SC_MODULE( c h e c k e r ) 6 7 8 9 10 11 sc_fifo_in < sat_audio_ptr > audio_saida_from_refmod ; sc_fifo_in < sat_audio_ptr > audio_saida_from_duv ; { / / Pre C h e c k e r T e m p l a t e
59
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 SC_CTOR ( c h e c k e r ) 38 39 40 41 42 43 }; } { SC_THREAD( a u d i o _ s a i d a _ p ) ; } } } delete ( trans_refmod ) ; delete ( trans_duv ) ; i f ( ! ( t r a n s _ r e f m o d == t r a n s _ d u v ) ) { o s t r i n g s t r e a m ms ; ms << " e x p e c t e d : " << t r a n s _ r e f m o d << e n d l << " r e c e i v e d : " << t r a n s _ d u v << e n d s ; SCV_REPORT_ERROR ( " a u d i o _ s a i d a _ a c c e s s " , ms . s t r ( ) . c _ s t r ( ) ) ; e r r o r _ c o u n t _ a u d i o _ s a i d a = e r r o r _ c o u n t _ a u d i o _ s a i d a . read ( ) +1; sc_stop () ; while (1) { sat_audio_ptr sat_audio_ptr trans_refmod = audio_saida_from_refmod . read ( ) ; trans_duv = audio_saida_from_duv . read ( ) ; sc_signal <unsigned int > error_count_audio_saida ; void audio_saida_p ( ) {
Cdigo Fonte B.5: Cdigo fonte das estruturas de dados das transaes do mdulo DPCM
1 2 3 # i f n d e f STRUCTS_H # d e f i n e STRUCTS_H
60
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 // struct for diff_audio diff_audio { typedef sat_audio sat_audio_ptr ; }; } i n l i n e b o o l o p e r a t o r == ( c o n s t s a t _ a u d i o& a r g ) c o n s t { bool r e s u l t = t r u e ; r e s u l t &= a m o s t r a == a r g . a m o s t r a ; return result ; i n t amostra ; // struct for sat_audio sat_audio { typedef audio audio_ptr ; }; } i n l i n e b o o l o p e r a t o r == ( c o n s t a u d i o& a r g ) c o n s t { bool r e s u l t = t r u e ; r e s u l t &= a m o s t r a == a r g . a m o s t r a ; return result ; i n t amostra ; // s t r u c t for audio audio { # i n c l u d e # i n c l u d e u s i n g namespace s t d ;
struct
struct
struct
61
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 i n l i n e o s t r e a m& o p e r a t o r << ( o s t r e a m& os , c o n s t s a t _ a u d i o& a r g ) { } i n l i n e o s t r e a m& o p e r a t o r << ( o s t r e a m& os , c o n s t a u d i o& a r g ) { o s << " a u d i o = ( " ; o s << a r g . a m o s t r a << " " o s << " ) " ; r e t u r n os ; ; } i s t r e a m &o p e r a t o r >> ( i s t r e a m &i s , d i f f _ a u d i o &a r g ) { } i s t r e a m &o p e r a t o r >> ( i s t r e a m &i s , s a t _ a u d i o &a r g ) { } i s t r e a m &o p e r a t o r >> ( i s t r e a m &i s , a u d i o &a r g ) { / / o p e r a t o r s typedef diff_audio diff_audio_ptr ; }; } i n l i n e b o o l o p e r a t o r == ( c o n s t d i f f _ a u d i o& a r g ) c o n s t { bool r e s u l t = t r u e ; r e s u l t &= d i f f _ a m o s t r a == a r g . d i f f _ a m o s t r a ; return result ; int diff_amostra ;
i s >> a r g . a m o s t r a ; return is ;
i s >> a r g . a m o s t r a ; return is ;
i s >> a r g . d i f f _ a m o s t r a ; return is ;
62
78 79 80 81 82 83 84 85 86 87 88 89 90 91 # endif } i n l i n e o s t r e a m& o p e r a t o r << ( o s t r e a m& os , c o n s t d i f f _ a u d i o& a r g ) { o s << " d i f f _ a u d i o = ( " ; o s << a r g . d i f f _ a m o s t r a << " " o s << " ) " ; r e t u r n os ; ; } o s << " s a t _ a u d i o = ( " ; o s << a r g . a m o s t r a << " " o s << " ) " ; r e t u r n os ; ;
Cdigo Fonte B.6: Cdigo fonte do mdulo que conecta todos os elementos do testbench
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 refmod_dpcm r e f m o d _ 1 ( " r e f m o d _ 1 " ) ; refmod_dpcm_mut refmod_mut ( " refmod_mut " ) ; source source_i (" source_i ") ; i n t sc_main ( i n t argc , char argv [ ] ) { s c _ s e t _ t i m e _ r e s o l u t i o n ( 1 , SC_PS ) ; scv_tr_text_init () ; s c v _ t r _ d b db ( " t x d b . t x t " ) ; s c _ t r a c e _ f i l e t f = s c _ c r e a t e _ v c d _ t r a c e _ f i l e ( " wave " ) ; ( ( v c d _ t r a c e _ f i l e ) t f ) > s c _ s e t _ v c d _ t i m e _ u n i t ( 12) ; l o g f i l e = new o f s t r e a m ( " f i f o . l o g " ) ; ofstream l o g f i l e ; # include " structs_ext . h" # i n c l u d e " bve . h " # include " source . h" # include " checker . h" # i n c l u d e " refmod_dpcm . h " # i n c l u d e " refmod_dpcm_mut . h "
63
22 23 24 25 26 bve_fifo <audio_ptr > audio_entrada_refmod (" audio_entrada_refmod " , logfile ) ; 27 bve_fifo <audio_ptr > audio_entrada_to_driver (" audio_entrada_to_driver " , logfile ) ; 28 29 30 31 bve_fifo < sat_audio_ptr > audio_saida_refmod (" audio_saida_refmod " , logfile ) ; 32 bve_fifo < sat_audio_ptr > audio_saida_from_driver (" audio_saida_from_driver " , log file ) ; 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 }; sc_start () ; return 0; refmod_1 . a u d i o _ s a i d a _ s t i m ( a u d i o _ s a i d a _ r e f m o d ) ; checker_i . audio_saida_from_refmod ( audio_saida_refmod ) ; refmod_mut . a u d i o _ s a i d a _ s t i m ( a u d i o _ s a i d a _ f r o m _ d r i v e r ) ; checker_i . audio_saida_from_duv ( audio_saida_from_driver ) ; / / FIFOs l i n k s o f o u t p u t i n t e r f a c e s source_i . audio_entrada_to_refmod ( audio_entrada_refmod ) ; refmod_1 . a u d i o _ e n t r a d a _ s t i m ( a u d i o _ e n t r a d a _ r e f m o d ) ; source_i . audio_entrada_to_driver ( audio_entrada_to_driver ) ; refmod_mut . a u d i o _ e n t r a d a _ s t i m ( a u d i o _ e n t r a d a _ t o _ d r i v e r ) ; / / FIFOs l i n k s o f i n p u t i n t e r f a c e s / / Output F i f o s / / Input Fifos checker checker_i (" checker_i ") ;
Apndice C Cdigo Fonte do Testbench alterado do mdulo DPCM.

A seguir, o Cdigo Fonte do testbench do DPCM alterado para que pudessem ser aplicadas as mutaes. O Cdigo Fonte B.1 referente ao Source no muda, j que os estmulos utilizados so iguais aos originais. So acrescentados dois novos cdigos fonte para diferenciar o modelo de referncia, que permanece original, daquele sobre o qual sero aplicadas as mutaes. Os cdigos fonte C.1 e C.2 representam estes novos mdulos. Os originais permanecem inalterados. Cdigo Fonte C.1: Cdigo fonte do modelo de referncia do mdulo DPCM modicado para a mutao.
1 2 3 SC_MODULE( refmod_dpcm_mut ) { 4 5 6 7 8 9 10 11 sc_fifo_out <sat_audio_ptr > audio_saida_stim ; sc_fifo_in <audio_ptr > audio_entrada_stim ; # i n c l u d e " dpcm_api_mut . c "
64
65
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 / / Coverage delete ( audio_entrada_ptr ) ; audio_saida_stim . write ( audio_saida_ptr ) ; a u d i o _ s a i d a _ p t r >a m o s t r a = s a t ; a u d i o _ s a i d a _ p t r = new s a t _ a u d i o ( ) ; b u f f = a u d i o _ e n t r a d a _ p t r >a m o s t r a ; / / ####### R e f e r e n c e Model Main F u n c t i o n s ####### i n t d i f f = s u b t r a c t _ m u t ( a u d i o _ e n t r a d a _ p t r >a m o s t r a , b u f f ) ; int sat = saturation_mut ( diff ) ; / / ####### R e f e r e n c e Model Main F u n c t i o n s ####### audio_entrada_ptr = audio_entrada_stim . read ( ) ; while (1) { void p ( ) { bve_cover_bucket Cv_bucket_refmod_audio ; bve_cover_bucket Cv_bucket_refmod_diff ; bve_cover_bucket Cv_bucket_refmod_sat ; int buff ; sat_audio_ptr audio_saida_ptr ; audio_ptr audio_entrada_ptr ;
66
49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 } } C v _ b u c k e t _ r e f m o d _ s a t . end ( ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t == LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t == LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t > LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t < LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ s a t , s a t == 0 , 1 0 0 0 ) ; Cv_bucket_refmod_sat . begin ( ) ; C v _ b u c k e t _ r e f m o d _ d i f f . end ( ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f > LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f < LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f == LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f == LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f > LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f < LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ d i f f , d i f f == 0 , 1 0 0 0 ) ; Cv_bucket_refmod_diff . begin ( ) ; C v _ b u c k e t _ r e f m o d _ a u d i o . end ( ) ; Cv_bucket_refmod_audio . begin ( ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f == 0 , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f == LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f == LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f > LIM_INF , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f < LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f > LIM_SUP , 1 0 0 0 ) ; BVE_COVER_BUCKET( C v _ b u c k e t _ r e f m o d _ a u d i o , b u f f < LIM_INF , 1 0 0 0 ) ;
67
86 87 88 89 90 91 92 93 94 95 96 97 98 }; } { buff = 0; SC_THREAD( p ) ; Cv_bucket_refmod_audio (" Cv_bucket_refmod_audio ") , Cv_bucket_refmod_diff (" Cv_bucket_refmod_diff ") , Cv_bucket_refmod_sat (" Cv_bucket_refmod_sat ") SC_CTOR ( refmod_dpcm_mut ) :
O arquivo dpcm_api_mut.c precisa da funo main() da linguagem C, apenas para que a ferramenta de mutao possa gerar os mutantes a partir dele. Sem o main(), a ferramenta no consegue gerar os mutantes. Cdigo Fonte C.2: Cdigo fonte das subrotinas que executam as funcionalidades do DPCM modicado para a mutao.
1 2 3 4 5 6 7 8 9 10 11 } int saturation_mut ( int unsat_data ) { i f ( u n s a t _ d a t a < 4 ) r e t u r n 4; i f ( unsat_data > 3 ) return 3; return unsat_data ; } # include " / o p t / s o f t / proteumIM2 . 0 / LINUX / b i n / p r o t e u m . h "
int subtract_mut ( int a , int b ) { r e t u r n (0 b ) ;
O Checker recebe apenas a instruo sc_stop() na linha 28 para interromper a simulao assim que um erro for encontrado. Cdigo Fonte C.3: Cdigo fonte do checker do mdulo DPCM
1 2
68
3 4 5 SC_MODULE( c h e c k e r ) 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 SC_CTOR ( c h e c k e r ) 38 39 { SC_THREAD( a u d i o _ s a i d a _ p ) ; } } } delete ( trans_refmod ) ; delete ( trans_duv ) ; i f ( ! ( t r a n s _ r e f m o d == t r a n s _ d u v ) ) { o s t r i n g s t r e a m ms ; ms << " e x p e c t e d : " << t r a n s _ r e f m o d << e n d l << " r e c e i v e d : " << t r a n s _ d u v << e n d s ; SCV_REPORT_ERROR ( " a u d i o _ s a i d a _ a c c e s s " , ms . s t r ( ) . c _ s t r ( ) ) ; e r r o r _ c o u n t _ a u d i o _ s a i d a = e r r o r _ c o u n t _ a u d i o _ s a i d a . read ( ) +1; sc_stop () ; while (1) { sat_audio_ptr sat_audio_ptr trans_refmod = audio_saida_from_refmod . read ( ) ; trans_duv = audio_saida_from_duv . read ( ) ; sc_signal <unsigned int > error_count_audio_saida ; void audio_saida_p ( ) { sc_fifo_in < sat_audio_ptr > audio_saida_from_refmod ; sc_fifo_in < sat_audio_ptr > audio_saida_from_duv ; { / / Pre C h e c k e r T e m p l a t e
69
40 41 42 43 }; }
O novo arquivo de ligaes representado no Cdigo Fonte C.4 agora precisa incluir o modelo de referncia que foi alterado (linha 6), instanci-lo (linha 20) e realizar as devidas ligaes no Source e no Checker do testbench (linhas 41 e 48). Cdigo Fonte C.4: Cdigo fonte do mdulo que liga todos os elementos do testbench.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 bve_fifo <audio_ptr > audio_entrada_refmod (" audio_entrada_refmod " , logfile ) ; 27 bve_fifo <audio_ptr > audio_entrada_to_driver (" audio_entrada_to_driver / / Input Fifos refmod_dpcm r e f m o d _ 1 ( " r e f m o d _ 1 " ) ; refmod_dpcm_mut refmod_mut ( " refmod_mut " ) ; source source_i (" source_i ") ; i n t sc_main ( i n t argc , char argv [ ] ) { s c _ s e t _ t i m e _ r e s o l u t i o n ( 1 , SC_PS ) ; scv_tr_text_init () ; s c v _ t r _ d b db ( " t x d b . t x t " ) ; s c _ t r a c e _ f i l e t f = s c _ c r e a t e _ v c d _ t r a c e _ f i l e ( " wave " ) ; ( ( v c d _ t r a c e _ f i l e ) t f ) > s c _ s e t _ v c d _ t i m e _ u n i t ( 12) ; l o g f i l e = new o f s t r e a m ( " f i f o . l o g " ) ; ofstream l o g f i l e ; # include " structs_ext . h" # i n c l u d e " bve . h " # include " source . h" # include " checker . h" # i n c l u d e " refmod_dpcm . h " # i n c l u d e " refmod_dpcm_mut . h "
checker checker_i (" checker_i ") ;
70
" , logfile ) ; 28 29 30 31 bve_fifo < sat_audio_ptr > audio_saida_refmod (" audio_saida_refmod " , logfile ) ; 32 bve_fifo < sat_audio_ptr > audio_saida_from_driver (" audio_saida_from_driver " , log file ) ; 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 }; sc_start () ; return 0; refmod_1 . a u d i o _ s a i d a _ s t i m ( a u d i o _ s a i d a _ r e f m o d ) ; checker_i . audio_saida_from_refmod ( audio_saida_refmod ) ; refmod_mut . a u d i o _ s a i d a _ s t i m ( a u d i o _ s a i d a _ f r o m _ d r i v e r ) ; checker_i . audio_saida_from_duv ( audio_saida_from_driver ) ; / / FIFOs l i n k s o f o u t p u t i n t e r f a c e s source_i . audio_entrada_to_refmod ( audio_entrada_refmod ) ; refmod_1 . a u d i o _ e n t r a d a _ s t i m ( a u d i o _ e n t r a d a _ r e f m o d ) ; source_i . audio_entrada_to_driver ( audio_entrada_to_driver ) ; refmod_mut . a u d i o _ e n t r a d a _ s t i m ( a u d i o _ e n t r a d a _ t o _ d r i v e r ) ; / / FIFOs l i n k s o f i n p u t i n t e r f a c e s / / Output F i f o s
Apndice D Cdigo Fonte do Modelo de Referncia do mdulo IDCT

A seguir, o cdigo fonte da subrotina que implementa a IDCT do decodicador de vdeo xvid verso 0.9 patch-20 utilizada como modelo de referncia para um dos casos de estudo deste trabalho. Cdigo Fonte D.1: Cdigo fonte da subrotina que implementa a IDCT
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 idctFunc i d c t _ a l t i v e c ; idctFunc idct_ia64 ; i d c t F u n c idct_mmx ; i d c t F u n c idct_xmm ; idctFunc idct_sse2 ; idctFunc idct_int32 ; extern idctFuncPtr idct ; typedef void ( idctFunc ) ( s h o r t const block ) ; typedef idctFunc idctFuncPtr ; void i d c t _ i n t 3 2 _ i n i t ( void ) ; void i d c t _ i a 6 4 _ i n i t ( void ) ;
71
72
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 X8 = 565 ( X4 + X5 ) ; X4 = X8 + ( 2 8 4 1 5 6 5 ) X4 ; X5 = X8 ( 2 8 4 1 + 5 6 5 ) X5 ; X8 = 2408 ( X6 + X7 ) ; X6 = X8 ( 2 4 0 8 1 6 0 9 ) X6 ; X7 = X8 ( 2 4 0 8 + 1 6 0 9 ) X7 ; X0 = ( b l k [ 0 ] << 1 1 ) + 1 2 8 ; } for ( { b l k = b l o c k + ( i << 3 ) ; if (! ( ( X1 = b l k [ 4 ] << 1 1 ) | ( X2 = b l k [ 6 ] ) | ( X3 = b l k [ 2 ] ) | ( X4 = blk [ 1 ] ) | ( X5 = b l k [ 7 ] ) | ( X6 = b l k [ 5 ] ) | ( X7 = b l k [ 3 ] ) ) ) { blk [0] = blk [1] = blk [2] = blk [3] = blk [4] = blk [5] = blk [6] = b l k [ 7 ] = b l k [ 0 ] << 3 ; continue ; ( i = 3) ; i < 8 ; i ++) void i d c t _ i n t 3 2 ( short const block ) { s t a t i c short blk ; s t a t i c long i ; s t a t i c l o n g X0 , X1 , X2 , X3 , X4 , X5 , X6 , X7 , X8 ; s t a t i c short iclip [1024]; static short iclp ; idctFuncPtr idct ;
73
55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 f o r ( i = 0 ; i < 8 ; i ++) { blk = block + i ; } b l k [ 0 ] = ( s h o r t ) ( ( X7 + X1 ) >> 8 ) ; b l k [ 1 ] = ( s h o r t ) ( ( X3 + X2 ) >> 8 ) ; b l k [ 2 ] = ( s h o r t ) ( ( X0 + X4 ) >> 8 ) ; b l k [ 3 ] = ( s h o r t ) ( ( X8 + X6 ) >> 8 ) ; b l k [ 4 ] = ( s h o r t ) ( ( X8 X6 ) >> 8 ) ; b l k [ 5 ] = ( s h o r t ) ( ( X0 X4 ) >> 8 ) ; b l k [ 6 ] = ( s h o r t ) ( ( X3 X2 ) >> 8 ) ; b l k [ 7 ] = ( s h o r t ) ( ( X7 X1 ) >> 8 ) ; X7 = X8 + X3 ; X8 = X3 ; X3 = X0 + X2 ; X0 = X2 ; X2 = ( 1 8 1 ( X4 + X5 ) + 1 2 8 ) >> 8 ; X4 = ( 1 8 1 ( X4 X5 ) + 1 2 8 ) >> 8 ; X8 = X0 + X1 ; X0 = X1 ; X1 = 1108 ( X3 + X2 ) ; X2 = X1 ( 2 6 7 6 + 1 1 0 8 ) X2 ; X3 = X1 + ( 2 6 7 6 1 1 0 8 ) X3 ; X1 = X4 + X6 ; X4 = X6 ; X6 = X5 + X7 ; X5 = X7 ;
74
92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 X7 = X8 + X3 ; X8 = X0 + X1 ; X0 = X1 ; X1 = 1108 ( X3 + X2 ) + 4 ; X2 = ( X1 ( 2 6 7 6 + 1 1 0 8 ) X2 ) >> 3 ; X3 = ( X1 + ( 2 6 7 6 1 1 0 8 ) X3 ) >> 3 ; X1 = X4 + X6 ; X4 = X6 ; X6 = X5 + X7 ; X5 = X7 ; X8 = 565 ( X4 + X5 ) + 4 ; X4 = ( X8 + ( 2 8 4 1 5 6 5 ) X4 ) >> 3 ; X5 = ( X8 ( 2 8 4 1 + 5 6 5 ) X5 ) >> 3 ; X8 = 2408 ( X6 + X7 ) + 4 ; X6 = ( X8 ( 2 4 0 8 1 6 0 9 ) X6 ) >> 3 ; X7 = ( X8 ( 2 4 0 8 + 1 6 0 9 ) X7 ) >> 3 ; X0 = ( b l k [ 8 0 ] << 8 ) + 8 1 9 2 ; } if (! ( ( X1 = ( b l k [ 8 4 ] << 8 ) ) | ( X2 = b l k [ 8 6 ] ) | ( X3 = blk [8 2 ] ) | ( X4 = blk [8 1]) | ( X5 = b l k [ 8 7 ] ) | ( X6 = b l k [ 8 5 ] ) | ( X7 = b l k [ 8 3 ] ) ) ) { blk [8 0] = blk [8 1] = blk [8 2] = blk [8 3] = blk [8 4] = blk [8 5] = blk [8 6] = blk [8 7] = i c l p [ ( b l k [ 8 0 ] + 3 2 ) >> 6 ] ; continue ;
75
129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 } i c l p = i c l i p + 512; f o r ( i = 512; i < 5 1 2 ; i ++) i c l p [ i ] = ( i < 256) ? 256 : ( ( i > 2 5 5 ) ? 255 : i ) ; void i d c t _ i n t 3 2 _ i n i t ( void ) { int i ; } } b l k [ 8 0 ] = i c l p [ ( X7 + X1 ) >> 1 4 ] ; b l k [ 8 1 ] = i c l p [ ( X3 + X2 ) >> 1 4 ] ; b l k [ 8 2 ] = i c l p [ ( X0 + X4 ) >> 1 4 ] ; b l k [ 8 3 ] = i c l p [ ( X8 + X6 ) >> 1 4 ] ; b l k [ 8 4 ] = i c l p [ ( X8 X6 ) >> 1 4 ] ; b l k [ 8 5 ] = i c l p [ ( X0 X4 ) >> 1 4 ] ; b l k [ 8 6 ] = i c l p [ ( X3 X2 ) >> 1 4 ] ; b l k [ 8 7 ] = i c l p [ ( X7 X1 ) >> 1 4 ] ; X8 = X3 ; X3 = X0 + X2 ; X0 = X2 ; X2 = ( 1 8 1 ( X4 + X5 ) + 1 2 8 ) >> 8 ; X4 = ( 1 8 1 ( X4 X5 ) + 1 2 8 ) >> 8 ;

Disser Tac A Oh Enrique

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Disser Tac A Oh Enrique

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidade Federal de Campina Grande Centro de Engenharia Eltrica e Informtica Coordenao de Ps-Graduao em Informtica

Anlise de Mutao Aplicada Vericao Funcional de IP Core

Henrique do Nascimento Cunha

Joseana Macdo Fechine (Orientadora)

Campina Grande, Paraba, Brasil c Henrique do Nascimento Cunha, 29/08/2008

Referncias. Orientadora: Dra . Joseane Macdo Fechine.

1. Vericao funcional. 2. Teste de Mutao. 3. IP Core. I. Titulo

Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lista de Cdigos Fonte

1.1.1 Objetivos Especcos

1.2 Organizao da Dissertao

Captulo 2 Fundamentao Terica

2.1 A Metodologia de Vericao Funcional VeriSC

A Metodologia de Vericao Funcional VeriSC

2.1 A Metodologia de Vericao Funcional VeriSC

2.1 A Metodologia de Vericao Funcional VeriSC

2.1 A Metodologia de Vericao Funcional VeriSC

2.2 Anlise de mutao (Mutation Analysis)

Anlise de mutao (Mutation Analysis)

2.2.1 Hiptese do Programador Competente

2.2 Anlise de mutao (Mutation Analysis)

2.2.2 Efeito de acoplamento (Coupling effect)

2.2.3 Anlise e Teste de Mutao

2.2 Anlise de mutao (Mutation Analysis)

2.2 Anlise de mutao (Mutation Analysis)

2.2.4 Operadores de Mutao

2.2 Anlise de mutao (Mutation Analysis) k = 0 + *p k = 1 + *p k = 1 + *p k = ui + *p k = j + null

2.2.5 Aplicao da Anlise de Mutao

2.3 Trabalhos Relacionados

Captulo 3 Descrio da Anlise de Mutao Aplicada Metodologia VeriSC

3.1 Vericao das pr-condies

Vericao das pr-condies

Aplicao de mutao sobre o modelo de referncia

3.2 Aplicao de mutao sobre o modelo de referncia

3.2 Aplicao de mutao sobre o modelo de referncia

3.2 Aplicao de mutao sobre o modelo de referncia

3.3 Vericao do modelo de referncia mutado em relao ao original

Vericao do modelo de referncia mutado em relao ao original

Captulo 4 Apresentao e Anlise de Resultados

Caso de estudo: DPCM - Differential Pulse Code Modulator

4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator

4.1.1 Modelo de Referncia

4.1.2 Ambiente de Vericao

4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator

Figura 4.1: Aplicao das mutaes sobre o modelo de referncia do DPCM.

4.1.3 Preparao do Ambiente para Aplicao das Mutaes

4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator

4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator

4.1 Caso de estudo: DPCM - Differential Pulse Code Modulator

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

Caso de estudo: IDCT - Inverse Discrete Cosine Transform

4.2.1 Modelo de Referncia

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

4.2.2 Ambiente de Vericao

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

Dos 69 mutantes equivalentes ao programa original, 13 so devido a arquitetura do

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

4.2 Caso de estudo: IDCT - Inverse Discrete Cosine Transform

= 0, 883. Vale lembrar, que os mutantes equivalentes ao

= 0, 890. Observa-se, ento, que

2.2 Anlise de mutao (Mutation Analysis) k = 0 + p k = 1 + p k = 1 + p k = ui + p k = j + null