LA DO-254 pour les nuls (6) Le paradoxe de la couverture de code

Il y a couverture et couverture
La DO254 et surtout les vangiles associs voquent de nombreuses reprises des objectifs de couverture . Aprs un peu de pdagogie et de clarification, nous allons ici aborder le paradoxe trs tonnant li lutilisation de la couverture de code dans un design respectant la DO254 (et particulirement lindpendance).

Couverture fonctionnelle
En ce qui concerne le corps de la DO254, et particulirement la partie ddie la vrification, il ny a aucune ambigut : il sagit dune notion fondamentale de la mthodologie de conception sre : Lobjectif principal de la vrification consiste assurer la couverture exhaustive par les moyens appropris de lensemble des exigences de lobjet en cours de dveloppement. Evidence is provided that the hardware implementation meets the requirements. (DO254 6.2.1-1) Cette notion de couverture fonctionnelle est la seule aborde de faon explicite dans le texte de la DO254. Rappelons simplement ici limportance mcanique de cette approche : le centre du dveloppement est bien la spcification (Hardware Requirement Data) et elle est la source unique qui dtermine la stratgie de vrification. La couverture fonctionnelle est un objectif partag tous les niveaux de dveloppement dun systme (quipement, carte, composant, IP) et quel que soit le niveau de DAL et la complexit de lobjet en dveloppement.

Vision composant de la couverture

Si lon restreint la lecture de la DO254 la conception des circuits intgrs de type ASIC, FPGA ou COTS IP (ce qui correspond au focus largement prsent dans la littrature DO254) de nouvelles dfinitions de la couverture apparaissent, toutes lies des bonnes pratiques mtiers. La couverture de fautes est une technique ncessaire au test des composants spcifiques de type ASIC, qui assure que le fabricant est capable de sparer les puces correctement fabriques des puces ayant subi un ala de fabrication (poussire, fracture ). Cette technique trs cible et trs particulire met en uvre des processus classs dans la catgorie Design For test (DFT) [SCAN, BIST, JTAG). IL est noter que la cible de ces techniques est la netlist (liste des portes logiques constituant un circuit intgr numrique) obtenue aprs synthse du code RTL dorigine.

Ce document est la proprit de DMAP. Le contenu ne peut tre reproduit ou utilis sans lautorisation crite de la socit.

LA DO-254 pour les nuls (6) Le paradoxe de la couverture de code

Elle nest bien entendu pas dcrite dans la DO254 (heureusement), mais elle resurgit de faon trs tonnante dans le CAST -30 (Certification Authorities Software Team) consacr au traitement des composants simples. Pour les niveaux de DAL lev (DAL A-B) il est ncessaire dappliquer une technique de vrification qui est vraiment trs proche de la vrification de fautes (ce qui est vraiment trs loin dtre simple !). Ce qui nous intresse ici, concerne un autre type de couverture : la couverture de code (code coverage). Cette notion na de sens que dans le domaine de la conception de composants hardware, plutt numriques et dcrits avec des langages de type HDL (Verilog, VHDL ou autres).

Couverture de code : dfinition

Wikipedia fournit une dfinition parfaitement claire de cette activit : Code coverage is a measure used in verification. It describes the degree to which the source code of a hardware item has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing. Il sagit donc ici de sassurer que la vrification (ici cest de la simulation) exerce bien toutes les lignes de code, passe bien dans toutes les branches des machines dtat, que tous les signaux internes passent bien de zro un et vice versa On appelle mtriques les diffrentes analyses mener (branch, condition, toggle, statement) Evidemment cela a du sens si on lapplique du code source de type VHDL ou Verilog . Dailleurs une vision audacieuse (et un peu rapide) pourrait permettre de considrer la couverture de fautes comme de la couverture de code au niveau netlist (une phrase du dernier Certification Mmo de lEASA le laisse penser). Quelques ides associes avant de regarder lintrt de cette approche et le lien avec les attentes de la certification aronautique. La mme dfinition sapplique la partie software dun dveloppement (il sagit galement de code source analyser). Les outils CAO associs existent depuis longtemps et sont largement utiliss dans le monde de la conception hardware (maturit de lapproche) Il sagit dune vrification en bote blanche (ncessit de laccs au code) La mise en uvre ncessite la dfinition des mtriques utiliser, qui varient dun outil lautre (mais qui sont globalement quivalentes). Il est impratif dobtenir 100% de couverture, ou tout au moins de justifier les carts (les drogations sont trs limites et non fonctionnelles) Cest accessoirement un excellent dtecteur de redondances et de code mort Cest un excellent moyen daccroitre lexhaustivit et donc la qualit dune vrification

Ce document est la proprit de DMAP. Le contenu ne peut tre reproduit ou utilis sans lautorisation crite de la socit.

LA DO-254 pour les nuls (6) Le paradoxe de la couverture de code

Par ailleurs, il sagit dune mesure de la qualit de la vrification, qui est ncessaire, mais pas suffisante : 100% de couverture de code, nassure absolument pas la couverture de la fonctionnalit : pensez un test exhaustif qui couvrirait tous les cas possibles, sans connatre la fonction de lobjet, ses modes de fonctionnement, lenchainement logique des squences A linverse, si une fonction nest pas couverte 100% au sens de la couverture de code, il est probable que la vrification doit tre amliore (cas de figure non couvert, tat jamais atteint..). Comme on le constate , il sagit dune technique largement rpandue (en tout ce devrait tre le cas) qui est un lment indispensable du flow de conception des circuits intgrs numriques complexes, ASIC et FPGA. Donc applicable un dveloppement structur et organis, qui procde de lutilisation de bonnes pratiques de conception, avec un objectif affirm de qualit de la vrification. Quen dit donc la DO254 ?

Code coverage et DO254.

Malheureusement, la DO254 nen parle absolument pas. Sauf de faon extrmement subliminale dans la trop fameuse annexe B. La DO178 y consacre un chapitre entier, en dnommant la technique structural Coverage Analysis (ce qui confirme quil sagit bien dune mtode danalyse structurelle (cf annexe B). Cependant la jurisprudence de ces dernires annes a rendu quasiment incontournable lappel cette analyse dans le cadre de dveloppement hardware (de composants numriques bien entendu), au moins pour des designs de niveau A ou B (et probablement pour les DAL C aujourdhui). LEASA comble ce dficit (pas dactivit dcrite dans la DO254), via son dernier (et premier) Certification Memo consacr la mise en uvre de la DO254 ( EASA CM - SWCEH 001 ). Dans le chapitre ddi la vrification on trouve un sous-chapitre consacr la Verification of the design description qui contient la couverture de code : Verification of the design description stands for verification of the design at code level (e.g. HDL) and thus before Place & Route. . g. If a Hardware Description Language (HDL), as defined in ED-80/DO-254, is used, an HDL code coverage measurement is an acceptable means to assess the way the HDL code has been exercised during device functional verification by simulation. (EASA CM - SWCEH 001 8.4.2.1) Ce texte reprend le contenu de documents spcifiques non publics, lis un avion ou un hlicoptre (CRI-F16 pour lEC175B par exemple). Cependant il possde une autre force, puisquil est maintenant public et probablement applicable pour les futurs dveloppements. Donc nous pouvons conclure ce chapitre en constatant que la couverture de code est quasiment un delivrable obligatoire dune conception de composant numrique soumis la DO254.

Ce document est la proprit de DMAP. Le contenu ne peut tre reproduit ou utilis sans lautorisation crite de la socit.

LA DO-254 pour les nuls (6) Le paradoxe de la couverture de code

Le paradoxe.
Le rapprochement de deux objectifs majeurs de la DO254, tels que nous venons de les dfinir, conduit un constat trs tonnant. La couverture fonctionnelle sattache la vrification des exigences (de la spcification) sans se proccuper des solutions mises en uvre Lindpendance design/vrification renforce cette approche bote noire de la couverture fonctionnelle Dans le cas dune conception de FPGA le vecteur principal de la couverture fonctionnelle est la simulation (un testbench qui droule un certain nombre de testcases). La couverture de code ne sattache qu lexhaustivit de lanalyse du code (vision bote blanche) Le support de la couverture de code est galement la simulation (en fait le code coverage est un appendice du simulateur logique).

La question que tout designer se pose est la suivante :

Quelle efficacit, en termes de couverture de code, peut avoir un testbench dvelopp en aveugle total, sans aucune visibilit du code (parfois avant lcriture du code) ?
La premire rponse est vidente : les deux objectifs sont incompatibles et la couverture de code par un test dvelopp en aveugle est probablement trs mauvaise et incomplte. La pratique, couple avec un peu de rflexion, donne un rsultat tout autre. Le niveau de couverture du code obtenu partir dune couverture fonctionnelle est toujours proche de la perfection (100%).

Pourquoi ? Tout dabord il faut faire quelques hypothses concernant le dveloppement : La spcification (exigences) a t valide et est donc rpute complte et correcte : le vrificateur part dune entre utilisable et suffisamment claire et prcise (description de la fonction) La vrification fonctionnelle couvre compltement la fonction (objectif majeur de la vrification) Le code HDL reprsente exactement la fonction ( partir de la spcification)

Ce document est la proprit de DMAP. Le contenu ne peut tre reproduit ou utilis sans lautorisation crite de la socit.

LA DO-254 pour les nuls (6) Le paradoxe de la couverture de code

En gros tout le monde a bien travaill, ce qui arrive avec une quipe performante et efficace (et une bonne dose de relecture et de revues). Dans ce cas, toutes les lignes de code, toutes les branches des machines dtat, ont une raison dtre et doivent correspondre la mise en uvre dun besoin de la spcification (travail du designer) Donc la vrification fonctionnelle doit passer cet endroit lorsque la partie correspondante de la fonctionnalit est teste (travail du vrificateur)

Le rapprochement des deux univers (design et vrification) doit donc conduire gratuitement un niveau de qualit lev (cest--dire une couverture de code trs satisfaisante).

Bien entendu, il reste toujours quelques cas non compltement couverts quil faut examiner attentivement : Du code mort, de la redondance ou des transitions impossibles (modification du code) Des configurations non testes (complment de la vrification) Un dficit de clart ou de prcision de la spcification (complment de la vrification ,reprise de la spcification)

Au final, aprs cette phase de finalisation, en principe marginale, la spcification, le code et la vrification fonctionnelle ont gagn en qualit et en maturit.

CQFD

James Bezamat, novembre 2011

Ce document est la proprit de DMAP. Le contenu ne peut tre reproduit ou utilis sans lautorisation crite de la socit.

DMAP EXPERT DMAP-IP

DMAP DESIGN

DMAP Design Methods and Assurance Process

100 Route des Houillres13590 MeyreuilBP 2 04.42.61.29.13 contact@dmap.fr

DMAP est membre du Groupement

Ils font confiance DMAP

Ce document est la proprit de DMAP. Le contenu ne peut tre reproduit ou utilis sans lautorisation crite de la socit.

www.dmap.fr