Especificação e Verificação funcional

1. Workshop Brazil-IPFevereiro 2003 Especificação eVerificação funcional Elmar Melcher Universidade Federal de Campina Grande elmar@dsc.ufcg.edu.br

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 decriar IPs para ganhar dinheiro. • Mostrar que atingiu a meta de ensinoatravé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 ? 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. Fluxo de projeto Especificação Descrição comportamental Descrição RTL Verificação Descrição estrutural Layout

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 de100 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 Modelsby 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 verificadoa 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 ReferenceModel 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 • 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 completamente em SystemC ou co-simulação VHDL/Verilog/SystemC ReferenceModel 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