1 / 60

Verificação funcional por simulação

Verificação funcional por simulação. Curso do projeto Fênix Agosto 2003. Elmar Melcher UFCG elmar@dsc.ufcg.edu.br http://lad.dsc.ufcg.edu.br/ip. Roteiro. Introdução Motivação Verificação funcional no fluxo de projeto Definições Cobertura da verificação Testbench Elementos básicos

mareo
Download Presentation

Verificação funcional por simulação

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Verificação funcionalpor simulação Curso do projeto Fênix Agosto 2003 Elmar Melcher UFCG elmar@dsc.ufcg.edu.br http://lad.dsc.ufcg.edu.br/ip

  2. Roteiro • Introdução • Motivação • Verificação funcional no fluxo de projeto • Definições • Cobertura da verificação • Testbench • Elementos básicos • Regras de projeto • Implementação

  3. Motivação • Entregar produtos e ganhar dinheiro. • 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 • na fabricação em volume • no uso pelo cliente

  4. Problema para empresas • 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. • Verificação é difícil. • Engenheiros da Motorola no SBCCI 2002:“Estamos procurando trabalhos sobre verificação”

  5. Problema para empresas • Processo de projeto está indo direito. • Procura para “bons” engenheiros de verificação em todas as empresas.

  6. Caso famoso: INTEL • Problema descoberto no Pentium em 1994por um professor de matemática durante uma pesquisa matemática. • A FPU produzia resultados de divisão errôneos no oitavo digito significativo para certos argumentos. • Embora no máximo 1 usuário em 1 milhão jamais foi afetado, confiança em INTEL caiu. • Abriu o caminho para crescimento maior de AMD. • Prejuízo de 500 MUS$ (?)

  7. Caso famoso: NASA • Mars Climate Orbiter de 1999 • Erro de verificação de sistema fiz com que o Orbiter de voava muito próximo à atmosfera marciana e queimava. • Problema era um mistura de unidades métricas e unidades inglesas que causou um erro no cálculo da trajetória.

  8. Custo da verificação • Um mal necessário • sempre leva tempo demais e custa caro demais • mas indispensável. • porque afeta diretamente os três requisitos: • cronograma • custo • qualidade

  9. Verificação de IP • Ninguém usa uma IP na 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.

  10. 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. • O funcionário de uma empresadeve poder dormir tranqüilose a verificação responde “sim”.

  11. 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 • Material usado para fazer este curso: • Functional Verification of Hardware Design, Baback Izadi et al., SUNY-New Paltz e IBM, outono 2002,http://www.engr.newpaltz.edu/~bai/CSE45493/ • Principles of Verifiable RTL Design, Bening et al., Kluwer 2000 • System-on-a-chip Verification, Rashnikar et al., Kluwer 2001 • EVITA, Curso em CD, Aldec • VHDL Testbench Methodologies, Raytheon Company, 5/3/01 • A staged Verification Process with inherent testbench code reusability, Klaus-Dieter Schubert, IBM Germany, DVE 2001 • Técnicas de Verificação, Alexandre Amory, PUCRS

  12. Definições • Verificação funcional • confrontar um modelo 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

  13. Verificação estática • Analisadores de código HDL, Lint ou linting tools • Tipos de problemas detectáveis • case incompleto • atribuições em if...else inconsistente • falta de sinais na lista de sensibilidade • reset síncrono / assíncrono • falta de sinais a serem resetadas

  14. Fluxo de projeto Verificação Especificação Função Descrição comportamental Função & Timing Descrição RTL Função & Timing Descrição estrutural Função & Timing Layout consumo, área, etc.

  15. Modelo de Reconvergência • Representação conceptual do processo de verificação • Questão importante: verificar o quê? Síntese Verificação

  16. Nível hierárquico adequado • Verificação funcional pode ser realizada a vários níveis: • componente/unidade/sub-unidade, ... • ASIC/FPGA/IP • Sistema/SOC • placa

  17. Nível hierárquico adequado • Como decidir qual nível? • Nível mais baixo fornece mais observabilidade mas exige mais esforço, • a nível mais alto os elementos menores são verificadas implicitamente com menos esforço desde que os cenários e vetores de entrada são completos. • Decisão depende do projeto. • Faz parte do plano de verificação • para cada elemento existe uma seção nele.

  18. Verificação em vários níveis • Na verificação no nível de sistema é suficiente verificar a interação dos componentes se uma verificação correta a nível de componentes foi feita.

  19. Fator Humano • Alguém tem que interpretar a especificação e transformar na função correta. Síntese Especificação Interpretação Verificação

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

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

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

  23. Verificação funcional • Pode provar a presença de erros, mas não pode provar a ausência de erros. Síntese RTL Especificação formal Especificação RTL Interpretação Verificação

  24. Abordagens de Verificacão • Black Box • Grey Box • White Box

  25. Black Box DUV • Entradas, saídas, função • Função bem documentada (ou não...) • Para verificar, é preciso entender a função e prever as saídas sabendo as entradas.

  26. White Box DUV • Todas as variáveis internas visíveis. • Podem ser acessadas para verificação. • Para teste de unidades pequenas nas folhas da hierarquia

  27. Grey Box DUV • Uma seleção restrita de variáveis internas pode ser usado para verificação. • Exemplo: registradores de um processador

  28. Plano de Verificação • Especificação do processo de verificação; • Define o quê será verificado e como. • Abordagem tradicional: • faça como quiser • Abordagem nova: • uso de métricas para saber quando a verificação estiver completa: Verification Coverage • idealmente a definição de sucesso “de primeira”.

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

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

  31. Conteudo do Plano de Verificação • Resumo do sistema • Níveis de abstração • Tecnologias de Verificação • Modelos de referência a ser usados • Fluxograma da verificação • Definição dos estímulos • Testes de regressão

  32. Conteúdo do Plano de Verificação • Gerência de falhas • Plano de recursos • Cronograma

  33. Os três mandamentosda verificação funcional Você deve solicitar mais seu projeto do que jamais ele será solicitado no futuro. Você deve monitorar tudo. Você não deve passar a um nível mais alto de hierarquia antes de atingir cobertura completa.

  34. Testbench - Definição e Ideal • Definição:Montagem em volta do Design Under Verification • transaction-based • self-checking • random-constrained • coverage-driven

  35. Transação • Definição: Uma operação que inicia num determinado momento no tempo e termina em outro. • É caracterizada pelo conjunto de instruções e dados necessárias para realizar a operação. • Exemplos: • transmissão de um pacote ethernet • recepção de uma imagem • uma escrita num barramento • uma instrução de máquina para um processador

  36. FIFO Testbench sinal refmod Source ReferenceModel Checker Driver Moni-tor duv Design Under Verification

  37. Definições • Testbench • montagem de teste para simulação. • Código escrito em SystemC • 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.

  38. 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) • EUV (Entity Under Verification) • DUV (Design Under Verification)

  39. Elementos de um testbench • Source • envia transações de entrada para o driver e o modelo de referencia • Checker • compara as transações de saída recebidos do monitor com as um modelo de referência. • É bom ser reutilizável, ou seja, depender pouco do DUV. • Modelo de referência • tipicamente timeless

  40. Elementos de um testbench • Driver • recebe transações de entrada e os converta em transições de sinais da interface de entrada do DUV • Monitor • observe sinais da interface de saída do DUV, implementa o protocolo de sinalização e gera transações de saída que ele repassa para o checker

  41. FIFO Reutilização sinal ReferenceModel_2 Checker_2 Source_1 ReferenceModel_1 Monitor_2 Driver_1 duv_1 duv_2 Design Under Verification Design Under Verification

  42. FIFO Refinamento de umModelo de Referência sinal Checker Source ReferenceModelsão ReferenceModel_3 ReferenceModel_2 ReferenceModel_1

  43. FIFO Desenvolvimento deModelo de Referência e DUV sinal ReferenceModel_3 ReferenceModel_2 ReferenceModel_1 duv_1 duv_2 duv_3 Design Under Verification Design Under Verification Design Under Verification

  44. FIFO Desenvolvimento do Testbench sinal Checker_2 Source_2 ReferenceModel_2 Monitor_2 Driver_3 Driver_2 Monitor_1 ReferenceModel_2

  45. Regras de projeto • Driver • Acesso ao DUV somente pela interface do mesmo; • transação flui do source para o driver mas nunca na direção oposta. • Monitor • acesso somente pela interface do DUV; • faz verificação de protocolo (baixo nivel); • envia transações ao checker; • independente de driver e checker.

  46. Regras de projeto • Source • não envia sinais diretamente para o DUV • Checker • nunca escreve (força sinal) dentro do DUV; • pode eventualmente ler informação do DUV (por exemplo registradores internos); • Modelo de Referência • modela a funcionalidade, mas não a interface

  47. HDL Comportamental • RTL ´ comportamental • RTL foca implementação • código comportamental é mais rápido de escrever e mais simples • descrever sistema e seu TB requer conhecimento de toda a linguagem SystemC

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

  49. Ideal x Real • Gerar todas as possíveis combinações de entrada tem custo inviável para unidades maiores. • Testar muitos unidades pequenas também tem custo inviável. • É necessário fazer uma escolha.

  50. Tipos de Estimulos • 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.

More Related