Rapport PFE

Rf : p27
AU : 2009-2010
Universit de Sousse Ecole Nationale dIngnieurs de Sousse
Mmoire de Projet de Fin d'tudes

Prsent en vue de lobtention du diplme d
Ingnieur en Gnie Electronique Industrielle Option : .....

Titre du projet
Vrification dun FPGA pour le systme de Titre du projet contrle des trains datterrissage et de freinage de lAirbus RalisA350 par : XWB
Safwen SELMI
Soutenu le 23/06/2010 devant le jury Prsidant : M. Sabeur JEMMALI, ENISo
Membre du jury : M. Abdelazize AMMARI, ENISo Encadrant Encadrant : M. Bouraoui MAHMOUD, ENISo : M. Lassaad LETAIEF, HCELL-ingineering
SELMI2010
Ddicaces
A m es trs chers parents R afika et K ham as Q ue pourrai-je vous dire !! Les m ots m e m anquent pour exprim er toute la reconnaissance, la fiert et le profond am our que je vous porte pour les sacrifices que vous avez consentis pour m a russite. Q ue vous trouvez ici le tm oignage de m on attachem ent, m a reconnaissance, m a gratitude et m on respect. Q ue D ieu vous prservent bonne sant et longue vie... A m on cher frre Marouene, ma chre sur Rihab Jespre avoir atteint le seuil de vos esprances. Q ue ce travail soit lexpression de m a profonde affection. Je vous rem ercie pour le soutient m oral et lencouragem ent que vous m avez accord. Je vous souhaite un brillant avenir. A m a chre fiance H anene Je tadresse m on attachem ent et m on affection les plus sincres pour toute laide que tu m as toujours apporte. A m es beaux parents N ajet et R achid et m es beaux frres A fef, A nas et O ns A lm e de m on dfunt am i A bdelraouf, Je ne toublierai jam ais tu resteras toujours grav dans m a m m oire A m es am i(e)s, a toute personne qui vient chercher son nom ici U n m ot final pour vous tous, Jespre que jai t la hauteur de vos esprances et sachez que jam ais je ne pourrai oublier ce que vous avez fait pour m oi petit soit-il ou grand.. Sans vous tous, jam ais je pourrai vivre ce jour. Safwen
Remerciement
M erci A LLAH , et nulle rem erciem ent ne Lui sera suffisant, lunique Dieu, lO m niscient, lO m nipotent, le Pur, pour m a voir clair le droit chem in, et pour tous ses bienfaits apparents et cachs. M erci au m essager dALLA H qui a port la charge du m essage.
Je remercie M. Majed HALILA, directeur de HCELL-engineering, de mavoir accord cette chance dintgrer son entreprise.
Je remercie galement M. Lassaad LETAIEF ,ingnieur Hardware, pour son encadrement, ses conseils et ses directives qui mont permis de mener bien mon travail.
Je remercie galement M. Mahmoud BOURAOUI, enseignant lENISo, pour avoir appuy ma candidature pour ce stage.
Je tiens remercier tous les membres de lquipe de HCELL-engineering (Aymen et Majdi) pour leur accueil chaleureux et les conseils quils mont fournis. Je remercie en particulier M. Zied JABNOUN ingnieur vrificateur dans cette quipe pour son enthousiasme et son support tout au long de mon stage.
Aussi bien, je tiens adresser mes sincres remerciements tous les membres du jury qui ont accept dvaluer mon modeste travail.
Jexprime, enfin, ma profonde reconnaissance tout le corps enseignant de lENISo pour la qualit de la formation qui mont donn durant mes trois annes dtudes.
ii
Sommaire
Sommaire ............................................................................................................................. iii Liste des figures ................................................................................................................... vi Liste des tables ................................................................................................................... viii Introduction Gnrale ............................................................................................................ 1 Chapitre 1: Systme de contrle des trains datterrissage et de freinage ................................. 3 1. 2. 3. Introduction ................................................................................................................ 4 Systme de scurit critique ........................................................................................ 4 Le standard DO-254.................................................................................................... 4 3.1. 3.2. Prsentation gnrale du standard DO-254........................................................... 4 Documents rdiger ............................................................................................ 6
4. Prsentation gnrale du projet : Design et vrification dun FPGA pour le systme de contrle des trains datterrissage et de freinage de lavion Airbus A350 XWB ................... 7 5. 1. 2. Conclusion.................................................................................................................. 8 Introduction ...............................................................................................................10 Flot de Conception.....................................................................................................10 2.1. 2.2. 2.3. 3. 3.1. Flot de conception traditionnelle .........................................................................10 Cycle en V..........................................................................................................12 Langages de descriptions matrielle ....................................................................14 Gnralit sur la vrification des descriptions en HDL ........................................14 Dfinitions...................................................................................................15 Objectif de la vrification dune description en HDL ...................................16 Cots de la vrification ................................................................................16 Chapitre 2: Fondements de la conception et de la vrification des descriptions en HDL......... 9
Diversit des outils et mthodes de vrification..........................................................14 3.1.1. 3.1.2. 3.1.3. 3.2. 3.3.
Les diffrents approches de vrification ..............................................................16 Techniques de vrification ..................................................................................17 Vrification formelle....................................................................................17 Vrification dynamique ...............................................................................18
3.3.1. 3.3.2. 3.4. 4. 1. 2. 3.
Les langages spcifiques pour la vrification du matriel HVL ...........................20
Conclusion.................................................................................................................20 Introduction ...............................................................................................................22 Prsentation du projet ................................................................................................22 Choix de la cible dimplmentation ............................................................................23 3.1. ASIC ou FPGA...................................................................................................23
iii
Chapitre 3: Conception et spcification fonctionnelles..........................................................21
3.1.1. 3.1.2. 3.1.3. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.2.4. 4. 4.1. 4.2. 5. 5.1. 5.2. 5.3. 6. 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 7. 8. 1. 2. 3.
ASIC ...........................................................................................................23 FPGA ..........................................................................................................23 Discussion et justification du choix..............................................................24 SRAM_based FPGA....................................................................................25 Flash_based FPGA ......................................................................................25 Discussion et justification du choix..............................................................26 Cible dimplmentation ACTEL A3P600-PQFP208I ...................................27
SRAM_based FPGA ou Flash_based FPGA .......................................................25
Langages de programmation ......................................................................................28 VHDL.................................................................................................................28 Langage Script Tcl..............................................................................................29 Emacs .................................................................................................................30 Modelsim SE ......................................................................................................30 Libero .................................................................................................................31 FPGA identification............................................................................................32 Watchdog interface .............................................................................................32 ARINC interface.................................................................................................33 SPI interface .......................................................................................................35 SPY interface......................................................................................................36 SDA interface .....................................................................................................36
Outils de travail .........................................................................................................30
Spcifications fonctionnelles......................................................................................32
Synthse ....................................................................................................................37 Conclusion.................................................................................................................38 Introduction ...............................................................................................................40 Architecture de Testbench..........................................................................................40 Spcifications fonctionnelles de lenvironnement de test ............................................42 3.1. Gnrateurs de Stimuli........................................................................................42 Mthode de gnration des vecteurs de test : LFSR......................................42 Gnrateur pour FPGA identification...........................................................43 Gnrateur pour Watchdog interface............................................................44 SPI master ...................................................................................................45 SPY receiver................................................................................................47 REG_SPI checkers.......................................................................................48 SPY Words checkers ...................................................................................49
iv
Chapitre 4: Vrification fonctionnelle...................................................................................39
3.1.1. 3.1.2. 3.1.3. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.2.4.
Les checkers .......................................................................................................45
3.2.5. 3.2.6. 3.3. 4. 4.1.
ARINC checker ...........................................................................................50 SDA checker................................................................................................51
Scripts Tcl ..........................................................................................................51 Simulation niveau RTL.......................................................................................53 La phase Bring-up........................................................................................53 Rgression et couverture de code .................................................................54
Simulation .................................................................................................................53 4.1.1. 4.1.2. 4.2. 4.3.
Simulation postlayout .........................................................................................54 Analyse de timing ...............................................................................................54
5. 6. 7.
Rsultats et discussions..............................................................................................55 Perspectives : Tests de robustesse ..............................................................................55 Conclusion.................................................................................................................56
Conclusion Gnrale ............................................................................................................57 Bibliographie &Neto-graphie ...............................................................................................58 Annexes ...............................................................................................................................62 Annexe A :........................................................................................................................63 Systme de contrle des trains d'atterrissage et de freinage................................................63 1. Historique de l'volution de l'nergie lectrique embarque .......................................63 2. Ncessit d'un systme hybride : lectro-embarque ..................................................63 3. Technologie daujourdhui: BTV ...............................................................................64 4. volution future vers le tout lectrique ......................................................................64 Annexe B :........................................................................................................................66 1. 2. Test Status_{TEST_ID}.txt .......................................................................................66 TEST_Scenario_{TEST_ID}.txt................................................................................66
Annexe C :........................................................................................................................68 Annexe D:.........................................................................................................................69
Liste des figures

Figure 1: cycle de vie DO-254 [2] ......................................................................................... 5 Figure 2: systme ATA32 : systmes de freinage, dorientation des roues, dextension et rtraction des trains datterrissage et de surveillance des pneus, freins et atterrisseurs. ........... 7 Figure 3 : Flot de conception dun projet VHDL [29] ...........................................................11 Figure 4 : Flot de conception dun FPGA [29] ......................................................................12 Figure 5: Cycle en V.............................................................................................................13 Figure 6: Cycle en V amlior ..............................................................................................13 Figure 7: Diagramme de vrification [17] .............................................................................15 Figure 8: Environnement de vrification dynamique [17] .....................................................19 Figure 9 : Elments de base dun FPGA [29] ........................................................................24 Figure 10 : Cellule Flash vs Cellule SRAM ..........................................................................26 Figure 11: Architecture globale du circuit A3P600 [35]........................................................28 Figure 12: Exemple de Macro crite en Tcl ..........................................................................29 Figure 13 : Exemple de Module VHDL sous Emacs .............................................................30 Figure 14 : Environnement Modelsim...................................................................................31 Figure 15 : Interface du Libero .............................................................................................31 Figure 16 : Organigramme de WDG interface.......................................................................32 Figure 17 : architecture de bus ARINC 429 ..........................................................................33 Figure 18: Encodage bipolaire avec retour zro (ARINC 429)............................................33 Figure 19: Format de trame ARINC 429...............................................................................34 Figure 20: Schma bloque de linterface ARINC 429 ...........................................................34 Figure 21 : Connexion SPI Master/Slave (s) ........................................................................35 Figure 22 : Trames changes selon le protocole SPI [36] ....................................................36 Figure 23: Format de trame SDA_LGPX ..............................................................................37 Figure 24: Format des trames reues.....................................................................................37 Figure 25: rapport des ressources utilises ............................................................................38 Figure 26: rapport de timing .................................................................................................38 Figure 27: Processus de vrification [17] ..............................................................................40 Figure 28 : architecture de Testbench ...................................................................................41 Figure 29: Schma dun LFSR de taille N.............................................................................42 Figure 30 : les 16 premires valeurs de BOARD_SEL gnres par FPGA_id generator ......44 Figure 31 : Condition de validation de WDG_power_up_test_validity ..................................44 Figure 32: Les quatre premiers scnarios de gnration de WDG_timeout_sig ......................45 Figure 33: Simulation de SPI master.....................................................................................46 Figure 34: Machine dtat pour la vrification de Protocole SPI............................................46 Figure 35: Machine dtat pour la vrification de la communication SPY .............................47 Figure 36: Simulation du SPY receiver .................................................................................48 Figure 37 : Machine dtat des REG_SPI checkers ...............................................................49 Figure 38:Machine dtat des SPY Words checkers ..............................................................50 Figure 39: Provocation de faute dencodage .........................................................................50 Figure 40: Hirarchie des macros Tcl ...................................................................................52 Figure 41: Lancement des tests en utilisant les macros Tcl....................................................53 Figure 42: traabilit des diffrents bugs dtects .................................................................55 Figure 43: Evolution de la puissance lectrique embarque [5] .............................................63 Figure 44: systme Brak-To-Vacate dAirbus .......................................................................64 Figure 45: Schma du principe du frein lectrique [6]...........................................................65 Figure 46 : Freinage hydraulique vs Freinage lectrique [34]................................................65
vi
Figure 47 : Rapport de Test OK............................................................................................66 Figure 48 : Rapport de Test OK............................................................................................66 Figure 49 : Scnario de test de protocole SPI ........................................................................67 Figure 50. Scenario de test de linterface SPI .......................................................................67 Figure 51 : Planning de vrification (SS : Safwen Selmi)......................................................68
vii
Liste des tables

Tableau I: Niveaux dassurance selon le standard DO-254 [2] ............................................... 5 Tableau II: Tableau comparatif entre les performances dun FPGA et un ASIC ....................25 Tableau III: Gnralits sur les ressources de FPGA A3P600 de la famille ACTEL ProASIC3 extrait du Data-sheet du composant [35] ...............................................................................27 Tableau IV: Liste des polynmes primitifs pour des diffrentes tailles de LFSR [31]............43
viii
ENISo |Introduction Gnrale
HCELL-engineering
Introduction Gnrale
Ils sont universelles, omniprsents. Ils nous enveloppent. Tu les tiens dans les mains. Tu les utilise dans ton quotidien en prparant ton caf ou en regardant ton mission prfrait sans mme se rendre compte quils sont l....Et parfois tu narrive mme pas les identifier. Ce sont les systmes embarqus. Tout dabord, dfinissons un tel systme. Un systme embarqu peut tre dfini comme un systme lectronique et informatique autonome, qui est ddi une tche bien prcise. [1] Ces systmes utilisent des technologies de la haute gamme pour rendre intelligents, communicants et srs tous les objets de notre quotidien. Tlphones portables, tlvisions, consoles de jeux, machines--laver, cartes puce, systmes mdicaux, automobiles, avions...les exemples sont innombrables dobjets industriels de consommation courante ou de grandes infrastructures qui font appel aux systmes embarqus. Et cela reflte lampleur que pend ce secteur de lindustrie moderne. Parmi la grande diversit de ces applications, on peut distinguer les systmes embarqus critiques. La conception et le dveloppement de tels composants sont assujettis la fois des objectifs conomiques, telle que la rduction des cots et du temps de dveloppement, mais galement au respect des normes de scurit. Dans le contexte aronautique, par exemple, ces contraintes sont amplifies puisque la marche de dveloppement doit rpondre une certaine fiabilit pour passer l'tape de certification. Pour ce faire, la RTCA (Radio Technical Commission for Aeronautics) a labor, en avril 2000, un standard qui unifie le processus de dveloppement, de validation et de vrification ainsi que la traabilit des systmes embarqus critiques : le DO-254[2], un standard qui a t adapt par la FAA (Federal Aviation Administration) en 2005, est appliqu par les dveloppeurs de ces systmes aronautiques dans les quatre coins du globe. Et les ingnieurs de HCELL-engineering ne schappent pas cette rgle. En effet, HCELL-engineering est une socit de recherche et dveloppement base dans le technople de Sousse. Membre de la ACAP [3] (Altera Consultants Alliance Program), elle fournit des solutions et des services de consultation pour les systmes embarqus visant laronautique, lautomobile et les applications mdicales. Fonde sur une quipe experte et dynamique, cette socit cre de la grande valeur ajoute en dveloppant des soft IP complexes et en fournissant des customs design, selon la norme DO-254, visant des circuits FPGA ou ASIC. Dans la conjoncture du projet de fin dtudes, on a joint cet organisme, au sein de lquipe de vrification et validation, afin de faire la vrification dun FPGA pour le systme de contrle des trains datterrissage et de freinage de lairbus A350 XWB. Et en tant quun soft IP desti n une application aronautique, ce systme critique sera dvelopper, vrifier et valider selon le standard DO-254 avec un DAL A comme degr de criticit de lapplication. Dans ce manuscrit, on va prsenter le travail qui a t fait durant ce PFE. Il comporte quatre chapitres structurs comme suit : Dans le premier chapitre, intitul Systme de contrle des trains d'atterrissage et de freinage, on va essayer de prsenter le cadre gnrale du projet. On parlera des systmes de scurit critique, du standard DO-254 pour aboutir une prsentation
1
ENISo |Introduction Gnrale
HCELL-engineering
gnrale du projet. Tandis que au deuxime, libell Fondements de la Conception et de la Vrification des Descriptions en HDL , on prsentera les mthodologies de conception en exposant un tat de lart des diffrents mthodes et stratgies de vrification. Le troisime chapitre, Conception et spcification fonctionnelle, dvoilera les critres de choix du FPGA, cible de lapplication et les diffrents outils et langages de programmation utiliss et finira par faire voir quelques spcifications fonctionnelles et les rsultats de synthses du composant. Et avant de clturer, le dernier, intitul Vrification Fonctionnelle , dtaillera le travail ralis : On commencera par une prsentation gnrale de larchitecture du Testbench et les diffrents blocs raliss intgrants lenvironnement de test, pour en finir par pa rler des diffrentes simulations, des rsultats obtenus et des perspectives.
ENISo |
HCELL-engineering
Chapitre
1:
Systme de contrle des trains datterrissage et de freinage
Objectifs :
Introduction des Systmes de scurit Prsentation du standard DO-254 Description gnrale du Projet
3
ENISo |Systme de contrle des trains datterrissage et de freinage
HCELL-engineering
Chapitre 1 :
Systme de contrle des trains datterrissage et de freinage

1. Introduction
Initialement, les systmes embarqus ont t utiliss pour des applications temps rel critique, de sret et/ou de scurit, comme le contrle des fuses, missiles, satellites, la production dnergie, le contrle de vol, les tlcommunications. Dans ce chapitre, on va mettre le projet, sujet de ce rapport, dans son cadre gnrale. On va tout dabord donner la dfinition dun Systme de Scurit Critique. Ensuite, on prsentera le standard DO-254 pour finir par une prsentation gnrale du projet.
2. Systme de scurit critique

Un systme critique est un systme lectronique ou lectromcanique dont une panne peut avoir des consquences dramatiques, dire catastrophiques tel que la perte de vie ou des blessures graves pour des tres humains, des dommages matriels importants, ou des consquences tragiques pour lenvironnement [4]. On peut considrer critiques, les applications intervenants dans les systmes de transport (avion, train), de production dnergie (central nuclaire), dimagerie mdicale (IRM, radiographie) ou encore dans des applications militaires. Il existe des diffrents niveaux de criticit des systmes de scurit. Ils prennent comme rfrence le danger que prsente une dfaillance du dispositif sur la vie humaine. Pour quun systme de scurit critique soit certifi, il doit passer par des procdures de vrific ation multiples. La criticit et le cot de cette tche ne cesse daugmenter vu la complexit accru des applications embarqus critiques [17].
3. Le standard DO-254 3.1. Prsentation gnrale du standard DO-254

Lutilisation de dispositifs lectroniques complexes au bord de lavion, dans le but de garantir plus de scurit et facilit dutilisation, ne cesse accroitre et ce l rvle de nouveaux dfis et relve la barre trs haut en terme de suret de fonctionnement et certification des systmes critiques. Pour ce faire, la RTCA a labor, en avril 2000, un standard qui unifie le processus de dveloppement, de validation et de vrification ainsi que la traabilit des systmes embarqus critiques : le DO-254[2], un standard qui a t adapt par la FAA en 2005. Ce standard aussi appel DO254, ou tout simplement "254", est la norme mondiale de Hardware dans le domaine davionique avec laquelle tout le matriel arien est tenu respecter. Le DO-254 est
4
HCELL-engineering
considr comme la norme la plus stricte au monde de llectronique, et elle influence d'autres domaines, y compris les dispositifs mdicaux, de transport et de tlcommunications. Cest un processus standard de haut niveau qui ne prcise pas les activits suivre pour atteindre les objectifs imposs ni dfinie dune manire tranchante un cycle de vie pour le processus de dveloppement. Il impose seulement une dfinition claire et prcise de certains types dactivits pour prouver lexistence de celles-ci. En effet, et en premier lieu, le cycle de vie prsent dans la figure 1, doit tre tabli pour chaque projet en slectionnant et arrangeant des processus et des activits dtermines par les attributs du projet, tels que les exigences de stabilit, lutilisation de matriel dj dvelopp, et les niveaux dassurance du design matriel cits dans le tableau I.
Figure 1: cycle de vie DO-254 [2] Lassurance de dveloppement est lassurance dune confiance justifie en un systme complexe dont on ne peut matriser exhaustivement le dveloppement. Le tableau suivant dclare les diffrents niveaux dassurance accords par les autorits de RTCA. Tableau I: Niveaux dassurance selon le standard DO-254 [2] Niveau Classification de la dfaillance du systme Catastrophique Probabilit de dfaillance1 < 10-9 < 10-7 < 10-5 < 10-3 -Description
B C D E
Dangereuse Majeure Mineure Sans effet2
Scurit du vol ou atterrissage compromis Une dfaillance du systme cause ou contribue un crash de l'avion Problme majeur entranant des dgts srieux voir la mort de quelques occupants Problme srieux entranant une dfaillance des quipements vitaux de l'appareil Problme pouvant perturber la scurit du vol Problme sans effet sur la scurit du vol
1 2
Probabilit par heure de vol Ce niveau concerne gnralement les quipements de loisir destins aux passagers.
HCELL-engineering
En second lieu, la norme impose la traabilit des exigences du design, des procdures de vrification et les rsultats des tests. Le processus de vrification peut tre appliqu tous les niveaux de la hirarchie de conception. Pour exiger plus de scurit pour le systme, il est avantageux d'appliquer le processus de vrification diffrents stades de la conception pour garantir avec un degr lev de suret, que les erreurs du design ont t limines [1].
3.2. Documents rdiger

Pour assurer la traabilit des diffrentes activits durant le processus de dveloppement, et dans le but de garantir une meilleure couverture des exigences du projet, une srie de documents est rdig le long de droulement de travail. Tout dabord, et pendant la phase de planification, trois documents doivent tre crits : Le PHAC (Plan for Hardware Aspect of certification): Il prsente le principal moyen utilis par les autorits de certification afin de dterminer si les activits du cycle de vie des composants, propos pour les designs complexes, sont compatibles avec le niveau de criticit requis pour ces design, et valuer la conformit avec les directives de conception d'assurance pour les systmes lectroniques destins laronautique [2]. Le HVVP (Hardware Validation and Verification Plan) : Le but de ce manuscrit est de dfinir les activits et les moyens de satisfaire la validation et aux objectifs du processus de vrification conformment aux directives de conception d'assurance pour les systmes lectroniques destins laronautique [2]. Le HPAP (Hardware Process Assurance Plan) : Ce papier dcrit les procdures, les mthodes, les normes appliquer, les processus et les activits mener pour atteindre les objectifs de qualit des processus de ce document.
Ensuite, pendant la phase de design, le HRD (Hardware Requirement Data) est rdig et va servir comme rfrence pour la rdaction des autres justificatifs. Ce texte, comme son nom lindique, dtaille les exigences du design. Il dcrit le comportement et la structure du produit en exposant les diffrentes interfaces et en dfinissant les performances (frquence, types des ports dentres/sorties, temprature) et les conditions aux lim ites (dlais maximal pour des signaux particuliers, taille des registres) du PLD. Ces derniers serviront comme repre pour dterminer les trais dun environnement de fonctionnement anormal du FPGA dans le but de faire les tests de robustesses. Un autre document doit tre crit dans cette phase du projet : Cest le HDD (Hardware Design Data). Il dcrypte lensemble darchitecture du circuit en question. Ce papier dmle dune faon explicite limplmentation RTL du systme en voie de dveloppement. Enfin, lors du processus de vrification et validation, les documentations transcrire sont les suivants : HAP (Hardware Acceptance Plan) : Il dcrit larchitecture de lenvironnement de vrification. HATP (Hardware Acceptance Test Procedure): Il expose les diffrents scenarios de tests et dtaille les procdures de vrification.
6
HCELL-engineering
HRTR (Hardware RTL simulation Test Result): Il mentionne les rsultats des tests issus de la simulation RTL. HATR (Hardware Acceptance Test Result) : Il mentionne les rsultats des tests issus de la simulation postlayout.
4. Prsentation gnrale du projet : Design et vrification dun FPGA pour le systme de contrle des trains datterrissage et de freinage de lavion Airbus A350 XWB
Paris, le 14 fvrier 2008 Airbus vient de slectionner Messier-Bugatti, socit du Groupe SAFRAN, pour concevoir, dvelopper, fabriquer, intgrer et assurer le support en service des systmes lectroniques et hydrauliques de gestion de latterrissage et du freinage de son nouveau long -courrier A350 XWB. Le contrat comprend la totalit des systmes ATA32 : systmes de freinage, dorientation des roues, dextension et rtraction des trains datterrissage et de surveillance des pneus, freins et atterrisseurs. Messier-Bugatti est la seule socit au monde capable de proposer ce type de package qui couvre lensemble des fonctions de freinage et datterrissage. Son offre sappuie sur les comptences globales du Groupe SAFRAN qui permettent de fournir des work packages comprenant le systme et lensemble des quipements ncessaires une fonction de lavion. Elle apporte des solutions techn ologiques pour rpondre aux exigences conomiques, de performance, de fiabilit et de respect de lenvironnement du programme A350 XWB.
Les systmes seront conus pour sadapter aux diffrentes versions de la famille A350 XWB.
Figure 2: systme ATA32 : systmes de freinage, dorientation des roues, dextension et rtraction des trains datterrissage et de surveillance des pneus, freins et atterrisseurs. Cest ainsi que la presse dans les quatre coins du globe a annonc la nouvelle. Messier Bugatti, membre de groupe Safran, participera au programme A350 XWB. Elle fournira un package complet de systmes : systme de freinage, systme dorie ntation, systme dextension/rtraction des trains datterrissage et systmes de surveillance. Lentreprise a g alement t slectionne pour fournir les roues et freins sur ce programme. Ce projet fait partie du systme dextension/rtraction des trains datterrissage, un des divers modules intgrs dans le calculateur ATA 32 responsable de contrle de freinage et trains datterrissage de l'avion airbus A350 XWB.
7
ENISo |
HCELL-engineering
Il consiste dvelopper un FPGA, faisant partie de llectronique de contrle de ce systme, selon la norme RTCA/DO-254 DAL A. Le travail demand par le client inclus le design, la vrification niveau RTL et postlayout, la gnration des rapports des tests et simulation ainsi que la rdaction des documentations ncessaires pour assurer la traabilit de ce travail.
5. Conclusion
Les systmes lectroniques sont devenus omniprsents dans les aronefs. Cet envahissement a donn naissance une ncessit : mettre laccent sur des diffrentes notions afin de pouvoir bien grer la situation. Cest ainsi que dans ce chapitre, on a introduit la notion du systme de scurit critique. On a aussi parl de la norme RTCA/DO-254 en finissant par prsenter en gnrale un exemple de systme critique dvelopp sous les recommandations de ce standard : Un FPGA intgrant le systme de contrle des trains datterrissage et de freinage dont la vrification est le sujet de ce projet de fin dtude.
ENISo |
HCELL-engineering
Chapitre
2:
Fondements de la conception et de la vrification des descriptions en HDL
Objectifs :
Prsentation des diffrents modles de flot de conception. Description des diffrentes mthodologies de vrification
ENISo |Fondements de la conception et de la vrification des descriptions en HDL
HCELL-engineering
Chapitre 2 :
Fondements de la conception et de la vrification des descriptions en HDL

1. Introduction
Les progrs techniques et la demande du march contribuent conjointement laccroissement exponentiel de la complexit des systmes intgrs. Les progrs accomplis dans les techniques de conception, dintgration et de fabrication des systmes sur pu ce, permettent de maintenir vrai la prdiction de Moore3 [7]. Cependant, les cots et les temps de conception et de vrification de tels systmes augmentent galement de manires exponentielles. Dans ce chapitre, on prsentera deux approches visant la conception et la vrification des systmes intgrs : le flot de conception traditionnelle et le cycle en V en clturant par exposer les diffrentes mthodologies de vrification.
2. Flot de Conception
La ralisation dun systme intgr est structure en plusieurs tapes ; une telle structuration est appele flot de conception. Dans cette section, on prsentera deux approches de flots de conception ainsi quune brve prsentation des langages de description matrielles.
2.1. Flot de conception traditionnelle

De plus en plus, la mthodologie de conception de circuits et de systmes fait appel une dmarche qui passe par une description dite de haut niveau, ne ncessitant pas de connaissance spcifique de la technologie de ralisation du composant.
La loi de Moore a t exprime en 1965 dans Electronics Magazine par Gordon Moore, un des fondateurs dIntel. Constatant que la complexit des semi-conducteurs doublait tous les ans cot constant depuis 1959, date de leur invention, il postulait la poursuite de cette croissance, ce qui fut rapidement nomme Loi de Moore. En 1975, Moore rvalua sa prdiction en posant que le nombre de transistors dans un microprocesseur double tous les deux ans. Et en 2007, il prvoyait l'obsolescence de sa loi dans 10 15 ans.
10
HCELL-engineering
Figure 3 : Flot de conception dun projet VHDL [29] Cette mthodologie sappuie sur lutilisation dun outil de synthse qui, partir dune descri ption sous forme graphique ou textuelle, va construire le schma logique capable de reproduire le fonctionnement logique dcrit, comme le montre la figure 3. Cette ralisation du schma se fera sous contrle dun ensemble de directives en utilisant les ressources matrielles (cellules logiques lmentaires, macro fonctions) proposes par la technologie cible choisie. La mthode traditionnelle consiste dcrire les composants au niveau RTL (Register Transfer Level) dans un langage de description matrielle (Hardware Description Language HDL), comme le VHDL. Le langage de description VHDL offre de nombreux avantages pour la conception des circuits et des systmes. Cependant les outils de synthse et les technologies cibles imposent souvent certaines contraintes ou limitations quil faut prendre en compte pour aboutir une descri ption synthtisable . La description dune fonction peut se faire diffrents niveaux de modlisation, de mme la synthse dun circuit peut tre vue diffrents niveaux : - Spcification ou Synthse systme : partir du cahier des charges, la synthse systme dtermine la description comportementale. Cest la transformation de plus haut niveau ralise manuellement par le concepteur. Elle permet le dcoupage logiciel/matriel et le partitionnement en sous circuits. [8] - Synthse darchitectures ou synthse comportementale : Les outils de synthse darchitectures transforment une description comportementale (Code) en une description au niveau transfert de registres (RTL pour Register Transfer Level) qui servira d'entre pour l'outil de synthse logique. [8] - Synthse logique : Elle dtermine la vue structurelle d'un circuit au niveau logique. En synthse logique, on manipule des spcifications logiques pour gnrer des interconnexions de primitives logiques. [8] - Synthse physique ou placement et routage : Elle permet de gnrer les motifs gomtriques des masques de fabrication des circuits partir dune description logique du systme.
11
HCELL-engineering
Ainsi que pour la simulation, on trouve trois niveaux dans le flot de conception des FPGAs comme lindique la figure 4 :
Figure 4 : Flot de conception dun FPGA [29]
Le premier niveau est la simulation au niveau de transfert de registre (RTL). Dans ce niveau, la syntaxe, et les fonctionnalits de base sont vrifies (sans les informations temporelles). Le second niveau est nomm la simulation fonctionnelle au niveau porte qui se fait aprs ltape de synthse, mais avant limplmentation. Dans cette tape la technologie des FPGAs nest pas spcifie. Cette simulation est utilise pour vrifier que le modle achve le processus de synthse avec les mmes fonctionnalits du niveau RTL. Le troisime, dans le processus de simulation des FPGA sappelle la simulation temporelle au niveau porte logique, o on implmente le modle sur la technologie cible FPGA.
2.2. Cycle en V
Le modle du cycle en V est un modle conceptuel de gestion de projet. Il est devenu un standard dans les annes 80. Cest un modle qui permet, en cas danomalie, de limiter un retour aux tapes prcdentes. Pour ce faire, toute description d'un composant est accompagne de tests qui permettront de s'assurer qu'il correspond sa description. Ceci rend valable la prparation des dernires phases (validation-vrification) par celles du dbut (construction du systme), et permet ainsi d'viter un problme courant de la spcification d'une application : noncer une spcification qu'il est impossible de vrifier objectivement aprs la ralisation. A la fin de la conception gnrale, le protocole et les jeux de test de lintgration doivent tre compltement dcrits.
12
HCELL-engineering
Figure 5: Cycle en V Mais, cette mthodologie prsente aussi des inconvnients qui se manifestent, en premier lieu, dans le fait que la validation du systme ne commence quaprs la mise en uvre de celui -ci; et en second lieu, dans labsence de format particulire pour dfinir les exigences et le cahier des charges du produit. Ce qui laisse la porte ouverte pour une potentielle ambigit et des contradictions possibles. Le remde ces problmes rside dans lamliorat ion du cycle en V par le biais des mthodes formelles de vrification.
Figure 6: Cycle en V amlior Ainsi, le cycle en V amlior parait le mieux adapt pour dvelopper un systme de scurit critique en harmonie avec le standard DO-254. Dans ce contexte, le client chafaude son propre cycle de vie pour le dveloppement de PLD : une mthodologie qui colle fortement avec les cosignes du standard de Hardware avionique et contrefait le cycle en V amlior.
13
HCELL-engineering
Ce flow de dveloppement rpond parfaitement aux exigences de la norme DO-254. La vrification et la validation de lapplication est assure dans les diffrents tapes du processus. La planification et la traabilit des recommandations du design et de vrification sont garanties par toute une hirarchie de documents crits formellement.
2.3. Langages de descriptions matrielle

Les langages de description de systmes matriels HDL (Hardware Description Langages) sont dvelopps spcialement pour supporter les concepts spcifiques aux composants matriels et leurs processus de conception. Lun des premiers langages normalis par lIEEE fut le VHDL [9], pour Very High Speed Integrated Circuit Hardware Description Language , sa premire version a vu le jour en 1987 et tait conue initialement pour la simulation des systmes matriels. Mais, rapidement, des outils de CAO de synthse logique, permettant la transformation automatique dune description HDL au niveau RTL en un modle au niveau porte logique, ont t dvelopps. Ainsi, un sous-ensemble de ce langage, et des styles de descriptions, ont t dfinis pour tre supports par ces outils de synthse [10]. Verilog est un autre HDL normalis par IEEE [11]. Ces langages ont la particularit de permettre la description multi-niveaux et dtre utiliss pour la spcification, la modlisation, la simulation et la synthse. Cette utilisation, tout au long du flot de conception, est un avantage auquel sajoute lindpendance par rapport aux diffrents outils CAO et aux cibles (ASIC, CPLD ou FPGA). Cette indpendance implique, entre autre, des notions de rutilisation (Reuse) et de proprit intellectuelle (IP): un bloc logique convenablement crit en VHDL peut tre rutilis et intgr dans la description dautres systmes ou composants. On verra comment cette notion de rutilisation augmente les exigences du processus de vrification.
3. Diversit des outils et mthodes de vrification 3.1. Gnralit sur la vrification des descriptions en HDL
A chaque tape de la conception, le concepteur doit sassurer que la nouvelle description obtenue est fonctionnellement quivalente la description qui la prcde dans le flot et quelle est toujours conforme aux spcifications. Ce mcanisme de sassurer que toute nouvelle de scription, obtenue par transformation automatique ou manuelle, est exempte derreurs, est un processus cl dans la conception. La validit des toutes premires spcifications, dont il faut assurer la correspondance avec lintention de celui qui les a crites, ne peut tre dmontre car le modle le plus abstrait dans le flot est inaccessible. Ce modle est dans lintention humaine dont la formalisation est irralisable ; cette validit, donc, ne pourra tre que partiellement tablie [12]. Certes, les spcifications sont la rfrence et lexactitude de la ralisation en dpend, mais les statistiques montrent que le pourcentage des erreurs, dont lorigine est lie de mauvaises spcifications ou des omissions dans les spcifications, est estim environ 4% [7]. Ltape la plus cruciale est de sassurer quaucune erreur nest introduite en implmentant les spcifications fonctionnelles en description RTL. Ceci revient vrifier que le fonctionnement de la description RTL est conforme avec le comportement spcifi. Elle est cruciale dans le processus de conception car, dune part, il a t dmontr [7] que 71% des dfai llances dun circuit intgr sont dues des erreurs conceptuelles ce niveau et, dautre part, la dcouverte tardive dune erreur de conception a des consquences catastrophiques sur les
14
HCELL-engineering
cots et les dlais de fabrication. On appelle cette tape, ltape de vrification. Dans la littrature, elle est dsigne par vrification ou encore par validation de conception . 3.1.1. Dfinitions Dans [12], la vrification fonctionnelle est dfinie comme le fait de vouloir tablir ou montrer la conformit dune implmentation avec les spcifications, et la validation comme le fait de vouloir sassurer quune ralisation accomplit le fonctionnement pour lequel elle a t conue. De mme, daprs les dfinitions de lIEEE [13], lactivit de vrification est le moyen dtablir la correspondance entre un produit et ses spcifications (on vrifie quon a bien fait le produit) et la validation est le moyen dassurer que le produit accompli t bien la fonction pour laquelle il a t conu (on valide quon a fait le bon produit). On trouve aussi une autre dfinition donne par lauteur de [14] : la vrification fonctionnelle est le fait de dmontrer que lintention de la conception est prserve dans limplmentation. Cette dfinition peut tre illustre par le diagramme de la figure 7. Ce diagramme reprsente, sous forme de cercles, lintention de dpart qui est lide abstraite de ce qui va tre conu, les spcifications qui sont les premires interprtations de cette intention, et enfin limplmentation. Chacun de ces cercles reprsente un comportement du circuit concevoir. Lobjectif de la vrification est de faire concider ces comportements. Donc par comparaison aux spcifications, la vrification va permettre : de dmontrer que la partie des spcifications implmente, qui correspond aux zones C et F, est correctement implmente. de dcouvrir les comportements implments et non spcifis (zones D et G). de pointer les comportements spcifis et non implments, correspondant aux zones B et E.
Figure 7: Diagramme de vrification [17]
Dans la suite de ce travail, on sintresse plus particulirement la vrification. Les mthodes de vrification prsentes ciblent plus prcisment la vrification dun systme, de sa spcif ication au niveau RTL. Ainsi, on peut dfinir la vrification dune manire compatible avec le contexte de ce travail, comme le processus de sassurer quune implmentation dans un la ngage HDL (ici VHDL) au niveau RTL, dun composant matriel, est conforme aux spcific ations fonctionnelles de ce composant
15
HCELL-engineering
3.1.2. Objectif de la vrification dune description en HDL Daprs la dfinition prcdente, deux types de vrification fonctionnelle peuvent tre identifis. Un type de vrification qui cherche prouver que le DUT est exempt derreurs conformment ses spcifications. Les mthodes de ce type cherchent prouver formellement lexactitude et la correction de limplmentation vis--vis des spcifications ; i.e. prouver labsence derreurs dans limplmentation. Il sagit des approches de vrification formelles. Malgr les avances accomplies dans les approches formelles, leur utilisation est restreinte des descriptions simples. En effet, leur principal dfaut est li lexplosion du nombre dtats [15]. Le deuxime type de vrification fonctionnelle cherche trouver les erreurs dans le DUT. Les approches qui ont cet objectif, dites approches dynamiques, cherchent exciter le DUT dans un environnement de vrification afin de dtecter des diffrences avec ses spcifications. Cest cette approche quon adaptera pour accomplir ce travail. On reviendra parler en dtails de ces deux approches dans la section 3.3. 3.1.3. Cots de la vrification Le cot de la vrification est dsormais trs lev surtout en termes deffort et de temps. En effet, il est estim que 70 % du temps de la conception est rserv la phase de la vrification. Le cot financier de la conception est aussi trs lev. Par exemple, pour un ASIC, le prix dun jeu de masques dans une technologie avance tant, aujourdhui, de lordre de 0,5 million deuros, une erreur dtecte aprs la fabrication du circuit entrane un surcot. Pour cette raison, le systme doit tre rigoureusement vrifi avant sa fabrication, ce qui permet de rduire de faon significative son cot [16].
3.2. Les diffrents approches de vrification

En fonction de ce qui est observ pour faire la vrification on distingue trois approches. La premire de ces approches est nomme bote noire ou Black Box en anglais. Elle consiste gnrer les vecteur de tests en se basant seulement sur les spcifications du design de fait que le composant vrifier nest pas accessible de lintrieur. Les avantages de lapproc he Black Box sont innombrables. En effet, Elle permet dviter de faire les mmes postulats que lquipe de design se qui mne avoir des vecteurs de tests qui ne dpondent pas de la mise en uvre du composant et interprter les rsultats des tests sans connatre les dtails dimplmentation. Donc, dans les tests en Black Box , lintrieur de systme est ignorer. Lingnieur de vrification doit se focaliser sur les relations entre les inputs et les outputs. Et dans ce cas, la qualification de la vrification ne peut tre faite que par les mtriques de couverture de code. Cela implique que la gnration des vecteurs de tests doit tre exhaustive pour couvrir touts les cas possibles. [17] La deuxime approche, dite bote blanche ou encore White Box et parfois vrification structurelle dans la littrature, consiste exhiber la structure interne du design, en rendant visible tous ses objets internes. Lingnieur vrificateur se base sur la connaissance de larchitecture interne pour faire dvelopper ces procdures de tests. Dans le cas idal, tous les cas possibles sont examins. Mais puisque cest pratiquement impossible, le but de cette a pproche reste tester chaque ligne de code au moins une seule fois [17].
16
HCELL-engineering
Enfin, la dernire approche est lapproche bote grise ou Gray Box qui, en ne rendant observable quune partie du systme, nest quune combinaison des deux approches prcdentes. Dans ce cas, le client exige que la vrification du FPGA se produise en Black Box . En effet, le processus de vrification, selon les recommandations du RTCA/DO-254, doit vrifier et valider le modle pour des diffrents niveaux : RTL, postlayout et physique. Lapproche White Box , une fois utiliser pour vrifier le code RTL, demeure inutile pour le modle postlayout et physique puisque la description interne nest plus la mme et dvelopper dautres environnements de test pour chaque niveau dabstraction savre indispensable. Donc cette approche, bien quelle est base sur une parfaite connaissance du design, semble peut pratique. De plus elle peut tre juge comme approche subjectif de vrification. Par contre lapproche Black box ne prsente pas ces inconvnients. Laffaire est donc close et la vrification en Black Box gagne.
3.3. Techniques de vrification

Dans les techniques de vrification, deux mthodes peuvent tre distingues. La distinction se fait sur le modle dexcution. Ces modles sont : Le Modle formel : la vrification formelle peut elle-mme tre dcompose en trois mthodes [18] : La vrification dquivalence permettant de dmontrer lquivalence entre deux modles du mme systme qui peuvent tre au mme niveau dabstraction ou des niveaux diffrents. La vrification de proprits permettant de vrifier si le circuit respecte les proprits qui ont t dfinies partir de la spcification du systme. La preuve de thorme dmontrant mathmatiquement que le systme ralise une fonction donne.
Le Modle dynamique ou par simulation : Dans la vrification dynamique, la vrification est effectue par simulation. 3.3.1. Vrification formelle La vrification formelle peut se dcomposer en trois catgories [19] qui sont : La vrification dquivalence : elle consiste montrer lquivalence entre deux ralisations dun circuit au mme niveau dabstraction ou entre le circuit raffin et le circuit dcrit un niveau dabstraction plus lev. Cette mthode est largement utilise pour vr ifier lquivalence entre les rsultats de synthse dun circuit et son modle RTL. Formality (Synopsys) est un exemple doutil proposant cette mthode de vrification dquivalence. Ce type de vrification se base sur la modlisation des circuits combin atoires sous la forme de diagramme de dcision binaire BDD4. Lquivalence est dmontre par comparaison des BDDs de chacun des deux modles. Pour les circuits squentiels, lquivalence est dmontre par comparaison des machines dtats finis FSM.
Voir glossaire
17
HCELL-engineering
La vrification de proprits : cette mthode se base sur la modlisation du systme sous forme de machine dtats finis ainsi que dun ensemble de proprits dcrites dans un langage logico-temporel que doit respecter le circuit par exemple en utilisant le langage PSL. Ce langage repose ainsi principalement sur le langage SUGAR, dvelopp originellement par IBM dans le cadre de la vrification formelle pour la dmonstration de proprits. Vrifier quun circuit respecte une certaine proprit consiste montrer que quel que soit lensemble des combinaisons possibles en entre du circuit et quel que soit le chemin dexcution, la proprit est respecte. Cette opration est ralise en parco urant lespace dtats de la machine dtats finis et en dterminant si la proprit est vr ifie ou non. Cependant, cette mthode souffre de limitations lies la taille de lespace dtats du circuit qui croit exponentiellement avec le nombre de variables dtat. Ainsi, les outils actuels permettent dadresser des circuits ayant quelques milliers de variables dtats. Parmi les outils commerciaux proposant la vrification de proprits on peut citer RuleBase PE [20] (IBM), Magelan [21] (Synopsys) et Insicive Formal Verifier [22] (Cadence). La dmonstration du thorme : cette mthode prsente le problme de la vrification sous la forme dun thorme. Ensuite un ensemble daxiomes est utilis pour construire la preuve du thorme. La preuve de thorme ncessite souvent la dmonstration de rsultats intermdiaires et nest pas compltement automatise. La dmonstration de th ormes est actuellement une tche trs difficile et rserve aux experts. On peut galement noter que la preuve de thorme est applique la vrification de blocs matriels comme les units de calcul en virgule flottante embarques dans les processeurs [19].
Ces diffrentes mthodes utilisent toutes un modle formel du circuit (BDD, FSM, thorme). Enfin en cas de bug, ces mthodes dterminent en gnral un scnario permettant de reproduire le bug en simulation. Ces mthodes ne ncessitent pas lutilisation de vecteur de test afin dachever la vr ification, elles sont exhaustives. Malheureusement, la complexit et la taille des systmes actuels rendent ces mthodes inapplicables tous les types de circuit. Ces mthodes sont cependant trs efficaces pour les blocs matriels de petite et moyenne taille. Reste dire aussi que les mthodes formelles de vrification ainsi que les outils ne sont pas qualifies par les autorits de FAA. Ce qui mne utiliser la vrification dynamique.
3.3.2. Vrification dynamique La vrification fonctionnelle base sur des approches dynamiques consiste imiter le comportement du DUT dans diffrents scnarios. Ces scenarios se traduisent par la gnration dun ensemble de donnes ; appel stimuli, appliquer sur les entres du DUT. Limitation nest alors que lexcution du DUT avec ces donnes. Pour vrifier et dtecter les erreurs, les rponses du DUT sont compares avec des rponses de rfrence. Ainsi, dans ces approches, lenvironnement de vrification, indpendamment de la plateforme dexcution, est bas sur trois mcanismes : un mcanisme de gnration des stimuli, un mcanisme de vrification des rponses, et un mcanisme pour lvaluation de la progression de la vrification. La figure 8 illustre, avec un schma simplifi, un environnent de vrification qui montre ces trois aspects.
18
HCELL-engineering
Figure 8: Environnement de vrification dynamique [17]
Selon cette figure, un environnement de test est une interaction de diffrents bloques qui sont : Le DUT : cest le circuit ou la description vrifier. La plateforme de vrification : La plateforme utilise dans la vrification dynamique, pour imiter le comportement du DUT excite avec les stimuli, peut tre un simulateur logiciel, un mulateur matriel gnrique ou une plateforme de prototypage. La qualification de la vrification: La plupart des outils offrent une fonctionnalit intressante pour amliorer la qualit de la vrification savoir le recueil dinformations sur le taux de couverture. Suivant les cas, cette mtrique peut tre obtenue directement par lintermdiaire de loutil ou bien par lutilisation dautres utilitaires spcifiques. Gnrateur des stimuli : Le rle de ce composant est dengendrer les donnes ncessaires pour stresser suffisamment le DUT, afin de vrifier tous les comportements possibles de cette dernire, dans des dlais raisonnables. De cette dfinition dcoulent trois principes fondamentaux que tout gnrateur de stimuli, quelque soit sa stratgie, doit satisfaire. Le premier de ces principes est la validit des stimuli ; cette validit est spcifie par les contraintes logico-temporelles dfinissant les protocoles dinterfaage du DUT avec son environnement dutilisation [14-23]. Le deuxime principe est ladquation des stimuli aux critres de compltude ; ces critres, spcifis par le plan de vrification, dfinissent lensemble des niveaux de couverture exigs pour arrter la vrification. Enfin, loptimalit est ncessaire pour rduire les dlais. Le principe dadquation, qui implique une approximation de compltude, et le principe doptimalit sont contradictoires, ce qui ncessite un compromis entre ces deux principes. Vrificateur des repenses : Pour certifier la conformit dun comportement du DUT, engendr par des stimuli, au comportement spcifi, il faut un mcanisme de vrification des rponses du DUT avec les prdictions des spcifications. Les mcanismes danalyse et de comparaison peuvent tre classs, dune part, selon la rfrence de comparaison et, dautre part, selon les objets observs et compars. Au niveau de la rfrence de comparaison, on distingue entre modles de rfrence dcrits dans un niveau dabstraction co mpatible avec la vrification et modles transactionnels [24]. Dans le cas dun modle de rfrence, les rponses du DUT et du modle sont compares pour vrifier leur quivalence. Alors, que dans le cas dun modle transactionnel, des Checkers de temps et de
19
ENISo |
HCELL-engineering
donnes capturent le comportement du DUT et le comparent avec des prdictions calcules selon les spcifications.
3.4. Les langages spcifiques pour la vrification du matriel HVL

Les outils et mthodes bass sur lenvironnement de test exploitent des langages spcifiques. Les plus couramment utiliss dans lindustrie sont le langage e et OpenVera [25]. Ces langages reposent sur un modle orient objet qui permet de raliser labstraction et de faciliter la rutilisation. Ils offrent la construction standard de langage de programmation comme le C++, et comme ceux des langages de description du matriel (HDL). Ils possdent en outre des primitives spcifiques qui permettent la dfinition des contraintes. Enfin, ils intgrent un ensemble de primitives exclusivement destines la vrification : taux de couverture et vrification de proprits temporelles (assertions). Reste dire que ces langages spcifiques ne sont pas qualifis par les autorits de FAA. Ce qui pousse utiliser le langage de description avec lequel le design vrifier est crit.
4. Conclusion
La complexit et la criticit des systmes lectroniques ont cr la ncessit de mettre en uvre des flots de conception et des mthodes de vrification afin de contrler la qualit et le cot des applications dvelopps. Dans ce contexte, on a prsent dans ce chapitre les diffrents flots de conception, et on a dfini la tche de vrification et prsent ses motivations, ses dfis, ses techniques, ses langages et ses outils. On a donc essay de clarifier lensemble des aspects et problmes qui lentourent tout en motionnant les choix faits pour ce projet, sujet de ce texte.
20
ENISo |
HCELL-engineering
Chapitre
3:
Conception et spcifications fonctionnelles
Objectifs :
Prsentation des justificatifs de choix de la cible dimplmentation Prsentation des diffrents outils et langages de programmations utiliss Exposition des spcifications fonctionnelles du projet
21
ENISo |Conception et spcification fonctionnelles
HCELL-engineering
Chapitre 3 :
Conception et spcification fonctionnelles

1. Introduction
Le choix de la cible que vise lapplication est un choix crucial. Il est effectu selon plusieurs critres. Dans ce chapitre, on va donner les justificatifs du choix de ACTEL A3P600 comme cible dimplmentation en passant par rpondre la fameuse question : Pourquoi FPGA et non pas ASIC ? Ensuite, on va numrer les diffrents outils de travail quon utilisera le long du projet. Ainsi, on arrive dfinir tous les lments qui ont une relation avec le travail prsent dans ce manuscrit. On finira donc ce chapitre par une prsentation des spcifications fonctionnelles du FPGA, sujet de vrification.
2. Prsentation du projet
Le projet consiste dvelopper, selon la norme DO-254 DAL A, un FPGA qui fait partie du systme dextension/rtraction des trains datterrissage, un des divers modules intgrs dans le calculateur responsable de contrle de trains datterrissage et d e freinage l'avion airbus A350 XWB. Le module en question assure des diffrentes fonctions tels que : la lecture des donnes issues de diffrents capteurs installs sur les divers composants qui interagissent dans dextension/rtraction des trains datterrissage tels que les portes et les roues. Lmission et la rception dune multitude du signal en utilisant des diffrentes interfaces et protocoles de communication tels que linterface ARINC429, le bus SPI et dautres types de communication srie. Excution de deux modes de fonctionnement: mode Power_up_TEST et mode de fonctionnement normal.
22
HCELL-engineering
3. Choix de la cible dimplmentation 3.1. ASIC ou FPGA

Certes, chaque camp a ses vertus et ses vices qui poussent le joindre ou le repousser. Dans ce qui suit, on prsentera les avantages et les inconvnients de chaque technologie. Puis on discutera les performances de chacun afin de choisir la solution adquate pour implmenter le circuit en question.
3.1.1.
ASIC
ASIC est lacronyme de Application-Specific Integrated Circuit . Ce type de circuit est en gnral utilis lorsque le traitement dsir ncessite des performances trs leves, que ne peuvent fournir des architectures gnrales. Dans ce cas, l'architecture implante est optimise en fonction de l'algorithme de traitement. Cette solution offre aussi les avantages suivants : Rduction du cot final du systme. Augmentation de la scurit du produit. Introduction de fonctionnalits spcifiques. Diminution du nombre de composants du systme. Augmentation de la fiabilit du systme. Rduction de la taille du systme. Utilisation efficace de la surface de circuit imprim. Rduction de la consommation en nergie. Augmentation des performances (vitesse).
Mais elle souffre de certains inconvnients majeurs : un simple changement dans la spcification de lapplication peut signifier la r -conception presque complte du circuit, le cot, le temps de dveloppement et le manque de flexibilit en sont pour cause. Ainsi, en terme dimplmentation (ou de ralisation physique), la technologie ASIC consiste raliser les composantes directement sur une puce, cest--dire en exploitant les transistors de cette puce. Il en rsulte un circuit trs performant, mais coteux, long produire et dont la conception peut engendrer de nombreuses erreurs ce qui est intolrable pour un systme de niveau DAL A.
3.1.2.
FPGA
Les FPGAs (Field Programmable Gate Array ou Champ Matriciel de portes Programmables), ce sont des Composants, constitus dun ensemble de ressources logiques lmentaires conf igurables pouvant tre mises en relation par un rseau dinterco nnexions aussi configurable. [26]. Ils ont t prsents au march en 1985 par XILINX Corporation . Depuis cette date, diffrents FPGAs ont t dvelopps par plusieurs autres compagnies comme Altera, Atmel, ACTEL, etc. les diffrences majeures des FPGAs par rapport aux formes antrieures de la logique programmable sont la structure interne et la dimension. Un FPGA ou champ Matric de Portes Programmables, est un composant VLSI Very Large Scale Integration , dont la caractristique fondamentale est quil est reconfiguration, de ce fait Il prsente une grande souplesse qui permet de le rutiliser volont dans des algorithmes diffrents en un temps trs court. Il consiste en une matrice de blocs logiques relis par un rseau dinterconnexions gnrales. Il se compose principalement de trois composants fondamentaux : les blocs logiques, les blocs dentres/sorties et les interco nnexions programmables (figure 9).
23
HCELL-engineering
Figure 9 : Elments de base dun FPGA [29] Les fabricants de FPGAs (Field Programmable Gate Arrays) proposent maintenant des macros cellules de traitement du signal directement implantables sur leurs circuits. Souvent paramtrables en taille, ces cellules vont des blocs de base (additionneurs, multiplieurs, dcaleurs...) aux fonctions plus complexes (oprateurs flottants, filtres FIR). Laspect configurable a videmment un cot : la surface de silicium et la consommation lectrique dune solution FPGA sont bien suprieures celles de son quivalent ASIC. Les interconnexions programmables, par exemple, utilisent la majeure partie de la surface dun FPGA, tandis quun ASIC utilisera des connexions en nombre limit et optimises en surface. De plus, limplantation dun algorithme sur FPGA nutilise jamais 100% des capacits du circuit, laissant une partie du matriel inutilis (mais consommant toujours !). [29]
3.1.3.
Discussion et justification du choix
Le choix entre lutilisation dune technologie ASIC ou FPGA est gnra lement dtermin par deux critres qui sont la performance du circuit et la quantit de pices produire. En termes de performance et pour une mme technologie dimplmentation, les ASICs pre nnent lavantage sur les FPGAs. Cela est en partie li aux conne xions qui, dans les FPGAs, sont parasites par les lments de la couche reconfigurable et qui sont contraintes dexploiter des ressources de routage reconfigurables existantes. Dans la pratique, on observe que les FPGAs exploitent des technologies de gravure plus rcentes que celles utilises pour la fabrication de puces ddies. En effet, le passage de nouvelles technologies est coteux et les concepteurs prfrent utiliser des technologies matrises et connues. Ainsi, un systme ralis de faon ddie sur puce peut parfois tre ralis de faon aussi performante sur un FPGA qui exploite une technologie de gravure plus rcente : la transition vers de nouvelles technologies de gravures compense les pertes introduites par la couche reconfigurable du FPGA. La quantit de pices produire est aussi un critre de slection. En effet, si les ASICs sont coteux la conception, le cot de production dune puce est relativement faible une fois le masque ralis et le circuit valid. En revanche, le cot dun prototypage sur FPGA est relativement faible puisquil ne fait pas intervenir de mcanisme de gravure sur silicium. Une fois
24
HCELL-engineering
la validation du prototype termine, le prix de revient dune pice inclut ncessairement le prix dachat dun FPGA. Par ailleurs, Les ASICs structurs sont une solution intermdiaire, ils sont mi-chemin entre les FPGAs et les ASICs. Ils sont construits depuis une configuration de FPGA mais sont toutefois gravs sur silicium. Seule une partie des masques est spcifique au circuit grav, offrant un compromis cot-performance intressant. Les performances toujours croissantes des FPGAs et leur grande flexibilit en font un support de ralisation physique adquat pour ce projet. Ainsi, le tableau suivant prsente un rcapitulatif de ce qui a t cit toute lheure.
Tableau II: Tableau comparatif entre les performances dun FPGA et un ASIC Technologie ASIC FPGA Performance Excellente Trs bonne Surface Faible Grande Consommation Faible Grande Flexibilit Nulle Bonne TTM5 Trs long Court
3.2. SRAM_based FPGA ou Flash_based FPGA

Les circuits FPGA base de cellule SRAM ou Flash sont des circuits programmables deux technologies diffrentes. Le choix de la cible de limplmentation de ce projet est bas sur le s critres suivants : Limmunit contre les SEU, la faible consommation dnergie et la scurit des donnes et bien videment le cot. Dans cette section, on va assister une brve tude comparative des deux technologies.
3.2.1.
SRAM_based FPGA
Cest la technologie traditionnelle de fabrication des circuits FPGA. Ces circuits prsentent les caractristiques suivantes : -
Circuits o la configuration du rseau d'interconnexion est stocke en mmoire vive SRAM (exemple: FPGAs de Xilinx). A chaque mise sous tension et reset, ces circuits doivent rcuprer leur configuration partir d'une composante externe (EPROM, microprocesseur hte, etc.) Permet la conception de systmes reconfigurables en opration, c.--d. la reconfiguration dynamique. Ces technologies brouillent la frontire logiciel-matriel. Reprogrammation facile et rapide (ne ncessite pas de voltages levs). Nombre de cycles d'criture infini.
3.2.2.
Flash_based FPGA
Les FPGAs base de Flash utilisent des cellules mmoire Flash non volatile pour stocker la configuration du circuit. Ils semblent avoir la confiance du client pour leurs caractristiques uniques qui les distinguent par rapport au FPGAs base de cellules SRAM.
5
Voir glossaire
25
HCELL-engineering
En effet ces circuits sont connus pour les particularits suivantes : La non-volatilit des cellules de configuration : cest une vertu majeure puisque elle est la base des autres : la scurit des donnes, limmunit contre les radiations, lhabilit dtre actif au dmarrage et bien videment la consommation Solution mono puce : Cette proprit descend directement de la non-volatilit des cellules de configurations. En effet, on na pas besoin dune mmoire externe pour stocker la configuration du FPGA. Ce qui aide gagner de points de vue cot du systme global. Scurit : Gnralement, les applications base des circuits FPGAs sont victimes de piratage pendant la phase de reconfiguration partir dune mmoire externe. Cela savre impossible dans le cas des FPGAs base de cellules mmoire Flash. Faible consommation : Selon les tudes menes dans [27], la puissance dissipe par les ressources de routage est de lordre de 60% de la puissance totale dissipe. En effet, et puisque les FPGAs base de cellules mmoire Flash utilise presque le 1/3 ou le 1/2 des transistors utiliss par les cellules SRAM (6 ou 4 pour la technologie SRAM contre seulement 2 pour la technologie Flash, la consommation est nettement rduite et peut ne pas dpasser quelques W (exemple : FPGA IGLOO de ACTEL). Actif au dmarrage (Power-Up) : Cette caractristique issue directement du non volatilit des cellules configuration Flash peut pargner lnergie et le temps de reconfiguration de puis une mmoire externe du circuit lors de la mise sous tension. Immunit contre les SEU : plusieurs tudes ont t menes dans cette voie qui ont mont que les FPGA base de cellules de configuration Flash se caractrisent par une immunit contre les radiations contrairement aux FPGAs base de cellules de configuration SRAM [28].
3.2.3.
Discussion et justification du choix
Comme pour les ASIC, la nature non volatile reprogrammable de dispositifs bass sur des cellules de configuration Flash fournit les principaux avantages par rapport la volatilit des offres base de SRAM. En effet, FPGA base de cellules de configuration Flash utilise une cellule de programmation Flash pour le contrle de la grille de l'interrupteur dans le tissu FPGA. Chaque commutateur a une porte un seul sens et un portail Flash flottant qui contrle l'tat de l'interrupteur. En revanche, les FPGA base de cellules de configuration comptent sur un lment SRAM six ou quatre transistors pour le contrle de commutateur.
Figure 10 : Cellule Flash vs Cellule SRAM

26
HCELL-engineering
De plus, et contrairement aux dispositifs base de Flash, l'lment volatile SRAM responsable de la programmation FPGA doit tre charg partir d'un dispositif externe tous mise sous tension du systme. Cette diffrence signifie que les FPGA base de Flash ne ncessitent pas des circuits de soutien supplmentaires et sont actifs au dmarrage. Ce qui peut se traduire par des importantes conomies au niveau des cots, surface, et bien videment nergie. Le troisime point se manifeste dans limmunit contre les radiations. Le dfi pour un FPGA adapt pour des applications aronautiques ou spatiales est principalement la tolrance contre SEU et cela concerne essentiellement les lments de commutation (table SRAM, Flash). Selon [28], les FPGAs base des cellules de configuration Flash gagnent contre celles base de SRAM vue leur structure interne (seulement deux transistors donc cest moins probable quils soient victime de radiation que les six ou quatre transistors dune cellule S RAM) et labsence dune mmoire externe qu partir de laquelle la configuration est charge (les mmoires sont les premires victimes des effets de radiation). Ainsi, le choix est de FPGA base de la technologie Flash semble justifi. La maison ACTEL est un leadeur du march et offre le meilleur rapport qualit/ prix. Ce qui a convaincu le client choisir lA3P600 de la famille ProASIC3 quon prsentera dans le paragraphe suivant.
3.2.4.
Cible dimplmentation ACTEL A3P600-PQFP208I
Les FPGAs de la famille ProASIC3 sont des circuits programmables grain fin. Cela, associ avec le nombre abondants des switchers de Flash, offre une immense flexibilit pendant le routage. Ainsi les designers ont une grande marge de libert pour implmenter leurs propres systmes complexes. Le tableau suivant est extrait du document technique (data-sheet) du circuit. [35] Tableau III: Gnralits sur les ressources de FPGA A3P600 de la famille ACTEL ProASIC3 extrait du Data-sheet du composant [35] ProASIC3 Devices Portes logiques VersaTiles (D-flip-flops) RAM (kbits) Blocks mmoires de 4,608-Bit FlashROM (Bits) Secure (AES) ISP PLL intgr VersaNet Globales Bancs I/O Nombre max. I/Os utiliser A3P600 600 K 13.824 108 24 1k Oui 1 18 4 235
A3P600 est compos dun nombre immense de VersaTiles . Chaque VersaTile peut tre configur soit comme une fonction logique 3 entres, soit comme une bascule D (sans ou avec enable). Et cela est ralisable en programmant le switcher Flash appropri. La figure suivante montre comment les ressources sont organises dans le circuit.
27
HCELL-engineering
Figure 11: Architecture globale du circuit A3P600 [35]
4. Langages de programmation 4.1. VHDL

Dvelopp dans les annes 80 aux tats-Unis, le langage de description VHDL est ensuite devenu une norme IEEE numro 1076 en 1987. Rvise en 1993 pour supprimer quelques ambiguts et amliorer la portabilit du langage, cette norme est vite devenue un standard en matire d'outils de description de fonctions logiques. A ce jour, on utilise le langage VHDL pour [29] : Concevoir des ASICs, Programmer des composants programmables du type PLD, CPLD et FPGA, Concevoir des modles de simulations numriques ou des bancs de tests.
L'lectronicien a toujours utilis des outils de description pour reprsenter des structures logiques ou analogiques. Le schma structurel que l'on utilise depuis si longtemps et si souvent n'est en fait qu'un outil de description graphique. Aujourd'hui, l'lectronique numrique est de plus en plus prsente et tiens bien souvent remplacer les structures analogiques utilises jusqu' prsent. Ainsi, l'ampleur des fonctions numriques raliser impose l'utilisation d'un autre outil de description. Il est en effet plus ais de dcrire un compteur ou un additionneur 64 bits en utilisant l'outil de description VHDL plutt qu'un schma. [29] Le deuxime point fort du VHDL est d'tre un langage de description de haut niveau. D'autres types de langage de description, comme l'ABEL par exemple, ne jouit pas de cette appellation. En fait, un langage est dit de haut niveau lorsqu'il fait la plus possible abstraction
28
HCELL-engineering
de l'objet auquel ou pour lequel il est crit. Dans le cas du langage VHDL, il n'est jamais fait rfrence au composant ou la structure pour lesquels on l'utilise. Ainsi, deux notions trs importantes apparaissent [29] : Portabilit des descriptions VHDL, c'est--dire, possibilit de cibler une description VHDL dans le composant ou la structure que l'on souhaite en utilisant l'outil que l'on veut (en supposant, bien sr, que la description en question puisse s'intgrer dans le composant choisi et que l'outil utilis possde une entre VHDL). Conception de haut niveau, c'est--dire qui ne suit plus la dmarche descendante habituelle (du cahier des charges jusqu' la ralisation et le calcul des structures finales) mais qui se limite une description comportementale directement issue des spcif ications techniques du produit que l'on souhaite obtenir.
4.2. Langage Script Tcl

Le langage scripts Tcl semble tre trs intressant utiliser pour assurer la traabilit que recommandent les autorits de RTCA dans leur standard RTCA/DO-254. Le Tcl est un langage scripts facile apprendre et manipuler. Il permet la gestion des fichiers ce quil le rend idal pour gnrer des comptes rendus des simulations effectues. En effet, lutilisation des scripts Tcl pour grer les tests et leurs traabilits semble tre trs bnfique. Un script Tcl permet d'automatiser les commandes ncessaires pour les diffrentes tapes d'une simulation, soit: cration des librairies Work ou spcifique. compilation de l'ensemble des fichiers du projet inclus le Testbench. chargement du Testbench. ouverture des fentres et placement de celles-ci. ajout des signaux visualiser ou chargement du format de la fentre wave pralablement sauve. lancement de la simulation.
En addition, toutes les commandes et options de configuration de Modelsim SE sont disponibles puisque le Modelsim SE, lui-mme, est crit en Tcl.
Figure 12: Exemple de Macro crite en Tcl

29
HCELL-engineering
Les fichiers crits en scripts Tcl sont disponible sous deux extensions : gnrale *.tcl et spcifique pour Modelsim SE *.do.
5. Outils de travail 5.1. Emacs

Emacs est lditeur de texte cre, en 1984, par Richard Stallman, linstigateur principal du projet GNU. Il est disponible dans tout systme GNU/Linux qui mrite ce nom. Lun des principaux intrts dEmacs rside dans les modes qui spcialisent son comportement en fonction du type de fichiers sur lequel on travaille. Cela se rvle trs apprciable lorsque, par exemple, on produit un document en C, en VHDL ou en Tcl.
Figure 13 : Exemple de Module VHDL sous Emacs
5.2. Modelsim SE
Modelsim est le simulateur VHDL/Verilog/System C mixte le plus rpandu au monde. La popularit des produits Modelsim est le reflet de l'engagement de Mentor Graphic fournir la meilleure technologie de simulation, la performance, le support et le prix. Les produits Modelsim ont une architecture unique utilisant des technologies comme la compilation directe optimise pour rduire les temps de compilation et de simulation, un kernel unique de simulation et Tcl/Tk comme langage de script pour un plus grand niveau d'ouverture et des mises au point rapides. Exclusives Modelsim, ces innovations permettent de grandes performances en compilation/simulation, l'entire libert d'utiliser le VHDL et/ou le Verilog, ainsi qu'une capacit ingale de personnaliser le simulateur. Enfin les utilisateurs apprcient la facilit d'utilisation et la qualit du support technique.
30
HCELL-engineering
Figure 14 : Environnement Modelsim
5.3. Libero
Libero est un outil complet de systmes ddi la conception des FPGAs ACTEL. Il regroupe le schma lectronique, la conception de HDL, la synthse et la simulation. Libero IDE inclut plusieurs outils tels que les graphiques de Mentor, le SynaptiCAD, et le Synplicity de Synopsys. Ces outils, combins avec les outils dvelopps par ACTEL permettent de contrler rapidement et facilement les conceptions ciblant ses FPGAs.
Figure 15 : Interface du Libero
En effet Libero offre les options suivantes : -
Gnration dIP prdfinie (avec le SmartGen et les bibliothques IP DirectCore). Manipulation des descriptions VHDL /Verilog niveau RTL ou comportemental. Synthse des codes VHDL / Verilog. Mise en uvre Physique, floor planning et routage. Analyse de temps et de frquence. Analyse de la puissance utilise.
31
HCELL-engineering
Lors de la vrification, les bibliothques dACTEL, incluses dans Libero, seront appeles pour excuter la vrification du modle postlayout.
6. Spcifications fonctionnelles6 6.1. FPGA identification

Ce module, comme son nom le fait rfrence, sert identifier et activer lFPGA. Les entres de cette interface, BOARD_SEL et PIN_PROG jouent le rle dun code didentification ou une cl dactivation du circuit pour la suite de traitement dont il est conu pour faire.
6.2. Watchdog interface

Le WDG est un dispositif de protection conu pour sassurer quune dfaillance de fonctionnement du circuit ne survient et ait des consquences non souhaitables sur le reste du systme. Il surveille un tat, un port...Aprs un certain temps (TIME REFRESH), le compteur de WDG doit tre remis 0 sinon il active son signal de sortie, qui sert comme un ENABLE pour dautres blocs dans le calculateur, aprs lcoulement dune priode prdfinie (WDG t imeout). Le rle de cette interface est de gnrer des impulsions conscutives, selon un scnario bien dfini (dcrit dans la figure suivante), qui serviront effectuer un redmarrage du compteur du WDG.
RESET
X ms Y ms Y ms
WDG_pulse
a ms
b ms
WDG_TIMEOUT_sig
WDG_power_up_test_ validity
WDG_power_up_test_ in_progress
Figure 16 : Organigramme de WDG interface Pendant le mode Power_up_TEST, la priode (X) qui spare deux impulsions conscutives est suprieure WDG timeout pour tester la capacit du chien de garde de fonctionner correcte6
Pour des mesures de confidentialit, on va se contenter de dcrire quelques fonctionnalits du systme sans trop entrer dans les dtails.
32
HCELL-engineering
ment. Des diffrentes mesures de signal WDG_TIMOUT_sig sont prises dans des diffrents instants pour pouvoir valider son comportement. Cependant, durant le mode de fonctionnement normal, les impulsions sont gnres chaque fois que la priode TIME REFRESH (Y) est coule.
6.3. ARINC interface

LARINC 429 est un des plus anciens bus avionique. Dvelopp par lAeronautical Radio INCorporation en 1977, ARINC 429 est une spcification qui dfinit la faon dont les quipements et les systmes avioniques doivent communiquer entre eux. Ce bus est un bus de donnes simple utilisant un seul metteur et de 1 20 rcepteurs par bus. [30]
Figure 17 : architecture de bus ARINC 429 Il sagit donc dune structure point point. La communication est unidirectionnelle et afin de raliser une communication full-duplex entre les systmes, on utilise deux bus monts en ttebche, un dans chaque direction. Un bus ARINC 429 utilise deux fils pour transmettre un encodage bipolaire avec Retour Zro, dit "RZ".
Figure 18: Encodage bipolaire avec retour zro (ARINC 429) Les mots de 32 bits sont spars par 1 bits-time NULL, il ny a donc pas besoin dun 3me fil pour le signal dhorloge. Le bus unidirectionnel utilise une paire torsade. ARINC 429 su pporte deux types de dbit : un haut dbit de 100 Kbps et un faible dbit variant entre 12 Kbps et 14,5. LARINC 429 utilise des trames dont le format est prdfini incluant 5 champs pr imaires, en gnral :
33
HCELL-engineering
- huit bits pour le label (nature de linformation). - le SDI (Source / Destination Identifier). - Data Field (le champ de donnes). - le SSM (Sign / Status Matrix). - un bit de parit (Odd parity bit).
Figure 19: Format de trame ARINC 429 Ainsi, de par la simplicit de sa topologie et des protocoles utiliss, ce bus est dune trs grande fiabilit. Et comme il ny a quun seul metteur par paire de fils, lARINC 429 est bien videmment dterministe [30]. Dans ce cas, on va opter pour le choix dune communication full-duplex haut dbit. Pour ce faire, linterface ARINC contient essentiellement quatre bloques : metteur, rcepteur, un bloque de boucle retour (Loop back) et un bloque pour le mode TEST (Power_up_Test) comme lindique la figure suivante :
Figure 20: Schma bloque de linterface ARINC 429 Pendant la phase Power_up_Test, les bloques actifs sont ARINC emitter et ARINC Power_up_Test. Ce dernier collecte les donnes entrantes et sortantes afin deffectuer des tests sur la validit des informations quils contiennent. Une fois que le temps du mode test est coul, Linterface ARINC passe au mode de fonctionnement normal. Lors de ce mode, trois
34
HCELL-engineering
bloques sont actifs, ARINC emitter, ARINC receiver et ARINC self_test. Ce dernier effectue un contrle sur les donnes mises afin de sassurer de leur validit.
6.4. SPI interface

Une liaison SPI (pour Serial Peripheral Interface) est un bus de donne srie synchrone baptis ainsi par Motorola, et qui opre en Full Duplex. Les circuits communiquent selon un schma matre-esclaves, o le matre s'occupe totalement de la communication.
Figure 21 : Connexion SPI Master/Slave (s) Plusieurs esclaves peuvent coexister sur un bus, la slection du destinataire se fait par une ligne ddie entre le matre et l'esclave appele chip select (CS). Lmission se fait en envoyant premirement le MSB. Le bus SPI contient 4 signaux logiques

LGPX_SL_SCLK Horloge (gnr par le matre) LGPX_SL_MOSI Master Output, Slave Input (gnr par le matre) LGPX_SL_MISO Master Input, Slave Output (gnr par l'esclave) LGPX_SL_CS Chip Select, Actif l'tat bas, (gnr par le matre)
35
HCELL-engineering
Figure 22 : Trames changes selon le protocole SPI [36] Lorsque le signal LGPX_SL_CS_N devient inactif, le SPI master envoi une commande lesclave, o il prcise ladresse de dbut et le nombre de registre quil demande. Au mme temps l, le master reois de la part de lesclave le premier status qui contient ltat de la trame envoye prcdemment et user_word, qui est le code identificateur de cet esclave. Lors de lmission de data par lFPGA travers le LGPX_SL_MISO, le matre envoi des donnes fictives travers le LGPX_SL_MOSI pour mietter lmission du slave et cela pour des mesures de synchronisation. La validit des donnes changes est assure par le calcul de CRC 16-bit CCITT, de part et dautre du bus SPI : Lors de lmission du dernier mot, le ma ster envoi son propre code CRC. Lesclave vrifie ce code en le recevant. Il le recalcule. Si le rsultat quil trouve est gale 0x0000 alors le compte est bon. Dans le cas chant, il s ignale cette erreur de transmission au matre en mettant le 8me bit du deuxime statut 1. Puis il calcule son propre code CRC et le transmet.
6.5. SPY interface

Comme son nom lindique, cette interface espionne les signaux internes du FPGA qui sont ncessaires pour tablir une vrification Black Box ou peut tre pour des ventuels traitements effectus par dautre module dans le calculateur. Lmission est en srie. Le module utilise un start_word et un end_word pour sassurer de la validit des informations mises. Les donnes transmises sont organises sous formes de 16 mots chacune de taille 16 bits. La dure de chaque bit est gale 610 cycles dhorloge. Aprs lmission de la trame complte, les 16 mots plus le prambule, une latence est recommande avant denvoyer la trame prochaine. Pendant ce temps, linterface SPY met des zros.
6.6. SDA interface

Le SDA interface est un autre bloque de communication avec le monde extrieur au FPGA. La trame envoye a la forme suivante (en envoyant le LSB en premier lieu) :
36
HCELL-engineering
Figure 23: Format de trame SDA_LGPX Lmission est en srie. Linterface utilise un bit de parit calcul pour les bits allant de 1 31 pour sassurer des informations mises. Il doit tre toujours impair. Les donnes sont transmises sous formes des trames de taille 32 bits chacune. La dure de chaque bit est gale 610 cycles dhorloge. Une fois lmission de la trame est termine, lactivit de lmetteur est corrompue pendant une priode prdfinie avant denvoyer la trame prochaine. Pendant ce temps, linterface SDA met des zros. Pour la rception, cet interface reois des trames de deux autres bloques. Ces trames sont organises de la manire prsente dans la figure suivante :
Figure 24: Format des trames reues La lecture est effectue au milieu de la dure du bit. En effet, et puisque le bit dure 610 priodes dhorloge, la capture de sa valeur se fait des instants prcises selon la formule su ivante : T lecture = 350 + 610 * N Avec N varie entre 0 et 31. Le SDA interface effectue bien videment un contrle sur les donnes reues. En effet, le signal SDA_validity sera inactif si : le rcepteur ne reoit rien pendant une priode SDA _timeout aprs linactivation du reset ou entre deux trames successives. Le bit, baptis 1_bit_counter et qui doit avoir deux valeurs diffrentes pour deux trames successives, garde sa valeur inchange. Un signal SDA_freeze est mis 1 signalant une erreur de 1_bit_counter. Le bit de parit est diffrent de la valeur calcule. Lidentificateur est diffrent de la valeur prdfinie.
7. Synthse
Aprs avoir dfinir les spcifications fonctionnelles du circuit concevoir. Lquipe de design traduit les exigences en langage VHDL niveau RTL synthtisable. Une fois le codage est achev, il passe faire la synthse et le placement et routage du design en utilisant loutil Libero. Les rsultats obtenus sont illustrs dans la figure suivante :
37
ENISo |
HCELL-engineering
Figure 25: rapport des ressources utilises Tandis quaux performances, Libero fournit le rapport de Timing suivant :
Figure 26: rapport de timing Lors du processus de vrification, on se focalisera sur lanalyse des rsultats fournis par le rapport de Timing.
8. Conclusion
Le cycle de vie dune description en HDL englobe deux volets. Le premier concerne la conception, le codage et la synthse du composant. Ces diffrents aspects ont t exposs dans ce chapitre. En effet, une justification de choix de la cible dimplmentation a t donne ainsi que les outils et les langages de programmation utiliss avant de finir avec les spcifications fonctionnelles de quelques bloques du composant et les rapports de synthse dans les limites des mesures de confidentialit du projet. Le deuxime volet, la vrification, sera le sujet du prochain chapitre o le processus de vrification sera dtaill.
38
ENISo |
HCELL-engineering
Chapitre
4:
Vrification fonctionnelle
Objectifs :
Prsentation de larchitecture du Testbench. Prsentation des spcifications de lenvironnement de test. Exposition des simulations ralises et des rsultats obtenus.
39
ENISo |Vrification fonctionnelle
HCELL-engineering
Chapitre 4 :
Vrification fonctionnelle
1. Introduction
La vrification est dsormais le processus le plus important et lui plus gourmand en termes de ressources dans le dveloppement dun composant complexe.
Figure 27: Processus de vrification [17] Aprs avoir rdig le plan de vrification, en se basant sur les spcifications et les exigences fonctionnelles du design, lenvironnement de vrification ou le Testbench est dvelopp. Pu is, un dbogage est effectu dans le but de dterminer les bugs dont la source est lenvironnement ou le design. Par la suite une rgression est lance pour finir avec les tests physiques et les analyses. Dans ce chapitre, on prsentera tout dabord larchitecture du Testbench en gnrale puis en dtails. Ensuite on parlera de diffrentes activits de simulations. Ce chapitre sera cltur par une prsentation des tests de robustesses comme perspectives de ce travail.
2. Architecture de Testbench
Le client exige que la vrification de lFPGA soit tablie en Black Box. Cette exigence lve la barre trs haut et complique de plus cette phase de processus de dveloppement du projet.
40
HCELL-engineering
Pour accomplir cette mission, lide tait dextraire les signaux internes du c ircuit travers les interfaces SPI et SPY. Ces signaux interfrent dans le comportement des sorties globales du design. Donc il est jug ncessaire de valider leurs conduites afin de vrifier le bon fonctionnement de lapplication. Lenvironnement de test vise mettre le design dans un environnement similaire son environnement naturel afin de prvoir son comportement. En effet lenvironnement de vrification est compos de : Le design sujet de vrification en Black Box (DUT). Des gnrateurs des stimuli qui serviront gnrer les vecteurs de test. SPI master qui jouera un double rle. Dune part, et comme son nom indique, le rle de master pour linterface SPI de lFPGA sous test. Dautre part, il se chargera de tester les diffrentes exigences qui concernent le format des trames SPI. SPY receiver qui assurera la vrification le format des trames prvenant du DUT travers linterface SPY. Des diffrents checkers qui soccuperont de vrifier les diffrents signaux du DUT, quils soient internes ou globaux. Une multitude de programmes crits en langage script Tcl afin dautomatiser le droul ement et lexcution des diffrents tests et assurer la traabilit des procdures et des rsu ltats de processus de vrification. Ces diffrentes composantes, que on vient de citer, seront expos en dtails7 dans les paragraphes qui suivent.
Figure 28 : architecture de Testbench

7
Lexposition des dtails sera dans les limites de confidentialit du projet.
41
HCELL-engineering
3. Spcifications fonctionnelles de lenvironnement de test 3.1. Gnrateurs de Stimuli

Le but est de dfinir les stimuli appliquer l'unit sous test. Les stimuli peuvent tre dfinis en VHDL ou dans un format plus proche de l'application (p.ex. en assembleur ou en C). Dans ce dernier cas, le gnrateur doit fournir les stimuli et les enregistrer dans des fichiers texte qui vont tre utilises par les checkers en suivant ventuellement les contraintes d'interface (p.ex. protocole, dlais). Le gnrateur peut aussi introduire volontairement des erreurs dans les vecteurs de tests. Dans ce projet, on sest content dutiliser des gnrateurs hardwares crits en VHDL et des fichiers texte qui contiennent des vecteurs de test prdfinis. En effet, et en se basant sur une parfaite connaissance des exigences de design, des vecteurs de tests sont crits dune faon explicite dans des fichiers texte afin dtre utiliss par les gnrateurs des stimuli pour exciter le circuit objet de test. Tandis que pour les gnrateurs crits en VHDL, on a eu recours lutilisation des registres dcalage rtroaction linaire connu plus par son acronyme anglais LFSR8 pour gnrer tous les vecteurs de test sauf ceux que le comportement dpond du temps ou la taille ne dpasse pas deux bit : Dans ce dernier cas, un simple compteur binaire fera laffaire.
3.1.1.
Mthode de gnration des vecteurs de test : LFSR
LFSR ou encore registre dcalage rtroaction linaire est une mthode utilise pour gnrer des vecteurs de tests dune manire pseudo-alatoire et exhaustive. Les registres dcalage rtroaction linaire sont des circuits logiques composs de bascule D et de port XOR monts en tages comme indiqu dans la figure 29.
Figure 29: Schma dun LFSR de taille N LFSR est un circuit de gnration cyclique. Il revient son tat initial aprs un nombre suffisant de coup dhorloge (2N-1 cycles). A chaque coup de clock, le bit de poids faible si constitue la sortie du registre, et les autres bits sont dcals vers la droite. Le nouveau bit si+L plac
Voir glossaire
42
HCELL-engineering
dans la cellule de poids fort du registre est donn par une fonction linaire des bits (si, . . ., si+L1) si+L = h1 * si+L1 + h2 * si+L2 + . . . + hL * si o les coefficients de rtroaction (hi) 1 i L sont des coefficients binaires. Les bits (s0, . . ., sL1), qui dterminent entirement la suite, constituent ltat initial du Registre dcalage. Les coefficients de rtroaction sont usuellement reprsents par un polynme binaire de Degr L, appel polynme de rtroaction du registre : P(X) = 1 + c1*X + c2 *X2 + . . . + cL*XL. Pour tre sr que les vecteurs de test gnrs couvrent tous les cas possible, il indispensable dutiliser un polynme primitif [31]. Dans le tableau suivant, les diffrents polynmes primitifs sont prsents pour une varit de largeur (N) de LFSR:
Tableau IV: Liste des polynmes primitifs pour des diffrentes tailles de LFSR [31]
Valeurs de N 5, 11, 21, 29 9 Polynme primitifs 1 + X2 + Xn 1 + X3 + Xn 1 + X4 + Xn 1 + X5 + Xn 1 + X2 + X3 + X4 + Xn 1 + X2 + X4 + X6 + Xn 1 + X + X3 + X4 + Xn 1 + X7 + Xn 1 + X + Xn
1, 2, 3, 4, 6, 7, 15, 22 10, 17, 20, 25, 28, 31 23 18 12, 14, 16 13 8
3.1.2.
Gnrateur pour FPGA identification
Les vecteurs de tests gnrer pour ce module sont dsormais les plus simples. FPGA identification a comme entre deux signaux : BOARD_SEL, un signal quatre bits de taille, et le signal PIN_PROG dont la taille est deux bits. Pour le premier, BOARD_SEL, on utilisera un LFSR de largeur quatre. Le polynme caractristique utilis est le suivant : P(X) = 1 + X + X4
43
HCELL-engineering
La valeur gnr change pendant une priode prdfinie dclare comme gnrique afin quelle soit chang volont. Pour le PIN_PROG, un simple compteur binaire est charg de laffaire.
Figure 30 : les 16 premires valeurs de BOARD_SEL gnres par FPGA_id generator Dans cette figure, une portion de wave forme est expose. Le LFSR est exist par des uns comme valeur initiale. Aprs que le compteur des stimuli arrive 16, BOARD_SEL est forc 0000 (puisque le LFSR avec des ports XOR ne peut pas le gnrer). Cest ainsi que on garantie la gnration des 16 valeurs possibles de BOARD_SEL en utilisant un LFSR.
3.1.3.
Gnrateur pour Watchdog interface
Dans le cas de Watchdog interface, les signaux dpendent fortement du temps. En effet cette interface possde une seule entre qui est WDG_TIMOUT_sig. Ce signal doit avoir un comportement bien dfinie dans le temps afin dactiver le WDG_power_up_test_validity.
RESET
X ms Y ms Y ms
WDG_pulse
a ms
b ms
WDG_TIMEOUT_sig
WDG_power_up_test_ validity
WDG_power_up_test_ in_progress
Figure 31 : Condition de validation de WDG_power_up_test_validity Donc, et comme le montre la figure ci-dessus, quatre temps dchantillonnage sont considrs pour activer le WDG_power_up_test_validity. Lide est de gnrer, en premier lieu un cas valide. En second lieu et pour pouvoir couvrir tous les autres cas, on a considr que les quatre points reprsente un vecteur de quatre bits. Donc on peut utiliser un LFSR pour le g44
HCELL-engineering
nrer. La priode de gnration, tant donn, est la priode de gnration des quatre chantillons ensemble. Ensuite, chaque bit du vecteur gnr est assign au signal WDG_TIMOUT_sig.
Figure 32: Les quatre premiers scnarios de gnration de WDG_timeout_sig
3.2. Les checkers

Le but est de collecter les donnes de sortie de l'unit tester, de les convertir ventuellement en un format plus lisible et d'effectuer des vrifications sur les donnes collectes. Ces vrifications peuvent tre faites de plusieurs manires: par comparaison avec des rsultats idaux dfinis dans le composant collecteur (expected signal value) par comparaison avec les sorties d'une seconde DUT un niveau plus abstrait (p.ex. comparaison entre un modle logique et RTL) et qui servira comme talon pour le composant sujet de test. Par inspection visuelle de wave forme issus de la simulation.
Dans ce travail, on opte pour une approche mixte : le composant collecteur, sil est ncessaire, calculera les sorties dsires, en utilisant des mthodes plus simple valider leurs fonctionnent, et comparera les rsultats avec celles de lunit tester. Sinon, les sorties du DUT seront comparer avec des rsultats idaux prdfinis. Une inspection visuelle de wave forme sera performe pour les signaux dont le comportement est simple.
3.2.1.
SPI master
Le rle de lenvironnement de test, comme on vient de motionner, se manifeste essentiellement dans le fait de mettre le circuit tester dans un environnement similaire la ralit afin de pouvoir vrifier son fonctionnement. Cest pourquoi on a eu recoure dvelopper cette interface, le SPI master. Elle jouera le rle de la carte MCU en ce qui concerne la communication SPI. Ce module joue en effet plusieurs rles : Il communique avec linterface SPI travers LGPX_SL_MOSI et LGPX_SL_MISO pour pouvoir extraire les registres et utiliser les signaux quils contiennent pour excuter les diffrents tests.
45
HCELL-engineering
Il enregistre les donnes quil reoit dans un fichier texte qui va tre utilis par les autres checkers VHDL. Il vrifie que le SPI interface a respect les recommandations qui concernent le protocole SPI (format de la trame).
Afin de pouvoir remplir ce dernier point, un scnario de test pr dfinie est excut. Le master envoi des trames successives en injectant des erreurs dans le CRC ou les donnes transmises afin de tester laptitude du slave les dtecter (mettre un 1 dans le premier status si la trame reue prcdemment est fausse et le deuxime 1 si la faute est dans la trame a ctuelle).
Figure 33: Simulation de SPI master Selon la valeur du signal chk_frame_with_error, le SPI master injecte ou non une erreur dans la trame envoyer au slave travers le LGPX_SL_MOSI. Le master vrifie ensuite les donnes reues travers le LGPX_SL_MISO en se basant sur le scnario de vrification. Une machine dtat est conue pour accomplir cette mission :
Figure 34: Machine dtat pour la vrification de Protocole SPI Ltat initial est Idle. Le SPI master vrifie les donnes si le signal Start_chk est actif pendant un cycle. Le master passe donc ltat check_state. Sil n y a pas derreur, la machine dtat
46
HCELL-engineering
retourne ltat Idle. Dans le cas chant, la machine dtats passe Error_state et se bloque dans cet tat.
3.2.2.
-
SPY receiver
Ce module assurera les fonctionnalits suivantes : recevoir les donnes venant de linterface SPY : La rception est dclenche lorsque un bit, dont la valeur est gale 1, se manifeste sur son input (SPY receiver). Reconstituer les donnes sous formes de mots de 16 bits et les sauvegarder dans un fichier texte qui va tre utilis par les autres checkers. Faire la vrification des diffrentes exigences lies lmission travers linterface SPY. En effet, il vrifie le start_word et le end_word et la dure de chaque bit qui doit tre gale 610 cycles dhorloge. Aprs lmission de la trame complte, il vrifie aussi la dure de latence recommande avant denvoyer la trame prochaine, et la valeur mise par linterface SPY durant ce temps l et qui doit tre gale zro.
Pour remplir ses tches, le SPY receiver suit une machine dtat bien dfinie.
Figure 35: Machine dtat pour la vrification de la communication SPY
En cas dune erreur trouve, le SPY receiver activera ses trois sorties (cercles en rouge) : une signalant quune erreur est dtecte, lautre indique le type de lerreur selon un code pr df inie. Tandis qu la troisime, elle fournit le numro de trame qui le contient.
47
HCELL-engineering
Figure 36: Simulation du SPY receiver
3.2.3.
REG_SPI checkers
Les registres SPI, qui comptent 26 registres, contiennent les signaux internes du circuit. Leur vrification est juge ncessaire pour performer un test fiable de lapplication. Le principe des vrificateurs des registres SPI est assez simple. Le module fait la lecture de contenu du registre, sujet de test, partir du fichier texte fournit par le SPI master. Il vrifie que : la longueur du registre est gale 16 bits. Les donnes sont conformes aux valeurs des signaux qui sont prdfinies par les vecteurs de test ou calculer par le checker lui-mme. En effet, et si leurs comportements savrent compliqu dcrire, les valeurs des signaux dites expected sont calcules par les gnrateurs de stimuli afin de garder la structure des checkers la plus simple possible. Dans le cas contraire, ces signaux sont dfinis dans les vrificateurs mmes. Ces signaux expected sont compars par les donnes stockes dans le registre SPI vrifier.
Une machine dtat est conue pour atteindre ce but (figure 37). La squence est dclenche par un signal start_chk_REG_SPI, le module effectue un accs au fichier texte qui contient les donnes, les enregistres dans des signaux internes pendant ltat Read_state. Aprs, la vrification est effectu lors de ltat check_state. Si aucune erreur nest dtecte, le module retourne ltat idle_state. En cas chant, un passage ltat Error_state est justifi et les deux flags derreurs du checker sont activs : un signalant quune erreur est dtecte et lautre indiquant la connotation de lerreur dfinie au pralable.
48
HCELL-engineering
Figure 37 : Machine dtat des REG_SPI checkers
3.2.4.
SPY Words checkers
Les mots valables travers linterface SPY, qui comptent 16 mots, contiennent les signaux internes du circuit et qui ne sont pas valables travers la communication SPI. Leur vrification est aussi jug ncessaire pour performer un test fiable de lapplication. Le principe des vrificateurs des mots SPY est assez simple et identique celui des registres SPI. Le module fait la lecture de contenu du mot, sujet de test, partir du fichier texte fournit par le SPY receiver. Il vrifie que : la longueur du mot est gale 16 bits. Les donnes sont conformes aux valeurs des signaux qui sont prdfinies par les vecteurs de test ou calculer par le checker lui-mme. En effet, et si leurs comportements savrent compliqu dcrire, les valeurs des signaux dites expected sont calcules par les gnrateurs de stimuli afin de garder la structure des checkers la plus simple possible. Dans le cas contraire, ces signaux sont dfinis dans les vrificateurs mmes. Ces signaux expected sont compars par les donnes stockes dans le mot SPY vrifier.
Les SPY Words checkers suivent la mme machine dtats que les checkers des REG_SPI. Le processus de vrification de contenue des mots mises par linterface SPY et enregistres par le SPY receiver dans un fichier texte est dclench par un signal start_chk_SPY_word. Un retour ltat Idle est recommand si aucune erreur nest dtecte. Dans le cas contraire, un passage ltat Error_state est fait et les deux flags derreurs du checker sont activs : un signalant que erreur est dtecte et lautre indiquant la connotation de lerreur dfinie au pr alable.
49
HCELL-engineering
sta r t _ c h k _ S P Y _ w o r d
I d le _ s ta te
P a s d e r r e u r
R e a d _ s ta te
C h e c k _ s ta te E r r e u r
E r r o r _ s ta te
Figure 38:Machine dtat des SPY Words checkers
3.2.5.
ARINC checker
Pour vrifier la fonction rception de l'interface ARINC, un metteur a t conu. Il dispose des mmes fonctionnalits de l'metteur ARINC et permet dinjecter les erreurs suivantes sur les trames gnres: - Erreur de parit (parity error): Lmetteur calcule la parit de la trame envoyer, linverse, linsert dans la trame et lmet : La trame envoye contient ainsi une erreur de parit. - Erreur d'encodage (encoding error): Durant l'encodage des bits, une faute de codage est provoque.
Trame
ARINC_TX_H
ARINC_TX_L
Figure 39: Provocation de faute dencodage Dans la figure au dessus, et lors de codage de la valeur zro, le signal ARINC_TX_H est maintenu 1. Ce qui provoque une ambigit de dcodage chez le rcepteur et il doit signaler cette erreur.
50
HCELL-engineering
- Erreur de la priode d'un bit (bit rate error): Augmenter ou bien diminuer la dure d'un bit par rapport la marge pr dfinie. - Erreur de la taille de la trame (frame width error): Envoyer des trames dont la taille est diffrente que celle dfinie. - Erreur de la priode entre les trames (interframe gap error): Varier la dure entre deux trames conscutives par rapport la marge pr dfinie. - Erreur de la priode entre les trames (interframe gap error): Varier la dure entre deux trames conscutives par rapport la marge pr dfinie. - Erreur de la forme de la trame (Label, SDI, SSM): insrer des valeurs diffrentes de celle dcrites dans le document de capture des exigences. Tandis quaux donnes mises par linterface ARINC, un rcepteur est conu pour effectuer les vrifications ncessaires concernant la parit, lencodage des donnes, la priode dun bit, la priode interframe, la taille de la trame ainsi que la forme de celle-ci.
3.2.6.
SDA checker
Un metteur a t conu afin de vrifier le bon fonctionnement du rcepteur SDA intgrant linterface SDA. Il dispose des mmes fonctionnalits de l'metteur SDA et permet dinjecter les erreurs suivantes sur les trames gnres: Pas dmission pendant une priode SDA_timeout aprs linactivation du reset ou entre deux trames successives. Garder la valeur de 1_bit_counter inchange pendant lmission de deux trames succe ssives. Le bit de parit est diffrent de la valeur calcule. Lidentificateur est diffrent de la valeur prdfinie.
Tandis quaux donnes mises par linterface SDA, le checker vrifie la validit des donnes et de protocole. Il sassure que la valeur de 1_bit_counter est diffrente que celle reu dans la trame prcdente. Il examine aussi le bit de parit, le ID et veille que la dure SDA_timeout nest pas viole. En cas chant, les deux sorties de ce module sont actives : une indique quune erreur est survenue et lautre donne la nature de lerreur selon un code prdfinie.
3.3.
Scripts Tcl
Le long de processus de vrification, on est appel dvelopper des macros en Tcl afin de pouvoir manipuler le lancement automatique des tests, la couverture de code, la capture et la traabilit des rsultats dans des fichiers texte9. Ces macros sont organiss dans des fichiers *.do selon la hirarchie prsent dans la figure 40.
Annexe B
51
HCELL-engineering
Figure 40: Hirarchie des macros Tcl La macro Comp_sim.do, responsable de la compilation et la simulation, fait appel trois autres afin daccomplir sa fonctionnalit : Sim_time.do : cette macro dfinisse les diffrents temps de simulation pour chaque test parmi les 60. Create_liste.do et Save_list.do : Ces scripts crent des fichiers *.list, gnrs par Modelsim SE. Ils permettent de faire la traabilit des signaux souhaits le long de la simulation. Ces fichiers sont utiliss par la macro Report_gen.do.
La macro Report_gen.do associe Code_coverage.do engendre les rapports des tests et de couvertures de code. Tout les deux sont instancis sous Proc.do afin quelles soient utilises par les procdures que lance lutilisateur lors de la simulation. Ainsi, pour rendre lenvironnement portable et fonctionnel sur nimporte quelle machine, une macro Config.do contient toutes les variables que lutilisateur est appel modifier : Chemin daccs du projet, de Modelsim SEetc. Tandis que macro Setup.do, il englobe tous les variables global internes. Ainsi, et aprs avoir modifi les paramtres que contient config.do, lutilisateur est invit lancer ModelSim SE, lancer la macro run.do, qui fait appel setup.do et config.do. Ensuite, il doit taper le nom de la procdure de test, selon la mode (Bring-up ou rgression), comme indique la figure 41dans la fentre de commandes de ModelSim SE.
52
HCELL-engineering
Figure 41: Lancement des tests en utilisant les macros Tcl
4. Simulation
La simulation peut tre dfinie littralement comme un type de modlisation de la DUT, permettant lexcution du modle rsultant par un ordinateur. Elle peut tre comprise comme un processus de modlisation dans laquelle la ralit physique de la DUT est imite grce des ordinateurs. Elle permet lobservation des comportements hypothtiques de la DUT dans diffrentes conditions. Ces conditions sont dtermines par les stimuli [17]. Donc, aprs avoir dfinie tous les composants de lenvironnement de vrification, le temps est venu pour faire tourner les tests et lancer la simulation. Cette tape comporte la simulation niveau RTL, la vrification des taux de couverture de code, la simulation du modle postlayout et finalement lanalyse de timing.
4.1. Simulation niveau RTL 4.1.1. La phase Bring-up

Pendant cette phase, lenvironnement de test est encore dans sa version prliminaire : Il vrifie le design et dtecte les erreurs mais noffre pas une bonne couverture de code pour le moment. La phase de Bring-up consiste donc dbugger et corriger lenvironnement de test et le DUT. En se basant sur les rapports que gnrent le Testbench, une vrification des rsultats des tests est effectue. En effet, Une analyse des rapports est tablie afin de dterminer lorigine des erreurs trouves : Si lerreur rapporte provient dune erreur lors de la conception de lun des checkers, alors lquipe de vrification se charge de la corriger et de relancer le test. Si le bug est dorigine design, il est communiqu lquipe en charge pour la corriger dune faon immdiate, si le bug est bloquant et impossible de continuer sans le corriger, ou ultrieurement sil est insignifiant pour le reste des tests.
53
HCELL-engineering
Une fois que tous les bugs sont corrigs, on est prt lancer une rgression [32].
4.1.2.
Rgression et couverture de code
La dfinition du mot rgression, dans le dictionnaire, est : recul, retour en arrire gnralement dans un tat pire ou sous dvelopp que ltat actuel [32]. Techniquement, le mot rgression est utilis pour dcrire le r-lancement de la simulation afin quon sassure que les bugs, dtects dans la phase de Bring-up, ne rapparaissent pas. Le lancement des tests de rgression et leur traabilit sont assurs par les scripts Tcl dvelopps prcdemment en lanant la macro run_listof_test dans la fentre de commande de Modelsim SE. De plus, et dans cette phase de vrification, interviennent les mesures de couverture de code. Modelsim SE offre un suivie graphique de taux de couverture. Mais en suivant les recommandations de la norme DO-254, des rapports de couverture de code doivent tre gnrs afin dassurer la traabilit et faciliter la validation de la phase de vrification. La couverture de code sert valuer la qualit de travail de lenvironnement de test. Si la couverture est infrieure 100 %, un retour la phase de dbogage est ncessaire fin damliorer lenvironnement. Une couverture qui dpasse 90 % est accepte sil est impo ssible datteindre le taux 100 %, mais il faut fournir les justificatifs ncessaires.
4.2. Simulation postlayout

Cette phase consiste lancer une rgression en prenant le modle psotlayout (netlist) gnr par Libero comme DUT. Si les mthodes de vrifications formelles taient adaptes par la FAA, on aurait pu vrifier le modle postlayout en se basant sur la vrification RTL puisque les deux modles sont quivalents. Mais du fait que ce nest pas le cas, on devra passer par cette phase de vrification dans le but de valider la netlist du composant. Tandis que la simulation RTL vise dtecter les erreurs fonctionnelles du design, la simulation postlayout poursuit les erreurs qui peuvent avoir lieu suite des dfauts lies un mauvais comportement dans le temps. En effet, trois types de simulations que le Mdelsim SE offre en utilisant les bibliothques dACTEL : une simulation avec un dlai de propagation typique, minimal et maximal. La mme macro run_listof_test est utilise avec un changement darguments. Cette tape est trs gourmande en termes de temps [33]. En guise dexemple, le test numro 3 dura toute une journe. Certes le temps de simulation change dun test un autre. On est appel lancer 60 tests en totalit.
4.3. Analyse de timing

Lanalyse de timing consiste refaire la synthse et g nrer les rapports de Timing que produit loutil Libero. Une fois les rapports sont gnrs, on compare les informations quils contiennent avec les exigences de design inscrits dans le document de capture dexigence. En effet, les informations gnres doivent tre conformes aux exigences demandes. Toute violation sera juge comme une erreur et elle doit tre corrige par l'quipe de design.
54
HCELL-engineering
5. Rsultats et discussions
Le processus de vrification a permis de dtecter des diffrents bugs donc les code RTL du design. Ces bugs se localisent en gnrale dans les modules jugs complexes et qui concernent les diffrents protocoles de communication utiliss par le composant. La liste des erreurs dtectes est organise comme indique la figure 42 Ce document est communiqu lquipe responsable de design afin de les corriger.
Figure 42: traabilit des diffrents bugs dtects
Cette procdure prend fin lorsque les critres suivants sont remplis : Avoir zro erreur dans design RTL. tre sr que la couverture de code est 100 %. Toutes les exigences sont vrifies. Les rsultats des tests et les procdures de vrification sont tracs dans les papiers appropris.
Cest ainsi que le composant sous dveloppement est garanti quil est dli vr au client avec zro erreurs en suivant les recommandations des autorits du standard RTCA/DO-254.
6. Perspectives : Tests de robustesse

Le travail achev permet d'affirmer que le FPGA et l'environnement de test fonctionnent parfaitement et que le but de ce stage a t atteint. Mais, selon le standard RTCA/DO-254, il reste un autre objectif remplir pour que ce composant soit valid puis certifi par les autorits responsables. Le composant dvelopp doit passer lpreuve des tests de robustesse. Ce sont des tests qui comptent mettre le circuit dans un tat de fonctionnement anormal afin
55
HCELL-engineering
danalyser son comportement. En effet, ces tests dfinissent les circonstances de fonctionnement du FPGA au-del des conditions aux limites exiges dans le document de capture dexigence.
7. Conclusion
Dans ce chapitre, on a introduit la vrification fonctionnelle du projet et on a port lattention, en particulier sur ltape dveloppement de lenvironnement de vrification ainsi que la vr ification des diffrents niveaux dabstraction du projet. Le projet a bien attnu ses objectifs tracs pour cette phase : avoir un design avec zro faute avec une traabilit complte de toutes les phases de dveloppement et tests. Il reste a excuter les tests de robustesses pour dfinir le comportement du composant en mode de fonctionnement anormale afin de fournir une image complte sur la conduite du circuit aux autorits responsables de certification des composants hardware dvelopps selon la norme RTCA/DO254.
56
ENISo |
HCELL-engineering
Conclusion Gnrale
Le projet de fin dtudes courant intitul Vrification dun FPGA pour le systme de contrle des trains datterrissage et de freinage de LAIRBUS A350 XWB et ralis au sein de lquipe Vrif. de Hcell-engineering, a pour objet la vrification fonctionnelle, selon les recommandations de la norme RTCA/DO-254 DAL A, de la description HDL dun FPGA intgrant le systme dextension/rtraction des trains datterrissage, un des divers modules intgrs dans le calculateur ATA 32 responsable de contrle des trains datterrissage et de freinage pour lavion A350 XWB. Dans ce rapport, on a essay tout dabord de dfinir les diffrents aspects quon a jugs en relation avec le projet afin de mettre le lecteur dans le bain avant dentamer les autres pa rties. En effet on a exhib les notions sur les systmes critiques, la norme RTCA/DO-254 et lvolution historique des systmes de freinage au bord de lavion. Quant au deuxime ch apitre, on a fait un tat de lart en se qui concerne les diffrents mthodologies de conception ainsi que de vrification. Le troisime chapitre a t rserv lexposition des diffrents a spects qui concernent la conception du composant pour aboutir parler de ma contribution sa vrification dans le dernier chapitre. Les principaux objectifs viss par ce travail consistaient alors, dune part laborer un environnement de test spcifique au projet, et dautre part de lutiliser pour vrifier le bon fonctionnement du design pour les diffrents niveaux dabstractions. Ces objectifs ont t achevs terme. Les rsultats obtenus sont assez satisfaisants puisque de point de vue vrification, lenvironnement dvelopp a pu dtecter les erreurs du design qui ont t corriges ainsi de suite jusqu avoir un design conforme aux exigences et exempte derreurs. En conclusion, lapport de ce projet se rsume surtout dans la dcouverte de la norme RTCA/DO-254, dun nouveau langage et de se familiariser avec des nouveaux outils et surtout approuver les connaissances acquises le long de mon cursus universitaire lENISo. En effet, ctait une occasion pour dcouvrir la standard avionique, dapprendre le langage scripts Tcl, de manipuler de plus les outils tels que Modelsim SE, Libero, Emacset surtout minstruire sur le plan relationnel et bien savourer le travail dquipe.
57
ENISo |Conclusion Gnrale
HCELL-engineering
Bi b l i o g r a p h i e Neto-graphie
&
58
ENISo |Bibliographie &Neto-graphie
HCELL-engineering
Bibliographie &Neto-graphie
[1] Patrice Kadionik, Matre de Confrences l'ENSEIRB. LES SYSTMES EMBARQUS : UNE INTRODUCTION. Dcembre 2005. [2] RTCA. RTCA DO-254/EUROCAE ED-80 DESIGN ASSURANCE GUIDANCE FOR AIRBORNE ELECTRONIC HARDWARE. 2000. [3] HCELL-engineering. Home page. Disponible sur : http://www.hcell-engineering.com [4] Luca Sterpone. ELECTRONICS SYSTEM DESIGN TECHNIQUES FOR SAFETY CRITICAL APPLICATIONS. Springer Science + Business Media B.V, 2008. [5] Flavien KOLIATENE. CONTRIBUTION A LETUDE DE LEXISTENCE DES DECHARGES DANS LES SYSTEMES DE LAVIONIQUE, Thse de doctorat. Universit Toulouse III Paul Sabatier, janvier 2009.
[6] Messier-Bugatti. VERS LAVION TOUT LECTRIQUE FREIN LECTRIQUE. Presse Safran, 2007. [7] Prabhat Mishra, Nikil D.Dutt, FUNCTIONAL VERIFICATION OF PROGRAMMABLE EMBEDDED ARCHITECTURES: A TOP-DOWN APPROACH. Springer Science & Business Media, Inc, 2005. [8] Jedidi Ahmed. SPCIFICATION, SIMULATION ET SYNTHSE VHDL DU BLOC INTRA PRDICTION DE LA NORME H.264 EN VUE DIMPLMENTATION SUR FPGA, projet fin dtude. ENIS, 21 juin 2005. [9] IEEE. VHDL LANGUAGE REFERENCE MANUAL. Std 1076-2001, 2001. [10] VHDL Synthesis Interoperability Working Group of the Design Automation Standards Committee. DRAFT STANDARD FOR VHDL REGISTER TRANSFER LEVEL SYNTHESIS. IEEE P1076, 2001. [11] IEEE. STANDARD VERILOG HARDWARE DESCRIPTION LANGUAGE. IEEE 13642001, 2001. [12] Trait EGEM. CONCEPTION DE HAUT NIVEAU DES SYSTMES MONOPUCES, sous la direction de Ahmed-Amine Jerraya. Lavoisier, 2002. [13] IEEE Press. IEEE STANDARD GLOSSARY OF SOFTWARE ENGINEERING TERMINOLOGY. AINSI/IEEE Standard 729-1983, 1983.
59
HCELL-engineering
[14] Andrew P. FUNCTIONAL VERIFICATION: COVERAGE MEASUREMENT AND ANALYSIS, Kluwer Academic Publishers, ISNB 1-4020-7876-5, 2004. [15] Rolf Drechsler. ADVANCED FORMAL VERIFICATION, Kluwer Academic Publishers 2004. [16] Yanick Paviot, IMPLMENTATIONS MIXTES LOGICIELLES/MATRIELLES DES SERVICES DE COMMUNICATION POUR LEXPLORATION DU PARTITIONNEMENT LOGICIEL/MATRIEL, Thse de doctorat, INPG, Spcialit Microlectronique, laboratoire TIMA, 2004. [17] Youssef Serrestou. OPTIMISATION DE LA QUALITE DE LA VERIFICATION FONCTIONNELLE PAR ANALYSE DE MUTATION, Thse de doctorat, LCIS Grenoble INP, Dcembre 2008. [18] Jorgen Staunstrup. A FORMAL APPROACH TO HARDWARE DESIGN, Kluwer Academic Publisher, 1994. [19] National Aeronautics and Space Administration Washington, DC (NASA). FORMAL METHODS SPECIFICATION AND ANALYSIS GUIDEBOOK FOR THE VERIFICATION OF SOFTWARE AND COMPUTER SYSTEMS VOLUME 2: A PRACTITIONERS COMPANION. NASA, May 1987. [20] IBM, RuleBase, Home page. Disponible sur : http://www.haifa.il.ibm.com/projects/verification/RB_Homepage/index.html [21] Synopsys, Magellan, Home page. Disponible sur : http://www.synopsys.com/products/magellan/magellan.html [22] Cadence, Incisive Formal Verifier, Home page. Disponible sur : http://www.cadence.com/products/functional_ver/incisive_formal_verifier [23] Bruce Wile, John C.Goss, Wolfgang Roesner. COMPREHENSIVE FUNCTIONAL VERIFICATION, THE COMPLETE INDUSTRY CYCLE. Elsevier, ISBN: 0-12-751803-7, 2005. [24] Sasan I., Sunita J. THE E HARDWARE VERIFICATION LANGUAGE, Kluwer Academic Publishers, ISNB 1-4020-8024-7, 2004. [25] Synopsys, OpenVera, Home page. Disponible sur : http://www.openvera.org/ [26] Xilinx, Virtex-II Pro Platform FPGAs. COMPLETE DATA SHEET. DS083. Product Specification, April 22, 2004.
60
HCELL-engineering
[27]Franois Xavier Standaert, Lejla De Mulder, Kerstin Lemke, Nele Mentens, Elisabeth Oswald, Eric Peeters. REPORT ON DPA AND DEMA ATTACKS ON FPGAS. European Network of Excellence in Cryptography, 31 July 2005. [28] T. Speers, J. J. Wang1, B. Cronquist, J. McCollum, H. Tseng, R. Katz and I. Kleyner Actel Corporation, Sunnyvale, CA 94086, NASA/Goddard Space Flight Center, Greenbelt, MD 20771, Orbital Sciences Corporation. 0.25 um FLASH MEMORY BASED FPGA FOR SPACE APPLICATIONS. [29] Aymen REGEIAG. CONCEPTION ET IMPLMENTATION SUR FPGA DUN MODULE GRANT LA COHRENCE DE CACHE DANS LES MPSOC, projet fin dtude ENIS, juin 2009. [30] CONDOR engineering. ARINC 429 PROTOCOL TUTORIAL. [31] Abdelaziz AMMARI. CONCEPTION EN VUE DU TEST: TEST INTGR (BIST). ENISo, Novembre 2009. [32] Andrew Piziali. FUNCTIONAL VERIFICATION COVERAGE MEASUREMENT AND ANALYSIS. Kluwer Academic Publishers, 2004 [33] Abdelaziz AMMARI. ANALYSE DE SURETE DES CIRCUITS COMPLEXES DECRITS EN LANGAGE DE HAUT NIVEAU, Thse de doctorat. Institut national polytechnique de Grenoble, aot 2006. [34] TT electronics. STEEL BRAKING ON AIRCRAFT. Welwyn Components Limited, Welwyn Electronics Park, Bedlington, Northumberland NE22 7AA, UK. [35] Actel. PROASIC3 FLASH FAMILY FPGAS WITH OPTIONAL SOFT ARM SUPPORT. [36] HCELL-engineering. HARDWARE REQUIREMENT DATA. Janvier 2010.
61
HCELL-engineering
An n e x e s
62
HCELL-engineering
Annexe A :
Systme de contrle des trains d'atterrissage et de freinage

Dune manire gnrale, llectricit prend une place prpondrante dans le schma ne rgtique des vhicules, notamment dans la distribution interne dnergie. Les aronefs nchappent pas cette tendance. Le besoin en puissance lectrique est de plus en plus croi ssant comme lillustre la figure 43, ce qui pourrait entraner labandon progressif de lnergie hydraulique ou pneumatique bord des aronefs : cest le concept de lavion tout lectrique.
Figure 43: Evolution de la puissance lectrique embarque [5] Nous revenons brivement dans les paragraphes suivants sur lhistorique de cet envol de la puissance lectrique embarque dans les aronefs.
1. Historique de l'volution de l'nergie lectrique embarque

Comme illustr sur la figure 43, les chiffres parlent deux-mmes. Depuis le dbut de lhistoire de laronautique, les avions deviennent de plus en plus lectriques. Au dbut des annes 70, Airbus commercialise lA300 (260 passagers) et la consommation est de 250kW. A cette poque, llectricit nest toutefois utilise que pour linstrumentation de vol. A la fin des annes 80, lA320 consomme 300kW, soit gure plus que son prdcesseur, mais il sonne le glas des anciennes commandes de vol. Dots dun systme appel Fly by Wire , les volets sont toujours actionns par pression hydraulique mais la commande est entirement lectrique. Le confort et le divertissement du passager prennent aussi une part non ngligeable de la consommation lectrique. Scurisante et souple dutilisation, cette nouvelle technologie sera applique par les autres avionneurs.
2. Ncessit d'un systme hybride : lectro-embarque

En dpit des avantages indniables du systme lectrique, lhydraulique conserve une place importante dans la conception des systmes. Ainsi, on assiste une utilisation accrue des ar63
HCELL-engineering
chitectures hybrides lectro-hydraulique qui remplacent les systmes entirement hydrauliques. Plutt que dacheminer depuis les moteurs et sur une longue distance des quantits importantes de fluide hydraulique, l'ide a consist gnrer localement lnergie hydraulique ncessaire pour actionner tel ou tel systme. En dautres termes, le principe dune gnration de puissance hydraulique centralise et commune tous les systmes est remplac par des rseaux hydrauliques dcentraliss, activs par lintermdiaire dune lectropompe (ou micropompe), elle-mme entrane par un moteur lectrique situ proximit immdiate du systme. Ainsi, les actionneurs hydrauliques sont remplacs par des nouveaux systmes tels que les EHA (Electro-Hydrostatic Actuator) et EMA (Electro-Mechanical Actuator) qui reprsentent plus dun tiers des actionneurs bord de lavion. Ce qui a fait gagner en termes de poids de lavion. Cette volution, aussi remarquable soit-elle, est loin de son apoge. Cest ainsi que les avionneurs annoncent une nouvelle gnration daronefs : le Boeing 787 dreamliner et lAirbus A350 XWB, qui ouvrent la voie vers le tout lectrique .
3. Technologie daujourdhui: BTV

Le Brake-to-Vacate ou simplement BTV est systme de freinage et guidage automatique pour lavion en phase datterrissage innov par Airbus afin daider une dcongestion simple et efficace et dans le but de diminuer le temps doccupation de piste par lavion des grands ar oports bourrs du trafic arien. Le BTV, disponible sur lA380, lA320 (optionnel) et bien videmment sur lA350 XWB, aidera rduire le temps d embouteillage dans les grands aroports. Il optimisera le temps d'occupation des pistes et abaissera lnergie de freinage tout en maximisant le confort des passagers. Le systme, qui est conu par une quipe multidisciplinaire (avionique, les commandes de vol et l'auto-vol, train d'atterrissage, les essais en vol) dans le cadre d'un projet multiprogramme, permet aux pilotes de slectionnez la piste de sortie approprie lors de la prparation de descente.
Figure 44: systme Brak-To-Vacate dAirbus Ce systme innovant, brevet par lAirbus, utilise le GPS (Global Positioning System), la navigation de l'aroport, le pilote automatique et le freinage automatique pour appliquer une rgulation automatique de dclration, permettant l'avion datteindre une sortie choisie la bonne vitesse dans des conditions optimales.
4. volution future vers le tout lectrique

Les spcialistes saccordent pour considrer lavion tout lectrique comme laronef du futur [6]. Le remplacement des systmes hydrauliques par des dispositifs lectriques permet en effet de rpondre un dfi majeur : rduire encore et toujours les cots dexploitation des avions en simplifiant la maintenance. En effet, La technologie du frein lectrique prsente plusieurs avantages, parmi lesquels la rapidit dinstallation sur lavion, une surveillance plus efficace de lusure des freins, lamlioration de la disponibilit de lavion et une simplification des oprations de mainte64
HCELL-engineering
nance. Pour les compagnies ariennes, ces avantages devraient amener une rduction significative des cots dopration de leurs appareils. Le dveloppement du frein lectrique est une vritable avance technologique. Avec les freins lectriques, les quipements hydrauliques sont remplacs par des botiers lectroniques et les pistons hydrauliques par des actionneurs lectromcaniques. Ainsi, lorsque le pilote freine, cest un calculateur qui envoie linformation un botier de commande, qui transforme linformation lectrique en un effort lectromcanique : les actionneurs placs sur la couronne de frein, qui remplacent les pistons hydrauliques, serrent alors les disques de carbone les uns contre les autres comme dans le freinage hydraulique traditionnel.
1. Moteur lectrique 2. Rducteur engrenage 3. Vis et crou 4. Disque carbone rotor 5. Disque carbone stator Figure 45: Schma du principe du frein lectrique [6] Les premiers essais de frein lectrique jamais raliss sur un avion commercial se sont drouls avec succs le 13 fvrier 2009 sur un Airbus A340-600. Ce systme entirement dvelopper par Messier-Bugatti, va envahir tous les futurs programmes dAirbus qui succderont le A350 XWB. Tandis quau Boeing, et toujours dans le contexte de la course affole entre les deux grands avionneurs, son futur 787 dreamliner intgre des freins lectriques dvelopps par la socit Messier-Bugatti [6]. Le 787 est pourvu de huit roues principales. Chacun des freins est actionn par un systme lectronique nomm EBAC et dispos dans une baie avionique. Les actionneurs situs au niveau des roues sont alors relis aux EBAC par des cbles de puissance dont la longueur est au moins gale la longueur de la jambe du train datterrissage.
Figure 46 : Freinage hydraulique vs Freinage lectrique [34] Moins dquipements grer, moins de poids manipuler, implique moins dnergie co nsommer et moins de temps et defforts pour la maintenance. Cest le futur des systmes de freinage pour les aronefs sans rival.
65
HCELL-engineering
Annexe B :
Exemples de rapports gnrs
1. Test Status_{TEST_ID}.txt
Exemple de rapport gnr quand le test est exempt derreurs :
Figure 47 : Rapport de Test OK
Exemple de rapport gnr quand le test trouve des erreurs :
Figure 48 : Rapport de Test OK
2. TEST_Scenario_{TEST_ID}.txt
Exemples des rapports de scenarios de test:
66
HCELL-engineering
Figure 49 : Scnario de test de protocole SPI
Figure 50. Scenario de test de linterface SPI
67
HCELL-engineering
Annexe C :
Planning de Vrification
Figure 51 : Planning de vrification (SS : Safwen Selmi)
68
HCELL-engineering
Annexe D:
Glossaire
A
ARINC : Aeronautical Radio INCorporation ACAP : Altera Consultants Alliance Program ASIC : Application-Specific Integrated Circuit EPROM : Erasable Programmable READ - Only Memory
F
FPGA : Field Programmable Gate Array FAA : Federal Aviation Administration FSM : Finit States Machine FIR : Filtre Infinite Response
B
BDD : Binary Decision Diagram BTV : Brake-to-Vacate
C
CAO : Conception Assist par Ordinateur CPLD :
H
HDL : Hardware Description Language HVL : Hardware Vrification Language HVVP : Hardware Validation and Verification Plan HPAP : Hardware Process Assurance Plan HRD : Hardware Requirement Data HDD : Hardware Design Data HAP : Hardware Acceptance Plan HATP : Hardware Acceptance Test Procedure HRTR : Hardware RTL simulation Test Result HATR : Hardware Acceptance Test Result
69
D
DAL : Design Assurance Level DUT : Design Under Test
E
EBAC : Electronic Braking Actuator Controller EHA : Electro-Hydrostatic Actuator EMA : Electro-Mechanical Actuator
HCELL-engineering
I
IEEE : Institut of Electrical and Electronics Engineers IRM : Imagerie par Rsonnance Magntique IP : Intellectual Propriety
S
SPI : Serial Peripheral Interface SRAM : Static Random Access Memory SEU : Single Event Upset
K
Kbps : Kilo bit per second
T
TTM : Time To Market
L
LSB : Least Significant Bit LFSR : Linear Feedback shift Registre
V
VHDL : Very High Speed Integrated Circuit Hardware Description Language.
M
MCU : Master Control Unit MSB : Most Significant Bit
VLSI : Very Large Scale Integration
W
WDG : Watch-Dog
P
PFE : Projet de Fin des tudes PHAC : Plan for Hardware Aspect of certification PLD : Programmable Logic Design PSL : Property Specification Language
X
XWB : Extra Wild Body
R
RTCA : Radio Technical Commission for Aeronautics RTL : Registre Transfer Level
70

. . . RTCA/DO-254 ATA 32 350 RTCA/DO-254 :
Rsum
La conception et le dveloppement des systmes de sret critiques sont assujettis la fois des objectifs conomiques et au respect des normes de scurit. Dans le contexte aronautique, par exemple, ces contraintes sont amplifies puisque la marche de dveloppement doit rpondre une certaine fiabilit pour passer l'tape de certification. Le projet consiste dvelopper un environnement de vrification pour un FPGA selon la norme RTCA/DO-254 DAL A. Ce circuit fait partie du systme dextension/rtraction des trains datterrissage, un des divers modules intgrs dans le calculateur ATA 32 responsable de contrle des trains datterrissage et de freinage pour lavion A350 XWB. Mots cls : Vrification, FPGA, RTCA/DO-254, DAL A, contrle des trains datterrissage.
Abstract
The design and development of safety critical systems are subject to both economic objectives and compliance with safety standards. In the aeronautical context, for example, these constraints are multiplied because the development process must meet a certain reliability to pass the certification stage. The project consists on the development of a verification environment for an FPGA according to the standard RTCA/DO-254 DAL A. This circuit is part of the extension / retraction landing gear system, one of several integrated modules in the ATA 32, computer responsible for controlling Landing Gear and Brake System on the aircraft A350 XWB. Keywords: Verification, FPGA, RTCA/DO-254, DAL A, control landing gear.
Technople de Sousse- Route de la Ceinture- 4023 Sousse. Tl/Fax : +216 73 820 701. Fax : +216 73 822 300 www.hcell-engineering.com

Rapport PFE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport PFE

Uploaded by

Copyright:

Available Formats

Rf : p27

Universit de Sousse Ecole Nationale dIngnieurs de Sousse

Mmoire de Projet de Fin d'tudes

Ingnieur en Gnie Electronique Industrielle Option : .....

3.3.1. 3.3.2. 3.4. 4. 1. 2. 3.

Les langages spcifiques pour la vrification du matriel HVL ...........................20

Chapitre 3: Conception et spcification fonctionnelles..........................................................21

SRAM_based FPGA ou Flash_based FPGA .......................................................25

Outils de travail .........................................................................................................30

Chapitre 4: Vrification fonctionnelle...................................................................................39

3.1.1. 3.1.2. 3.1.3. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.2.4.

Les checkers .......................................................................................................45

3.2.5. 3.2.6. 3.3. 4. 4.1.

ARINC checker ...........................................................................................50 SDA checker................................................................................................51

Simulation .................................................................................................................53 4.1.1. 4.1.2. 4.2. 4.3.

Simulation postlayout .........................................................................................54 Analyse de timing ...............................................................................................54

Annexe C :........................................................................................................................68 Annexe D:.........................................................................................................................69

Liste des figures

Liste des tables

ENISo |Introduction Gnrale

ENISo |Introduction Gnrale

Systme de contrle des trains datterrissage et de freinage

ENISo |Systme de contrle des trains datterrissage et de freinage

Systme de contrle des trains datterrissage et de freinage

2. Systme de scurit critique

3. Le standard DO-254 3.1. Prsentation gnrale du standard DO-254

ENISo |Systme de contrle des trains datterrissage et de freinage

Dangereuse Majeure Mineure Sans effet2

ENISo |Systme de contrle des trains datterrissage et de freinage

3.2. Documents rdiger

ENISo |Systme de contrle des trains datterrissage et de freinage

Fondements de la conception et de la vrification des descriptions en HDL

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

Fondements de la conception et de la vrification des descriptions en HDL

2.1. Flot de conception traditionnelle

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

Figure 4 : Flot de conception dun FPGA [29]

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

2.3. Langages de descriptions matrielle

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

Figure 7: Diagramme de vrification [17]

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

3.2. Les diffrents approches de vrification

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

3.3. Techniques de vrification

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

ENISo |Fondements de la conception et de la vrification des descriptions en HDL

Figure 8: Environnement de vrification dynamique [17]

3.4. Les langages spcifiques pour la vrification du matriel HVL

Conception et spcifications fonctionnelles

ENISo |Conception et spcification fonctionnelles

Conception et spcification fonctionnelles

ENISo |Conception et spcification fonctionnelles

3. Choix de la cible dimplmentation 3.1. ASIC ou FPGA

ENISo |Conception et spcification fonctionnelles

Discussion et justification du choix

ENISo |Conception et spcification fonctionnelles

3.2. SRAM_based FPGA ou Flash_based FPGA

ENISo |Conception et spcification fonctionnelles

Discussion et justification du choix

Figure 10 : Cellule Flash vs Cellule SRAM

ENISo |Conception et spcification fonctionnelles