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