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

Slides:



Advertisements
Apresentações semelhantes
Introdução a Algoritmos
Advertisements

Conceitos de Programação Paralela
VERIFICAÇÃO FORMAL DE BLOCOS COMPLEXOS
gerador de código intermediário
Metodologia de testes Nome: Gustavo G. Quintão
A Interface entre Processadores e Periféricos
Barramentos Introdução.
Entrada e Saída Introdução.
Técnicas para operações E/S
Fundamentos de Engenharia de SW
Teste de Software.
SISTEMAS DE INFORMAÇÃO
Tópicos Motivação para teste Por que algumas empresas não testam
ARQUITETURA DE COMPUTADORES II
Unidades de Execução e de Controle Sistemas Digitais.
Testabilidade Design for Testability (DFT) Guido Araujo Julho 2003.
Redução do Consumo de Energia
Modelagem e simulação de sistemas
Professor: Carlos Roberto da Silva Filho, M. Eng.
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Gerenciamento de Requisitos com Casos de Uso
Classes e objetos P. O. O. Prof. Grace.
José Roberto Blaschek Gerência do Escopo José Roberto Blaschek.
REDUNDÂNCIA POR SOFTWARE
Monitores.
Gerenciamento de Configuração
Expansão dos Casos de Uso
Sistemas Operacionais
Sistemas Operacionais I
PMBOK: Gerenciamento do Escopo do Projeto
Conteúdo Processos e threads Partes do processo
Gerência de Configuração - GC
Professor: Márcio Amador
Analises de sistemas ESTRUTURADA Analise de sistema estruturada.
Marcio de Carvalho Victorino Processo Unificado. Unidade VI: Teste.
Plano de Manutenção <RedMan>
Comunicação de dados Protocolos básicos de enlace de dados.
SISTEMAS OPERACIONAIS I
ANÁLISE ESTRUTURADA DE SISTEMAS
Sistemas Tolerantes a Falhas: Conceitos e Técnicas
Testes de Software AULA 02 Eduardo Silvestri
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Gestão de defeitos.
SISTEMAS OPERACIONAIS I
Entrada e Saída (E/S).
Laboratório de Programação
RUP - Cap. 3 – Processo Dirigido por Caso de Uso
Sistemas Operacionais
BRAZIL IP The BrazilIP Network Ferramenta para geração de templates para Testbench Projeto Fênix Fevereiro 2004 Karina Rocha G. da Silva UFCG
Conceitos Básicos Introdução.
Técnicas e Projeto de Sistemas
Protocolo MODBUS [ Slide de Abertura com a presença de outras logomarcas ] A segunda opção é a mais apropriada para a presença de mais de duas marcas.
Integração de Ferramentas CASE
Fundamentos de linguagens de programação
Engenharia de Sistemas Embarcados Aula 5: Um Conjunto Básico de Ferramentas.
Expansão dos Casos de Uso
Introdução aos Testes MO801/MC912. Motivação Aspectos iniciais de testabilidade são necessários antes de criar módulos maiores Como executar código VHDL?
Notas de aula Prof. Vicente Prado
Sistemas de Arquivos Sistemas Operacionais Profa. Priscila Facciolli
Sistemas Operacionais IV – Gerenciamento de E/S
Rede de Computadores MAT164 – Redes de Computadores I Universidade Federal da Bahia Instituto de Matemática Departamento de Ciência da Computação.
Arquitetura de Sistemas Operacionais
TÉCNICAS DE ESTIMATIVAS
Capítulo 5 Entrada/Saída 5.1 Princípios do hardware de E/S
QUALIDADE DE SOFTWARE Prof. Carlos Augusto da Costa Carvalho.
Estimativa, Teste e Inspeção de Software
JavaScript Introdução ao JavaScript 1. Objetivos Introdução Sintaxe Básica Arquivo (script) externo Script no HEAD da página Script no BODY da página.
Prof. Ivair Teixeira Redes de Computadores.
Testes de Unidade. 2 Pauta Testes de Unidade; Testes de Unidade; Desenvolvimento orientado a testes; Desenvolvimento orientado a testes; Testes unitários.
Transcrição da apresentação:

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