Especificação e Verificação funcional Workshop Brazil-IP Fevereiro 2003 Especificação e Verificação funcional Elmar Melcher Universidade Federal de Campina Grande elmar@dsc.ufcg.edu.br

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

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.

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

Especificação de um IP Não tem cliente específico. Estudo de mercado; Lista de requisitos; Especificação. Datasheet.

Verificação funcional A partir da especificação: Plano de verificação Implementação de testbenches. Documentação da verificação.

Descrição comportamental Fluxo de projeto Especificação Descrição comportamental Descrição RTL Verificação Descrição estrutural Layout

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

Estudo de mercado Departamento de Marketing casado com competências das equipes de projeto Nosso caso: achômetro

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

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

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

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

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.

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

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

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

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"

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.

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.

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”.

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/

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

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

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

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

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

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.

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.

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

Testbench Reference Model Checker Driver Monitor Design Under Verification

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.

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)

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.

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

A Arte da verificação Estou exercitando todos os possíveis cenários de entrada? Como vou saber se ocorreu um erro?

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.

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

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

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