rapport de stage

ACISTEC Engineering et SEICA France 14 avril – 27 juin 2003

Thomas FAYOUX 1 / 35 Rapport de stage


Développement d’un

traducteur de modèles

de composants

SI 635 SEICA



REMERCIEMENTS

Je remercie mes maîtres de stage, Gilles LETEINTURIER et Stéphane DUPOUX, qui m’ont suivi et aidé tout au long de ce stage. Je remercie également toute l’équipe d’ACISTEC pour l’accueil qui m’a été réservé durant ces douze semaines.Je souhaite également remercier mon tuteur de stage, Monsieur JOISEL, d’être venu me voir en entreprise.



RESUME

Le projet que l’on m’a confié lors de ce stage était de créer un traducteur de modèles de tests de composants. Le rôle de ce traducteur est de traduire les modèles de tests compris dans la bibliothèque du banc de test Schlumberger SI 635 de façon à ce que ces différents modèles soient utilisables par les testeurs de la gamme SEICA. Ces différents modèles de tests traduits seront intégrés aux testeurs SEICA et permettront ainsi de compléter les tests in-situ des cartes en post production. Pour développer ce logiciel, nous avons utilisé Lab Windows CVI et les tests ont été réalisés sur le testeur SEICA S40 Evolution.

ABSTRACT

The project that I’ve done during this stage was to create a translator of tests models. The translator has been done to translate the tests models that are in the library of the test bench Schlumberger SI635 to be able to use these tests models on SEICA’s testers. These different tests models translated will be put in the SEICA’s test benches and will complete the in-situ tests of the electronic cards in postproduction. To create this soft, we used Lab Windows CVI and all the tests have been done on the test bench SEICA S40 Evolution.



GLOSSAIRE

Test in-situ : Test portant sur un composant particulier sans prise en compte de l’environnement du composant.

Test fonctionnel : Test portant sur un ensemble fonctionnel (plusieurs composants) qui permet de tester la validité de cet ensemble.

Test dynamique : Test dont le timing est géré par une carte temps réel

Test statique : Test dont le timing est géré par le PC

Testeur à lit de clous : Testeur dont les contacts entre les canaux du testeur et la carte sont réalisés à l’aide de clous positionnés sur une planche (clou par équipotentielle).

Testeur à sondes mobiles : Testeur dont les contacts entre les points de mesure de la carte et les canaux sont réalisés à l’aide d’une ou plusieurs sondes montées sur une ou plusieurs tables XY.

Pattern : Période dans un programme fonctionnel, le pas de test

Cluster : Sous programme décrivant le test d’une chaîne fonctionnelle

U.U.T : Elément à tester, unit under test

Sonde guidée : Sonde gérée par le testeur demandant à l’opérateur de pointer pour effectuer l’acquisition des données en automatique



SOMMAIRE

I ) DEUX SOCIETES DANS LE DOMAINE DU TEST ELECTRIQUE p8 à 13

1 ) ACISTEC Engineering p9 et 101.1) Quatre domaines d’activité différents p9 et 10

2 ) SEICA p11 à 132.1) Situation géographique p112.2) Une présence internationale p112.3) Une société performante et à taille humaine p122.4) Quelques caractéristiques des testeurs SEICA p122.5) Quelques dates importantes p13

II ) LE TRADUCTEUR p14 à 33

1) Les testeurs et l’architecture de leurs fichiers p15 à 17

1.1) Le testeur Schlumberger SI635 p151.2) Les testeurs SEICA p16

1.2.1) Structure d’un fichier .PAT p161.2.2) L’interface de test et de debug p16

1.3) Conclusion p17

2) Conception de traducteur p18 à 20

2.1) Architecture des programmes p182.2) Tableau comparatif des instructions p18 et 192.3) Outils de validation p20

3) Réalisation du traducteur p21 à 33

3.1) Les instructions communes à tous les fichiers de testp21 à 26

3.1.1) Création des fichiers .PAT et .SRG p22

3.1.2)Traduction des instructions communes p23 à 26et des éléments de configuration

3.2) Les premières instructions traduites p26 à 283.3) Validation p293.4) Remise à niveau p30 à 323.5) La recette p33

4) Les interfaces utilisateurs p34



4.1) Le traducteur p344.2) L’affectation des canaux p34



INTRODUCTION

Lors de mon stage, j’ai dû réaliser un traducteur de modèles de tests de composants. Ce traducteur sert à transférer des modèles de tests d’un ancien testeur, le Schlumberger SI 635 in-situ à pince, vers un testeur plus récent, le S40 Evolution de SEICA qui est un testeur fonctionnel. Les langages de test sur ces deux machines étant différents, il nous fallait donc pouvoir transférer automatiquement un modèle de test du banc de test Schlumberger au testeur SEICA. Pour cela, nous avons créé un traducteur qui permet de traduire puis d’utiliser sur tous les testeurs SEICA les modèles de tests du testeur Schlumberger.

Les modèles de tests, ainsi traduits, serviront par la suite à tester en in-situ (un par un) les composants placés sur des cartes. Ces modèles de tests complèteront les tests car ils permettront de vérifier le fonctionnement des composants placés sur la carte.

Le traducteur a été développé en langage C à l’aide du logiciel Lab Windows CVI. Nous avons aussi créé un adaptateur nous permettant de tester les modèles traduits à partir d’un outil du testeur Schlumberger.

Ce projet s’est déroulé comme suit :- Apprentissage du fonctionnement puis des instructions des deux

bancs de test.- Réalisation d’un tableau comparatif des instructions des deux

testeurs.- Conception du traducteur et de l’adaptateur de test.- Enfin, traduction des modèles de tests.



PLANNING D’ACTIVITE

Activité Semaine 1 Semaine 2 Semaine 3 Semaine 4 Semaine 5 Semaine 6Apprentissage des commandes du SI635 Apprentissage des commandes du S40 Réalisation du traducteur Test des modèles traduits Traduction des modèles du SI635

Activité Semaine 7 Semaine 8 Semaine 9 Semaine 10 Semaine 11Apprentissage des commandes du SI635 Apprentissage des commandes du S40 Réalisation du traducteur Test des modèles traduits Traduction des modèles du SI635

Ce planning est équivalent au planning qui m’a été présenté lors de mon arrivée en avril ce qui signifie que les délais ont été respectés et que les objectifs ont été remplis.



1) ACISTEC Engineering

Située à Buc, au sud de Versailles, Acistec Engineering est une entreprise créée en 1991 qui emploie une quinzaine de personnes, de tous niveaux, du technicien à l’ingénieur, dans le domaine de l’électronique.

Le chiffre d’affaires d’Acistec est d’environ 1,4 millions d’euros. Il est réparti de la façon suivante :

- 65% liés au développement de bancs de test et de logiciels de test.

- 25% pour la maintenance.- Et 10% pour le négoce.

Acistec effectue de la maintenance dans différents domaines, notamment le secteur médical, la monétique ainsi que l’aviation civile et militaire.

Acistec Engineering a comme clients, aussi bien des grandes entreprises telles que Dassault électronique, Thalès (ex Thomson CSF), que des petites entreprises comme Sticom.

1.1) Quatre domaines d’activité

1.1.1) Le test

L’activité TEST concerne l’élaboration des outillages de test complet, c’est à dire logiciels et interfaces. Les logiciels sont développés sur


IDeux sociétés

dans le domaine du test

électrique


différents bancs de test, qui sont soit développés en interne soit achetés dans le commerce, tels que le Schlumberger SI 635 qui est un testeur à pinces in-situ qui permet de tester des composants un à un mais qui rend le test d’une carte très long. Acistec possède aussi un testeur Schlumberger S745 à lit de clous in situ qui est bien plus rapide d’utilisation que le Schlumberger SI 635 mais son utilisation nécessite l’achat de lit de clous pour chaque carte différente, ce qui le rend plus onéreux. Enfin Acistec possède également un banc de test POLAR T6000 (analyse de signature) qui est utilisé pour tester des cartes analogiques ou des alimentations.Il manquait à Acistec une possibilité de test fonctionnel, ils ont donc fait l’acquisition d’un testeur SEICA S40 Evolution qui est un banc de test fonctionnel.

1.1.2) La maintenance

La maintenance peut être curative ou préventive (sur site ou en atelier). La maintenance est faite en fonction des besoins sur des cartes ou équipements électroniques.De plus Acistec effectue une intégration des sous-ensembles testés et réparés dans le système auquel ils sont destinés et contrôle ainsi le bon fonctionnement des sous-ensembles.

L’équipement suivant permet de tester un lecteur de cartes de crédit :

1.1.3) L’étude

Le bureau d’étude réalise la conception de systèmes analogiques et numériques. Et pour ces systèmes, ACISTEC Engineering assure toutes les étapes du développement, de la simulation en CAO jusqu’au circuit imprimé.



Le test de tous les prototypes est effectué dans les locaux ou, si nécessaire, dans l’environnement final d’utilisation.Cette autonomie permet à ACISTEC de développer ces produits dans des délais réduits.

1.1.4) La réalisation

Acistec produit des cartes électroniques. C’est une production à faibles volumes pour des produits dont la fabrication automatisée n’est pas nécessaire. La gamme de produit s’étend de la carte à circuits CMS jusqu’au câblage d’armoires électriques.



2) SEICA

ACISTEC étant le partenaire particulier de SEICA France, le traducteur que j’ai réalisé est en fait destiné aux machines conçues par SEICA. Je vais donc, dans cette partie, vous présenter la société SEICA France.

2.1) Situation géographique

Un des leaders mondiaux dans le domaine du test de cartes câblées et de circuits nus. Basée en Italie, une filiale française a été crée en 2000.

Siège de SEICA en Italie Filiale de SEICA en France

La SARL SEICA France a pour but, dans une démarche uniquement de commercialisation et de support, de représenter la société SEICA SPA, basée en Italie et qui s’occupe de toute la partie étude et fabrication.

2.2) Une présence internationale

La marque SEICA est représentée sur tous les continents comme le montre la carte suivante :

Aujourd’hui, il existe quatre filiales de SEICA dans le monde : en Italie, en France, en Chine et aux Etats Unis.



550 systèmes SEICA sont actuellement installés dans le monde.

2.3) Une société performante et à taille humaine

Le diagramme suivant nous montre le chiffre d’affaires de SEICA depuis 1997 ainsi que le nombre d’employés de l’entreprise.

Les employés de la société assurent cinq rôles principaux :- La promotion des produits- La formation des clients- Un support en Hot-line- Le maintien des équipements, via la télé-assistance- Le développement de programmes (in-situ, fonctionnels) et

activités connexes (librairies).

2.4) Quelques caractéristiques des testeurs SEICA

Toute la gamme de testeurs SEICA possède une base hard et soft unique, c’est à dire :

- Un même rack de cartes pour tous les systèmes- Un même logiciel S20Win pour tous les systèmes- Un même programme de test, ce qui permet une

interchangeabilité totale



- Une évolutivité garantie grâce à la modularité de tous les

systèmesLa gamme variée de testeurs in-situ et fonctionnels peut se répartir en trois différents types de testeurs :

Testeurs in-situ ou combinés à lit de clous Testeurs fonctionnels Testeurs à sondes mobiles2.5)

Quelques dates importantesLe diagramme ci-dessous montre comment SEICA a évolué depuis la création des premiers testeurs in-situ en 1991 jusqu’aux innovations les plus récentes.

Pour conclure, SEICA est, aujourd’hui, une société mondialement connue dans le domaine du test. En France, elle possède des contrats avec Alcatel, Motorola, Bosch, Legrand ou encore la SNCF.


1995 1999

Développement du premier

testeur pour circuits nus

Accord de représentation avec

S40 Compact S40 Valid

-Testeurs à sondes mobiles

S40 Pilot S40 Pilot LX


IILe traducteur



1) Les testeurs et l’architecture de leurs fichiersLe testeur Schlumberger SI635

Testeur in-situ à pinces, le SI635 permet de tester les composants jusqu’à 64 broches. Le testeur émule les broches en entrée et vérifie que la sortie est exacte.Pour effectuer ces opérations, il faut créer un fichier « .SR » qui gère la totalité du test du composant. Ce fichier définit le composant (c’est à dire les broches, les niveaux de test) ainsi que les actions effectuées sur le composant pour le tester. Le fichier est structuré comme suit :

Un test commence toujours par son numéro « TX : » et est directement suivi par l’identification du test suivant. Tous les tests se finissent par « CLEAR » qui marque la fin du test et réinitialise le composant.

Le terme « exit » après le début d’un test montre que c’est le dernier test.


Affectation de canauxN° broche = Nom

Définition des paramètres

d’alimentation et des niveaux de test

T1 :ID 1 T2…CLEAR

T2 :ID 2 T3…CLEAR

Définition des macros.

Vérification des connexions, de

l’orientation de la pince et des courts-circuits

T30 :EXIT


S’il y a des subroutines et /ou des data, elles sont définies à la fin du programme.

1.1)Les testeurs SEICA

Pour les tests sur un testeur SEICA, il est nécessaire de posséder au moins deux fichiers : le .SRG et le .PAT. Le fichier « .SRG » contient la configuration du test, c’est à dire les niveaux d’entrée et les niveaux de mesure, la gestion de l’alimentation et l’appel des différents tests nécessaires à la vérification du composant. Le fichier « .PAT » contient les différents tests ainsi que la déclaration des canaux et tout ce qui est nécessaire aux tests comme le timing.

1.2.1) Structure d’un fichier .PAT

Chaque test est encadré par « START X » et « ENDTEST ».

1.2.2) L’interface de test et de debug

Tous les testeurs SEICA utilisent le même logiciel, S20 Win, c’est donc le logiciel que nous avons utilisé pour tester les composants sur le banc de test SEICA.


Affectation de canauxLabel = n° canal

Déclaration du timing.

START TI ;…

ENDTEST ;

START T2 ;…

ENDTEST ;

Définition des macros.

Définition des subroutines et des data


Ce logiciel est très simple d’utilisation, il permet d’émuler la carte connectée au testeur à l’aide des informations comprises dans les

fichiers de test (.PAT, .SRG). Ces fichiers étant au format ASCII, ils sont accessibles par d ’autres applications.Il est possible d’obtenir les chronogrammes de chaque canal utilisé ce qui permet de déceler aisément la cause d’un problème.

L’interface de test du logiciel S20 Win.

1.2)Conclusion

A l’aide des schémas ci-dessus, nous pouvons remarquer que les architectures des fichiers .SR pour le SI635 et .PAT pour les testeurs SEICA sont très proches. La plus grande différence réside dans le fait que les niveaux sont déclarés dans le fichier .SR pour le testeur Schlumberger alors qu’ils sont définis dans le fichier .SRG pour les bancs de tests SEICA.Par ailleurs les deux langages sont eux aussi assez proches et c’est la raison pour laquelle les dirigeants de SEICA et ACISTEC ont décidé de créer ce traducteur.

Le fait que les deux langages soient très proches va nous permettre de pouvoir créer un tableau des équivalents qui nous indiquera ce qu’il faut traduire. Comme les niveaux ne sont pas définis dans le même fichier, nous avons hésité entre deux possibilités, soit créer un fichier .SRG en plus du fichier de test, soit écrire ces niveaux dans un fichier texte.Nous avons décidé de créer un fichier .SRG car il nous a paru plus simple pour l’utilisateur de ne pas avoir à créer ce fichier. De plus, le fichier .SRG contient l’appel des clusters, il était plus simple de le créer en même temps que le fichier .PAT.



2) Conception de traducteur

Ce traducteur a été créé de façon à importer les modèles de tests de composants du testeur SI635 de Schlumberger sur le testeur S40 évolution de Seica.

Le but est de récupérer un grand nombre de fichiers de test sur le testeur Schlumberger puis de traduire ces fichiers afin d’obtenir les fichiers nécessaires au test sur le testeur Seica. Nous partons donc de fichiers de test Schlumberger et nous devons créer les deux fichiers nécessaires aux testeurs Seica.

2.1) Architecture des programmes

Les fichiers .SRG et .PAT peuvent être structurés de deux façons comme le montre les schémas suivants :

Nous avions le choix entre créer un fichier avec tous les tests ou un fichier par test. Chacune des méthodes avaient ses avantages : le fait de faire plusieurs fichiers .PAT était intéressant car il simplifiait les fichiers de test, mais le fait de ne faire qu’un fichier avait l’avantage de réduire le nombre de fichiers nécessaires pour effectuer un test. Elles avaient aussi leurs inconvénients : la première nous obligeait à avoir énormément de fichiers et donc de déclarer les canaux, les macros et le timing dans chaque fichier et l’inconvénient majeur de la seconde méthode était que nous ne savions pas si le fait d’avoir plusieurs tests séparés dans un seul fichier .PAT fonctionnait.Nous avons décidé, dans un souci de facilité d’accès et de nombre de fichiers, d’adopter la solution avec tous les tests dans un fichier « .PAT » car nous avons eu la confirmation que cela était possible. Cette solution nous permet de n’avoir que deux fichiers et de ne déclarer qu’une fois les canaux, les bus, le timing et les macros.

2.2)Tableau comparatif des instructions


.SRG

SP1

SP2

.PATSP1

.PATSP2

.SRG

SP1

SP2

.PAT

SP1

SP2


Le tableau suivant montre les différentes instructions existantes sur le testeur Schlumberger et leur équivalent s’il existe sur le testeur SEICA. Ce tableau résume les instructions qu’il m’a fallu traduire pour créer le traducteur. Certaines fonctions ne sont pas traduites car elles ne servent pas dans le programme SEICA ou elles n’ont pas d’équivalent ou de traduction possible.

Fonctions Schlumberger Equivalent SEICA Commentaires

; Output, 1st Gate ! Ou * Commentaire

BEGIN 7400

DEFPINS 14

PIN 1 1A I DECLARE CHANNEL S2 = 12 Déclaration de canal

DEFBUS 1BUS 1Q 1NQ DECLARE GROUP DATI = 1,2,3,4 Déclaration de bus

PARAMETER DEFAULT VOLTRANGE 0:5 POWER 5 : VCC IH 4.25 DVH=4.25 : ALL Niveau haut des entrées

IL 0 DVL=0 : ALL Niveau bas des entrées

TL 2.3 THH=2.3 : ALL Seuil du niveau haut en sortie

TH 0 THL=0 : ALL Seuil du niveau bas en sortie

PULLUP STD : 1 4 10 13 PULLDN STD : 1 DEFSHORTS TIED/2-9/15 T1: START PRG1 Début d'un test

END / EXIT / CLEAR ENDTEST Fin d'un test

ID 1 T2 HIGH A0 A1 IH S2 Mise à l'état haut

LOW A2 A3 IL S2 Mise à l'état bas

HINM MH Etat haut non auto contrôlé

LONM ML Etat bas non auto contrôlé

SET 1 0 0 1 0 IG ADDHH=0x55 Attribue la valeur d'un groupe

TESTH 1Y OH S2,S4 Vérification de l'état haut

TESTL 1Y OL 1/8 Vérification de l'état bas

TESTV 1Y : 1.2 2.4 MEASURE 1BUS 1 0 OG DATHH=0x4F Vérification de l'état du bus

STH CLK @MACRO STH (@CAN) Front descendant

IH @CAN;/;

IL @CAN;/;

@ENDMACRO

STL CLK @MACRO STL (@CAN) Front montant

IL @CAN;/;

IH @CAN;/;

@ENDMACRO

DROP 1D Masque une broche ou un bus

BDROP BUS1 Masque un bus

BLOOP LOOP1 @FOR I=1 TO 6 Début d'une boucle

ELOOP LOOP1 ENDFOR Fin de la boucle et décrémentation

GOSUB CLK @STH Utilisation d'un sous programme

SUBROUTINE CLK @MACRO STH Début d'un sous programme

RETURN CLK @ENDMACRO Fin d'un sous programme



LOAD Charger un registre

XEQ Ecrire une commande selon la valeur

du registre concerné

INC Incrémenter la valeur du registre

DEC Décrémenter la valeur du registre

! Pas de pattern la commande et la précédente sont effectuée

En même temps.

1 X X X X X X X Ne modifier qu'une broche d'un bus

Fonctions non traduites

Fonctions simples

Fonctions complexes

Fonctions traduites à l’aide du fichier .SRG

2.3)Outils de validation

Pour valider la traduction, il fallait un moyen de pouvoir tester les composants dans le même état, sans rajouter d’incertitude vis à vis de la traduction. Pour cela, mes maîtres de stage m’ont invité à créer un adaptateur (Voir dossier de définition (Annexe 1 page III)) me permettant de connecter l’IC TEST STAND du testeur Schlumberger au testeur SEICA S40 Evolution.L’IC TEST STAND est un boîtier permettant de tester des composants jusqu’à 64 broches.

Il y a 64 points de mesure sur l’ICT, j’ai dû choisir quels canaux j’allais utiliser :

- J’ai connecté les 32 premiers points de l’ICT avec les 32 premiers points du Schlumberger.

- Les points de 33 à 64 de l’ICT sont connectés sur les canaux de 128 à 97.

- Nous avons choisi de nous connecter sur l’alimentation PW4.- L’alimentation et la masse sont connectées à deux douilles



Connecteurs vers le testeur SEICA (96 broches).

Connecteur servant à brancher L’ICT (64 broches).



3) Réalisation du traducteur

3.1) Les instructions communes à tous les fichiers de test

3.1.1) Création des fichiers .PAT et .SRG

La création de ces deux fichiers est le rôle principal du traducteur donc dans cette partie, nous allons expliquer les étapes principales qui nous permettent de créer ces fichiers.

Tout d’abord, nous créons le fichier .PAT à l’aide des opérations suivantes. L’ordre de ces opérations est important car il nous permet d’écrire le fichier du début à la fin sans avoir à nous replacer à un endroit précis dans le fichier.Le diagramme suivant montre les grandes étapes de la création des fichiers de test.

Dans cette fonction, on recopie l’entête. On remplace la marque des commentaires « ; » par des « * ».

On traduit les déclarations des broches puis on écrit dans le fichier de test et dans le fichier où l’on conserve ces déclarations, le nom des broches et leur numéro ainsi que le nom des bus et des broches qui le compose.

On insère le timing qui est le même pour chaque programme. On insère aussi des macros qui sont communes à tous les programmes.

Dans cette fonction on récupère les subroutines définies à la fin du fichier Schlumberger, on les traduit et on les place à la suite des macros communes.


Réécriture de l’entête.

Traduction des déclarations des canaux.

Ecriture du timing et des

macros.

Récupération et écriture des subroutines

supplémentaires


On traduit toutes les fonctions une par une et on les réécrit en langage Seica.

On crée le fichier de configuration « .SRG » qui contient

la valeur de tous les niveaux et la définition de

l’alimentation.

3.1.2) Traduction des instructions communes et des éléments de configuration

Déclaration des canaux et des bus

La fonction de gestion des canaux a pour but de récupérer le nom et la broche qui sont associés de façon à savoir à quelle broche correspond un nom. Dans le cas d’un bus, cette fonction nous permet de connaître les différentes broches associées à ce bus ainsi que le nombre de broches qui composent le bus.


Traduction des différents tests.

Création du fichier .SRG


Déclaration d’une broche ou d’un bus

Pour effectuer la traduction des broches on lit les lignes du fichier du SI 635 du début jusqu’à ce que le premier mot de la ligne soit « PIN » et dans ce cas on traduit. La traduction de cette ligne, par exemple :

« PIN 1 VCC V ;+5 VOLTS ».


Non

Non

Non

Oui

Oui

Oui

Récupération de la ligne et lecture du premier mot

de la ligne.

PIN ?

PARAMETER ?

DEFBUS ?

Utilisation de la fonction de

définition d’un bus.

Utilisation de la fonction de

définition d’un canal.

Passage à la ligne suivante.

Le premier mot de la ligne est toujours la fonction.

Traduction des macros.

(Fonction suivante)


Tout d’abord, on récupère le nom et le numéro de la broche (ici 1 et VCC). On récupère aussi, si cela est précisé le fait que la broche soit une entrée ou une sortie (ici la broche est une alimentation de V) et les commentaires s’il y en a (les commentaires commencent à partir du « ; »).

Une fois toutes les informations récupérées, on écrit dans le fichier .PAT et dans un fichier qui regroupe toutes les définitions de broches ; ce fichier nous permet de savoir à tous moments à quoi correspond telle ou telle broche. Dans le fichier .PAT on écrit, par exemple :

« DECLARE CHANNEL VCC= 1 ; !+5 volts »

Lorsque le premier mot de la ligne est « DEFBUS », alors on déclare un bus qui est un ensemble de lignes signaux parallèles, regroupé à cause de leur similarité.Lors de la traduction d’un bus, par exemple :

« DEFBUS DBUS D0 D1 D2 D3 ;OUTPUT BUS »

Il nous faut récupérer le nombre de broches associées à ce bus ainsi que le nom de chaque broche qui compose le bus. On récupère aussi, s’il y en a, les commentaires. Pour obtenir le nombre de broches, on se repère à l’aide du « ; » qui indique les commentaires :

- S’il y a un « ; », il nous suffit de savoir avant quel mot il est placé pour connaître le nombre de broches du bus.

- S’il n’y en a pas alors le nombre de broches associées au bus est le nombre de mots de la ligne moins « DEFBUS » et le nom du bus.

Ensuite on écrit les informations ainsi récupérées dans le fichier « .PAT ». De plus les broches d’un bus ne sont pas définies dans le même sens sur les deux testeurs. Sur le testeur Schlumberger, la première broche déclarée dans le bus est le MSB (most significant bit) alors que sur le testeur Seica la première broche déclarée est le LSB (least significant bit). Il faut par conséquent inverser les broches lors de la déclaration du bus.

On écrit également les informations concernant le bus dans le fichier qui regroupe toutes les définitions de bus de façon à pouvoir récupérer la liste des broches qui compose un bus ainsi que leur nombre. Ce fichier nous sert, lors de certaines fonctions, à savoir quelle broche est concernée par la fonction si toutes les broches du bus ne sont pas concernées. Dans le fichier .PAT on écrit, par exemple :

« DECLARE GROUP DBUS=D3,D2,D1,D0; !OUTPUT BUS »



Gestion du timing

On a donc écrit dans le fichier « .PAT » l’entête et les définitions des broches et des bus. Après cela vient la définition du timing qui gère l’horloge, la longueur de chaque pattern ainsi que le moment de mesure du canal.

Le timing étant le même pour chaque composant, on insère un timing comme dans tous les modèles de tests. On peut décider de changer la valeur de l’horloge après la traduction en changeant sa valeur dans le fichier « .PAT »Un exemple de timing :

« TIMING TIM1; PERIOD 10C; Indique la longueur de la

période. STROBE 9C; Indique le moment de la mesure. ENDTIMING; CLOCK=100N; » Valeur de l’horloge.

La période représente la durée de la phase active, cette phase est appelée pattern. Cette phase est comprise entre deux symboles ‘/’ et toutes les actions entre ces deux symboles sont effectuées simultanément. La valeur de « STROBE» permet de choisir à quel moment de la phase active a lieu la mesure.

Par exemple :

« IH XA ;/ ; IH XB ;/ ; »

Equivaut à :

Les macros

Après le timing il nous faut définir les différentes macros qui seront utilisées dans le test. En fait il y a deux types de macros différentes :

- Tout d’abord il y a les macros que l’on insère d’office dans le programme de test car elles sont communes à tous les tests mais ne sont pas toujours utilisées.

- Ensuite, il existe des macros qui sont spécifiques à un programme particulier. Ces macros sont définies à la fin des programmes du SI635, il faut donc les lire et les traduire pour les placer dans le fichier « .PAT ».


XA

XB


Il existe cinq macros que l’on insère dans tous les programmes. Ces macros sont en fait les traductions de fonctions du testeur Schlumberger qui n’existe pas sous cette forme sur le testeur Seica. Ces instructions étant en fait une simplification d’écriture, il nous suffit de les développer dans une macro.

Deux de ces macros sont des traductions de fonctions du SI635 qui servent à créer des fronts montant et descendant. On a, par conséquent, traduit ces fonctions par une mise à l’état haut suivie d’une mise à l’état bas pour un front montant et inversement pour un front descendant. Voici par exemple la macro utilisée pour créer un front descendant :

« @MACRO STL (@CAN1,@CAN2,@CAN3); IL @CAN1 @CAN2 @CAN3; /; IH @CAN1 @CAN2 @CAN3; @ENDMACRO; »

Les trois autres macros que l’on insère sont des fonctions du testeur SI635 qui concernent les mémoires. Ces fonctions permettent de rafraîchir les cellules des mémoires. De la même façon que pour les fronts, on les traduit en les remplaçant par la suite de fonctions quelles représentent.

Ces cinq macros sont donc introduites dans tous les fichiers traduits, même si elles ne sont pas utilisées, mais il peut aussi exister des macros spécifiques au test d’un composant. Dans les programmes du SI635, ces macros sont appelées « subroutines » et sont placées à la fin du fichier, après tous les tests. Elles se présentent comme suit :

« SUBROUTINE TCLK LOW TXC E HIGH TXC E RETURN TCLK »

Pour traduire ces subroutines, on repère le mot « SUBROUTINE » . Alors on récupère son nom et on la réécrit dans le fichier « .PAT » sous la forme d’une macro, avant les tests. Pour traduire les fonctions utilisées dans la subroutine, on utilise la fonction qui traduit les différents tests. Lorsqu’on lit le mot « RETURN », on ferme la macro. Dans les programmes de test du testeur Schlumberger, pour appeler une macro, la commande « GOSUB » est utilisée. Il nous fallait, nous aussi, appeler les macros, pour cela il suffit d’écrire leur nom précédé de @, avec si nécessaire, les informations utiles entre parenthèses.

La création du fichier .SRG



Une des fonctions que nous avons développée nous permet de créer un fichier qui est nécessaire à la compilation sur le testeur Seica tandis que sur le SI635, toutes ces informations sont comprises au début du fichier contenant les tests.

Le fichier .SRG est le fichier de configuration, il contient les informations de réglage des alimentations et des niveaux de test ainsi que l’appel des tests nécessaires au composant. Pour le créer, il nous faut le nombre de pattes du composant, les pattes reliées à la masse ou au +VCC, le nombre de tests, la valeur de son alimentation et celle de ses niveaux. On donne aussi dans ce fichier des informations utiles, par exemple si le composant a besoin de résistances de pullup.

Toutes ces informations sont comprises dans le fichier du testeur Schlumberger, par exemple : « VOLTRANGE 0 5

POWER 5 : VCC POWER 0 : GNDIH 4.25 IL 0 TH 2.3 TL 0.8 PULLUP STD : 7 »

Donc pour créer le fichier .SRG, on récupère toutes ces informations et on les traduit de façon à avoir les niveaux et alimentation correcte lors du test .

3.2)Les premières instructions traduites

Après que la définition de tous les éléments de configuration ait été effectuée, on commence la traduction des tests. Pour cela on a créé une fonction qui traduit une ligne qu’on lui fournit afin de créer une fonction compatible avec le banc de test Seica. La ligne ainsi traduite est écrite dans le fichier « .PAT ». Toutes les fonctions du SI635 sont traduites en passant par cette fonction même si certaines nécessitent l’utilisation d’une fonction complémentaire.

Sur le SI 635, les fichiers de tests sont séparés en différents tests écrits comme suit :

T1:ID 1 T2HIGH 1A



TESTL 1YCLEAR

« T1 : » : représente l’indicateur de test.« ID 1 T2 » : donne le numéro du test et annonce le prochain test.« HIGH, TESTL » sont différentes fonctions possibles.« CLEAR » est placé à la fin du test. Il réinitialise le composant et passe au test suivant.

Pour traduire les différents tests on se repère grâce à « TX : » pour le début d’un test et avec « CLEAR » pour la fin du test. On traduit ces deux fonctions par les fonctions « START XXXX » et « ENDTEST».

Au début, nous avons commencé par créer la traduction pour les fonctions qui se traduisent simplement, grâce à leur équivalent sur le S40.

Nous avons traduit les fonctions de commande des entrées et de mesure des sorties :HIGH 1A devient IH 1A. Pour traduire ces fonctions, il nous a fallu remplacer HIGH par IH. Une des premières difficultés est de savoir combien de broches sont concernées par une de ces fonctions. Par exemple la fonction peut avoir de l’effet sur cinq broches. Il faut donc savoir combien et quelles broches sont concernées. Pour connaître le nombre de broches concernées par une fonction, on recherche le « ; » symbolisant les commentaires sur le SI 635 de façon à déterminer le nombre de mots avant les commentaires et ainsi le nombre de broches associées à la fonction.

Cette méthode nous a permis de traduire les fonctions suivantes :- HIGH Mise à l’état haut- LOW Mise à l’état bas- LONM Mise à l’état bas sans vérification- HINM Mise à l’état haut sans vérification- TESTH Teste l’état haut- TESTL Teste l’état bas

Ainsi, pour les bus, les fonctions utilisées par le testeur Schlumberger pour assigner ou mesurer une valeur sont SET et MEASURE. Les valeurs peuvent être entrées soit en binaire soit en hexadécimal par conséquent, il nous a donc fallu gérer les deux écritures. Il suffit de remplacer SET et MEASURE par, respectivement, IG et OG et récupérer la valeur.

Parfois, pour un test, la totalité des broches d’un bus ne sont pas utiles. Il est donc nécessaire de garder la possibilité de ne modifier que telle ou telle broche d’un bus. Pour effectuer cette fonction, le testeur Schlumberger offre la possibilité de remplacer la valeur des broches non utilisées par un ‘X’.



Par exemple :

« SET DBUS 1 X X X »

Cette fonction n’existe pas sur le banc de test Seica, il nous a donc fallu créer une fonction en C qui nous permet de savoir quelles broches sont modifiées de façon à pouvoir changer l’état de chaque broche concernée par la fonction comme si on forçait cette broche à l’état haut ou à l’état bas.

On obtient, par exemple :

« IH D3 ; »



Le diagramme suivant explique comment nous avons traité cette fonction.


Lorsque l’on sait quelle broche est modifiée, il nous faut connaître le type de fonction à laquelle elle est associée (SET ou MEASURE) ainsi que l’état auquel cette broche doit être forcée ou mesurée (1 ou 0).Une fois que nous possédons toutes les informations, nous pouvons écrire dans le

Oui

Non

Oui

Non

Non

Oui

Lecture de la fonction et de la valeur du bus.

X ?

Recherche de la broche modifiée.

Ecriture normale de la fonction

dans le fichier .PAT

1 ?

On cherche, pour chaque fonction utilisant un bus, s’il y a un ‘X’ dans la valeur du bus.

SET ?

Ecriture de la nouvelle valeur de

la broche.(IH,OH,OL,IL)

Retour à la fonction de

traduction des tests.

Mémorisation de la fonction SET.

Mémorisation de la fonction MEASURE.

Mémorisation de la valeur 1.

Mémorisation de la valeur 0.


3.3) Validation

Après avoir traduit les fonctions précédentes, nous avons pu effectuer les premiers tests sur le testeur SEICA S40 Evolution. Nous avons testé un composant simple qui n’utilisait que les fonctions précédentes.Nous avons constaté qu’il existe une différence importante entre le testeur Schlumberger et le testeur Seica. Le testeur SI635 ne vérifie la valeur d’une sortie que lorsqu'on le lui demande à l’aide des fonctions TESTL, TESTH, MEASURE…. Par contre le testeur Seica vérifie en permanence la valeur de la broche ou du bus à partir de la première demande de mesure. Cette différence dans les mesures, nous oblige à masquer les broches, avec OM pour une broche et ZG pour un bus, après chaque demande de mesure. En masquant ces broches on retrouve le fonctionnement du SI635. Nous nous sommes aperçus que la traduction était exacte en regardant les chronogrammes fournis par le logiciel de SEICA. En plaçant une erreur sur le composant, elle est repérée par le testeur ce qui prouve que le test fonctionne.

En regardant les modèles de tests de composant plus complexes du testeur Schlumberger, je me suis rendu compte qu’il manquait certaines fonctions plus complexes qui seraient nécessaires lors de la traduction de ces composants. J’ai donc cherché comment traduire ces fonctions.

Lors de ce test, nous nous sommes aussi rendu compte qu’il était long de changer tous les canaux car les canaux utilisés pour tester un composant sont rarement les canaux de un à quatorze ou vingt. J’ai, par conséquent, pour simplifier cette étape, décidé de créer une interface utilisateur qui permet de faire cette affectation simplement et rapidement.



3.4) Remise à niveau

Parmi les fonctions qu’il fallait maintenant traiter, il y a des fonctions qui n’existent pas sur le banc SEICA et qui ne peuvent être traduites par des macros. Nous sommes donc obligés de les recréer. Pour traduire ces fonctions, on utilise des routines en C :

- Les fonctions « DROP » et « BDROP » sont des fonctions du testeur Schlumberger qui servent à masquer respectivement une broche ou une série de broches et un bus que ce soit une entrée ou une sortie.

- Une série de fonctions du SI635 permet de charger une suite de commandes dans un registre qui possède un pointeur que l’on peut incrémenter et décrémenter de façon à lire la commande voulue.

L’utilisation des registres

Parfois, il faut faire plusieurs fois la même suite de commandes mais avec une valeur en entrée ou en sortie qui varie, cela nous empêche d’utiliser une boucle simple. Pour éviter de compliquer et d’allonger les programmes de test, le testeur SI635, nous propose d’utiliser huit registres que l’on peut charger avec une suite de commandes qui correspondent aux valeurs successives ce qui permet l’utilisation d’une boucle. On commence par charger ce registre avec des commandes, telles que « MEASURE » ou « SET », ensuite on incrémente ou décrémente le pointeur sur le registre ce qui permet d’écrire la commande voulue et si on place cette commande dans une boucle, on peut à chaque tour de boucle écrire une valeur différente ce qui simplifie énormément le programme.

Cette fonction n’existe pas sur le banc de test Seica, il nous a donc fallu trouver une méthode pour traduire l’utilisation de ces registres.

Dans un premier temps, il nous a fallu repérer l’utilisation de registres lors des tests. Pour cela, on commence par faire une recherche du terme « DATA » qui est la commande qui précède les suites de commandes que l’on placera ultérieurement dans les registres. Pour traduire on récupère ces commandes que l’on place dans un à huit registres selon le nombre de listes de commandes.

Une fois ces listes récupérées, on continue la traduction et lorsque l’on lit le terme « LOAD » on charge le regitre désigné avec la liste voulue. Par exemple :

« LOAD IR1 B_ADD_BUS »Ici, on charge le registre IR1 avec la liste B_ADD_BUS.

Ensuite, les fonctions qui utilisent ces registres étant souvent placées dans des boucles, il nous faut différencier ces boucles des boucles « normales ». Pour cela, on lit les fonctions contenues dans les boucles et,


Non

Oui

Non

Oui

Recherche du nom d’une broche du bus

dans le fichier des bus.

Lecture de la fonction.

BDROP ?

Tout d’abord, pour un bus, on cherche le nom d’une broche appartenant au bus. De façon à savoir si les broches du bus sont des entrées ou des sorties.

Recherche, dans les fichiers des broches, le

type de la broche.

ENTREE ?

Ecriture de la fonction SEICA équivalente.

(OM, ZG)

Recherche de l’état précédent dans les fichiers des tests.

Ecriture de la nouvelle fonction.(IH, IL)

Retour à la fonction de traduction des instructions.

Il faut que l’information ait été écrite dans le fichier du SI635. Sinon on considère la broche comme étant une entrée.

Dans le fichier des tests, toutes les actions effectuées précédemment sont notées.

Une fois que l’on connaît l’état précédent, on inverse la valeur de la broche ou du bus (bit à bit).


selon les fonctions utilisées, on traduit la boucle normalement ou on éclate la boucle pour insérer les fonctions comprises dans les registres.

Une fois que l’on sait que la boucle utilise les registres, on la décompose. Tout d’abord on récupère le nombre d’itération que la boucle devait effectuér, puis on traduit ce qu’aurait été chaque itération de la boucle. Il y a trois fonctions qui utilisent les registres : « XEQ », « INC », « DEC ». La fonction « XEQ » est remplacée par la fonction du registre désignée par le pointeur associé au registre. Les fonctions « INC » et « DEC » incrémente et décrémente respectivement le pointeur du registre cible. Donc pour chaque itération de la boucle, on écrit la fonction pointée dans le registre désigné par la fonction XEQ et on traite les incrémentations et décrémentations du registre.

A l’aide de cette fonction on écrit ce qui se passe réellement lorsque le testeur Schlumberger traite la boucle. Cela alourdit le programme de test mais est totalement équivalent.

Les fonctions DROP et BDROP

Le testeur SI635 possède deux fonctions permettant de masquer la valeur d’une broche, une suite de broches ou un bus en entrée ou en sortie. Ces fonctions existent à moitié sur le testeur Seica car on peut masquer la valeur d’une broche ou d’un bus en sortie seulement. Nous avons donc dû chercher un moyen de masquer la valeur d’une entrée. Pour cela nous avons décidé d’inverser l’état de la broche ou le bus par rapport à son état précédent.

Par exemple, pour tester l’état mémoire d’une bascule D, il faut mettre l’entrée à l’état haut puis effectuer un front d’horloge, à ce moment là, la valeur de l’entrée n’est plus importante mais pour savoir si l’état mémoire fonctionne, il faut que l’entrée soit différente de l’état haut. Le SI635 masque, alors, l’entrée tandis que nous avons choisi de la mettre à l’état bas. L’organigramme ci- dessous explique le déroulement de la fonction qui nous permet de connaître la valeur de l’état précédent et de l’inverser.



L’affectation des canaux

Lorsque l’on traduit un fichier de test, on donne à chaque broche un nom que l’on associe à un des canaux du testeur Seica. Lors de la traduction, on donne à chaque broche le numéro de canal correspondant à son numéro de broche : par exemple broche 1 = canal 1. De plus on utilise l’alimentation PW1 bien que cette ligne soit mise en commentaire pour éviter toute erreur de manipulation.Lors du test, les canaux sont souvent différents de ceux écrits lors de la traduction. Par conséquent , nous avons décidé de créer un logiciel permettant d’assigner des valeurs de canaux à chaque broche. Ce logiciel permet de ne pas avoir à modifier dans les fichiers « .PAT » et « .SRG » toutes les valeurs des canaux car le logiciel effectue cette opération automatiquement. Il suffit de lui donner la valeur des canaux associés aux broches.De même, il faut lui donner la valeur de l’alimentation utilisée pour qu’il modifie la valeur et enlève les commentaires de cette ligne.Ce logiciel fonctionne selon le diagramme suivant :


Ouverture de fichiers .PAT

et .SRG

Lecture du nombre de pattes

du composant.

Récupération de la valeur des

canaux.

Création de deux fichiers

temporaires un pour le .PAT et un

pour le .SRG.Lecture des

fichiers sources.

Remplacement des canaux dans les déclarations

du fichier .PAT et dans les

différentes fonctions du fichier .SRG.

Copie des fichiers temporaires dans

les fichiers originaux et

suppression des fichiers

temporaires.


3.5) La recette

Après cette remise à niveau, nous avons effectué un test sur un composant pris au hasard dans la bibliothèque du testeur Schlumberger et nous l’avons traduit et testé sur le banc de test SEICA.Lors de ce test, il n’y a eu aucun problème, le traducteur a été validé par mes maîtres de stage, ce qui m’a permis de lancer la traduction des nombreux modèles de test existant.Lors de ce test, le traduteur ne traduisait qu’un fichier à la fois ce qui était long d’utilisation, nous avons alors décidé de modifier le traducteur de façon à ce qu’il traite un nombre important de fichiers sans intervention de l’utilisateur.Pour cela, nous avons créé, sans modifier l’algorythme du traducteur, l’interface graphique suivante.



4) Les interfaces utilisateurs

4.1) Le traducteur

Cette interface permet de traduire un nombre important de fichiers de test, ce qui est très intéressant puisque j’ai traduit près de 800 modèles de composants.

4.2) L’affectation des canaux

De plus, j’ai écrit un manuel expliquant comment utiliser ces deux interfaces (voir annexe 1 page VII et VIII).



CONCLUSION

Au cours de ce stage, mon projet consistait à réaliser un traducteur de modèle de tests de composants. J’ai réalisé ce traducteur ainsi que la traduction des modèles de tests du testeur Schlumberger SI635 vers la gamme des testeurs SEICA .

La difficulté dans la réalisation de ce traducteur résidait dans le fait que certaines des fonctions du SI635 n’existent pas sur le testeur SEICA . J’ai donc dû les recréer en C ou dans le langage de test SEICA. Comme certaines fonctions n’existent pas sur le testeur SEICA et qu’il nous est impossible de les écrire sous une autre forme, il a été impossible de traduire certains tests.

Lors de ce stage, j’ai énormément appris. Tout d’abord j’ai découvert le monde du test que j’ignorais. J’ai appris ce qu’est un testeur, comment il fonctionne, à quoi il sert et quel est l’intérêt d’un test. De plus, le fait de ne pas connaître cet univers, m’a obligé à m’investir pour utiliser ces machines et comprendre leur logique de programmation.

Ce stage, très orienté programmation en C, m’a permis de mettre en oeuvre mes connaissances en programmation et de les améliorer.

J’ai aussi découvert le monde du travail dans une entreprise d’une quinzaine de personnes. Pour conclure, je dirai que ce stage a été très enrichissant et très intéressant.


rapport de stage

Documents

test et

testeur et

carte et

pat et

test dont

test fonctionnel

seica p11

seica thomas fayoux