Stage de deuxième année Filière F1

Institut Supérieur d Informatique de Modélisation et de leurs Applications Organisation Européenne pour la Recherche Nucléaire 1211-CH GENEVA 23 SUISSE COMPLEXE UNIVERSITAIRE DES CEZEAUX BP 125 63173 AUBIERE CEDEX CERN-THESIS-2005-043 21/09/2005 Stage de deuxième année Filière F1 Développement du logiciel de contrôle du Vertex Locator Présenté par : Mohamed MENNANE Responsables CERN : Mr FERRO-LUZZI Massimiliano Mr EKLUND Lars Responsable ISIMA : Mr MESNARD Emmanuel - 0 - Date : Avril 2005/Septembre 2005 Soutenance : 21 Septembre 2005

Remerciements Mon séjour au CERN durant ces cinq mois a été l occasion pour moi de profiter d une expérience riche au niveau de la pratique en électronique et en informatique. Je tiens donc à remercier Massimiliano Ferro-Luzzi et Lars Eklund pour la confiance qu ils m ont accordée en me confiant ce travail et en se portant disponible à chaque instant pour m apporter de l aide. Je tiens également à remercier : Jan Buytaert pour le temps qu il m a consacré pour résoudre les problèmes électroniques rencontrés Clara Gaspar et Ricardo Nogueira qui se sont grandement investi dans mon travail et qui m ont été d une aide précieuse. Loic Brarda qui a répondu au moindre souci matériel. Mon professeur Emmanuel Mesnard qui a consacré une partie de son temps libre pour venir observer le travail que j ai réalisé. Enfin, je souhaite particulièrement remercier toute l équipe du VELO qui m a accueilli à bras ouverts et avec j ai pris le plus grand plaisir à travailler. - 1 -

Glossaire LHC Large Hadron Collider. Nom de l accélérateur de particule en construction au CERN. LHCb Expérience dédiée à l étude de la violation CP dans le système des mésons B et à l étude de leurs désintégrations. VELO Vertex Locator. Détecteur permettant la reconstruction des vertex de désintégration des particules au plus près du point de collision. PVSS Logiciel qui permet de se connecter à du matériel, faire l acquisition des données que ce matériel produit pour contrôler et surveiller son comportement DIM Système de communication basé sur une architecture client-serveur. VHDL Very high scale integrated circuit Hardware description Langage. Langage de description matérielle, destiné à décrire le comportement et l architecture d un module de logique matérielle que l on souhaite implanter dans un FPGA. FPGA Field Programmable Gate Array. Composant électronique programmable permettant de réaliser des fonctions logiques personnalisées. SPECS Serial Protocol for the Experiment Control System. Protocole de communication série utilisé pour les connections longues distances entre la zone irradiée et la zone non-irradiée. I 2 C Inter-Integrated Circuit. Standard développé par Philips permettant à deux circuits de se communiquer en série des informations avec seulement une ligne d horloge et une ligne de données SCL Serial Clock Line. Ligne d horloge du bus I 2 C SDA Serial Data Line. Ligne de données du bus I 2 C. Mot Un mot correspond à un octet - 2 -

LVDS Low Voltage Differential Signaling est une méthode de transmission permettant de transférer un signal sur un fil et son contraire sur un autre. Le récepteur final pourra ainsi par différence reconstituer le signal. CMOS Complementary Metal Oxide Semi-conductor. Type de composant électronique à faible consummation électrique. Beetle Composant qui traite l impulsion électrique directement issue du détecteur de silicium pour pouvoir l utiliser par la suite. TTCrq Composant conçu au CERN et qui comporte deux ASICs : le TTCrx et le QPLL. TTCrx ASIC qui réalise l interface entre le système de distribution des signaux de synchronisation et les dispositifs électroniques qui recevront ces signaux. Il décode les horloges, les signaux de reset et les signaux de synchronisation contenus dans les signaux TFC. QPLL Quartz qui permet de réduire le balayage de l horloge provenant du TTCrx. Delay25 Composant qui permet de déphaser cinq signaux. AMUX Multiplexeur de huit entrées vers une sortie. DCU Composant qui comporte un convertisseur analogique numérique de six signaux et qui permet l acquisition de l une de ces valeurs grâce notamment à un multiplexeur. TFC Timing and Fast Commands. Signaux qui arrivent en entrée du TTCrq par le biais d une fibre optique et qui contiennent les horloges, les signaux de reset et les signaux de synchronisation. SEU Single Event Upset. Basculement logique d un point mémoire induit par le passage d une particule. ASIC Application Specific Integrated Circuit. Circuit integré spécialisé. ECS Experimental Control System. Système de contrôle de l expérience LHCb. - 3 -

Table des illustrations Figure 1 : Vue du détecteur LHCb dans la caverne... 11 Figure 2 : Vue en coupe du détecteur LHCb... 12 Figure 3 : Vue éclatée d'un module... 13 Figure 4 : Disposition des détecteurs de silicium dans le VELO... 13 Figure 5 : Architecture générale du système d'acquisition et du système de contrôle... 14 Figure 6 : Processus d'une application PVSS... 15 Figure 7 : Editeur graphique de PVSS... 16 Figure 8 : Communication entre client, serveur et DNS... 18 Figure 9 : Chaîne de contrôle du VELO... 19 Figure 10 : Architecture du control board... 20 Figure 11 : Photo du control board... 21 Figure 12 : Régulateur de tension... 22 Figure 13 : Architecture de la mezzanine ECS... 22 Figure 14 : Représentation des conditions start et stop... 25 Figure 15 : Premier octet écrit sur le bus SDA... 26 Figure 16 : Lignes SDA Maitre, SDA Esclave et SDA resultante pour l'ecriture d'un octet... 26 Figure 17 : Lignes SDA Maitre, SDA Esclave et SDA resultante pour la lecture d'un octet... 26 Figure 18 : Architecture de la carte réalisée... 27 Figure 19 : Photo de la carte réalisée... 28 Figure 20 : Hybride comportant un détecteur en silicium et 16 Beetles... 28 Figure 21 : Trame d'écriture d'un des 20 premiers registres du Beetle... 29 Figure 22 : Trame d'écriture de plusieurs registres du Beetle parmi les 20 premiers... 29 Figure 23 : Trames à envoyer dans le cas du premier mode de lecture... 30 Figure 24 : Trame à envoyer dans le cas du second mode de lecture... 30 Figure 25 : Trames d'écriture et de lecture d'un registre du TTCrq... 32 Figure 26 : Trames d'écriture et de lecture d'un registre du Delay25... 33 Figure 27 : Trames générées par les fonctions PVSS... 36 Figure 28 : Structure d'un datapoint pour un composant accessible par un bus I 2 C... 36 Figure 29 : Structures de tous les datapoints modélisant le systeme de contrôle du VELO... 39 Figure 30 : Panneau de contrôle... 41 Figure 31 : Panneau de surveillance... 41 Figure 32 : Trames d'écriture et de lecture d'un registre du FPGA... 43 Figure 33 : Architecture du design pour le FPGA... 48 Figure 34 : Bloc I2CInterface... 48 Figure 35 : Bloc SlaveRead... 49 Figure 36 : Bloc SlaveWrite... 49 Figure 37 : Bloc Counter8Bits... 50 Figure 38 : Blocs CTRLReg8Bits et Register8Bits... 50 Figure 39 : Bloc StatusRegister8Bits... 51 Figure 40 : Bloc Mux15... 51 Figure 41 : Bloc ControlInterface... 52 Figure 42 : Automate du bloc ControlInterface... 53 Figure 43 : Bloc I2CSignalsConnection... 54 Figure 44 : Architecture interne du bloc I2CSignalsConnection... 55 Figure 45 : Bloc ClockSelection... 56 Figure 46 : Bloc TFCSignalsSelection... 56-4 -

Figure 47 : Logique de sélection du signal COMPCLK_25... 56 Figure 48 : Bloc TFCCounters... 57 Figure 49 : Chronogramme indiquant la disponibilite des signaux bunch_n et event_n sur le bus BCnt... 57 Figure 50 : Bloc Reset1... 58 Figure 51 : Bloc Reset2... 58 Figure 52 : Panneaux de configuration et de surveillance des registres du FPGA... 59 Tableau 1 : Registres du Beetle... 31 Tableau 2 : Registres du TTCrq... 32 Tableau 3 : Registres du Delay25... 33 Tableau 4 : Registres du DCU... 33 Tableau 5 : Les quatre horloges du système... 44 Tableau 6 : Les signaux de synchronisation requis par les différents dispositifs... 44 Tableau 7 : Registres du FPGA pour la configuration du système(accès lecture/écriture )... 46 Tableau 8 : Registres du FPGA pour la surveillance du système(accès lecture)... 47-5 -

Résumé L expérience LHCb, qui consiste à mettre en collision deux faisceaux de particules pour en observer les phénomènes résultants, est dotée d un système de contrôle fondé sur l utilisation du logiciel PVSS et d un système client-serveur. PVSS permet à l utilisateur du détecteur de gérer par le biais d une interface graphique toute l électronique. Le système client-serveur intégré à PVSS, appelé DIM, offre quant à lui la possibilité de configurer et de surveiller le détecteur à partir d un ordinateur quelconque. Toute une chaîne de contrôle a été conçue pour le Vertex Locator, détecteur le plus proche du point de collision permettant de reconstituer la trajectoire des particules issues de l impact. Deux cartes électroniques sont au cœur de la chaîne de contrôle du Vertex Locator : le control board qui permet d envoyer via I 2 C des commandes de configuration aux composants et de distribuer des signaux de synchronisation, et le temperature board qui permet de veiller sur les différentes températures au sein du système. Le travail effectué a porté sur l analyse et la conception de solutions pour l electronique rattachée au control board. Un code VHDL a donc été implémenté pour un FPGA dans le but de satisfaire les spécifications de contrôle requises par l utilisateur. Finalement, une interface graphique a été conçue pour que l utilisateur puisse avoir accès au FPGA et aux autres composants électroniques se situant dans le Vertex Locator. Mot clés : PVSS, DIM, Vertex Locator, control board, I 2 C, FPGA, interface graphique Abstract The LHCb experiment, which consists in colliding two beams of particles to observe the resulting phenomena, is equipped with a contol system based on the PVSS software package and a client-server system. PVSS gives to the detector user the opportunity to manage the front-end electronics thanks to a graphical interface. The client-server system integrated into PVSS, called DIM, allows to configure and monitor the detector from anywhere. A control line was designed for the Vertex Locator, detector closest to the collision point which reconstructs the particles tracks exiting the impact. Two electronic boards constitute the heart of the control line of the Vertex Locator: the control board which allows to send via I 2 C configuration commands to the components and to distribute timing signals, and the temperature board which allows to monitor the temperatures in the system. My work concerned the analysis and the design of the solutions for the electronics attached to the control board. A VHDL code was thus implemented for an FPGA in order to satisfy the user requirements. Finally, a graphical interface was designed to offer the user an access to the FPGA and to the other electronic components being in the Vertex Locator. Keywords : PVSS, DIM, Vertex Locator, control board, I 2 C, FPGA, graphical interface - 6 -

Table des matières REMERCIEMENTS... GLOSSAIRE... TABLE DES ILLUSTRATIONS... RESUME, ABSTRACT... TABLE DES MATIERES... INTRODUCTION...9 1 PRESENTATION DU STAGE...10 1.1 CONTEXTE GENERAL...10 1.1.1 L EXPERIENCE LHCB... 10 1.2 1.1.2 LE DETECTEUR LHCB... 10 ANALYSE DE L EXISTANT...12 1.2.1 PRESENTATION DU VERTEX LOCATOR... 12 1.2.2 LE SYSTEME DE CONTROLE DE L EXPERIENCE... 14 1.2.2.1 L INTERFACE DE CONTROLE DES COMPOSANTS ELECTRONIQUES : LE LOGICIEL PVSS...14 1.2.2.2 DIM... 17 1.2.2.3 LE BUS SPECS... 18 1.2.3 LE SYSTEME DE CONTROLE DU VERTEX LOCATOR... 18 1.2.3.1 LE CONTROL BOARD...20 1.3 1.2.3.2 LE REPEATER BOARD...21 LES OBJECTIFS DU STAGE...23 2 ETUDE DU PROBLEME ET CONCEPTION DES SOLUTIONS...24 2.1 LE PROTOCOLE I 2 C...24 2.1.1 INTRODUCTION AU BUS I 2 C... 24 2.1.2 PRINCIPE DE FONCTIONNEMENT... 24 2.1.2.1 CONDITIONS DE DEPART ET D ARRET...24 2.1.2.2 TRANSMISSION DES DONNEES SUR LE BUS... 25 2.2 BANC D ESSAI...27 2.3 CONCEPTION DU LOGICIEL ASSOCIE AU CONTROL BOARD...28 2.3.1 COMPOSANTS A CONFIGURER ET A SURVEILLER... 28 2.3.1.1 BEETLE...28 2.3.1.2 TTCRQ... 31 2.3.1.3 DELAY 25...32 2.3.1.4 DCU... 33 2.3.1.5 LES AMUX... 34 2.3.1.6 LES REGISTRES EXTERNES DE LA MEZZANINE ESCLAVE SPECS... 34 2.3.1.7 LES REGULATEURS DE TENSIONS... 34 2.3.2 DESCRIPTION DES FONCTIONS PVSS UTILISEES... 34 2.3.2.1 LES FONCTIONS INDEPENDANTES DES DATAPOINTS CREES PAR L UTILISATEUR... 34 2.3.2.2 LES FONCTIONS QUI MANIPULENT LES DATAPOINTS CREES PAR L UTILISATEUR... 36 2.3.3 MODELISATION DU SYSTEME A CONTROLER... 37 2.3.3.1 TYPES DEJA EXISTANTS...37 2.3.3.2 TYPES DE BASE... 38 2.3.3.3 TYPES DE «SECOND NIVEAU»... 39 2.3.3.4 TYPES DE «TROISIEME NIVEAU»... 39 2.3.4 INTERFACE GRAPHIQUE REALISEE... 40-7 -

2.4 CONCEPTION DU MICROPROGRAMME A IMPLANTER DANS LE FPGA DU CONTROL BOARD ET LOGICIEL ASSOCIE...42 2.4.1 LES OUTILS DE DEVELOPPEMENT... 42 2.4.1.1 VISUAL ELITE...42 2.4.1.2 SYNPLIFY... 42 2.4.1.3 ACTEL DESIGNER...42 2.4.1.4 ACTEL FLASH PRO...42 2.4.2 FONCTIONNALITES IMPLEMENTEES... 42 2.4.2.1 SPECIFICATIONS DEFINIES POUR LE FONCTIONNEMENT NORMAL DU SYSTEME...43 2.4.2.2 SPECIFICATIONS DEFINIES POUR LE DEBUGGAGE DU SYSTEME... 45 2.4.2.3 REGISTRES INTERNES...46 2.4.3 ARCHITECTURE INTERNE DU FPGA... 48 2.4.3.1 APERCU GENERAL DU DESIGN REALISE...48 2.4.3.2 FONCTIONNALITE DES COMPOSANTS CREES... 48 2.4.4 INTERFACE GRAPHIQUE PERMETTANT LA CONFIGURATION DU FPGA... 59 3 RESULTATS ET DISCUSSIONS...60 3.1 ECRITURE A PARTIR DE LA BASE DE DONNEES...60 3.2 VITESSE DE LECTURE ET D ECRITURE...60 3.3 PROBLEME DE MEMOIRE...61 3.3 PROBLEME D ATTRIBUTION DE PINS...61 CONCLUSION...62 REFERENCES... - 8 -

Introduction Le LHC (Large collisionneur de hadrons), dont la date du premier fonctionnement est prévue pour avril 2007, offrira l occasion aux scientifiques de confirmer ou non par l experience les théories actuelles portant sur la constitution de la matière. Nombreux instituts collaborent avec le CERN en vue de réaliser ce projet de grande envergure qui fait appel à une technologie de pointe, notamment dans le domaine des détecteurs en silicium. Le Vertex Locator, élement essentiel du détecteur LHCb, aura pour but d apporter aux physiciens les réponses à la question suivante : où se situent exactement le point de collision entre les particules et les vertex déplacés? Un système électronique récupèrera les données qui seront analysées par la suite par les scientifiques. Par conséquent, une configuration préalable de ce système et une surveillance de certains paramètres sera nécessaire. Une description du système dans son ensemble permettra dans un premier temps de percevoir les besoins requis pour un bon fonctionnement de l électronique. Par la suite seront explicitées plus en détail les conceptions qui répondent aux besoins de configuration et de surveillance du système électronique du Vertex Locator. Enfin, nous analyserons les résultats de ce travail pour proposer d éventuelles améliorations. - 9 -

1 Présentation du stage 1.1 Contexte général Le CERN, Organisation européenne pour la recherche nucléaire, a été fondé en 1951 et se situe dans la banlieue de Genève. Ce laboratoire de renommée international a axé sa recherche dans le domaine de la physique des particules. Le CERN emploie un peu moins de 3000 personnes, mais ce sont près de 6500 scientifiques, soit la moitié des physiciens de particules dans le monde, qui utilisent ses installations. Ils représentent 500 universités, et plus de 80 nationalités. Afin de pouvoir sonder le cœur de la matière, des accélérateurs de particules sont construits. Depuis quelques années, un nouveau projet de grande ampleur a été entamé au CERN : la construction d'un nouvel accélérateur, bien plus puissant que les précédents : le LHC [1] (Large Hadron Collider). 1.1.1 L expérience LHCb LHCb [1] est l une des 4 expériences qui seront réalisées grâce à l accélérateur de particules LHC de circonférence 27km. L expérience LHCb a pour but d étudier la violation de la symétrie Charge-Parité (CP) observée pour la première fois en 1964. L origine de cette asymétrie est encore l un des mystères de la physique des particules qui étudie les grains de matière élémentaires et leurs interactions. La théorie actuelle, appelée Modèle Standard, prévoie la violation de CP dans le cas des interactions faibles agissant sur les particules, mais il n est pas exclu que d autres principes physiques participent à ce phénomène. La violation de CP joue aussi un rôle important en cosmologie car c est l une des conditions requises pour expliquer l excès de matière par rapport à l antimatière dans l univers. Le Modèle Standard ne suffisant pas à expliquer cette prédominance de matière, il est nécessaire de produire de nouvelles sources de violation de CP au delà de cette théorie. Pour cela, le système des mésons beaux (particules contenant un ou deux quarks «beaux») est très attractif. L expérience LHCb vise à produire de telles particules à partir de collisions proton-proton et à étudier leurs désintégrations. 1.1.2 Le détecteur LHCb Le détecteur LHCb se situera autour de l axe du faisceau de protons circulant dans le grand collisionneur de hadrons LHC. Sa fonction sera de détecter les particules produites lors des collisions entre protons afin de les identifier et de mesurer leur point d origine, leur direction et leur énergie impulsion. Le détecteur est enterré 100 mètres sous terre et s inscrit dans un parallélépipède de 10x10x20 mètres. Les systèmes électroniques sont, dans la mesure du possible, protéges des radiations par un mur en béton dans une partie distincte de la caverne. - 10 -

Faisceau 1 Mur de protection p Faisceau 2 20 m p VELO (Point de collision) Figure 1 - Vue du détecteur LHCb dans la caverne Un détecteur comme celui utilisé pour l expérience LHCb comporte trois grandes catégories d éléments matériels : - Les détecteurs physiques qui interagissent directement avec les particules. - Le système d acquisition des données (électronique et logiciel). - Le système de contrôle et de ressources (alimentations, refroidissement, régulation du faisceau de particules, etc ). Voici une présentation rapide des différents éléments qui composent le détecteur LHCb : - Le Vertex Locator fournit des informations sur la présence de vertex déplacés (désintégration de mésons «beaux») et permet de reconstruire la trajectoire des particules au plus près de la collision. - Le Pile Up permet d éliminer les événements contenant plusieurs interactions protons-protons. - Le Tracker permet de reconstruire les traces des particules chargées et de mesurer précisément l impulsion de chacune. - Les détecteurs RICH permettent l identification des particules par effet Tcherenkov. - Les calorimètres électromagnétiques (ECAL) et hadroniques (HCAL) ont pour but d identifier les photons, les électrons et les hadrons, puis de mesurer pour chacun d eux son énergie et sa position. - Le détecteur de muons (Muon Detector) fournit une identification des muons et une mesure de leur impulsion. - 11 -

Figure 2 - Vue en coupe du détecteur LHCb 1.2 Analyse de l existant 1.2.1 Présentation du Vertex Locator Le Vertex Locator [2] est la partie du détecteur LHCb la plus proche du point d interaction des deux faisceaux. Il doit fournir des mesures précises des traces des particules dans la région de la collision. Le VELO comprend 21 stations disposées toutes perpendiculairement au faisceau et parallèles entre elles. Une station est composée de deux entités appelées modules. Un module comprend : Deux détecteurs en silicium en forme de demi-cercle qui vont permettre de déterminer les trajectoires des particules. Ces détecteurs possèdent des bandes qui sont circulaires pour l un des détecteurs et radiales pour l autre. Grâce à des jonctions PN, le passage d une particule à travers un détecteur va générer une impulsion de courant sur les bandes. Les trajectoires sont alors mesurées dans un système de coordonnées polaires. L un des deux détecteurs mesure le rayon R tandis que l autre mesure l angle Phi. L axe du faisceau représentant la coordonnée Z, alors le point de passage de la particule est défini par une coordonnée cylindrique. Deux entités appelées hybrides et disposées l une face à l autre. Un hybride réalise le support de puces appelées Beetles qui effectuent l acquisition des données provenant des détecteurs. En effet, le signal provenant des bandes n est pas utilisable directement. Le Beetle prend donc en entrée ce signal analogique qui va passer à travers deux intégrateurs puis un pipeline. Un support rigide - 12 -

Un circuit de refroidissement Figure 3 - Vue éclatée d'un module Axe du faisceau Figure 4 - Disposition des détecteurs de silicium dans le VELO - 13 -

Les modules sont en capacité de s écarter lorsque le faisceau est chargé puis de se rapprocher lorsque des mesures veulent être effectuées. Le VELO représente donc au total 84 hybrides comportant 16 Beetles chacun. Le Pile Up utilise lui aussi deux stations. A la différence des modules du VELO, les modules du Pile Up ne mesurent que la coordonnée R. Les modules du Pile Up étant très similaires à ceux du VELO, on considerera par la suite les stations du Pile Up comme faisant parties intégrantes du VELO. 1.2.2 Le système de contrôle de l expérience Le système de contrôle [3] de l expérience LHCb est en charge de la configuration, du contrôle et de la surveillance de tous les composants du détecteur. Comme défini sur le schéma suivant, le contrôle est effectué sur toute la chaîne d acquisition des données, de la mesure des valeurs jusqu à leur stockage. Figure 5 - Architecture générale du système d'acquisition et du système de contrôle 1.2.2.1 L interface de contrôle des composants électroniques : le logiciel PVSS PVSS est un logiciel utilisé pour faire l acquisition de données sur du matériel électronique afin de superviser un système ou même le configurer. - 14 -

Architecture d une application PVSS Une application PVSS se compose de plusieurs processus appelés aussi Managers. Voici cidessous une représentation de ces différents processus au sein d une application PVSS. Figure 6 - Processus d'une application PVSS L Event Manager (EVM) s occupe de toutes les communications. Il reçoit des données des drivers et les stocke dans la base de données (DB). Il reçoit aussi les données de l interface utilisateur qu il stocke dans la base. Le Data Base Manager (DBM) réalise l interface pour la base de données. L User Interface Manager (UIM) permet de lire des données dans la base de données, ou même d envoyer les données destinées au matériel dans cette base de données. Elle permet aussi de rester continuellement connecté à la base de données. Les Control Managers (Ctrl) servent à faire tourner des processus en arrière-plan grâce à l utilisation de scripts. Les API Managers (API) permettent aux utilisateurs d écrire leurs propres programmes en C++ pour accéder à des données dans la base. Les Drivers (D) fournissent l interface au matériel à contrôler. Une application PVSS comporte au moins un Event Manager et un Data Base Manager. Elle peut posséder autant de drivers et d interfaces utilisateur que nécessaire. Fonctionnement d une application PVSS Prenons l exemple d un utilisateur souhaitant écrire dans un registre particulier. Cette opération s effectue en réalité en deux temps. Tout d abord, l utilisateur, par l intermédiaire de l interface graphique, inscrit la donnée dans la base. Le trajet suivi par la donnée est le suivant :UIM EVM DBM DB. Ce n est alors que par la suite que la donnée est envoyée de la base vers les drivers si l utilisateur envoit une commande d écriture ou si il a été défini qu une commande d écriture est réalisée à chaque fois que le contenu du datapoint change. Le trajet suivi est alors le suivant : DB DBM EVM D - 15 -

Si un utilisateur souhaite dans le cas contraire lire dans un registre, alors la donnée réalise le chemin inverse. Structure de la base de données PVSS permet de modéliser les composants en utilisant le concept de datapoint. Ce concept est principalement basé sur la notion d objet. La modélisation s effectue en deux étapes. D abord, un datapoint type doit être défini par l utilisateur. Il décrit la structure de données associée au composant à modéliser. Par analogie aux langages orientés objet, on pourrait définir un datapoint type comme étant une classe. Un datapoint type peut contenir des entiers, des chaînes de caractères ou bien même des pointeurs sur d autres structures. Ensuite, l utilisateur peut définir autant d instances de datapoint type qu il souhaite : ce sont les datapoint element. Il représente un objet particulier et contiennent les données propres à cet objet. Ainsi, il est possible de modéliser un système sous forme d arbre de données. Une fois la structure créée, toute une gamme d options est à la portée de l utilisateur : ce dernier peut mettre en place des contraintes sur certaines valeurs, en particulier des alarmes, ou effectuer des archivages. Création des interfaces utilisateurs PVSS permet aux utilisateurs de créer leurs propres interfaces. Figure 7 - Editeur graphique de PVSS En utilisant l éditeur graphique (ci-dessus), l utilisateur dans un premier temps définit la partie statique de son panneau en dimensionnant son interface puis en déposant les boutons, les tableaux, les champs de caractères à l endroit désiré. Ensuite il fait correspondre aux boutons une action pour un événement donné. Par exemple, l utilisateur envoie une donnée - 16 -

lorsqu il clique sur un bouton. Les actions sont programmées en utilisant des scripts où le code est écrit en langage PVSS. Les scripts PVSS Les scripts PVSS permettent une communication entre l utilisateur et la base de données. La syntaxe du langage PVSS est très proche de celle du langage C. Une librairie de fonctions assez large permet de manipuler des datapoint element, des graphiques ou même encore des fichiers. Trois fonctions en terme d accès aux datapoint element sont importantes : dpget («nom du datapoint element», «variable») Cette fonction récupère la valeur du datapoint element présente dans la base de données et la place dans la variable indiquée en paramètre. dpset («nom du datapoint element», «valeur») Cette fonction écrit la valeur dans le datapoint element présent dans la base de données. dpconnect («nom de la fonction», «nom du datapoint element») dpconnect permet d appeler une fonction à chaque fois que le contenu du datapoint element passé en paramètre change. Ainsi, si par exemple on souhaite afficher le contenu d un datapoint element en continu, il suffit de passer en paramètre le nom de la fonction d affichage que l on aura défini précédemment, accompagné du datapoint. La définition complète de toutes les fonctions est disponible dans l aide en ligne. Communication entre la base de données et le matériel électronique L un des points recherché par les utilisateurs du CERN consiste à pouvoir contrôler toute sorte de composants électroniques à partir d un ordinateur distant quelconque. Ainsi, l interface entre PVSS et le matériel n est pas directe. Un protocole de communication effectue la jonction entre les deux. Le protocole utilisé au cours de ce stage se nomme DIM. Le chapitre suivant explicite un peu plus en détail son principe de fonctionnement. 1.2.2.2 DIM DIM est un protocole de communication qui a été intégré dans PVSS. Il est fondé sur le principe de client/serveur et a été développé au CERN [4]. Une notion fondamentale dans le mécanisme de DIM est le service. Le serveur fournit des services et le client fournit le mécanisme de connexion au serveur. Les services sont des structures contenant des données et correspondent à des datapoint elements. Ces correspondances sont définies par l utilisateur grâce à PVSS. Le DIM Name serveur (DNS) est une troisième entité qui voit les serveurs disponibles et qui permet d établir la connexion entre un client et un serveur lorsqu un client en fait la demande. Le client et le serveur peuvent alors échanger des données. - 17 -

Figure 8 - Communication entre client, serveur et DNS L ordre des échanges entre client, serveur et DNS est décrit par la numérotation de 1 à 6. 1.2.2.3 Le bus SPECS Le bus SPECS est un bus série qui transmet des données à 10Mbit/s pour configurer des dispositifs électroniques. Il permet de relier un maître à 32 esclaves au maximum. Il se compose dequatre lignes unidirectionnelles: une ligne de données du maître vers l esclave, une ligne de données de l esclave vers le maître, une ligne d horloge du maître vers l esclave et une ligne d horloge de l esclave vers le maître. Il a été conçu pour faire communiquer des dispositifs électroniques simplement, rapidement, et avec des moyens peu couteux. 1.2.3 Le système de contrôle du Vertex Locator Lors de la mise en route du VELO, il sera nécessaire de pouvoir initialiser le système dans une certaine configuration, puis être capable de changer cette configuration chaque fois que l utilisateur le souhaite. La partie contrôle de ce système consiste plus précisément à modifier diverses tensions dans le VELO, distribuer correctement certains signaux ou définir des modes de fonctionnement. Toutes ces opérations sont généralement réalisées en écrivant dans des registres. La surveillance quant à elle consiste à lire des valeurs de températures, de courants, de tensions soit pour s assurer que les valeurs de configuration définies précédemment sont bien celles présentes dans les registres soit alors pour assurer la sécurité du système. Deux chaînes caractérisent globalement le VELO : la chaîne d acquisition des données qui seront analysées pour l expérience et la chaîne de contrôle des composants du système,de distribution de signaux, et de surveillance des températures, des tensions et courants dans le détecteur. Le travail qui a été réalisé durant ces cinq mois de stage a porté sur la chaîne de contrôle des composants du système. - 18 -

Figure 9 - Chaîne de contrôle du VELO Ce schéma représente la chaîne de contrôle des modules du VELO. L utilisateur sera en mesure de configurer le système à partir d un ordinateur distant disposant d une interface PVSS. Il est possible cependant de directement commander l électronique à partir de l ordinateur possédant le maître SPECS. Dans ce cas là, le client SPECS, le DNS et le serveur DIM devront tourner sur cette même machine. Un mur en béton sépare la zone de radiation de la zone de contrôle. Le bus SPECS a été préféré aux autres bus comme bus de longue distance. La distance du cable est de 60 mètres. Le maître SPECS est relié à une premier carte électronique : le control board [5]. Le control board est l élément central de cette chaîne. Il comporte une carte esclave SPECS qui va transmettre des signaux I 2 C aux hybrides. Le VELO comporte exactement quatorze control boards chainés les uns aux autres. Chaque control board est relié à six repeater boards, chaque repeater board étant connecté à un hybride. Le Pile Up comporte quant à lui trois control boards. Un seul de ces control boards est connecté à quatre hybrides. - 19 -

1.2.3.1 Le control board Le control Board est au coeur du système de contrôle du Vertex Locator. Le schéma suivant décrit la structure du Control Board. error strobes V_Hybrid0_inhib0 TTC (optical) TTCRq Mezzanine counters TTC Ch. B CLK V_Hybrid0_inhib1 V_Hybrid0_inhib2 V_Hybrid0_inhib3 L0A V_Driver_inhib SPECS Bus (remote) SPECS Bus (local) TTC Ch. B control signals SPECS Slave Mezzanine SDA SCL L0 FE Reset Test Pulse L1 FE Reset L1 Event Reset CLK status/control ADC Ext. register Ext. register Ext. register SDA_OUT I 2 C direction SDA_IN SCL_OUT FPGA L0A COMPCLK CLK L0 FE Reset Test Pulse local I 2 C Delay25 L0A COMPCLK CLK Reset Test Pulse V_mon Power on Reset TFC/I2C enable Curr_lim SDA_OUT SDA_IN SCL_OUT 6x Figure 10 - Architecture du control board Le control board va communiquer avec le maître SPECS situé dans l ordinateur par l intermédiaire de la mezzanine SPECS esclave. Le control board joue deux rôles essentiels. D une part il se comporte comme un esclave SPECS par rapport à la carte SPECS maître et comme un maître I 2 C pour les composants qui se situent sur le repeater board et sur les hybrides. Les signaux V_Hybrid0_inhib0, V_Hybrid0_inhib1, V_Hybrid0_inhib2, V_Hybrid0_inhib3 permettent de commander des régulateurs de tensions [5]. Les signaux V_mon et Curr_lim permettent de lire des informations de tensions et de courants. SDA et SCL correspond au bus I 2 C qui relie le control board au repeater board et aux hybrides. Un registre qui se situe dans la mezzanine permet d envoyer un signal de reset aux Beetles situés sur les hybrides. D autre part, le control board reçoit des signaux par une fibre optique. Le TTCrq [6] va décoder ces signaux qui permettent d effectuer la synchronisation de l électronique se - 20 -

situant sur cette chaîne. Il s agit principalement d horloges, de signaux de reset et de signaux de synchronisation. Le control board se charge donc de distribuer ces signaux par l intermédiaire d un FPGA dans lequel est implémentée la logique nécessaire à cette fonctionnalité. Par ailleurs, le TTCrq, le Delay25 [7] et la mezzanine esclave possèdent des registres internes que l utilisateur souhaiterait configurer. Ces composants sont accessibles par un bus I 2 C local. (Le control board comprend sept bus I 2 C: six bus longue distance en direction des hybrides et un bus local pour la communication avec les différents composants du control board). L esclave SPECS du control board possède un DCU [8], composant qui contient un convertisseur analogique numerique. Six canaux sont en entrée du convertisseur. Ces six entrées correspondent aux six tensions V_mon provenant d un des régulateurs de chaque hybride. Une fois la conversion effectuée, un multiplexeur permet de sélectionner une tension à lire parmi les six. Figure 11 - Photo du control board 1.2.3.2 Le repeater board Le repeater board se situe dans la zone de radiation, dans une chambre à vide qui se trouve à 1m50 du point de collision. Son rôle consiste à répéter les signaux de synchronisation et les signaux I 2 C provenant du control board. Il comporte aussi tous les régulateurs de tensions qui garantissent une alimentation correcte de l électronique. Il permet par ailleurs la transmission des données provenant des détecteurs au silicium. Il comporte six cartes : quatres d entre elles sont utilisées pour l acquisition des données utiles à l expérience, les deux autres comportent des composants que l utilisateur souhaite controler via I 2 C. La mezzanine ECS et la low voltage card. - 21 -

La low voltage card Cette mezzanine comporte huit régulateurs de tension. V i V I Voltage V OU V_xxx_out V xxx in IN AD V_xxx_curr_lim OC GN V_xxx_sense V_xxx_mon Figure 12 - Régulateur de tension V_in correspond à l entrée du régulateur de tension provenant de la source d alimentation. V_xxx_inhib désactive la tension de sortie V_xxx_out. La sortie V_xxx_curr_lim passe à 1 lorsque le courant consommé dépasse une certaine limite. V_xxx_mon indique la valeur de la tension actuelle appliquée. La mezzanine ECS Figure 13 - Architecture de la mezzanine ECS - 22 -

La mezzanine ECS transforme des signaux différentiels en signaux simples. Elle comporte également deux multiplexeurs configurables via I 2 C et qui vont permettre pour l un de sélectionner une des huit valeurs de tensions provenant des régulateurs à envoyer au DCU, qui va convertir le signal analogique en signal numérique puis permettre de faire l acquisition grâce à l interface I 2 C, et pour l autre de sélectionner l un des huit indices de courant à envoyer dans un registre de l esclave SPECS pour pouvoir être lu via I 2 C. 1.3 Les objectifs du stage Dans un premier temps, mon travail a consisté à mettre en place le banc d essai pour accéder aux registres des Beetles situés sur les hybrides. La familiarisation avec la chaîne de contrôle ayant été effectuée, les points suivants ont été réalisés : Le développement d une interface graphique permettant de configurer : les Beetles se situant sur les hybrides les Delay25 et les TTCrq se situant sur les control boards les signaux TFC/I2C enable et PowerOnReset Le développement d une interface graphique permettant de surveiller : le contenu des registres des Beetles, des Delay25 et des TTCrq les valeurs provenant des régulateurs de tension Le développement d un code VHDL, répondant aux besoins des utilisateurs, pour le FPGA du control board Le développement de l interface graphique qui contrôle et lit le contenu des regitres internes du FPGA - 23 -

2 Etude du problème et conception des solutions 2.1 Le protocole I 2 C 2.1.1 Introduction au bus I 2 C (Inter-Integrated Circuit) Le bus I 2 C a été élaboré au début des années 80 par Philips semiconductors et fait partie de la grande famille des L.A.N. (Local Area Networks - réseaux locaux) avec pour cible privilégiée le marché grand public. Depuis, des millions de téléviseurs, récepteurs de radio, autoradios utilisent ce moyen de communication interne à leurs propres systèmes. Ce bus est un bus série qui permet donc la communication d une large gamme de composants électroniques. Pour ce faire, le bus I 2 C utilise seulement trois fils : Un signal de donnée (SDA) Un signal d horloge (SCL) Un référentiel (Masse) Les dispositifs qui viennent se connecter au bus se raccordent en parallèle sur les lignes SDA et SCL. La discussion sur un bus se fait entre un maître et un esclave. C est le maître qui demande et l esclave qui répond. Electroniquement, la mise en place de plusieurs composants sur un même bus est possible grâce à la structure des sorties qui sont de type "Collecteur ouvert". Des résistances de rappel permettent de garantir l état haut du bus lorsque les éléments sont en mode haute impédance. Ce protocole est défini par la succession des états que peuvent prendre les signaux SDA et SCL. Les données sont transmises à 100Kbits/s en mode standard et jusqu'à 400Kbits/s en mode rapide. Par conséquent, le protocole I 2 C, bien que relativement simple, n a d utilité que pour les applications qui ne nécessitent pas une vitesse de communication élevée. 2.1.2 Principe de fonctionnement Lorsque le bus est libre, les lignes SDA et SCL sont à l état haut. Des lors que le maître désire communiquer avec un esclave, on observe sur le bus une condition de départ de la transmission, la transmission de données proprement dite, puis une condition d arrêt de la communication. 2.1.2.1 Conditions de départ et d arrêt Condition de départ (start): Cette situation a lieu et uniquement lieu lorsque la ligne de données SDA passe de l'état haut à l'état bas tandis que la ligne d'horloge reste à l'état haut. Condition d arrêt (stop) : Cette situation a lieu et uniquement lieu lorsque la ligne de données SDA passe de l'état bas à l'état haut tandis que la ligne d'horloge SCL reste à l'état haut. - 24 -

À tout cela il faut ajouter les compléments suivants : les conditions de start et de stop sont toujours créées par le maître. le bus est dit occupé après la condition de départ. le bus sera considéré comme libre après la condition de stop. Figure 14 - Représentation des conditions start et stop 2.1.2.2 Transfert des données sur le bus Le transfert des données s opère donc entre une condition de départ et une condition d arrêt. Chaque mot transmis sur la ligne de donnée SDA doit avoir une longueur de 8 bits. Chaque mot transmis doit être suivi d'un bit d acquittement généré par le récepteur du mot. Le nombre de mots transmis lors d'un transfert est en principe illimité. Un bit est lu sur chaque front montant de l horloge SCL générée par le maître. Les données contenues dans le mot sont transférées avec le bit de poids fort en tête. Premier mot transmis : Le premier mot transmis contient l'adresse de l'esclave que le maître souhaite sélectionner. Cette adresse a une longueur de 7 bits (les 7 premiers). Lorsqu'une adresse est envoyée par le maître, tous les composants présents physiquement sur le bus comparent les sept premiers bits qui suivent la condition de départ à leur propre adresse. Si celle-ci correspond exactement à la sienne, il se considère comme adressé. Le huitième bit transmis de ce premier mot est appelé R/W bit. Il correspond au bit de lecture/écriture et sert à indiquer l opération que le maître va effectuer, à savoir : si ce bit est égal à zéro, alors le maître veut effectuer une écriture vers l esclave sélectionné si ce bit est égal à un, alors le maître veut effectuer une lecture à partir de l esclave sélectionné Remarque : Les adresses 0000XXX et 1111XXX sont réservées selon la norme I 2 C pour d autres utilisations. Neuvième bit transmis : Alors que les 8 premiers bits sont écrits par le composant maître sur le bus, le neuvième bit est réservé pour l acquittement de l esclave. En effet, l esclave adressé écrit sur la ligne SDA la valeur 0 pour montrer au maître qu il a bien reçu les données. La communication peut alors continuer normalement. Si aucun esclave n a été adressé correctement, alors ni le maître, ni les esclaves ne vont écrire sur le bus laissant ainsi la ligne SDA à l état haut (SDA est tiré à l état haut par les résistances de rappel). Le maître va alors comprendre qu il doit générer la condition stop. - 25 -

Figure 15 - Premier octet écrit sur le bus SDA Suite de la transmission : Les mots suivant l'adresse n'ont pas de signification particulière. On peut résumer globalement leurs fonctions en disant qu'ils transportent des données. Très souvent les données qui sont présentes dans les mots qui suivent immédiatement l'adresse ont un sens plus orienté vers l'organisation interne du circuit commandé (mot de sous-adresse, de statuts, de commande...), mais il n'y a pas de règles générales. Puis viennent ensuite les mots qui contiennent des données, des valeurs au sens strict. Cas de l écriture Si le maître a spécifié précédemment qu il effectuerait une écriture vers l esclave, alors il écrit ses données sur la ligne SDA 8 bits par 8 bits. Entre chaque mot transmis, le maître libère la ligne SDA libre pour que l esclave puisse faire son acquittement. Si le maître ne voit pas d acquittement, alors la communication est interrompue, sinon il continue à transmettre ses données jusqu'à ce qu il génère la condition stop. Figure 16 - Lignes SDA Maitre, SDA Esclave et SDA resultante pour l'ecriture d'un octet Cas de la lecture Si le maître a spécifié précédemment qu il effectuerait une lecture à partir de l esclave, alors ce dernier devient écrit les données demandées par le maître sur la ligne SDA 8 bits par 8 bits. De la même façon que pour l écriture, le récepteur des données (dans ce cas là le maître) envoie un signal d acquittement en écrivant un zéro sur la ligne SDA après chaque mot transmis. Pour indiquer à l émetteur des données que le récepteur souhaite ne plus recevoir de données, ce dernier laisse la ligne d acquittement à l état haut en guise d acquittement. Le récepteur n écrit un 0 sur la ligne SDA que pour indiquer à l émetteur qu il peut encore accepter des données. Figure 17 - Lignes SDA Maitre, SDA Esclave et SDA resultante pour la lecture d'un octet - 26 -

2.2 Banc d essai Les premiers tests pratiques ont consisté à lire et écrire dans les registres des Beetles d un hybride à disposition. La démarche de l installation de la partie logicielle et développée en annexes. Le banc d essai n a pas été dans un premier temps identique à la chaîne de contrôle finale, le control board et le repeater board étant en cours de fabrication. La carte SPECS esclave a été installée sur une carte jouant le rôle du contrôle board. Cependant, le repeater board n ayant pas été à disposition, une solution temporaraire a dûe être définie pour relier le bus I 2 C provenant de la carte portant l esclave SPECS au bus I 2 C de l hybride [9]. En effet, le repeater board réalise la jonction du bus I 2 C différentiel LVDS (coté esclave SPECS) au bus I 2 C classique CMOS (coté hybride). Une carte temporaire a donc été réalisée pour palier à ce problème. LVDS CMOS Drain ouvert Figure 18- Architecture de la carte réalisée L horloge scl circule uniquement du SPECS vers l hybride. Par conséquent, il suffit juste de placer un composant qui va transformer le bus différentiel provenant du SPECS en un bus simple allant vers l hybride. En revanche, deux lignes sda différentiels unidirectionnels sont présentes du côté du SPECS alors qu une ligne sda bidirectionnelle simple est présente du côté de l hybride. Il faut donc gérer en plus du problème posé par les lignes différentielles, le tri-state. Lorsqu un 0 est écrit à l entrée du drain ouvert, alors la sortie prend la valeur 0 et dans le cas inverse la sortie passe en haute impédance (non connectée). Ainsi, lorsque la carte SPECS écrit un 0 pour le Beetle, la sortie du drain ouvert passe à 0 et par conséquent la ligne bidirectionnelle SDA connectée au Beetle passe à 0. Lorsque la carte SPECS écrit un 1, la sortie du drain ouvert est déconnectée. Cependant, une résistance de rappel tire la sortie vers le haut donc un 1 sera lu par le Beetle. Lorsque le Beetle enverra des signaux sur le bus SDA, alors l entrée du drain sera à 1 (état de repos). Par conséquent, la sortie du drain ouvert sera déconnectée et donc les données envoyées par le beetle seront dirigées vers les fils sda_specs_in+ et sda_specs_in-. - 27 -

Figure 19 - Photo de la carte réalisée 2.3 Conception du logiciel associé au Control Board 2.3.1 Composants à configurer et à surveiller 2.3.1.1 Beetle Le Beetle est une puce spécialement conçue pour l expérience LHCb. Dans le Vertex Locator, il permet de faire l acquisition des signaux provenant des detecteurs de silicium. Comme indiqué sur la photo suivante, il se situe sur un hybrid. Un hybrid comporte seize Beetles. Figure 20 - Hybride comportant un détecteur en silicium et 16 Beetles Le Beetle comporte vingt trois registres permettant de le configurer [10]. Un vingt quatrième registre est disponible en lecture seule. L accès à ces registres en lecture comme en écriture se fait par l intermédiaire d une interface I 2 C. Une adresse I 2 C est attribuée à chaque Beetle. Un registre est défini par une sous-adresse allant de 0 à 23. - 28 -

Cette sous-adresse est contenue dans un pointeur. Les registres 0 à 19 et le registre 24 sont de taille huit bits. Le registre 20 est de taille mille vingt quatre bits. Les registres 21 et 22 font cent vingt huit bits. Ecriture Les vingt premiers registres sont à la fois accessibles indépendamment ou en même temps. L écriture d un seul registre consiste à envoyer sur le bus de données l adresse du Beetle suivie de la sous adresse correspondant au registre puis la donnée de huit bits à écrire. Bit écrit par la carte SPECS Bit écrit par le beetle Figure 21 - Trame d'écriture d'un des 20 premiers registres du Beetle Cependant, le Beetle offre la possibilité d écrire dans plusieurs registres consécutifs (uniquement parmi les vingt premiers) à l aide d une seule trame grâce à un système de pointeur qui s incrémente automatiquement après l accès à un registre en écriture. Il suffit d envoyer l adresse du Beetle suivie de la sous adresse correspondant au premier registre à écrire puis la série de données de huit bits (la première donnée est écrite dans le registre indiquée dans la trame, la deuxième donnée est écrite dans le registre suivant, ). Ce système permet donc d optimiser la vitesse de transmission des données en évitant de renvoyer l adresse du Beetle et la sous-adresse pour chaque registre. Bit écrit par la carte SPECS Bit écrit par le beetle Figure 22 - Trame d'écriture de plusieurs registres du Beetle parmi les 20 premiers Les registres 20, 21 et 22 se comportent comme des registres à décalage. En envoyant une commande d écriture de huit bits dans l un de ces registres, le contenu du registre est décalé de huit bits en direction des poids faibles et les huits bits écrits correspondent au huits bits de poids les plus fort dans le registre. Il est possible d écrire un registre complet à l aide d une seule trame en envoyant l adresse du Beetle suivie de la sous-adresse correspondant au registre, puis les bits de poids les plus faibles, puis les huit bits de poids juste supérieurs au précédents et ainsi de suite. Lecture Les registres 20, 21 et 22 ne sont accessibles en lecture que sur les huit bits de poids les plus faibles. Toutes les valeurs lues de chaque registre sont donc de taille huit bits. Deux modes existent pour la lecture des registres du Beetle. - 29 -

1 er mode de lecture : La lecture s effectue en envoyant deux trames consécutives. Dans un premier temps, le pointeur doit être initialisé avec la sous-adresse du registre à lire. Cela revient à écrire l adresse du Beetle puis le pointeur. Une fois le pointeur initialisé, il suffit d envoyer une commande de lecture. La valeur du registre est alors écrite sur le bus de données. Bit écrit par la carte SPECS Bit écrit par le beetle Figure 23 - Trames à envoyer dans le cas du premier mode de lecture Comme pour l ecriture, la lecture de plusieurs registres consécutifs (uniquement parmi les vingt premiers registres) est possible. Pour cela, le pointeur doit être initialisé à la sous-adresse correspondant au premier registre à lire. Dans la trame suivante, la première donnée reçue correspond au premier registre. Cette donnée est suivie d un acquittement de la part de la mezzanine qui indique qu elle souhaite continuer à recevoir des données. Les données suivantes correspondent alors aux registres suivants. 2 ème mode de lecture: La lecture s effectue en envoyant une seule trame. La mezzanine doit écrire l adresse du Beetle suivie de la sous-adresse correspondant au registre à lire, puis la mezzanine génere une condition restart après laquelle est envoyé une commande de lecture, puis vient enfin l écriture des données sur le bus par le Beetle. Bit écrit par la carte SPECS Bit écrit par le beetle Figure 24 - Trame à envoyer dans le cas du second mode de lecture Actuellement, ce mode de lecture n est pas disponible pour l utilisateur car aucune fonction PVSS ne permet de générer la condition de restart. - 30 -

Tableau 1- Registres du Beetle 2.3.1.2 TTCrq Le TTCrq est une mezzanine développée au CERN et qui comporte deux ASICs : le TTCrx et le QPLL [6] aussi conçus au CERN. Le TTCrx reçoit les signaux TFC puis après décodage délivre l horloge et les signaux de synchronisation nécessaires aux dispositifs électroniques tels que le Beetle ou le Delay25. Il fournit entre autre une horloge de 40MHz, le signal de décision du premier niveau de trigger, et des signaux de reset. Le QPLL est un quartz qui permet de générer à partir de l horloge provenant du TTCrx une horloge plus propre. Elle réduit en fait le balayage de l horloge du TTCrx. Le TTCrx possède des registres internes permettant la configuration du TTCrq et la lecture de certaines valeurs clés par l utilisateur. L accès à ces registres se fait via une interface I 2 C. Le TTCrx possède vingt registres huit bits. Il possède aussi deux registres spéciaux : le registre pointeur et le registre de données. La lecture comme l ecriture d un registre se procède en deux étapes. Dans un premier temps, il faut envoyer après la condition start l adresse du registre pointeur suivi de la sous-adresse correspondant au registre à lire ou écrire, puis vient alors la condition stop. Cette première trame est nécessaire pour la lecture comme pour l écriture. Elle permet d initialiser le registre pointeur. La deuxième étape consiste à lire (dans le cas d une lecture) ou écrire (dans le cas d une écriture) dans le registre de donnée. L adresse du regitre pointeur est obtenue en multipliant par deux les six bits ID_I2C fixés sur le control board grâce à des cavaliers [11]. Le registre de données quant à lui se situe à l adresse «adresse du pointeur» + 1. - 31 -

Ecriture Lecture Bit écrit par la carte SPECS Bit écrit par le TTCrq Figure 25 - Trames d'écriture et de lecture d'un registre du TTCrq Tableau 2 - Registres du TTCrq 2.3.1.3 Delay25 Six Delay25 présents sur le control board permettent le déphasage de cinq signaux périodiques ou non [7]. Le Delay25 comporte six registres configurables via I 2 C. Les bits [6 :3] de l adresse I 2 C correspondant à un Delay25 est fixée sur le control board. Les bits [2 :0] de l adresse I 2 C permettent de définir le registre auquel on souhaite accéder. - 32 -

Ecriture Lecture Bit écrit par la carte SPECS Bit écrit par le Delay25 Figure 26 - Trames d'écriture et de lecture d'un registre du Delay25 2.3.1.4 DCU Tableau 3 - Registres du Delay25 Le DCU est une puce qui permet l acquisition d un signal parmi huit en entrée [8]. Il possède huit registres huit bits que l utilisateur peut utiliser. L écriture et la lecture s effectuent de la même manière que pour le Delay25 : les bits [6:3] identifient le DCU et les bits [2:0] sélectionnent le registre. L acquisition d une valeur de douze bits s effectue de la façon suivante : Ecriture dans le registre CREG d un 1 sur le bit 7 indiquant le début d une acquisition, et des bits [2:0] qui vont permettre de définir sur quelle entrée se fait l acquisition. Lire la valeur de de douze bits contenue dans les registres SHREG et LREG : RESULTAT[11:8]=SHREG[3:0] RESULTAT[7:0]=LREG[7:0] Tableau 4 - Registres du DCU - 33 -

2.3.1.5 Les AMUX Deux AMUXs se situent sur chaque mezzanine ECS (voir 1.2.3.2) et correspondent à des multiplexeurs [12]. Accesibles par le bus I 2 C, ils permettent de sélectionner une des tensions provenant des régulateurs de tensions et une des indications de courant. 2.3.1.6 Les registres internes de la mezzanine esclave SPECS La mezzanine esclave SPECS finale devrait posséder 11 registres. Quatre registres parmi les onze sont utilisés pour des fonctionnalités précises. Ces registres portent les noms suivants : CONFREGOUT_MSB, CONFREGOUT_LSB, REGOUT_MSB, REGOUT_LSB. Ils sont de tailles 16 bits. Le bit i des registres REGOUT_MSB et REGOUT_LSB indiquent si respectivement le bit i des registres REGOUT_MSB et REGOUT_LSB est un bit que l on peut lire car il correspondrait à une sortie ou un bit que l on peut écrire car il servirait d entrée pour autre chose [13]. Les bits 12, 13, 14, 15 du registre REGOUT_LSB et les bits 0 et 1 du registre REGOUT_MSB vont correspondre respectivement à l un des indices de courant curr_lim provenant des hybrides 1, 2, 3, 4, 5 et 6. REGOUT_MSB[15 :9] correspond à la valeur du regiatre de statut présent dans le FPGA. REGOUT_LSB[11 :0] correspond aux signaux TFC/I 2 C enable et Power On Reset envoyés aux hybrides. 2.3.1.7 Les régulateurs de tensions La sortie des régulateurs de tensions présents sur la low voltage card sont en entrée de l un des deux multiplexeurs sur la mezzanine ECS. Pour pouvoir lire une tension, l utilisateur doit effectuer une configuration du multiplexeur sur la tension qu il souhaite lire, puis faire une acquisition sur l une des entrées du DCU comme indiqué en 2.3.1.4. Les valeurs des indices de courant sont lues dans les registres internes de la mezzanine comme indiqué précédemment. 2.3.2 Description des fonctions PVSS utilisées Une bibliothèque de fonctions C a permis d élaborer une bibliothèque de fonctions PVSS relatives au bus I 2 C [14]. Deux types de fonctions PVSS permettant d écrire sur le bus I 2 C ont permis d établir la communication avec l électronique. Le premier type de fonctions prend en paramètre toutes les données caractéristiques au composant à sélectionner, place tous ces paramètres dans un datapoint, fait appel à la fonction C correspondante qui permet d envoyer le signal désiré, puis place le résultat dans le datapoint de départ. Ces fonctions posent un problème dans le sens où le même datapoint est utilisé à chaque appel de fonction, et l archivage des valeurs de tous les registres de tout le système est impossible. Un deuxième type de fonctions a donc été dévellopé pour palier à ce problème. Ces fonctions prennent en paramètre un datapoint donné contenant tous les paramètres propres au composant et les champs nécessaires pour stocker les valeurs lues. 2.3.2.1 Les fonctions indépendantes des datapoints crées par l utilisateur Les fonctions PVSS décrites ci-dessous permettent d accéder à des registres par le biais du même datapoint. Ce datapoint ne peut être utilisé que temporairement dans le cas d accès à différents registres car à chaque appel de fonction, les données passées en paramètre sont recopiés dans les champs du datapoint. Les données contenues précédemment dans le datapoint sont alors perdues. Voici les différentes fonctions utilisées dans les scripts PVSS : - 34 -

fwspecs_i2cwrite (string pspecs, int pmasterid, int pslaveaddress, int pi2cbus, int pi2caddress, int psize, dyn_char pdata) fwspecs_i2cwritesub (string pspecs, int pmasterid, int pslaveaddress, int pi2cbus, int pi2caddress, int pi2csubaddress, int psize, dyn_char pdata) fwspecs_i2cread (string pspecs, int pmasterid, int pslaveaddress, int pi2cbus, int pi2caddress, int psize, dyn_char &pdata) fwspecs_i2creadsub (string pspecs, int pmasterid, int pslaveaddress, int pi2cbus, int pi2caddress, int pi2csubaddress, int psize, dyn_char &pdata) fwspecs_dcuregisterwrite (string pspecs, int pmasterid, int pslaveaddress, int pdcuaddress, int pregisternum, char pdata) fwspecs_dcuregisterread (string pspecs, int pmasterid, int pslaveaddress, int pdcuaddress, int pregisternum, char &pdata) pspecs, pmasterid, pslaveaddress et pi2cbus, pdcuaddress permettent de localiser le composant auquel on souhaite accéder. Plus particulièrement, pspecs indique le nom de la machine qui porte la carte SPECS maître, pmasterid indique le port de la carte SPECS maître utilisé, pslaveadress représente le control board selectionné, pi2cbus permet de déterminer l un des bus du contrrol board. pdcuaddress représente les bits [6 :3] de l un des registres du DCU. pi2caddress, pi2csubaddress, et pregisternum caractérise le registre du composant que l on souhaite manipuler. pdata correspond à la donnée à écrire et &pdata à la variable qui va stocker une valeur lue. Les fonctions fwspecs_dcuregisterwrite et fwspecs_dcuregisterread sont des fonctions fwspecs_i2cwrite et fwspecs_i2cread spécifiques au DCU. fwspecs_i2cwrite et fwspecs_i2cread permettent d envoyer sur le bus sélectionné les trames suivantes : pour fwspecs_i2cwrite Bit écrit par la carte SPECS Bit écrit par le composant pour fwspecs_i2cread Bit écrit par la carte SPECS Bit écrit par le composant - 35 -

fwspecs_i2cwritesub et fwspecs_i2creadsub sélectionné les trames suivantes : pour fwspecs_i2cwritesub permettent d envoyer sur le bus Bit écrit par la carte SPECS Bit écrit par le composant pour fwspecs_i2creadsub Bit écrit par la carte SPECS Bit écrit par le composant Figure 27 - Trames générées par les fonctions PVSS 2.3.2.2 Les fonctions qui manipulent les datapoints crées par l utilisateur Le principe d utilisation d une de ces fonctions consiste à définir un datapoint dont la structure est adaptée à cette fonction, à remplir les parties du datapoint qui caractérisent le composant. Une fois l appel de la fonction effectué avec le datapoint comme paramètre de la fonction, alors l opération désirée est effectuée sur le composant correspondant au datapoint (dans le cas d une lecture, la valeur du registre est renvoyée dans le datapoint). Supposons qu un composant comporte un seul registre dans lequel on souhaite lire. Alors la structure du datapoint correspondant à ce composant doit être la suivante : Figure 28 - Structure d'un datapoint pour un composant accessible par un bus I 2 C - 36 -

Après avoir crée cette instance, l utilisateur doit remplir les champs specs, masterid, slaveaddress et i2cbus, champs caractéristiques au composant. Il doit aussi remplir le champ i2caddress, i2csubaddress si necessaire, et size qui sont propres au registre. A cet instant, l utilisateur peut manipuler le datapoint comme s il manipulait le composant associé. S il désire effectuer une lecture d un octet dans le registre, alors il lui suffit de faire appel à la fonction fwspecs_i2creadbyname de la manière suivante : fwspecs_i2creadbyname ( composant. registre, 1, mydata); La valeur du registre qui est alors lue est placée dans le champ readings.data du datapoint composant La valeur est aussi stockée dans la variable mydata dans le cas où l on souhaiterait utiliser la valeur directement après l appel de fonction. Voici ci-dessous quatre fonctions qui ont été utilisées dans l élaboration des scripts PVSS. fwspecs_i2cwritebyname (string pregister, int psize, dyn_char pdata) fwspecs_i2creadbyname (string pregister, int psize, dyn_char &pdata) fwspecs_regwritebyname (string pregister, dyn_char pdata) fwspecs_regreadbyname (string pregister, dyn_char &pdata) pregister correspond au registre que l utilisateur souhaite manipuler. psize indique le nombre d octets à lire ou à écrire. pdata est la valeur à écrire. &pdata correspond à la variable qui va stocker une valeur lue. Les deux fonctions fwspecs_regwritebyname et fwspecs_regreadbyname sont des fonctions spécifiques aux registres externes de la mezzanine. Les fonctions fwspecs_i2cwritebyname et fwspecs_i2creadbyname sont quant à elles plus général et permettent de lire ou écrire dans un composant I 2 C quelconque. 2.3.3 Modélisation du système à contrôler La première étape dans la réalisation du logiciel de contrôle du Vertex Locator a consisté à définir la base de données représentative de tous les composants électroniques à configurer. Les types de datapoint de base ont tous d abord été crées à partir de types déjà existants : ces types de base sont les composants décrits auparavant comme le Beetle, le Delay25, ou le TTCrq. A partir de ces composants de base ont été crées des types plus élaborés comme l hybrid ou la Low Voltage Card. Enfin, un type de datapoint de niveau plus élevé a été crée : le control board. Voici la description complète de la structure de datapoint réalisée : 2.3.3.1 Types déjà existants - 37 -

2.3.3.2 Types de base - 38 -

2.3.3.3 Types de second niveau 2.3.3.4 Types de troisième niveau Figure 29 - Structures de tous les datapoints modélisant le systeme de contrôle du VELO - 39 -

Une fois ces définitions de types de datapoint effectuées, la création d instances doit être réalisée. Le choix de créer les instances et de les répartir d une manière donnée sur différents ordinateurs est laissé à l utilisateur. Cependant, le logiciel a été réalisé de telle sorte que l utilisateur doit procéder d une façon définie lorsqu il crée ses instances. Dans un premier temps, il doit créer un nouveau type de datapoint portant précisemment l un des deux noms suivants selon qu il désire crée une instance de control board appartenant au Pile Up, à la partie droite ou à la partie gauche du VELO : PileUpSection VeloSection Ensuite, il définit comme champ du type créé l un des noms suivant avec une ortographe identique à celle indiquée : ControlBoard1, ControlBoard2, ControlBoard3, ControlBoard4, ControlBoard5, ControlBoard6 ou ControlBoard7. Le type PileUpSection ne peut contenir que ControlBoard1, ControlBoard2 et ControlBoard3. Tous les champs pour le type VeloSection doivent faire référence au type VeloControlBoard. Pour le type PileUpSection, le champ ControlBoard1 doit obligatoirement faire référence au type PileUpHybControlBoard. Les champs ControlBoard2 et ControlBoard3 doivent obligatoirement faire référence au type PileUpOBControlBoard. Enfin, l utilisateur peut créer les instances proprement dites. Il doit obligatoirement créer une instance de PileUpSection en la nommant exactement pileup. L instance de VeloSection correspondant à la partie droite du VELO doit exactement être nommé velo_r et la partie gauche velo_l. 2.3.4 Interface graphique réalisée Un panneau de contrôle est un panneau de surveillance ont été conçus. Le panneau de contrôle comporte cinq sous-panneaux, un sous-panneau étant dédié à la configuration d un type de composant. Il offre la possibilité de configurer tous les registres d un ou plusieurs componsants à partir d un fichier. Il permet aussi de configurer un registre particulier en entrant la valeur directement dans le champ Data in. - 40 -

Figure 30 - Panneau de contrôle Le panneau de surveillance composé de la même manière cinq sous-panneaux, permet d observer le contenu des registres d un composant. La lecture dans tous les registres est périodique. Figure 31 - Panneau de surveillance - 41 -

2.4 Conception du microprogramme à implanter dans le FPGA du control board et logiciel associé. 2.4.1 Les outils de développement 2.4.1.1 Visual elite Visual elite est un logiciel de conception pour FPGA et ASIC. Il a permis dans un premier temps de développer chaque entité et architecture en VHDL puis d effectuer par la suite une simulation fonctionnelle du design réalisé. 2.4.1.2 Synplify L'outil Synplify réalise ensuite la synthèse logique : il effectue l implémentation physique du design. 2.4.1.3 Actel Designer Actel Designer permet de faire correspondre les pins du composant actel aux entrées sorties du design, d effectuer le placement et le routage puis de générer le fichier.bit ou stapl qui permettra la programmation du FPGA. 2.4.1.4 Actel Flash Pro Lorsque le fichier bit ou stapl a été généré, le FPGA est prêt pour la programmation. Il suffit alors de le connecter au programmeur d Actel qui est lui-même connecté à un ordinateur sur le port parallèle. Le logiciel Actel Flash Pro doit être lancé. Successivement, l utilisateur se connecte au programmeur, détecte le FPGA, ouvre le fichier bit ou stapl, puis lance la programmation. 2.4.2 Fonctionnalités implémentées Le control board recevra les commandes de configuration des différents composants provenant du bus SPECS et les commandes de synchronisation dites commandes TFC (Timing and Fast Commands) puis les distribuera à toute l électronique situé derrière. Le control board surveille et contrôle entre autres les régulateurs de tensions situés sur le repeater board. Ce chapitre décrit donc les fonctionnalités définies pour l élaboration du code à implanter dans le FPGA du control board. Dans un premier temps est décrite la fonctionnalité du FPGA pour un fonctionnement normal du système. Elle prévoit de satisfaire à la fois les besoins des hybrides du VELO et ceux des hybrides du Pile-Up. Le contrôle de l optical board du Pile-Up nécessiterait un microprogramme différent. Cependant, cette différence a été prise en compte dans la réalisation de ce microprogramme. En fait, le choix d une des configurations parmi les deux est défini par le signal OPTICAL_SELECT [11]. Dans un deuxième temps sont décrites les fonctionnalités supplémentaires qui ont étés implémentées dans la perspective de réaliser certains débuggages. Cela concerne spécialement la surveillance des signaux TFC et le fonctionnement du TTCrx et du QPLL. - 42 -

2.4.2.1 Spécifications définies pour le fonctionnement normal du système Bus I 2 C Le FPGA utilise le bus local I 2 C pour la communication avec la mezzanine esclave SPECS. Par conséquent le FPGA possède une interface esclave pour décoder les signaux I 2 C envoyées par la mezzanine, et donc pour lire et écrire dans les registres internes. Afin de ne pas trop occuper l espace d adressage I 2 C, l accès aux registres internes est réalisé à l aide d un système de pointeur. La mezzanine SPECS est le maître sur le bus local I 2 C et l adresse du FPGA est codée en dur dans le microprogramme. Le FPGA se situe à l adresse 0010110 sur le bus local (bus numéro 15). Les signaux du bus sont nommés SDA25 et SCL25 sur les schémas du control board. Pour écrire dans un registre, la carte SPECS esclave envoie dans un premier temps sur le bus local I 2 C l adresse du FPGA, puis le pointeur correspondant au registre et enfin la donnée à écrire. Pour la lecture, la carte SPECS esclave effectue la même opération à l exception près qu à la place d écrire la donnée, la donnée est lue. Un système d incrémentation du pointeur a été implémenté de telle sorte qu il est possible d écrire ou de lire dans plusieurs registres successifs. Il suffit donc, par exemple pour écrire dans les registres 3, 4, et 5, d envoyer l adresse du FPGA, puis le pointeur correspondant au premier registre (dans ce cas là, le registre 3), puis les trois valeurs à écrire. Ecriture Lecture Bit écrit par la carte SPECS Bit écrit par le FPGA Figure 32 - Trames d'écriture et de lecture d'un registre du FPGA Une seconde fonctionnalité sur le bus I 2 C a été implémentée. Les niveaux de signal du bus I 2 C originaire de la carte esclave SPECS et en entrée du FPGA sont en CMOS 2.5. Ces signaux sont alors copiés par le FPGA en 3.3V car c est le niveau de signal requis par le TTCrx. Ces signaux sont nommés SDA33 et SCL 33 sur les schémas du control board. Les ports du FPGA sont configurés pour être conforme avec la norme I 2 C. Les signaux de reset Sur le control board, deux signaux de reset sont présents, POWER_RST et SPECS_RST.[11]. Les deux sont actifs au niveau bas et sont des signaux en 3.3V. POWER_RST est déclenché au démarrage. SPECS_RST provient de la commande de reset envoyée à travers le bus SPECS. Ces signaux sont reçus par le FPGA lequel génère à partir de là un reset actif au niveau bas. RESET = POWER_RST I SPECS_RST - 43 -

Ce signal résultant effectue le reset des registres internes. De plus, il est distribué hors du FPGA à la fois en 2.5V et 3.3V. Les deux signaux sont appelés RESET_25 et RESET_33. [11]. Sélection de l horloge Le control board possède quatre sources différentes pour le système d horloge. [11]. Une seule horloge peut être sélectionnée à la fois à n importe quel moment. La sélection de l horloge que l on souhaite utiliser est réalisée grâce aux deux bits du registre de configuration CLK_SEL. L horloge par défaut est celle qui provient du SPECS, appelée CLK_FROM_SPECS.[11]. L horloge est envoyée à la carte esclave SPECS avec un niveau de 3.3V (CLK_TO_SPECS) et aux hybrides (CLK_25) avec un niveau de 2.5V. Horloge Nom Description CLK_SEL Horloge SPECS CLK_FROM_SPECS Générée par l esclave SPECS. Horloge local, asynchrone avec le reset du système. Horloge TTCrx Clock40Des1 Horloge reçue par le TTCrx du TFC système, retardée par le registre Deskew. Horloge QPLL Clock40Des1_QPLL Horloge du TTCrx nettoyée par le QPLL dans le TTCrq Horloge LVDS LVDS40MHz Horloge d au-dessus avant passage dans le convertisseur LVDS-CMOS dans le TTCrq 00 01 10 11 Sélection et distribution des signaux TFC Tableau 5 - Les quatre horloges du système Les trois types de dispositifs que sont les hybrides du VELO, les hybrides du Pile Up et les optical boards nécessitent différentes combinaisons de signaux de synchronisation. Un maximum de cinq signaux, horloge comprise, peut être distribué à chacun des dispositifs. Puisque le VELO a besoin d un sous-ensemble des signaux pour le Pile-Up, alors les signaux en commun sont envoyés aux deux dispositifs. Le signal nommé OPTICAL_SELECT va permettre d effectuer la sélection des signaux qui doivent être envoyés selon que le dispositif soit un optical board ou un hybride. NB: L'horloge du système doit être envoyée par l'intermédiaire de la ligne marquée CLK_25 sur les schémas [11]. CompClock est une copie de l'horloge déphasé de 180 degrés (ou inversé). Dispositif Hybride du VELO Hybride du Pile Up Optical board Signaux de synchronisation nécessaires Clock, L0Accept, L0 FE Reset, Test Pulse Clock, CompClock, L0Accept, L0 FE Reset, Test Pulse Clock, L0Accept, L0 FE Reset, Bunch-ID Reset, Test Pulse Tableau 6 - Les signaux de synchronisation requis par les différents dispositifs - 44 -

Signaux inhibiteurs Il y a cinq signaux inhibiteurs par hybride, appelés VDREN_#, VHYB0EN_#, VHYB1EN_#, VHYB2EN_# et VHYB3EN_#. Ces signaux allument et éteignent les régulateurs de tension pour l hybride. Cette configuration est réalisée en écrivant dans le registre V_EN_REG#, où # représente le numéro de l hybride concerné (0-5). La structure des registres est définie plus loin et les valeurs par défaut au démarrage sont telles que les régulateurs de tensions sont éteints. Changement de niveau Le FPGA est entre autre utilisé pour effectuer un changement de niveau pour certains signaux. On désire particulièrement obtenir en 3.3V les signaux décrits dans le bloc TFC_2V5_TO_LVDS des schémas du control board [11]. En entrée ces signaux sont en 2. 5V. Cette spécification est réalisée par une simple connexion entre les pins d entrée et les pins de sortie. 2.4.2.2 Spécifications définies pour le débuguage du système Compteurs d erreur Le FPGA surveille les conditions d erreur signallées par la mezzanine TTCrq. Le TTCrx envoie deux signaux, SinErrStr et DbErrStrobe, indiquant des erreurs de transmission des signaux TFC [11]. SinErrStr indique qu une erreur de transmission sur un seul bit a eu lieu. DbErrStrobe indique qu une erreur de 2 bits a été détectée ou bien une erreur dans la trame de transmission. Ces erreurs peuvent seulement être détectée et ne peuvent pas être corrigées. SEU_error_QPLL est un autre signal indiquant un SEU (Single Event Upset= basculement logique d un point mémoire induit par le passage d une particule). Il permet de détecter un SEU single errror upset dans le QPLL. Trois compteurs 8-bits sont implémentés, un pour chaque type d erreur. Les compteurs sont incrémentés à chaque détection d erreur et lorsqu ils atteignent la valeur 255, ils conservent cette valeur jusqu à ce qu un reset du compteur soit effectué. Le reset des compteurs est déclenché par le passage du bit CNT_RST du registre de contrôle à 1. Lorsque la valeur d un compteur est non nulle, alors le bit correspondant dans le registre de statut est mis à 1. Le registre de statut permet donc de savoir si une erreur s est produite depuis le dernier reset. Surveillance des compteurs TFC Les compteurs de Level 0 Event ID et de Bunch ID du TTCrx sont disponibles sur le bunch counter bus, appelé BCnt0-11 sur les schémas du control board [11]. La présence des valeurs des compteurs sur le bus est indiquée par les signaux BCntStr, EvCntLStr et EvCntHStr. Les valeurs des compteurs sont alors copiés dans les registres internes du FPGA lorsque les trois signaux BCntStr, EvCntLStr et EvCntHStr indique la présence de ces valeurs sur le bus. Ces valeurs peuvent être ensuite lues via l interface I 2 C. Cette fonctionnalité n est disponible que si le bit CNTR_MON du registre de configuration est mis à 1. Registre de statut Le registre de statut de taille 8 bits indique l état du système. Ce registre est connecté en sortie au registre externe de l esclave SPECS. (bits 24-31). La valeur du registre de statut est par conséquent disponible à la fois dans le FPGA et dans l esclave SPECS. - 45 -

2.4.2.3 Registres internes Le FPGA possède sept registres que l on peut à la fois lire et écrire pour configurer le système. Il possède de plus neuf autres registres que l on ne peut que lire pour avoir une indication sur le système. Le contenu des registres est défini ci-dessous avec plus de précisions. Les bits marqués X ne sont pas utilisés. Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 CTRL_REG: Registre de contrôle (ou registre de configuration) X X X INTR_EN CNTR_MON CNT_RST CLK_SEL1 CLK_SEL0 V_EN_REG0: Registre de contrôle des régulateurs de tension pour l hybride 1 X X X VDRV VHYB3 VHYB2 VHYB1 VHYB0 V_EN_REG1: Registre de contrôle des régulateurs de tension pour l hybride 2 X X X VDRV VHYB3 VHYB2 VHYB1 VHYB0 V_EN_REG2: Registre de contrôle des régulateurs de tension hybride pour l hybride 3 X X X VDRV VHYB3 VHYB2 VHYB1 VHYB0 V_EN_REG3: Registre de contrôle des régulateurs de tension pour l hybride 4 X X X VDRV VHYB3 VHYB2 VHYB1 VHYB0 V_EN_REG4: Registre de contrôle des régulateurs de tension pour l hybride 5 X X X VDRV VHYB3 VHYB2 VHYB1 VHYB0 V_EN_REG5: Registre de contrôle des régulateurs de tension pour l hybride 6 X X X VDRV VHYB3 VHYB2 VHYB1 VHYB0 Tableau 7 - Registres du FPGA pour la configuration du système (accès lecture et écriture) - 46 -

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 STATUS_REG: Registre de statut X X X X X SEU_ERR DB_ER R SIN_ERR SEU_ERR_REG: Compteur d erreur pour le signal SEU_ERR 8-bit error counter SIN_ERR_REG: Compteur d erreur pour le signal SIN_ERR 8-bit error counter DB_ERR_REG: Compteur d erreur pour le signal DB_ERR 8-bit error counter B_ID_LOW: Partie basse du compteur Bunch-ID Bits 0-7 of Bunch-ID B_ID_HIGH: : Partie haute du compteur Bunch-ID X Bits 8-11 of Bunch-ID EV_ID_LOW: : Partie basse du compteur Level-0 Event Bits 0-7 of Event-ID EV_ID_MID: : Partie mediane du compteur Level-0 Event Bits 8-15 of Event-ID EV_ID_HIGH: : Partie haute du compteur Level-0 Event Bits 16-23 of Event-ID Tableau 8 - Registres du FPGA pour la surveillance du système (accès lecture uniquement) - 47 -

2.4.3 Architecture interne du FPGA 2.4.3.1 Aperçu général du design réalisé Figure 33 - Architecture du design pour le FPGA Le design comporte globalement quatres parties majeures : les blocs I2C Signals Connection, Clock Selection, TFC Signals Connection et le bloc restant qui constitue les registres et ce qui permet de lire ou d écrire dedans. Remarque : les blocs de reset n ont pas été représentés. 2.4.3.2 Fonctionnalité des composants crées I2CInterface Figure 34 - Bloc I2CInterface I2CInterface divise la ligne bidirectionnelle sda en deux lignes unidirectionnelle sda_in et sda_out. Soit sda est copié sur sda_in, c est le cas pour une écriture de la mezzanine vers le FPGA, soit sda_out est copié sur sda pour une transmission du FPGA vers la mezzanine. Le signal de contrôle sda_we permet de selectionner la liaison à réaliser. Le signal scl est tout simplement copié sur scl_in. Sda_in et scl_in vont alors servir de signaux d entrée pour les autres composants du FPGA. - 48 -

SlaveRead Figure 35 - Bloc SlaveRead Ce composant lit un octet sur le bus sda_in, puis génère sur le front montant de scl_in suivant un signal d acquittement sur sda_out. L octet est alors disponible sur le bus byte_read lorsque le signal byte passe à 1. La lecture débute si une impulsion sur le signal start a lieu et le signal end_read indique la fin de la lecture de l octet et de la génération de l acquittement en passant quelques instants à 1. SlaveWrite Figure 36 - Bloc SlaveWrite Ce composant transmet en série sur la sortie sda_out l octet présent sur le bus byte, puis génère un 1 sur fin_tx pour indiquer la fin de la transmission. Les entrées sda_in et scl_out permettent de repérer l acquittement généré par le maître. L écriture débute si une impulsion sur le signal start a lieu et le signal end_write indique la fin de la l écriture de l octet et de la génération de l acquittement de la part du maître en passant quelques instant à 1. - 49 -

Counter8Bits Figure 37 - Bloc Counter8Bits Ce compteur 8bits s incrémente à chaque front montant d horloge. Il se bloque à la valeur 11111111. Seul un reset peut le refaire passer à 00000000. Trois instances de ce compteur sont utilisées pour réaliser SEU_ERR_REG, SIN_ERR_REG, DB_ERR_REG. CTRLReg8Bits, Register8Bits, Register12Bits Figure 38 - Blocs CTRLReg8Bits et Register8Bits Register8Bits est un registre synchrone actif sur un front montant d horloge. Pointer Register pointant sur l un des registres internes, V_EN_REG0, V_EN_REG1, V_EN_REG2, V_EN_REG3, V_EN_REG4, V_EN_REG5, constituent sept instances de ce composant. CTRLReg8bits se distingue de Register8Bits sur un point : le bit 2 revient immédiatement à 0 après un passage à 1. Register12Bits est aussi un registre synchrone actif sur un front montant d horloge. Il est utilisé dans le composant TFCCounters. - 50 -

StatusRegister8Bits Figure 39 - Bloc StatusRegister8Bits Le registre de statut indique si des erreurs ont été détéctées. Les bits 4 à 7 sont toujours à 0 car inutilisés. Les trois autres bits sont le resultat d une fonction AND entre tous les bits de chaque signal d erreur. Ainsi, les bits de statuts passent à 1 dès que les signaux sont différents de 0. Ce registre est asynchrone. Mux15 Figure 40 - Bloc Mux15 Multiplexeur qui sélectionne une des 15 entrées din grâce au signal sel_mux15-51 -

ControlInterface Figure 41 - Bloc ControlInterface Ce composant est l unité de contrôle de ce design. Les sorties de ce composant à l exception de sda_out sont des signaux de commandes des autres unités. Sda_out correspond à la donnée destinée au maître, sda_out_1 ou sda_out_2. Sda_out_1 provient du composant slave_read et est utilisé pour l acquittement envers le maître. Sda_out_2 provient du composant slave_write et permet la transmission des données du FPGA vers la mezzanine. Les signaux de commandes : sel_mux15 sélectionne la donnée contenue dans l un des 15 registres à transmettre à la mezzanine. start_slave_read permet d actionner le composant slave_read. start_slave_write permet d actionner le composant slave_write. ld_pointer charge le registre pointer. ld_reg0 charge le registre CTRL_REG. ld_reg1 charge le registre V_EN_REG0. ld_ reg2 charge le registre V_EN_REG1. ld_ reg3 charge le registre V_EN_REG2. ld_ reg4 charge le registre V_EN_REG3. ld_ reg5 charge le registre V_EN_REG4. ld_ reg6 charge le registre V_EN_REG5. nresetslave1 envoie un signal de reset vers le composant slave_read. - 52 -

Figure 42 - Automate du bloc ControlInterface - 53 -

Certains états decrits ci-dessus sont des macro-états. Voici en details leur correspondance dans le code VHDL : - Repos : q0 - Lecture de l adresse et du bit R/W : q1 - Ecriture de l acquittement : q2 q3 - Lecture du pointeur : q4 - Ecriture de l acquittement : q5 q6 - Détection de condition : q7 q8 - Ecriture de 8 bits : q21 q9 q10 - Lecture de l acquittement : q22 q23 - Incrémentation du pointeur : q24 q27 - Détection de condition : q26 q28 - Lecture de 8 bits : q11 - Ecriture de l acquittement : q12 q13 - Incrémentation du pointeur : q14 q15 - Detection de condition : q16 q18 q33 - Attente de la condition stop : q31 q32 q34 I2CSignalsConnection Figure 43 - Bloc I2CSignalsConnection Ce composant permet de copier le bus sda25 et scl25 provenant de la mezzanine sur le bus sda33 et scl33. Il a été réalisé en utilisant deux instances du composant I2CInterface. Voici un schéma interne du composant et un extrait de code en VHDL de l architecture de I2CSignalsConnection qui permettront de mieux comprendre le fonctionnement : - 54 -

Figure 44 - Architecture interne du bloc I2CSignalsConnection process(sda3325,sda2533) begin if sda3325='0'then sda_we25<='1'; sda_we33<='0'; elsif sda2533='0' then sda_we25<='0'; sda_we33<='1'; else sda_we25<='0'; sda_we33<='0'; end if; end process; La copie de la ligne d horloge scl25 sur scl33 ne pose aucun problème car l horloge est distibuée uniquement par le maître (sda25 et scl25 se situent du côté maître tandis que sda33 et scl33 se situent du côté esclave). La connection entre sda25 et sda33 est quant à elle différente : l esclave comme le maître peut écrire sur la ligne de donnée. Lorsque le maître écrit, alors sda25 doit être copié sur sda33 et lorsque l esclave écrit, sda33 doit être copié sur sda25. Cependant, des résistances de rappel sur sda25 et sda33 tirent ces lignes vers l état haut lorsqu aucun signal n est envoyé. L écriture d un 1 ne nécessite alors aucune copie. Par conséquent, l écriture d un 0 va permettre de commander les deux composants I2CInterface. Sda3325, sda2533, sda_we33 et sda_we25 sont des signaux internes. Le code VHDL indique que lors de l écriture d un 0 sur sda33, donc sur sda3325, le bloc dont le signal de contrôle se nomme sda_we25 autorise l écriture de sda3325 sur sda. Le même procédé est effectué dans le cas d une écriture du maître vers l esclave. - 55 -

ClockSelection Figure 45 - Bloc ClockSelection Ce composant réalise la sélection d une horloge parmi les 4 possibles grâce au signal sel. L entrée sel est connectée aux bits 0 et 1 du registre de contrôle. Un multiplexeur réalise cette fonction. Remarque: il se peut qu il y ait une modification à réaliser car lors du changement d horloge, un passage à 1 de Clock25 plus court que la demi période des 4 horloges pourrait être généré et entraîner le blocage du Beetle. Ce problème pourrait être aussi résolu en effectuant un reset du Beetle après le changement d horloge. TFCSignalsSelection Figure 46 - Bloc TFCSignalsSelection Ce composant sélectionne parmi les signaux d entrées ceux à envoyer au dispositif qui se situe derrière. CLK_25, L0_RST_25, L0A_25 et TEST_PULSE_25 sont respectivement connectés à Clock25, L0_FRONTEND_RESET, L0Accept, TESTPULSE. COMPCLK_25 est quant à lui défini comme indiqué sur le schéma suivant : Figure 47 - Logique de sélection du signal COMPCLK_25-56 -

TFCCounters Figure 48 - Bloc TFCCounters TFCCounters comporte trois registres 12 bits qui prennent en entrée tous les trois le bus BCnt[11:0]. La figure suivante permet de comprendre le fonctionnement de ce bloc. Les trois registres vont permettre de récupérer bunch_n<11 :0>, event_n<11 :0> et event_n<23 :12> contenant les valeurs des compteurs TFC. Lorsque l une des trois valeurs est disponible sur le bus BCnt<11:0> (BCntStr, EvCntLStr et EvCntHStr indiquent la présence des valeurs sur le bus), alors le registre correspondant est chargé sur le front montant de Clock40Des1. L entrée en des trois registres résulte d une fonction and entre CNTR_MON et le signal ###Str associé au registre. Ainsi, les chargements n ont lieu que si CNTR_MON = 1 (CNTR_MON est fixée par l utilisateur dans le registre de contrôle). Les données contenues dans les registres sont disponibles en sortie sous la forme d octets et non sous la forme de 12 bits afin de faciliter la communication suivant le protocole I 2 C. Figure 49 - Chronogramme indiquant la disponibilite des signaux bunch_n et event_n sur le bus BCnt - 57 -

Reset1 Figure 50 - Bloc Reset1 Ce composant génère un signal de reset actif à l état bas lorsque l une des deux entrées passent à l état bas. Il s agit tout simplement d une fonction AND. Il sert à réaliser RESET à partir de POWER_RST et SPECS_RST, et le reset du composant SlaveRead à partir de RESET et du signal de reset envoyé par l unité de contrôle. Reset2 Figure 51 - Bloc Reset2 Ce composant génère un signal de reset actif à l état haut lorsque nreset passe à l état bas ou lorsque reset1 passe à l état haut. Il est utilisé pour réaliser le reset des trois compteurs d erreur. Deux signaux peuvent effectuer un reset sur le compteur : RESET issu de POWER_RST et SPECS_RST, et le bit 2 du registre de contrôle. - 58 -

2.4.4 Interface graphique permettant la configuration du FPGA Un sous-panneau consacré au FPGA a été intégré dans les deux panneaux décrits dans 2.3.4. L utilisation est identique à celle des autres sous-panneaux. Figure 52 - Panneaux de configuration et de surveillance des registres du FPGA - 59 -

3 Résultats et discussions La fonctionnalité du logiciel a été obtenue. Cependant, certains problèmes ont été rencontrés et doivent être résolus. 3.1 Ecriture à partir de la base de données Le logiciel conçu est tel que la configuration du VELO s effectue uniquement par l intermédiaire de l interface graphique créée : il faut cliquer sur un bouton pour lancer la configuration. L utilisateur aurait souhaité pouvoir effectuer une écriture dans un registre en modifiant simplement le champ writings.data d un datapoint. Cette option est possible grâce à la fonction dpconnect qui fait appel à une fonction à chaque fois que le contenu d un datapoint change. Cependant, cette solution n a pas été retenue car chaque écriture doit être suivie d une lecture pour s assurer que la valeur correcte a bien été écrite, or aucun mécanisme au niveau du matériel ne permet d envoyer la valeur d un registre dans le champ readings.data d un datapoint à chaque fois que la valeur dans le registre change. 3.2 Vitesse de lecture et d écriture Le Vertex Locator (Pile Up inclus) comporte au total 88 hybrides contenant 16 Beetles chacun. Avec 24 registres par Beetle, le nombre total de registres pour les hybrides du Vertex Locator se chiffre à 33792. L utilisateur du Vertex Locator souhaiterait pouvoir instantanément configurer le système tout entier puis surveiller les valeurs régulièrement. Cependant, une mesure effectuée à l oscilloscope relève un intervalle de 125 ms entre deux appels de fonctions PVSS. Les fonctions PVSS n étant pas adaptées au Beetle, la seule écriture d un registre 8 bits d un Beetle nécessite deux appels de fonctions. (Tout d abord l écriture sur le bus de données de la sous-adresse du registre puis enfin l écriture de la valeur). Actuellement, la configuration de tous les registres d un Beetle avec une lecture en retour requiert 21 appels de fonctions. Par conséquent, la configuration d un Beetle est réalisée en 2625 ms, ce qui représente une heure de configuration pour tous les hybrides. Le problème semble provenir de l implémentation des fonctions PVSS à partir des fonctions C. L implémentation des fonctions PVSS est telle qu un acquittement est attendu avant la fin de l execution de la fonction. La solution qui semble donc résoudre ce problème consiste à ne plus attendre l acquittement pour pouvoir tout de suite passer à la fonction suivante. Afin d optimiser le logiciel et de gagner du temps si l amélioration précédente n est pas complètement efficace, voici quelques propositions de modifications : Dans les deux panneaux de configuration est de surveillance, un script est exécuté périodiquement pour indiquer si un serveur SPECS est reconnu par le client en affichant dans le champ au bas du panneau «Waiting for a SPECS client» ou «SPECS client is running». Afin d optimiser le temps d exécution des scripts de configuration, il est possible de supprimer le script précédent qui correspond à l action EventIntialize des deux panneaux. - 60 -

Essayer d implémenter une fonction PVSS spécifique au Beetle qui puisse configurer un Beetle entier d un seul coup. L implementation de cette fontion serait alors à réaliser dans le serveur SPECS. Actuellement, l écriture des registres 20,21 et 22, de taille 1024 et 128 bits est réalisée en envoyant des trames successives contenant 16 octets de données seulement. Cette restriction provient du protocole SPECS qui possède actuellement une limite dans le nombre de données qui sont transmises sur le bus SPECS. Prochainement, il sera possible d envoyer un nombre illimité de données et par conséquent l écriture de l un des trois registres précédents pourra s effectuer d un seul coup. 3.3 Problème de mémoire PVSS est un logiciel qui nécéssite une mémoire très importante lorsque la base de données est grande. Au final, trois ordinateurs comporteront une carte SPECS maître chacun. Chacun des ordinateurs sera consacré à une partie du système, autrement dit un ordinateur pour la demi-partie droite du VELO, un ordinateur pour la demie-partie gauche du VELO, et un ordinateur pour le Pile Up. La base de données pourra donc être répartie entre les trois machines. Actuellement, un ordinateur de 512 MegaOctets de mémoire ne permet pas la création de 7 control boards dans la base de données. Le problème peut être résolu de trois manières : Ajouter jusqu à 2 GigaOctets de mémoire sur chaque ordinateur. Si la proposition précédente ne fonctionne pas, alors il faudra éventuellement tester la séparation de l ensemble des datapoints correspondant à une des trois parties du système sur deux ordinateurs connectés au même ordinateur comportant la carte maître SPECS. Le dernier recours consiste à modifier la structure de la modélisation du sytème. L arbre défini actuellement possède des champs redondants et qui peuvent être factorisés. Par exemple le type de datapoint SpecsSpecificBeetle comporte le champ masterid qui concrétement est spécifique à la carte SPECS maître. Sachant qu une seule carte SPECS maître est utilisée pour les 7 control boards de la partie droite du VELO par exemple, il serait préférable de placer ce champ dans un type de niveau plus haut, le control board par exemple, afin de réduire le nombre de feuilles de l arbre. Une instance de VELOControlBoard contient 22000 champs. En factorisant au maximum, cette instance peut posséder un nombre de champs réduit à 5000. Cependant, il est préférable de n utiliser cette solution qu en dernier recours car les types de base ont été défini dans le but de n utiliser que les fonctions qui manipulent les datapoint créés par l utilisateur et dans le but d avoir une implémentation générique des fonctions PVSS. Aussi, modifier la base de données implique une modification du code. 3.4 Problème d attribution de pins Certaines pins du FPGA n ont pas réussi à être attribuées tel que le concepteur du control board les a défini car certains signaux doivent utiliser les réseaux globaux du FPGA pour favoriser la synchronisation. - 61 -

Conclusion Une premiere version du logiciel de configuration et de surveillance du Vertex Locator est donc à présent disponible. Les configurations du Beetle, du DCU, et du Delay25 ont été validées. Le microprogramme implanté dans le FPGA est actuellement en cours de test, ainsi que l accès au TTCrq qui utilise le bus I 2 C en 3.3V à la sortie du FPGA. De même, la lecture d une tension provenant de l un des régulateurs de tension et la bonne distribution des signaux de synchronisation seront prochainement vérifiées. Cependant, malgré la fonctionnalité fournie par ce logiciel, une contrainte de temps de configuration subsiste. Afin d optimiser le logiciel, une collaboration étroite avec les concepteurs du serveur DIM sera nécessaire car ces derniers doivent connaître précisemment les besoins du Vertex Locator pour implémenter de nouvelles fonctions PVSS ou même modifier le serveur DIM. D autre part, des fonctionnalités supplémentaires comme une demande d interruption de la part du FPGA pourront être dévellopées dans le micro-programme. Côté PVSS, le minimum de fonctionnalités ayant été réalisées pour le fonctionnement du Vertex Locator, il sera possible d agrémenter l interface graphique en y ajoutant des options comme la signalisation par des alarmes de tensions trop grandes à la sortie des régulateurs. Aussi, un aménagement dans l interface graphique permettant la configuration du système à partir d une base de données externe est à prévoir. Par conséquent, les quelques mois précédant les premiers tests du Vertex Locator offriront l occasion de modifier cette première version du logiciel en une version optimisée pour le système final. - 62 -

Références [1] LHCb Reoptimized detector design and performance, Technical Design Report 9 [2] LHCb VELO, Technical Design Report 5 [3] LHCB Online system, Technical Design Report 7 [4] http://dim.web.cern.ch/dim [5] Control and Monitoring of the VELO and Pile-Up Level 0 Electronics, L. Eklund, EDMS 596194 [6] TTCrx Reference Manual, J. Christiansen and A. Marchioro, http://ttc.web.cern.ch/ttc [7] Delay25, H. Correia, A. Marchioro, P. Moreira and J.Schrader [8] DCUF User Guide, G. Magazzu, A. Marchioro and P. Moreira [9] Mezzanine Croquette design files, D.Charlet [10] The Beetle Reference Manual, N van Bakel and al. [11] Control Board design files, A. Denker and L. Eklund, EDMS 608966 [12] Analog Multiplexer Datasheet [13] SPECS: a Serial Protocol for the Experiment Control System of LHCb, D. Breton and D. Charlet [14] https://test-interfaces.web.cern.ch/test-interfaces/beta - 63 -

- 64 -