Intel Keynote sur un programme formel d'étirement de l'esprit

Republié par Platon

Suiveurs: 0

Synopsys a publié sur le site SolvNet une conférence fascinante donnée par le Dr Theo Drane d'Intel Graphics. Le sujet est la vérification de l'équivalence des chemins de données. Cela peut ressembler à une autre approbation officielle de Synopsys VC DPV, mais vous devriez quand même le regarder. Il s'agit d'une discussion enrichissante sur les utilisations et les considérations formelles qui vous mènera au-delà du type de présentation habituelle du guide de l'utilisateur vers un territoire plus fascinant.

Intel Keynote sur le formel

Compréhension intellectuelle versus tests sur échantillons

La simulation pilotée par les tests sous toutes ses formes est excellente et souvent irremplaçable pour vérifier l'exactitude d'une spécification de conception ou d'une mise en œuvre. Il est également facile de démarrer. Écrivez simplement un programme de test et commencez à simuler. Mais le revers de la médaille de cette simplicité est que nous n’avons pas besoin de d’étiquettes électroniques entièrement comprendre ce que nous testons pour commencer. Nous nous convainquons que nous avons lu attentivement les spécifications et que nous comprenons tous les cas particuliers, mais il ne faut pas beaucoup de complexité pour submerger notre compréhension.

Formal vous encourage à comprendre la fonctionnalité à un niveau approfondi (au moins si vous souhaitez obtenir un résultat précieux). Dans l’exemple ci-dessus, une question simple – z peut-il être uniquement composé de 1 – ne parvient pas à démontrer un exemple sur un milliard de cycles sur un simulateur. Ce n’est pas surprenant, puisqu’il s’agit d’un cas extrême. Un test formel fournit un exemple spécifique et très non évident en 188 secondes et peut prouver qu'il s'agit du seul cas de ce type en un peu moins de temps.

OK, le formel a fait ce que les tests dynamiques ne pouvaient pas faire, mais plus important encore, vous avez appris quelque chose que le simulateur ne vous aurait peut-être jamais dit. Qu’il n’y avait qu’un seul cas possible dans lequel cette condition pourrait se produire. Formal vous a aidé à mieux comprendre la conception à un niveau intellectuel, et pas seulement sous forme de résumé probabiliste sur un ensemble fini de cas de test.

Problèmes de spécifications

L’exemple suivant de Theo est basé sur un distributeur automatique de bugs (ainsi appelé parce que lorsque vous appuyez sur un bouton, vous obtenez un bug). Cela ressemble à un problème de vérification d'équivalence C à RTL assez simple, modèle C à gauche, modèle RTL à droite. Une surprise pour Theo à ses débuts dans le formel était que le comportement de décalage à droite dans le modèle C n'est pas complètement défini dans le standard C, même si gcc se comportera de manière raisonnable. Cependant, DPV se plaindra, comme il se doit, d'un décalage dans la comparaison avec le RTL. Un comportement indéfini est une chose dangereuse sur laquelle s’appuyer.

Formel comme un distributeur automatique de bugs

La comparaison des spécifications entre C et RTL comporte d'autres dangers, en particulier autour des largeurs de bits. La troncature ou la perte d'un bit de retenue dans un signal intermédiaire (#3 ci-dessus) en sont de bons exemples. S'agit-il de problèmes de spécifications ? Peut-être une zone grise entre les choix de spécifications et de mise en œuvre.

Au-delà de la vérification d'équivalence

L'objectif principal de DPV, semble-t-il, est de vérifier l'équivalence entre une référence C ou RTL et une implémentation RTL. Mais ce besoin est relativement rare et il existe d’autres façons utiles d’appliquer une telle technologie, même si elle est un peu originale. D’abord un classique dans le monde de l’implémentation – j’ai apporté une modification, corrigé un bug – ai-je introduit de nouveaux bugs en conséquence ? Un peu comme la vérification SEQ après avoir ajouté le déclenchement d'horloge. L'analyse d'accessibilité dans les sorties de bloc peut être une autre application utile dans certains cas.

Pas seulement une vérification d'équivalence

Theo fait preuve encore plus de créativité en demandant aux stagiaires d'utiliser des contre-exemples pour mieux comprendre la conception, résoudre des Sudokus or factoriser des entiers. Il reconnaît que le DPV est une manière étrange d'aborder de tels problèmes, mais souligne que son intention est de briser l'illusion selon laquelle le DPV ne sert qu'à vérifier l'équivalence. Idée intéressante et certainement stimulante pour réfléchir à de tels défis. (J'avoue que j'ai immédiatement commencé à réfléchir au problème du Sudoku dès qu'il en a parlé.)

Conclure

Theo conclut par une discussion sur les méthodologies importantes dans l'utilisation en production, autour des contraintes, des régressions et des comparaisons avec les modèles RTL existants. Il est également difficile de savoir si ce que vous vérifiez correspond réellement à la spécification de langage naturel de niveau supérieur.

Discours très énergisant, qui vaut la peine d'être regardé ici sur SolvNet!

Partagez cet article via: