Speaker
Description
An overview of the electronics readout/trigger architecture for the CMS HGCAL will be given. To respond to physics performance requirements, data rates, trigger-primitive generation and radiation tolerance has been extremely challenging. Each HGCAL endcap includes ∼300m² of active silicon in 50 layers, with a largely inhomogenous layout with limited commonality between layers. An agile, python-based counting scheme was implemented that creates tables of component counts. These are subsequently incorporated in the architecture specifications document and costbook, providing critical input to the mechanical design and integration optimisation.
Summary (500 words)
The CMS High Granularity CALorimeter (HGCAL) project is in the process of designing two identical endcaps to be installed as part of the phase 2 upgrades of the CMS detector. The architecture is based on a sampling calorimeter with 50 active layers. These are instrumented with silicon diode pads in the electromagnetic region (CE-E), which runs from layers 1-28 inclusive, and a mixture of silicon and plastic scintillator tiles instrumented with on-tile SiPMs in the hadronic region: layers 29-50 (CE-H). There are two diode pad size variants and 3 doping layer thicknesses. The absorber is a mixture of lead, copper, tungsten and steel giving a total weight of nearly 250 tonnes per end-cap. The requirements are legion and impose demanding and sometimes conflicting constraints on the design of the read-out electronics. These include, but are not limited to: an intense and non-uniform radiation environment; highly non-uniform data rates: very high at high η to moderate at low η; Trigger Primitive Generation; tightly limited Z space; 10s of ps (RMS) shower time resolution; and a detector envelope that varies with Z and hence layer. The baseline architecture that attempts to respond to as many of these as possible is somewhat inhomegeneous. A description will be given along with the main motivations for some of the key design choices that attempt to simplify this architecture by concentrating some of the complexity into key components with the goal of reducing the design effort required, as well as the production testing by reducing the number of complex variants. Despite this focus, a large number of variants exists in the baseline design. A software tool was written in python that reads the architecture description and, running through all these variants, produces component count tables that feed into the project cost book and part provisioning. Additional outputs are also programmed in that facilitate the mechanical design and integration, power cable and read-out fibre routing and channel mapping. The ethos behind this approach is to be able to more easily understand the importance and consequences of changes in the baseline architecture during the detector optimisation phase.
