Especificação e Verificação funcional

Apresentação em tema: "Especificação e Verificação funcional"— Transcrição da apresentação:

1 Especificação e Verificação funcional
Workshop Brazil-IP Fevereiro 2003 Especificação e Verificação funcional Elmar Melcher Universidade Federal de Campina Grande

2 Roteiro Introdução Especificação Verificaçã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 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 Verificação funcional
Qualidade de um IP ? Como fazer ? 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

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 Descrição comportamental
Fluxo de projeto Especificação Descrição comportamental Descrição RTL Verificação Descrição estrutural Layout

8 Roteiro Introdução Especificação Verificaçã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 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ência para Verificação funcional

16 Roteiro Introdução Especificação Verificaçã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 Plano de Verificação Elementos básicos Ferramentas

17 Motivação Custo e tempo de corrigir um defeito cresce quando descoberto mais tarde no 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 mas indispensável
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,

23 Definições Verificação funcional não confundir com Teste
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 Redundância
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 ? Sim, o erro será descoberto por um teste.
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 Reference Model Checker Driver Monitor Design Under
Verification

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 Corner Case Real Code Random
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 Reference Model Checker Driver Monitor Design Under
completamente em SystemC ou co-simulação VHDL/Verilog/SystemC Reference Model Checker Driver Monitor Design Under Verification

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