Verificação Baseada em Simulação

MO801/MC912

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

DUV

StimulusInitiator A

StimulusInitiator B

Scoreboard

Stimulusresponder

Checker

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

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

DUV

StimulusInitiator A

StimulusInitiator B

Scoreboard

Stimulusresponder

Checker

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

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(s1 and s2))

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