Verificação Baseada em Simulação

1. Verificação Baseada em Simulação MO801/MC912

2. Ambiente Completo • Testbench • Todo código utilizado para criar, observar e verificar características do circuito • É uma entidade de alto nível • Sem entradas nem saídas • Controla o DUV • DUV = Design Under Verification • Pode ser escrito em diversas linguagens

3. Testbench • Tem como meta estimular o circuito com entradas importantes • O que são entradas importantes? • Deve conhecer as respostas para essas entradas • Passar pelo teste significa gerar as saídas corretas para as entradas fornecidas • Quantas entradas são necessárias?

4. Ambiente Completo Stimulus responder Checker Stimulus Initiator A DUV Monitor Stimulus Initiator B Scoreboard

5. Gerador de estímulos • É o gerador de entradas para o DUV • Outros nomes: stimulus generators, drivers, agitators irritators, generators • Funciona como os vizinhos do DUV no circuito final • Mas modela apenas as interfaces dos vizinhos, não seus comportamentos • Não se preocupa com detalhes internos dos vizinhos • Foca nas especificações do DUV e não nas especificações do vizinho

6. Exemplo • O vizinho (que gera as entradas) tem um buffer de 8 posições • O DUV possui sinais de controle de fluxo para indicar quando pode ou não receber dados • O gerador de estímulos deve se focar no buffer, nos sinais de controle ou nos dois?

7. Resposta • O gerador de estímulos deve focar apenas nas limitações do DUV • O tamanho do buffer provavelmente foi uma restrição do vizinho e não do DUV • Esse buffer pode ser modificado sem alterar o DUV • Será que uma alteração no tamanho do buffer tafetaria o DUV? • Nesse caso, é interessante testar além dos limites que serão utilizados na prática

8. Protocolos de comunicação • O gerador de estímulos conhecer todo o protocolo de entrada • Cada variação do protocolo deve ser exercitada

9. Estímulos especiais • Alguns componentes podem ser usados apenas em determinadas configurações • Essas configurações devem ser testadas com mais ênfase • Mas as outras também devem ser testadas • Também devem ser gerados sinais que não indicam atividade útil • O DUV deve ser capaz de ignorá-los

10. Geradores de Estímulos • Initiators • Geram as transações de entrada para o DUV • Responders • Reagem às saídas do DUV, fornecendo estímulos de volta

11. Initiator • É o responsável por gerar as entradas do DUV • Costuma ser quebrado em partes • Uma que é capaz de se comunicar através do protocolo, temporização e sinalização especificados para o DUV • Outra que gera os estímulos propriamente ditos

12. Exemplo • Se o DUV possui um buffer de 8 lugares internamente • O gerador de estímulos pode gerar 9 comandos/dados em seqüência? • Como saber desse buffer? • O que acontece quando o buffer fica cheio? • Quem é o responsável, no projeto inteiro, por tratar dessa situaç ão?

13. Protocolo • Isolar o gerador de sinais compatíveis com um protocolo permite reutilizá-lo no futuro • Protocolos complicados, com atividades simultâneas (como pipeline do OCP/IP) são difíceis de serem tratados juntamente com o gerador de estímulos

14. Responder • Também é reponsável por gerar estímulos para o DUV • Enquanto o Initiator deve ser visto como um Mestre para o DUV, o Responder é um Escravo do DUV • Se o DUV é uma cache, um Initiator é o processador e um Responder é a memória principal • Deve serguir as mesmas regras de criação do Initiator

15. Monitor • É um componente auto-contido que observa • As saídas do DUV verificando a corretude do protocolo • Entradas do DUV para verificar cobertura • Sinais internos do DUV para eventos de interesse

16. Monitor • Não deve gerar nenhum sinal • Não deve influenciar o DUV, quem faz isso é o Responder • Sem gerar saídas, é mais fácil reutilizá-lo em níveis superiores de verificação • Deve aproveitar as entradas para gerar informações sobre cobertura • Guarda as informações para uso futuro • Por exemplo, num arquivo

17. Checker • É um Monitor especial que verifica as respostas do DUV • Módulo mais difícil • Para implementá-lo, deve-se responder a pergunta: • Como saber se o DUV está errado? • Pode utilizar informações dos Initiators e do Scoreboard para realizar sua tarefa

18. Checker Todas as solicitações foram respondidas? Todas as respostas estão corretas? Alguma resposta supérflua foi gerada? Monitor Paridade e bits de verificação estão ok? Os dados transmitidos correspondem aos indicados no cabeçalho do pacote? Outras respostas que não precisam de informações dos geradores de estímulos Checker x Monitor

19. Scoreboard • Espaço de armazenamento temporário • Duas alternativas de uso pelo Checker • O Scoreboard guarda as entradas para o Checker calcular as saídas com base nelas • O Scoreboard pré-calcula as saídas e fornece ao Checker • Se existe uma fila (FIFO) dentro do DUV, provavelmente o Scoreboard terá uma fila também

20. Scoreboard • O Scoreboard não deve se comunicar diretamente com os Initiators • Ele só deve ter acesso aos barramentos de dados • Evita problemas de interpretação • Permite reuso

21. DUV • Design Under Verification • Design Unter Test (DUT) • Unit Under Test (UUT)

22. Ambiente Completo Stimulus responder Checker Stimulus Initiator A DUV Monitor Stimulus Initiator B Scoreboard

23. Níveis de Observação • Três níveis são possíveis • Black box • White box • Gray box

24. Black Box • É o mais comum • As saídas são previstas com base nas entradas • Vantagens: • Mudanças internas no DUV não afetam o código de verificação • Prever as saídas com base apenas nas entradas indica que o testbench não foi afetado pelo DUV • Desvantagens • Não consegue resolver ambiguidades • Não consegue acesso a sinais internos

25. White Box • Permite acesso a todo o conteúdo do DUV • Permite detectar erros diretamente no código fonte • Não apenas como uma instância que causa problemas como no Black Box • Inclui o uso de assertions • Mesmo tendo acesso a ele, não se deve utilizar o código fonte como origem de especificação

26. Gray Box • Meio termo entre White Box e Black Box • Alguns sinais ou partes do circuito são monitorados • Permite influenciar o circuito diretamente • Alterar o valor de um contador interno que demora muito tempo para causar overflow

27. Assertions • Permite especificar características garantidas do circuito • Estados ilegais • Sinais ortogonais (codificação one-hot) • Condições de controle ilegais • Em geral, essas condições não estão bem descritas na especificação do circuito • Especificam a motivação do projetista

28. Exemplo assert (not(s1 and s2)) report “both selects on” severity error;

29. Importância de Assertions • Características internas, que não fazem parte da especificação, podem ser verificadas • Permite utilizar verificação formal • Um erro capturado por um assertion é mais fácil de corrigir • Assertions não geram grandes cargas de simulação • O uso sistemático de assertion pode capturar de 24% a 35% dos bugs de projetos grandes

30. Classificação das Assertions • Event detection • Versão mais simples. Detectam a ocorrência de um evento • Temporal event detection • Detectam um evento baseado numa outra condição (clock ativo, por exemplo) • Pre-defined event detection building blocks • Blocos projetados para fazerem verificação de certas propriedades de um circuito • Existem linguagens/ferramentas só para tratar de assertions

31. Testbenches Determinísticos • Utilizados nas fases iniciais de teste • Em geral, projetados manualmente • Possuem as respostas codificadas manualmente também • Difícil manutenção ou aprimoramento • Todos os testes são feitos manualmente

32. Testbenches com Verificadores • Possuem algum tipo de implementação do DUV • Diferente da própria implementação do DUV • São capazes de verificar a resposta do DUV • Três alternativas de implementação • Golden Vectors • Reference Model • Transaction Based

33. Golden Vectors • Inclui respostas a algumas das operações diretamente no Scoreboard • Codificado manualmente, implementado no Scoreboard • As respostas devem ser verificadas de outra forma antes da implementação • Facilita os testes de regressão • Problemas com temporização

34. Reference Model • Modelo que calcula as respostas corretas para serem comparadas com o DUV • Precisa saber a temporização do circuito • Permite uma maior cobertura do projeto, sem ter que calcular as respostas manualmente

35. Transaction Based • Não se preocupa com a temporização e sim com as respostas • A temporização dos protocolos já está sendo verificada pelo Monitor • Muitos circuitos possuem o conceito de transação, basta utiliza-los para evitar problemas de temporização