Verificao Baseada em Simulao MO 801MC 912 Ambiente

Verificação Baseada em Simulação MO 801/MC 912

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

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?

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

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

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?

Resposta • O gerador de estímulos deve focar apenas 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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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 entradas indica que o testbench não foi afetado pelo DUV • Desvantagens – Não consegue resolver ambiguidades – Não consegue acesso a sinais internos

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

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

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

Exemplo assert (not(s 1 and s 2)) report “both selects on” severity error;

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

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

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

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

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

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

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