“IVM: Uma Metodologia de Verificação Funcional ... · IVM: Uma Metodologia de Verificação...
Transcript of “IVM: Uma Metodologia de Verificação Funcional ... · IVM: Uma Metodologia de Verificaçã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
CAPÍTULO 1. INTRODUÇÃO 3
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.
CAPÍTULO 1. INTRODUÇÃO 4
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 1. INTRODUÇÃO 5
� 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,
CAPÍTULO 2. CONCEITOS BÁSICOS 8
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.
CAPÍTULO 2. CONCEITOS BÁSICOS 9
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
CAPÍTULO 2. CONCEITOS BÁSICOS 10
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.
CAPÍTULO 2. CONCEITOS BÁSICOS 11
→ 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
CAPÍTULO 2. CONCEITOS BÁSICOS 12
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:
CAPÍTULO 3. ESTADO DA ARTE 15
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.
CAPÍTULO 3. ESTADO DA ARTE 16
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
CAPÍTULO 3. ESTADO DA ARTE 17
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.
CAPÍTULO 3. ESTADO DA ARTE 18
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.
CAPÍTULO 3. ESTADO DA ARTE 19
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:
CAPÍTULO 3. ESTADO DA ARTE 20
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.
CAPÍTULO 3. ESTADO DA ARTE 21
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.
CAPÍTULO 3. ESTADO DA ARTE 22
� 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.
CAPÍTULO 3. ESTADO DA ARTE 23
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
CAPÍTULO 4. METODOLOGIA IVM 26
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
CAPÍTULO 4. METODOLOGIA IVM 27
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.
CAPÍTULO 4. METODOLOGIA IVM 28
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
CAPÍTULO 4. METODOLOGIA IVM 29
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.
CAPÍTULO 4. METODOLOGIA IVM 30
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
CAPÍTULO 4. METODOLOGIA IVM 31
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.
CAPÍTULO 4. METODOLOGIA IVM 32
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.
CAPÍTULO 4. METODOLOGIA IVM 33
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
�
CAPÍTULO 4. METODOLOGIA IVM 34
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.
CAPÍTULO 4. METODOLOGIA IVM 35
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.
CAPÍTULO 5. ESTUDOS DE CASO 38
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
CAPÍTULO 5. ESTUDOS DE CASO 39
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.
CAPÍTULO 5. ESTUDOS DE CASO 40
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).
CAPÍTULO 5. ESTUDOS DE CASO 41
Figura 5.8: Interface Refinement de Memory
Componente Número de linhas de código Percentual de re-uso
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.
CAPÍTULO 5. ESTUDOS DE CASO 42
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.
CAPÍTULO 5. ESTUDOS DE CASO 43
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).
CAPÍTULO 5. ESTUDOS DE CASO 44
Figura 5.11: Sanity Checking de Mutex
Componente Número de linhas de código Percentual de re-uso
Test Case Model Mutex 40 0%Agent Interface 33 0%Agent Memory 21 0%
Reference Model Mutex 54 0%
Total de linhas 148 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.
CAPÍTULO 5. ESTUDOS DE CASO 45
Figura 5.12: Interface Refinement de Mutex
Componente Número de linhas de código Percentual de re-uso
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%
Total de linhas 314 57.96%
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
CAPÍTULO 5. ESTUDOS DE CASO 46
(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
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
Leitura simples 55,13% 1.535Escrita simples 47,82% 1.452
Leitura simultânea 59,74% 1.987Escrita simultânea 58,29% 2.543
Randômico 63,93% 7.834
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
CAPÍTULO 5. ESTUDOS DE CASO 47
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
CAPÍTULO 5. ESTUDOS DE CASO 48
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
Componente Número de linhas de código Percentual de re-uso
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.
CAPÍTULO 5. ESTUDOS DE CASO 49
Figura 5.16: Interface Refinement de MemoryMutex
Componente Número de linhas de código Percentual de re-uso
Test Case ModelMemoryMutex
64 100%
Agent Interface 33 100%Reference ModelMemoryMutex
68 100%
Driver Interface 22 100%Monitor Interface 43 100%
Total de linhas 230 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).
CAPÍTULO 5. ESTUDOS DE CASO 50
Figura 5.17: Environment Validation de MemoryMutex
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
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.
CAPÍTULO 5. ESTUDOS DE CASO 51
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
CAPÍTULO 5. ESTUDOS DE CASO 52
Componente Número de linhas de código Percentual de re-uso
Test Case Model Interface 38 0%Agent Mutex 26 100%
Agent Processor 23 0%Reference Model Interface 43 0%
Total de linhas 130 20%
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
CAPÍTULO 5. ESTUDOS DE CASO 53
Componente Número de linhas de código Percentual de re-uso
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%
Total de linhas 229 85.15%
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
CAPÍTULO 5. ESTUDOS DE CASO 54
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
Leitura 57,23% 1.788Escrita 59,76% 1.734
Randômico 67,82% 4.823
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.
CAPÍTULO 5. ESTUDOS DE CASO 55
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
Componente Número de linhas de código Percentual de re-uso
Test Case ModelDualPortMemory
38 0%
Agent Processor 23 100%Reference ModelDualPortMemory
111 100%
Total de linhas 172 77,91%
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.
CAPÍTULO 5. ESTUDOS DE CASO 56
Figura 5.24: Interface Refinement de DualPortMemory
Componente Número de linhas de código Percentual de re-uso
Test Case ModelDualPortMemory
38 100%
Agent Processor 23 100%Reference ModelDualPortMemory
111 100%
Driver Processor 21 100%Monitor Processor 13 100%
Total de linhas 206 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.
CAPÍTULO 5. ESTUDOS DE CASO 57
Figura 5.25: Environment Validation de DualPortMemory
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
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.
CAPÍTULO 5. ESTUDOS DE CASO 58
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.
CAPÍTULO 5. ESTUDOS DE CASO 59
Figura 5.27: Arquitetura do OCP-IP Router
5.2.2 Aplicando o IVM
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.
CAPÍTULO 5. ESTUDOS DE CASO 60
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
CAPÍTULO 5. ESTUDOS DE CASO 61
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
Componente Número de linhas de código Percentual de re-uso
Test Case ModelRoutingUnit
77 0%
Agent Interface 23 0%Reference ModelRoutingUnit
396 0%
Total de linhas 496 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.
CAPÍTULO 5. ESTUDOS DE CASO 62
Figura 5.32: Interface Refinement de RoutingUnit
Componente Número de linhas de código Percentual de re-uso
Test Case ModelRoutingUnit
77 100%
Agent Interface 23 100%Reference ModelRoutingUnit
396 100%
Driver Interface 23 0%Monitor Interface 24 0%
Total de linhas 543 91,34%
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-
CAPÍTULO 5. ESTUDOS DE CASO 63
tesDriver Interface eMonitor Interface. Os detalhes deste refinamento estão sumarizados
na tabela 5.17.
Figura 5.33: Environment Validation de RoutingUnit
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
Acesso a interface 1 55,43% 1.392Acesso a interface 2 53,92% 1.562Acesso a interface 3 49,83% 1.293
Randômico 71,75% 6.342
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.
CAPÍTULO 5. ESTUDOS DE CASO 64
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).
CAPÍTULO 5. ESTUDOS DE CASO 65
Figura 5.35: Sanity Checking de OCP-IP Interface
Componente Número de linhas de código Percentual de re-uso
Test Case ModelInterface
135 0%
Agent Device 61 0%Agent RoutingUnit 63 0%Reference Model
Interface435 0%
Total de linhas 694 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.
CAPÍTULO 5. ESTUDOS DE CASO 66
Figura 5.36: Interface Refinement de OCP-IP Interface
Componente Número de linhas de código Percentual de re-uso
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%
Total de linhas 937 74,07%
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.
CAPÍTULO 5. ESTUDOS DE CASO 67
Figura 5.37: Environment Validation de OCP-IP Interface
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
Leitura de dispositivo 54,83% 2.109Escrita de dispositivo 49,74% 2.378
Randômico 62,94% 4.934
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.
CAPÍTULO 5. ESTUDOS DE CASO 68
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).
CAPÍTULO 5. ESTUDOS DE CASO 69
Figura 5.39: Sanity Checking de OCP-IP Router
Componente Número de linhas de código Percentual de re-uso
Test Case ModelOCPIPRouter
378 0%
Agent Device 61 100%Reference ModelOCPIPRouter
831 100%
Total de linhas 1270 70,24%
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.
CAPÍTULO 5. ESTUDOS DE CASO 70
Figura 5.40: Interface Refinement de OCP-IP Router
Componente Número de linhas de código Percentual de re-uso
Test Case ModelOCPIPRouter
378 100%
Agent Device 61 100%Reference ModelOCPIPRouter
831 100%
Driver Device 55 100%Monitor Device 64 100%
Total de linhas 1389 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
CAPÍTULO 5. ESTUDOS DE CASO 71
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
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
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
Randômico 45,89% 6.853
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
CAPÍTULO 5. ESTUDOS DE CASO 72
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
CAPÍTULO 5. ESTUDOS DE CASO 73
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
5.3.2 Aplicando o IVM
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
CAPÍTULO 5. ESTUDOS DE CASO 74
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
Componente Número de linhas de código Percentual de re-uso
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.
CAPÍTULO 5. ESTUDOS DE CASO 75
Figura 5.46: Interface Refinement de CAIP
Componente Número de linhas de código Percentual de re-uso
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).
CAPÍTULO 5. ESTUDOS DE CASO 76
Figura 5.47: Environment Validation de CAIP
Caso de teste Cobertura (0 - 100%) Vetores de teste aplicados
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
CAPÍTULO 5. ESTUDOS DE CASO 77
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.
CAPÍTULO 5. ESTUDOS DE CASO 78
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.
CAPÍTULO 5. ESTUDOS DE CASO 79
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.
CAPÍTULO 5. ESTUDOS DE CASO 80
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
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 declarations
public:
/**
* Default constructor
* @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
APÊNDICE A. BIBLIOTECA DE PADRONIZAÇÃO 88
// End of class
};
// End of IVM namespace
};
#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 declarations
public:
/**
* Default constructor
* @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
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 declarations
public:
/**
* Default constructor
* @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
APÊNDICE A. BIBLIOTECA DE PADRONIZAÇÃO 92
* This method activates reset signal
* @param numberOfCycles Number of reset active cycles
*/
virtual void activateReset(unsigned int numberOfCycles) = 0;
// End of class
};
// End of IVM namespace
};
#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 declarations
public:
/**
* Default constructor
* @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
APÊNDICE A. BIBLIOTECA DE PADRONIZAÇÃO 94
*/
virtual double getCoverage() = 0;
/**
* This method generates the desired report(s)
*/
virtual void generateReport() = 0;
// End of class
};
// End of IVM namespace
};
#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 declarations
public:
/**
* Default constructor
* @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
APÊNDICE A. BIBLIOTECA DE PADRONIZAÇÃO 96
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;
/**
* This method returns
* the number of protocol errors
* @return Number of protocol errors found
*/
virtual int getProtocolError() = 0;
/**
* This method returns
* 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
};
// End of IVM namespace
};
#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
*/
template < class INTERFACE >
class Channel : public INTERFACE { };
/**
* @class Port
* @brief This class is a SystemC sc_port wrapper
*/
template < class INTERFACE >
class Port : public sc_port< INTERFACE > {
public:
/**
* Default constructor
*/
explicit Port() : sc_port< INTERFACE >() { }
/**
* Default constructor
* @param portName Port instance name
*/
97
APÊNDICE A. BIBLIOTECA DE PADRONIZAÇÃO 98
explicit Port(const char *portName) :
sc_port< INTERFACE >(portName) { }
/**
* Default constructor
* @param &interface Interface reference
*/
explicit Port(INTERFACE &interface) :
sc_port< INTERFACE >(interface) { }
};
/**
* @class Export
* @brief This class is a SystemC sc_export wrapper
*/
template < class INTERFACE >
class Export : public sc_export< INTERFACE > {
public:
/**
* Default constructor
*/
explicit Export() : sc_export< INTERFACE >() { }
/**
* Default constructor
* @param exportName Export instance name
*/
explicit Export(const char *exportName) :
sc_export< INTERFACE >(exportName) { }
/**
* Default constructor
* @param &interface Interface reference
*/
explicit Export(INTERFACE &interface) :
sc_export< INTERFACE >(interface) { }
};
// End of IVM namespace
};
#endif /*IVM_TLM_H_*/
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