• Aucun résultat trouvé

LA CARTE D’ÉLECTRONIQUE DHCAL1 63 La mémoire doit être pleine pour qu’elle puisse être lue, ce qui peut être une contrainte

Électronique du calorimètre hadronique semi–digital

2.3 LA CARTE D’ÉLECTRONIQUE DHCAL1 63 La mémoire doit être pleine pour qu’elle puisse être lue, ce qui peut être une contrainte

dans le cas d’évènements trop peu fréquents.

Interface série

Comme le nombre de sorties disponibles sur des connecteurs LEMOs était trop faible pour observer un nombre de signaux suffisant, cette interface a permis de corriger les erreurs existant dans les premiers développements sur l’interface USB. Une mémoire est remplie sur les fronts des impulsions de lecture et d’écriture dont le contenu est restitué en série. En observant à l’oscilloscope ces signaux de données ainsi qu’un signal impulsionnel repérant le début des mots, l’utilisateur peut récupérer le contenu de cette mémoire. Il lui reste alors à décoder les mots série pour en comprendre la signification. Cette fonctionnalité peut être utile dans d’autres circonstances.

La DAQ analogique

La gestion de la DAQ analogique comprend plusieurs fonctionnalités : selon le mode il est possible de piloter le registre à décalage de multiplexage des sorties analogiques des ASICs ou de laisser cette tâche à une acquisition externe. Le mode émulation permet de sélectionner une voie en particulier afin de pouvoir l’observer à l’oscilloscope.

2.3.4.7 Conclusions et discussion

Le code VHDL réalisé est donc générique selon le type de détecteur (longueur du registre de configuration, quantités de données à lire) et de FPGA (Xilinx, Altera). Ses paramètres sont regroupés dans un fichier d’entête afin de les regrouper. La manière d’aborder les différences entre FPGAs a été peu décrite. La principale caractéristique de la stratégie adoptée est d’isoler les parties du code spécifiques et d’y associer des fichiers séparés. Cela concerne la description des blocs à architecture optimisée comme les mémoires ou non décrite comme les DLL et DCM. Il est possible pour les premiers d’utiliser une manière de décrire qui permettent de cibler une architecture en particulier sans utiliser les modèles de boîtes noires fournis par les constructeurs, mais ce ne sera pas forcément le même type de code en fonction du constructeur et c’est impossible dans le deuxième cas. Il eut été simple de rendre générique également les paramètres de taille concernant les « accès registre ».

Cette manière de procéder peut avoir des limites en ce qui concerne les quantités de mémoire dans les FPGAs ou d’éventuels problèmes de vitesse si la fréquence d’horloge est trop différente de celle utilisée dans le projet initial.

L’USB semble limitant pour la vitesse d’acquisition vis à vis de ses temps d’accès. Une autre stratégie aurait sans doute pu fonctionner, qui aurait consisté à lire régulièrement les données contenues dans une FIFO au fur et à mesure de leur écriture, en mettant à jour leur nombre dans un registre. Mais cela aurait nécessité d’encapsuler les données afin de pouvoir reformer les trames, d’utiliser des caractères d’envoi direct (spécificité des FT245) et de coder les données pour éviter d’y trouver des occurrences de ces caractères et il n’est pas certain, du fait de la nécessité d’accès fréquents que le résultat aurait été plus satisfaisant.

La pulsation de l’alimentation des différents bloc des ASICs n’est pas implémentée pour le moment. Cette étude sera à faire dans un second temps. Les délais de mise en marche de chacune des parties concernées devront être évalués par l’observation de l’état de sorties significatives et les transitions d’état de la machine d’état devront les respecter, quitte à rajouter des états ou des délais pour les transitions à l’aide de compteurs. La partie digitale

doit nécessairement être remise à zéro après son allumage pour que les bascules se trouvent dans un état connu.

2.4

Logiciels de lecture des cartes DHCAL1

Des développements logiciels ont été effectués conjointement à celui du micropro- gramme pour réaliser le pilotage et la lecture des données de la carte DHCAL1 depuis un ordinateur. Une librairie de fonctions a d’abord été écrite qui donne des primitives d’accès direct à la carte et aux ASICs (cf. 2.4.1). Puis, une première interface en ligne de commande a été développée qui utilise ces primitives (cf. 2.4.2). Enfin, une interface gra- phique réalisée sous Labview faisant appel à la librairie sous forme d’un objet partagé est venue compléter l’environnement logiciel en fournissant un système d’acquisition cyclique indépendant et convivial (cf. 2.4.3).

Certains aspects généraux de l’interface logicielle vers l’USB (comme les délais d’exé- cution) de même que des aspects architecturaux ont déjà été abordés dans la section sur la schématique de la carte (cf. 2.3.2.3) ainsi que dans les sous–sections du microprogramme concernant la gestion des accès USB et le protocole d’échange avec le FPGA (en 2.3.4.3 et 2.3.4.4 respectivement), nous ne revenons donc pas dessus.

2.4.1 Bibliothèque d’accès commandes et registres

Une librairie logicielle (écrite en langage C) générique selon le type d’ASIC, associée à la librairie VHDL du microprogramme a d’abord été développée pour gérer les accès à la carte DHCAL1. Elle est nommée libROC50. Un fichier d’entête contient l’ensemble

des paramètres de la carte et des différents ASICs « ROC51» (nombre d’ASICs, taille du

registre de configuration et d’une trame de données, etc).

Cette librairie est conçue avec différents niveaux d’abstraction : une couche de gestion de l’USB qui gère l’interface avec la FIFO et son EEPROM de configuration (sous–section 2.4.1.1), une couche d’entrées/sorties qui comprend les interfaces avec des fichiers ou le ter- minal (sous–section 2.4.1.2), et une couche de plus haut niveau qui propose des commandes d’accès direct au FPGA ou aux ASICs (sous–section 2.4.1.3).

Le schéma 2.19 résume le principe de fonctionnement du pilote de la carte DHCAL1. Les flèches représentent les principaux axes de transfert de données : l’interface avec des fichiers à gauche, le passage par l’API52 constructeur pour atteindre le pilote matériel53

au centre et la couche protocole d’échange avec le FPGA et les ASICs sur la droite. 2.4.1.1 Accès USB

Le composant FTDI FT245BL est accessible par une librairie partagée nommée libftd2xx dont il existe une version sous linux. Sous WINDOWS™, elle est associée à un pilote ma- tériel qui prend en charge les accès USB par l’intermédiaire de l’agent d’ordonnancement

50. librairie pour les puces ROC

51. ReadOut Chip : dénomination donnée aux ASIC développés par le LAL pour les calorimètres de . 52. Application Programming Iinterface : interface de programmation applicative. Ensemble de fonc- tions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logi- cielle, un système d’exploitation ou un service.

53. un logiciel qui accède directement à un périphérique, par opposition à pilote virtuel (« hadrware driver » et « virtual driver » en anglais)

2.4 LOGICIELS DE LECTURE DES CARTES DHCAL1 65

Outline

Documents relatifs