INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Exemple 3 : (5R)-5-éthyl-8-fluoro-5-hydroxy-4,5,13,15-tétrahydro- 1H,3H-oxépino[3',4':6,7]indolizino[1,2-b]quinoléine-3,15-dione Ce composé est obtenu en appliquant à l'acide 2-amino-3-Iluorobenzofque (préparé selon Muchowski, et coll., J. Org. Chem., vol. 45, p. 4798) les étapes le à lh du mode opératoire de l'exemple 1 ci-dessus. On obtient un solide (Pf > 250 C).
IR (KBr) : 1659,1731, 3344 cm-1.
RMN 1H (DMSO-d6, 8) : 0,88 (t, 3H) ; 1,85 (q, 2H) ; 3,07 (d, 1H) ; 3,47 (d, 1H) ; 5,29 (s, 2H) ; 5,40 (d, IH) ; 5,53 (d, IH) ; 6,06 (s, IH) ; 7,44 (s, IH) ; 7,69 (m, 2H) ; (m, IH) ; 8,75 (s, IH).
Exemple 4 : (5R)-12-benzyl-5-éthyl-5-hydroxy-4,5,13,15-tétrahydro- 1 H,3H-oxépi no[3',4': 6,7] i ndolizi no[ 1,2-b ] quinol éi ne- 3,15-di one Etape 4a : 1-(2-aminophényl)-2-phényl-1-éthanone.
Une solution de 2-aminobenzonitrile (4,25 g, 36 mmol) dans l'éther diéthylique anhydre (40 ml) à 0 C est traitée sous argon par du chlorure de benzylmagnésium (2M dans le tétrahydrofurane ; 50 ml ; mmol). Le milieu réactionnel est maintenu sous agitation pendant lh à température ambiante, puis hydrolysé à 0 C par l'ajout d'acide chlorhydrique à 10%, agité pendant 1 h, et neutralisé avec de la soude. Le mélange résultant est extrait à l'acétate d'éthyle. Les extraits combinés sont lavés à l'eau et avec une solution aqueuse saturée en chlorure de sodium, puis séchés sur sulfate de magnésium et concentrés pour donner 3,5 g du produit désiré, sous la forme d'un solide blanc (Pf: 100-101 C).
IR (KBr) : 1469,1612, 1725 cm-1 RMN 1H (DMSO-d6, 8) : 4,25 (s, 2H) ; 6,53 (t, IH) ; 6,74 (d, IH); 7,2-7,35 (m, 8H) ; 7,90 (d, IH).
Etape 4b : 4-benzyl-2-oxo-1,2-dihydro-3-quinoléinecarboxylate d'éthyle.
II. Une deuxième entité est appelée dispositif pilote dudit dispositif témoin.
Elle peut être contenue notamment dans ledit objet nomade.
III. Une troisième entité, appelée dispositif contrôleur, est contenue dans ledit dispositif de contrôle.
Le dispositif de contrôle comporte :
- des moyens de connexion pour connecter électriquement, électromagnétiquement, optiquement ou de manière acoustique ledit dispositif contrôleur audit dispositif témoin et/ou audit dispositif pilote, - des moyens de transmission pour transmettre les données produites par ledit dispositif contrôleur vers ledit dispositif témoin et/ou ledit dispositif pilote, - des moyens de réception pour recevoir les données provenant dudit dispositif témoin et/ou dudit dispositif pilote.
Le dispositif contrôleur comporte : - des premiers moyens de calcul pour produire un ou plusieurs défis d telque0 R' = GA d. D"x mod n ou du type : R'1.GA<1=EDï:iinodn - des troisièmes moyens de calcul pour vérifier que les triplets {R', d, D} sont cohérents.
Cas où l'exposant de vérification v est unique De même que précédemment, ledit dispositif de contrôle se présente sous la forme d'un terminal ou d'un serveur distant connecté à un réseau de communication informatique. Il met en #uvre : - un module public n tel que n soit le produit de facteurs premiers secrets p,, p2, ... (p,, ...) (i étant supérieur ou égal à 2) n = pl.pZ. p3.... , - des clés publiques GA, GB,...
- un exposant public de vérification v Les clés privées GA et les clés publiques associées QA sont liées par des
relations du type : GA.QA" mod n = 1 ou GA QA'mod n ledit dispositif de contrôle fait intervenir trois entités : I. Une première entité, appelée dispositif témoin, est contenue notamment dans un objet nomade se présentant par exemple sous la forme d'une carte bancaire à microprocesseur. Le dispositif témoin produit des engagements R et des réponses D à des défis d.
II. Une deuxième entité est appelée dispositif pilote dudit dispositif témoin Elle peut être contenue notamment dans ledit objet nomade.
Le dispositif de contrôle comporte : - des moyens de connexion pour connecter électriquement, électromagnétiquement, optiquement ou de manière acoustique ledit dispositif contrôleur audit dispositif témoin et/ou audit dispositif pilote, - des moyens de transmission pour transmettre les données produites par ledit dispositif contrôleur vers ledit dispositif témoin et/ou ledit dispositif pilote, - des moyens de réception pour recevoir les données provenant dudit dispositif témoin et/ou dudit dispositif pilote, Le dispositif contrôleur comporte : - des premiers moyens de calcul pour produire un ou plusieurs défis d {dA, dB, ...}tels que 0 # dA # v -1, - des deuxièmes moyens de calcul pour calculer, en fonction des réponses D reçues du dudit dispositif témoin et/ou dudit dispositif pilote, des engagements R' en effectuant des opérations du type : R'=- GA dA. GB dR .... D" mod n ou du type : R'. GA dA. GBdb. ... # Dv mod n
- des troisièmes moyens de calcul pour vérifier que les triplets {R', d, D} sont cohérents.
Dans le cas de cette variante de réalisation, la session est destinée à vérifier l'authenticité d'une entité. Dans le cas d'une authentification d'entité, le dispositif pilote est appelé dispositif démonstrateur.
Pour prouver l'authenticité d'une entité ledit dispositif de contrôle exécute les étapes suivantes : # étape 1. engagement R du dispositif témoin : Le dispositif témoin produit au moins un engagement R à partir d'au moins une collection d'aléas {r1, r2, r3, ...}, telle que, pour chaque facteur premier p,, chaque collection comporte un aléa r@ entier positif et plus petit que p, .
Selon un premier type, la panne provoque une erreur mineure qui reste localisée au niveau d'un composant et est directement corrigée par le logiciel
gérant ce composant et l'utilisateur ne ressent alors aucune perturbation dans son travail.
Selon un deuxième type, la panne peut provoquer une erreur dont la gravité ne permet plus de garantir l'intégrité des données traitées et peut obliger à redémarrer la machine La présente invention s'intéresse plus particulièrement mais non exclusivement à ce deuxième type de panne qui peut provoquer des arrêts de fonctionnement de la machine, connus également et respectivement sous les terminologies anglo-saxonnes de "machine check" et de "checkstop".
Dans le cas d'un arrêt de type "machine check", les informations collectées sont ciblées sur le composant ayant détecté l'erreur tandis que, dans le cas d'un arrêt de type "checkstop", toutes les "signatures" des registres d'état de la machine sont collectées.
Dans les deux cas, il faut ensuite interpréter les valeurs des registres d'état pour déterminer l'erreur et éventuellement en déduire la cause.
Chaque composant de la machine est en relation plus ou moins étroite avec un ou plusieurs autres composants de cette machine que nous appellerons "composants voisins" Si un composant comporte un défaut, il est relevé par les composants voisins dans leurs registres d'état. L'utilisateur est donc prévenu qu'il y a eu un défaut sur la machine, mais dans certains cas, rien ne lui permet de savoir avec précision quel est le composant défectueux à l'origine de l'erreur.
On a bien la signature des registres d'état de la machine en cas d'erreur, mais pas une vue d'ensemble de l'état de la machine. Il y a un trou dans l'information. On connaît des informations précises mais partielles (les registres d'état), et une information globale mais imprécise (il y a une erreur de fonctionnement). Quand l'erreur se solde par un arrêt brutal de la machine, il faut se plonger dans une documentation épaisse pour en extraire la signification des registres d'état. Cela nécessite le concours d'un expert pour faire une analyse globale a posteriori de ces registres.
Les outils d'analyse d'erreurs existants peuvent fournir l'ensemble des valeurs des registres sous forme de texte et peuvent même faire l'analyse de ces valeurs. Cependant la description des registres d'état et les règles d'interprétation de leur contenu sont noyées dans le code machine de ces outils Comme un outil est généralement dédié à une version de matériel, Il n'est pas possible d'ajouter de nouvelles descriptions de registres ou de nouvelles règles d'interprétation sans refaire une nouvelle version de l'outil.
Le but de l'invention est de pallier notamment ces inconvénients.
A cet effet, l'invention a pour objet un procédé d'analyse et de localisation de pannes matérielles dans une machine informatique stockant des informations d'erreurs de fonctionnement générées par les différents composants matériels sensibles de la machine Il est caractérisé en ce qu'il consiste à créer une interface homme/machine par l'intermédiaire de laquelle les composants et les règles d'interprétation des erreurs sont décrits dans un langage structuré et exploités par la machine comme des paramètres externes en corrélation avec les informations d'erreurs pour détecter le ou les composants défaillants.
L'invention a également pour objet un outil d'analyse et de localisation de pannes matérielles dans une machine informatique comportant des moyens de stockage des informations d'erreurs générées par les composants sensibles de la machine.
Il est caractérisé en ce qu'il comporte un moteur d'analyse d'erreurs recevant sur une première série d'entrées les informations d'erreurs, et recevant sur une deuxième série d'entrées les paramètres nécessaires à la description des composants sensibles de la machine et à la description des règles d'interprétation des erreurs, et en ce qu'il comporte une interface homme/machine entre l'outil et l'expert en composants pour lui permettre de formuler les paramètres dans un langage structuré.
Enfin, l'invention a pour objet une machine incorporant l'outil défini ci-dessus.
La formulation des paramètres de description des registres et des règles d'interprétation des erreurs selon l'invention permet d'ajouter de nouvelles descriptions ou d'enrichir l'interprétation par simple édition de fichiers sources écrits dans un format déterminé, sans avoir à refaire une nouvelle version de l'outil à chaque évolution du matériel.
De plus, l'architecture de l'outil selon l'invention est évolutive et sa maintenance est facilitée en séparant bien l'outil d'analyse proprement dit (le moteur) traitant les informations en code "machine", de la description des registres d'état et des règles d'interprétation écrites en code "source".
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit et de la figure annexée qui représente l'architecture générale d'un outil d'analyse selon l'invention.
Ils se contentent généralement de consulter quelques parties de certains registres. Par contre, Ils doivent décrire précisément l'état d'un ensemble de registres de la machine en fonction des erreurs qui peuvent survenir, et doivent préciser l'origine de chaque erreur en fonction de l'état des registres.
Ces descriptions sont exprimées selon une syntaxe déterminée qui constitue un langage de description structuré, exploitable par le module d'analyse 3 du moteur ANACHECK 1.
L'ensemble des fichiers de paramètres 8 à 11 définissent un fichier électronique F, délimité sur la figure par une ligne fermée discontinue et peut être supporté, par exemple, par un support amovible non représenté Cette caractéristique est intéressante, car elle permet d'utiliser le même fichier électronique de description F pour l'analyse d'une autre machine de même type L'outil selon l'invention introduit donc une interface utilisateur, ou interface homme/machine I, permettant à un expert d'accéder de l'extérieur de la machine, aux composants sensibles de la machine. Cette interface est matérialisée sur la figure par un segment de droite en trait interrompu entre le module d'analyse 3 et le fichier F.
Les principaux fichiers sont exploités dans l'ordre suivant : 1 le fichier COMPOSANTS 10 est utilisé pour stocker en mémoire les valeurs de tous les registres des composants sensibles de la machine ; 2. le fichier REGISTRES 11 est utilisé pour afficher la signification de tous les bits de statut identifiés par les informations d'erreurs ; et 3. le fichier REGLES 9 est utilisé pour déterminer le composant matériel à l'origine de la panne à partir des règles d'interprétation des erreurs.
La syntaxe utilisée pour ces trois principaux fichiers de paramètres met en #uvre les expressions suivantes : concernant les masques : [n] est le masque égal à 2An ; [ni , n2, ... est le masque égal à 2^n1 # 2^n2 et [nl-n2] est le masque égal à 2^n1 #2^(n1+1) .. #2^n2.
Par exemple, le masque [0-2,10] correspond au mot 11100000 00100...0 , de 64 bits de long Concernant les registres :
: désigne un registre d'un composant. Il est utilisé dans le fichier REGISTRES 11. Par exemple : SMC2 : GSR ; * : désigne les occurrences multiples d'un registre. Par exemple : CPU*4:SRR1 ;$ [mask] est utilisé dans la définition des registres pour désigner le registre courant dans le fichier REGISTRES 11. Cette notation est utilisée uniquement avec un masque. Par exemple $ [0-7]correspond aux 8 premiers bits du registre courant , : [mask] désigne la valeur suivante'valeur du registre et valeur du masque.
Par exemple : SMC2 : GSR = OxcOOOOO donne SMC2:GSR[1] = 0x800000.
Les paramètres sont des expressions manipulant les valeurs des registres, des masques, des constantes et des index d'occurrences.
Ces expressions manipulent les opérateurs suivants : # correspond à un OU binaire ; & correspond à un ET binaire ; ( ) correspond à des parenthèses respectivement ouvrante et fermante ; correspond à un décalage binaire vers la droite ; correspond à un décalage binaire vers la gauche ; et * désigne l'index d'occurrence.
Par exemple : (SMC2:M~ADDR[4] 59) # (SMC2:M~ADDR[0-2] 60) Le type "paramètre" est "unsigned long long" . Il représente un type de données qui est un entier non signé codé sur 64 bits. Il doit être utilisé avec les paramètres %11x dans les chaînes de caractères Par exemple, l'expression suivante : "memO bank#%llx", (SMC2:M~ADDR[4] 59) # (SMC2:M~ADDR[0-2] 60) permet d'imprimer le message avec le numéro du banc mémoire correspondant. Un banc mémoire se présente sous la forme de barrettes mémoires qui doivent être installées ensemble pour que la machine fonctionne.
Ces bancs mémoires sont aisément repérables par les techniciens qui effectuent la maintenance Les opérateurs de condition sont des expressions booléennes implicitement comparée à zéro Le résultat est "vrai" si l'expression est différente de zéro et faux autrement.
Les opérateurs de condition admis sont les suivants .
# # correspond à un OU logique ; && correspond à un ET logique ; == correspond à une égalité ; ! correspond à un NON logique ; et ( ) correspond à des parenthèses respectivement ouvrante et fermante.
L'utilisation de registres masqués, de constantes et de masques est autorisée A titre d'exemple dans un fichier REGISTRES 11, une condition peut être : ! (($[0-31] == 0) 1 ($[0-31] == [0-31])) Cela signifie que les 32 premiers bits du registre courant devraient avoir une valeur différente de 0 ou OxFFFFFFFF.
A titre d'exemple dans le fichier REGLES 9, une condition peut être : ((DCBK*:GSR[2,10]) ## ( ( ! SMC2 : GSR [ 1 && (DCBK*:GSR[1,9])) Cela signifie que si le deuxième ou le dixième bit du registre GSR de l'occurrence courante du DCBK est présent, ou si les premier ou neuvième bits du registre sont présents et pas le premier bit du registre GSR du composant SMC2 alors la condition est vraie (et le composant correspondant DCBANK serait en défaut).
On a procédé à des mesures viscosimétriques au cours du temps à l'aide d'un viscosimètre rotatif (modèle RHEOMAT RM 180, société METTLER). Toutes les mesures ont été effectuées à 25 C, à l'aide du mobile n 3, après 30 secondes de cisaillement à une vitesse de 50 s-1.
Avant chaque mesure, la composition AC ou BC a été homogénéisée par une agitation faible d'une durée de 1 minute.
La perte de viscosité a été calculée selon la formule suivante : perte (%) = ((#5- #t) /#5) x 100 où 115 est la viscosité mesurée 5 minutes après mélange des compositions A et B avec la composition C, et #t est la viscosité mesurée au bout d'un temps t (en minutes) suivant le mélange des compositions A et B avec la composition C.
Les résultats obtenus ont été les suivants :
t (min) composition AC (art antérieur) composition BC (invention) viscosité (Pa. s) perte (%) viscosité (Pa. s) perte (%) 5 11,54 15,85 10 6,64 42 10,45 34 20 3,99 65 9,95 37 30 3,32 71 10,32 35
Pour la composition AC correspondant à l'état de la technique, on a constaté une perte de viscosité croissante au cours du temps qui a atteint 70 % au bout de seulement 25 minutes.
Pour la composition BC selon la présente invention, la viscosité diminue d'environ 35 % au bout de 10 minutes mais reste ensuite constante au cours du temps.
Procédé et outil d'analyse et de localisation de pannes matérielles dans une machine informatique La présente invention se situe dans le domaine de la résolution des pannes matérielles et de la maintenance des machines informatiques.
Elle concerne plus particulièrement un procédé d'analyse des informations ayant été enregistrées au moment où un dysfonctionnement a été détecté dans la machine pour localiser le ou les composants à l'origine de la panne et ne remplacer uniquement que le ou les composants défaillants.
Elle concerne également un outil d'analyse et de localisation de pannes et une machine l'incorporant.
La baisse constante des coûts des machines informatiques conduit parfois les constructeurs à baisser la qualité de certains composants matériels.
Un composant peut être par exemple un ASIC, abréviations anglo-saxonnes pour "Application Specific Integrated Circuit" (circuit intégré spécifique) ou un processeur.
L'utilisateur se trouve donc de plus en plus fréquemment confronté à des problèmes liés à des erreurs dues au matériel. Toutes les machines sont plus ou moins capables aujourd'hui de relever ces erreurs qui quelquefois peuvent conduire à des pannes sur certaines parties de la machine, voire à un arrêt complet de la machine Chaque composant sensible d'une machine possède des registres d'état indiquant le niveau de fonctionnement du composant en question.
Un état déterminé de la machine est caractérisé par une "signature" de ses registres d'état, c'est-à-dire une valeur caractéristique de chaque registre pour cet état déterminé.
Ce sont ces valeurs qui constituent les informations qui seront ensuite analysées par la machine.
On distingue plusieurs types de pannes dans une machine informatique.
Le fichier COMPOSANTS 10 contient la description de l'ensemble des accès aux registres des composants matériels de la machine dont les registres sont copiés dans les fichiers d'erreurs.
Cette description permet d'accéder aux registres pour les analyser.
Une syntaxe pour le fichier COMPOSANTS 10 débute par : // System : Release : version> suivi de : // comment
COMP> component~name[* occurences]: signature { register~namel: offset~in~octets, width~in~bits; register~name2: offset~in~octets, width~in~bits; } dans laquelle : component~name correspond au nom du composant décrit ; occurrences correspond à un champ optionnel utilisé pour mettre en facteur plusieurs composants (DCBK(*2), CPUs(*4)...) dans une seule définition ; signature correspond à la signature du composant; register~name correspond au nom du registre défini ; offset~in~octets correspond au décalage, exprimé en octets, à partir du début des données des registres copiées dans le fichier pour ce composant. Ce décalage correspond, par exemple, à un décalage dans la structure du processeur de service de l'ASIC correspondant. width~in~bits correspond à la longueur du registre exprimé en bits (1-64).
Il est inutile de décrire les registres de tous les composants, mais tous les registres utilisés doivent être décrits. En effet, il y a beaucoup de registres qui sont copiés dans les fichiers d'erreur mais seulement quelques-uns d'entre eux sont utilisés pour l'analyse.
On donne ci-après un exemple de fichier de description de plusieurs composants ARB, SMC2, DCBK, DPCI et CPU620 mettant en #uvre la syntaxe définie précédemment : COMP> ARB:2 { CHIP~ID:0,8; GSR :1,8; PROCERR :2,14; } Le composant considéré ci-dessus est un ASIC dénommé ARB (Arbitre du bus système).
ARB: 2 signifie que le code de l'enregistrement dans les fichiers d'erreur est 2.
CHIP~ID correspond au nom d'un registre de l'ARB.
CHIP ID ::0,8; signifie que l'emplacement du registre CHIP~ID dans l'enregistrement de l'erreur concernant ARB est situé à 0 octet (donc au début du registre) et que le registre à une longueur de 8 bits La même description est ensuite faite pour les autres registres du composant et pour les autres composants.
COMP> SMC2:3 CHIP~ID : 0,8; GSR :4,24; S~ADDR:8,39; M~ADDR : 16, 39; } COMP> DCBK*2:4 // INDEXED COMPONENT { CHIP~ID : 0,8; GSR :2,16; S~SYND:4,16; M~SYND:6,16; } COMP> DPCI:5 { CHIP~ID : 0,8; DPCI~ERR : 1,8; PCI~A~ERR:4,64; PCI~B~ERR:12,64; MERR~AD:20,64; EXT~ERR :28, 64; } COMP> CPU620*4:1 HIDO :540,32; PVR : 688,32;
SRR1 :612,32; BUSCSR :544,32; COMP> ARB:2 { CHIP~ID : 0,8; GSR :1,8; PROCERR :2,14; } COMP> SMC2:3 { CHIP~ID : 0,8; GSR :4,24; S ADDR:8,39; M ADDR:16,39; } COMP> DCBK*2:4 // INDEXED COMPONENT { CHIP ID : 0,8; GSR :2,16; S~SYND:4,16; M~SYND : 6,16; } Dans l'exemple de description du composant DCBK ci-dessus, *2 signifie qu'il y a deux ASICs dans la machine.
COMP> DPCI:5 { CHIP~ID : 0,8; DPCI~ERR : 1,8; PCI~A~ERR : 4,64; PCI~B~ERR:12,64; MERR~AD:20,64; EXT~ERR:28,64; }
COMP> CPU620*4:1 { HIDO :540,32; PVR :688,32; SRR1 : :612,32; BUSCSR :544,32; Le fichier REGISTRES 11est utilisé pour décrire les bits de statut des registres de l'ASIC copiés dans les fichiers d'erreurs Cette description est utilisée par le moteur d'analyse ANACHECK 1 pour afficher les symptômes trouvés pour une erreur.
Une syntaxe pour le fichier REGISTRES 11débute par : // System : Release : version> suivi de : // comment REG>component[*occurences]:register[,component[*occurences] :register, ...] [IF> condition] { condition "status bit description"[, parameters]; dans laquelle : component correspond au nom du composant ; occurrences correspond à un champ optionnel utilisé pour mettre en facteur plusieurs composants (DCBK, CPUs...) dans une seule définition ; register correspond à un nom de registre du composant ; condition correspond à une expression booléenne indiquant si le résultat de l'opération "valeur du registre courant ET un masque binaire" est nul (faux) ou non nul (vrai) ; Par exemple, $ [ 0-2, 10correspond à une condition pour laquelle on a la valeur du registre courant ET le masque 111000000010000...0 (64 bits de
long). Si la valeur pour ce masque est différente de zéro alors, le résultat est "vrai". parameters correspond à une liste de valeurs numériques séparées par des virgules (, ). L'étoile (*) représente la valeur courante de l'index dans le cas de registres d'index.
On donne ci-après un exemple de fichier de description de plusieurs registres mettant en #uvre la syntaxe définie précédemment : REG> ARB:CHIP ID { $[0-7] " " ; REG> DCBK*2:CHIP ID { $[0-7] " " ; } REG> CPU620*4:HIDO { $ [0-31] == 0 "CPU#%llx not present or disabled", *; $ [0-31] == [0-31] "No response from CPU#%llx", *; !(($[0-31] == 0) Il ($[0-31] == [0-31] )) "CPU#%llx started", *; } REG> DPCI:PCI~A~ERR, DPCI:PCI~B~ERR IF> (DPCI:EXT~ERR[42,46]) { $[0-31] "PCI Address = Ox%8.811x", $[0-31] 32; $[57] "root cause : Error"; $[58] "root cause : Abort"; $[59] "root cause : Abort"; $ [52-55] [52,53,54] "PCI CBE: Memory Read Line"; $ [52-55] == [52,53,54,55] "PCI CBE : Write And Invalidate" ; }
Les figures 8A à 8C représentent un condensateur ferroélectrique conformément à des techniques classiques. Comme représenté sur la figure 8A, sur la surface d'un substrat en silicium de type p 51, une électrode de grille flottante 53 en polysilicium ou similaire est formée, un film d'oxyde de grille 52 étant interposé entre le substrat et l'électrode de grille flottante. Sur cette électrode de grille flottante 53, une couche ferroélectrique 54 est formée et sur cette couche ferroélectrique 54, une électrode de grille de commande 55 est formée. Cette structure par empilement est conformée de manière à former une électrode de grille. Une région de source 61 et une région de drain 62 sont formées sur les deux côtés de l'électrode de grille en dopant des impuretés de type n par l'intermédiaire d'une implantation ionique.