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