Document - Institut d'Informatique et Mathématiques Appliquées de ...

I.2 Les langages de description de matériel3 L'intégration de méthodes de vérification formelle au sein d'un environnementde CAO de circuits, afin de proposer la preuve formelle en alternative ou encomplément à la simulation ou au test, nécessite de pouvoir raisonner à partir d'unedescription faite dans un (sous-ensemble d'un) langage de description de matériel(Hardware Description Language, HDL).3 Ces langages ont vu le jour à la fin des années 1960, dans le but de décrire etsimuler des circuits.Entre 1968 et 1975, prolifération de langages (et simulateurs), couvrant diversniveaux d'abstraction. Tentative de standardisation à partir de 1973, avec le projetCONLAN (CONsensus LANguage).A l'heure actuelle, deux standards IEEE : Verilog et VHDL.3 Généralement, les langages de description de matériel offrent plusieurs niveauxde description, parmi lesquels :• Algorithmique : modélisation de l'algorithme que le circuit doit réaliser.• Comportemental (ou système) : modélisation du comportement du circuit(automate, réseau de Pétri,...).• Transfert de registres (RTL) : modélisation du circuit par des équations (quiexpriment la mise à jour des registres).Notion de temps d'exécution, descriptions synchronisées par une horlogeexplicite.• Portes logiques : modélisation comme une interconnexion de porteslogiques.6

Notion de temps d'exécution (temps de traversée des portes).Dans une description hiérarchique, on trouve un interconnexion decomposants, eux-mêmes pouvant être vus au niveau portes.3 Verilog. http://www.verilog.com/• né au début des années 1980 (Gateway Design Automation), avec lesimulateur logique Verilog-XL• mis dans le domaine public en 1990 par Cadence (acquéreur de GatewayDesign Automation)• standardisé par l'IEEE en 1995 (IEEE Std. 1364-1995)• niveaux algorithmique, RTL, portes logiques et transistors3 VHDL.• développement entrepris en 1981 par le Département de la Défense desUSA (DoD), industriels largement impliqués dans le processus destandardisation• premier manuel de référence fin 1984, et premiers outils en 1986 (vraimentdisponibles en 1988)• standardisé par l'IEEE en 1987, révision en 1993 (groupes de travailsynthèse de haut niveau, simulation digital/analogique, vérificationformelle,…)• niveaux algorithmique, RTL et portes logiques3 Quelques mots sur SystemC. http://www.systemc.org/• version préliminaire (0.9) fin 1999 (Synopsys et CoWare).7

Diverses releases depuis, actuellement version 2.2.Standard IEEE 1666 en Décembre 2005.• bibliothèque C++ pour la description de systèmes matériels(comportements concurrents, notion de temps,...) + noyau de simulation• TLM (Transactional Level Modeling) : cosimulation matérielle/logicielleau niveau transactionnel (communications).Dans la suite de ce cours, nous discuterons principalement l'intégration desméthodes formelles dans le processus de conception, et le lien entre représentationsformelles et descriptions en langage de description de matériel, en nousconcentrant sur VHDL.8

II. GENERALITESII.1 Deux grandes approchesLes méthodes et techniques utilisées pour garantir la correction sont variées. Onpeut grossièrement identifier deux grandes approches.3 Approche vérification à posteriori :Description de la réalisation(VHDL, C,…)traductionmodèle formeldémonstrateurs généraux outils spécialisés(equivalence checking, model checking)3 Approche conception correcte :Spécification de haut niveau(langage formel)transformations préservant la correction(raffinements)réalisation(niveau abstrait)synthèseréalisation correcte par construction(niveau concret)9

Par exemple, la méthode B [Ab96] permet des étapes successives deraffinements, assorties d'obligations de preuve.3 Dans tous les cas (conception correcte ou vérification a posteriori), unemodélisation formelle du problème est indispensable, une phase de traductionpourra donc être nécessaire.3 Remarquons que, suivant le contexte, divers niveaux d'abstraction peuvent êtremis en jeu (comportemental, machine d'états, RTL, structurel,...) et certainsaspects peuvent être pris en compte sous diverses formes, par ex. au niveautemporel (modélisation des retards ou pas, horloge de synchronisation,....)II.2 Les outils de vérification3 Systèmes de preuve formelle Æ deux grands axes :• outils dits d' "equivalence checking" ou de "model checking" (approchealgorithmique)• systèmes de démonstration automatisée (approche déductive)Depuis quelques années, diverses tentatives de développement d'outils où lesdeux approches coopèrent.3 Equivalence checkers :• preuve de l'équivalence de 2 circuits séquentiels Æ preuve d'équivalencede 2 machines d'états finis.• pour des machines ayant des espaces d'états identiques (correspondanceentre les éléments mémorisants) et un même état initial Æpreuve10

d'équivalence entre les parties combinatoires (i.e. équivalence pour lesfonctions de sortie et les fonctions de transition d'état).3 Model checkers :• Model checking peut se traduire par vérification par évaluation sur unmodèle.On cherche à vérifier si une représentation de notre système est un modèled'une formule de logique temporelle F• le modèle fait intervenir la notion de relation d'ordre temporel. logiques temporelles :• linear time (la relation d'ordre est totale)• ou branching time.Par exemple LTL, CTL, m-calcul,… propriétés dites de "sûreté" (safety) ou de "vivacité" (liveness).3 Systèmes de démonstration automatisée :• démonstrateurs automatiques• assistants de preuves : utilisation de "tactiques" pour valider la preuve del'utilisateurDéveloppement dès les années 1970. A l'heure actuelle, il existe une grandevariété de systèmes, plus ou moins automatiques. Suivant les cas, ils sontconçus pour :• logique classique du premier ordre• logique du premier ordre + induction (ACL2)• spécialisés pour raisonner sur des théories équationnelles (RRL, OBJ3,…)11

• logiques d'ordre supérieur (HOL, PVS, Coq) ...II.3 ExemplesVoyons deux petits exemples très simples de vérification d'équivalence et depreuve de propriétés temporelles.3 On peut vouloir vérifier l'équivalence de deux versions d'un circuit séquentiel,reconnaisseur de code BCD (Binary Coded Decimal).S 3S 4IS1S2OIS 1S 2OS 3On remarque qu'ici il n'y a pas correspondance des espaces d'état.12

3 Pour le système de contrôle de feux tricolores ci-dessous (feux sur une routeprincipale et sur une route secondaire), on peut vouloir vérifier des propriétéstemporelles, comme par exemple le fait que l'arrivée de voitures sur la routesecondaire (un détecteur les repère) fera bien passer au vert le feucorrespondant (et au rouge l'autre feu !).De façon générale, si l'on n'utilise pas de méthodes de raffinement dont il estgaranti qu'elles préservent la correction, le problème va se poser de déterminerdans quelle mesure le comportement espéré est respecté lorsque l'on descend dansles niveaux d'abstraction décrits dans la section I.2 : fonctionnalité et/ou diversespropriétés (temporelles) préservées ? Il peut s'agir également de vérifier lacorrection d'une optimisation, au même niveau d'abstraction.13

III. VERIFICATIONS TEMPORELLES (APERÇU)III.1 Model-checking - CTL3 Un model checker est utilisé dès qu'on cherche à vérifier si notre système estun modèle d'une formule de logique temporelle F [CE81], [Mc93]. Il faut quele modèle soit fini (et de taille raisonnable), le circuit peut donc être considéréà tout niveau de représentation garantissant la finitude (une représentationalgorithmique au niveau arithmétique, par exemple, est a priori exclue).3 Les modèles sont généralement des systèmes de transitions étiquetés(exécutions d'un automate, d'une spécification écrite dans une algèbre deprocessus,…).Quel que soit le modèle, il fait intervenir une relation d'ordre temporel (lastructure sous-jacente est une structure de Kripke).Structure de Kripke : (S,

Remarque : définition des autres opérateursf ⁄ g = ÿ (ÿ f Ÿ ÿ g)AF f = A(true U f), EF f = E(true U f) eventuallyAG f = ÿ E(true U ÿ f), EG f = ÿ A(true U ÿ f)globallyIII.2 Quelques outils3 Il existe à l'heure actuelle divers outils commerciaux pour la preuve depropriétés, parmi eux RuleBase (IBM) [IB], ou Solidify (Averant) [Av].Voir [Sur] pour une comparaison d'outils commerciaux de model checking etd'equivalence checking (datant de Nov. 2001).3 Parmi les outils domaine public, SPIN (G.Holzmann, Bell Labs) [Spi], permetla simulation et la vérification d'algorithmes répartis, et notamment lavérification de propriétés exprimées en logique temporelle linéaire LTL.En cas d'échec, une trace d'exécution peut être "rejouée" par simulation.Les descriptions sont faites en Promela : description de chaque processus et desinteractions entre les processus (communication par FIFOs, par rendez-vous,ou par variables partagées).3 L'outil Evaluator de CADP, Construction and Analysis of DistributedProcesses (INRIA Rhône-Alpes et Verimag) [Cad], permet la vérification depropriétés temporelles écrites en m-calcul modal, sur des descriptions faites enLOTOS.3 Le système VIS ("Verification Interacting with Synthesis", Berkeley) [Vis]propose un environnement pour la simulation et la synthèse logique de FSMs.Il offre la possibilité de faire des vérifications de propriétés exprimées en CTL.16

Il propose un front-end pour un sous-ensemble du langage Verilog (transformédans le format BLIF-MV utilisé par VIS).3 Le système SMV (Ken McMillan, Carnegie-Mellon puis Cadence) [Smv] estun outil basé sur les BDDs, qui permet le model checking symbolique deformules CTL sur des descriptions d'automates (ou même de réseauxd'automates avec variables partagées).Les descriptions sont faites dans un langage maison, très déclaratif, qui permetd'exprimer l'évolution de l'état global du système par la mise à jour desvariables (relation "next"). De telles descriptions sont très proches, dansl'esprit, de descriptions VHDL comportementales ou RTL synchrones. Laconstruction d'un réseau synchrone d'automates se fait comme l'interconnexionde circuits logiques ("modules" interconnectés par leurs ports d'E/S).SMV exhibe un contre-exemple en cas d'échec.III.3 Exemple3 Considérons l'exemple d'un ascenseur dans un immeuble à 3 niveaux. Cesystème a 6 entrées : les 3 boutons intérieurs (e1, e2, e3) et les 3 boutonsd'appels à chaque niveau (req1, req2, req3).Trois signaux r1, r2, et r3, servent à mémoriser les requêtes. Suivant lesrequêtes, la partie contrôle positionne les signaux go1, go2, et go3, et lesignal up qui indique la direction du mouvement. Elle comprend 8 états :• chaque état ATi correspond à un arrêt au niveau i, et chaque état ATiacorrespond à un départ du niveau i17

• les états B12 et B23 correspondent respectivement à des déplacementsentre les niveaux 1 et 2, et 2 et 3.Les transitions d'états peuvent être représentés par la figure ci-dessousAT1a1---B12AT2a10-0 -011-011-1--10-0B23AT3a01--0-1-1-0--10---1-1--0 -1-1-1-0 --11AT1AT2AT3Arrow labelling : go1 go2 go3 up3 La description de ce système, transitions d'états et mises à jour des signaux, estla suivante, dans le format d'entrée de SMV :MODULE main(e1, e2, e3, req1, req2, req3){/* E/S */input e1, e2, e3, req1, req2, req3: boolean;/* Etat d'automate */state : { at1a, at1, b12, at2, at2a, b23, at3, at3a };/* Signaux */go1, go2, go3, r1, r2, r3, up: boolean;next(state) :=switch(state){at1a: go1 ? at1: (go2 | go3 ? b12: at1a);at1: at1a;b12: go1 & ~up ? at1 :(go2 & up ? at2 : (go3 & up ? b23 : b12));at2a: go2 ? at2 :(go1 & ~up ? b12 : (go3 & up ? b23 : at2a));at2: at2a;b23: go2 & ~up ? at2 :(go1 & ~up ? b12 : (go3 & up ? at3 : b23));at3a: go3 ? at3 : (go1 | go2 ? b23 : at3a);at3: at3a;};18

}next(r1) := ((state ~= at1) & (req1 | e1)) ? 1 :(state=at1 ? 0 : r1);next(r2) := ((state ~= at2) & (req2 | e2)) ? 1 :(state=at2 ? 0 : r2);next(r3) := ((state ~= at3) & (req3 | e3)) ? 1 :(state=at3 ? 0 : r3);switch(state){at1: next(go1):=0;at1a: { next(up):=1;if (r1) next(go1) := 1;if (r2) next(go2) := 1;if (r3) next(go3) := 1;}at2: next(go2):=0;at2a: { next(up):= go3 ? 1 : (go1 ? 0 : up);if (r1) next(go1) := 1;if (r2) next(go2) := 1;if (r3) next(go3) := 1;}at3: next(go3):=0;at3a: { next(up):=0;if (r1) next(go1) := 1;if (r2) next(go2) := 1;if (r3) next(go3) := 1;}}REACH1 : SPEC (state=at1 -> AG(r1 -> AF(state=at1)));REACH2 : SPEC (state=at1 -> AG(r2 -> AF(state=at2)));REACH3 : SPEC (state=at1 -> AG(r3 -> AF(state=at3)));Les trois dernières lignes sont trois propriétés que satisfait ce système : lesystème étant à l'origine dans l'état AT1, si une requête se produit pour leniveau i, cette requête sera inévitablement satisfaite (i.e. l'ascenseur se rendrainévitablement au niveau i).III.4 Systèmes infinis3 Les algorithmes de model-checking ne peuvent traiter que des systèmes finis.Des méthodes ont été proposées pour construire des modèles finis à partir desystèmes infinis, afin de pouvoir leur appliquer ces algorithmes. Il s'agit19

notamment de méthodes d'abstraction pour raisonner sur des systèmes avecdonnées non bornées.L'interprétation abstraite [CC96] permet de construire une approximation de lasémantique d'un programme, qui ne contient qu'une partie des informations dela sémantique concrète (par exemple : on ne garde que le signe des variables,on abstrait les entiers par des intervalles,…). Elle utilise les connexions deGalois : domaine concret, domaine abstrait, fonction d'abstraction a et fonctionde concrétisation g. Elle est non constructive (on peut prouver l'abstraction,mais rien ne peut être utilisé pour la trouver automatiquement). Diversesapplications au model checking ont été réalisées ([CC99], [DG00],…).Les méthodes basées sur le concept de predicate abstraction réalisent unpartitionnement de l'espace d'état concret en sous-ensembles disjoints, suivantun ensemble de prédicats (voir par exemple [BL98b], [BB00], [NK00]).3 Ces méthodes présentent cependant des inconvénients :• il est souvent difficile de calculer l'abstraction (méthodes heuristiques),• le système abstrait ne préserve pas forcément toutes les propriétés dusystème concret, et en cas d'échec de la procédure de model-checking la"reconstruction" d'un contre-exemple au niveau concret à partir d'un contreexempleau niveau abstrait peut être laborieuse ([BG02] par exemple),• il n'est pas possible de vérifier des propriétés mettant en jeu des variablessur lesquelles on a réalisé l'abstraction, …3 Exemple dans [BB00] : Bakery protocolIl s'agit du fameux algorithme d'exclusion mutuelle "Bakery", dans sa version àdeux processus. Chaque processus a un numéro de ticket (y 1 et y 2 ci-dessous),20

Cette procédure d'abstraction guarantit la préservation faible des propriétésLTL (si une propriété est vraie pour le système abstrait, alors la propriétécorrespondante est vraie pour le système concret).22

IV. VERIFICATIONS FONCTIONNELLESIV.1 Circuits combinatoires3 Dans le cas de l'équivalence fonctionnelle de circuits purement combinatoiresconsidérés au niveau portes logiques, il suffit de vérifier, pour les sorties deuxà deux, l'équivalence des fonctions booléennes.L'outil utilisé est généralement appelé un tautology checker, il peut faire usaged'une technologie à base de BDDs (Binary Decision Diagrams) pour lareprésentation et la manipulation des fonctions booléennes.Rappel : le calcul propositionnel est décidable (il existe un algorithmepermettant de décider en un nombre fini de pas si une formule donnée est vraieou fausse).3 Exemple : prenons l'exemple très simple de l'équivalence de deux full-adders• Version 1 (http://jingwei.eng.hmc.edu/~rwang/e85/lectures/digital_logic/node7.html) :Fonction de sortieSumOut = A xor B xor CarryInFonction de retenueCarryOut = A.B + A.CarryIn + B.CarryIn23

• Version 2 (http://www.tpub.com/content/neets/14185/css/14185_125.htm) :Fonction de sortieSumOut = A xor B xor CarryInFonction de retenueCarryOut = A.B + CarryIn.(A xor B)On vérifie l'équivalence des fonctions deux à deux (il faut évidemment lemême nommage des entrées) :A xor B xor CarryIn A xor B xor CarryInA.B + A.CarryIn + B.CarryIn A.B + CarryIn.(A xor B)IV.2 Circuits séquentiels, bas niveaux d'abstraction3 Dans le cas de l'équivalence fonctionnelle de circuits séquentiels considérés auniveau RTL, on vérifie l'équivalence des fonctions au niveau des sortiesprimaires.Le codage des états peut avoir été réalisé (registres synthétisés) ou pas (étatsymbolique de l'automate).24

L'outil utilisé peut être un equivalence checker, qui réalise la preuved'équivalence de 2 machines d'états finis (Formality [Syn], FormalPro[Men],...). On peut également avoir recours à un outil de démonstrationautomatique.3 Exemple : reprenons l'exemple du reconnaisseur de code BCD, cette fois nouscomparons une réalisation à la spécification sous forme d'automate [Di78].On lit une séquence de 4 bits I 0 I 1 I 2 I 3 sur l'entrée, c'est un code DCB valide siI 3 vaut 0, ou I 1 et I 2 valent tous les deux 0.L'automate qui spécifie un tel comportement est le suivant :STATE0/10/1STATE11/10/1/1STATE20/1STATE31/1STATE4/1STATE50/1 1/0Reprenons la réalisation vue section II :S 3S 4IS1S2O25

Le système a une entrée booléenne I et une sortie booléenne O. La réalisationproposée contient 4 registres, dont les fonctions de mise à jour sont :S1

architecture Automaton of BCD istype States is (STATE0,STATE1,STATE2,STATE3,STATE4,STATE5);signal state:States := STATE0;beginprocessbeginwait until clk'event and clk='1';case state iswhen STATE0 => state if I='0' then state

* version automate */next(etat) :=switch(etat){st0 : st1;st1 : i ? st4: st2;st2 : i ? st5: st3;st3 : st0;st4 : st5;st5 : st0;};if (etat=st5 & i) o1:=0; else o1:=1;/* version circuit */next(s1) := i;next(s2) := s1;next(s3) := ~s3;next(s4) := (s4 & ~s3) | (~s4 & s3);o2 := ~(i & (s1 | s2)) | ~(s3 & s4);o := o2;}EQUIV : SPEC (etat=st0 & s1=0 & s2=0 & s3=0 & s4=0) ->AG(o1 = o2) ;IV.3 Spécifications algorithmiques3 Que les circuits considérés soient combinatoires ou séquentiels, l'équivalencefonctionnelle entre la réalisation et une spécification algorithmique au niveauarithmétique ne peut pas être traitée avec les equivalence checkers classiques.Un outil de démonstration automatique est plus approprié pour résoudre ceproblème.3 Faisons un bref historique et tour d'horizon de ces outils :• parmi les précurseurs : LCF [Go84] et HOL [Go87].Preuve du micro-processeur VIPER avec HOL [Co89],...• à la même époque, Robert Boyer et J Moore : démonstrateur de Boyer-Moore, Nqthm [BM79][BM88].28

Preuve du microprocesseur FM8501 [Hu86],... Nqthm donnera ensuitenaissance à ACL2 (voir plus loin)• RRL (Rewrite Rule Laboratory) [KZ95] : démonstrateur pour la logique dupremier ordre utilisant essentiellement des techniques de réécriture pourraisonner sur des spécifications équationnelles.Travaux orientés vers la vérification d'architectures paramétrées, dont unevariété de multiplieurs à structure régulière [KS96]• COQ [CO98] : assistant de preuve en logique d'ordre supérieur basé sur lecalcul des constructions.Utilisé pour diverses preuves de systèmes logiciels et matériels (preuve deprotocoles au CNET,...)• PVS [OR92] : système interactif basé sur une logique d'ordre supérieurtypée.Preuve d'un diviseur [RS96], intégration dans PVS d'une procédure dedécision pour le model-checking [Sh96], intégration de PVS et d'un modelchecker (SMV) dans un système de vérification de programmes avectechniques d'abstraction [BL98a],...3 Exemples combinatoires : des systèmes combinatoires, notamment àarchitecture régulière, peuvent avoir des spécifications arithmétiques, c'est lecas par exemple des additionneurs ou des multiplieurs.• Voyons tout d'abord le cas d'un additionneur à retenue propagée :La cellule de base de cet additionneur peut se décrire comme suit :entity fulladd isport(a,b,carry: in Bit;s,c: out Bit);end fulladd;29

architecture dataflow of fulladd issignal I : Bit;beginI

Chaque cellule est un full-adder, les deux vecteurs à additionner A et B sontfournis en parallèle, la retenue entrante est positionnée à 0. Le vecteur de sortieS contient la somme des vecteurs d'entrée A et B.La somme étant l'opération arithmétique +, on abstrait la réalisation au niveaudes entiers naturels, et on prouve que :BitvectorToNatural(Adder(A, B, 0)) =BitvectorToNatural(A) + BitvectorToNatural(B)Cela suppose une modélisation fonctionnelle ou équationnelle de Adder. Unegénéralisation de l'énoncé ci-dessus peut être nécessaire.On remarque que cette preuve est indépendante de la taille des vecteurs de bits.• Le même type de raisonnement peut s'étendre à des circuits à deuxdimensions, comme les multiplieurs :Dans le multiplieur ci-dessous, chaque rangée est constituée de full-adders etde portes and.y3 y2 y1 y0x0x1FAFAFAFAx2FAFAFAFAx3FAFAFAFAz7 z6 z5 z4 z3 z2 z1 z031

Les deux vecteurs à multiplier X et Y sont fournis en parallèle, la retenueentrante de chaque rangée de full-adders est positionnée à 0.Le vecteur de sortie Z contient le produit des vecteurs d'entrée X et Y.La multiplication étant l'opération arithmétique *, comme précédemment onabstrait la réalisation au niveau des entiers naturels, et on prouve que :BitvectorToNatural(Multiplier(X, Y, 0)) =BitvectorToNatural(X) * BitvectorToNatural(Y)Tout comme ci-dessus, on sera amenés à généraliser cet énoncé, et à prouverdes propriétés intermédiaires sur les rangées de ce circuit.IV.4 Le theorem prover ACL2En TP, nous allons donner un aperçu de l'utilisation possible de l'outil dedémonstration automatique ACL2 dans le cas où une réalisation d'un circuit doitêtre prouvée équivalente à sa spécification algorithmique au niveau arithmétique.3 Avant de présenter brièvement ACL2 [KM00], faisons tout d'abord quelquesrappels sur le raisonnement par induction.La forme générale du raisonnement par récurrence est la suivante :De(1) P(0)(2) " n, n Œ N Ÿ P(n) fi P(n+1)on déduit " n, n Œ N fi P(n)Ce qui deviendra par exemple sur les listes :De(1) P(nil)(2) " l, l liste non vide Ÿ P(tail(l)) fi P(l)on déduit " l, l est une liste fi P(l)32

REFERENCES[Ab96] Jean-Raymond ABRIAL : "The B-Book". Cambridge University Press. 1996.[Av] http://www.averant.com/products-solidify.html[BB00] N.BJORNER, A.BROWNE, M.COLON, B.FINKBEINER, Z.MANNA, H.SIPMA,T.URIBE : "Verifying temporal properties of reactive systems : a STeP tutorial". FormalMethods in System Design, Vol. 16, n°3, June 2000.[BG02] S.BARNER, D.GEIST, A.GRINGAUZE : "Symbolic localization reduction withreconstruction layering and backtracking". Proc. CAV'2002, LNCS 2404, Springer-Verlag,2002.[BL98a] S.BENSALEM, Y.LAKHNECH, S.OWRE : "InVeSt: A Tool for the Verification ofInvariance Properties". Proc. 10th Intern. Conf. on Computer Aided Verification (CAV'98),June 1998.[BL98b] S.BENSALEM, Y.LAKHNECH, S.OWRE : "Computing abstractions of infinite statesystems compositionally and automatically". Proc. 10th Intern. Conf. on Computer AidedVerification (CAV'98), June 1998.[BM79] R.S. BOYER, J S. MOORE : "A Computational Logic". ACM Monograph Series.Academic Press, Inc. 1979.[BM88] R.S.BOYER, J S.MOORE : "A Computational Logic Handbook". Perspectives inComputing, Vol. 23. Academic Press, Inc. 1988.[Cad] http://www.inrialpes.fr/vasy/cadp[CC96] P.COUSOT, R.COUSOT : "Abstract Interpretation". In ACM Computing Surveys,28(2), June 1996.[CC99] P.COUSOT, R.COUSOT : "Refining model checking by abstract interpretation". InJournal of Automated Software Engineering, 6, 1999.[CE81] E.CLARKE, E.EMERSON : "Synthesis of synchronization skeletons for branching timetemporal logic". In Logic of Programs: workshop. LNCS 131, Springer-Verlag, 1981.[Co89] A.COHN : "The Notion of Proof in Hardware Verification", Journal of AutomatedReasoning, vol. 5, 1989.[CO98] "The Coq Proof Assistant Reference Manual", May 1998. Voir http://pauillac.inria.fr/coq/doc/main.html[CY00] H.CHOI, B.YUN, Y.LEE : "Simulation Strategy after Model Checking: Experience inIndustrial SOC Design". Proc. IEEE Int. High Level Design Validation and Test WorkshopHLDVT'00, 2000.[DG00] D.DAMS, R.GERTH, O.GRUMBERG : "Fair model checking of abstractions".Workshop on Verification and Computational Logic, 2000.[Di78] D.DIETMEYER : "Logic Design of Digital Systems". Allyn and Bacon. 1978.[Go84] M.GORDON : "LCF-LSM". Technical Report n°41. Univ. of Cambridge (UK). 1984.34

[Go87] M.GORDON : "HOL: A Proof Generating System for Higher-Order Logic", in "VLSISpecification, Verification and Synthesis", G.Birtwistle and P.A. Subrahmanyam editors,Kluwer 1987.[Go00] R.GOERING : "Real World creeps into Verification Conference". EE Times, 14 Nov.2000.[Hu86] W.A.HUNT : "FM8501 : A verified microprocessor". Institute for Computing Science,University of Texas, Austin (USA). Technical Report n°47. February 1986.[IB] http://www.haifa.il.ibm.com/projects/verification/RB_Homepage[KM00] M.KAUFMANN, P.MANOLIOS, J MOORE : "Computer-Aided Reasoning: AnApproach", Kluwer Academic Publishers, June 2000.[KM01] M.KAUFMANN, J MOORE : "Structured Theory Development for a MechanizedLogic", Journal of Automated Reasoning, 26(2), 2001.[KS96] D.KAPUR, M.SUBRAMANIAM : "Mechanically verifying a family of multipliercircuits". Proc. CAV'96, LNCS 1102, Springer-Verlag, 1996.[KZ95] D.KAPUR, H.ZHANG : "An overview of Rewrite-Rule Laboratory (RRL)". Journal ofComputer and Mathematics with Applications, vol.29(2), 1995.[Mc93] K.McMILLAN : "Symbolic Model Checking". Kluwer Academic Pub, 1993.[Men] http://www.mentor.com/formalpro/formalpro.html[Mo98] J MOORE : "Symbolic Simulation: An ACL2 Approach", Proc. FMCAD'98, LNCS1522, Springer-Verlag, 1998.[NK00] K.NAMJOSHI, R.KURSHAN : "Syntactic program transformations for automaticabstraction". Proc. CAV'2000, LNCS 1855, Springer-Verlag, 2000.[OR92] S.OWRE, J.RUSHBY, N.SHANKAR : "PVS : a Prototype Verification System". InD.Kapur ed. 11th Int. Conf. on Automated Deduction, LNAI n°607, Springer-Verlag, 1992.[RS96] H.RUESS, N.SHANKAR, M.SRIVAS : "Modular Verification of SRT Division". Proc.CAV '96, LNCS n°1102, Springer-Verlag, 1996.[Sc99] P.SCHNOEBELEN et al : "Vérification de logiciels (techniques et outils du modelchecking). Vuibert, 1999.[Sh96] N.SHANKAR : "PVS: Combining Specification, Proof Checking and Model Checking",Proc. FMCAD'96, Lecture Notes in Computer Science n°1166, Springer Verlag pp. 257-264, 1996.[Smv] http://www.cs.cmu.edu/~modelcheck/smv.html[Spi] http://spinroot.com[Sur] http://www.us.design-reuse.com/articles/article2287.html[Syn] http://www.synopsys.com/products/verification/formality_ds.html[Vis] http://embedded.eecs.berkeley.edu/research/vis[VV92] D.VERKEST, J.VANDENBERGH, L.CLAESEN, H.DE MAN : "A description methodologyfor parameterized modules in the Boyer-Moore logic". In "Theorem Provers inCircuit Design", North Holland, 1992.35