1
Especificação eVerificação funcional
Elmar Melcher
Universidade Federal de Campina Grande
Workshop Brazil-IPFevereiro 2003
2
Roteiro• Introdução
– Motivação– Especificação e Verificação funcional no fluxo de projeto
• Especificação– Requisitos– Níveis de hierarquia na especificação– Especificação "executável"
• Verificação– Motivação– Plano de Verificação– Elementos básicos– Ferramentas
3
Motivação
• Entregar produtos e ganhar dinheiro.
• No caso Brazil-IP:– Formar pessoas capazes de
criar IPs para ganhar dinheiro.– Mostrar que atingiu a meta de ensino
através dos IPs criados durante a formação.– Criar IPs cuja qualidade é comparável com a
qualidade dos melhores IPs disponíveis no mercado.
4
Qualidade de um IP ?• Documentação:
– Qual é a funcionalidade do IP ?• Detalhar todas as funcionalidades;
• Ser claro e preciso para não criar expectativas falsas.
• Confiança:– Ninguém compra um IP no qual não confia.
– fornecer junto com IP uma montagem de verificação que comprova as funcionalidades;
– implementar protótipo em FPGA;
– fundição em silício;
– usar dentro de sistema vendido no mercado.
Especificação
Verificação funcional
Como fazer ?
5
Especificação de um IP
• Não tem cliente específico.
• Estudo de mercado;
• Lista de requisitos;
• Especificação.
• Datasheet.
6
Verificação funcional
• A partir da especificação:
• Plano de verificação
• Implementação de testbenches.
• Documentação da verificação.
7
Fluxo de projeto
Especificação
Descrição comportamental
Descrição estrutural
Layout
Descrição RTL Verificação
8
Roteiro• Introdução
– Motivação– Especificação e Verificação funcional no fluxo de projeto
• Especificação– Requisitos– Níveis de hierarquia na especificação– Especificação "executável"
• Verificação– Motivação– Plano de Verificação– Elementos básicos– Ferramentas
9
Estudo de mercado
• Departamento de Marketing
• casado com competências das equipes de projeto
• Nosso caso:– achômetro
10
Lista de requisitos
• texto em português
• informações qualitativas e quantitativas
• frases simples sem ambiguidades
• exemplo:– sistema faz transmissão de áudio sem fio– qualidade do sinal recebido semelhante a CD
11
Cenários de uso
• Cenarios típicos de utilização
• serão utilizados para criar testbenches
• exemplo:– conecta-se um microfone no transmissor– o receptor está a 50m dentro de uma sala de
100 m2– no receptor está conectado um alto-falante– um forno de microondas está ligado no centro
da sala exemplo de uma frase ambígua
12
Especificação do IP
• vê IP como black box
• contém todas as informações funcionais relevantes (propriedades), tanto qualitativas como quantitativas
• dificuldade: selecionar tudo aquilo que é relevante
• relacionar propriedades na especificação com requisitos e cenários de uso
13
Especificação detalhada• Esquema de blocos (esquemático, netlist)• cada bloco do tamanho de 1 a 4 homem-
semanas de projeto (sem contar verificação)• uma especificação completa para cada
bloco• relacionar propriedades do bloco com
requisitos• propriedade preenche requisito completamente• propriedade preenche requisito parcialmente
– somatório de relações de todos os blocos devem cobrir todos os requisitos
14
Níveis de detalhamento
• Um esquema de blocos não deve conter mais do que 10 blocos,
• eventualmente levando à necessidade de um nível de hierarquia adicional.
• Talvez melhor: definir vários IPs que podem ser conectados para implementar a funcionalidade desejada.
15
Especificação "executável"
• uma implementação do IP em alto nível– tipicamente usando C, C++ ou Matlab
• permite verificar escolha de algoritmos
• serve de Modelo de Referênciapara Verificação funcional
16
Roteiro• Introdução
– Motivação– Especificação e Verificação funcional no fluxo de projeto
• Especificação– Requisitos– Níveis de hierarquia na especificação– Especificação "executável"
• Verificação– Motivação– Plano de Verificação– Elementos básicos– Ferramentas
17
Motivação
• Custo e tempo de corrigir um defeito cresce quando descoberto mais tardeno ciclo de vida do produto.– na especificação– na simulação– na prototipagem FPGA– na fundição em silício– no uso pelo cliente
18
Problema para Brazil-IP
• Mais da metade do esforço de projeto está na verificação.– Um testbench muitas vezes contém mais linhas
que a própria descrição do projeto.– A equipe de engenheiros de verificação é maior
do que a equipe de projetistas.
• Processo de projeto têm receita de bolo,• verificação requer experiência.
"Arte de verificação"
19
Custo da verificação
• Um mal necessário– sempre leva tempo demais
• mas indispensável– porque afeta diretamente a qualidade do IP.
20
Verificação de IP
• Ninguém usa um IP no qual não confia.
• Como pode confiar?– Processo de verificação bem executado e
documentado.
• IPs precisam ser verificadas mais amplamente,– todas propriedades e utilizações possíveis
devem ser verificadas,– não somente um ambiente específico.
21
Isso funciona mesmo ?
• A verificação funcional deve responder a esta pergunta.
• “isso” é uma descrição RTL de um projeto.
• “funciona” se refere a simulação.
• Apostamos o futuro da microeletrônica brasileira quando a verificação responde “sim”.
22
Como saber fazer ?
• Muitos livros falam sobre implementação.
• Poucos falam sobre verificação.– Writing Testbenches: Functional Verification of HDL Models by
Janick Bergeron, 2nd edition, KluwerAcademic Publishers, 2003
– Verification Guild website
• Material de curso:– Functional Verification of Hardware Design, Baback Izadi et al.,
SUNY-New Paltz e IBM, outono 2002,http://www.engr.newpaltz.edu/~bai/CSE45493/
23
Definições
• Verificação funcional– confrontar um modela a ser verificado
a outro modelo padrão,comparando a funcionalidade.
não confundir com• Teste
– verificar se um CI está sem erro de fabricação.• Verificação formal• Validação
24
Da Especificação para a Verificação funcional
• cada unidade espeificada deve ser verificada– Especificação do IP– Especificação detalhada
• Plano de verificação define como deve ser feita a verificação de cada unidade
25
Plano de Verificação
• Feito a partir da especificação do DUV.
• Define os cenários de teste (testbenches a ser escritos):– define a complexidade deles,– as dependências entre eles.
• A partir daí é feito um cronograma:– recursos (humanos, máquinas, etc.) necessários,– recursos disponíveis
26
Plano de Verificação
• Pertence à equipe:– todo mundo envolvido é responsável,– tudo mundo deve contribuir.
• Plano de Verificação não é algo novo, já é usado por:– NASA– FAA– Software
27
Reduzir o erro humano• Automação
– eliminar intervenção humana no processo.– Realidade mostra que não é possível:
• processos mal definidos,
• precisando de invenção e criatividade humana.
• Redundância– usar dois engenheiros (ou grupos) para um
verificar o outro.• Projetista
• Engenheiro de verificação
28
Quem pode errar ?• Um projetista pode implementar uma funcionalidade de forma
errada ?
– Sim, o erro será descoberto por um teste.• Um engenheiro de verificação pode testar uma funcionalidade de forma
errada ?
– Sim, um erro falso aparecerá no teste.
• O projetista e o engenheiro de verificação podem cometer o mesmo erro ?– Não, o erro será aceito no teste.
29
Quem pode errar ?
• Um projetista pode esquecer de implementar alguma funcionalidade ?
– Sim, a falha será descoberto por um teste.
• Um engenheiro de verificação pode esquecer de testar alguma funcionalidade ?– Não, um possível erro do projetista passará
despercebido.
30
Verificação "ad-hoc"• usar editor gráfico para desenhar formas de
onda para sinais de entrada• observar formas de onda de saída
• muito pouco confiável• limitado a poucas entradas/saídas• não reutilizável
• formas de onda somente para depuração
31
Testbench
DesignUnderVerification
Driver Monitor
Checker
ReferenceModel
32
Definições
• Testbench– montagem de teste para simulação.– Código escrito em Verilog, VHDL, C, etc.,– cria estímulos e verifica a resposta,– não tem entrada nem saída,– um modelo do universo em volta do projeto,– imprime mensagens quando o DUV apresenta
comportamento inesperado,– caso tudo está ok imprime uma única menagem
no final.
33
Elementos de um testbench
Tudo a mesma coisa:
• UUV (Unit Under Test)– unidade a ser testado
• MUT (Model Under Test)
• DUT (Device Under Test Design Under Test)
• DUV (Design Under Verification)
34
Elementos de um testbench
• Driver– gera estímulos,– gera transações de entrada.
• Monitor– recolha as respostas do DUV,– verificando o protocolo de saída.
Driver e Monitor são totalmente independentes.
35
Elementos de um testbench
• Checker– envia dados de entrada para o driver e compara
os dados de saída recebidos do monitor com um modelo de referência.
– É normalmente o elemento maior do testbench.– É bom ser reutilizável ou seja, depender pouco
do DUV.
• Modelo de referencia– tipicamente timeless
36
A Arte da verificação
• Estou exercitando todos os possíveis cenários de entrada?
• Como vou saber se ocorreu um erro?
37
Tipos de Verificação• Compliance Testing
– verificar situações mencionadas na especificação
• Corner Case– verificar situações críticas (extremas) do projeto
• Real Code– utilizar estímulos reais da aplicação
• Random– cria situações “inusitadas”
– cobertura tipicamente melhor do que os outros tipos porque pode gerar cenários que seriam esquecidos.
38
Ferramentas de apoio• Simulador com análise de cobertura• Specman / Verisity
• linguagem proprietária
• Testbuilder / Cadence• Testbuilder para LDV
• Testbuilder SC
• SCV - SystemC Verification Library– todo poder do C++ e do SystemC
– acesso a sinais dentro da hierarquia de módulos
– funções para constraint randomization
– funções para monitorar handshake de sinais
39
Testbench
DesignUnderVerification
Driver Monitor
Checker
ReferenceModel
completamente em SystemC ou co-simulação VHDL/Verilog/SystemC
40
Procedimento proposto
• Decidir metodologia de verificação– SCV + SystemC ou VHDL ou Verilog
• Selecionar feramentas baseado em informações do fabricante e de usuários– Synopsys
• Adquirir rapidamente
• Testar metodologia completa
• Corrigir metodologia em função da capacidade real das ferramentas