Verificação MO801/MC912

Passos de Projeto Requisitos Especificação geral e arquitetura Projeto em alto nível Implementação em HDL Verificação funcional Projeto físico (ferramentas específicas) Fabricação

Definições Validação Verificação Certificação de que o circuito final é equivalente ao HDL que o gerou Verificação Certificação de que o HDL é equivalente à especificação do projeto Nosso foco

Exemplo O sinal de trânsito entre as ruas Elm e Main deve ficar ativo (verde) por um minuto em cada direção quando possuir tráfego Sensores foram instalados nas duas ruas

Código library ieee; use ieee.std_logic_1164.all; entity traffic is port (clk, reset, timer_pulse, Main_street, Elm_street : in std_ulogic; Light_Direction : out std_ulogic_vector(1 downto 0)); end entity traffic;

Código architecture rtl of traffic is signal current_state_din, current_state_dout : std_ulogic_vector(1 downto 0); begin dfp : process(timer_pulse, Main_Street, Elm_Street, current_state_dout) current_state_din <= current_state_dout; if timer_pulse = ‘1’ then if Main_street = ‘1’ then current_state_din <= “01”; elsif Elm_Street = ‘1’ then current_state_din <= “10”; end if; end process dfp;

Código reg_proc: process(clk, reset) begin if (reset = ‘0’) then current_state_dout <= “01”; elsif clk’event and clk = ‘1’ then current_state_dout <= current_state_din; end if; end process reg_proc; Light_Direction <= current_state_dout; end rtl;

Fluxograma Esperar 60s Tráfego em Main? Não Sim Não Tráfego em Elm? Main verde Sim Elm verde

Comentários A ferramenta de síntese é capaz de sintetizar a descrição errada do circuito É possível produzir o chip errado É responsabilidade do engenheiro de verificação detectar essa falha de projeto

Primeiro desafio da verificação Explosão de estados O exemplo simples tem 5 entradas 4 possíveis estados 128 combinações possíveis a serem tratadas E num circuito com memória? 1Mb de memória interna. Quantos estados?

Como tratar Quebrar o componente em módulos menores Tratar cada módulo individualmente Proceder para testes de integração apenas quando cada submódulo estiver correto Cuidado com deduções Se cada módulo está correto individualmente, o circuito está correto?

Estados inválidos Alguns estados nunca devem ser alcançados No caso do semáforo, apenas alternativas são válidas Podem ser descartados? O que fazer nesses casos? O engenheiro de verificação deve verificar se o circuito realmente não entra nesses estados Deve existir uma forma de sair de um desses estados

Segundo desafio Comportamento errado São detectados através dos estímulos e transições Focar numa modelagem de mais alto nível ao invés dos sinais separadamente Observar que o clock e reset do semáforo têm significados bem definidos e checá-los separadamente

Exemplos do que verificar Microprocessador Dispositivo de Entrada/Saída Controlador de memória de um sistema multiprocessado Conversor de vídeo digital

Microprocessador Estímulo funcional Resultado da validação Desafio Instruções carregadas na memória Resultado da validação Os registradores estão com os valores corretos após cada instrução? Desafio Todas as combinações de instruções foram verificadas?

Dispositivo de Entrada e Saída Estímulo funcional Cabeçalho de dados, seguido por endereços, dados e bits de verificação Resultado da validação O dado foi transportado para o destino correto? Desafio O dispositivo é capaz de gerenciar centenas de fontes de dados simultaneamente?

Controlador de memória de um sistema multiprocessado Estímulo funcional Solicitação de dados e comandos de escrita de múltiplos processadores Resultado da validação Os dados foram armazenados e lidos corretamente? Desafio A coerência global foi mantida?

Conversor de vídeo digital Estímulo funcional Vídeo codificado num stream Resultado da validação O vídeo pode ser mostrado corretamente num monitor? Desafio Como saber se um ponto está errado?

Os dois desafios Definir cenários de estados e entradas para verificação Indicar qualquer comportamento incorreto do circuito

Como atacá-los Verificação baseada em simulação Verificação formal O circuito é simulado com um subconjunto das entradas e dos estados possíveis Verificação formal É feita uma prova formal de que o circuito se comporta de uma determinada forma

Missão e objetivos da verificação Tempo Chegar atrasado no mercado pode expor o produto a uma concorrência maior Custo Quanto mais tarde um erro for descoberto, mais caro será corrigi-lo Qualidade Produto com problemas gera despesas de manutenção e afeta o nome da empresa

Custo de corrigir um problema Verificação Teste do sistema Usuário Tempo

Aumento de produtividade Número de bugs Teste de sistema Verificação Tempo

Bugs Guardar um histórico de bugs detectados Bugs simples devem aparecer no início da verificação Se bugs simples aparecerem no final dos testes, rever o plano de verificaçao Bugs complexos (exotéricos) devem aparecer no final

Níveis de verificação Especificação Implementação Em geral bem documentada Indica as entradas, saídas e funcionalidade geral Implementação Informações dos desenvolvedores Em geral com documentação pior Inclui componentes internos que precisam ser testados

Fator humano A equipe de projeto e a de testes precisam conviver! Cuidado ao falar “Encontrei um bug no seu projeto” Talvez seja melhor “Encontrei um caso de teste que gera resultados inconsistentes”

Custos da verificação Engenharia Ferramentas Tempo

Custo de engenharia Em geral, é aconselhável ter uma equipe de verificação separada da de projeto O engenheiro de verificação deve ter habilitades diferentes do de projeto O projetista que faz a verificação corre o risco de cometer o mesmo erro duas vezes Um cenário não observado no projeto, provavelmente não será observado nos testes

Custo de engenharia Os projetistas são os primeiros verificadores Ex.: erros de sintaxe não podem existir Devem indicar partes do circuito que precisa ser verificada com mais detalhes Devem fornecer uma documentação adequada

Custo de ferramentas É um dos grandes custos de projeto É possível economizar engenheiros de verificação com o uso de ferramentas mais avençadas Devem ser capazes de Simular, checar cobertura, visualizar respostas, gerar testes baseados em padrões, controlar múltiplas simulações, suportar assertions

Custo de tempo Tempo É dinheiro Tempo demais gasto em verificação é tempo de mercado perdido Pouco tempo gasto em verificação pode gerar produto com problema no mercado

O ciclo de verificação Especificação funcional Plano de verificação Desenvolvimento do ambiente Ambiente de depuração Teste de regressão Processo de fabricação do hardware Teste do sistema (depuração do hardware) Análise do hardware

Especificação funcional Descreve as funcionalidades do circuito É desenvolvida pelos projetistas É incorporada no ambiente de testes para comparação com o circuito final

Plano de verificação Perguntas Conteúdo O que será verificado? Como será verificado? Conteúdo Testes e métodos Ferramentas necessárias Critério de parada Recursos necessários e cronograma Funcionalidade a verificar Funções não cobertas

Desenvolvimento do ambiente Criar o conjunto de ferramentas necessário para realizar os testes A maior parte do projeto dos testes é nessa fase Preocupação com os testes a serem gerados determinísticos, aleatórios, formais, casos de contorno Deve ser reavaliado constantemente

Ambiente de depuração Integrar o ambiente de verificação ao ambiente de projeto Executar os testes projetados sobre o circuito Comparar os resultados obtidos com os esperados

Testes de regressão Garantem que erros antigos não surjam novamente No caso de testes aleatórios, garantem que seja possível executar novamente uma mesma instância para achar os bugs Deve ser possível executar novamente todos os testes antes de enviar para produção

Outras fases Fora do nosso escopo, mais detalhes no livro Processo de fabricação do hardware Teste do sistema (depuração do hardware) Análise do hardware