Verificacao - FACOM
Propaganda
Verificação MO801/MC912 Passos de Projeto 1. 2. 3. 4. 5. 6. 7. 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 – 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) begin 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 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 Não Tráfego em Main? Sim Não Tráfego em Elm? Sim Elm verde Main 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 – 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 – 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 Custo de corrigir um problema Verificação Teste do sistema Usuário Tempo Número de bugs Aumento de produtividade Verificação Teste de sistema 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 – 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 – 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
