Intégration de techniques coopératives pour la

RECHERCHE
Intégration de techniques coopératives pour
la vérification formelle des processeurs
Laurent Arditi et Hélène Collavizza
Université de Nice – Sophia Antipolis
Laboratoire I3S, CNRS-URA 1376
650, Route des Colles. B.P. 145
06903 Sophia Antipolis Cédex. France
email: [email protected], [email protected]
RÉSUMÉ. Nous proposons un environnement de spécification et vérification formelle des pro-
cesseurs. Ce système intègre différentes techniques de preuve: simplification, représentation
symbolique compacte sous forme de Diagrammes de Moments Binaires, preuve inductive avec
Coq. Ces techniques sont utilisées de façon progressive afin de minimiser l’intervention de
l’utilisateur. Notre système a permis de prouver efficacement plusieurs processeurs et des ins-
tructions complexes qui n’avaient jamais été vérifiées.
ABSTRACT. We propose a framework for the specification and formal verification of processors.
This system integrates different proof techniques: simplification, a compact symbolic repres-
entation (Binary Moment Diagram), inductive proof with Coq. These techniques are used in a
progressive way in order to reduce user intervention. Our system has been efficiently used to
verify several processorsand complex instructions.
MOTS-CLÉS : Vérificationformelle, spécification,preuve,microprocesseur,exécution symbolique,
simplification, Diagrammes de Moments Binaires, Coq
KEY WORDS : Formal verification, specification, proof, microprocessor, symbolic execution, sim-
plification, Binary Moment Diagrams, Coq
1. Introduction
1.1. Le problème
La complexité actuelle des microprocesseurs rend indispensable leur validation en
cours de conception, avant de les graver définitivement sur silicium. La conception as-
sistée par ordinateur (CAO) est incontournable pour concevoir des circuits ayant plu-
sieurs milliers de transistors. Les outils de CAO usuels permettent de faire le schéma,
le placement/routage des composants et la simulation du comportement des circuits.

Toutefois, la technique de validation largement implantée dans l’industrie est la
simulation qui ne permet pas une vérification exhaustive, puisque les circuits sont si-
mulés seulement pour certaines valeurs de leurs entrées et variables internes. De plus,
les techniques actuelles de CAO sont plutôt dédiées aux composants électroniques et
ne permettent pas de vérifier les visions abstraites des circuits.
L’application des méthodes de vérification formelle à la validation des circuits di-
gitaux vise à combler ces deux lacunes. D’une part, elles fournissent des modèles
suffisament abstraits. D’autre part, les preuves portent sur des formules universelle-
ment quantifiées et sont donc exhaustives. Plus précisément, vérifier formellement un
circuit consiste à:
1. définir un modèle formel de la spécification du circuit;
2. définir un modèle formel de l’implémentation du circuit, et
3. établir la preuve que pour toute valeur des entrées et des variables d’état, le
modèle de l’implémentation implique celui de la spécification.
La vérification formelle à bas niveau commence à être utilisée en milieu indus-
triel. Dans cet article, nous considérons un niveau abstrait, le jeu d’instructions des
processeurs, pour lequel il n’existe pas encore d’outil de CAO. Il s’agit dans ce cas de
montrer qu’un jeu d’instructions assembleur est correctement réalisé sur un chemin
de données commandé par une partie contrôle. Un grand pas doit être franchi entre la
spécification (modèle du programmeur en assembleur) et l’implémentation(ensemble
de modules électroniques). Le processeur est donc décrit à des niveaux d’abstraction
successifs (langage assembleur, langage des micro-instructions, blocs électroniques),
et la preuve montre la cohérence entre deux niveaux adjacents. Chaque étape de vé-
rification doit établir qu’une opération d’un niveau abstrait est correctement réalisée
par une séquence d’opérations plus simples à un niveau relativement plus concret.
1.2. Objectifs et contributions
Notre objectif est de fournir un système de vérification formelle des processeurs
qui puisse être accepté par les concepteurs de circuits comme un complément à leurs
outils de validation habituels. Pour cela le processus de spécification et celui de vé-
rification ne doivent pas nécessiter de connaissance particulière en logique mathéma-
tique.
Nous avons d’une part conçu un environnement de spécification générique et convi-
vial pour décrire les processeurs dans un style adapté à la preuve. D’autre part, la
complexité des processeurs actuels et la différence d’abstraction entre la spécification
et l’implémentation rendent la preuve des processeurs intraitable dans le cas général.
Par conséquent, l’intervention de l’utilisateurest inévitable. Cependant, nous pensons
qu’elle doit survenir le plus tard possible dans le processus de preuve et préconisons
donc l’utilisationprogressive de plusieurs méthodes:
—premièrement, des méthodes simples et efficaces comme la simplification(ma-
nipulation d’expressions symboliques en vue de les mettre sous une forme canonique).

Ces méthodes suffisent pour résoudre une grande partie des problèmes;
—puis associer ces méthodes de simplification à une représentation compacte des
données afin de retarder l’explosion combinatoire;
—enfin, utiliser des méthodes complexes non automatiques.
Dans la suite de cet article, nous montrerons qu’une telle approche a permis de vé-
rifier efficacement et avec un minimum d’intervention humaine, un ensemble d’exem-
ples significatifs. En particulier nous avons mis en évidence des erreurs dans la spéci-
fication d’un processeur réel.
De plus, nous avons traité le cas des instructions implémentées par des boucles de
micro-instructions, ce qui n’avait pas été fait auparavant dans le cadre d’un outil dédié
à la preuve des processeurs.
1.3. État de l’art
La vérification formelle de circuits (voir [GUP 92] pour une présentation géné-
rale sur ce sujet) est maintenant utilisée en milieu industriel en ce qui concerne la
preuve à bas niveau. Dans ce cadre, les outils utilisés sont basés sur des représenta-
tions efficaces des formules booléennes [BRY 86], et les preuves sont entièrement au-
tomatiques. Pour les niveaux plus abstraits, l’approche adoptée est d’utiliser des outils
généraux de démonstration automatique tels que Nqthm [BOY 88], HOL [GOR 92]
ou PVS [OWR 92].
En ce qui concerne le cas spécifique des processeurs, les premiers résultats ont
été obtenus par Gordon [GOR 83], qui a vérifié un processeur simple avec le sys-
tème LCF-LSM. Cette expérience a été suivie de deux cas d’études significatifs: le
processeur VIPER a été en partie vérifié avec HOL [COH 87], et le FM8501 avec
le démonstrateur Nqthm [Hun 89]. Dans les deux cas, les processeurs ont été décrits
dans le langage formel associé au démonstrateur, et la spécification aussi bien que la
preuve ont nécessité un grand savoir-faire.
L’étude de ces cas particuliers a mis en évidence la nécessité d’une méthodologie
applicable à une classe générale de processeurs. Un modèle fonctionnel a d’abord
été proposé dans [BOR 88] pour décrire les processeurs aux niveaux abstraits. Plus
récemment, une méthodologie basée sur la notion d’interprète [ANC 86] générique
a été proposée [JOY 90, WIN 90] pour la vérification des processeurs à tout niveau
d’abstraction. Ce concept générique a été implémenté en HOL qui est, à notre avis,
trop général pour être efficace et nécessite trop d’intervention humaine. Nous avons
cependant adapté et étendu ce concept dans notre système de preuve (voir section 2).
Des résultats intéressants ont aussi été obtenus avec des méthodes plus spéciali-
sées et plus automatiques [COU 89, BEA 94, BUR 94] ainsi qu’avec des approches
hybrides [ZHU 93]. Toutefois, ces méthodes portaient sur des descriptions de bas ni-
veaux et n’offraient pas d’interface de spécification.
La suite de cet article est organisée ainsi: nous détaillons l’environnement de des-
cription des processeurs dans la section 2, puis la méthodologie de preuve dans la

section 3. La section 4 présente les différents outils de preuve et la section 5 illustre
leur utilisation coopérative sur un ensemble d’exemples significatifs.
2. Le processus de spécification
2.1. Description des processeurs
En enseignant l’architecture des ordinateurs, on introduit généralement un proces-
seur comme un ensemble de composants (ces composants sont des registres, des bus,
des multiplexeurs, Ils forment le chemin de données) qui interagissent en fonction
des signaux émis par le séquenceur (la partie contrôle). Un processeur est ainsi défini
par son état (ensemble des composants), ses transitionsd’état (commandées par la par-
tie contrôleà chaque top d’horloge) et son séquencement (la succession des transitions
d’état).
Cela nous a amenés à décrire un processeur par un interprète ayant trois attributs:
—state: l’ensemble des composants visibles au niveau courant.
—transitions: les fonctions de transition d’état qui définissent le comporte-
ment du processeur,
—select: une fonction qui, selon l’état du processeur, renvoie la transition
activée par la partie contrôle.
Un tel interprète est générique car il est réutilisable pour spécifier différents pro-
cesseurs et s’applique à différents niveaux d’abstraction [WIN 90]. Ces niveaux sont,
pour le plus abstrait, le processeur tel qu’il est vu par un programmeur en assembleur.
Le niveau le plus concret est sa description structurelle sous forme d’un diagramme
électronique.
2.2. Description des preuves
Pour assurer la généricité de la preuve, nous avons étendu le concept d’interprète
générique. Nous décrivons les vérifications à effectuer entre deux niveaux de spécifica-
tion par une entité désignant deux interprètes et définissant les fonctions d’abstraction
de l’implémentation vers la spécification:
—abstraction: définit l’abstraction de l’état. Le plus souvent, elle est unique
car il s’agit d’une projection: l’état de la spécification est un sous-ensemble de l’état
de l’implémentation.
—sync définit l’abstraction temporelle. C’est un prédicat vrai seulement quand
les deux niveaux sont synchronisés c’est à dire quand l’état de l’implémentation cor-
respond au début d’une transition au niveau abstrait. Il est le plus souvent défini
comme un test sur la valeur du compteur de programme de l’implémentation.
La preuve est effectuée en exécutant une transition au et une séquence de
transitions au . L’implémentation est correcte si l’état final au est

une abstraction de l’état final au (voir le diagramme de 3.1).
2.3. Implémentation et interface utilisateur
Nous avons choisi une approche objet pour implémenter l’environnement de spé-
cification [ARD 95a]. Une telle approche est bien adaptée pour mettre en oeuvre les
concepts de généricité et réutilisabilité [MEY 88, RUM 91].
Chaque processeur est défini à chaque niveau comme un objet de la classe
Interpreter qui a les troisattributs state,transitions et select. Chaque
composant de l’attribut state est une instance d’une classe obtenue par héritage
multiple. Elle hérite d’une classe structurelle (type de données) et d’une classe com-
portementale (comportement temporel) [ARD 95a]. De même une preuve est une ins-
tance de la classe Proof ayant les attributs specification (l’interprète repré-
sentant la spécification), implementation (l’interprète représentant l’implémen-
tation), abstraction et sync. Cette hiérarchie de classes a été implémentée dans
un langage fonctionnel orienté objet: STk [GAL 94] qui est un interprète Scheme
associé à un système objet très proche de CLOS [Ste 90].
Pour aider les concepteurs qui ne sont pas familiers avec Scheme, nous avons
conçu un langage simple pour décrire les processeurs dans un style facilitant la preuve.
Sa syntaxe est proche du standard VHDL et nous avons montré dans [ARD 95b] la
faisabilité de la traduction d’un sous-ensemble de VHDL vers ce langage. À partir de
cette forme textuelle, un traducteur génère automatiquement la représentation interne
Scheme.
3. Le processus de vérification
3.1. Une approche coopérative
Comme expliqué en 1.1, la vérification du jeu d’instruction d’un processeur par
rapport à son architecture est réalisée par des équivalences successives entre des ni-
veaux de spécification adjacents. Une étape de vérification consiste à montrer que le
diagramme suivant commute:
trans1
i+1 transn i+1
transk
i+1
. . . . . .
transi
abs abs
i
i+1
état
état état
état
i,final
i+1,final
q
P
où état est un niveau abstrait (par exemple, le langage assembleur), état est un ni-
veau plus concret (par exemple, le langage des micro-instructions), est la fonction