“ivm: uma metodologia de verificação funcional ... · ivm: uma metodologia de veriﬁcação...

Pós-Graduação em Ciência da Computação

“IVM: Uma Metodologia de Verificação Funcional Iteroperável, Iterativa e

Incremental”

Por

BRUNO OTÁVIO PIEDADE PRADO

Dissertação de Mestrado

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, MARÇO/2009

Universidade Federal de Pernambuco

Centro de Informática

Pós-graduação em Ciências da Computação

Bruno Otávio Piedade Prado

IVM: Uma Metodologia de Verificação FuncionalInteroperável, Iterativa e Incremental

Trabalho apresentado ao programa de pós-graduação em Ciências da Computação da Uni-versidade Federal de Pernambuco como requi-sito parcial para obtenção do grau de mestre emCiências da Computação.

Recife

11 de março de 2009

Prado, Bruno Otávio Piedade IVM: uma metodologia de verificação funcional interoperável, iterativa e incremental / Bruno Otávio Piedade Prado - Recife : O Autor, 2009. ix, 101 folhas : il., fig., tab.

Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2009.

Inclui bibliografia, anexo e apêndices.

1. Circuitos digitais. 2. Microeletrônica. I. Título.

621.381 5 CDD (22. ed.) MEI2009-047

Dedico este trabalho a Deus e a minha família,sem os quais nada disto seria possível nem faria

sentido.

"Confia no Senhor de todo o teu coração e nãote estribes no teu próprio entendimento."

Provérbios 3.5

Resumo

A crescente demanda por produtos eletrônicos e a capacidade cada vezmaior de in-

tegração criaram sistemas extremamente complexos em chips, conhecidos como System-

on-Chip ou SoC. Seguindo em sentido oposto a esta tendência, os prazos (time-to-market)

para que estes sistemas sejam construídos vem continuamente sendo reduzidos, obri-

gando que muito mais funcionalidades sejam implementadas em períodos cada vez

menores de tempo. A necessidade de um maior controle de qualidade do produto

final demanda a atividade de Verificação Funcional que consiste em utilizar um con-

juntos de técnicas para estimular o sistema em busca de falhas. Esta atividade é a ex-

tremamente dispendiosa e necessária, consumindo até cerca de 80% do custo final do

produto. É neste contexto que se insere este trabalho, propondo uma metodologia de

Verificação Funcional chamada IVM que irá fornecer todos os subsídios para garantir

a entrega de sistemas de alta qualidade, e ainda atingindo as rígidas restrições tempo-

rais impostas pelo mercado. Sendo baseado em metodologias já bastante difundidas

e acreditadas, como o OVM e o VeriSC, o IVM definiu uma organização arquitetural e

um fluxo de atividades que incorporou as principais características de ambas as abor-

dagens que antes estavam disjuntas. Esta integração de técnicas e conceitos resulta em

um fluxo de verificação mais eficiente, permitindo que sistemas atinjam o custo, prazo

e qualidade esperados.

Palavras-chave: SoC, Sistemas Digitais, Verificação Funcional, Cobertura Funcional,

OVM, VeriSC.

i

Abstract

The growing demand for electronic devices and its even higher integration capa-

bility created extremely complex systems in chips, known as System-on-Chip or SoC.

In a opposite way to this tendency, the time-to-market for these systems be built have

been continually reduced, forcing much more functionalities be implemented in even

shorten time periods. The final product quality control is assured by the Functional

Verification activity that consists in a set of techniques to stimulate a system in order

to find bugs. This activity is extremely expensive and necessary, responding to around

80% of final product cost. In this context this work is inserted on, proposing a Func-

tional Verification methodology called IVM that will provide all conditions to deliver

high quality systems, while keeping the hard time restrictions imposed by the mar-

ket. Based in well known and trusted methodologies, as OVM and VeriSC, the IVM

defined an architectural organization and an activity flow that incorporates features of

both approaches that were separated from each other. This techniques and concepts

integration resulted in a more efficient verification flow, allowing systems to meet the

desired budget, schedule and quality.

Keywords: SoC, Digital Systems, Functional Verification, Functional Coverage, OVM,

VeriSC.

ii

Sumário

1 Introdução 1

1.1 Objetivos e contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Conceitos básicos 6

2.1 O que é Verificação Funcional? . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Verificação no fluxo de desenvolvimento . . . . . . . . . . . . . . . . . . 7

2.2.1 Desenvolvimento Iterativo e Incremental . . . . . . . . . . . . . . 8

2.3 Abordagens de Verificação . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Estado da Arte 13

3.1 VeriSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.3 Fluxo de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3.1 Single Refmod . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3.2 Double Refmod . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3.3 DUV Emulation . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Open Verification Methodology (OVM) . . . . . . . . . . . . . . . . . . . 18

3.2.1 SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.3 Fluxo de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Cobertura Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Técnicas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Análise Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Metodologia IVM 24

4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Fluxo de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.1 Sanity Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2 Interface Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iii

SUMÁRIO iv

4.2.3 Environment Validation . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.4 DUV Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Análise de cobertura e critério de parada . . . . . . . . . . . . . . . . . . 32

5 Estudos de caso 36

5.1 Estudo de Caso: Dual Port Memory . . . . . . . . . . . . . . . . . . . . . 36

5.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.2 Aplicando o IVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.2.1 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.2.2 Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.2.3 Memory e Mutex (MemoryMutex) . . . . . . . . . . . . 47

5.1.2.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.2.5 Dual Port Memory (DualPortMemory) . . . . . . . . . . 55

5.2 Estudo de Caso: OCP-IP Router . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.2 Aplicando o IVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.2.1 Routing Unit (RoutingUnit) . . . . . . . . . . . . . . . . 60

5.2.2.2 OCP-IP Interface (Interface) . . . . . . . . . . . . . . . . 64

5.2.2.3 OCP-IP Router (OCPIPRouter) . . . . . . . . . . . . . . . 68

5.3 Estudo de Caso: CAIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3.2 Aplicando o IVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4 Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6 Conclusões e Trabalhos Futuros 81

6.1 Principais contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Referências Bibliográficas 83

A Biblioteca de padronização 84

B Código do critério de parada 99

Lista de Figuras

1.1 Lei de Moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Custo de correção de falhas . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Fluxo de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Fases do ipPROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Organização de SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Arquitetura do VeriSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Etapa Single Refmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Etapa Double Refmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.5 Etapa DUV Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6 Organização do OVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.7 Arquitetura do OVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Arquitetura do IVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Camadas do IVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Visão geral do fluxo de atividades do IVM . . . . . . . . . . . . . . . . . . 28

4.4 Etapa de checagem de sanidade . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5 Refinando interface da esquerda . . . . . . . . . . . . . . . . . . . . . . . 30

4.6 Refinando interface da direita . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.7 Etapa de validação do ambiente . . . . . . . . . . . . . . . . . . . . . . . . 31

4.8 Etapa de execução do DUV . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.9 Comportamento da cobertura . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 Arquitetura do Dual Port Memory . . . . . . . . . . . . . . . . . . . . . . 37

5.2 Cenário de uso do Dual Port Memory . . . . . . . . . . . . . . . . . . . . 37

5.3 Cenário da Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4 Cenário do Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.5 Cenário da Memory e Mutex . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.6 Cenário da Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.7 Sanity Checking de Memory . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.8 Interface Refinement de Memory . . . . . . . . . . . . . . . . . . . . . . . 41

v

LISTA DE FIGURAS vi

5.9 Environment Validation de Memory . . . . . . . . . . . . . . . . . . . . . 42

5.10 DUV Execution de Memory . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.11 Sanity Checking de Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.12 Interface Refinement de Mutex . . . . . . . . . . . . . . . . . . . . . . . . 45

5.13 Environment Validation de Mutex . . . . . . . . . . . . . . . . . . . . . . 46

5.14 DUV Execution de Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.15 Sanity Checking de MemoryMutex . . . . . . . . . . . . . . . . . . . . . . 48

5.16 Interface Refinement de MemoryMutex . . . . . . . . . . . . . . . . . . . 49

5.17 Environment Validation de MemoryMutex . . . . . . . . . . . . . . . . . 50

5.18 DUV Execution de MemoryMutex . . . . . . . . . . . . . . . . . . . . . . 51

5.19 Sanity Checking de Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.20 Interface Refinement de Interface . . . . . . . . . . . . . . . . . . . . . . . 52

5.21 Environment Validation de Interface . . . . . . . . . . . . . . . . . . . . . 53

5.22 DUV Execution de Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.23 Sanity Checking de DualPortMemory . . . . . . . . . . . . . . . . . . . . 55

5.24 Interface Refinement de DualPortMemory . . . . . . . . . . . . . . . . . . 56

5.25 Environment Validation de DualPortMemory . . . . . . . . . . . . . . . . 57

5.26 DUV Execution de DualPortMemory . . . . . . . . . . . . . . . . . . . . . 58

5.27 Arquitetura do OCP-IP Router . . . . . . . . . . . . . . . . . . . . . . . . 59

5.28 Cenário de uso do OCP-IP Router . . . . . . . . . . . . . . . . . . . . . . 59

5.29 Cenário do Routing Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.30 Cenário do OCP-IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.31 Sanity Checking de RoutingUnit . . . . . . . . . . . . . . . . . . . . . . . 61

5.32 Interface Refinement de RoutingUnit . . . . . . . . . . . . . . . . . . . . . 62

5.33 Environment Validation de RoutingUnit . . . . . . . . . . . . . . . . . . . 63

5.34 DUV Execution de RoutingUnit . . . . . . . . . . . . . . . . . . . . . . . . 64

5.35 Sanity Checking de OCP-IP Interface . . . . . . . . . . . . . . . . . . . . . 65

5.36 Interface Refinement de OCP-IP Interface . . . . . . . . . . . . . . . . . . 66

5.37 Environment Validation de OCP-IP Interface . . . . . . . . . . . . . . . . 67

5.38 DUV Execution de OCP-IP Interface . . . . . . . . . . . . . . . . . . . . . 68

5.39 Sanity Checking de OCP-IP Router . . . . . . . . . . . . . . . . . . . . . . 69

5.40 Interface Refinement de OCP-IP Router . . . . . . . . . . . . . . . . . . . 70

5.41 Environment Validation de OCP-IP Router . . . . . . . . . . . . . . . . . 71

5.42 DUV Execution de OCP-IP Router . . . . . . . . . . . . . . . . . . . . . . 72

5.43 Arquitetura do CAIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.44 Cenário de uso de CAIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.45 Sanity Checking de CAIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.46 Interface Refinement de CAIP . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.47 Environment Validation de CAIP . . . . . . . . . . . . . . . . . . . . . . . 76

LISTA DE FIGURAS vii

5.48 DUV Execution de CAIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.49 Análise comparativa do estudo de caso Dual Port Memory . . . . . . . . 79

5.50 Análise comparativa do estudo de caso OCP-IP Router . . . . . . . . . . 80

5.51 Análise comparativa do estudo de caso CAIP . . . . . . . . . . . . . . . . 80

Lista de Tabelas

3.1 Quadro comparativo do VeriSC e OVM . . . . . . . . . . . . . . . . . . . 23

4.1 Interface das camadas do IVM . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Detalhes da etapa de Sanity Checking de Memory . . . . . . . . . . . . . 40

5.2 Detalhes da etapa de Interface Refinement de Memory . . . . . . . . . . 41

5.3 Detalhes da etapa de Environment Validation de Memory . . . . . . . . 42

5.4 Detalhes da etapa de Sanity Checking de Mutex . . . . . . . . . . . . . . 44

5.5 Detalhes da etapa de Interface Refinement de Mutex . . . . . . . . . . . . 45

5.6 Detalhes da etapa de Environment Validation de Mutex . . . . . . . . . . 46

5.7 Detalhes da etapa de Sanity Checking de MemoryMutex . . . . . . . . . 48

5.8 Detalhes da etapa de Interface Refinement de MemoryMutex . . . . . . . 49

5.9 Detalhes da etapa de Environment Validation de MemoryMutex . . . . . 50

5.10 Detalhes da etapa de Sanity Checking de Interface . . . . . . . . . . . . . 52

5.11 Detalhes da etapa de Interface Refinement de Interface . . . . . . . . . . 53

5.12 Detalhes da etapa de Environment Validation de Interface . . . . . . . . 54

5.13 Detalhes da etapa de Sanity Checking de DualPortMemory . . . . . . . . 55

5.14 Detalhes da etapa de Interface Refinement de DualPortMemory . . . . . 56

5.15 Detalhes da etapa de Environment Validation de DualPortMemory . . . 57

5.16 Detalhes da etapa de Sanity Checking de RoutingUnit . . . . . . . . . . . 61

5.17 Detalhes da etapa de Interface Refinement de RoutingUnit . . . . . . . . 62

5.18 Detalhes da etapa de Environment Validation de RoutingUnit . . . . . . 63

5.19 Detalhes da etapa de Sanity Checking de Interface . . . . . . . . . . . . . 65

5.20 Detalhes da etapa de Interface Refinement de Interface . . . . . . . . . . 66

5.21 Detalhes da etapa de Environment Validation de Interface . . . . . . . . 67

5.22 Detalhes da etapa de Sanity Checking de OCP-IP Router . . . . . . . . . 69

5.23 Detalhes da etapa de Interface Refinement de OCP-IP Router . . . . . . . 70

5.24 Resultados da etapa de Environment Validation de OCP-IP Router . . . 71

5.25 Detalhes da etapa de Sanity Checking de CAIP . . . . . . . . . . . . . . . 74

5.26 Detalhes da etapa de Interface Refinement de CAIP . . . . . . . . . . . . 75

5.27 Detalhes da etapa de Environment Validation de CAIP . . . . . . . . . . 76

viii

LISTA DE TABELAS ix

5.28 Tamanho do ambiente de Verificação e complexidade dos sistemas . . . 78

5.29 Resultados de simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.30 Cobertura atingida nos estudos de caso . . . . . . . . . . . . . . . . . . . 78

Capítulo 1

Introdução

Diversos produtos de uso geral, que as pessoas utilizam em seu cotidiano, possuem

algum tipo de sistema com tecnologia semicondutora, e muitos de seus usuários des-

conhecem ou ignoram sua presença. Entretanto, a importância destes sistemas tem

sido continuamente aumentada, assim como sua complexidade.

Figura 1.1: Lei de Moore

Este aumento de complexidade se deve, em grande parte, a necessidade de produ-

tos que tenham cada vezmais funcionalidades disponíveis. O telefone celular é umdos

melhores exemplos deste grande aumento de funcionalidades, pois, no início de sua

utilização, o mesmo apenas realizava ligações e armazenava uma simples agenda de

contatos. Em modelos mais modernos, o celular é capaz de navegar na internet, enviar

e receber e-mails, executar jogos e aplicações, entre outros usos. A consequência lógica

da adição de todas estas funções é o aumento exponencial da complexidade do sis-

tema. Este comportamento foi previsto pela Lei de Moore (ilustrado na figura 1.1) que

define que a cada 2 anos, aproximadamente, é duplicada a capacidade de integração

de transistores em uma mesma área de silício.

1

CAPÍTULO 1. INTRODUÇÃO 2

É interessante perceber que segue, em sentido oposto ao eixo da complexidade, o

tempo em que o produto deve ser construído, verificado e posto em produção. Este

tempo é comumente conhecido como time-to-market, e o motivo que tem determinado

o seu encolhimento é a necessidade das empresas em maximizar seus lucros e obter

uma fatia maior do mercado.

Na busca pela qualidade, o custo e prazo previstos, a atividade de Verificação Fun-

cional, que busca garantir que o projeto desenvolvido atinja o seu propósito esperado,

ganha bastante importância. Por lidar com aspectos tão cruciais do projeto, a Verifi-

cação Funcional representa, sem dúvida, o maior desafio que a indústria de sistemas

semicondutores tem enfrentado nos últimos anos.

Estimativas de esforço de projeto falam que a Verificação Funcional consome de

50% a 80%[1] ou 70%[2] do esforço total do projeto. Apesar de números ligeiramente

diferentes, é patente que a Verificação Funcional representa uma etapa importante do

fluxo de desenvolvimento de sistemas digitais.

Figura 1.2: Custo de correção de falhas

Além do notório impacto no fluxo de projeto, as falhas não detectadas também

representam uma grande ameaça ao sucesso do projeto e à reputação da empresa que

desenvolve o sistema. Quanto mais se avança no desenvolvimento para se detectar

uma falha, maior será seu custo de correção [3] (cresce exponencialmente, como pode

ser visto na figura 1.2), devido ao fato de que todas as etapas anteriores precisarão ser

repassadas para que a correção seja feita e não inclua outros erros no sistema.

Alguns casos de falhas[4]1 não detectadas pela Verificação Funcional, como a falha

na unidade de ponto flutuante do Intel Pentium 4 e a destruição do satélite Mars Cli-

mate Orbiter da NASA, ganharam notoriedade, em grande parte pelas consequências e

prejuízos que causaram.

Em 1994, o processador Pentium da Intel teve uma falha na sua unidade de ponto

flutuante descoberta, durante erros de cálculos de números primos. Esta falha gerava

1Introdução do Trabalho de Graduação em Engenharia da Computação


resultados errôneos na operação de divisão para o oitavo dígito significativo, para al-

guns argumentos. Apesar deste problema só se manifestar para, no máximo, 1 usuário

dentro de um grupo de 1 milhão, a Intel teve um prejuízo estimado de cerca de US$

500 milhões, além de perder credibilidade e mercado para sua rival AMD.

Outro caso que também ficou famoso ocorreu no ano de 1999: o satélite Mars Cli-

mate Orbiter daNASA, que vooumuito próximo da atmosferamarciana e acabou sendo

destruído. Depois da perda do satélite foi feita uma investigação, que constatou que

falha aconteceu por diferentes unidades métricas terem sido utilizadas (Sistema Inter-

nacional e Britânicas), gerando o erro fatal na trajetória.

Por causa da importância da Verificação Funcional, foram criadasmetodologias que

buscavam otimizar o esforço empreendido, fornecendo uma cobertura de testes mais

ampla possível. Deste universo foram escolhidos duas metodologias como estado da

arte: o VeriSC e o Open Verification Methodology (OVM), por apresentarem característi-

cas bem distintas entre si e ao mesmo tempo de bastante relevância.

O VeriSC é caracterizado por um fluxo de atividades top-down e um conjunto de

passos que permitem a construção do ambiente de Verificação Funcional em fases e

correto por construção. Os objetivos principais desta abordagem são a simplicidade

da arquitetura, o reduzido número de linhas de código que precisa ser implementado

e a possibilidade de utilizar bibliotecas ou componentes disponíveis como modelos de

referência.

A metodologia OVM se caracteriza por um fluxo bottom-up e uma elaborada arqui-

tetura em camadas que permite a interoperabilidade2 dos componentes criados através

de uma biblioteca de padronização dos seus componentes. Os aspectos primordiais

desta metodologia residem na capacidade de padronização dos componentes criados

e na análise de cobertura que fornece ao projetista uma clara visão do que foi e do que

não foi efetivamente verificado.

Pelos fatores explicitados, nota-se que é extremamente importante que exista e seja

aplicado um processo de Verificação Funcional durante o desenvolvimento de sistemas

digitais, mesmo que seja difícil de ser feito, impacte no cronograma, aumente o custo,

pois a qualidade do produto final depende disto.

1.1 Objetivos e contribuições

Este trabalho tem como principal objetivo o estabelecimento de uma metodologia

de Verificação Funcional que apresente uma combinação das metodologias VeriSC e

OVM, que são o estado da arte considerado, proporcionando novas funcionalidades e

2É um conceito amplo de re-utilização de componentes em projetos distintos, através do uso deinterfaces padronizadas que permitem sua integração em diferentes plataformas e ferramentas, semque modificações se façam necessárias.


melhorias. Para atingir tal intento, os seguintes requisitos, antes disjuntos ou mesmo

ausentes em ambas metodologias, foram atendidos por este trabalho, sendo listados a

seguir:

� Suporte a fluxos de desenvolvimento em cascata (modelo clássico e ampla-

mente adotado no desenvolvimento de sistemas) e iterativo e incremental (mo-

delo cíclico que permite que versões funcionais do sistema sejam liberadas

mais rapidamente) que são adotados em projetos de desenvolvimento;

� Um algoritmo genérico e automático (funciona sem intervenção humana) para

finalização da simulação (critério de parada) baseado na análise da cobertura,

liberando o projetista da difícil tarefa de definir de quando o sistema foi sufi-

cientemente verificado;

� Todo o ambiente de Verificação Funcional pode ser construído e executado an-

tes da primeira versão do projeto ser completada, de maneira natural e sem

implicar em esforço adicional. Desta maneira, consegue-se validar todo o am-

biente sem que nenhuma integração com o sistema se faça necessária, preve-

nindo assim possíveis erros derivados desta interação;

� Os componentes de Verificação Funcional são projetados, padronizados e es-

truturados em camadas, assim como no OVM, de forma que seu re-uso em

outros projetos seja assegurado, reduzindo o esforço para construção de ambi-

entes.

Nas próximas seções e capítulos, ficarão claras ao leitor quais funcionalidades es-

tavam disjuntas ou inexistentes nas metodologias consideradas e como este trabalho

as unificou ou complementou. Todas estas contribuições serão retomadas no capítulo

final de conclusão deste trabalho, de forma a re-afirmá-las e consolidar a contribuição

deste trabalho.

1.2 Estrutura da dissertação

Para guiar o leitor sobre a organização desta dissertação, esta seção foi dedicada a

detalhar como estão estruturados os capítulos e quais são seus conteúdos.

� Capítulo 1: é feita uma introdução mostrando a importância da Verificação Fun-

cional e quais são os objetivos e contribuições deste trabalho;

� Capítulo 2: os conceitos básicos necessários para um melhor entendimento do

trabalho é fornecido neste capítulo, além de definições e considerações;


� Capítulo 3: as metodologias consideradas como estado da arte são detalhadas e

uma importante técnica associada, chamada cobertura funcional, é também ex-

plicitada;

� Capítulo 4: a metodologia proposta é descrita, detalhando todos os aspectos rele-

vantes que forammostrados e atendendo aos objetivos e contribuições definidos;

� Capítulo 5: os estudos de caso são detalhados, fornecendo ao leitor uma noção

prática da aplicação da metodologia proposta e de sua real capacidade de con-

templar os objetivos traçados;

� Capítulo 6: as conclusões e trabalhos futuros são explicitados, fechando as con-

tribuições realizadas e propondo pontos para melhorias e futuros trabalhos;

� Apêndice A: este apêndice contém o código fonte da biblioteca de padroniza-

ção de componentes, criada para que a metodologia proposta tivesse elementos

concretos que garantissem a interoperabilidade de seus componentes;

� Apêndice B: o código fonte da análise de cobertura para decisão do critério de

parada é descrito, permitindo um entendimento mais claro do funcionamento do

algoritmo.

Capítulo 2

Conceitos básicos

Neste capítulo será feita uma breve introdução sobre os conceitos básicos da Verifi-

cação Funcional, estabelecendo sua importância nos projetos de sistemas digitais, seus

fundamentos, abordagens mais difundidas e desafios inerentes.

2.1 O que é Verificação Funcional?

Antes mesmo de definir que é Verificação Funcional, é necessário esclarecer um

ponto que causa bastante confusão: verificação é diferente de validação. A verificação

responde se o sistema está sendo construído corretamente, enquanto a validação se

preocupa em responder se o sistema especificado tem o propósito esperado.

É importante que o leitor tenha emmente estes dois aspectos tão similares, pois um

sistema idealmente verificado pode não atingir o intento que motivou sua criação, ape-

sar de sua "perfeição" funcional. Para evitar ambiguidades e definir bem o escopo do

que é Verificação Funcional, uma definição clara e precisa será utilizada neste trabalho:

"Verificação Funcional é o processo que busca demonstrar a equivalência entre uma

implementação com sua respectiva especificação."

O trabalho de validação do sistema, como já foi dito, foge ao escopo do que se

propõe a Verificação Funcional, sendo de responsabilidade da equipe que especifica

o sistema. Falhas tardiamente detectadas ou não detectadas, em ambas atividades,

impactam de maneira devastadora sobre o cronograma, custo e qualidade do projeto,

podendo inclusive culminar em seu cancelamento.

Muitos trabalhos costumam falar em corretude funcional ou ausência de erros ou

mesmo perfeição, quando é teoricamente impossível demonstrar que, para a grande

maioria dos sistemas, estão corretos ou não possuem falhas, independentemente do

6

CAPÍTULO 2. CONCEITOS BÁSICOS 7

tempo e recursos disponíveis. Devido a esta incapacidade, uma metodologia de Veri-

ficação Funcional que rastreie as funcionalidades do sistema é fundamental para que

os projetistas tenham uma métrica do que foi exercitado e do que não foi, reduzindo

assim as chances de falhas não serem detectadas.

Para fins de simplificação, falaremos de agora em diante apenas Verificação ao invés

de Verificação Funcional, mas fica aqui registrado que quando for utilizado este termo

o aspecto funcional estará subentendido.

2.2 Verificação no fluxo de desenvolvimento

Antes de nos aprofundarmos nos conceitos de Verificação, é interessante que o lei-

tor possua uma visão geral de como esta importante atividade se insere no fluxo de

desenvolvimento de sistemas digitais. O modelo que será utilizado como base é com-

posto pelas atividades de Especificação, Implementação Alto Nível ou RTL, Síntese

Comportamental ou Lógica e Prototipação, podendo ser visualizado na figura 2.1.

Figura 2.1: Fluxo de desenvolvimento

Todos os projetos de sistemas digitais devem ter como ponto de partida algum

tipo de especificação que contém informações sobre que funcionalidades o sistema irá

proporcionar. Esta especificação pode ser estruturada das mais variadas formas e é

utilizada como base referencial para a Verificação que, como já foi dito anteriormente,


busca demonstrar a equivalência entre uma implementação e sua especificação.

A partir da especificação é possível iniciar a próxima etapa do fluxo que é a im-

plementação do sistema. Normalmente, a implementação é feita utilizando alguma

linguagem de descrição de hardware, como VHDL ou Verilog, por exemplo, em nível

de transferência de registradores (RTL). Entretanto, com o advento da síntese com-

portamental, descrições em alto nível, como ANSI C ou SystemC comportamental são

utilizadas para descrever o sistema.

Após o processamento e Verificação desta descrição, ferramentas de síntese com-

portamental ou lógica são capazes de gerar outra implementação, em nível mais baixo

de abstração, como código RTL ou portas lógicas. Esta implementação em nível de

abstração mais baixo precisará ser novamente verificada antes de serem novamente

processada emapeada em um nível aindamais baixo. Este mapeamento permite a pro-

totipação da implementação em sistemas programáveis, como FPGAs ou fixos, como

ASICs.

É interessante observar que as transições entre a Implementação, Síntese Compor-

tamental ou Lógica e Prototipação nada mais consistem de refinamentos e otimizações

sobre um mesmo comportamento que precisa ser preservado. A Verificação, de ma-

neira transparente, estimula o sistema e compara suas saídas, em qualquer um dos

níveis citados, de forma a verificar se o comportamento é preservado.

2.2.1 Desenvolvimento Iterativo e Incremental

Em contraste com o tradicional fluxo de desenvolvimento em cascata1, um pro-

cesso iterativo e incremental, como o ipPROCESS[5], tem como principal característica

a construção do sistema através de passos centrados em porções de funcionalidades

selecionadas. Desta maneira, reduz-se a complexidade do problema, pois é analisada

apenas uma parte do sistema por vez e não o sistema como um todo. A implementa-

ção parcial do sistema permite que os possíveis erros de especificação e entendimento

sejam descobertos mais rapidamente, reduzindo o custo de resolução dramaticamente,

como já foi dito anteriormente.

Para explicar a diferença entre os fluxos de desenvolvimento em cascata e iterativo

e incremental, de maneira simples e clara, uma analogia com a construção de uma es-

trada de duas faixas2 será utilizada. Imagine que duas construtoras C (constrói em

cascata) e I (constrói iterativamente e incrementalmente) estão construindo duas estra-

das idênticas.

A construtora C prepara o terreno, a base, a compactação do solo e coloca o asfalto

1Fluxos de desenvolvimento cascata são caracterizados por explorar em largura todas as funcionali-dades do sistema, somente avançando para a próxima fase quando a fase atual estiver completamenteterminada.

2Cada faixa representa uma hipotética funcionalidade do sistema.


das duas faixas, sempre observando a seguinte regra: enquanto que, para ambas as fai-

xas que estão sendo construídas, a fase anterior não estiver completamente concluída,

em toda extensão da estrada, a próxima fase não poderá ser iniciada. Já a construtora

I prepara somente a parte do terreno, da base, da compactação e coloca o asfalto re-

ferente a apenas uma das faixas. Para a construtora I a regra base é: para cada faixa

da estrada que estiver sendo construída, todas as fases deverão ser executadas até que

toda a faixa seja construída.

Através do exemplo dado fica evidente que a construtora I terá uma meia pista

pronta para o tráfego de veículos na metade do tempo que construtora C, e a principal

consequência disto é que correções e ajustes serão mais precoces e frequentes.

Figura 2.2: Fases do ipPROCESS

Da mesma maneira que construir uma estrada demanda uma série de etapas, a im-

plementação de um sistema também requer que um fluxo seja seguido. No processo

de desenvolvimento iterativo e incremental ipPROCESS, estas etapas são chamadas de

fases (ilustradas com seus respectivos esforços de projeto na figura 2.2) e são: Requi-

sitos (Elicitação dos requisitos com o cliente e definição das funcionalidades), Análise

e Projeto (Definição das classes e projeto dos componentes), Implementação RTL (Co-

dificação em VHDL ou Verilog), Verificação Funcional (Definição e execução dos casos

de teste) e Prototipação em FPGA (Síntese lógica e mapeamento tecnológico).

2.3 Abordagens de Verificação

Várias abordagens podem e devem ser utilizadas para que a Verificação seja exe-

cutada de maneira satisfatória. Estas técnicas são muitas vezes aplicadas de maneira


complementar e com combinações entre os agrupamentos3 que são descritos a seguir:

� Nível de observabilidade[6]

→ Caixa Preta: nesta abordagem, o sistema é estimulado e observado apenas

através de suas entradas e saídas, desconsiderando completamente infor-

mações sobre estrutura e implementação. A abstração de detalhes internos

traz vários benefícios, entretanto dificulta que certos estados internos sejam

atingidos, além de dificultar a localização de erros detectados durante as

simulações.

→ Caixa Branca: propõe a completa visualização e controle de todo o sistema,

permitindo que combinações de estados e entradas sejam rapidamente con-

figurados. Porém, esta intensa integração cria uma forte dependência das

estruturas de Verificação com uma determinada implementação, impedindo

que estes componentes sejam re-usados em outros projetos. Após a síntese

lógica, as estruturas internas são transformadas ou suprimidas, desta forma

inviabilizando que o mesmo ambiente de Verificação utilizado na fase RTL

seja usado.

→ Caixa Cinza: é o compromisso entre as abordagens caixa preta e caixa branca,

combinando a re-usabilidade do método caixa preta que considera somente

as interfaces externas do sistema e a capacidade de observar e controlar es-

truturas internas do caixa branca, buscando assim avaliar se o objetivo dos

estímulos foi atingido.

� Fluxo de desenvolvimento[2]

→ Top-down: o sistema é concebido de cima para baixo, onde suas funcio-

nalidades especificadas são implementas em alto nível de abstração e com

o avançar do tempo são particionadas até que todos componentes do pro-

jeto sejam completamente detalhados. Quando o projeto tem um tamanho

e complexidade razoáveis, não permite simulações com níveis detalhados,

necessitando de sistemas rápidos de prototipação, emuladores, aceleradores

de hardware ou particionamento em blocos menores.

→ Bottom-up: é usado largamente em diversas empresas, consistindo em ve-

rificar todas as partes componentes do sistema de maneira isolada num pri-

meiro momento. Depois desta etapa, a integração entre os módulos é tes-

tada, de maneira incremental até que todo o sistema esteja integrado.

3Por exemplo, ambiente de Verificação com observabilidade caixa preta, fluxo baseado em plata-forma e cobertura funcional.


→ Baseado em Plataforma: centrado no conceito de plataforma, onde uma já

verificada plataforma é extendida com a adição de um novo componente.

Nesta abordagem, tanto a Verificação top-down como a bottom-up precisam

ser utilizadas.

→ Dirigido a Interface: foca nas interfaces do sistema, explorando as funciona-

lidades proporcionadas por cada uma delas, reduzindo o esforço de integra-

ção e permitindo que erros de comunicação sejam descobertos mais cedo.

� Cobertura[4, 2, 7]

→ Cobertura de Código: consiste em analisar os fluxos de código executados

pelo sistema que está sendo verificado, permitindo que se saiba que trechos

estão sendo executados e os que não estão. O uso adequado desta técnica

implica no conhecimento profundo do sistema em questão, o que pode cau-

sar um efeito de contaminação sobre a equipe de Verificação, já que a mesma

terá acesso a como foi feita a implementação;

→ Cobertura Funcional: é uma técnica que tem como objetivo principal medir

a qualidade dos estímulos gerados para o sistema. Através destas informa-

ções obtidas, o engenheiro tem uma visão clara do que foi e do que não foi

estimulado. Ex: Quando 80% dos endereços de memória forem acessados,

a simulação pode ser finalizada. Após a análise dos endereços que não fo-

ram acessados, o responsável pode verificar se algum endereço relevante

precisaria ser acessado, caso contrário a cobertura foi atingida.

A Cobertura de Código, apesar de ser uma importante ferramenta de análise, não

será explorada por este trabalho, pois não fornece informações referentes às funciona-

lidades que foram estimuladas (esta análise é feita pela cobertura funcional e é consi-

derada muito mais importante do que medir quanto do código foi estimulado). Outro

fator importante para que a cobertura de código não seja aprofundada é o problema

de contaminação da equipe de Verificação que passará a conhecer a solução imple-

mentada (código fonte) e isto poderá implicar no mascaramento de erros. Apesar da

cobertura de código não ser efetivamente abordada, fica registrado que sua utilização

é possível e suportada, mas que o leitor deve ter em mente que o aspecto funcional

do sistema deve ser priorizado e não sua implementação (linhas de código). Mais adi-

ante, no capítulo de estado da arte, o leitor terá maiores detalhes sobre a Cobertura

Funcional e sua importância.

Antes de seguir adiante é necessário esclarecer as diferenças e semelhanças entre

Verificação e Teste. Verificação é igual a Teste quando se faz referência a termos lega-

dos, como Projeto em Teste (Design Under Test ou DUT) que trata Verificação e Teste


como sinônimo. Quando se fala em Teste como a busca de defeitos de fabricação, Veri-

ficação e Teste são atividades bem distintas.

É importante sempre ter em mente que ambas as situações são frequentes e que

o leitor deve utilizar o seu bom censo ao avaliar o real significado do termo Teste.

Sempre que possível, deve ser dada preferência ao termo Verificação quando o aspecto

funcional estiver em enfoque.

Capítulo 3

Estado da Arte

O principal objetivo deste capítulo é apresentar ao leitor o estado da arte na área

de Verificação, que foi considerado para o desenvolvimento deste trabalho. Será for-

necida, também, uma descrição detalhada de cada metodologia considerada, de forma

que fiquem explícitas as motivações que levaram às suas escolhas como referências.

3.1 VeriSC

É a metodologia de Verificação do consórcio acadêmico Brazil IP, que tem como

principal objetivo formar competências em projetos de circuitos integrados no Bra-

sil. Atualmente, é suportado principalmente pelas Universidades Federais de Pernam-

buco e de Campina Grande, contribuindo ativamente para a formação de recursos hu-

manos na área de microeletrônica.

A metodologia VeriSC[7], [8] é o resultado de um doutorado em Engenharia Elé-

trica de Karina Rocha Gomes da Silva, sob orientação do professor Elmar Uwe Kurt

Melcher, da Universidade Federal de Campina Grande. A grande motivação deste

trabalho foi construir uma metodologia inovadora que atendesse aos requisitos esta-

belecidos pelo consórcio Brazil IP.

Foi estruturada inicialmente para ser implementada com a linguagem SystemC,

que será detalhada na próxima sub-seção, definindo um fluxo bem definido de pro-

jeto. Além da definição de um fluxo de atividades, ferramentas de suporte foram de-

senvolvidas para auxiliar a criação do ambiente de Verificação, como geradores de

componentes semi-automáticos e uma biblioteca de cobertura funcional baseada em

regras.

3.1.1 SystemC

Uma biblioteca de código aberto implementada em C++ com o intuito de descrever

componentes de hardware e sistemas, permitindo que sistemas possam ser compilados

13

CAPÍTULO 3. ESTADO DA ARTE 14

e executados usando compiladores genéricos, como o GNU GCC. Foi criada pela Sy-

nopsys Inc. em 1999, e é um padrão IEEE 1666-2005 e sua organização pode ser vista a

seguir na figura 3.1.

Figura 3.1: Organização de SystemC

Diversas empresas tem investido e suportado esta linguagem, explorando as mais

diversas aplicações, como síntese comportamental e cobertura funcional. SystemC é

extremamente poderosa e genérica para modelar os mais variados sistemas, mas não

possui em seu conjunto um suporte nativo para Verificação.

Para contornar esta deficiência, dentro do próprio consórcio SystemC foi criada

a biblioteca SystemC Verification (SCV) que buscou reduzir as dificuldades de quem

utiliza SystemC para verificar sistemas. Apesar de cobrir de maneira bastante satisfa-

tória a parte de geração de estímulos, a biblioteca SCV não contempla outros aspectos

também fundamentais para a Verificação Funcional, como a cobertura funcional e o

conceito de assertions.

3.1.2 Arquitetura

Os componentes que compõem a arquitetura do VeriSC (ilustrada na figura 3.2)

são responsáveis pela geração de estímulos, modelagem do comportamento esperado,

através de um modelo de referência, e análise dos resultados gerados. Uma descrição

mais precisa é fornecida a seguir:


Figura 3.2: Arquitetura do VeriSC

� Source: este módulo é responsável pela geração de uma estrutura de dados, con-

tendo um conjunto de informações (transação) que serão utilizadas para geração

de sinais que estimularão o sistema. As transações geradas são escritas, de ma-

neira simultânea, em duas filas ordenadas (estruturas FIFO), para que os demais

componentes que fizerem a leitura não percam o sincronismo. Os casos de teste

são implementados neste componente, desta forma, para cada instância diferente

do sistema que está sendo verificado, é necessário que um Source específico para

cada contexto seja utilizado.

� TDriver: é o componente responsável por ler as transações geradas pelo Source

e as converter em estímulos baseados em sinais, respeitando o protocolo asso-

ciado. Somente é utilizado para inserir estímulos, não sendo capaz de capturar

nenhuma informação fornecida pelo sistema.

� Reference Model (Refmod): modela, em alto nível, o comportamento do sistema

que está sendo verificado, sendo normalmente atemporal e funcionando em nível

de transação. Este componente recebe as transações geradas pelo Source da FIFO,

as processa e, por fim, gera novas transações contendo as respostas que serão

comparadas com o resultado dado pelo sistema que está sendo verificado.

� TMonitor: captura as respostas fornecidas em nível de sinais pelo sistema, ge-

rando transações que serão comparadas com as transações geradas pelo Refmod.

Funcionando como função inversa do TDriver, o TMonitor só captura os sinais

gerados pelo sistema, sendo incapaz de gerar estímulos.

� Checker: tem como função a comparação das transações geradas pelo Refmod

(valor esperado) com as transações geradas pelo TMonitor (valor recebido). Uma

vez que o sincronismo é garantido pelo uso das FIFOs, o Checker carrega as tran-

sações disponíveis e as compara, procurando por diferenças entre elas. Quando

diferenças são detectadas, mensagens de erro são geradas, informando o valor

esperado e o valor recebido, além de outras informações relevantes.


A simplicidade e o fácil entendimento da arquitetura do VeriSC são, sem dúvida,

os pontos fortes desta metodologia, pois, pelo que já foi dito sobre a complexidade das

atividades de Verificação, verificar um sistema é complicado e demanda grande parte

do esforço de projeto.

Entretanto, a simples organização arquitetural do VeriSC, como o uso de FIFO para

sincronização, traz algumas consequência, como a abstração da noção de tempo da

comunicação. Desta forma, funcionalidades que dependem ou são baseadas em tempo

não podem ser adequadamente modeladas. Portanto, antes da aplicação do VeriSC,

como metodologia de Verificação, deve ser realizada uma análise sobre os requisitos

exigidos, pois suas facilidades podem implicar em restrições não toleráveis.

Nas próximas seções serão explicitados todos os pontos relativos as limitações do

VeriSC, bem como a que domínios esta metodologia melhor se aplica.

3.1.3 Fluxo de atividades

Além de definir os componentes e sua organização arquitetural, o VeriSC também

propõe um conjunto de passos para implementação de seu fluxo de atividades. Baseia-

se numa visão top-down, onde o sistema é tratado de maneira completa, e com o avan-

çar das etapas de projeto vai sendo decomposto em suas partes componentes.

3.1.3.1 Single Refmod

Nesta etapa a capacidade de interação dos componentes é testada, através da ins-

tanciação de três componentes: Pre-Source, Reference Model e Sink. A forma como os

componentes são conectados pode ser vista na figura 3.3.

Figura 3.3: Etapa Single Refmod

O Reference Model tem sua capacidade de comunicação testada, através de tran-

sações geradas pelo Pre-Source e de transações capturadas pelo Sink. O Pre-Source é

um subconjunto do Source, contendo praticamente todas as suas funcionalidades, po-

rém, somente com uma interface de saída. O Sink, de maneira análoga ao Pre-Source,

representa um subconjunto do Checker.

3.1.3.2 Double Refmod

Uma vez certificada a capacidademínima de comunicação dos componentes, é feita

uma expansão do cenário anterior, através do uso de um Source, dois Reference Model


e um Checker, como pode ser visto na figura 3.4.

Figura 3.4: Etapa Double Refmod

Tanto o Source como o Checker estão totalmente completos e funcionais, sendo

capazes de gerar estímulos e detectar possíveis erros de comunicação ou sincronismo

entre os módulos. De forma a se verificar a sanidade1 do ambiente, erros propositais

podem ser inseridos para assegurar que o Checker é capaz de detectá-los. O Checker

deve emitir mensagens somente em caso de erro, para evitar excesso de informações

na tela que dificultam a leitura do terminal.

3.1.3.3 DUV Emulation

Uma vez que a capacidade de geração e comparação de transações foi testada,

os componentes responsáveis pela conversão das transações de estímulos em sinais

(TDriver) e dos sinais em transações (TMonitor) são inseridos. A organização pode ser

vista na figura 3.5.

Figura 3.5: Etapa DUV Emulation

Um pré-requisito para que esta etapa seja realizada é a simetria entre o TDriver e

o TMonitor. Isto significa que se conectarmos um TDriver ao seu respectivo TMoni-

tor, uma função identidade será implementada, deixando inalterada as transações que

1O leitor deve entender por sanidade a capacidade do ambiente de Verificação em diagnosticar seseu funcionamento está coerente, através de um conjunto de testes.


passarem pelo canal. Para exemplificar este conceito, faça-se a transação T como pa-

râmetro que será gerado pelo Source, o TDriver e o TMonitor como as funções D(x) e

M(x) que irão processar e gerar transações, respectivamente. Desta forma, temos que

se o TDriver e o TMonitor são simétricos, M(D(x)) é igual a T, ou seja, a transação

de entrada do TDriver será a mesma gerada na saída do TMonitor para o Reference

Model.

Esta etapa permite que os TDrivers e TMonitors do ambiente de Verificação sejam

testados e validados, sem a necessidade de interação com sistema, visto que uma das

premissas do VeriSC é ter o ambiente de Verificação pronto antes do primeiro release

do sistema que será verificado.

Uma vez finalizadas estas etapas, o ambiente de Verificação já está apto a receber

o sistema (representado pela área interna delimitada pela linha tracejada que engloba

o Reference Model, TDriver e TMonitor na figura 3.5) a ser verificado. A metodologia

prevê outros passos referentes a decomposição hierárquica (que repete os passos Single

Refmod, Double Refmod e DUV Emulation para diferentes partições do sistema), mas,

para fins de simplificação e melhoria de entendimento do leitor, estes serão omitidos.

3.2 Open Verification Methodology (OVM)

Resultante de um esforço conjunto das principais empresas de Electronic Design Au-

tomation (EDA) do mundo, Cadence® e Mentor®, o OVM[9]2 tem como objetivo a pa-

dronização e interoperabilidade de componentes de Verificação. Sua organização é

ilustrada na figura 3.6, deixando para o leitor uma visão geral da metodologia, com-

posta por uma biblioteca de classes na linguagem SystemVerilog.

Figura 3.6: Organização do OVM

É um superconjunto de duas metodologias de Verificação já consolidadas na in-

2Informações obtidas através do estudo conjunto do datasheet, reference e white paper disponibilizados.


dústria: a Universal Reuse Methodology (URM) da Cadence® e a Advanced Verification

Methodology (AVM)[10] da Mentor® que são bastante similares entre si, mas sem capa-

cidade de interoperação. Sendo totalmente compatível com as ferramentas oferecidas

pela Cadence® e Mentor®, o OVM é, sem dúvida, a principal iniciativa de código

aberto feita pela indústria de EDA para padronização dos componentes de Verificação.

3.2.1 SystemVerilog

É uma linguagem proprietária derivada de Verilog (linguagem de descrição de

hardware e de Verificação), com recursos de orientação a objetos, bastante análoga à

SystemC. Sua concepção teve como motivação oferecer a Verilog a capacidade de mo-

delagem de sistemas em alto nível e mecanismos de Verificação mais integrados e efici-

entes. Foi desenvolvida pela Accellera Inc. em 2002, sendo um padrão IEEE 1800-2005.

A linguagem SystemVerilog tem sido amplamente utilizada por várias empresas

e inclui um excelente conjunto de ferramentas de Verificação, destacando-se a cober-

tura funcional e assertions que funcionam de maneira nativa. Entretanto, por ser uma

linguagem de domínio específico, ou seja, é usada exclusivamente por projetistas de

hardware, não oferece um conjunto variado de bibliotecas. Este problema é contornado

através da importação de funções diretamente de código C/C++, de forma a permitir

que funcionalidades já implementadas (como funções matemáticas ou algoritmos) não

precisem ser refeitas.

3.2.2 Arquitetura

A principal característica da arquitetura do OVM é o foco na interoperabilidade de

seus componentes, através da padronização de interfaces e configurabilidade dos com-

ponentes, além de diversas facilidades para simulação como a checagem de condições

e coleta de informações de cobertura. Maiores detalhes sobre os componentes do OVM

serão fornecidos a seguir e uma visão geral da arquitetura é dada na figura 3.7:


Figura 3.7: Arquitetura do OVM

� Virtual Sequencer: é responsável pela coordenação das sequências que serão ge-

radas nos Sequencer instanciados no ambiente, definindo a ordem de geração das

transações, criando a visão de cenário de caso de teste. Por conter informações

específicas da instância do sistema que está sendo verificado, este componente

não pode ser re-usado em outros contextos.

� Sequencer: cria as transações que irão estimular uma determinada interface do

sistema, através da geração e requisição de dados ao sistema, sendo alheios a que

contexto estão inseridos, podendo ser reusados em diversos projetos, ao contrário

do Virtual Sequencer.

� Driver: também conhecido como Bus Functional Model (BFM), o Driver é uma

entidade ativa que realiza a injeção e captura de estímulos, convertendo as re-

quisições em nível de transação (TLM) do Sequencer em estímulos baseados em

sinais e vice-versa.

� Monitor: é uma unidade passiva do ambiente de Verificação responsável pela

coleta de informações de cobertura e de checagem de dados através da extração

das informações que são transmitidas e recebidas pelo sistema. Com estas infor-

mações, as transações que serão utilizadas pelo Data Checker podem ser geradas

e a análise de cobertura funcional pode ser feita, além de possibilitar a checagem

de eventuais violações de protocolo de comunicação.

� Data Checker: é o equivalente ao Refmod e Checker do VeriSC, sendo respon-

sável tanto pela modelagem do comportamento do sistema como pela checagem

dos resultados gerados. Também é chamado de Score Board, e recebe as informa-

ções dos seus monitores associados, sendo capaz de inferir das entradas e saídas

geradas e qual deveria ser a resposta correta.


O foco em interoperabilidade de seus componentes e na análise de cobertura são os

conceitos chave do OVM, proporcionando redução do esforço na construção de ambi-

ente de Verificação e na melhoria da qualidade dos testes realizados, respectivamente.

O apoio das principais companhias de EDA do mundo torna o OVM omais impor-

tante esforço da indústria para padronização e unificação de componentes e metodo-

logias de Verificação.

3.2.3 Fluxo de atividades

Em fluxos de desenvolvimento em cascata, como é o caso onde o OVM é aplicado,

é necessário que uma atividade que precede a outra, seja completamente terminada,

para que a próxima atividade seja iniciada. Por isso, o OVM necessita de uma especifi-

cação completa e prévia do sistema que será verificado. Isto pode implicar em atrasar o

desenvolvimento do ambiente de Verificação até que a especificação e um release com-

pletos do sistema estejam disponíveis.

Outro aspecto interessante a ser notado é que o OVM não prevê nenhum meca-

nismo para validação de seus componentes3. Esta validação implícita torna ainda mais

importante a interoperabilidade de seus componentes, já que não existe ummecanismo

dedicado para validar os componentes, é fundamental que o ambiente de Verificação

possa ser construído utilizando uma biblioteca de componentes que já foram utilizados

e acreditados.

3.3 Cobertura Funcional

Esta importante técnica de análise, apesar de não figurar como uma metodologia,

possui um papel extremamente importante em ambientes de Verificação, sendo consi-

derada um dos pilares de sustentação das principais metodologias. Consiste emmedir

quais funcionalidades foram e quais não foram estimuladas, fornecendo ao engenheiro

de Verificação informações relevantes e criteriosas sobre a qualidade dos vetores de

teste que estão sendo utilizados.

3.3.1 Técnicas utilizadas

Dentre as possíveis técnicas de Cobertura Funcional, duas, consideradas mais rele-

vantes, serão explicitadas:

3A validação do componente de Verificação ocorre implicitamente através de sua utilização em di-versos projetos.


� Baseada em regras[7]: a análise é realizada através de um conjunto de regras

explícitas que precisam ser definidas pelo projetista para que a simulação seja

finalizada. Ex: Quando três endereços consecutivos de uma memória forem es-

critos, a simulação pode ser finalizada. A qualidade da definição das regras é fun-

damental para que a Cobertura Funcional e a Verificação sejam bem sucedidas.

Portanto, especial atenção deve ser empreendida durante o uso desta técnica,

para que importantes aspectos funcionais do sistema não sejam suprimidos;

� Baseada em espaço de valores[2]: esta análise se concentra em como as infor-

mações devem ser amostradas, definindo, por exemplo, se os dados devem ser

agrupados ou se devem ser considerados individualmente. Ao invés de definir a

condição de parada explicitamente, o projetista analisa os dados coletados e de-

fine em qual o momento a simulação pode ser finalizada. Ex: Quando 80% dos

endereços de memória forem acessados, a simulação pode ser finalizada. Esta

técnica possui a grande vantagem de livrar o projetista da definição de todos os

possíveis valores que deveriam gerados, deixando a análise de cobertura mais

rápida e eficiente.

Em ambas as técnicas descritas, é necessário que regras sejam definidas, baseando-

se em proposições que podem não ser necessariamente verdadeiras ou dependendo

do julgamento subjetivo das informações geradas. O impacto principal disto é ter uma

cobertura inadequada e ineficiente, permitindo que erros possam ficar mascarados.

3.4 Análise Comparativa

Um quadro comparativo, sistematizado na tabela 3.1, resume as características an-

teriormente descritas do VeriSC e do OVM, fornecendo ao leitor uma visão geral das

metodologias e de suas diferenças e semelhanças.


Característica VeriSC OVM

Fluxo dedesenvolvimento

Modelo cascata Modelo cascata

Ambiente deVerificação

executando antes doDUV

Suporte direto

Suportado, masnecessita da criação deum modelo funcional

adicionalInteroperabilidadedos componentes

Pouco suportada Suporte efetivo

Organizaçãoestrutural

Monolítico e sem umaclara distinção de

fronteiras de níveis

Em camadas parageração dos estímulos

Cobertura Funcional Baseada em regrasBaseada em espaço de

valoresLinguagem deprogramação

SystemC SystemVerilog

Tabela 3.1: Quadro comparativo do VeriSC e OVM

É interessante perceber que a comparação realizada representa a análise sobre um

ponto de vista, não representando uma verdade absoluta. Esta observação se deve ao

fato de que termos como "pouco" ou "direto" serem subjetivos e podem ser questiona-

dos pelo leitor. A idéia deste quadro comparativo é reunir as características percebidas

em ambas as metodologias, permitindo que leitor tenha todos os subsídios necessários

ao completo entendimento deste trabalho.

No próximo capítulo, que descreve a metodologia de Verificação proposta, será

mostrado que todas as vantagens que estavam disjuntas nas metodologias considera-

das, como a interoperabilidade do OVM e o ambiente de Verificação pronto antes do

DUV do VeriSC, foram unificadas em uma só metodologia. Além de unificar os pontos

fortes de cada metodologia, novas funcionalidades foram adicionadas, como o suporte

efetivo ao fluxo de desenvolvimento iterativo e incremental que não é explicitamente

suportado por nenhuma das metodologias consideradas.

Capítulo 4

Metodologia IVM

Este capítulo apresenta o IVM (acrônimo para Interoperable Verification Methodo-

logy), que foi desenvolvido no contexto deste trabalho, suportando diferentes tipos de

projetos de sistemas digitais. As seções a seguir detalham a arquitetura proposta, o

fluxo de atividades da metodologia e como foi feita sua validação através da exposição

dos estudos de caso realizados.

4.1 Arquitetura

A arquitetura do IVM foi concebida tendo em mente as virtudes e defeitos das

metodologias descritas no estado da arte, principalmente o OVM, de forma que uma

metodologia melhorada fosse obtida. As contribuições e modificações arquiteturais

propostas ficarão mais explicitas durante o decorrer da leitura desta seção e uma visão

geral pode ser vista na figura 4.1.

Figura 4.1: Arquitetura do IVM

24

CAPÍTULO 4. METODOLOGIA IVM 25

� Test Case Model: é responsável pela coordenação dos agentes que estimularão

o sistema em questão, realizando função similar ao Virtual Sequencer do OVM,

modelando a especificação dos casos de teste, permitindo que todas as funci-

onalidades fornecidas pelos agentes sejam acionadas de maneira coordenada.

Este módulo possui referências para os Agents e Monitors do ambiente através

da qual os controla, permitindo uma visão centralizada de todas as funcionali-

dades proporcionadas. Os casos de teste são implementados por extensões de

classes, permitindo assim que novos testes sejam criados com a certeza de que as

propriedades anteriores do ambiente serão mantidas. Por conter informações es-

pecíficas da instância do sistema que está sendo verificado, este componente não

pode ser re-usado em outros contextos, ou seja, na Verificação de outros módulos

ou projetos.

� Agent: concentra todas as funcionalidades de um determinado componente ex-

terno ao sistema, proporcionando ao Test Case Model um conjunto de funcio-

nalidades que poderão compor seus casos de teste através da geração e captura

de transações que irão estimular uma determinada interface do sistema. Além

dos papéis de captura e geração de transações, este componente também é res-

ponsável pela comparação das respostas recebidas com as respostas geradas pelo

Reference Model e são alheios a que contexto estão inseridos, podendo ser reusa-

dos em diversos projetos, assim como o Sequencer do OVM.

� Reference Model: é responsável por modelar idealmente o comportamento do

sistema que está sendo verificado, normalmente implementado em um nível

mais alto de abstração e sem detalhes temporais, diferentemente do Data Checker

do OVM que modela comportamento e faz checagens de respostas, o Reference

Model apenas modela o comportamento do sistema em questão, permitindo que

este componente possa ser estruturado hierarquicamente. É implementado em

nível de transação (TLM), o que facilita o enfoque na funcionalidade que se de-

seja modelar, além de permitir uma simulação bem mais rápida.

� Driver: também conhecido como Bus Functional Model (BFM), o Driver é uma en-

tidade ativa que realiza a comunicação entre interfaces RTL e TLM, convertendo

as requisições em nível de transação (TLM) do componente Agent ou Reference

Model em estímulos baseados em sinais e vice-versa.

� Monitor: é um componente do IVM responsável pela coleta de informações de

cobertura funcional e de checagem de protocolo de comunicação, funcionando

através da extração das informações (como endereços acessados ou operações re-

alizadas) que são transmitidas pelos sinais monitorados. Este módulo analisa de


cobertura utilizando as informações obtidas e verifica a conformidade do proto-

colo através de regras descritas pelo projetista.

As principais contribuições arquiteturais do IVM estão na composição das arqui-

teturas do VeriSC e do OVM, através de modificações no Reference Model (somente

modelando comportamento), permitindo construção hierárquica de novos modelos,

assim como acontece no VeriSC e não é possível no OVM. Outra contribuição está nos

Agents, que aparecem independentes de seus respectivos Drivers e Monitors, além de

assumirem a função de checagem de transações que no OVM é feita pelo Data Checker

(modela comportamento e checa transações) e no VeriSC é realizada pelo Checker.

Figura 4.2: Camadas do IVM

Camada Interface

Test Case Model

int getTotalError();void configureSeed(unsigned int seed);

void generateReport();void executeTestCase();

int getFunctionalError();int getProtocolError();double getCoverage();bool haltExecution();

Agentint getNumberOfError();

void comparator();

Monitor

void addToTraceFile(trace_file *traceFile);int getNumberOfError();

double getCoverage();void generateReport();

TLM TLM padrão (Interface, Channel, Port e Export)Reference Model Definida pela especificação do sistema

Drivervoid bindPort(INTERFACE &interface);

INTERFACE& getExport();Design Under Verification Definida pela especificação do sistema

Tabela 4.1: Interface das camadas do IVM


O requisitos de interoperabilidade e organização em camadas são satisfeitos através

da padronização dos componentes do ambiente de Verificação, permitindo que uma

interface padrão (todos os componentes de uma determinada camada deve possuir

uma interface padrão e se comunicar somente com as camadas verticalmente adjacen-

tes) seja assegurada, como pode ser visto na figura 4.2 e na tabela 4.1. Desta forma,

independentemente da origem deste componente, desde que ele seja aderente a esta

interface e organização em camadas, ele poderá ser seguramente utilizado sem necessi-

dade de modificações ou adaptações. Na parte de anexos deste documento se encontra

a biblioteca desenvolvida e sua interface como referência.

Pelo que foi mostrado na arquitetura proposta, as principais qualidades das me-

todologias do estado da arte, como ambiente executável antes do DUV e interopera-

bilidade dos componentes, continuam sendo atendidos, só que de maneira unificada,

permitindo que novas funcionalidades sejam oferecidas. As contribuições da metodo-

logia proposta ficarão mais evidentes nas seções posteriores, que descreverão seu fluxo

de atividades e estudos de caso realizados.

4.2 Fluxo de atividades

O fluxo de atividades do IVM, apesar de similar ao VeriSC[7], possui um ponto

chave que o difere: sua visão bottom-up que é oposta a do VeriSC que é top-down. No

IVM, o sistema é decomposto numa série de partes componentes e é verificado parte

por parte até que todas elas estejam integradas e validadas.

Na figura 4.3, uma visão geral do fluxo de atividades é fornecida, permitindo que

o leitor tenha a clara idéia de como as atividades estão relacionadas e quais são seus

pré-requisitos.


Figura 4.3: Visão geral do fluxo de atividades do IVM

As etapas mostradas são executadas sempre de forma iterativa e incremental, para

cada nova funcionalidade adicionada ou modificação feita, garantindo que os propó-

sitos de cada etapa sejam sempre atingidos. A sua estruturação bottom-up e seu fluxo

de atividades são as características que adequam esta metodologia em processos de

desenvolvimento iterativos e incrementais, como o ipPROCESS[5].

Os pré-requisitos necessários para todas as etapas são: a especificação completa

ou parcial do sistema; o plano de Verificação do sistema com as metas e estratégias

adotadas; e a biblioteca de componentes que serão estendidos para padronização dos

componentes. Na etapa de Sanity Checking, o foco está em demonstrar que o ambiente

funciona adequadamente e já pode ser refinado na etapa de Interface Refinement que

especializa as interfaces TLM em interfaces baseadas em sinais. Uma vez feita as che-

cagens e refinamentos, o ambiente é validado por completo na etapa de Environment

Validation e finalmente recebe o sistema que será verificado na etapa deDUV Execution.

Nas seções a seguir, maiores detalhes sobre cada uma destas etapas serão fornecidos.

4.2.1 Sanity Checking

O objetivo principal desta etapa é garantir que o ambiente possui capacidades mí-

nimas de funcionamento, como a capacidade de comunicação e detecção de erros. Para


avaliar a sanidade é desejável que um subconjunto mínimo de componentes sejam ins-

tanciados, de forma a reduzir a quantidade de variáveis que serão analisadas. Desta

forma, apenas os seguintes componentes devem ser utilizados nesta etapa: Test Case

Model, Reference Model e Agent, como pode ser visto na figura 4.4.

Figura 4.4: Etapa de checagem de sanidade

Esta é, sem dúvida, a mais importante das etapas, pelo fato de servir como base

para as próximas etapas que somente irão refinar o comportamento do ambiente. Este

refinamento ocorrerá através da criação de unidades de comunicação baseadas em si-

nais, que permitirão que interfaces TLM sejam traduzidas em sinais, além da adição

de módulos de análise de cobertura e de protocolo que irão certificar que estes sinais

estão sendo devidamente modificados.

Durante a execução desta etapa, os casos de teste, seus agentes e o modelo de refe-

rência devem ser implementados de maneira iterativa e incremental, permitindo que a

cada pequeno passo realizado, a corretude seja sempre verificada, evitando a depura-

ção de todo o ambiente no final da implementação.

4.2.2 Interface Refinement

Quando um conjunto de funcionalidades já teve sua sanidade devidamente che-

cada é a hora de refinar as interfaces de comunicação baseadas em transação (TLM)

para interfaces baseadas em sinais, com seus respectivos analisadores de protocolo e

cobertura. Neste processo novos componentes, como Driver e Monitor são inseridos, e

isto é ilustrado nas figuras 4.5 e 4.6.


Figura 4.5: Refinando interface da esquerda

Figura 4.6: Refinando interface da direita

Os componentes Driver e o Monitor respondem, respectivamente, pela tradução de

requisições TLM para estímulos baseados em sinais e vice versa e pela análise de con-

formidade de protocolo, além da coleta de dados de cobertura. No final desta etapa,

regras de cobertura são adicionadas no Monitor, permitindo que análises mais sofisti-

cadas sobre a qualidade dos casos de teste sejam realizadas.

4.2.3 Environment Validation

Uma vez verificada a sanidade e capacidade de comunicação com o Projeto em

Verificação, todos os componentes são instanciados e o comportamento do ambiente


como um todo é avaliado, antes da primeira interação com o sistema que será verifi-

cado. Isto previne que possíveis erros sejam mascarados pela interação com o Projeto

em Verificação. Esta etapa pode ser vista na figura 4.7.

Figura 4.7: Etapa de validação do ambiente

Um pseudo DUV é obtido quando ao Reference Model são plugados todos os seus

respectivos Driveres, desta forma criando, sem nenhum esforço adicional, um modelo

que representará de maneira fiel o sistema que será verificado.

Além do propósito de validação, esta etapa busca atender a um dos principais ob-

jetivos deste trabalho: ter o ambiente de Verificação pronto antes do primeiro release

do sistema que será verificado. Com isto, cria-se uma nítida independência entre o de-

senvolvimento e a Verificação do sistema, permitindo que atrasos no desenvolvimento

não sejam propagados para a Verificação.

4.2.4 DUV Execution

Ao final da execução da etapa de Environment Validation, o ambiente de Verificação

está apto a receber o sistema que será verificado sem maiores adaptações, sendo ne-

cessário somente criar e controlar fontes de clock e reset para o sistema (componente

padronizado e chamado de Clock and Reset Unit). A figura 4.8 ilustra a etapa final do

fluxo de atividades do IVM.


Figura 4.8: Etapa de execução do DUV

Nesta etapa, o pseudo DUV, que foi utilizado anteriormente, é removido e em seu

lugar o sistema (DUV) é inserido, sem necessidade de ajustes. É recomendado que esta

substituição seja feita de forma automática, buscando evitar erros e agilizar o processo.

O objetivo desta etapa é preservar o comportamento observado no pseudo DUV, ga-

rantindo assim que, para os testes realizados, o DUV é equivalente ao modelo de refe-

rência e não gerou violações em seu protocolo de comunicação. Quando esta etapa for

concluída, o DUV pode seguir para a próxima fase de seu ciclo de desenvolvimento,

como síntese lógica ou prototipação.

No capítulo de estudos de caso, os aspectos referentes a decomposição hierárquica,

que são essenciais em qualquer projeto de sistemas digitais, serão explicitados, além

de outros conceitos que ainda ficaram pendentes.

4.3 Análise de cobertura e critério de parada

Uma das questões fundamentais da Verificação reside em responder a seguinte per-

gunta: Quando eu sei que já verifiquei o sistema de maneira satisfatória? Assim como

a pergunta, que é bem direta e objetiva, deve ser a solução para o problema. A par-

tir desta necessidade surgem as técnicas de cobertura, como ferramenta que guiará o

engenheiro de Verificação na decisão de terminar suas simulações.


Figura 4.9: Comportamento da cobertura

O IVM utiliza a técnica de cobertura baseada em espaço de valores, como já foi

explicado no capítulo de estado da arte. Entretanto, a contribuição deste trabalho,

sobre esta área, reside em adicionar um novo mecanismo de decisão de parada para as

simulações, baseado no comportamento da cobertura. Como pode ser visto na figura

4.9, a cobertura sempre aumentará ou ficará constante, e após um determinado tempo,

razoavelmente grande de simulação, tenderá a se estabilizar em umdeterminado valor.

Devido a este comportamento, foi observado que melhor do que definir explicita-

mente quando a simulação pode ser finalizada, através de critérios arbitrários, seria

mais interessante e simples, definir apenas de quanto a cobertura deve ser incremen-

tada (Incremento de Cobertura) em um determinado tempo de simulação ou número

de operações (Passo de Tempo). Desta maneira, o projetista ganha uma ferramenta que

reduzirá o custo computacional de suas simulações, atingindo um determinado nível

de cobertura sem que passos desnecessários sejam executados. As fórmulas 4.1 e 4.2

(implementadas pelo algoritmo 1 em pseudo código) formalizam esta abordagem:

Delta(x, y) =∆y

∆x=

Incremento de Cobertura

Passo de Tempo(4.1)

Halt(x, y, z) =

False, Delta(x, y) > z

True, Delta(x, y) ≤ z(4.2)

onde :

x = Tempo de simulação,

y = Percentual de cobertura,

z = Critério de parada

�Incremento de Cobertura de f inida

Passo de Tempo de f inido

�


Algorithm 1 Pseudo código da análise de cobertura

// Halt functionboolean haltFunction() {// Incrementing simulator timesimulator.incrementTimeStep();// Calculating deltadeltaCoverage = (currentCoverage - lastCoverage);deltaTime = (currentTime - lastTime);// Checking if the time step was completedtimeCondition = (deltaTime > definedTimeStep);// Checking coverage increment achievementcoverageCondition = (deltaCoverage > definedCoverageIncrement);// Updating internal variables// when time step condition is satisfiedif(timeCondition) {// Updating referentialslastTime = currentTime;lastCoverage = currentCoverage;

}// Returns true (simulation halting) when the time condition was// reached and the coverage increment was not metreturn (timeCondition and (not coverageCondition));

}// Test case functionvoid testcase() {// Main loopdo {//// Test case code//

}// Checking if halt condition was achievedwhile(not haltFunction());// Finishing simulationsimulator.finish();

}

Este conceito é bastante similar ao cálculo derivativo1, permitindo que estimativas

sobre a taxa de crescimento de cobertura sejam feitos e determinando previamente

quando mais passos de simulação não irão produzir resultados significativos. Com

esta nova abordagem, o critério de parada para as simulações se reduz a definir de

quanto a cobertura da simulação deve incrementar em um determinado espaço de

tempo.

Para exemplificar os resultados desta técnica, um exemplo de análise de cobertura

1O termo matemático para o segmento (função Delta 4.1) que cruza dois ou mais pontos do gráfico(cuja inclinação indica o crescimento da cobertura em função do tempo) é a reta secante.


de umamemória do tipo ROM (somente leitura) será utilizado. Primeiramente, define-

se que o critério de parada é: 3 vetores de teste (Passo de Tempo) e qualquer incremento

positivo e não nulo da cobertura (Incremento da Cobertura), ou seja, a cada 3 tran-

sações executadas a cobertura será amostrada e o seu incremento deve ser maior do

que zero para que a simulação não seja terminada. Os endereços desta memória estão

sendo acessados aleatoriamente e cada operação distinta (endereço diferente acessado)

realizada contribui para o incremento do percentual de cobertura, ou seja, endereços já

acessados não modificam a cobertura. Desta forma, existe um determinado momento,

que só será conhecido em tempo de simulação, em que três vetores de teste serão repe-

tidos, causando a finalização simulação e geração dos relatórios de cobertura (contendo

informações sobre quais vetores foram gerados e quais não foram).

Por fim, o projetista, analisando os relatórios gerados, verifica se algum vetor rele-

vante não foi gerado ou se vetores demais foram gerados, e aprova ou rejeita o critério

de parada de simulação escolhido. É importante lembrar ao leitor que o critério de pa-

rada de simulação não é equivalente ao critério de parada da Verificação. O término da

Verificação é sempre decido pelo projetista, tomando como base a análise dos relatórios

gerados e dos requisitos definidos pelo Plano de Verificação.

Capítulo 5

Estudos de caso

Neste capítulo, todos os resultados experimentais realizados serão detalhados, de

forma a demonstrar que o trabalho proposto de fato atender aos requisitos propostos

e colabora construtivamente sobre o estado da arte considerado.

Foram desenvolvidos três estudos de caso, com características e complexidades

bem diversas, de forma a explorar de maneira mais abrangente possível os diversos

cenários em que este trabalho poderia estar inserido. São estes estudos de caso: uma

memória com duas portas (Dual Port Memory), um roteador OCP-IP (OCP-IP Router)

e um sistema de Controle Automático de Iluminação Pública (CAIP).

5.1 Estudo de Caso: Dual Port Memory

Este estudo de caso é uma memória com duas interfaces de comunicação que per-

mite acesso concorrente e paralelo ao seu conteúdo, tanto para operações de leitura

e como de escrita. Esta memória possui um caráter de uso genérico, entretanto, para

tornar mais intuitivo o entendimento do leitor, foi construído um cenário de uso onde

a mesma funciona como área de compartilhamento de informações entre dois proces-

sadores genéricos.

Este estudo de caso tem como principais objetivos: a validação da metodologia

para projetos de controle, como processadores e memórias; a demonstração da re-

usabilidade horizontal (dentro do mesmo nível hierárquico) e vertical (em diferentes

níveis hierárquicos) dos componentes de Verificação; e ilustração do fluxo de ativida-

des se aplica a projetos com múltiplos níveis de hierarquia.

5.1.1 Arquitetura

Nesta seção, a arquitetura do componente Dual Port Memory será ilustrada, de

forma a permitir ao leitor uma visão geral das partes que compõe este sistema e como

estas partes estão conectadas.

36

CAPÍTULO 5. ESTUDOS DE CASO 37

Figura 5.1: Arquitetura do Dual Port Memory

Amemória é composta por três partes: uma unidade de controle de acesso (Mutex)

que previne condições de corrida; duas unidades de interfaces (Interface 1 e 2) para

receber e responder as requisições; e a memória (Memory) propriamente dita que irá

armazenar e carregar os dados. Na figura 5.1, a hierarquia destas partes e a como estão

conectadas fica explícita.

5.1.2 Aplicando o IVM

A aplicação da metodologia IVM para verificar o componente Dual Port Memory

tem como duas macro etapas: a definição da arquitetura do ambiente de Verificação e

a execução do fluxo de atividades.

A definição da arquitetura do ambiente é basicamente feita escolhendo que parte

do componente que será estimulada e que agentes externos criarão e capturarão os

estímulos gerados. O cenário de uso desta memória, para este estudo de caso, é a

sua utilização como região de compartilhamento de dados entre dois processadores

genéricos, que chamaremos de Processor 1 e Processor 2. Este cenário é ilustrado na

figura 5.2.

Figura 5.2: Cenário de uso do Dual Port Memory

Normalmente, todas as partes funcionais do componente devem ser verificadas e

devido a isto todas as três unidades que compõem do Dual Port Memory e suas possí-

veis combinações devem ser verificadas, como pode ser visto nas figuras 5.3, 5.4, 5.5 e

5.6.


Figura 5.3: Cenário da Memory

O cenário de Verificação da Memory é caracterizado pela existência de apenas um

ator externo que é o Mutex, verificando se o componente Memory está realizando sua

função de armazenamento de dados.

Figura 5.4: Cenário do Mutex

A Verificação do Mutex tem como objetivo principal certificar que este componente

está desempenhando adequadamente suas funções de controle de concorrência que

mantem o conteúdo da memória coerente para ambas as interfaces.

Figura 5.5: Cenário da Memory e Mutex

Um vez já tendo sido devidamente verificados, os componentes Memory e Mutex


podem ser integrados, e novos testes serão realizados, visando, principalmente garan-

tir que esta composição conserva o comportamento individual dos componentes.

Figura 5.6: Cenário da Interface

A principal funcionalidade do componente Interface está em converter as requisi-

ções de um agente externo, como um processador, para a unidade que irá tratar os

problemas de acesso concorrente.

Uma vez definidos os cenários, a execução do fluxo consiste, para qualquer arqui-

tetura definida, em tornar funcional o ambiente de Verificação e fornecer um conjunto

de passos que otimizem o esforço empreendido. Por ser uma metodologia bottom-up,

o IVM orienta que os níveis mais baixos de hierarquia sejam verificados primeiro.

Devido a esta orientação, os subcomponentes Mutex e Memory são verificados in-

dividualmente e depois em conjunto, antes do subcomponente Interface que está num

nível hierárquico mais elevado. Por fim, o componente é verificado com todas as suas

partes componentes, consistindo no estágio final do processo de Verificação.

5.1.2.1 Memory

Esta seção é dedicada a detalhar a aplicação do fluxo de atividades do IVM sobre

o componente Memory que compõe a arquitetura do estudo de caso Dual Port Memory.

Na Verificação deste componente foram desenvolvidos três casos de teste que fazem

leituras, escritas e combinações de leitura e escritas (caso de teste randômico), todas de

maneira aleatória.


Figura 5.7: Sanity Checking de Memory

Componente Número de linhas de código Percentual de re-uso

Test Case Model Memory 40 0%Agent Mutex 26 0%

Reference Model Memory 14 0%

Total de linhas 80 0%

Tabela 5.1: Detalhes da etapa de Sanity Checking de Memory

Na aplicação do fluxo de atividades para instância Memory, durante a etapa de Sa-

nity Checking, que é ilustrada na figura 5.7, foram implementadas as funcionalidades

que se desejam verificar no Reference Model Memory, foi feita a codificação dos casos de

teste no Test Case Model Memory e foi implementado o Agent Mutex que cria, captura e

compara as transações. Também foi necessário que um arquivo principal, que instan-

ciasse todos os componentes, fosse criado, além dos canais e portas TLM que fazem a

comunicação entre os módulos. Os detalhes referentes aos módulos implementados e

seus percentuais de re-uso são sumarizados na tabela 5.1.

Por ainda não possuir, nesta etapa de Sanity Checking, o componente responsável

pela análise de cobertura (Monitor Mutex), o critério de parada desta etapa se baseia

em alguma regra definida pelo projetista, como um determinado tempo de simulação

ou umnúmero específico de iterações (foi definido que este número de iterações seriam

100 vetores gerados).


Figura 5.8: Interface Refinement de Memory


Test Case Model Memory 40 100%Agent Mutex 26 100%

Reference Model Memory 14 100%Driver Mutex 46 0%Monitor Mutex 22 0%

Total de linhas 148 54.05%

Tabela 5.2: Detalhes da etapa de Interface Refinement de Memory

Após a validação do modelo de referência e de seus casos de teste associados, du-

rante a etapa de Sanity Checking, foi feita a implementação dos módulos que são res-

ponsáveis pela tradução das transações em estímulos baseados em sinais e vice-versa

(Driver) e checagem de protocolo e análise de cobertura (Monitor). Esta etapa é cha-

mada de Interface Refinement e é mostrada na figura 5.8. Por se tratar de um refina-

mento, todos os componentes da etapa anterior foram re-usados, como está sumari-

zado na tabela 5.2.


Figura 5.9: Environment Validation de Memory

Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados

Leitura 45,33% 2.203Escrita 57,82% 1.872

Randômico 72,46% 6.382

Geral 58,54% 10.457

Tabela 5.3: Detalhes da etapa de Environment Validation de Memory

Uma vez finalizados todos os componentes do ambiente de Verificação, é necessá-

rio testá-los de forma integrada, executar os casos de teste definidos e analisar sua co-

bertura, através da etapa de Environment Validation (ver figura 5.9 e tabela 5.3). Nesta

etapa foram instanciados todos os mesmos componentes da etapa de Interface Refi-

nement, proporcionando um pseudo componente Memory que se comportou como o

componente Memory.

Com a implementação do componente Monitor Mutex e a etapa de Environment Va-

lidation, os casos de teste adotaram um novo critério de parada: a cada 3 vetores de

teste gerados, a cobertura deve apresentar algum incremento positivo e não nulo em

seu percentual. Caso este critério não fosse satisfeito, a simulação era finalizada e os

relatórios de cobertura eram gerados.


Figura 5.10: DUV Execution de Memory

Concluídas todas as etapas de preparação, o módulo Memory foi finalmente ins-

tanciado e seu comportamento foi verificado, durante a execução da etapa de DUV

Execution, ilustrada na figura 5.10. Foi nesta etapa que os erros foram encontrados

e que o comportamento do sistema foi confrontado com sua especificação através da

execução dos casos de teste.

5.1.2.2 Mutex

Nesta seção, será descrito como o componente Mutex, que pertence ao estudo de

caso Dual Port Memory, foi verificado, através da aplicação do fluxo de atividades da

metodologia IVM. Nesta instância do estudo de caso foram feitos cinco casos de teste

randômicos que realizam leituras simples (sem concorrência), escritas simples (sem

concorrência), leituras simultâneas (com concorrência), escritas simultâneas (com con-

corrência), combinações leituras e escritas simples e simultâneas (caso de teste randô-

mico).


Figura 5.11: Sanity Checking de Mutex


Test Case Model Mutex 40 0%Agent Interface 33 0%Agent Memory 21 0%

Reference Model Mutex 54 0%


Tabela 5.4: Detalhes da etapa de Sanity Checking de Mutex

A etapa inicial do fluxo de atividades do IVM consistiu em aplicar o Sanity Chec-

king para o Mutex, que é ilustrado na figura 5.11. Nesta etapa as funcionalidades que

deveriam verificadas foram modeladas no Reference Model Mutex e os casos de teste

associados foram adicionados ao Test Case Model Mutex. Os Agent Interface e Agent Me-

mory são responsáveis pela geração, captura e checagem das transações do ambiente.

Os detalhes referentes ao esforço de implementação e seus percentuais de re-uso estão

sumarizados na tabela 5.4.

Pelo fato de não possuir o componente responsável pela análise de cobertura (Mo-

nitor), o projetista precisa definir um critério de parada baseado em alguma regra (100

vetores de teste gerados foi a regra escolhida), como tempo de simulação ou mesmo o

número de transações que devem ser executadas para que a simulação seja finalizada.


Figura 5.12: Interface Refinement de Mutex


Test Case Model Mutex 74 100%Agent Interface 33 100%Agent Memory 21 100%

Reference Model Mutex 54 100%Driver Interface 22 0%Driver Memory 31 0%Monitor Interface 43 0%Monitor Memory 31 0%


Tabela 5.5: Detalhes da etapa de Interface Refinement de Mutex

Assim que as funcionalidades foram modeladas no componente Reference Model

Mutex, os casos de teste foram implementados no Test Case Model Mutex e os Agent In-

terface e Agent Memory foram testados, a interface com o DUV precisou ser implemen-

tada e verificada também. Esta demanda foi atendida pela etapa de Interface Refinement


(arquitetura ilustrada na figura 5.12) que refinou a comunicação em alto nível TLM em

estímulos de baixo nível baseados em sinais, através dos componentes Driver Interface,

Driver Memory, Monitor Interface e Monitor Memory. Os detalhes referentes à complexi-

dade e re-usabilidade dos componentes utilizados estão sumarizados na tabela 5.5.

Figura 5.13: Environment Validation de Mutex


Leitura simples 55,13% 1.535Escrita simples 47,82% 1.452

Leitura simultânea 59,74% 1.987Escrita simultânea 58,29% 2.543


Geral 56,98% 15.351

Tabela 5.6: Detalhes da etapa de Environment Validation de Mutex

Uma vez tendo sido todos os componentes devidamente validados, foi feita a inte-

gração de todos eles, o que proporcionou um pseudo Mutex (composto pelo Reference

Model Mutex, pelo Driver Interface e pelo Driver Memory) durante a etapa de Environ-

ment Validation, como pode ser visto na figura 5.13. O objetivo principal desta etapa


foi de garantir que o ambiente de Verificação funcionará de maneira correta quando o

Mutex for instanciado, utilizando os mesmos componentes da etapa anterior de Inter-

face Refinement. Isto foi feito através da execução dos casos de teste implementados e

da análise da cobertura obtida (detalhes na tabela 5.6), visto que estava disponível um

pseudo componente Mutex que permitiu estas operações.

Com a disponibilidade dos Monitor Interface e Monitor Memory, foi possível rede-

finir o critério de parada para que a cada 3 vetores de teste gerados o percentual de

cobertura sofra um incremento positivo e não nulo. Isto significou que a cada 3 vetores

gerados o percentual de cobertura precisava aumentar, pois caso contrário a simulação

seria finalizada.

Figura 5.14: DUV Execution de Mutex

Para finalizar, o componente Mutex foi instanciado e suas interfaces foram estimu-

ladas em busca de falhas, durante a etapa de DUV Execution (ilustrada na figura 5.14).

Ao ter sido iniciada esta etapa, tendo a premissa de que as etapas anteriores foram

devidamente cumpridas, o projetista teve uma alta confiança em seu ambiente, o que

foi confirmado pelo baixíssimo índice de falhas do ambiente de Verificação.

5.1.2.3 Memory e Mutex (MemoryMutex)

Esta seção se dedica à aplicação do fluxo de atividades sobre o componentes Me-

mory e Mutex integrados (MemoryMutex), que compõem a arquitetura do estudo de

caso Dual Port Memory, além de ressaltar a importância desta instância na ilustração


dos aspectos de hierarquia e de re-usabilidade de componentes. Para verificar este

componente foram implementados três casos de teste que realizam leituras e escritas

simples (sem concorrência), leituras e escritas simultâneas (com concorrência) e com-

binações de leituras e escritas simples e simultâneas (caso de teste randômico).

Figura 5.15: Sanity Checking de MemoryMutex


Test Case ModelMemoryMutex

64 0%

Agent Interface 33 100%Reference ModelMemoryMutex

68 100%

Total de linhas 165 61,21%

Tabela 5.7: Detalhes da etapa de Sanity Checking de MemoryMutex

Na aplicação da etapa de Sanity Checking com o componente MemoryMutex, que é

ilustrada na figura 5.15, foram implementadas as funcionalidades que se deseja veri-

ficar no Reference Model MemoryMutex (construído a partir do Reference Model Memory

e Mutex), no Agent Interface (re-utilizado da Verificação de Mutex) e no Test Case Model

MemoryMutex (detalhes disponíveis na tabela 5.7). O arquivo topo foi implementado e

instanciou todos os componentes, conectando-os através de suas interfaces TLM.

Apesar de ter disponível o componente Monitor Interface, ainda não era o momento

para que o mesmo fosse instanciado e a coleta de informações de cobertura pudesse

ser feita. Por isto, o critério de parada (100 vetores de teste como condição de parada)

precisava ser definido como uma regra qualquer que seria substituída na etapa de

Environment Validation quando a cobertura seria implementada.


Figura 5.16: Interface Refinement de MemoryMutex


Test Case ModelMemoryMutex

64 100%

Agent Interface 33 100%Reference ModelMemoryMutex

68 100%

Driver Interface 22 100%Monitor Interface 43 100%


Tabela 5.8: Detalhes da etapa de Interface Refinement de MemoryMutex

Após a consistência do ambiente ter sido verificada, a etapa de Sanity Checking foi

finalizada e a etapa de Interface Refinement foi iniciada, como é ilustrado na figura 5.16.

Os módulos responsáveis pela tradução das transações em estímulos baseados em si-

nais e vice-versa (Driver Interface re-utilizado da Verificação de Mutex) e checagem de

protocolo e análise de cobertura (Monitor Interface re-utilizado da Verificação deMutex)

foram instanciados (detalhes sobre os componentes e seu re-uso estão sumarizados na

tabela 5.8).


Figura 5.17: Environment Validation de MemoryMutex


Leitura/Escrita simples 39,72% 2.097Leitura/Escrita simultânea 61,23% 5.134

Randômico 78,92% 13.452

Geral 59,97% 20.683

Tabela 5.9: Detalhes da etapa de Environment Validation de MemoryMutex

Após a finalização de todos os componentes do ambiente de Verificação, foi ne-

cessário testar a integração entre eles, através da etapa de Environment Validation (ver

figura 5.17) que instanciou todos os componentes, e simulou o comportamento de Me-

moryMutex através de um pseudo componente. Com a redefinição do critério de pa-

rada (3 vetores e incremento positivo e não nulo do percentual de cobertura) foi possí-

vel extrair uma série de informações que estão sumarizadas na tabela 5.9.


Figura 5.18: DUV Execution de MemoryMutex

Por fim, o pseudo componente MemoryMutex que foi utilizado para validação do

ambiente foi removido e o componenteMemoryMutex foi colocado em seu lugar. Nesta

etapa de DUV Execution (ilustrada na figura 5.18) os casos de teste foram executados e

os erros encontrados foram corrigidos. A finalização desta etapa ocorreu quando todos

os testes não mais acusaram erros.

5.1.2.4 Interface

Nesta seção, será ilustrado como o componente Interface foi verificado através da

aplicação do fluxo de atividades da metodologia e o leitor poderá perceber mais uma

vez a re-usabilidade de componentes implementados na Verificação de outros com-

ponentes de DualPortMemory. Para esta instância deste estudo de caso foram imple-

mentados três casos de teste que realizam leituras, escritas e combinações de leitura e

escrita (caso de teste randômico).

Figura 5.19: Sanity Checking de Interface



Test Case Model Interface 38 0%Agent Mutex 26 100%

Agent Processor 23 0%Reference Model Interface 43 0%


Tabela 5.10: Detalhes da etapa de Sanity Checking de Interface

A aplicação do Sanity Checking para o módulo Interface, que é ilustrado na figura

5.19, tinha como metas principais: a modelagem das funcionalidades de Interface no

Reference Model Interface, a implementação dos casos de teste especificados no Test Case

Model Interface, a instanciação doAgent Mutex que estava sendo re-usado e a implemen-

tação do Agent Processor. Os detalhes referentes à complexidades destes componentes

e do esforço de implementação estão sumarizados na tabela 5.19.

Como ainda não existia osmecanismos de cobertura, foi necessário definir um crité-

rio de parada arbitrário (100 vetores de teste) que permitisse ao ambiente de Verificação

finalizar suas simulações de forma automática.

Figura 5.20: Interface Refinement de Interface



Test Case Model Interface 38 100%Agent Mutex 26 100%

Agent Processor 23 100%Reference Model Interface 43 100%

Driver Mutex 22 100%Driver Processor 21 0%Monitor Mutex 43 100%

Monitor Processor 13 0%


Tabela 5.11: Detalhes da etapa de Interface Refinement de Interface

Uma vez terminados os testes de sanidade do ambiente, a interface com o DUV foi

refinada e verificada. Na etapa de Interface Refinement (arquitetura ilustrada na figura

5.20) ocorreu a implementação dos componentes Driver Mutex (re-utilizado da Verifi-

cação de Memory) e Driver Processor que traduzem a comunicação TLM em em sinais

e vice-versa, além da implementação dos componentes Monitor Mutex (re-utilizado da

Verificação de Memory) e Monitor Processor que coletaram informações de cobertura e

fizeram checagem de protocolo (detalhes sumarizados na tabela 5.20).

Figura 5.21: Environment Validation de Interface



Leitura 57,23% 1.788Escrita 59,76% 1.734


Geral 61,60% 8.345

Tabela 5.12: Detalhes da etapa de Environment Validation de Interface

Completada a validação dos componentes, todos eles foram integrados, fornecendo

um pseudo componente Interface (composto pelo Reference Model Interface,Driver Mutex

e Driver Processor) na etapa de Environment Validation, como pode ser visto na figura

5.21. O propósito desta etapa foi assegurar que o ambiente de Verificação estava apto

a estimular corretamente a instância do componente Interface.

Com a instanciação dos componentesMonitor Mutex eMonitor Processor foi possível

obter informações de cobertura, o que possibilitou a redefinição do critério de parada

que seria baseado no crescimento da cobertura que precisava ser sempre positivo e

não nulo a cada 3 vetores de teste gerados. As informações obtidas nas análises foram

sumarizadas na tabela 5.21.

Figura 5.22: DUV Execution de Interface

No final do fluxo de atividades, o módulo Interface foi instanciado e suas interfaces

foram estimuladas em busca de falhas, durante a etapa de DUV Execution (ilustrada

na figura 5.22). Como as etapas anteriores foram cumpridas com êxito, o engenheiro

tinha um ambiente confiável e boa parte dos erros encontrados eram relativos ao com-

ponente Interface e não ao ambiente.


5.1.2.5 Dual Port Memory (DualPortMemory)

Seguindo o fluxo bottom-up do IVM, quando todas as partes componentes de umde-

terminado sistema foram verificadas, o sistema como um todo já pode ser verificado.

A grande vantagem ilustrada neste exemplo é que praticamente todos os componentes

já foram implementados, restando ao engenheiro somente a implementação dos casos

de teste que são quatro: leitura de dados após escrita feita pelo outro processador, es-

crita de dados seguida pela leitura do outro processador, leitura e escrita concorrentes

e combinações dos casos de teste anteriores (caso de teste randômico).

Figura 5.23: Sanity Checking de DualPortMemory


Test Case ModelDualPortMemory

38 0%

Agent Processor 23 100%Reference ModelDualPortMemory

111 100%


Tabela 5.13: Detalhes da etapa de Sanity Checking de DualPortMemory

A etapa de Sanity Checking instanciou o módulo Reference Model DualPortMemory

(que é composto pelo Reference Model Memory, Mutex e Interface), o Agent Processor (im-

plementado na Verificação de Interface) e implementou os casos de teste em Test Case

Model DualPortMemory, como pode ser visto na figura 5.23. Os detalhes sobre cada

componente e sua re-usabilidade estão sumarizados na tabela 5.13.

Mais uma vez, apesar da disponibilidade doMonitor Processor para realizar a coleta

de informações sobre cobertura, foi necessária a definição de um critério de parada

(100 vetores de teste gerados) mais simples e que permitisse a finalização automática

das simulações. Este critério será redefinido na etapa de Environment Validation que é

detalhada a seguir.


Figura 5.24: Interface Refinement de DualPortMemory


Test Case ModelDualPortMemory

38 100%

Agent Processor 23 100%Reference ModelDualPortMemory

111 100%

Driver Processor 21 100%Monitor Processor 13 100%


Tabela 5.14: Detalhes da etapa de Interface Refinement de DualPortMemory

Uma vez terminada a implementação dos casos de teste e verificada a sanidade do

ambiente, as interfaces foram refinadas através da instanciação dos módulos Driver

Processor e Monitor Processor que já foram implementados na Verificação de Interface.

Por re-utilizar componentes que já foram validados, esta etapa de Interface Refinement

(ilustrada na figura 5.24) se resume a verificar se os mesmos foram devidamente ins-

tanciados e conectados e coletar informações sobre os componentes, como pode ser

visto na tabela 5.14.


Figura 5.25: Environment Validation de DualPortMemory


Leitura após escrita 57,37% 11.300Escrita seguida de leitura 48,75% 10.843

Leitura/Escrita concorrentes 63,74% 13.243Randômico 72,34% 31.834

Geral 60,55% 67.220

Tabela 5.15: Detalhes da etapa de Environment Validation de DualPortMemory

A etapa de Environment Validation, que pode ser vista na figura 5.25, verificou se a

ordenação das sequências geradas pelo componente Test Case Model DualPortMemory

estavam corretas e se o comportamento esperado estava sendo obtido. Nesta etapa

o critério de parada foi redefinido para levar em conta os dados obtidos da análise de

cobertura (a cada 3 vetores de teste o percentual de cobertura precisa sofrer incrementa-

ção positiva e não nula), derivando numa série de informações que foram sumarizadas

na tabela 5.15.


Figura 5.26: DUV Execution de DualPortMemory

No final de todo o processo, na etapa de DUV Execution (ilustrada na figura 5.26),

o módulo DualPortMemory foi finalmente instanciado com todas as suas parte compo-

nentes, que foram verificadas individualmente, e teve seu comportamento verificado.

Este sistema só foi aprovado pela Verificação quando nenhuma de suas partes compo-

nentes e quaisquer combinações delas apresentavam falhas em aberto, sendo o tempo

total consumido para realização deste estudo de caso igual a 40 horas.

5.2 Estudo de Caso: OCP-IP Router

O OCP-IP Router é um roteador simples que utiliza o protocolo Open Core Protocol

(OCP-IP). O cenário de uso deste componente ilustra a sua utilização para realizar

comunicação entre três dispositivos conectados a este roteador.

Este estudo de caso tem como principal objetivo a validação da metodologia para

projetos de fluxo de dados ou processamento digital de sinais, como roteadores e sis-

temas de áudio e vídeo.

5.2.1 Arquitetura

O roteador OCP-IP é composto por duas partes: três unidades de interfaces OCP-IP

(Interface 1, 2 e 3) para comunicação mestre e escravo; e uma unidade de roteamento

(Routing Unit) que indica como as requisições devem ser mapeadas. A figura 5.27,

ilustra a hierarquia destas partes e como as mesmas estão conectadas.


Figura 5.27: Arquitetura do OCP-IP Router


O uso do IVM na Verificação do OCP-IP Router tem duas macro etapas: a definição

da arquitetura e a execução do fluxo de atividades.

A arquitetura é definida através da escolha do componente ou subcomponente que

será estimulado e que agentes externos proverão e capturarão os estímulos criados.

Como foi dito anteriormente, o cenário de uso deste roteador é como controlador de

comunicação entre três dispositivos, que chamaremos de Device 1, 2 e 3. Este cenário é

ilustrado na figura 5.28.

Figura 5.28: Cenário de uso do OCP-IP Router

Em geral, todas as unidades funcionais devem ser verificadas, de forma a evitar

que erros não sejam detectados. Devido a isto, os dois subcomponentes que compõem

o OCP-IP Router serão verificados, como pode ser visto nas figuras 5.29 e 5.30.


Figura 5.29: Cenário do Routing Unit

No cenário de teste do módulo Routing Unit, três atores figuram como possíveis

interfaces OCP-IP que por ele serão controladas, como pode ser visto na figura 5.29.

Figura 5.30: Cenário do OCP-IP Interface

O cenário do módulo Interface ilustra a interação deste componente com um dispo-

sitivo genérico, tendo suas funcionalidades sendo controladas pelo Routing Unit, como

pode ser visto na figura 5.30.

Quando definidos os cenários, a execução do fluxo de atividades tem como prin-

cipal objetivo, para qualquer arquitetura definida, obter um ambiente de Verificação

operacional, além de prover uma série de passos que reduzam o tempo de projeto. De-

vido a sua abordagem bottom-up, o IVM propõe que os níveis mais baixos de hierarquia

sejam verificados antes dos níveis de hierarquia superiores.

Considerando este fluxo de Verificação, os subcomponentes Routing Unit e OCP-IP

Interface foram verificados individualmente e, depois, a instância topo, que é o módulo

OCP-IP Router, foi verificado.

5.2.2.1 Routing Unit (RoutingUnit)

Esta seção ilustra como, o fluxo de atividades do IVM foi aplicado na instância Rou-

tingUnit que pertence ao componente OCPIPRouter que terá sua Verificação mostrada

posteriormente. Nesta instância deste estudo de caso foram realizados quatro casos


de teste que acessavam somente a interface 1, acessavam a interface 2, acessavam a

interface 3 e uma combinação de acesso as três interfaces (caso de teste randômico).

Figura 5.31: Sanity Checking de RoutingUnit


Test Case ModelRoutingUnit

77 0%

Agent Interface 23 0%Reference ModelRoutingUnit

396 0%


Tabela 5.16: Detalhes da etapa de Sanity Checking de RoutingUnit

A aplicação do Sanity Checking para o módulo RoutingUnit, que é ilustrado na fi-

gura 5.31, teve como metas principais: a modelagem do Reference Model Interface, a

implementação do Agent Interface e a implementação dos casos de teste associados no

Test Case Model Interface. Os detalhes referentes aos módulos e o nível de re-uso obtido

nesta etapa estão sumarizados na tabela 5.16.

Por ainda não disponibilizar o componente Monitor Interface que foi implementado

em uma etapa posterior, um critério de parada foi definido utilizando alguma regra

arbitrária (o número de vetores de teste aplicados igual a 100) para cada caso de teste,

para que a simulação fosse finalizada automaticamente.


Figura 5.32: Interface Refinement de RoutingUnit


Test Case ModelRoutingUnit

77 100%

Agent Interface 23 100%Reference ModelRoutingUnit

396 100%

Driver Interface 23 0%Monitor Interface 24 0%


Tabela 5.17: Detalhes da etapa de Interface Refinement de RoutingUnit

Assim que as funcionalidades e os casos de teste foram implementados, a interface

com o DUV foi implementada e verificada. Esta demanda foi atendida pela etapa de

Interface Refinement (arquitetura ilustrada na figura 5.32) que refina a comunicação em

alto nível TLM em estímulos de baixo nível baseados em sinais, através dos componen-


tesDriver Interface eMonitor Interface. Os detalhes deste refinamento estão sumarizados

na tabela 5.17.

Figura 5.33: Environment Validation de RoutingUnit


Acesso a interface 1 55,43% 1.392Acesso a interface 2 53,92% 1.562Acesso a interface 3 49,83% 1.293


Geral 57,73% 10.589

Tabela 5.18: Detalhes da etapa de Environment Validation de RoutingUnit

Completada a validação dos componentes (resultados relativos a cobertura e veto-

res de teste estão sumarizados na tabela 5.18), um pseudo DUV (composto pelo Refe-

rence Model RoutingUnit e Driver Interface) foi utilizado na etapa de Environment Vali-

dation para emular o comportamento do módulo RoutingUnit, como pode ser visto na

figura 5.33. O propósito desta etapa foi assegurar que o ambiente de Verificação es-

tava apto a estimular corretamente a instância do componente RoutingUnit, através de

testes de integração, execução dos casos de teste e análise de cobertura.


Com a implementação do Monitor Interface e a etapa de Environment Validation, os

casos de testes utilizaram um novo critério de parada baseado na cobertura que define

que a cada 3 vetores de teste o percentual de cobertura precisa aumentar. Caso esta

condição não fosse atendida a simulação seria finalizada e os relatórios de cobertura

seriam gerados.

Figura 5.34: DUV Execution de RoutingUnit

Finalmente, o módulo RoutingUnit foi instanciado e suas interfaces foram estimula-

das em busca de falhas, durante a etapa deDUV Execution (ilustrada na figura 5.34). Ao

iniciar esta etapa, tendo como premissa que as etapas anteriores foram devidamente

cumpridas, o projetista tinha bastante confiança nos componentes de Verificação, e esta

confiança foi confirmada pelo fato da maioria dos erros encontrados não pertencerem

ao ambiente de Verificação e sim ao próprio DUV.

5.2.2.2 OCP-IP Interface (Interface)

Esta seção ilustra a Verificação do componente Interface, que pertence ao estudo

de caso OCP-IP Router, e foi verificado através da aplicação do fluxo de atividades

da metodologia IVM. Para este componente foram especificados três casos de teste

que realizam leitura de dispositivo, escrita de dispositivo e combinação de leituras e

escritas (caso de teste randômico).


Figura 5.35: Sanity Checking de OCP-IP Interface


Test Case ModelInterface

135 0%

Agent Device 61 0%Agent RoutingUnit 63 0%Reference Model

Interface435 0%


Tabela 5.19: Detalhes da etapa de Sanity Checking de Interface

A etapa de Sanity Checking implementou o componente Reference Model Interface, o

componente Agent Device e componente Agent RoutingUnit e modelou os casos de teste

no componente Test Case Model Interface, como pode ser visto na figura 5.35 e detalhado

na tabela 5.19.

Pelo fato de ainda não possuir nenhum Monitor que é responsável pela análise de

cobertura, o critério de parada (número de vetores de teste igual a 100) se baseou na

definição do número de passos que precisavam ser realizados para que simulação fosse

finalizada.


Figura 5.36: Interface Refinement de OCP-IP Interface


Test Case ModelInterface

135 100%

Agent Device 61 100%Agent RoutingUnit 63 100%Reference Model

Interface435 100%

Driver Device 55 0%Driver RoutingUnit 67 0%Monitor Device 64 0%

Monitor RoutingUnit 57 0%


Tabela 5.20: Detalhes da etapa de Interface Refinement de Interface

Uma vez terminados os testes de sanidade do ambiente, a interface com o DUV foi

refinada e verificada. Na etapa de Interface Refinement (arquitetura ilustrada na figura

5.36 e detalhes sumarizados na tabela 5.20) foram implementados os componentesDri-

ver Device eDriver RoutingUnit que traduzem a comunicação TLM em em sinais e vice-

versa, além da implementação dos componentes Monitor Device e Monitor RoutingUnit

que coletaram informações de cobertura e fizeram a checagem de protocolo.


Figura 5.37: Environment Validation de OCP-IP Interface


Leitura de dispositivo 54,83% 2.109Escrita de dispositivo 49,74% 2.378


Geral 55,84% 9.421

Tabela 5.21: Detalhes da etapa de Environment Validation de Interface

Após a finalização de todos os componentes do ambiente de Verificação, foi ne-

cessário testar integração entre eles, através da etapa de Environment Validation que

instanciou todos os componentes desenvolvidos, e simulou o comportamento do com-

ponente Interface através do pseudo componente destacado na figura 5.37. Estes testes

foram realizados utilizando os casos de teste já implementados e os resultados obtidos

estão sumarizados na tabela 5.21.

Com a instanciação dos componentesMonitor Device eMonitor RoutingUnit foi pos-

sível redefinir o critério de parada para levar em conta as informações de cobertura

e o que foi feito foi definir que a cada 3 vetores de teste executados o percentual de

cobertura precisaria ser incrementado, para que a simulação não fosse finalizada.


Figura 5.38: DUV Execution de OCP-IP Interface

Por fim, o pseudo componente Interface utilizado para validação do ambiente foi

removido e o componente Interface foi colocado em seu lugar. Nesta etapa de DUV

Execution (ilustrada na figura 5.38) os casos de teste foram executados e os todos os

erros encontrados foram corrigidos.

5.2.2.3 OCP-IP Router (OCPIPRouter)

Seguindo o fluxo bottom-up do IVM, quando todos as partes componentes de um

determinado sistema foram verificadas, o sistema como um todo já pode ser verificado.

A grande vantagem ilustrada neste exemplo é que praticamente todos os componen-

tes já foram implementados, restando ao engenheiro somente o desenvolvimento dos

casos de teste que foram quatro: comunicação através do dispositivo 1, comunicação

através do dispositivo 2, comunicação através do dispositivo 3 e combinação das co-

municações com os dispositivos (caso de teste randômico).


Figura 5.39: Sanity Checking de OCP-IP Router


Test Case ModelOCPIPRouter

378 0%

Agent Device 61 100%Reference ModelOCPIPRouter

831 100%


Tabela 5.22: Detalhes da etapa de Sanity Checking de OCP-IP Router

A etapa de Sanity Checking instanciou o Reference Model OCPIPRouter (implemen-

tado a partir dos componentes Reference Model RoutingUnit e Interface), o Agent Device

(implementado na Verificação de Interface) e implementou os casos de teste no compo-

nente Test Case Model OCPIPRouter, como pode ser visto na figura 5.39 e detalhado na

tabela 5.22.

Apesar doMonitor Device já estar disponível, o critério de parada foi feito utilizando

o número de vetores de teste igual a 100 como condição para finalização das simula-

ções. Este critério será redefinido na etapa de Environment Validation que será mostrada

mais adiante.


Figura 5.40: Interface Refinement de OCP-IP Router


Test Case ModelOCPIPRouter

378 100%

Agent Device 61 100%Reference ModelOCPIPRouter

831 100%

Driver Device 55 100%Monitor Device 64 100%


Tabela 5.23: Detalhes da etapa de Interface Refinement de OCP-IP Router

Uma vez terminada a implementação dos casos de teste e verificada a sanidade do

ambiente, as interfaces foram refinadas através a instanciação do Driver Device e Moni-

tor Device que já haviam sido implementados na Verificação de Interface. Por re-utilizar

componentes que já foram validados, esta etapa de Interface Refinement (ilustrada na


figura 5.40) se resume a verificar se os mesmos foram devidamente instanciados e co-

nectados. Os resultados desta etapa estão sumarizados na tabela 5.23.

Figura 5.41: Environment Validation de OCP-IP Router


Comunicação via dispositivo 1 36,43% 2.405Comunicação via dispositivo 2 35,84% 2.183Comunicação via dispositivo 3 37,92% 2.956


Geral 39,02% 14.397

Tabela 5.24: Resultados da etapa de Environment Validation de OCP-IP Router

A etapa de Environment Validation, que pode ser vista na figura 5.41, verificou se

a ordenação das sequências geradas pelo módulo Test Case Model OCPIPRouter (casos

de teste) estavam corretas e se o comportamento esperado estaria sendo obtido. Os

resultados gerados nesta etapa estão sumarizados na tabela 5.24.

Com a instanciação do componente Monitor Device foi possível redefinir um novo

critério de parada das simulações (a cada 3 vetores de testes, o percentual de cobertura


seria amostrado, e caso não fosse incrementado a simulação seria finalizada) baseado

na análise de cobertura.

Figura 5.42: DUV Execution de OCP-IP Router

No final de todo o processo, na etapa de DUV Execution (ilustrada na figura 5.42),

o OCPIPRouter foi finalmente instanciado com todas as suas parte componentes, que

foram verificadas individualmente, e teve seu comportamento analisado e estimulado

em busca de erros. Este sistema só poderá ser aprovado pela Verificação quando ne-

nhuma de suas partes componentes e quaisquer combinações delas apresentarem fa-

lhas em aberto. A realização deste estudo de caso demandou aproximadamente 80

horas de trabalho para ser realizado.

5.3 Estudo de Caso: CAIP

Este foi o estudo de caso mais complexo realizado, o CAIP é o acrônimo para Con-

trole Automático de Iluminação Pública. Neste trabalho, uma plataforma complexa de

hardware, composta por um micro-controlador 8051 e periféricos, é controlada através

de um software embarcado rodando sobre o sistema operacional de tempo real cha-

mado Free RTOS.

Este estudo de caso teve como principais objetivos a validação da metodologia para

projetos complexos que contenham software embarcado, como plataformas de monito-

ramento e controle; e a demonstração de que para projetos bem mais complexos as


propriedades da metodologia são mantidas.

5.3.1 Arquitetura

O sistema CAIP é composto por componentes de hardware e software integrados que

controlam e monitoram um sistema de iluminação pública, de maneira distribuída,

um conjunto de postes. Pelo fato de suas partes componentes de hardware, como os

monitores de tensão e corrente ou omicro-controlador 8051, já terem sido devidamente

verificadas, o CAIP foi considerado como uma unidade atômica (como pode ser visto

na figura 5.43). Nesta plataforma de controle, todas as funcionalidades que foram

verificadas estavam implementadas no software embarcado.

Figura 5.43: Arquitetura do CAIP


Apesar de CAIP ser um sistema relativamente complexo, a aplicação do IVM ainda

persiste nas mesmas duas macro etapas: a definição da arquitetura e a execução do

fluxo de atividades.

Como foi dito anteriormente, o cenário de uso deste sistema é exatamente o mesmo

para o qual ele foi concebido (monitorando sensores e atuadores de um poste de ilu-

minação), com seus sensores e atuadores. Para fins de simplificação, todos os sensores

e atuadores de CAIP foram agrupados nos atores Sensor e Actuator, respectivamente,

sendo este cenário ilustrado na figura 5.44.

Figura 5.44: Cenário de uso de CAIP


A arquitetura, para este caso em particular, é a instância topo do sistema que foi

estimulada por seus respectivos agentes externos. O fluxo de atividades para verificar

o CAIP está descrito no decorrer da leitura desta seção, com a aplicação das etapas

estabelecidas pelo IVM que serão detalhadas e ilustradas, para os dezesseis casos de

teste especificados.

Figura 5.45: Sanity Checking de CAIP


Test Case ModelCAIP

6.492 0%

Agent Sensor 594 0%Agent Actuator 627 0%Reference Model

CAIP1.481 0%

Total de linhas 9.194 0%

Tabela 5.25: Detalhes da etapa de Sanity Checking de CAIP

Na primeira etapa do fluxo IVM de Sanity Checking (ilustrada na figura 5.45), o

propósito principal foi descrever os casos de teste no componente Test Case Model

CAIP, modelar as funcionalidades do sistema em Reference Model CAIP e por fim,

implementar o Agent Sensor e Agent Actuator que geram e capturaram estímulos de

CAIP. Esta etapa se mostrou especialmente importante, pois o sistema CAIP possui

diversas restrições temporais que exigem que uma sequência bem precisa de eventos

seja gerada pelo Test Case Model CAIP. Todos os resultados gerados nesta etapa estão

sumarizados na tabela 5.25.


Figura 5.46: Interface Refinement de CAIP


Test Case ModelCAIP

6.492 100%

Agent Sensor 594 100%Agent Actuator 627 100%Reference Model

CAIP1.481 100%

Driver Sensor 678 0%Driver Actuator 621 0%Monitor Sensor 774 0%Monitor Actuator 440 0%

Total de linhas 11.707 78,53%

Tabela 5.26: Detalhes da etapa de Interface Refinement de CAIP

Verificada a sanidade do ambiente e atendidas todas as restrições temporais, o re-

finamento das interfaces de comunicação foi implementado, para que o DUV pudesse

ser inserido, como pode ser visto na figura 5.46. Como já foi anteriormente falado, o ob-

jetivo desta etapa é garantir que o comportamento validado, utilizando comunicação

TLM, continue sendo preservado com a comunicação a nível de sinais (implementada

pelo Driver Sensor e Driver Actuator). Além de preservar as propriedades da comuni-

cação, o monitoramento de protocolo e análise de cobertura também foi feito (imple-

mentado através do Monitor Sensor e Monitor Actuator, resultados sumarizados na

tabela 5.26).


Figura 5.47: Environment Validation de CAIP


Caso de Teste 1 57,72% 22Caso de Teste 2 69,84% 23Caso de Teste 3 56,93% 35Caso de Teste 4 62,94% 49Caso de Teste 5 69,42% 34Caso de Teste 6 62,92% 28Caso de Teste 7 60,74% 35Caso de Teste 8 79,64% 56Caso de Teste 9 82,43% 44Caso de Teste 10 74,84% 39Caso de Teste 11 88,87% 51Caso de Teste 12 84,32% 53Caso de Teste 13 89,94% 61Caso de Teste 14 73,11% 59Caso de Teste 15 84,02% 61Caso de Teste 16 83,90% 73

Geral 74,18% 723

Tabela 5.27: Detalhes da etapa de Environment Validation de CAIP

Quando todas as interfaces foram refinadas e foi atestado que a comunicação estava

dentro da especificação, o ambiente teve seu comportamento validado. Isto foi feito

através da utilização de um pseudo componente CAIP, ilustrado na figura 5.47, que se

comportou como o módulo CAIP, fornecendo ao projetista uma visão realista de como

o sistema real deveria funcionar (detalhes sobre os casos de teste e cobertura estão

sumarizados na tabela 5.27). Esta etapa foi finalizada quando o pseudo CAIP passou


por todos os casos de testes sem apresentar falhas nem violações de protocolo.

Figura 5.48: DUV Execution de CAIP

Com a validação do ambiente, o sistema CAIP pode ser instanciado no ambiente

de Verificação, como pode ser visto na figura 5.48, e todos os casos de teste foram

executados. Como todo o ambiente já havia sido validado com um pseudo CAIP, se-

ria bastante improvável que erros descobertos nesta etapa fossem do ambiente. Esta

característica permitiu ao engenheiro ter bastante confiança no ambiente criado. A im-

plementação deste estudo de caso demandou aproximadamente 480 horas de trabalho

para ser finalizado.

5.4 Resultados obtidos

Os estudos de casos realizados permitiram que uma série de resultados fossem ge-

rados, e esta seção tem por objetivo sintetizar todos estes dados obtidos em tabelas a

seguir. Todos os experimentos foram implementados seguindo os seguintes parâme-

tros e configurações:

� Linguagem OSCI SystemC 2.2.0 (poderia ser qualquer outra com orientação a

objetos, como SystemVerilog ou e);

� Período de relógio de 83 ns (12 MHz);

� Semente aleatória escolhida: 1234;

� Passo de simulação de 3 transações e qualquer incremento positivo de cober-

tura como critério de parada.


ProjetoAmbiente

deVerificação

DUVTempo

dedesenvolvimento

Dual Port Memory 1.346 linhas 664 linhas 40hOCP-IP Router 2.689 linhas 990 linhas 80h

CAIP 11.707 linhas 4.619 linhas 480h

Tabela 5.28: Tamanho do ambiente de Verificação e complexidade dos sistemas

Os primeiros dados, que são sumarizados na tabela 5.28, são referentes ao tamanho

do ambiente de Verificação, a complexidade do sistema (DUV) e o tempo de desen-

volvimento do ambiente de Verificação, para todos os estudos de caso realizados. É

interessante perceber que DualPortMemory é o sistema mais trivial (apesar de parecer

o sistema mais complicado devido aos grande número de cenários e componentes de

Verificação), e que o CAIP é o de longe o mais complexo (em contraste com seu cenário

de uso simples e poucos componentes de Verificação).

Projeto Vetores de teste Tempo de simulação Tempo real

Dual Port Memory 122.056 30.391 us 7m32sOCP-IP Router 34.404 334.266 us 8m34s

CAIP 723 449.888 ms 65h22m

Tabela 5.29: Resultados de simulação

Dados sobre tempos de simulação também foram extraídos, permitindo que o leitor

possa ter uma noção mais real da complexidade das transações realizadas e do tempo

de simulação e real que são consumidos, como pode ser visto a tabela 5.29. Estes dados

só vem re-afirmar a complexidade mostrada na tabela anterior, e de como o número de

cenários e componentes de Verificação não determinam quão complexo é o sistema.

Projeto Cobertura funcional (0 - 100%)

Dual Port Memory 60,55%OCP-IP Router 39,02%

CAIP 74,18%

Tabela 5.30: Cobertura atingida nos estudos de caso

Os dados referentes a cobertura funcional atingida1 são mostrados na tabela 5.30.

Estes valores de cobertura refletem o quanto todas as interfaces do DUV foram esti-

muladas pelo ambiente de Verificação e se os critérios definidos pelo projetista foram

satisfeitos. O que isto significa é quanto, percentualmente, o sistema foi efetivamente

1O valor de cobertura obtido representa efetivamente quanto, percentualmente, as funcionalidadesdo sistema foram estimuladas, de acordo com especificação definida no Plano de Verificação.


estimulado, tendo em vista todas as suas interfaces externas. Por exemplo, para o com-

ponente DualPortMemory a cobertura atingida significa que 60,55% das combinações

de endereços e dados possíveis foram gerados. Estes percentuais de cobertura forne-

cem uma estimativa de completude dos vetores de teste gerados sobre todo o universo

possível definido, sumarizando em um número os resultados obtidos.

Além dos dados de cobertura gerados, também são gerados relatórios que deta-

lham todos os valores que foram gerados e quais não foram. Esta informação permite

ao engenheiro de Verificação confirmar se a funcionalidade foi ou não adequadamente

estimulada, baseando-se não em critérios subjetivos ou em experiência, mas sim na

especificação do sistema e nos dados de cobertura obtidos.

Por fim, foi realizada uma análise comparativa entre as metodologias do estado da

arte (VeriSC e OVM) e a metodologia proposta (IVM) para que fiquem explícitas as

contribuições deste trabalho para a atividade de Verificação. Tendo em vista que todos

os resultados anteriormente mostrados, como números de linha de código, vetores de

teste aplicados ou cobertura funcional, ficaram bastante próximos em todas as meto-

dologias, a análise comparativa será feita em cima do número de componentes criados

e o índice de re-usabilidade dos mesmos dentro do mesmo projeto.

Figura 5.49: Análise comparativa do estudo de caso Dual Port Memory

Pela observação da figura 5.49, pode ser visto que o número total de componen-

tes implementados na metodologia IVM é o menor e que o percentual de re-uso dos

componentes foi de 55% contra 47,83% do VeriSC e 53,85% do OVM.


Figura 5.50: Análise comparativa do estudo de caso OCP-IP Router

No estudo de caso OCP-IP Router, mais uma vez o número total de componentes

implementados na metodologia IVM foi o menor (como pode ser visto na figura 5.50)

e seu percentual de re-uso foi de 25% contra 14,29% do VeriSC e 19,05% do OVM.

Figura 5.51: Análise comparativa do estudo de caso CAIP

Mais uma vez, durante o estudo de caso do CAIP, o número total de componentes

implementados na aplicação dametodologia IVM é omenor entre as demaismetodolo-

gias, como pode ser visto na figura 5.51. Por se tratar de um sistema atômico (somente

um único ambiente é criado), em nenhuma das metodologias houve a possibilidade de

re-usar componentes.

É interessante ressaltar que, além de ter um percentual de re-uso superior às demais

metodologias nos estudos de caso realizados, a metodologia IVM também reduziu

significativamente o número total de componentes criados. Esta redução no número de

componentes permite que um ambiente de Verificação seja validado mais facilmente,

pois os problemas de integração são amenizados devido a sua organização reduzida.

Capítulo 6

Conclusões e Trabalhos Futuros

Este trabalho apresentou uma metodologia de Verificação para sistemas digitais,

tendo como principais objetivos: permitir a construção e execução de um ambiente

de Verificação antes da primeira versão do sistema; suportar projetos desenvolvidos

segundo a metodologia em cascata e iterativos e incrementais; definir componentes

interoperáveis e em camadas para reduzir o esforço de projeto; e definir um critério de

parada simplificado baseado no crescimento do percentual de cobertura em função do

tempo de simulação.

Todos os conceitos do IVM foram construídos em cima de metodologias consoli-

dadas, como o OVM e o VeriSC, permitindo que uma abordagem construtiva fosse

utilizada para garantir que o resultado final continuasse atendendo aos requisitos de

ambas as metodologias. Além destas metodologias base, outras referências também

foram utilizadas, mas com menor impacto e, principalmente, com intuito de organizar

e conhecer de maneira mais ampla como as várias técnicas e abordagens são utilizadas.

Os estudos de caso só vieram a confirmar o imenso esforço que é empreendido

durante o desenvolvimento de qualquer sistema digital, inclusive os triviais. Apesar

deste grande esforço, ambientes de Verificação interoperáveis, de qualidade superior e

com reduzidas chances de erros ou falhas foram obtidos com a utilização da metodo-

logia proposta. A consequência lógica de tudo isto foi um avanço na produtividade e

na qualidade dos sistemas desenvolvidos que utilizaram o IVM como metodologia de

Verificação.

6.1 Principais contribuições

O resultado da junção de metodologias bem diferentes, teve como resultado uma

nova metodologia que combinou o melhor das metodologias consideradas, criando as

seguintes contribuições:

� Suporte a fluxos de desenvolvimento em cascata (modelo clássico) e iterativo e

81

CAPÍTULO 6. CONCLUSÕES E TRABALHOS FUTUROS 82

incremental;

� Um algoritmo genérico e automático para finalização da simulação (critério de

parada) baseado na análise da cobertura;

� Todo o ambiente de simulação pode ser construído e executado antes da pri-

meira versão do projeto ser fornecida, de maneira natural e sem implicar em

esforço adicional;

� Os componentes são projetados, padronizados e estruturados em camadas, de

forma que seu re-uso em outros projetos possa ser assegurado, reduzindo o

esforço para construção de ambientes de Verificação Funcional.

6.2 Trabalhos futuros

No decorrer da criação deste trabalho, foram observadas algumas oportunidades

para trabalhos futuros, que poderiam agregar valor a este trabalho, e serão listados a

seguir:

� Criação de um conjunto de ferramentas, baseadas em UML ou outra lingua-

gem de alto nível, que permitam reduzir a quantidade de trabalho manual que

precisa ser feita para construir os componentes de Verificação;

� Definição de técnicas que permitam um suporte mais efetivo à Verificação de

software embarcado, que na maioria das metodologias consideradas o anali-

sam sempre com uma visão de sistema hardware e software.

Por fim, estes trabalhos futuros, caso incorporados a este trabalho, permitiriam um

aumento significativo em produtividade, além de suportar de maneira mais eficaz sis-

temas que possuem software embarcado, que cada vez mais estão ganhando terreno em

projetos, principalmente pela sua grande versatilidade e flexibilidade.

Referências Bibliográficas

[1] KEATING, M.; BRICAUD, P. Reuse Methodology Manual for System-on-a-Chip De-

signs. Third edition. [S.l.]: Kluwer Academic Publishers, 2002.

[2] RASHINKAR, P.; PATERSON, P.; SINGH, L. System-on-a-chip Verification - Methodo-

logy and Techniques. [S.l.]: Kluwer Academic Publishers, 2002.

[3] VMM. Verification Methodology Manual. 2000.

[4] PRADO, B. O. P. Avaliação e Refinamento da Estratégia de Verificação do Brazil IP -

Trabalho de Graduação/UFPE. 2006.

[5] LIMA, M. S. M. ipPROCESS: Um processo para desenvolvimento de IP-Cores com proto-

tipação em FPGA. Dissertação (Mestrado) — Universidade Federal de Pernambuco,

2006.

[6] BERGERON, J. Writing Testbenches: Functional Verification of HDL Models. Second

edition. [S.l.]: Kluwer Academic Publishers, 2003.

[7] MELCHER, E. U. K. Curso de Verificação Funcional do projeto Brazil IP. 2006. Projeto

Brazil IP.

[8] SILVA, K. R. G. da; MELCHER, E. U. K.; ARAÚJO, G. An automatic testbench

generation tool for a systemc functional verification methodology. SBCCI, 2004.

[9] OVMWORLD. Open Verification Methodology Datasheet/Reference/White Paper. 2008.

[10] HTTP://WWW.MENTOR.COM/GO/COOKBOOK. Advanced Verification Metho-

dology Cookbook. 2008.

83

Apêndice A

Biblioteca de padronização

84

IVM.h

#ifndef IVM_H_

#define IVM_H_

// SystemC library

#include <systemc.h>

/**

* @namespace IVM Interoperable Verification Methodology Library

* @brief This package contains all IVM components

* @example IVMExample.cpp

* This example show how IVM library should be used

*/

namespace IVM {

// SystemC module name redefinition

typedef sc_module_name ComponentName;

/**

* @class Component

* @brief Component extending SystemC Module.

*/

class Component : public sc_module {

// Public declarations

public:

/**

* Default constructor

* @param componentName Component instance name

*/

explicit Component(ComponentName componentName) :

sc_module(ComponentName(componentName)) { }

/**

* Component get name method

* @return Returns the name of this component

*/

85

APÊNDICE A. BIBLIOTECA DE PADRONIZAÇÃO 86

const char* componentName() {

return name();

}

// End of class

};

// End of IVM namespace

};

// Include IVM templates

#include "IVM/IVM_TLM.h"

#include "IVM/IVM_Agent.h"

#include "IVM/IVM_BFM.h"

#include "IVM/IVM_CRU.h"

#include "IVM/IVM_PCM.h"

#include "IVM/IVM_TCM.h"

using namespace IVM;

#endif /*IVM_H_*/

IVM_Agent.h

#ifndef IVM_AGENT_H_

#define IVM_AGENT_H_

// IVM namespace

namespace IVM {

/**

* @class Agent

* @brief Agent extending IVM Component

*/

class Agent : public Component {


public:

/**


* @param agentName Agent instance name

*/

explicit Agent(ComponentName agentName) :

Component(agentName) { }

/**

* This method returns the number of errors detected

* @return Returns the number of errors

*/

virtual int getNumberOfError() = 0;

// Private declarations

private:

/**

* This method compares the executed transactions,

* incrementing or not the number of errors

*/

virtual void comparator() = 0;

87


// End of class

};


};

#endif /*IVM_AGENT_H_*/

IVM_BFM.h

#ifndef IVM_BFM_H_

#define IVM_BFM_H_

// IVM namespace

namespace IVM {

/**

* @class BusFunctionalModel

* @brief Bus Functional Model extending IVM Component

*/

template < class INTERFACE >

class BusFunctionalModel : public Component {


public:

/**


* @param name BusFunctionalModel instance name

*/

explicit BusFunctionalModel(ComponentName name) :

Component(name) { }

/**

* Default method for BFM’s port interface binding

* @param &interface Port interface

*/

virtual void bindPort(INTERFACE &interface) = 0;

/**

* Default method for getting export reference

* @return Returns the BFM’s export reference

*/

virtual INTERFACE& getExport() = 0;

// End of class

};

89



};

#endif /*IVM_BFM_H_*/

IVM_CRU.h

#ifndef IVM_CRU_H_

#define IVM_CRU_H_

// IVM namespace

namespace IVM {

/**

* @class ClockResetUnit

* @brief Clock/Reset Unit extending IVM Component

*/

class ClockResetUnit : public Component {


public:

/**


* @param name Clock/Reset Unit instance name

*/

explicit ClockResetUnit(ComponentName name) :

Component(name) { }

/**

* This method adds the signals to trace file

* @param *traceFile Trace file reference

*/

virtual void addToTraceFile(sc_trace_file *traceFile) = 0;

/**

* This method configures the clock period

* @param clockPeriod New clock period

* @param clockTimeUnit New clock time unit

*/

virtual void configureClockPeriod(double clockPeriod,

sc_time_unit clockTimeUnit) = 0;

/**

91


* This method activates reset signal

* @param numberOfCycles Number of reset active cycles

*/

virtual void activateReset(unsigned int numberOfCycles) = 0;

// End of class

};


};

#endif /*IVM_CRU_H_*/

IVM_PCM.h

#ifndef IVM_PCM_H_

#define IVM_PCM_H_

// IVM namespace

namespace IVM {

/**

* @class ProtocolCoverageMonitor

* @brief Protocol/Coverage Monitor extending IVM Component

*/

class ProtocolCoverageMonitor : public Component {


public:

/**


* @param name ProtocolCoverageMonitor instance name

*/

explicit ProtocolCoverageMonitor(ComponentName name) :

Component(name) { }

/**

* This method adds the signals to trace file

* @param *traceFile Trace file reference

*/

virtual void addToTraceFile(sc_trace_file *traceFile) = 0;

/**

* This method gets the number of errors found

* @return Returns the number of errors

*/

virtual int getNumberOfError() = 0;

/**

* This method gets the interface coverage

* @return Returns 0-100% range coverage level

93


*/

virtual double getCoverage() = 0;

/**

* This method generates the desired report(s)

*/

virtual void generateReport() = 0;

// End of class

};


};

#endif /*IVM_PCM_H_*/

IVM_TCM.h

#ifndef IVM_TCM_H_

#define IVM_TCM_H_

// IVM namespace

namespace IVM {

/**

* @class TestCaseModel

* @brief Test Case Model extending IVM Component

*/

class TestCaseModel : public Component {


public:

/**


* @param name Test Case Model instance name

*/

explicit TestCaseModel(ComponentName name) :

Component(name) { }

/**

* This method return the total number of errors

* (functional and protocol) found

*/

virtual int getTotalError() = 0;

/**

* This method configures the random generation seed

* @param seed Selected seed for random number

*/

virtual void configureSeed(unsigned int seed) = 0;

/**

* This method generates the desired report(s)

*/

95


virtual void generateReport() = 0;

// Private declarations

private:

/**

* This method starts simulation

* using specified test case

*/

virtual void executeTestCase() = 0;

/**

* This method returns

* the number of functional errors

* @return Number of functional errors found

*/

virtual int getFunctionalError() = 0;

/**


* the number of protocol errors

* @return Number of protocol errors found

*/

virtual int getProtocolError() = 0;

/**


* the environment coverage

* @return Coverage percentage (0-100%)

*/

virtual double getCoverage() = 0;

/**

* This method verifies

* the simulation halt conditions

* @return Returns false (Simulation will stop) or

* true (Simulation will continue)

*/

virtual bool haltExecution() = 0;

// End of class

};


};

#endif /*IVM_TCM_H_*/

IVM_TLM.h

#ifndef IVM_TLM_H_

#define IVM_TLM_H_

// IVM namespace

namespace IVM {

/**

* @class Interface

* @brief This class is a SystemC sc_interface wrapper

*/

class Interface : public virtual sc_interface { };

/**

* @class Channel

* @brief This class is the TLM Channel

*/


class Channel : public INTERFACE { };

/**

* @class Port

* @brief This class is a SystemC sc_port wrapper

*/


class Port : public sc_port< INTERFACE > {

public:

/**


*/

explicit Port() : sc_port< INTERFACE >() { }

/**


* @param portName Port instance name

*/

97


explicit Port(const char *portName) :

sc_port< INTERFACE >(portName) { }

/**


* @param &interface Interface reference

*/

explicit Port(INTERFACE &interface) :

sc_port< INTERFACE >(interface) { }

};

/**

* @class Export

* @brief This class is a SystemC sc_export wrapper

*/


class Export : public sc_export< INTERFACE > {

public:

/**


*/

explicit Export() : sc_export< INTERFACE >() { }

/**


* @param exportName Export instance name

*/

explicit Export(const char *exportName) :

sc_export< INTERFACE >(exportName) { }

/**


* @param &interface Interface reference

*/

explicit Export(INTERFACE &interface) :

sc_export< INTERFACE >(interface) { }

};


};

#endif /*IVM_TLM_H_*/

Apêndice B

Código do critério de parada

99

HaltCriteria.cpp

// Cover step

#define COVER_STEP 1

// Cover increment

#define COVER_INCREMENT 1

// Previous coverage

double previousCoverage;

// This method returns the testbench coverage

double getCoverage() {

// Returns 0 - 100% coverage

}

// This method verifies the simulation halt condition

bool haltExecution() {

// Increment the number of transactions

numberOfTransactions++;

// Step condition checking

bool stepCondition =

((numberOfTransactions % COVER_STEP) == 0);

// Coverage grow condition checking

bool growCondition =

((getCoverage() - previousCoverage) >= COVER_INCREMENT);

// Coverage update

if(stepCondition) previousCoverage = getCoverage();

// Halt decision condition

// Step Condition (false) and Grow Condition (false) => true

// Step Condition (false) and Grow Condition (true) => true

// Step Condition (true) and Grow Condition (false) => false

// Step Condition (true) and Grow Condition (true) => true

return (stepCondition && (!growCondition));

}

// Testcase

100

APÊNDICE B. CÓDIGO DO CRITÉRIO DE PARADA 101

void testcase() {

// Testcase loop

do {

// Testcase code

}

while(!haltExecution());

}

“ivm: uma metodologia de verificação funcional ... · ivm: uma metodologia de veriﬁcação...

Documents