verificação baseada em simulação mo801/mc912. ambiente completo testbench –todo código...
TRANSCRIPT
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