Palestra da Intel sobre uma maca mental formal

Republicado por Platão

seguidores: 0

A Synopsys postou no site SolvNet uma palestra fascinante proferida pelo Dr. Theo Drane da Intel Graphics. O tópico é verificação de equivalência de caminho de dados. Pode parecer apenas mais um endosso do Synopsys VC Formal DPV, mas você deve assisti-lo de qualquer maneira. Esta é uma discussão que expande a mente sobre os usos e considerações formais, que o levará além do tipo rotineiro de guia do usuário para um território mais fascinante.

Palestra da Intel sobre formal

Compreensão intelectual versus teste de amostra

A simulação orientada a testes em todas as suas formas é excelente e muitas vezes insubstituível na verificação da exatidão de uma especificação ou implementação de projeto. Também é fácil começar. Basta escrever um programa de teste e começar a simular. Mas o outro lado dessa simplicidade é que não precisamos totalmente entenda o que estamos testando para começar. Nós nos convencemos de que lemos as especificações cuidadosamente e entendemos todos os casos extremos, mas não é necessária muita complexidade para sobrecarregar nossa compreensão.

Formal incentiva você a compreender a funcionalidade em um nível profundo (pelo menos se quiser entregar um resultado valioso). No exemplo acima, uma pergunta simples – z pode ser apenas 1 – não consegue demonstrar um exemplo em um bilhão de ciclos em um simulador. Não é surpreendente, já que este é um caso extremo. Um teste formal fornece um exemplo específico e pouco óbvio em 188 segundos e pode provar que este é o único caso em um tempo um pouco menos.

OK, formal fez o que o teste dinâmico não conseguiu fazer, mas o mais importante é que você aprendeu algo que o simulador talvez nunca tenha lhe contado. Que havia apenas um caso possível em que essa condição poderia acontecer. Formal ajudou você a entender melhor o design em nível intelectual, não apenas como um resumo probabilístico em um conjunto finito de casos de teste.

Problemas de especificações

O próximo exemplo de Theo é baseado em uma máquina de venda de bugs (assim chamada porque quando você pressiona um botão você recebe um bug). Isto parece um problema bastante simples de verificação de equivalência de C para RTL, modelo C à esquerda, modelo RTL à direita. Uma surpresa para Theo em seus primeiros dias no formal foi que o comportamento do deslocamento para a direita no modelo C não está completamente definido no padrão C, embora o gcc se comporte de maneira razoável. Porém, o DPV reclamará de descasamento na comparação com a RTL, como deveria. Comportamento indefinido é algo perigoso em que se pode confiar.

Formal como uma máquina de venda automática de insetos

A comparação de especificações entre C e RTL traz outros perigos, especialmente em torno de larguras de bits. Truncamento ou perda de um carry em um sinal intermediário (#3 acima) são bons exemplos. Esses são problemas de especificações? Talvez uma área cinzenta entre as opções de especificação e implementação.

Além da verificação de equivalência

O objetivo principal do DPV, ao que parece, é verificar a equivalência entre uma referência C ou RTL e uma implementação RTL. Mas essa necessidade é relativamente rara e existem outras maneiras úteis de aplicar essa tecnologia, ainda que um pouco inovadoras. Primeiro, um clássico no mundo da implementação – fiz uma alteração, corrigi um bug – como resultado, introduzi algum novo bug? Um pouco como a verificação de SEQ depois de adicionar o clock gate. A análise de acessibilidade nas saídas dos blocos pode ser outra aplicação útil em alguns casos.

Não apenas verificação de equivalência

Theo fica ainda mais criativo, pedindo aos trainees que usem contra-exemplos para entender melhor o design, resolver Sudokus or fatorar inteiros. Ele reconhece que o DPV é uma forma estranha de abordar tais problemas, mas ressalta que sua intenção é quebrar a ilusão de que o DPV serve apenas para verificação de equivalência. Idéia interessante e certamente estimulante para pensar em tais desafios. (Confesso que comecei imediatamente a pensar no problema do Sudoku assim que ele o mencionou.)

Embrulhar

Theo conclui com uma discussão sobre metodologias importantes no uso da produção, em torno de restrições, regressões e comparações com modelos RTL legados. Também há desafios em saber se o que você está verificando realmente corresponde à especificação de linguagem natural de nível superior.

Palestra muito energizante, vale a pena assistir aqui na SolvNet!

Compartilhe esta postagem via: