Électronique du calorimètre hadronique semi–digital
2.4 LOGICIELS DE LECTURE DES CARTES DHCAL1 67 Listons maintenant les principales commandes existant :
– identification des cartes selon leur numéro de série (programmé au préalable dans l’EEPROM de configuration du composant USB).
– initialisation et configuration de l’accès USB.
– chargement et vérification de la configuration des ASICs. – « accès registre ».
– acquisition (démarrage, arrêt, contrôle du nombre de déclenchements et du statut). – lecture de données (démarrage, arrêt, contrôle du statut et de la quantité de données,
rapatriement de celles–ci vers l’ordinateur).
Chacune de ces fonctions utilise plusieurs des fonctions des couches de plus bas niveau. Détaillons à titre d’exemple le fonctionnement de celle qui permet de vérifier le contenu de la configuration des ASICs : la chaîne de configuration préalablement chargée dans le registre de configuration des ASICs est à nouveau mise en mémoire. Un octet de com- mande est ensuite envoyé au FPGA. À sa réception, il pousse les données hors du registre de configuration, les enregistre dans une mémoire, puis les recharge dans le registre de configuration. Ceci prend dans le cas de la carte DHCAL1 (le temps de traitement dans l’ordinateur est omis) :
t = ∼1 ms + 4 × 571/8 × 1 µs + 4 × 571 × 1.25 µs
(accès USB) (envoi des données par l’USB) (chargement local)
= ∼1 ms + 286 µs + 2.855 ms
= 4.141 ms
Ce temps pouvant varier selon les charges du processeur et de l’agent d’ordonnancement, nous accédons le registre de statut en attendant la fin de l’opération. Ceci fait, un octet de commande est envoyé au FPGA pour lui signifier que nous sommes prêt à réceptionner ses données. Il les envoie donc assorties d’un CRC qui nous permet de contrôler l’intégrité de la trame à réception et de l’indiquer par le mécanisme de gestion d’erreur.
Les fonctions proposées dans leur ensemble utilisent un « handle » pour désigner la carte et font donc appel aux fonctions USB adéquates (sous linux, il n’est plus possible de faire appel à la fonction qui liste les cartes connectées à l’ordinateur de pilotage après ouverture de l’une d’elles. Il n’est donc pas possible en cours de fonctionnement de récupérer l’« index » en fonction du « handle »).
2.4.2 Interface en ligne de commande
Une interface en ligne de commande a été développée pour fournir un accès simple au pilotage des cartes. Elle a été utilisée lors des tests sur table (cf. section 3.1) avant qu’une interface graphique soit accolée à la librairie.
Elle fournit un ensemble de fonctions dérivé de la librairie plus certaines facilités pour générer automatiquement des séquences d’appels de fonctions répétitifs, avec la gestion d’interactions avec l’utilisateur pour lui faire préciser la valeur d’un paramètre, l’informer sur l’entrée dans un mode de fonctionnement particulier, sur les valeurs de retour ou sur les temps d’exécution.
Afin de rendre cette interface plus conviviale, la librairie « GNU readline » a été ins- tanciée. Outre l’ensemble des fonctionnalités de base attendues d’une ligne de commande (position du pointeur de caractère, édition de la mémoire tampon de commande, gestion des interruptions, association de chaînes de caractères à des commandes), elle donne accès à la complétion automatique et à l’historique des commandes passées ainsi qu’à sa ma- nipulation. Dans notre cas, une complétion sur le nom de la commande est réalisée pour
le premier mot de la ligne, et une complétion sur le nom du registre dans le cas où la commande est identifiée comme une commande d’« accès registre ».
Pour permettre l’action sur plusieurs cartes de manière simultanée, la librairie Pthread a également été utilisée. Dévolue initialement à la réalisation d’une acquisition de données de plus grande envergure, elle a malgré tout permis d’instancier un fonctionnement paral- lèle des cartes, testé dans le cas d’un accès registre (demandes d’écritures et de lectures successives dans plusieurs cartes avec retours échelonnés selon les temps d’accès et contrôle des valeurs).
2.4.3 Librairie partagée pour pilotage sous Labview
Une interface graphique de gestion des cartes a été développée sous Labview à l’IPNL56
(R. Della–Negra), utilisant la librairie libROC. Cela a nécessité la compréhension des limites inhérentes à Labview, comme l’impossibilité d’allouer de la mémoire à sa place, l’obligation d’utiliser des types prédéfinis ou la manière d’effectuer les appels à une librairie externe.
La librairie a dû être adaptée pour supporter des accès dynamiques (dll57 sous WIN-
DOWS™ et so58sous linux). Elle a donc été modifiée pour être réentrante, à savoir accepter
plusieurs appels simultanés, ce qui implique entre autres de ne pas garder de variable sto- ckées en mémoire (comme les variables statiques) dont la valeur pourrait être différente d’un appel à l’autre.
J’ai participé à la réflexion de principe sur le schéma de l’acquisition, à l’intégration, au test de fonctionnement et à l’optimisation en temps des commandes sous Labview. Une première version d’acquisition tournante à donc été utilisée sur le banc cosmique (voir 3.2). Une deuxième version a été développée pour fonctionner avec la version de la librai- rie utilisée lors des tests en faisceau (voir 3.3). Outre la simplification des séquences de commandes, un fonctionnement multi–tâches a été mis en place.
2.4.4 Conclusion
Un système d’acquisition logiciel complet a été développé pour le prototype de calo- rimètre hadronique semi–digital, venant compléter son électronique. Différentes versions en sont disponibles : une « Single Slab DAQ » qui, associée à un microprogramme dédié, permet de tester une carte isolée de manière indépendante, également utilisée pour des tests avec des cosmiques, ainsi qu’une deuxième version, optimisée en vitesse, consacrée à des tests en faisceau.
56. Institut de Physique Nucléaire de Lyon : laboratoire de l’IN2P3.
57. dynamic loaded library : librairie logicielle à chargement dynamique, concept et objet WINDOWS™. 58. shared object : librairie logicielle partagée, concept et objet unix.