From: "Olivier Callot" To: "'cyril drancourt'" Subject: RE : discussion CROP et carte commune Date: Wed, 22 Jan 2003 08:26:48 +0100 Message-ID: <004501c2c1e7$9fd7ee90$941c8d80@lal.in2p3.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3E2D6271.6080403@lapp.in2p3.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lappa0.in2p3.fr id IAA05897 Cher Cyril, Merci de ce document déraillé, mais il y a plusieurs contraintes sur la géographie des crates que tu ignores. La plus importante est que nous échangeons des informations entre cartes par le backplane des châssis pour former les informations de trigger de niveau 0. On échange 72 bits entre chaque carte et sa voisine. Il n'est donc pas possible d'avoir des cartes d'une même rangée verticale dans deux châssis différents. Ceci explique la topologie en bandes verticales. Essentiellement non négociable ! Il y a une autre contrainte pour la connection Ecal-Hcal pour les cartes de validation, qui contraint le groupement dans la zone centrale, en particulier l'endroit de la limite entre les cartes 8 et 9, limite pour les cartes de validation. La note LHCb 2002-015 résume les contraintes et donne ces raisons, un peu succinctement sans doute. Cependant, on peut se libérer de ces contraintes par la suggestion d'utiliser la même méthode que le trigger Muon présenté à Lyon, c'est à dire un patch panel pour regrouper différemment les cartes (fibres), libérant la géométrie pour le L1 common module. Ce que j'avais aussi découvert à Lyon, c'est qu'il n'est pas impossible, avec 24 sorties pour 16 cartes dans le CROC, de sortir la même information sur plusieurs fibres, et ainsi envoyer les voisins nécessaires sur la carte L1. Ceci permettrait d'éviter une liaison spéciale pour nous entre cartes L1. Mon scénario est donc proche de ton schéma 1. Je propose même de réduire à 2 cartes pour l'extérieur, chaque carte recevant 20 ou 22 cartes, plus 2 pour les voisins ( cartes 6 7 11 12 de ton schéma ). OK pour la zone moyenne. Pour la zone centrale, une seule carte L1 doit suffire, il y a 24 cartes front-end ! Ceci ferait donc 10 cartes pour Ecal. Pour PreShower et le HCAL, on ne fait pas de 2D, mais un processing d'une voie à la fois, indépendamment des voisins. Là, il faut maximiser le remplissage. Une carte L1 par région du Prs est OK, soit 6 cartes en tout. Pour HCAL, on peut avoir 4 cartes L1, mais on peut économiser une carte en groupant les parties extérieures droite et gauche, elles ont 11 cartes chacune. Mais ceci introduit un couplage droite gauche, le seul, et on peut vouloir garder cette séparation, utile durant la période de mise au point, pour pouvoir travailler sur deux problèmes HCAL en même temps. C'est juste une question de coût versus souplesse. Je suis bien sûr tout à fait prêt à venir discuter avec vous à Annecy. Cette semaine est impossible, la suivante tu es absent, et il faut sans doute avancer avant le workshop électronique. Ça laisse le 3 février! Et j'ai des réunions l'après-midi au CERN, donc il reste 10 heures du matin... On peut aussi voir ça après le Workshop, le vendredi 7. Olivier ----------------------------------------------------------------------------- Olivier Callot mailto:Olivier.Callot@cern.ch Expérience LHCb Tel: [41] 22 767 2335 Laboratoire de l'Accélérateur Linéaire CERN/EP bat.1-R-001 B.P. 34 Mailbox J06700 F-91898 ORSAY Cedex F-01631 CERN Cedex ----------------------------------------------------------------------------- -----Original Message----- From: cyril drancourt [mailto:cyril.drancourt@lapp.in2p3.fr] Sent: Tuesday, January 21, 2003 4:09 PM To: Olivier.Callot@cern.ch Subject: discussion CROP et carte commune Bonjour Olivier, ci-joint un fichier powerpoint décrivant la possibilité de prendre le "common L1 module" à la place du CROP. Bien sur, nous n'avons pas fait notre choix et ne pouvons pas le prendre seul. -Garder la CROP nous facilitera l'étude actuelle, l'assurance d'être le maître d'oeuvre de la carte, l'intérêt des domaines électroniques (programmation FPGA mais aussi conception de la carte et des interfaces CROC, CC-PC, DAQ). Il est raisonnable de projeter la réalisation de son prototype cette année. Il nous reste à bien cerner la mise en oeuvre des différentes interfaces. -Prendre le "common L1 module" favorisera la maintenance de la carte et le développement des différentes interfaces par des groupes dédiés (ECS,DAQ, TRIGGER). Nous n'aurons pas la maîtrise du planning. Une telle carte prendra certainement beaucoup de temps d'étude du cahier des charges. Le temps de réalisation dépendra des forces mise en oeuvre. Dans mon fichier attaché je n'ai voulu prendre en compte que la faisabilité technique en partant du design de Lausanne. Bonne Lecture, Cyril Drancourt. 04 50 09 16 08