Proposition d’une nouvelle acquisition pour CTF3-CLIC partie CO. Jean Jacquemier, Yannis Karyotakis, Jean-Marc Nappa,, Jean Tassan, Sébastien Vilalte.

Présentation au sujet: "Proposition d’une nouvelle acquisition pour CTF3-CLIC partie CO. Jean Jacquemier, Yannis Karyotakis, Jean-Marc Nappa,, Jean Tassan, Sébastien Vilalte."— Transcription de la présentation:

1 Proposition d’une nouvelle acquisition pour CTF3-CLIC partie CO. Jean Jacquemier, Yannis Karyotakis, Jean-Marc Nappa,, Jean Tassan, Sébastien Vilalte.

2 15/10/2009Sébastien VILALTE2 Réseau: timing, mode de fonctionnement. Sujet commun BI-CO: ici réseau… p.11 Nécessité dans CTF3 pour l’instant de réaliser une acquisition synchrone avec la machine. → Nécessité de récupérer l’horloge machine au niveau de l’ADC (96MHz). Si acquisition pas synchrone: jitter d’un coup d’horloge des données à l’écran si toutefois le trigger se fait correctement (obligatoirement local si système asynchrone). Actuellement, le timing est distribué par lien cuivre aux châssis: clk 96MHz et trigger. Dans l’avenir, acquisition pas forcément synchrone. CTF3 ou CLIC: Données montantes : acquisition carte ADC. Données descendantes: consignes, timings si système synchrone. Après comparaison avec les autres solutions, la fibre optique semble la plus appropriée. Dans CTF3, nous connaissons des problèmes importants sur les liaisons cuivre. Avantages fibres: Distances importantes, débits possibles élevés, pas de perturbations de l’environnement.

3 15/10/2009Sébastien VILALTE3 Réseau: timing, mode de fonctionnement. Choix du réseau: p.12 Fibres monomodes: 1 fibre montante, 1 descendante. Les tests réalisés ont montré que nous pouvons transmettre l’horloge en imposant la fréquence porteuse sur la fibre. Le test a montré également que nous pouvons l’imposer en chainage également dans le but de développer de futurs switches de concentration de données. Qui peut le plus, peut le moins: cette solution pourrait basculer facilement (code FPGA) vers une solution réseau classique avec l’utilisation d’une horloge locale pour les ADCs (oscillateur implémenté sur carte).

4 15/10/2009Sébastien VILALTE4 Réseau: architecture. Choix du réseau: dans l’accélérateur. 2 architectures possibles: chainée ou en arbre. Avantage chainage: moins de câblage, plus simple. Inconvénient majeur: si perte d’un maillon, plus d’acquisition en dessous. Le protocole chainé sur des centaines de module est beaucoup plus gourmand en bande et plus complexe. La solution limitant le nombre d’étage de collection et donc assurant la fiabilité est celle de l’arbre. Avec une carte ADC unique par module (4X4 canaux), un switch local dans le crate n’est plus nécessaire. → réduction des couts: 1 seul FPGA, pas de câblage optique local. → réduction d’un étage de collecte du réseau. L’architecture en arbre permet également de développer un protocole maison simple: broadcast en flux descendant et point à point en flux montant. Ce réseau nécessite une carte de réception afin de récolter les données (pour un framework par ex.) et des switches de collection.

5 15/10/2009Sébastien VILALTE5 Réseau: architecture. Choix du réseau: White Rabbit en sortie. Les discussions avec WR nous ont permis de mieux comprendre comment intégrer le futur réseau du CERN. Nous pensons que le réseau local, jusqu’à la collection dans une machine type PC, doit être portée par un protocole synchrone propre à l’acquisition: → garantit la transmission du timing dans le cas d’une acquisition synchrone. → augmente la bande. → WR a de nombreuses fonctionnalités inutiles au crate. → implémentation lourde dans la carte ADC. Nous pensons donc qu’il faut développer un réseau local avec une carte de réception PCIe, lien entre les modules et le réseau externe. Cette PCIe devra ferait le pont vers le réseau externe WR (cf. proposition).

6 15/10/2009Sébastien VILALTE6 Réseau: architecture. Extrapolation CLIC: Débits: PIRE CAS… Typiquement, pour une fenêtre de ~250 échantillons, on peut estimer que les quatre canaux d’un bpm en raw data représentent un paquet de 20X250X4 bits (avec headers), soit 20kbits pour chaque bpm. Avec 4 ADCs quad par carte, le paquet total représente 80kbits pour chaque acquisition. Avec un rate machine maximum de 100Hz, le débit total d’un module représente 8Mb/s. Les données seront collectées et envoyées aux accès (puits). Pour une section de ~450 modules, la remonté des données peut être séparée en 2 groupes de ~225 crates: un de chaque coté de la section. La collection des données passe par l’utilisation de switches. Un calcul sur une section et les possibilités des FPGA permettent de fixer à 10 les collections pour 1 lien montant: compromis entre nombre d’entrées, nombre d’étages dans la ½ section, aspects techniques, cout… → Switch 10 vers 1.

7 15/10/2009Sébastien VILALTE7 10 10 modules ~225 modules 10 X25 switches 10 1 1 1 11 1 X3 switches White Rabbit network. PCIe board Extrapolation CLIC: Avec des étages de collection1 vers 10, 2 étages sont nécessaires pour collecter les données: 1 switch collecte 10 crates, on a besoin de ~25 switches pour la ½ section. À l’étage supérieur, on collecte ces 25 liens avec 3 switches. → 1 seul type de switch à développer. 2 PCIe. 2X28=56 switches par section. → 10X10X3X8Mbits/s=2,4Gbits/s! Réseau: architecture.

8 15/10/2009Sébastien VILALTE8 Un premier pas vers CLIC: Extrapolation avec technologies actuelles. Bien sur, évolutions dans l’avenir. Les directions à prendre sont: carte réception PCIe: permet de transmettre les données au framework (ex. FESA) et au réseau externe (WR). PCIe sera le futur standard, le front panel fixe les entrées-sorties. On peut implémenter 2 connecteurs SFP optiques (3,75Gbits/s), 1 RJ45 réseau (WR), 2 entrées analogiques (timings). Les gateways actuelles CTF3 possèdent les ports PCIe, les tests sont possibles dans l’accélérateur. carte switch: devra être autonome comme le châssis ADC. Le réseau local doit être souple et fonctionner quelque soit le nombre de niveau (point à point). Le Lapp a déjà les compétences en matière de switch « multiplexer ». Cette solution pourrait être implémentée dans sa version point à point dans CTF3: ~12 crates, 6 PCIe. L’installation pourrait par la suite évoluer avec l’installation de switches: CTF3 est une zone de tests évolutive pour le CLIC mais également pour son acquisition. Réseau: architecture.

9 17-18/10/2009Sébastien VILALTE9 Proposition: p.15 Carte réseau PCIe: → réseau local avec protocole propriétaire, lien avec futur réseau White Rabbit. → carte PCIe pour bus X8. → 2 liens optique monomodes. → 1 lien Ethernet/WR. → 2 entrées analogique timing. → développement software (FPGA, driver, framework…). Prototype prévu pour tests et debug: fin 2010. switch réseau: → 10 vers 1. → autonome. Prototype prévu pour tests et debug: fin 2011. Réseau: proposition.

10 15/10/2009Sébastien VILALTE10 Réseau: programme. Milestones Fin 2009: choix techniques, définition de la collaboration. Mi 2010: crate avec carte ADC, carte calibration, alimentations. Tests et debug avec carte évaluation PCIe. Fin 2010: carte réseau PCIe. Tests et debug de la chaine, tests dans CTF3. Pourrait remplacer l’acquisition de CTF3. 2011: switch réseau. Ressources LAPP : pour les développements à suivre, 3 hommes.an FTE, financement IN2P3 ~30k€/an. La demande d’un remplacement de l’électronique actuelle de CTF3 n’ira qu’en augmentant: grosses difficultés à maintenir le système dans une situation stable (réseau). → si système adéquat pour CTF3, nécessité de le produire rapidement.