Verificação Baseada em Simulação MO801/MC912. Ambiente Completo Testbench –Todo código utilizado para criar, observar e verificar características do circuito.

Apresentação em tema: "Verificação Baseada em Simulação MO801/MC912. Ambiente Completo Testbench –Todo código utilizado para criar, observar e verificar características do circuito."— Transcrição da apresentaçã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 DUV Stimulus Initiator A Stimulus Initiator B Scoreboard Stimulus responder Checker Monitor

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 x Monitor 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

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 DUV Stimulus Initiator A Stimulus Initiator B Scoreboard Stimulus responder Checker Monitor

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