1

Especificação eVerificação funcional

Elmar Melcher

Universidade Federal de Campina Grande

elmar@dsc.ufcg.edu.br

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