<table><caption>Table 7.1: Specifications of the HGTD sensor wafer UBM.</caption><tr><td>Wafer material</td><td>Silicon</td></tr><tr><td>Wafer thickness</td><td>300 µm</td></tr><tr><td>Sensor size (R×C)</td><td>20.1 × 39.6 mm² (15×30)</td></tr><tr><td>Distance between pads</td><td>1.3 mm</td></tr><tr><td>Pad size (passivation opening)</td><td>90 µm</td></tr><tr><td>Pad metalization</td><td>Aluminum</td></tr><tr><td>Scribe line passivated</td><td>Yes</td></tr><tr><td>Baseline UBM process</td><td>Electroless Ni/Au</td></tr></table>

ASIC wafers. As mentioned above electroless Ni/Au deposition is selected as the baseline process for UBM, while solder bumps composed of SnAg (SAC305) would be deposited through a laser solder jetting system. However, other procedures can be considered. Table 7.2 summarizes the requirements for the UBM and bumping of the HGTD ASIC wafers.

<table><caption>Table 7.2: Baseline specifications of the HGTD ASIC wafer UBM and solder bump deposition. Other UBM and bumping process will be studied.</caption><tr><td>Wafer material</td><td>Silicon</td></tr><tr><td>Wafer thickness</td><td>300 µm</td></tr><tr><td>ESD sensitive</td><td>Yes</td></tr><tr><td>Passivation</td><td>8750A SiO<sub>2</sub></td></tr><tr><td>ASIC size (rows×columns)</td><td>21.7 × 19.9 mm² (15×15)</td></tr><tr><td>Distance between pads</td><td>1.3 mm</td></tr><tr><td>Pad size (passivation opening)</td><td>90 µm</td></tr><tr><td>Pad metalization</td><td>Al</td></tr><tr><td>Baseline UBM process</td><td>Electroless Ni/Au</td></tr><tr><td>Solder bumps</td><td>SnAg (SAC305)</td></tr><tr><td>Baseline bumping process</td><td>Laser solder jetting</td></tr><tr><td>Bump shear strength</td><td>40 gf/bump</td></tr></table>

After UBM and bump deposition the sensor and ALTIROC wafers will be diced. The width of the scribe line shall be 20 µm and the dicing precision ±10 µm. Break offs at the dicing edge shall be limited to less than 75 µm.

The flip-chip process is the final step in the hybridization procedure. The flip-chipping will be done on single sensor tiles. Two ASICs have to be flip-chipped to a sensor. The cycle has to be consistent with the SnAg solder bumps and result in a high hybridization yield. Table 7.3 summarizes the flip-chip requirements for the HGTD modules.

Requirements in the specifications have been fulfilled in small module prototypes with 5 × 5 pad sensors as shown in Section 7.2.2. Full-size bare module prototyping will be carried out to demonstrate the requirements can be met in the final design with 15 × 30 pad sensors.
## 7 Module Assembly and Loading

<table><caption>Table 7.3: Specifications of the flip-chip process for the HGTD modules.</caption><tr><td>Alignment between ASIC and sensor in X-Y plane</td><td>5 µm</td></tr><tr><td>Minimum distance between ASIC and sensor after flip-chip</td><td>20 µm</td></tr><tr><td>Maximum distance between ASIC and sensor after flip-chip</td><td>50 µm</td></tr><tr><td>Maximum failure rate per ASIC</td><td>0.044%</td></tr><tr><td>Shear strength after flip-chip</td><td>40 gf/bump</td></tr></table>

### 7.2.4 Quality assurance / quality control

Modules will be tested according to the specifications. Bare modules will be optically inspected and weighed. The distance between the substrates (bump height) will also be measured. Inspection with x-rays for disconnected channels before module assembly (dressing with the flex hybrid) will follow. If the yield of the bump-bonding process is found to be high after the initial production and the modules are found to be highly uniform, these time consuming steps (x-ray inspection and substrate separation) can be performed only on a small fraction of devices. Note that the channel connectivity will be anyhow tested during the module electrical tests. A small number of ASICs will be sacrificed to test the bump quality with shear tests before flip-chipping. Furthermore, a small number of devices will be tested destructively to verify the robustness of the hybridization process. Burn-in tests will be carried out on some devices to test specifically for the degradation of the module.

### 7.2.5 Production hybridization strategy

The total surface covered by the HGTD (6.4 m²) requires a well planned approach to successfully carry out the hybridization of all the modules. The three step hybridization strategy consists of: process R&D and specification, search and qualification of bump-bonding vendors with full sized ASICs, and finally, module hybridization pre-production.

As presented above, the baseline bump-bonding process has been developed and successfully tested, both in Institutes and companies. Initial specifications have been established. Full size tests will be carried out as soon as the final sized sensor and ASIC become available. The specifications have already been provided to two companies (one in Germany and one in China) and discussions of an early qualification of the bump-bonding process with the currently available devices (ALTIROC1) was carried out in China. Both companies have expressed their willingness to carry out the hybridization service for HGTD and can do the full process in-house (metalization, bump-deposition, dicing and flip-chip). The estimated time for the hybridization process (sensor UBM, ASIC bumping and flip-chipping) for the full HGTD production in either company is only about 3 months. The target is to carry out the final hybridization qualification with two or more companies when the ALTIROC2 is available.
### 7.3 Module design and assembly

#### 7.3.1 General description

##### Baseline module design

The bare module described above is glued with accurate positioning to a small flexible printed circuit board (the module flex), to which a long flex cable (called flex tail in the following) will be connected during detector assembly (see Section 13.1). A more detailed technical drawing of the full module can be found in Figure D.1 and Figure D.2. ASIC signals and low voltage, as well as bias voltage for the sensor (HV) will be connected to the module flex by wire bonding. The flex tail with a length up to 69 cm connects, via two connectors, the module flex to one peripheral electronic board. Figure 7.7 shows three modules with the components stacked in the z direction of the HGTD. The total thickness of a module, including ASIC, sensor and module flex with all components and connectors, is 3.25 mm, with the contributions of each element listed in Table 7.4. To allow for some tolerance, the maximally allowed total thickness for the module package is 4.2 mm (see Table 11.1).

<figure><img src="image_118.png" /><figcaption>Figure 7.7: Schematic drawing of two adjacent modules on the top side and one on the bottom side of the cooling plate. A more detailed technical drawing of the full module can be found in Figure D.1 and Figure D.2.</figcaption></figure>
## 7 Module Assembly and Loading

<table><caption>Table 7.4: Contribution of each module component to its thickness.</caption><thead><tr><td>Component</td><td>Thickness [mm]</td></tr></thead><tbody><tr><td>ASIC</td><td>0.30</td></tr><tr><td>Bump bonding</td><td>0.05</td></tr><tr><td>Sensor</td><td>0.30</td></tr><tr><td>Glue</td><td>0.10</td></tr><tr><td>Module flex</td><td>0.50</td></tr><tr><td>Connector</td><td>2.00</td></tr><tr><td>Total</td><td>3.25</td></tr></tbody></table>

<table><caption>Table 7.5: Type and number of signal lines for two ASICs and one sensor included in the flex cable design</caption><thead><tr><td>Signal name</td><td>Signal type</td><td>No. of wires</td><td>Requirement</td></tr></thead><tbody><tr><td>HV</td><td>800 V max.</td><td>1</td><td>Clearance</td></tr><tr><td>POWER</td><td>1 × Vdda, 1 × Vddd, 1.2 V</td><td>2</td><td>2 planes, R < 2.7 mΩ cm<sup>-1</sup></td></tr><tr><td>GROUND</td><td>Analog, Digital</td><td>2 planes</td><td>Dedicated layer<br>R < 0.7 mΩ cm<sup>-1</sup></td></tr><tr><td>Slow control</td><td>Data, Ck (opt. + rst, error)</td><td>2 to 4</td><td>I<sup>2</sup>C link</td></tr><tr><td>Input clocks</td><td>320 MHz, Fast command e-link<br>(opt. 40 MHz (L1))</td><td>4 or 8</td><td>CLPS</td></tr><tr><td>Data out lines</td><td>Readout data (TOT, TOA, Lumi)</td><td>4 pairs</td><td>4 e-links differential CLPS</td></tr><tr><td>ASIC reset</td><td>ASIC_rst</td><td>1</td><td>Digital</td></tr><tr><td>Monitoring</td><td>Temperature, V_dda, V_ddd</td><td>4</td><td>DC voltage</td></tr><tr><td>Debugging</td><td>ASIC_debug</td><td>2</td><td>Analog</td></tr></tbody></table>

### Alternative module design

In addition to the development and test of the baseline design, alternative options are being investigated, in particular with the aim of replacing wire bonding with mechanically more robust solutions. In particular the usage of conductive glue for the connection of the HV line to the sensor and of bump bonds to connect all signal and power lines between the module flex and the ASICs is being studied and prototypes are in preparation.

### 7.3.2 Voltage distribution and signal readout: flex cables

Two cables based on the flexible electronics technology, a module flex and a flex tail (see Figure 7.7), will connect the signals from each bare module to the peripheral electronics board. The geometrical constraints on the flex tails are determined by the available space between two layers (see Table 11.1), the distance between the modules and the peripheral electronics and the maximum number of modules per readout row. Considering the harshest
constraints, the module flex plus the flex tail must have a maximum length of about 690 mm, width of at most 36 mm, and thickness of less than 220 µm. The total length of flex cables in the HGTD, including both module flexes and flex tails, is 3000 m.

In terms of electrical requirements, one HV line has to be included in the design in order to bias the LGAD sensors (800 V maximum). The HV line must have a sufficient insulation resistance (IR) to not affect the other lines (IR > 10 GΩ). The types of signals to and from the ASICs in each flex cable include the transmission of high speed signals (1.28 Gbit s⁻¹) as well as clock and power signals. The total numbers of signal lines for each module are listed in Table 7.5.

The mean impedance along the lines for all flex tail lengths is required to be in the range of 90 Ω–120 Ω for the differential pairs and of 50 Ω–65 Ω for the single lines. The impedance of the ASIC pins can be adapted according to the impedance of the tracks in order to minimise signal reflections. The impedance variation between the lines of the same flex is much smaller than the expected difference for the flexes of different lengths according to the results of the measurements shown later in this section. The same radiation tolerance is required as for sensors and ASICs, i.e. up to at least 2.0 MGy, as well as operation at a temperature of about –30 °C (see Section 7.5).

A module flex with a width of 39.5 mm and a length of 18.5 mm along the readout row has been produced as a 4-layer stack-up with a thickness of 500 µm. A design of the module flex is being developed based on the ALTIROC2 pinout and design. Two connectors, suitable for the connection of the flex tail, as well as surface mount components are considered. The schematics of the module flex prototype design can be found in Figure D.3. The flex tail is a 2-layer cable to be produced with different lengths, 220 µm thickness and a width of 36 mm. A preliminary layout of the flex tail is shown in Figure 7.8. A prototype of the flex tail has been ordered, while the design of the module flex is being finalised.

Two separate connectors, one specific for HV of the sensor and the other for all the signal lines to the ASIC, will be used to connect the module flex to the flex tail and transmit the signals to the peripheral electronics boards. The Hirose DF26 series provides good candidates from the geometrical and electrical point of view. The exact specifications on the maximum pressure that can be applied on the connector without damaging the modules and on the robustness against several connections and disconnections depend on not yet finalised details of the detector layout and qualification procedure.

To allow for the thermal expansion of the flex tails without mechanical stress on the module, studies on the possibility to place the connectors between two adjacent modules are being performed. This will allow for some bowing of the flex tail and some movement of the non-glued part of the module flex, taking advantage of the tolerance between the expected total thickness of the module (see Table 7.4) and the allocated space for it (see Table 11.1). Simulations will be used to study the expected behaviour of the flex tails as a function of temperature and tests will be performed with the demonstrator (see Chapter 14).
# 7 Module Assembly and Loading

In the baseline design, the functionality of the flex tail for up to six modules per readout row in the outer ring (2688 flex tails in total) will be integrated directly in the PEBs, while the remaining 5344 flex tails will be connected singularly to the PEBs with a connector for HV and one for all the other lines (see Figure 9.8).

The specifications of the module flexes and flex tails are summarized in Table 7.6. Most of them are common to both kinds of flex cables, the specific ones are indicated explicitly.

<table><caption>Table 7.6: Specifications of the flex cable.</caption><tr><td>Tolerance in length</td><td>1 mm</td></tr><tr><td>Tolerance in width</td><td>100 µm</td></tr><tr><td>Flex tail maximum thickness</td><td>220 µm</td></tr><tr><td>Module flex maximum thickness</td><td>500 µm</td></tr><tr><td>Insulation resistance of HV line</td><td>10 GΩ</td></tr><tr><td>Maximum resistance of power planes</td><td>2.7 mΩ cm<sup>-1</sup></td></tr><tr><td>Maximum resistance of ground planes</td><td>0.7 mΩ cm<sup>-1</sup></td></tr><tr><td>Impedance of single lines</td><td>50 Ω–65 Ω</td></tr><tr><td>Impedance of differential lines</td><td>90 Ω–120 Ω</td></tr><tr><td>Maximum allowed BER</td><td>10<sup>-12</sup></td></tr><tr><td>Radiation tolerance</td><td>2 MGy</td></tr><tr><td>Neutron fluence</td><td>2.5x10<sup>15</sup>neq/cm<sup>2</sup></td></tr></table>

<figure><img src="image_119.png" /><figcaption>Figure 7.8: Layout of the FLEX tail two-layers design prototype. (a) Top (gold) and bottom (green) layer view of the connection region of the prototype to the adapter board used to inject signals simulating the ones from the module. Two separate connections are foreseen: Zero Insertion Force type on top and a through-hole type on bottom for HV. (b) Top (gold) and bottom (green) layer view of the testing region of the prototype footprints for components are included for tests.</figcaption></figure>

## Prototype characterisation

As part of the initial study phase, before defining the current baseline design, a prototype combining module flex and flex tail into one L-shaped 4-layer design has been produced
with the aim to understand the technical requirements, such as materials, manufacturing capability, electrical and mechanical robustness, and to address any potential problem by representing a significant subset of the signals (signal integrity, power distribution, HV insulation, interference and crosstalk). The design used for this prototype is considered inconvenient for assembly and will therefore not be further considered, however the obtained results are expected to not depend significantly on the details of the shape and design of the flex cable. The direct interaction with the CERN PCB Service allowed optimisation of the manufacturing process leading to the production of four prototypes of 750 mm length as depicted in Figure 7.9. Upilex-VT from UBE Industries was the commercial dielectric material chosen for this prototype. The length was chosen based on a previous version of the detector layout and it is 6 cm longer than the longest flex tail to be produced for the HGTD.

<figure><img src="image_120.png" /><figcaption>Figure 7.9: A 4-layer flex cable prototype from CERN PCB Service. (a) Top view. (b) Assembled extremity.</figcaption></figure>

The stack-up of the cable has layers numbered 1 to 4 from top to bottom. On the top layer the single lines are routed following a micro-strip configuration. The differential pairs as well as the HV line are placed in layer 3 in a stripline configuration in order to improve the shielding of these lines. Layers 2 and 4 are full planes dedicated to powering and grounding. In order to perform the electrical tests the four flex cables have been assembled with all the foreseen components.

The qualification of the flex cables has been performed both at room temperature and in a climate chamber reproducing the operating conditions of the HGTD in terms of temperature (see Section 7.5), yielding very similar results.

The final production of flex cables will be performed in the industry. In order to verify the quality of industry product, 40 L-shaped 4-layer design flex cables have been fabricated by Shennan Circuits company in China with all components assembled, as shown in Fig. 7.10.

<figure><img src="image_121.png" /><figcaption>Figure 7.10: A 4-layer flex cable prototype from Shennan Circuits company in China</figcaption></figure>
## 7 Module Assembly and Loading

**Geometrical tests** The thickness and the width of the flex cable must be uniform along its length to assure the proper assembly of the full detector according to the requirements in Table 11.1. Several measurements of the thickness and width of the cables were performed with a caliper every 5 cm. The mean values and standard deviations of the measurements are shown in Table 7.7. The spread of the values is well within the tolerance and the length and width average values are compatible with the nominal ones (see Table 7.6). A smaller thickness than the nominal one is acceptable from a mechanical point of view, as long as the electrical properties are not affected.

<table><caption>Table 7.7: Mean values and standard deviation of the measured length, width, and thickness for three long flex cables. Nominal refers to the now outdated specifications used for the design of the tested prototype.</caption><thead><tr><th></th><th>Length [cm]</th><th>Width [mm]</th><th>Thickness [µm]</th></tr></thead><tbody><tr><td>Nominal</td><td>75</td><td>18</td><td>340</td></tr><tr><td>Measured</td><td>75.0 ± 0.2</td><td>17.99 ± 0.04</td><td>300 ± 9</td></tr></tbody></table>

**Power integrity** A simulation of the voltage drop in each plane was performed with the Cadence Allegro Sigrity PI software package [81] and the expectation for the longest CERN prototype (750 mm) was estimated and compared with multimeter measurements (see Table 7.8). The uncertainties on the simulation values reflect the uncertainty on the thickness of the layers in the production process as indicated by the CERN PCB design service, while the measurement uncertainty is given by the spread of the measured values from the available prototypes. Similar simulations for the current baseline design of the flex tail (also shown in Table 7.8) are well within specifications for all power and ground planes.

<table><caption>Table 7.8: Simulated and measured resistance of the analog and digital power and ground planes for the CERN prototype (75 cm length). Simulated resistance for the baseline design of the flex tail (69 cm length)</caption><thead><tr><th>plane type</th><th>CERN sim. [mΩ cm<sup>-1</sup>]</th><th>CERN meas. [mΩ cm<sup>-1</sup>]</th><th>tail baseline sim. [mΩ cm<sup>-1</sup>]</th></tr></thead><tbody><tr><td>analog power</td><td>1.6 ± 0.1</td><td>2.0 ± 0.1</td><td>1.3</td></tr><tr><td>digital power</td><td>0.30 ± 0.01</td><td>0.4 ± 0.1</td><td>1.7</td></tr><tr><td>analog ground</td><td>1.5 ± 0.1</td><td>1.70 ± 0.03</td><td>0.5</td></tr><tr><td>digital ground</td><td>0.30 ± 0.01</td><td>0.35 ± 0.03</td><td>0.5</td></tr><tr><td>length [cm]</td><td>75</td><td>75</td><td>69</td></tr></tbody></table>

Considering the results in Table 7.8, the simulation is reliable within 30%. The differences between the analog and digital planes in the CERN flex prototype are due to the choice to consider a lower number of analog signal versus digital lines. Therefore, the surface of the power and ground analog planes is smaller than that of the digital ones leading to a larger resistance. In the flex tail baseline design the total number of signals listed in Table 7.5 were
considered. The ground planes are designed symmetrical and placed in a dedicated layer. The power planes are placed together with the rest of the lines in a dedicated layer. The number of digital signals is higher than the number of analog signals, leading to less space available for the digital power plane and consequently to a slightly higher resistance than for the analog one. Simple geometrical calculations easily reproduce the ratio of resistances.

For the total power consumption estimation, the total length of the flex tails in addition with the 2 cm length of the module flex was considered. The same resistance is assumed for the flex tail and for the module flex and set to the maximum allowed values from Table 7.5, including additional resistance from the connections between the two parts. This estimate is higher than the current simulation results, because the simulation does not include the connection between module flex and flex tail and to allow for a possible mismatch between the simulation and the actual measured resistance. The total power consumption estimated is 2 kW over the whole detector (see Table 11.2).

**Insulation test** The insulation of the flex materials was checked for voltages up to 1 kV with the CAEN DT5521HEN HV power supply [82] that can measure currents as small as 500 pA. Since no current was observed over a long time, a lower limit was set on the insulation resistance at 2000 GΩ, well above the requirement. For this test no signals were injected in any of the lines of the flex cable. The possible interference between the HV and the other lines has been tested. The bit error test, described below, as well as the eye diagrams performed with 1.25 Gbit s⁻¹ signal transmission did not show difference while the HV was delivered (1 kV at 1 mA). Two flex cables were stacked while a 1.25 Gbit s⁻¹ signal was transmitted in one of the cables and HV was delivered through both. No errors were observed during the bit error tests. Eye diagram results were not affected by the HV delivery.

**Time Domain Reflectometry** The Time Domain Reflectometry (TDR) test is performed in order to check the impedance homogeneity of the tracks, which is crucial for high-speed data transmission. Three assembled flex cables were used to measure in each one three differential pairs (one dedicated to clock transmission, two for e-links) and two single lines that are accessible from a custom adapter board that was designed for the purpose of these tests. The TDR module 80E08 together with the DSA8200 oscilloscope by Tektronix [83] was connected through SMA connectors to the adapter board. The impedance of the lines was measured and compared with the impedance estimated from simulation. For all the measured lines the mean impedance along the cable is found to be well within the specifications for the foreseen lengths up to 69 cm (see Figure 7.11). Assuming perfect linearity and approximating the mean value over the cable length by the measurement at a distance of 34.5 cm, the observed range of impedances is about 58 Ω–61 Ω for single lines and 105 Ω–108 Ω for differential pairs.
<figure><img src="image_122.png" /></figure>

<figure><img src="image_123.png" /></figure>

Figure 7.11: Impedance results for the single lines (a) and the differential pairs (b) for the CERN prototype (75 cm length). The vertical grey line indicates the length of the longest flex tail for the current detector baseline.
**Integrated Bit Error Test (IBERT) and eye diagrams** To emulate the signals from the ASIC an FPGA on a Kintex KC705 evaluation board [84] has been programmed and connected to the flex cable via the adapter board also used for the TDR measurements.

The FPGA injects test patterns at 1.25 Gbit s⁻¹ and checks the response with the Integrated Bit Error Rate Test (IBERT). The SMA connectors placed on the adapter board route the signals to the oscilloscope for classical eye-diagram analysis. A wire bond between two differential pairs at the end of the flex cable creates a loopback path for the signals. Therefore, the transmission length of the signals is twice the length of the cable, 150 cm. The test configuration and the I/O drivers are compatible with the VC707 FPGA used by the lpGBT system. In this way we ensure the same conditions as for on-field operation.

The IBERT detected no errors over a few days, yielding a limit at 95% confidence level on the error rate for one of the flex cable prototypes at 1.25 Gbit s⁻¹ with BER less than $1 \times 10^{-15}$. This value is much better (lower) than the acceptable error rate of $1 \times 10^{-12}$ (see Table 7.6).

The same test was repeated with the HV up to 1000 V at 1 mA and showed no error for eight days at room temperature and at -30 °C. The BER result obtained during this test was no more than $1 \times 10^{-15}$ at room temperature and $2 \times 10^{-15}$ at -30 °C at 95% confidence level. The Kintex KC705 evaluation board encodes the signals at the receiver after an equalization stage. The signals were measured prior to the equalizer by an oscilloscope. The signal amplitudes range from ±100 mV to ±200 mV. The eye diagrams in Figure 7.12 measured without HV (a) and with HV (b) show a similar shape and opening area. The opening areas for both eye diagrams are larger than the no error accepted area indicated by the mask. Tests over higher currents and while delivering Low Voltage (LV) are ongoing.

**Quality assurance / quality control and production strategy**

The set of tests described above constitutes the baseline procedure for quality control of the all the flex cables (module flexes and flex tails) during production. However, since some of the measurements (e.g. IBERT) are time consuming and some of them are only relevant for one type of cables, the option of performing them only on a limited fraction of the produced pieces will be considered if a low failure rate has been established. All electric tests will be performed in a climate chamber reproducing the operating temperature of the HGTD (about -30 °C, see Section 7.5) and under controlled humidity conditions. Radiation tolerance will only be tested on a small fraction of flex cables that will not be usable for assembly afterwards.

The design of both flex cable types will be finalized after testing them connected to the ALTIROC2 in the demonstrator described in Chapter 14. Companies that are expected to be able to produce small 4-layer flexible PCBs and to perform the assembly of all necessary components and connectors in house are being contacted, as well as those who can produce long 2-layer flex cables within the specifications listed in Table 7.6 are being contacted and
## 7 Module Assembly and Loading

<figure><img src="image_124.png" /><figcaption>Figure 7.12: Eye diagrams for the flex cable prototype from the CERN PCB service. (a) $HV = 0$ V (b) $HV = 1$ kV. The solid line indicates the mask in which no errors are acceptable, the dashed line the marginal region in which few errors can be tolerated.</figcaption></figure>
the production should be ideally shared among a few of them that can provide the same quality of cables. The plan is to involve them early on in the prototyping phase so that they can contribute to the design optimizations specific to their manufacturing process.

For the module flexes the PDR is foreseen in Q2 2022, followed by the FDR in Q3 of the same year. The pre-production will take place between October 2022 and February 2023 and the production from July 2023 until April 2024. The design of the flex tails will be finalised on a similar timescale (PDR Q2 2022 and FDR 2023), while the pre-production and production will take place somewhat later to reduce overlap, while being ready in time for detector assembly at CERN. The pre-production is foreseen between March and November 2023 and the production from March 2024 until September 2025 (see Figure 15.6).

After the tests performed at the Institutes, the module flexes will be glued and wire bonded to the bare module (see Section 7.3.3), while the flex tails will be shipped directly to CERN to be connected during the detector assembly (see Section 13.1).

### 7.3.3 Gluing and wire-bonding

The assembly and interconnection of the bare module with the flex cable results in the HGTD module. The steps involved in the assembly process are the following:

* Cleaning and preparation of the flex and bare module

* Gluing of the flex on the bare module

* Wire-bonding

* Inspection, quality control and documentation

These steps are discussed in more detail below. Assembly of modules will be done in several Institutes. The HGTD modules assembly procedure will be as uniform as possible among the sites, though some differences, mainly coming from diversity of the equipment, will have to be accounted for. The prescription for the assembly will guarantee the respect of the module specifications.

This facilitates the definition of the assembly procedure and increases yield. However, the details of the assembly procedure might differ between assembly sites, mostly in the gluing step, due to the availability of specialized equipment in the different Institutes (dispensing and pick-and-place machines, for example). All module assembly and testing will take place in a clean environment equipped with temperature and humidity control and ESD protection. Specification for this environment will be developed and critical steps shall take place inside clean rooms. A database will be used to record the status of each module at every step of assembly. Electrical test results will also be added to the database. Given the number of modules needed for the HGTD, several sites are foreseen to be qualified for the
## 7 Module Assembly and Loading

module assembly activities. To ensure uniform high quality in the module assembly process the sites will be asked to pass a site qualification stage.

Initially the flex cables and the bare modules will be optically inspected for damage and anomalies. Components will be weighed and the surfaces where the adhesive will be deposited will be cleaned. Bare modules and flex circuits will be mechanically joined using a dedicated adhesive. Several adhesives are currently being studied, for robustness, radiation hardness and other practical advantages (curing time, viscosity, etc). The baseline solution would be to use the same adhesive used in the ITk Pixel detector (Araldite 2011). Different options are available to carry out the gluing process. However, all assembly methods will be ensured to produce modules to the same specifications.

One method to mechanically join the flex cable to the bare module relies on a pick-and-place machine, which typically achieves positioning accuracy of ~ 10 µm, and exists in a variety of automation options (from mostly manual to fully automated). Pre-tested components (flex cable and bare module) are loaded by vacuum tools of the machine. The operator then aligns the components through fiducials in the module (on the ohmic side of the sensor) and flex, visualized simultaneously in the machine monitor screen, and applies manually, or through a dispensing arm or stamping tool, the adhesive to the bare module and/or flex cable. The flex is then placed on top of the bare module (or the bare module is placed on top of the flex) and held in position until the adhesive is sufficiently cured.

An alternative process relies on custom made jig gluing tools instead of the pick-and-place machine. As shown in Figure 7.13, the tool consists of two aluminum jigs, each consisting of a vacuum chamber to hold the bare module and the flex, respectively, at fixed positions and then the adhesive is applied. The vacuum pressure is applied through holes in exchangeable inlays with a shape adapted to the electrical components on the top side of the flex. In order to guarantee the correct alignment between the inlays in x and y directions, three dowel pins are used in each jig before the guide pins, and the body is adjusted with precision screws. Positioning accuracy of ~ 100 µm is achievable with this method. The distance in the z direction can be adjusted in the tooling to allow variation in the amount of glue.

Following mechanical assembly, the front-end chips and the sensor bias voltage are electrically connected to the flex circuit through 25 µm diameter aluminium wire bonds using an automated ultrasonic wedge bonder. Wire-bond quality will be checked routinely through pull tests of sample wire bonds using a pull tester machine. Visual inspection of the wire bonds will also be performed. Figure 7.14 shows an assembled ALTIROC1 device and the pull testing procedure.

### 7.3.4 Specifications, quality assurance / quality control

The bare modules and flex cables that fulfil all their respective requirements will be used for the next steps in the module assembly, i.e. gluing and wire bonding. The specifications
<figure><img src="image_125.png" /><figcaption>Figure 7.13: The design of custom made jig gluing tools.</figcaption></figure>

for this stage are aimed at ensuring the mechanical stability of the assembled module, see Table 7.9. These need to be combined with the requirements in terms of efficiency, response and number of working channels defined for the sensors and that are valid also for the assembled module.

After assembly all modules will be optically inspected and weighed, and their metrology recorded in the database. As mentioned above, wire-bond pull tests will be carried out periodically on a fraction of modules to ensure robust connectivity. All modules will be tested for ASIC communication, current-voltage behaviour and response to a radioactive source using a lightweight table top DAQ system. Short burn-in tests, where the modules are operated continuously for a day are foreseen. Furthermore a small fraction of the modules will be subjected to long-term burn-in tests where the devices will be thermal cycled while
## 7 Module Assembly and Loading

<figure><img src="image_126.png" /><figcaption>Figure 7.14: Photo of a mounted ALTIROC1 device being tested (left) and the measured wire strengths (right).</figcaption></figure>

<table><caption>Table 7.9: Specifications of the gluing and wire bonding processes.</caption><tr><td>Radiation tolerance</td><td>2 MGy</td></tr><tr><td>Neutron fluence</td><td>2.5x10<sup>15</sup>neq/cm<sup>2</sup></td></tr><tr><td>Lap shear force</td><td>5 MPa</td></tr><tr><td>Push-off strength</td><td>10 MPa</td></tr><tr><td>Wire bond pull force</td><td>8 gf</td></tr><tr><td>Positioning accuracy</td><td>100 µm</td></tr></table>

being operated.

### 7.3.5 Production strategy for flex cables and module assembly

The flex cable design will be finalized after testing it connected to the ALTIROC2 in the demonstrator described in Chapter 14. Companies that are expected to be able to produce long flex cables within specifications are being contacted and the production should be ideally shared among a few of them that can provide the same quality of cables. The plan is to involve them early on in the prototyping phase so that they can contribute to the design optimizations specific to their manufacturing process.

The module assembly production, including inspection of parts, gluing, wire bonding and testing of the modules, will be shared among several HGTD Institutes, with the target production rate of four modules per day per institute. Institutes module assembly qualification procedure will be defined to ensure that all sites uniformly produce modules according to specifications. A minimum set of equipment will be required (for example, wire-bonding and pull and shear machines) as well as a clean environment and minimum throughput capacities.
After the prototyping phase is completed, and the first full sized (ALTIROC2) modules are produced, the module assembly PDR will be submitted in Q2 2022, followed by the FDR in Q4 that same year. The module pre-production will take place at the first half of 2023, while the production is foreseen from Q4 2023 to Q3 2026 (see Figure 15.6).

## 7.4 Module loading

### 7.4.1 General description

The assembled modules have to be mounted on the cooling plates in readout rows, aligned along the *x* or *y* direction. Figure 7.15 shows the position of the modules on the front side (left plot in red) and back side (right plot in blue) allowing an overlap of 20% for the inner part, 55% for the middle part and 70% for the outer part. The longest rows contain 19 modules. For mechanical stability the modules will be glued to a thin support plate which is then screwed to the cooling plate. The modules will be held in place between the support plate and the cooling plate. As described previously, the active area is divided into three rings (inner, middle and outer ring). Therefore, three types of support units per side corresponding to the three rings are foreseen. The inner support units consist of half disks of 120 mm < *r* < 230 mm, the middle and the outer support units of quarter disks of 230 mm < *r* < 470 mm and 470 mm < *r* < 660 mm, respectively. Figure 7.16 shows a drawing of the detector units with the loaded modules. The inner and middle disks will be replaced every 1000 fb⁻¹ and 2000 fb⁻¹, respectively. The total number of support units for the eight sides of the detector is 224 (32 quarter inner supports, 96 middle supports, 96 outer supports). Moreover, since the positions of the modules are different for the two sides of the cooling plates, there are 14 different types of support units.

### 7.4.2 Support units and detector units

Modules are installed and glued on plates (the support units) to be screwed on each side of one of the four cooling plates. The baseline design of the support units consists of a pattern plate, with modules inserted between the plate and the cooling plate. The full size plate is divided into three parts as shown in Figure 7.16. The current baseline is to use quarter disks for the inner part and three pieces per quarter for the middle and outer parts. To ensure the feasibility (fragility, flatness, glue deposition), small supports are considered. The maximum thickness of the support plate is typically 6 mm. The target material is currently carbon fibre. As an example, Figure 7.17 shows the current design of the quarter disk of the inner support unit.
## 7 Module Assembly and Loading

<figure><img src="image_127.png" /></figure>

Figure 7.15: Position of modules and readout rows numbering for the front side of one disk (left plot in red) and for the back side of the same disk (right plot in blue). Smallest radius at 120 mm and maximal radius at 660 mm are shown. The 640 mm radius is the minimal target for the external instrumented area. 230 mm and 470 mm radius are shown as typical limits of the different parts of the support units.

Windows are machined in order to encapsulate the modules which are glued on rectangular strips, while leaving room for the wire bonds and the connector between the module flex and the flex tail (see Figure 7.17).

The windows of the plate give the positioning of modules. The support structure and each window have edges with a precise height, ensuring a constant distance between the modules and the cooling plate. The edges are in contact with the cooling plate and the height is greater than the thickness of the module. Each support unit will be checked with a 3D metrological machine before loading. The tolerances allowing a thermal contact will be defined thanks to the measurements on the demonstrator. These tolerances must also allow a sufficient height so that the modules are not damaged in compression.

Once the detector unit is screwed to the cooling plate, the modules are in direct contact with it, so that the thermal properties of the plate material and of the glue used to fix the modules are not critical. Moreover, thermal grease will be used to improve the contact between the modules and the cooling plate.

For better mechanical strength and rigidity, some reinforcements are added (Figure 7.17). In particular, the material is added near the zone of the internal radius and everywhere possible, leaving open only the necessary areas. First tests show that a single half disk for the inner part and a single quarter for the middle and outer parts would guarantee the stability of the global structure. This type of support plate is more complex than a full plate,
<figure><img src="image_128.png" /><figcaption>Figure 7.16: Detector units with modules assembled on the inner, middle and outer support plates</figcaption></figure>

<figure><img src="image_129.png" /><figcaption>Figure 7.17: Drawing of inner support unit with holes for fixation on the cooling plate</figcaption></figure>

since the windows need to be defined precisely for each module, but then the positioning of
the module itself is straightforward. The structure provides mechanical protection to the
modules and the plate has good rigidity with a minimum contribution to the total thickness
## 7 Module Assembly and Loading

of the detector. On the downside, this design only allows for a small surface when gluing the module to the plate and the mechanical strength and long term stability have to be proven. Some tests have to be performed and several prototypes and the demonstrator will be used to draw a conclusion (see Chapter 14). Should a module be found to be faulty after gluing to the support, rework will be possible. Conclusive tests of module removal have already been carried out and others will be done with the demonstrator.

### 7.4.3 Gluing studies

The modules are fixed to the support unit with four glue dots of 2 mm diameter (see Figure 7.18). The glue dots are deposited onto the edges of the module flex. The glue for module loading into the intermediate plates is required to meet the parameters listed in Table 7.10.

<figure><img src="image_130.png" /><figcaption>Figure 7.18: Schematic view of the module with the four glue dots allowing the fixation with the support unit (left) and test of glue deposition (right) - Pressure values are an example of tuned parameters, depending on the duration and temperature.</figcaption></figure>

With these constraints, six types of glues have been chosen to perform the tests: Araldite 2011; EG7655-LV; EG7655; EG7658; EG8050; Stycast 2850FT. Their characteristics have been checked in the MaxRad (Materials and Adhesives for Extreme Radiation Environments) CERN database<fnref n="1" />

Ease of implementation (fluidity, life time, duration and temperature of the polymerisation) has been evaluated. The ITk choice is also considered, in particular for radiation hardness. The final choice will have to be qualified. Moreover, push-off strength measurements and lap shear tests have been performed in several configurations. These tests have been done using some dummy modules, with a piece of flex cable glued onto, to mimic the module flex. Other tests with a glass plate have been performed to determine the volume of glue needed to obtain the correct thickness and surface (see Figure 7.18). Finally, taking into account all the tests already done and the results, Araldite 2011 is chosen as the baseline for the loading of the modules onto the support units.

<footnote n="1">¹ https://maxrad.web.cern.ch/</footnote>
<table><caption>Table 7.10: Specifications of the glues parameters.</caption><tr><td>Radiation tolerance</td><td>> 5 MGy</td></tr><tr><td>Viscosity</td><td>< 100 Pa s</td></tr><tr><td>Lap shear force</td><td>~ 1 MPa</td></tr><tr><td>Push-off strength</td><td>~ 1 MPa</td></tr></table>

### 7.4.4 Procedure for loading and qualification

The procedure for detector unit loading will be tested when assembling the demonstrator (see Chapter 14), which will be also used to improve the qualification steps. Tools for each step are being developed and tested. Tests are performed following a procedure first using glass plates then silicon glued to a small flex prototype, all without any electrical functionalities, but with the correct geometrical dimensions, instead of actual modules. For all the tests Araldite 2011 is used as glue.

Module loading on support unit should follow this procedure:

1. The modules are placed on a temporary plate with the exact pattern of the final module positions. They are held by a suction system included in the plate.

2. Four glue dots are dispensed on the left and right edge of the module flex (see Figure 7.18). The correct amount of glue is ensured by the usage of an automatic dispenser.

3. The support unit is put in place and pressed on all modules at a nominal compression strength. An adjusting shim is used to ensure the correct thickness of the glue.

4. The polymerisation is carried out (temperature and duration to be defined after final glue tests).

5. The detector unit is removed from the temporary plate and fixed on another plate for packaging and shipping.

6. The system is turned over upside down and a second transport plate is fixed on the top.

7. Electrical tests will be performed at this stage. The tests must ensure that the loading has not damaged the modules. Measurements after loading will be the same as those made after module assembly. Test benches will be adapted, especially the size of the testing box.

8. The detector units are then packed in specially designed packaging to ensure secure transport to CERN where they will be mounted onto the cooling plate (see Chapter 13).
## 7 Module Assembly and Loading

During production, a visual inspection will be performed after module loading, looking for possible mechanical damages to the module, in particular to the edges of the hybrid, the components of the module flex and the wire bonds. Signals will be injected into the sensors and the response will be tested with the same DAQ system used for the test of the single modules. Additionally, it will be checked that there is no interference between the modules, by temporarily connecting stacked flex tails to adjacent modules along a readout row. For all detector units passing the qualification tests, the information on the nominal and measured position of the modules on the support unit, as well as any relevant performance results will be saved to a database. Once the initial characterisation is completed in the R&D phase, thermal tests are not foreseen during production. Mechanical stress tests could be performed on a small fraction of support units if it is deemed necessary.

### 7.4.5 Detector unit assembly strategy

Once their design is finalised, the production of the support units will be carried out by a company and the quality control by one or more Institutes. Then, the plates will be shipped to the module loading sites that have been qualified. To minimize the amount of modules to be shipped and to avoid long distance transport, sites able to perform both module assembly and loading or geographically close to the module assembly sites will be preferred. Since the setup for mechanical and electrical qualification of the detector units is similar to the one needed for module assembly, the site qualification procedure will be mostly common to both activities (excluding the wire bonding capability in this case). As for module assembly, the exact procedure used for module loading might be slightly different among the Institutes, but the same quality of assembled detector units has to be delivered. 224 detector units (32 inner, 96 middle, 96 outer) will be produced in total. The glue and the expendable supplies will be purchased from one or more companies. Most of the components of the electrical test benches are standard ones, available in the Institutes. Some dedicated electronic boards will be developed to test the modules at many steps of the construction of the detector, included the loading step. The gluing and positioning system will be developed in the Institutes, using existing elements, complemented by specific mechanical parts. Because of the non-standard shape of the detector units and the fragility, different types of dedicated packaging will be necessary for transportation from loading sites to CERN.

## 7.5 Thermal Simulations

The power dissipation of the sensor depends strongly on the temperature of the sensor. The irradiation of the sensors will increase the leakage current thus increasing the power dissipation at a given temperature. Therefore the thermal properties of the system have been studied following the strategy outlined in [85].
<table><caption>Table 7.11: Material type and thickness used in the simulation of the thermal properties.</caption><thead><tr><th>Al</th><th>Al-Ti</th><th>CF-Al</th><th>Block</th><th>Material</th><th>Thickness [mm]</th><th>Thermal Conductivity [W m<sup>-1</sup> °C<sup>-1</sup>]</th></tr></thead><tbody><tr><td>x</td><td>x</td><td>x</td><td>Sensor</td><td>Si</td><td>0.25</td><td>124</td></tr><tr><td>x</td><td>x</td><td>x</td><td>Bumps</td><td>SnAg</td><td>0.05</td><td>79</td></tr><tr><td>x</td><td>x</td><td>x</td><td>ASIC</td><td>Si</td><td>0.25</td><td>124</td></tr><tr><td>x</td><td>x</td><td>x</td><td>Foil</td><td>Polymer</td><td>0.10</td><td>3.5</td></tr><tr><td>x</td><td>x</td><td></td><td>Structure</td><td>Al</td><td>0.50</td><td>135</td></tr><tr><td></td><td></td><td>x</td><td></td><td>CarbonFiber</td><td>0.50</td><td>1</td></tr><tr><td>x</td><td></td><td></td><td>Cooling</td><td>Al</td><td>2.50</td><td>135</td></tr><tr><td></td><td>x</td><td></td><td></td><td>Al</td><td>2.00</td><td>135</td></tr><tr><td></td><td></td><td>x</td><td></td><td>Graphite foam</td><td>2.00</td><td>30</td></tr><tr><td>x</td><td>x</td><td></td><td>Interface</td><td>Polymer</td><td>0.1</td><td>3.5</td></tr><tr><td>x</td><td></td><td>x</td><td>Pipe</td><td>Al</td><td>0.50</td><td>135</td></tr><tr><td></td><td>x</td><td></td><td></td><td>Ti</td><td>0.30</td><td>22</td></tr></tbody></table>

As discussed in Chapter 11, several variants of the cooling system are under consideration:

* Al: the entire cooling structure is made of Aluminum down to the pipes. The thermal contact between the pipes and the structure is ensured with an interface foil made of Polymer.

* Al-Ti: identical to Al with the exception of the pipes which are made of Titanium.

* CF-Al: the structure is made of carbon fiber, the pipe of Aluminum. The thermal contact is ensured with graphite foam between the structure and the cooling pipes.

For a choice between the variants the thermal properties, the thermo-mechanical properties (deformations), the electro-chemical compatibility of the material and the radiation length of the materials have to be considered.

CarbonFiber and together with graphite foam are light materials which will lead to a small contribution to the total radiation length. CarbonFiber is rather stable under temperature variations. The thermal conductivity of CarbonFiber depends on the orientation of the fibers, the value given in Table 7.11 is for main direction of the heat flow in the HGTD. In transverse direction, the conductivity is two orders of magnitude higher.

Titanium and Aluminum have a larger contribution to the radiation length of the HGTD. Aluminum is favored with respect to Titanium for this aspect. However Titanium is more robust, therefore thinner structures can be built. A homogeneous use of the same type of material such as Aluminum has the advantage that the system is insensitive to differences in the thermal expansion properties of the materials. The thermal conductivity of Aluminum is better than that of Titanium as shown in Table 7.11. The thermal simulations are performed
## 7 Module Assembly and Loading

with ANSYS. When available in ANSYS, the temperature dependence of the conductivity is taken into account, e.g., for Aluminum.

For the following calculations the CF–Al setup has been used to determine the thermal properties of a module. If such a system is thermally stable, it will also be stable if a material with better thermal conductivity. The impact of deviations from this choice will also be discussed. For a larger system, corresponding to a half HGTD wheel, the Al–Ti variant was simulated.

In a first step, the geometry of a stack with a single ASIC and (half an LGAD) sensor is built. The material used in the thermal simulation of the module are shown in Table 7.11 along with their thickness and thermal conductivity. The sensor, the ASIC, the foil, the structure and the cooling are implemented each as a cuboid built of a square 2 cm × 2 cm and the height given in Table 7.11. The conductivity of silicon increases with decreasing temperature, conservatively the bumps connecting the sensor to the ASIC are implemented individually as 225 cylinders with a radius of 0.045 mm and height of 0.05 mm.

The cooling pipes are half-cylinders embedded in the cooling material. The inner radius of the pipes is 1.5 mm. The outer radius is 2 mm if the pipes are made of Aluminum and 1.8 mm for the Al–Ti setup. As a consequence the cooling structure made of Aluminum with Aluminum pipes has a half-width of 2.5 mm and 2 mm for the Al–Ti and CF–Al setups.

The cooling is simulated as convection which is applied on the surface of the cooling pipes. The nominal temperature of the coolant is –35 °C. As baseline a power consumption of the ASIC of 1.2 W (0.3 W cm⁻²) is used. For the sensor a power consumption of 0.4 W (0.1 W cm⁻²) is assumed.

While the contact between the sensor and the ASIC via the SnAg bumps is assumed to be a perfect thermal contact conductance of 0.01 W mm⁻² °C⁻¹ is applied to the contact between ASIC and foil as well as foil and the carbon fiber structure. The contact conductance leads to a temperature step increasing the thermal resistance of the system. For a power dissipation of 1.6 W the temperature step is 0.4 °C at each material transition.

In Figure 7.19 the result of the thermal simulation by ANSYS is shown. The maximum temperature difference with respect to the nominal temperature of –35 °C is 7.6 °C. If the ASIC is powered alone, the temperature difference is 5.5 °C, for the sensor alone, the temperature difference is determined to be 2.1 °C. The thermal resistance for the sensor is therefore 5.3 °C W⁻¹ and for the ASIC it is 4.6 °C W⁻¹. As the difference between these two resistances of 0.7 °C W⁻¹ is due to the soldering bumps, the thermal resistance of the bumps was calculated analytically using a continuous equivalent volume of SnAg instead of the discrete bumps. The approximation leads to a resistance of 0.5 °C W⁻¹, the larger value for the individual bumps can be understood as the heat transfer will encounter also the resistance in the sensor plane before reaching the bumps in order to flow to the cold reservoir.
<figure><img src="image_131.png" /><figcaption>Figure 7.19: The temperature distribution is shown for the baseline power consumption with an ASIC and a sensor half.</figcaption></figure>

<figure><img src="image_132.png" /><figcaption>Figure 7.20: The temperature distribution is shown for the baseline power consumption with two ASICs and one sensor.</figcaption></figure>

As a second step, the second half of the sensor was added as well as the corresponding ASIC. The current design of the cooling pipes calls for pipes every 16 mm in radius, therefore a second cooling pipe was added at the nominal distance leading to an asymmetric configuration shown in Figure 7.20. Compared to the previous simulation the temperature difference increases to 8.6 °C peak to peak. However, the temperature distribution of the sensor now shows variations with a symmetry axis corresponding to the axis of the cooling pipe. Restricting the study to a single cooling pipe ± half the cooling pipe to cooling pipe distance, the temperature increase is reduced to 7.4 °C, close to the result of the previous simulation within 5%. For the simulations with only the sensor or ASIC dissipating power the temperature increase is globally larger, however as the increase is less than a factor 2, but the power is doubled, the resulting thermal resistance is smaller. Therefore the single-ASIC simulation is a good approximation of the system. Additionally, the geometry is conservative as the next cooling pipe is close to the second ASIC, but has not been simulated. This would
## 7 Module Assembly and Loading

further reduce the thermal resistance.

<figure><img src="image_133.png" /><figcaption>Figure 7.21: The power dissipation of the sensors as function of the temperature is shown as well as the thermal properties of the CF-Al, Al, and Al-Ti systems. The dashed line corresponds to the CF-Al system with a degradation of the thermal resistance from the ASIC to the cooling pipe by 40%.</figcaption></figure>

As the power dissipated by the sensor increases as function of the temperature, if the system cannot evacuate the heat effectively, the temperature will increase, increasing the leaking current, so that a thermal runaway condition is created as explained in [85].

The power dissipation of the sensor, modeled according to Section 5.5.8, is shown as a function of the temperature in Figure 7.21. The strong temperature dependence is clearly visible, e.g. in the red curve for the baseline. The power dissipation of the ASIC increases the effective temperature delivered by the cooling system to -29.4 °C. The black line has a slope which is the inverse of the thermal resistance for the sensor. Once the power dissipation of the sensor crosses this line, thermal runaway is excluded as the heat can be evacuated efficiently. At -5 °C stable operation cannot be achieved anymore.

The maximum power dissipation the system can handle is roughly 0.17 W cm⁻² for the sensor. Thus compared to the baseline a margin of 70% is included in the system. The model from Section 5.5.8 was compared to the one used in [85] by normalizing the models to the same power dissipation at a temperature of -30 °C. In a window of half-width 5 °C around the normalization point, the two models agree within 15%.

A different way of analyzing the properties of the system is to determine the resistance for which the baseline sensor power dissipation is tangent to the line (Rmax scenario). Since
the thermal properties of the system from the sensor to the ASIC are driven by the SnAg bumps, the contact being essential for a functioning system, this part of the simulation is left unchanged. The thermal resistance from the ASIC to the cooling pipes is increased by 40%. This results in the increase of the starting temperature to -27.2 °C. The resistance increases to 7.1 °C W⁻¹ resulting in a flatter slope than in the nominal case. The dashed black line shows the result of the increased thermal resistance.

The simulation can also be interpreted in the following way: an increase of at least 40% of the ASIC power dissipation can be handled by the nominal system. The ASIC power increase would increase the starting temperature to -27.2 °C, but it would not affect the slope as the thermal resistance is unchanged.

The temperature increase of 5.6 °C for the nominal system includes the contact conductance degradation of 0.8 °C proving a further margin of 14%. As the effective contact area between materials is difficult to estimate, it is essential to have this margin built into the system.

In the Al–Ti setup the main part of the cooling system is made of Aluminum with exception of the pipes, the thermal resistance of the system is improved further. The effective operating temperature of system would decrease to –31.2 °C and the thermal resistance would decrease to 3.9 °C W⁻¹ as shown in Figure 7.21 leading to further margin in the operation of the system.

The thermal resistance of the Al is practically identical to the Al-Ti setup. Aluminum has a superior thermal conductivity with respect to Titanium, but the Aluminum pipes are thicker than the pipes made of Titanium. In an assembled Aluminum system the cooling structure is thicker by 0.5 mm half width. This additional contribution to the thermal resistance annihilates the gain expected from the thermal conductivity.

The results for the Al and Al–Ti should be interpreted with caution. If the cooling pipes are produced separately from the cooling structure, a foil is needed to ensure the thermal contact. The simulation has been run without a surface conductance. If the same conductance as the one between the ASICs and the foil is used (on both sides of the foil), the peak temperature increases by 3 °C. The effect is larger than for the other foil as the effective surface of the cooling pipe is smaller. The smaller area is compensated by an increase of the temperature difference. In this case the CF–Al setup has better thermal conductivity than the Al–Ti and Al setups. If in the Al setup the pipes are integrated in the cooling structure and the foil is not needed, the contact will be excellent.

The detailed simulation of the stack for the full HGTD is not possible for the ASIC stack. Therefore a different approach is used. The cooling system is simulated fully for a half disk using the Al–Ti setup. At the position of each module on the disk a power dissipation of 0.4 W cm⁻² corresponding to 1.6 W is applied. The resulting temperature variation is shown in Figure 7.22. The maximal temperature overall is –32.2 °C. Three regions, corresponding to the three rings of the HGTD can be distinguished. The modules and the space between the modules explains the temperature variation. In the inner ring of the HGTD, at the position
<figure><img src="image_134.png" /><figcaption>Figure 7.22: The temperature distribution on the surface of the cooling system is shown for a half disk when applying $0.4 \text{ W cm}^{-2}$ at the location of each ASIC.</figcaption></figure>

of a module, the typical maximal temperature is slightly colder at -32.6 °C. The temperature decreases slightly, only by about 0.3 °C, in the space between the modules.

Having determined the maximal temperature on the cooling structure with the full simulation, the highest temperature of the sensor is calculated by using the detailed model of a single ASIC. The temperature of the structure is fixed to the maximal temperature observed in full simulation, i.e., -32.2 °C. The baseline power dissipation of sensor and ASIC is simulated. The temperature at the sensor increases by 1.2 °C to -31 °C. This is a lower temperature than the -29.6 °C determined in a single pipe simulation using the Al-Ti setup.

While the detailed setup with a single cooling pipe simulates a straight cooling pipe, the full simulation takes into account the curvature of the pipes. For some modules in extreme cases, this could have lead to a loss of cooling surface of the pipes, increasing the thermal resistance, e.g., if the pipe exits the module on the side instead of going through the whole module. On the other hand, the distance between two cooling tubes is smaller than the lateral size of the half-module. This leads to a larger surface area of cooling in full simulation with respect to a single pipe simulation. The temperature difference in the detailed model is therefore increased, increasing also the thermal resistance. The result shows that the simulation of a single ASIC with a single cooling pipe is conservative setup, leading to a higher peak temperature than the one that would be determined in a full model.

All three types of setups, i.e., Al, Al-Ti and CF-Al, have the potential to ensure stable operation of the HGTD without thermal runaway. Ensuring the quality of the thermal contact between the different parts of the HGTD will be essential to keep the thermal
resistance of the system under control.

## 7.6 Roadmap towards production

The total surface covered by the HGTD (6.4 m²) requires a well planned approach to successfully carry out the module assembly and loading. A brief schedule of module assembly and loading activities is described below, and more details can be found in Section 15.2 and Figure 15.6.

*   **Bare Module Hybridisation:** Full-size bare module prototyping will be carried out after the final sized sensor and ASIC (ALTIROC2) become available. A Specification Review will take place in Q2 2021 before hybridization qualification. The PDR will be submitted in Q1 2022, presenting the bare module prototype design with ALTIROC2. Hybridization qualification is scheduled in Q2 2022 with two or more companies to qualify their hybridization service (including metalization, bump-deposition, dicing and flip-chip). It is followed by the FDR in Q4 2022. The bare module pre-production will take place in Q1 2023, followed by the production from Q1 2024 to Q1 2025.

*   **Module Assembly and Module Flex:** The module assembly production will be shared among 4 to 5 HGTD Institutes. The overall production rate is expected to be approximately 19 modules per working day in the first half and 22 modules per working day in the second half of the production. After the prototyping phase is completed, and the first full-sized (ALTIROC2) modules are produced, the module assembly PDR will be submitted in Q3 2022. Institutes module assembly qualification procedure will start in Q4 2022, to ensure that all sites uniformly produce modules according to specifications. followed by the FDR in Q4 in Q2 2023. The module pre-production will take place in the second half of 2023, while the production is foreseen from Q3 2024 to Q3 2026.

*   **Module Loading:** The design and specification review of detector support units and module loading procedure will take place in Q1 2022, followed by the PDR in Q4 2022. Once the design is finalised, the production of the support units will be carried out by a company and the quality control by one or more Institutes.

The module loading will be shared among several HGTD Institutes. Institutes able to perform both module assembly and loading or geographically close to the module assembly sites will be preferred. Institutes will assemble the modules and then load them on the Detector Units. The site qualification procedure will take place in 2023. This qualification is mostly common to both module assembly and loading activities. FDR will be submitted in Q2 2023, followed by pre-production at the second half of 2023. The production will last from Q3 2024 to Q3 2026. 224 detector units (32 inner, 96 middle, 96 outer) will be produced in total. They will be shipped from loading sites to CERN.
## 7 Module Assembly and Loading

* *Flex Tails:* The flex cable design will be finalized after testing it connected to the ALTIROC2 in the demonstrator described in Chapter 14. In the design, simulations and tests particular attention will be given to avoiding mechanical stress on the other components due to the expansion and shrinking of the long flex tails with temperature. A Specification Review will take place in Q1 2022, followed by the PDR in Q2 2022. The production of flex tails should be ideally shared among a few of the companies that can provide good quality of cables. FDR will be submitted in Q1 2023, followed by pre-production from March to November 2023. The production is foreseen from March 2024 to September 2025.
# 8 Power distribution, Grounding and Shielding

This section covers the powering of the detector, including the schematic layout of the High Voltage (HV) and Low Voltage (LV), from the supplies located in the USA15/UX15 services cavern, the DC-DC converters placed at the patch panels boxes in the PP-EC area (Section 12.3), up to the peripheral electronics and modules sitting inside the vessel. The grounding and shielding schemes are also briefly described. The details of the services needed to power the detector and respective connectivity are described in Chapter 12.

## 8.1 High voltage

Each of the 8032 LGAD sensor modules of the detector require an individual bias voltage in a range up to 800 V. Such a high voltage is needed to power the sensors after being exposed to the high radiation conditions of the HL-LHC (detailed in Chapter 5). The bias voltage of the sensors has to be adjusted due to the gain degradation with the received fluence. Figure 5.17 shows the required bias voltage as a function of the radial position for different fluence levels. In combination with the non-radial geometry, this results in a limited possibility to connect several modules to the same bias supply. Since sensor modules close in radius are expected to require the same voltage, the baseline choice is that two modules share bias supply. High voltage supplies capable of delivering 6 mA current per channel will be used, which allows with sufficient margin an average leakage current up to 5 µA per pad for irradiated sensors. This choice, which requires 2008 HV channels per end-cap, allows to save cost. Commercial supplies with multi-channel rack mounted units will be located in the service cavern. Systems with high channels density (~400-500 per crate) allow to minimize space but also to reduce cost. A schematic layout of the high voltage system is shown in Figure 8.1.

The filter units at the PP-EC area will also serve as patch panels allowing to select sharing of supplies of the individual sensor modules. A further low pass filter is placed on the flex cables near the sensor modules. In the baseline design each sensor has an individual HV return connection to the filter unit. An alternative solution, using a common return from the reference grounds of peripheral electronics boards, is under study. In this solution the individual HV is referenced to the analog ground at the module. The voltage difference of
## 8 Power distribution, Grounding and Shielding

the analog ground at the module and the PEB ground will be less than 50 mV even for the longest flex cables and can be neglected.

<figure><img src="image_135.png" /><figcaption>Figure 8.1: HGTD schematic High Voltage layout</figcaption></figure>

## 8.2 Low voltage

For supplying the low voltages needed by the front-end and peripheral electronics a three stage system is used, as shown in Figure 8.2. The system will have to be able to deliver about 20 kW at 1.2 V to the Front-End ASICs as well as the peripheral readout electronics. Bulk power supplies located in USA15 provide 300 V DC current to DC-DC converters placed in the PP-EC areas (described including radiation environment and magnetic field in Section 12.3). These second-stage multi-channel DC-DC units convert the 300 V to 10 V which is distributed to radiation hard DC-DC converters located on the peripheral electronics boards inside the vessel (details in Chapter 9). The last stage converts power to the front end ASICs on the detector chips and the peripheral electronics providing mainly 1.2 V DC power but also 2.5 V for optical links. The converters on the peripheral boards are based on the bPOL12V ASIC developed by CERN for the HL-LHC upgrade. Due to space limitations on the peripheral boards, the 10 V to 1.2 V conversion will be done in a single stage (see Section 9.2). The exact output voltage for each converter on the peripheral boards is selected by a resistor chain to take the voltage drop of the flex cables into account.

Each ALTIROC ASIC requires 0.5 W analog power and 0.7 W digital power at 1.2 V. Separate DC-DC converters will be used for the analog and digital voltages. With two ASICs per module, one bPOL12V based DC-DC converter will be used to supply analog or digital power to 3 modules. The modules connected to the same DC-DC converter are chosen to assure that the voltage difference is less than 30 mV which is within the (1.20 ± 0.05) V specifications of the ALTIROC ASICs (Table 6.1). With 2008 modules per disk (or double-sided layer), 1408 DC-DC converters on the peripheral electronics per disk are needed to power the front end electronics, including power losses on the flex cables. A further 120 DC-DC converters per disk are required for powering the components on the peripheral boards.

These DC-DC converters on the peripheral electronics will need to provide almost 5.0 kW of power per disk. With an efficiency of 72% (at -30 °C and 3 A), each disk has to receive
850 A at 10 V which will be supplied by 72 channels that are able to provide 16 A each. The number of channels is given by the requirement that the ground reference is separate for each peripheral board and that 32 out of the 40 boards per disk require more than 16 A at 10 V. The 300 V will be provided by 14 rack-mounted units in the service cavern, each delivering 3 kW. Details on the low voltage units are given in Table 8.1.

<table><caption>Table 8.1: Type of LV units, location, maximum current delivered per unit and number of units/channels.</caption><thead><tr><td>Voltage</td><td>Location</td><td>Current/channel</td><td>Nb of channels/units</td></tr></thead><tbody><tr><td>300 V</td><td>USA15</td><td>10 A</td><td>14</td></tr><tr><td>300 V → 10 V</td><td>PP_EC</td><td>16 A</td><td>288</td></tr><tr><td>10 V → 1.2 V (or 2.5 V)</td><td>On peripheral board</td><td>4 A</td><td>6112</td></tr></tbody></table>

With an 80% efficiency of the 300 V to 10 V DC-DC power converters located in the PP-EC area, a total cooling power of 4 kW per end-cap is required at these locations. A water leak-less cooling system, providing water at ≈ 18 °C, and corresponding pipes/manifolds on the calorimeter surface will be needed. Details on the services, patch panels area and cabling are given in Section 12.6.

<figure><img src="image_136.png" /><figcaption>Figure 8.2: HGTD schematic Low Voltage/power layout</figcaption></figure>

## 8.3 Grounding/shielding

The grounding and shielding of HGTD follows similar requirements as defined for ITk [86]. The ground reference point for the HGTD itself will be the inside of the detector vessel. This inside is covered with a thin high conductive foil to ensure the function as a Faraday cage.

Both end-caps will be independent Faraday cages. The cage extended up to the patch panels at PP-EC through the shields of the LV, HV and control cables. The patch panels as well as the vessels are electrically insulated from the detector walls and from the mechanical
## 8 Power distribution, Grounding and Shielding

structures on which they are mounted. The Faraday cage will be connected through a single ground line to the ATLAS common ground. This will constitute the reference potential. The connectors for the conductor cables at the outer ring of the vessels (Section 11.5.5) are designed to assure good connection of the cable shields to the vessel inside.

The reference ground for the low voltage power is the ground plane of the peripheral electronics boards. Each peripheral board is locally floating. The planes will individually be electrically connected to the vessel ground plane at selected places avoiding ground loops. The sensor modules and ALTIROC ASICs are floating and will be referenced to peripheral board ground through the analog ground plane of the flex cables (Section 7.3.2).

The sensors for the Detector Control System (DCS) system (Section 10.4), e.g temperature probes on the cooling plates, are electrically floating and connected via cables to DCS units mounted inside the extension of the Faraday cage at the patch panel areas. Connection to the experimental cavern is via optical fibers or optocouplers to maintain the shielding. The same DCS units will also supply the enable signals to the 1.2 and 2.5 V DC-DC converters for powering the peripheral electronics.

The cooling plates inside the vessels will be part of the shielding and electrically connected to the inside of the vessels. This requires the CO₂ transfer line to be electrically insulated at the cooling junction box located on the end-cap calorimeter surface. Shielding for cables will be discontinued appropriately to avoid ground loops.

## 8.4 Roadmap for power system

The studies of the grounding options for the High Voltage return will continue in 2020 for decision no later than Q3. In parallel, studies of commercial solutions for the power supplies (both HV and LV) will take place in order to prepare for the Specification Review in Q3 2021 (Figure 15.4). Tendering will follow in 2022 with subsequent prototype tests for the FDR and PRR. Design and prototype studies of the HV filter and patch boxes is integrated with the studies of the grounding options and the HV power supplies. The final design of the boxes are dependent on configuration of the selected commercial solution and will take place towards the end of 2022.
# 9 Peripheral Electronics

The on-detector peripheral electronics transfer data between the detector modules and the DAQ system, the luminosity system as well as the Detector Control System (DCS). It also has a central role in the monitoring of sensor temperatures and supplied low voltage. The peripheral electronics system is based on the CERN-developed lpGBT ASICs [60]. The modules are connected via flex cables (see Section 7.3.2), while signals to and from the DAQ and the luminosity systems are transferred on optical fibers. On these fibers the DCS data and commands are embedded in the data streams.

Each flex cable serves a module consisting of two ALTIROC ASICs and contains two differential electrical CERN Low Power Signalling (CLPS) e-links transmitting timing data at different rates (320 Mbit s⁻¹, 640 Mbit s⁻¹, or 1.28 Gbit s⁻¹) depending on the ALTIROC position. Flex cables for modules placed at a radius above 430 mm carry a further two differential e-links at 640 Mbit s⁻¹ with luminosity data. Each cable also contains four e-links with clock and fast DAQ commands to the ALTIROC ASICs with a bandwidth of 320 Mbit s⁻¹, as well as the lines for the ALTIROC low voltage power supplies, control signals and the bias voltage of the sensor. The digital output data from several ALTIROCs are merged in lpGBTs on peripheral electronics boards (PEB) and transmitted on optical fibres to the off detector DAQ system. Control and configuration commands to and from the ALTIROC ASICs are transmitted via I²C bus. The I²C bus information is embedded in the data streams between the lpGBTs and the detector DAQ system. An overview of the HGTD readout chain is presented in Figure 9.1.

The peripheral electronics also include the 10 V to 1.2 V DC-DC converters for the digital and analogue voltages supplied to the ALTIROC ASICs. The supply voltages are monitored using the internal multiplexed ADC on the lpGBTs. The ADCs are also used to measure actual voltages received by the ALTIROC, as well as the sensor temperatures. The voltages to be measured are selected by analog 64-to-1 multiplexers mounted on the peripheral boards as described in Section 9.3.

The lpGBTs that are used for transmitting luminosity data do not a priori need to receive downlink data via optical fibres and will thus only send data to the off-detector luminosity backend electronics. These lpGBTs will receive the required 40 MHz clock from lpGBTs connected to the off-detector DAQ system.

A schematic block diagram of the PEB electronics for one module connected to off detector electronics is shown in Figure 9.2.
<figure><img src="image_137.png" /></figure>

Figure 9.1: Upstream and downstream data flow. The e-links transmit data, fast commands and clocks between the ALTIROC ASIC and the lpGBT. VTRX+ is the Versatile Link+ optical module. I²C-bus, ASIC control and monitoring lines from the ALTIROC are also shown. Only one module (2 ALTIROC ASICs) is shown. Up to 8 modules are connected to the same DAQ lpGBT. Each of these lpGBTs uses one Rx port at 2.56 Gbit s⁻¹ and one Tx port at 10.24 Gbit s⁻¹ of the VTRX+. The luminosity lpGBTs uses one TX port of some of the VTRX+.

As introduced in Section 2.3, each HGTD vessel contains two cooling disks (shown in Figure 2.4), with detector modules mounted on both sides, thus having two instrumented layers per disk. The baseline design is to have five Peripheral Electronics Boards (PEBs) per quadrant and per side of each cooling disk, as shown in Figure 9.3. Such a layout yields 80 boards per HGTD vessel, thus 160 boards in total. Each board covers three or more readout rows in order to have a similar number of ALTIROC ASICs connected per board (typically 106-110). This optimizes the use of the lpGBTs by sharing across readout rows.

All the active components of the peripheral boards will be located at radii above 700 mm. Extrapolating from Figure 2.14, the maximum expected fluence, which these components have to withstand, will be below $1 \times 10^{15} \text{ n}_{\text{eq}} \text{ cm}^{-2}$ and the TID below 0.2 MGy.

## 9.1 Data transmission

The data transmission between lpGBTs on the peripheral electronics and the off detector systems uses optical fibres based on the VTRX+ optical transceiver developed within the Versatile Link Plus project [87]. The bandwidth required for the digital data output from the ALTIROC ASICs is given by the number of pads hit in an event. The expected average number of hits depends on the radius of the module position. The hit rate has been studied using simulations and the results are presented as average occupancy per ASIC for an $\langle \mu \rangle = 200$ in Figure 9.4. The radial dependency is clearly seen with a maximum of just below
<figure><img src="image_138.png" /><figcaption>Figure 9.2: Block diagram of the peripheral electronics for powering and readout of a module. Multiple modules are connected to the same DC-DC converters and lpGBTs. The brown lines indicate voltages measured by the multiplexed ADC on the lpGBT. Light blue lines are low voltage (1.2 V) power supplied from bPOL12V DC-DC converters. Light green lines are 2.5 V. The 2.5 V is connected to the lpGBTs only to measure the voltage for monitoring purpose. The thin black lines are control signals via the general purpose I/O ports of the lpGBTs. The thick black lines are high speed electrical links to and from the VL+ optical module. Other lines are explained in the figure.</figcaption></figure>
<figure><img src="image_139.png" /><figcaption>Figure 9.3: One quadrant of the HGTD front and back disk is shown. The PEBs (in green) are attached to the readout rows (numbered from 1 to 21).</figcaption></figure>

8% at the innermost radius. Such an occupancy can be accommodated within the maximum available rate for the data from the ALTIROC, which is 1.28 Gbit s⁻¹.

For larger radius the bandwidth per e-link can be reduced, using 640 Mbit s⁻¹ at radii above 220 mm and 320 Mbit s⁻¹ at radii above 405 mm. These rates are chosen in order to minimise the numbers of lpGBTs and optical links while keeping the average bandwidth usage below 55% for the expected number of average hits per ASIC at a readout rate of 1 MHz. The average bandwidth usage for each module in a quadrant of the first double sided layer is shown in Figure 9.5.

In addition to the readout output e-link each ALTIROC ASIC requires a 320 Mbit s⁻¹ fast command input e-link to supply both the bunch crossing information and the DAQ commands. A 320 MHz clock extracted inside the lpGBT from the command data packages is also sent to each ASIC. In the regions of readout rows 4 to 18 (Figure 9.3) the minimum number of lpGBTs used is given by the required number of fast command links. In these cases, readout e-links at 640 Mbit s⁻¹ are available for higher radii than mentioned above, resulting in increased bandwidth capacity as seen in the figure.
<figure><img src="image_140.png" /><figcaption>Figure 9.4: Average occupancy of an ASIC as function of radius in a simulated sample with $\langle\mu\rangle = 200$.</figcaption></figure>

<figure><img src="image_141.png" /><figcaption>Figure 9.5: Readout bandwidth usage, in % of the capacity, for the expected number of average hits per ASIC from simulations with $\langle\mu\rangle = 200$ at a readout rate of 1 MHz. The usage is shown per sensor module in a quadrant of the first double sided layer. Left: Front layer. Right: Back layer. In regions corresponding to the readout rows 4-18, higher bit rate capacity is available (see text) resulting in lower bandwidth usage.</figcaption></figure>
9.1.1 LpGBT

<figure><img src="image_142.png" /><figcaption>Figure 9.6: Block diagram of the lpGBT ASIC.</figcaption></figure>

A block diagram of the lpGBT is shown in Figure 9.6 and more details concerning its
specifications can be found in [60].

The lpGBT ASIC is able to transmit data to an optical link at 10.24 Gbit s⁻¹. When using FEC5 error correction code the bandwidth can be shared by 7 groups of 32 bit data received on differential (CLPS) e-links. The 32 bits can come from one 1.28 Gbit s⁻¹, two 640 Mbit s⁻¹, or four 320 Mbit s⁻¹ e-links. The phase aligner circuit for each input e-link of the lpGBT will be used to ensure that the received data is sampled by the lpGBT at the optimal phase. This allows data from flex cables with different lengths to be connected to the same lpGBT. The total package length of the transmitted data, including headers, error correction codes, and 2 bits of internal and 2 bits external DCS data, is 256 bits, that are transmitted at a rate of 40 MHz.

Each lpGBT is able to receive four independent 320 Mbit s⁻¹ bit streams encoded in the
2.56 Gbit s⁻¹, 64 bit frame, down-link data from an optical link. Each package includes
headers, FEC12 error correction bits as well as 2 bits internal and 2 bits external DCS data.

The lpGBTs require configuration commands for setting up registers controlling their beha-
vior, e.g. bit rates and phase shift adjustment. This is normally done through their I²C bus
slave port, however to avoid external I²C bus cables, the lpGBTs receiving data via optical
links on each peripheral electronics board will be programmed by e-fuses to receive their configuration via the 2.56 Gbit s⁻¹ downlink bit stream. The same lpGBTs will in turn be used to configure the lpGBTs for the luminosity system of the same board via one of their I²C bus master ports.

*   **Fast commands and clock distribution.** Each data package received by the lpGBT via the optical links contains up to four independent 320 Mbit s⁻¹ data streams. These can be mirrored to four different outputs of the lpGBT, allowing one lpGBT to control 16 ALTIROC ASICs using 8 bit words. The 320 MHz clock required by the ALTIROC is extracted from the data streams by the lpGBT and distributed to the ASICs on individual clock streams. Preliminary measurements done by the CERN lpGBT group show an excellent random component of the jitter (2.1 ps) but a sizeable deterministic part. The minimum number of lpGBTs required for the peripheral electronics is defined by the above limitation of not more than 16 ALTIROC ASICs connected to the same lpGBT.

*   **DAQ data.** The different e-link bit rates 1.28 Gbit s⁻¹, 640 Mbit s⁻¹, and 320 Mbit s⁻¹ allow for an average number of hits per bunch crossing and per ALTIROC at ⟨μ⟩ = 200 of up to about 41, 20 and 9, respectively, at 1 MHz of event readout. The number of lpGBTs must be kept to a minimum, in view of the limited space available for the peripheral electronics.

*   **Luminosity data.** Each ALTIROC ASIC at radii larger than 430 mm provides 16-bit luminosity data for each bunch crossing, transmitted to the lpGBTs via the flex cables. The 430 mm results from using all available e-links of the minimum number of lpGBTs that allows all modules in the outer ring at r > 470 mm to be included. Two 640 Mbit s⁻¹ e-links are merged into a 32 bit lpGBT group, allowing 14 luminosity e-links to be connected to a single lpGBT for transmission to the off detector electronics via an optical link. In the baseline design, no downlink data is foreseen for these lpGBTs, which will be operated in simplex transmitter mode. The clock signal will instead be obtained as a 40 MHz clock from the DAQ lpGBTs. Operation parameters and controls for the luminosity lpGBTs, e.g. phase adjustment delays, are set up via the I²C bus also from the DAQ lpGBTs.

*   **I²C bus.** Each lpGBT has three I²C bus masters and one slave. Only the master ports on the DAQ lpGBTs are used since the luminosity lpGBTs do not receive optical downlink data. One I²C bus master will be connected to up to eight ALTIROC ASICs on four modules for DCS control. Since these I²C-buses will only be used for configuration, traffic will be minimal during data taking limiting the risk of generating noise inside the ALTIROC ASICs. I²C-bus master ports are furthermore used to configure the laser drivers of the optical links and, as previously mentioned, to configure all lpGBTs of the luminosity readout.
To load the initial configuration, which will be fused into the lpGBT registers, connec-
tions for an external I²C-bus to the peripheral electronics is foreseen.

**9.1.2 Optical links**

Each lpGBT connected to the DAQ system will need one up and one down optical link, while the lpGBT connected to the luminosity readout will only need an uplink to the off detector system. The VTRX+ optical transceivers handle four fibres for transmission and one for reception. The dimensions are specified as a 20 × 10 mm² footprint. The specified radiation hardness, 1 MGy and 1 × 10¹⁵ nₐq cm⁻², exceed the required levels at radii greater than 85 cm, where they will be located. The VTRX+ modules are pluggable via electrical connectors and are delivered with a pigtail ending in a 12 fibre MT type optical connector.

**9.2 DC-DC converters**

The peripheral electronics will contain DC-DC converters based on the bPOL12V Point Of Load regulators. These converters supply the 1.2 V required by the ALTIROC ASICs and the lpGBT ASICS. The Versatile Link plus require 2.5 V for the laser driver and limited current at 1.2 V for the receiver. The DC-DC converters use the bPOL12V ASIC developed at CERN. The bPOL12V will be used as a single stage converter from the 10 V input to the 1.2 V output (or 2.5 V for the laser driver). The motivation for this choice, rather than a dual stage converter that potentially has higher efficiency, is the limited surface available for the peripheral electronics.

The maximum output current of the bPOL12V is 4 A. Measurements on prototypes by the
developers indicate that an efficiency up to 72% at -30 °C and 3 A current can be achieved.
When operating near the maximum current the input voltage should not exceed 10 V to
reduce switching transients. The ASIC is designed for radiation tolerance up to 2 MGy and
2.5 × 10¹⁵ n<sub>eq</sub> cm⁻². The converters need a 460 µH inductance as well as further filtering
components. A printed circuit board layout exists, which is adapted from the layout op-
timized by the bPOL12V developer team. The footprint of this layout, 11 mm × 30 mm, is
however still considered to be large compared to the available space. The feasibility of a
reduction by the choice of the design of the inductor and shielding cage of the converter is
under investigation.

The analogue and digital voltages are supplied separately to the ALTIROC ASICs. Each ALTIROC requires at most 0.5 W analogue and 0.7 W digital power. The two ASICs on the same module share supplies. The current consumption is dependent on the average number of hits within an ASIC and thus has a radial dependence. Separate DC-DC converters will be used to supply the analog and the digital parts of the ALTIROCs. Each DC-DC converter will
supply 6 ALTIROC ASICs (3 modules). The power consumption of an lpGBT will not exceed 0.55 W (0.45 W for lpGBTs of the luminosity readout due to only uplinks being used).

To power on the electronics for one PEB the DC-DC converters supplying the PEB itself, i.e. the lpGBTs and the optical links, are first switched on by an external 1 V enable signal. The status of these converters is read out via external electric cables (open drain) and on general purpose I/O-lines on lpGBTs other than those they supply. This allows to differentiate between possible power failures and lpGBT failures. The external signals are controlled via EMCI units [88] from the DCS system. Care is taken to avoid that the external electrical cables violate the grounding and shielding rules.

Once the lpGBTs and VTRX+ are powered on, the DCS bits i the lpGBT data stream can be used to control the DC-DC converters supplying voltages to the ALTIROC ASICs. The DC-DC converters are switched on by applying a voltage (at least 850 mV) which is generated via general purpose I/O-lines from DAQ lpGBTs while the status of the converters are reported via their open drain Power Good output and monitored via lpGBTs.

**9.3 Control and monitoring**

The DCS control and monitoring of the front-end electronics, the monitoring of the sensor temperature and the delivered and received low voltage of the electronics is handled through the lpGBTs. The DCS information is embedded in the up and down bit streams of the optical connections at a rate of 80 Mbit s⁻¹. Two bits per data package at 40 MHz, in both directions, can be used for the general purpose I/O-port, ADC or I²C bus masters of the lpGBT. Since the lpGBTs of the luminosity system will not have optical downlinks, only the lpGBTs connected to the DAQ system will be used for DCS handling in the baseline option.

Each flex cable will, as described in Chapter 7, carry 5 voltages: temperature of the sensor from each of the two ALTIROC (voltage from the temperature sensor); analogue and digital supply voltages received at the ALTIROCs and the analog current return voltage at the module. Due to the resistance of the conductors on the flex cable, the latter three voltages serve to measure the current consumption and detect latch-up. Each lpGBT has an 8 input 10-bit multiplexed ADC allowing 1 mV resolution for a 1 V range. To handle all voltages to be measured, a 64:1 multiplexer (see Section 6.8) is used. Each multiplexer, which can switch the received voltages from up to 12 modules, is controlled by 6 I/O lines from an lpGBT.

As mentioned above, the peripheral electronics boards will each receive an external control signal to switch on the DC-DC converters supplying the lpGBTs and the optical links. The status of these converters is read out on I/O-lines on lpGBTs other than those they supply to allow to differentiate between possible power failures and lpGBT failures. Further I/O-lines on the DAQ lpGBTs are used for switching on and monitoring the status of the DC-DC converters supplying voltages to the ALTIROC ASICs.
The I²C bus will be used to control and configure the ALTIROC ASICs as well as to configure the lpGBTs.

## 9.4 Connectors

The limited space available for the peripheral electronics puts severe constraints on connectors. The PEB ground will be connected to the reference ground of the detector vessel.

* The flex cables from a readout row will enter the peripheral electronics in bundles of up to 19 cables. Each flex cable is 36 mm wide. Several options for connecting them to the PEBs are under study. Limitations on the available space, both concerning height and footprint on the boards, put severe restrictions on solutions. Furthermore, the reliability of the connection is an important consideration. The baseline choice is to integrate up to 6 flex cable ends from modules in the outer ring directly in a rigid flex part of the PEB. This is illustrated in Figure 9.7.

* All modules have individual high voltage supplied through the PEB via the flex cables to the modules. Commercial 56 pin connectors specified to sustain operation up to at least 800 V will be used on the PEBs for connection from the vessel feedthroughs. In the baseline design each sensor module has individual HV return connection requiring two connectors per PEB to connect both supply and return to each of the up to 55 modules. An option, in which a common HV return is connected to the ground plane of each peripheral board, is being studied in order to reduce the number of cables. The HV at each module is then referenced to ground through the analog ground plane on the flex cables at the module end.

* The peripheral boards will each require 2 cables with 10 V for the on-board DC-DC converters. Suitable connectors are under study.

* The optical fibre pigtails of the VTRx end in a 12 fibre MT-type connector to which the patch cables of the fibre feed-throughs at the detector vessel have to be connected.

## 9.5 Peripheral boards

### 9.5.1 Physical limitations

The available physical space for the peripheral electronics is very limited. It is constrained in the radial direction by the end of the instrumented area and the limit of the HGTD vessel, therefore ranging from 660 to 920 mm. Because the allowed thickness of the HGTD is only
<figure><img src="image_143.png" /><figcaption>Figure 9.7: Illustration of the rigid flex concept. The ends of the flex cables (orange) are part of the printed circuit board.</figcaption></figure>

75 mm, the space available for the electronics in the z-dimension is also very small: 9 mm with a 1 mm margin.

### 9.5.2 Layout considerations

The peripheral electronics will be split up in five peripheral boards (PEB) per quadrant with a similar number of sensor modules connected per board. This is achieved by combining the readout rows 1–3, 4–7, 8–14, 15–18, and 19–21, see figure Figure 9.3 for the row numbering convention, into one board each. (The readout row numbering is shown in Figure 7.15). This combination allows the reduction in the number of lpGBT ASICs, multiplexers and VTRx used and would lead to a better use of the available surface area at the outer radius of the disks for connectors.

The number of modules, e-links for DAQ at different transfer rates and luminosity e-links per peripheral boards are shown in Table 9.1. The bit rates of the DAQ e-links will be re-optimised for the final layout based on further simulations. The number of lpGBT ASICs per PEB is given by the limitation, that there are only 16 e-links to transmit DAQ commands to the ALTIROC ASICs per lpGBT. The bit rates for readout are selected to be as high as possible given the available capacity.

A number of considerations have to be taken into account for the actual PEB design.

* To limit the implications of possible failing components, care must be taken in the layout design such that as few detector modules as possible are affected. The modules have to share, as far as possible, the same lpGBT for readout as the one that also transmit their clock and fast commands, control their DC-DC supply as well as DCS
<table><caption>Table 9.1: Number of module readout e-links at different rates for the different peripheral boards of the front and back layers. The tables also show which readout rows are connected to which board and the number of modules per board.</caption><thead><tr><th>Peripheral board</th><th>Readout rows</th><th>Nb of modules</th><th>1.28 Gb/s</th><th>640 Mb/s</th><th>320 Mb/s</th><th>Luminosity</th></tr></thead><tbody><tr><td colspan="7"><strong>Front</strong></td></tr><tr><td>1</td><td>1-3</td><td>55</td><td>18</td><td>32</td><td>60</td><td>42</td></tr><tr><td>2</td><td>4-7</td><td>53</td><td>8</td><td>66</td><td>32</td><td>56</td></tr><tr><td>3</td><td>8-14</td><td>36</td><td>0</td><td>68</td><td>4</td><td>70</td></tr><tr><td>4</td><td>15-18</td><td>53</td><td>8</td><td>66</td><td>32</td><td>56</td></tr><tr><td>5</td><td>19-21</td><td>53</td><td>20</td><td>30</td><td>56</td><td>42</td></tr><tr><td colspan="7"><strong>Back</strong></td></tr><tr><td>1</td><td>1-3</td><td>55</td><td>18</td><td>26</td><td>64</td><td>42</td></tr><tr><td>2</td><td>4-7</td><td>53</td><td>10</td><td>60</td><td>36</td><td>56</td></tr><tr><td>3</td><td>8-14</td><td>37</td><td>0</td><td>72</td><td>2</td><td>70</td></tr><tr><td>4</td><td>15-18</td><td>53</td><td>8</td><td>66</td><td>32</td><td>56</td></tr><tr><td>5</td><td>19-21</td><td>54</td><td>20</td><td>18</td><td>44</td><td>42</td></tr></tbody></table>

control via I²C bus and handle the module voltage monitoring. Optimised schemes for this exist and will be implemented.

* For the same reason, modules sharing the same readout lpGBTs should share luminosity lpGBTs, that will receive their configuration control and clock from the readout lpGBTs.

* The power dissipation of the peripheral electronics is used to preheat the CO₂ cooling requiring a suitable radial arrangement of the DC-DC converters and lpGBTs.

### 9.5.3 Layout

Combining multiple readout rows on the same PEB, as described above, the required number of different components is worked out per PEB, as shown in Table 9.2.

A conceptual design of the first two PEBs (Front 1 and Front 2) is shown in Figure 9.8. A functional prototype of the PEBs is scheduled to be produced by 2020 as part of the demonstrator program Section 14.3 in parallel with a complete PCB design of a real size PEB for early 2021.
<figure><img src="image_144.png" /><figcaption>Figure 9.8: Conceptual design of a PEB 1 and 2 for the front layer. The yellow parts are the flex cable tails. The blue rectangle are the VTRX+ transceivers. The white squares are the lpGBTs. The flex cable connectors are in two parts, one for signals av LV power and a smaller one for HV. The MUXes (red squares with white rectangular band) and the DC-DC converters (red blocks of components) are also visible</figcaption></figure>
<table><caption>Table 9.2: Numbers of lpGBTs, analog multiplexers, VTRx, and DC-DC converters for the different Peripheral Electronics Boards.</caption><thead><tr><th>Peripheral board</th><th>lpGBTs DAQ</th><th>lpGBTs Luminosity</th><th>DC-DC converters</th><th>MUX</th><th>VTRx</th></tr></thead><tbody><tr><td colspan="6"><strong>Front</strong></td></tr><tr><td>1</td><td>8</td><td>3</td><td>42</td><td>5</td><td>8</td></tr><tr><td>2</td><td>7</td><td>4</td><td>40</td><td>5</td><td>7</td></tr><tr><td>3</td><td>5</td><td>5</td><td>28</td><td>4</td><td>5</td></tr><tr><td>4</td><td>7</td><td>4</td><td>40</td><td>5</td><td>7</td></tr><tr><td>5</td><td>8</td><td>3</td><td>40</td><td>5</td><td>8</td></tr><tr><td colspan="6"><strong>Back</strong></td></tr><tr><td>1</td><td>8</td><td>3</td><td>42</td><td>5</td><td>8</td></tr><tr><td>2</td><td>7</td><td>4</td><td>40</td><td>5</td><td>7</td></tr><tr><td>3</td><td>5</td><td>5</td><td>30</td><td>4</td><td>5</td></tr><tr><td>4</td><td>7</td><td>4</td><td>40</td><td>5</td><td>7</td></tr><tr><td>5</td><td>8</td><td>3</td><td>40</td><td>5</td><td>8</td></tr></tbody></table>

## 9.6 Power dissipation

The peripheral electronics will be in thermal contact with the cooling plates acting as pre-heaters for the CO₂ cooling system (Section 11.3). The dominant source of the power dissipation on the PEBs is the power loss in the DC-DC converters. With an average power consumption of 1.1 W per ALTIROC ASIC (Figure 11.4), the total required power delivered to the ASICs from the DC-DC converters including power losses in the flex cables will be 4.9 kW per double sided layer. With 72% efficiency at -30 °C and 3 A current, the power loss due to the ASIC supplies will be 1.9 kW per double sided layer. Including an estimated power consumption of 300 W per double sided layer for the lpGBTs and VTRx, the total power dissipation of the peripheral electronics will be 2.2 kW per double sided layer. The total power dissipation will be 4.4 kW per end-cap. Since most of the detectors components do not yet exist, a careful re-evaluation of the expected power dissipation will be done based on the first prototypes.

## 9.7 Roadmap towards PEB production

Following the prototype of the PEBs in the demonstrator program, a complete PCB design of a real size PEB is expected to be released at the beginning of 2021 after the SPR. It may be followed by a second real size prototype with minor modifications in 2021, after the PDR, that is expected in Q3 2021 as indicated in Figure 15.4. The pre-production of the full-size PCB is expected between May 2022 and November 2022, just after the FDR review. The
## 9.7 Roadmap towards PEB production

PRR, expected in Q4 2022, should give the green light for the final PCB production. The production, including the QA to be done by the Institutes is expected to take place between December 2022 and March 2025.

The PEBs use the rigid-flex PCB technology to integrate up to 6 flex cable ends from modules in the outer ring directly to save the space. After pre-production, a burn-in test will be performed to evaluate the product life and to identify any potential problems. During the mass-production, an accelerated ageing temperature test will be performed in batches to find the early failure.
<figure><img src="image_145.png" /></figure>
# 10 DAQ, calibration, luminosity and control

## 10.1 DAQ interface

The HGTD data acquisition system will be embedded in the ATLAS DAQ common read-out. The proposed HGTD architecture is shown in Figure 10.1 and can be divided in two main blocks: on-detector electronics located in the experimental hall and off-detector electronics located in the USA15 counting room. The on-detector electronics consist of ALTIROC modules connected via flex cable to the Peripheral Electronics Board, as described in Chapter 9.

The interface between on-detector and off-detector electronics is performed via optical links using lpGBT chip set and VTRx+ optoelectronics, which provides different data paths for Timing, Trigger and Control (TTC), DAQ and DCS. Two optical links with different purpose data streams are proposed: the main data stream that provides time-over-threshold (TOT) and time-of-arrival (TOA) information per triggered event and the luminosity stream that contains bunch-by-bunch hit information for luminosity measurements. These two different data streams are needed in order to disentangle the standardized format for the ATLAS dataflow driven by the main data stream and the custom luminosity stream which requires different processing. The main data stream is used for the propagation of clock, fast commands and configuration to the modules, as well as the data information for the ATLAS event processor. The luminosity stream only sends hit information through the uplink and will be described in Section 10.3.7.

### 10.1.1 Off-detector electronics

The off-detector electronics is based on the general-purpose FELIX system [89], which is the main interface between the off-detector back-end and the on-detector electronics. The proposed back-end architecture is shown in Figure 10.2. FELIX receives event data from the on-detector electronics and transmits them to the Data Handler via multi gigabit network. In addition, FELIX interfaces to the TTC system via the Local Trigger Interface (LTI) and to DCS for control, configuration and monitoring.

The FELIX downlink will follow lpGBT encoding, which is composed of 64-bits frames that are transmitted at every LHC bunch crossing period with a data rate of 2.56 Gbit s⁻¹. The
10 DAQ, calibration, luminosity and control

<figure><img src="image_146.png" /><figcaption>Figure 10.1: Data transmission paths among the ALTIROC, Peripheral Electronics Board (PEB), and DAQ components for hit data, luminosity data, clock, fast commands, and DCS/slow controls.</figcaption></figure>

clock is propagated to the lpGBT and thus to the modules by sampling the data stream. The downlink frame has different fields for data (fast commands), internal and external configuration meant for lpGBT, module and DCS handling. The uplink will also follow lpGBT encoding with a data rate of 10.24 Gbit s⁻¹, the different frame fields for data, configuration and DCS will be decoded in the FELIX board. Upstream, the data will be forwarded to the Data Handler using multi-gigabit network. In addition, monitoring information, like errors and timing will be computed in FELIX and will be sent to the monitoring unit together with a prescaled sample of the events. The monitoring unit will receive specific HGTD data via multi-gigabit network, it will decode and compute HGTD monitoring information that will be included in the global ATLAS on-line monitoring.

The Data Handler will receive data from FELIX via a multi-gigabit network. It will decode HGTD specific information providing event building and monitoring within a common DAQ infrastructure [59]. The data will be sent to the Dataflow system for further processing by the Event Filter. The event size is estimated to be 250 kB on average, with a range between
## 10.1 DAQ interface

<figure><img src="image_147.png" /><figcaption>Figure 10.2: Proposed off-detector back-end architecture for Phase II. Plot taken from [59].</figcaption></figure>

150 and 350 kB. In addition, the Data Handler will also receive trigger information via FELIX for monitoring and automatic recoveries. On the other hand, a software application called HGTD Controller, running in a dedicated computer will be used to manage the module and lpGBT configuration. The Controller will be also used to manage HGTD calibrations via dedicated software that will be described in the following section.

Requirements on the number of FELIX boards are set by the number of optical links and it is driven by the HGTD layout. Current estimates call for a total of 48 FELIX I/O cards and 48 Data Handlers for the main data stream. The luminosity back-end electronics will require 32 FELIX I/O cards.

### 10.1.2 Calibration and timing

Regular calibrations will be performed in HGTD in which different parameters like TOA and TOT will be monitored and tuned. A dedicated HGTD software running on the HGTD Controller will be used for this purpose. The calibration procedure is shown in Figure 10.3, it will consist of different nested loops with a specific module configuration followed by
## 10 DAQ, calibration, luminosity and control

a calibration pulse and a trigger command with a proper timing. The HGTD Controller will interface with FELIX for the handling of the module configuration and generation of a particular bitstream for the fast commands. Downstream the event data will be processed and stored for a further analysis and may be used as input inside the nested loop for tuning purposes.

During the calibration procedure 3.4 million of electrical channels have to be readout, which correspond to 11 MB per event and can surpass TDAQ infrastructure limitations for HGTD. In order to reduce the event size, several pixels inside and ASIC will not be read-out during the calibration loop using a particular mask pattern, the so-called mask step. The mask step will be added as a nested loop inside the calibration procedure as shown in Figure 10.3, in which several pixels will be masked in every step loop. For instance, while using 45 mask steps, which correspond to 5 pixels being readout per ASIC at every trigger, the event size can be reduced to 250 kB per event and thus matching HGTD specifications. Another limitation might arise from the data processing in the Data Handler, which can be avoided by optimizing the time delay between two consecutive triggers, however it may slow down the calibration procedure. The implementation of a histogramming unit inside FELIX will help to overcome these limitations by speeding up the calibration procedure and will be investigated. Nevertheless, the calibration procedure described before for entire HGTD should not last more than 5 minutes.

<figure><img src="image_148.png" /><figcaption>Figure 10.3: Diagram of the proposed calibration procedure for HGTD.</figcaption></figure>

Accurate timing for the modules is critical for operation. For this purpose, dedicated timing calibrations will be performed. In the first stage, the detector timing will be adjusted using a standard calibration procedure. It will consist of injection of different charges while looping over coarse and fine delay DAC values of the TDC. The quantisation step of the TOA in the TDC is 20 ps inside the 2.5 ns readout window. Moreover, the phase shifter inside the ALTIROC ASIC with a 100 ps resolution and 8 ns window has to be adjusted. After the calibration procedure, the delay values which set the 7-bit TOA in the middle range will be selected. In a second stage, the detector will be timed during stable beams by using dedicated LHC fills with a small number of isolated bunches, similar to the LHC Run 1 and
Run 2 fills used for Pixel and SCT timing scans performed during the LHC intensity ramp-up period. During these fills different delay values of the phase shifter inside the lpGBT will be scanned. This procedure will allow a global shift of the clock provided by lpGBT with a 50 ps step and 25 ns window. Using this methodology, the timing on the detector can be properly adjusted while the different operational parameters of the TDC remains unchanged. The data will be analyzed offline and the delays that ensure the proper timing will be selected. Further timing corrections taking into account clock jitter variations will be described in the following section.

## 10.2 Timing correction

Despite regular calibrations and timing adjustments of the detector, dynamic and static contributions to the clock have to be taken into account and will be described in this section. The master clock will be distributed to the lpGBT downlinks and then to the individual ALTIROC readout chips, in which a clock tree will be used to distribute the clock as uniformly as possible. Any temporal or spatial variation in the time discriminator may compromise the ultimate resolution of the detector unless it is understood and controlled.

The sensors themselves will have a resolution as good as 35 ps per hit, as described in Chapter 5. The contributions to the time resolution from the on-detector electronics (UX15) and from the clock distribution (USA15) has to be smaller than 35 ps. For instance, the clock dispersion for HGTD should be less than 15 ps across a wide range of frequencies and over the detector acceptance. Static contributions to the timing resolution, i.e. those fixed by geometry or varying on time scales longer than a run, include the time-of-flight and detector alignment; the propagation times to distribute the clock to each ASIC as a whole; and non-uniform clock propagation paths within an ASIC to each TDC. Dynamic contributions, like the variation of the clock with time, can occur through a variety of mechanisms across a wide range of frequencies, including high-frequency jitter, noise in the flex cables, and low-frequency day/night temperature changes. These effects must be monitored and calibrated to minimise static and dynamic contributions to the timing measurements. In the case of dynamic contributions, sufficient data may not be recorded to calibrate away fast effects, and therefore in this section we study how to determine the timing correction in real-time using all of the data flow.

For relativistic particles produced in an LHC collision, the time-of-arrival distribution of each measurement channel will consist of a Gaussian core derived from the time dispersion of the LHC collisions convolved with the combined hit time resolution of the sensor and electronics, as shown in Figure 10.4. The mean of the distribution encodes information on the relationships between the global LHC clock on arrival to ATLAS, the mean LHC collision time for a given bunch, and the reference clock phase at a given TDC. This mean shifts from zero through the cumulative effects of time-of-flight, clock propagation delays, and dynamic
10 DAQ, calibration, luminosity and control

shifts of the clock phase during data-taking. Assuming that the relationship between the clock at the TDC and the LHC clock is stable within a given time interval, data collected during the interval can be used to sample the $t_{hit}$ distribution and estimate its mean, $t_0$. This mean can then be used to correct the cumulative time offset of each channel individually.

Assuming a trigger rate of 1 MHz and 100 ms of data collection, the $t_0$ can be measured with a precision of 8 ps for a single channel at 150 mm radius. If $t_0$ is calculated on a per-ALTIROC level, combining the hits of up to 225 channels, the same precision can be reached in 2 ms. Integration times are shown in Table 10.1.

<table><caption>Table 10.1: Precision of the $t_0$ determination, $\sigma(t_0)$, vs integration time $T_{int}$</caption><thead><tr><th>Radius [mm]</th><th>150</th><th>250</th><th>350</th><th>450</th><th>550</th></tr></thead><tbody><tr><td>σ(t<sub>0</sub>) after T<sub>int</sub> = 100 ms for 1 channel</td><td>8 ps</td><td>12 ps</td><td>20 ps</td><td>29 ps</td><td>44 ps</td></tr><tr><td>σ(t<sub>0</sub>) after T<sub>int</sub> = 100 ms for 15 × 15 channels</td><td>0.6 ps</td><td>1.0 ps</td><td>1.7 ps</td><td>2.6 ps</td><td>4.2 ps</td></tr><tr><td>T<sub>int</sub> required for σ(t<sub>0</sub>) < 5 ps for 15 × 15 channels</td><td>2 ms</td><td>5 ms</td><td>13 ms</td><td>38 ms</td><td>92 ms</td></tr></tbody></table>

### 10.2.1 Sources of clock jitter

The data path from the ALTIROC up to the DAQ is shown in Figure 10.1 and described in Section 10.1. Different contributions to the clock jitter are expected in the readout system:

1. Front-end electronics: the clock distribution within the ALTIROC to each TDC will be shifted due to path-length differences and possible internal jitter. A conservative random Gaussian-distributed 5 ps jitter is included to account for jitter in the ALTIROC.

2. FLEX cable: it is made of Kapton and copper, and it could pick up noise from the environment and might have some inherent time jitter performance. A random Gaussian-distributed 5 ps jitter is included to account for jitter in the FLEX.

3. lpGBT: a preliminary measurement of the lpGBT clock performance in [90] indicated that a large non-Gaussian deterministic time jitter might be expected for the lpGBT. However, any front-end chip with a phase-locked loop can filter this effect to a small 2.2 ps jitter. Both of these scenarios are included in the $t_0$ calibrations study, and are shown in Figure 10.5.

4. FELIX: the clock jitter from the FELIX system will depend on the final chips used and bandwidth filtering applied, as studied in [91]. A conservative 5.2 ps jitter is added to represent the worst jitter expected for the FELIX.

Additional sources of timing jitter and $t_0$ variation are expected to affect the $t_{hit}$ measurement and are included in this study. The LHC radio frequency systems which compensate the beam loading and maintain bucket stability result in a periodic collision point time shift
in the ATLAS Detector. The variation in the average time of collision with bunch number was studied in [92], and the expected bunch crossing time offset for the ATLAS detector is included as a bunch-dependent variation. The collision time is expected to shift by a few ps per bunch, but can be corrected to a jitter in the order of 5 ps. Finally, a time-of-flight variation is added as a static radially-dependent offset from 0 to 70 ps as a function of sensor radius.

<figure><img src="image_149.png" /><figcaption>Figure 10.4: Hit time distribution before (red) and after (blue) the timing correction procedure, corresponding to a $t_0$ of (48 ± 369) ps and (-1 ± 363) ps respectively. The $t_0$ offset can be recovered after applying the timing correction, while the RMS of the distribution is driven by the time dispersion of the hits in the entire HGTD. Non-Gaussian tails arise from late particles, backscatter, and other effects. The hit time distribution is obtained from the HGTD simulation described in Section 3.1.</figcaption></figure>

<figure><img src="image_150.png" /><figcaption>Figure 10.5: Timing jitter distribution assumed for the lpGBT in the corrected (blue) and uncorrected (red) scenarios. These distributions are approximations of the timing jitter expected in the lpGBT.</figcaption></figure>

Random event-by-event fluctuations cannot be calibrated away, although they are included as part of the hit time resolution. Instead, the performance of the timing correction procedure
10 DAQ, calibration, luminosity and control

will depend on how many longer-term variations (heat cycles or other effects) affect the time
measurement, which are largely unknown. For the purpose of this study, these unknown
longer-term variations are parameterised as a sinusoidally varying 100 ps time offset with
variable period.

10.2.2 Timing correction procedure

The hit time offset $t_0$ is calculated at regular intervals as the arithmetic mean of the $t_{\text{hit}}$ distribution. The length of the time interval strongly affects the performance of the timing correction. The $t_0$ can be calculated to better precision with averaging over a longer time, but shorter times can correct for faster variations. The timing can be computed by forwarding a particular data stream from FELIX to a monitoring unit in which the $t_{\text{hit}}$ will be averaged and then applied offline. Alternatively, the computing of the average $t_0$ inside FELIX will be investigated.

The hit time distribution before and after the timing correction is shown in Figure 10.4. Figure 10.6 shows the timing performance as a function of the integration time and the variation period for channels at three different radii, calculating the $t_0$ correction from a 15 × 15 grid of channels, and including all of the sources of time variation discussed above, including the sinusoidally varying 100 ps offset with period plotted along the x-axis. Smaller calibration window sizes can reduce $t_0$ jitter when shorter-term variations affect the hit time. However, longer calibration windows, which can collect more statistics and therefore more precisely determine $t_0$, result in a better hit time correction. Variations with period smaller than 1 ms cannot be corrected with this procedure because of insufficient statistics, and variations with period greater than 20 ms can be corrected in all regions of the detector. The timing correction procedure should also work well for longer-term variations on the scale of $1 \times 10^5$ s (1 day).

The procedure outlined above and the corresponding results are a preliminary plan for
the timing correction scheme using conservative values of clock jitter contributions. Con-
servative estimates for the expected ALTIROC and FLEX timing jitter were used, and the
study will be updated when final numbers are available. When accounting for the expec-
ted jitter from components of the readout system and LHC bunch crossing time drift, the
clock jitter of approximately 15 ps can be reached, in accord with the specifications outlined
in Section 4.2.2. If additional unknown sources of jitter are included, the timing correction
procedure can reduce the total jitter to 20 ps for the time variations studied and thus fulfilling
HGTD requirements of 35 ps driven by the intrinsic resolution of the sensors. In general,
more accurate corrections can be calculated to correct for longer-term variations, and should
result in smaller total clock jitter.

The timing correction procedure assumes that time offsets across different channels are not
correlated. However, the time offsets in each channel are expected to be somewhat correlated
## 10.2 Timing correction

<figure><img src="image_151.png" /></figure>

Figure 10.6: Hit time resolution RMS ($t_{\text{smear}} - t_{\text{reco}}$) after the timing correction procedure as a function of the variation period, and for several different choices of calibration window time, shown for $r = 150$ mm, $R = 350$ mm, and $r = 450$ mm. $t_{\text{reco}}$ is the hit time taken from simulation and includes inherent hit time resolution effects from the sensor and electronics and the collision time spread. The $t_{\text{smear}}$ term adds additional sources of time jitter from the ASIC, FELIX, flex cable, lpGBT, and ATLAS collision time drift, with an additional sinusoidally varying 100 ps offset of variable period. The time jitter without any correction applied is shown as the dashed line, and the time jitter without any long-term timing variation effects is shown as the dotted-dashed line. For a variation period of greater than 20 ms, and with the right choice of calibration window size, the calibration procedure will always improve the $t_0$ precision.
from both global (i.e. offsets in the LHC collision time and the ATLAS clock) and local effects
(i.e. tree structure of the clock distribution creates correlations between modules of the same
branch), the timing correction procedure assumes the worst-case scenario of no correlation
and applies corrections per-ASIC level. Timing corrections targeting global or more broadly
correlated effects can combine hits from more channels, achieving more statistical precision
and a better correction across even shorter timescales. Furthermore, the $t_0$ jitter at the ASIC
level can be corrected on a per-channel basis by using the hit times of single pixels, although
a factor of 225 would be lost in statistics.

## 10.3 Luminosity

The measurement of the integrated luminosity delivered by the LHC is critical for almost all physics analyses, as discussed in Section 3.4.4.

Any luminosity detector (luminometer) attempts to measure some observable which is assumed to be proportional to the instantaneous luminosity, or equivalently, to the average number of inelastic interactions per bunch crossing $\langle \mu \rangle$. Conceptually simple examples are the average number of charged-particle tracks reconstructed in the inner tracker [93] or the noise-corrected number of clusters in the pixel detector [94]. In the early years of LHC operation, many luminometers used the so-called *event-counting* method [95], also known as *zero counting*, which exploits Poisson statistics to infer the pileup parameter $\mu$ from the fraction of bunch crossings in which no interaction was detected. As the mean $\mu$ of the Poisson distribution increases, the fraction of bunch crossings with no detected interaction decreases, and eventually reaches zero. The $\mu$ value at which this saturation, or “zero starvation”, occurs depends on the geometrical acceptance and the efficiency of the luminometer considered. Already in LHC Run 2, the baseline ATLAS luminometer [96] was forced to exploit its 16-channel granularity to switch from event counting to hit counting. This latter method [95] applies a Poisson formalism very similar to that of event counting, to extract $\mu$ from the average number of detector hits recorded per bunch crossing; the finer the granularity of the luminometer, and the smaller the acceptance of its individual channels, the higher the pileup value at which the method eventually saturates. In the limit of a very large number of channels, as is the case in a pixelated detector such as the HGTD, the per-channel occupancy becomes small enough for the Poisson non-linearity to become almost negligible. The average number of hits in randomly selected colliding-bunch crossings then depends linearly on the luminosity (except perhaps at the highest $\mu$ values expected at the HL-LHC, where the hit-counting Poisson formalism may need to be invoked again).

The primary calibration technique to determine the absolute luminosity scale of a bunch-by-bunch luminometer employs dedicated van der Meer (vdM) scans [93] to infer the delivered luminosity at one point in time from the measured parameters (primarily the intensity and the transverse area) of the colliding bunches. The conversion factor from luminometer
counting rate to measured luminosity is then determined by comparing the luminosity computed from the above-mentioned accelerator parameters to the visible, uncalibrated interaction rate reported by the luminometer at the peak of the beam-separation scans. The beam conditions during vdM scans are different from those in normal physics operation, with lower bunch intensities and only a few tens of widely spaced bunches circulating. These conditions, which are optimized to reduce various systematic uncertainties in the calibration procedure [97], typically result in a pileup parameter $\mu$ of about 0.5 at the peak of the scans, and as low as $\mu \sim 2 \times 10^{-5}$ in the tails of the scans, where the beams are barely overlapping. Since the same luminosity-calibration procedure is foreseen at the HL-LHC, the luminometer response will have to remain linear over seven orders of magnitude in $\mu$, from vdM conditions ($\mu \sim 2 \times 10^{-5}$ to $\mu \sim 0.5$) up to high-luminosity physics data taking at $\langle\mu\rangle$ of around 200.

The online and offline environments impose different and sometimes conflicting constraints on the luminometers and the associated luminosity-determination methods, with processing speed being of the essence during data taking (possibly at the expense of absolute accuracy), and offline luminosity requiring the best possible precision on much longer time scales. For instance, track counting [93], which proved essential to control the dominant luminosity uncertainties in both LHC Runs 1 and 2, has only be used offline so far since it requires a dedicated, randomly-triggered event stream that must be subjected to extensive offline analysis before usable luminosity values can be provided.

Bunch-by-bunch luminosity estimates are required not only for offline physics analysis, but also in the online environment, for instance to apply bunch- and $\mu$-dependent corrections to calorimeter data in the high-level trigger algorithms; to optimize the trigger menus on the fly; and to monitor, analyze and improve the accelerator performance over the long term. An additional requirement is the availability of a bunch-integrated, fast and reasonably accurate luminosity measurement, provided at $\sim 1$ Hz as input to the collision-optimization and luminosity-leveling accelerator protocols.

As discussed further in Section 10.3.5, the precision of the offline determination of the integrated luminosity has so far been limited not by statistics, but by systematic uncertainties. An essential lesson from LHC Runs 1 and 2 is that the dominant systematic uncertainties can only be determined, or at least constrained, by confronting the response of a redundant set of luminometers, each based on a different technology, with complementary capabilities and independent instrumental biases.

### 10.3.1 HGTD as a luminometer

As a fast high-granularity detector in the forward region, the HGTD provides unique capabilities for measuring the luminosity at the HL-LHC. The idea for using HGTD as a luminometer is straightforward: the occupancy will be linearly correlated with the interaction rate (i.e. the
luminosity). The high granularity gives a low occupancy, and therefore excellent linearity between the average number of hits and the average number of simultaneous *pp* interactions over the full range of luminosity expected at the HL-LHC, as discussed in Section 10.3.2. With detector signal durations in the few-ns range, the charged-particle multiplicities within the acceptance can be determined accurately for each individual bunch crossing separately. With the occupancy information sent at 40 MHz, i.e. for every bunch crossing independent of the ATLAS trigger (further discussed in Section 10.3.6), the HGTD will provide both online and offline per-BCID luminosity measurements. The measurement is made in a reduced $|η|$ range, and in this proposal the plan is to read out the ASICs for sensors at $430 \text{ mm} < r < 640 \text{ mm}$ (equivalent to $2.4 < |η| < 2.8$) for the luminosity determination. The HGTD is designed to have capabilities to constrain many systematic uncertainties by itself, with the goal of reducing the total uncertainty on the integrated luminosity in HL-LHC compared to Run 2 despite the much harsher experimental conditions, as is discussed in Section 10.3.4 and Section 10.3.5.

## 10.3.2 Linearity of the luminosity determination

For the $|η|$ range $2.4 < |η| < 2.8$, the average number of hits per inelastic *pp* collision for one double-sided layer on one side of the interaction point is 14.7, and approximately 16.0% of these collisions result in 0 hits. Figure 10.7(a) shows the average number of hits per bunch crossing registered in the first double-sided HGTD layer (both sides of the innermost cooling plate) as a function of the number of simultaneous inelastic *pp* interactions. The black points at number of interactions of 1 and between 175-225 are determined from fully simulated minimum-bias events with $\mu = 1$ and $\langle\mu\rangle$ in the range 190-210, respectively. The green stars represent results from a toy MC where several $\mu = 1$ minimum-bias events have been overlaid to produce samples with intermediate numbers of interactions, while making sure not to double-count multiple hits in the same channel. A linear, ideal, relationship between the mean number of hits and the number of interactions (blue dashed line), derived from the fully simulated sample at $\mu = 1$, is extrapolated to the $\mu \sim 200$ region where its prediction can be compared to the hit multiplicities extracted from fully simulated high-pileup samples. The small discrepancy, of approximately 0.6%, between the blue dashed line and the simulated points in the bottom left frame around $\mu \approx 200$ is mostly attributed to multiple particles hitting the same pad. The red line (labelled "Linear + multiple hit correction") is the result of correcting the linear function with the contribution from multiple particles hitting the same pad. A residual 0.2% discrepancy between the corrected function and the fully simulated MC events around $\mu \approx 200$ can be observed in the bottom frame, this can be attributed to all the differences between the toy MC model and the fully simulated sample. Examples of such differences are, for example, the simulation of out-of-time pileup and multiple below-threshold energy deposits from different proton-proton collisions superimposing and generating above-threshold hits.
<figure><img src="image_152.png" /><figcaption>Figure 10.7: Left: mean number of HGTD hits per bunch crossing as a function of the number of interactions. The black points are the results from fully simulated samples. The green stars represent results from a toy MC where several $\mu = 1$ minimum-bias events have been overlaid to produce samples with intermediate numbers of interactions. The blue dashed line is the ideal linear relationship between the mean number of hits and the number of interactions, derived from the $\mu = 1$ sample. The red line is the result of adding a correction from multiple particles hitting the same pad to the linear parameterisation. In the bottom panel, both lines can be compared to the fully simulated samples at $\mu \sim 200$ (see the text for a full description of the plot). Right: pileup dependence of the statistical uncertainty per BCID, for an integration time of 1 s.</figcaption></figure>

### 10.3.3 Statistical precision of the luminosity determination

To confirm that statistical uncertainties are small for the online luminosity measurements, the size of the uncertainty has been studied as a function of the duration of the averaging period and $\langle\mu\rangle$. The average number of hits per bunch crossing is simulated using a toy Monte-Carlo method with inputs extracted from fully simulated samples. For each value of $\langle\mu\rangle$, a random number of $pp$ interactions is drawn from a Poisson distribution with a mean equal to $\langle\mu\rangle$. For each $pp$ interaction, a number of HGTD hits is then generated randomly based on the distribution of hits per $pp$ interaction extracted from full-simulation samples. By repeating this process 11 000 times (for the number of turns the LHC beams will make in one second) and averaging the number of hits, the statistical precision achieved in each individual BCID during 1 s of LHC running is emulated. Figure 10.7(b) shows the relative uncertainty expected from statistical fluctuations as a function of $\langle\mu\rangle$ using this method. The coverage of $2.4 < |\eta| < 2.8$ presented here gives a statistical uncertainty of 1.4% at $\langle\mu\rangle = 1$ and 14.3% at $\langle\mu\rangle = 0.01$. For measurements in the low-$\mu$ regime (e.g. during van der Meer scans) better precision can be achieved through a longer averaging time.
10.3.4 Noise and afterglow subtraction

The HGTD is affected by three distinct background contributions to the luminosity sig-
nal: single-beam backgrounds, instrumental noise, and afterglow, in order of increasing
importance.

Single-beam background arises from activity correlated with the passage of a single beam
through the detector. This activity is caused by shower debris from beam-halo particles, that
impinge on the luminosity detectors in time with the circulating bunch. Although its impact
remains to be simulated, single-beam background is expected to be close to negligible (on
the scale of the luminosity signal), based not only on experience with Run-1 and Run-2
luminometers, but also on HGTD-specific features: on the incoming-beam side, not only
should the shielding provided by the end-cap calorimeter absorb all of the high-radius
backgrounds (except for a few muons), but the surviving background particles will be out-
of-time by several nanoseconds with respect to the collision products originating from the IP.
Residual HGTD backgrounds on the outgoing-beam side, if any, can be roughly estimated
from a few non-colliding bunches injected in each ring for this specific purpose, as was
frequently done during LHC Runs 1 and 2.

Instrumental noise can arise from thermal noise in detector electronics, or from high-rate
contributions from "noisy pixels" (such as caused by radiation-induced "single-event upsets").
Thermal-noise (and, up to a point, noisy-pixel) contributions can be subtracted by the same
method as that used for afterglow, which is discussed in the next paragraph. Alternatively,
noisy pixels can be masked, if only to prevent excessive dataflow rates (in which case their
unavailability will have to be accounted for when normalizing the measured hit counts).

As detailed in [95], all Run-2 bunch-by-bunch luminometers (with the exception of track
counting) observe some activity in the BCIDs immediately following a collision, which in
later BCIDs decays to a baseline value with several different time constants. This afterglow
is attributed to slow particles (such as neutrons) and to delayed decays (e.g. from stopped
muons), that originate from the hadronic cascades initiated by pp collision products. For a
given bunch pattern, the afterglow level is observed to be proportional to the luminosity
in the preceding colliding bunches. Its magnitude relative to the luminosity signal, and its
time structure, both depend on the sensitivity of the luminometer considered to the particle
composition and the energy spectrum of the afterglow (and therefore on the technology used
by that luminometer), as well as on the location and the physical environment (geometry,
chemical composition of neighbouring equipment) in which this luminometer operates. The
magnitude of the afterglow contamination observed in Runs 1 and 2 varies widely, from
$10^{-4}$ for LUCID in vdM scans, to 0.2-0.4% for BCM in high-$\mu$ bunch trains; it can be as high
as 10% in pixel detectors during routine physics running, therefore requiring a delicate
correction that contributes sizeably to the total luminosity uncertainty.

The time resolution of the HGTD is a unique capability that is essential to mitigate the large
impact of instrumental noise and afterglow intrinsic to the pixel-cluster counting technique. As described in Section 6.1, and illustrated in Figure 6.2, the ASIC will send occupancy information in two different time windows:

* a central time window, 3.125 ns wide, centred on the nominal bunch crossing time;

* a sideband window, nominally covering 3.125 ns before the central time window and 3.125 ns after the central time window.

This double-sideband window will be programmable. Here it has been chosen symmetric, such that its occupancy provides, after appropriate scaling, an estimate of the noise and afterglow contributions as interpolated under the luminosity signal in the central time window, separately for each BCID. This ability to perform an in-situ measurement of the noise and afterglow level for each bunch crossing, using data from empty RF buckets just before and after the filled bucket within the same nominally filled 25-ns bunch slot, is a unique capability of the HGTD compared to other luminometers.

### 10.3.5 Systematic uncertainties affecting the luminosity determination

A detailed discussion of the systematic uncertainties affecting the 2012 luminosity determination at $\sqrt{s} = 8$ TeV is presented in [93]; the sources and the magnitude of the luminosity uncertainties in LHC Run 2 at $\sqrt{s} = 13$ TeV are comparable [46]. Of the dominant uncertainties, two are luminometer-specific (rather than related to, for instance, beam conditions or accelerator instrumentation): the time stability of the luminometer response, and the calibration transfer.

The time stability of relative-luminosity measurements is potentially affected by different sources, depending on the time scale considered.

* *Long-term stability* refers to potential drifts of the luminometer response on the time scale of days to months, compared to its response at the time of the vdM-calibration session. Such drifts have been seen to arise, for instance, from gain fluctuations in, or flux-induced ageing of, LUCID photomultipliers (PMTs); darkening of TILE scintillators; cumulative radiation damage to inner-tracker silicon-strip or pixel modules; or unaccounted-for dead or inefficient channels. In LHC Runs 1 and 2, this class of effects contributed from 0.5% to 1.3% to the systematic luminosity uncertainty, a large number compared to the luminosity-precision goal of 1% at the HL-LHC.

* *In-run stability* refers to variations in luminometer response on the time scale of one ATLAS run (a few hours). The reference ATLAS luminometers (BCM in most of Run 1, LUCID in Run 2) proved mostly immune to such drifts. In contrast, pixel-cluster-counting-based luminosity measurements were significantly more sensitive, typically because of unaccounted-for changes in effective coverage (noisy, misbehaving or automatically disabled modules). Because the luminosity, and therefore the pileup
parameter $\mu$, typically decays during an LHC fill, such drifts are difficult to disentangle
from a genuine $\mu$-dependence of the detector response. It is therefore essential, for
pixel-counting methods, to keep track of variations in both the number and the radial
location of misbehaving channels on the time scale of a few minutes: for instance,
a few noisy pixels that suddenly start firing at a high rate may bias the luminosity
measurement and prove hard to correct for after the fact.

The long-term stability and the in-run stability of the HGTD will be monitored by offline data quality analysis, similarly to what is done for the current Pixel and SCT detectors. This includes both prompt analysis of the recorded data during the calibration loop and thorough analysis of data taken over timespans of months or a full year. Detector elements that are found to have non-constant hit efficiency can then be excluded when determining the final luminosity estimates.

The *calibration-transfer uncertainty*, which in LHC Run 2 typically amounted to a 1.0–1.5% uncertainty on the absolute luminosity scale, refers to how precisely one controls potential shifts in detector response, that occur between the beam conditions of vdM scans ($\langle\mu\rangle \sim 0.5$, a few tens of low-intensity isolated bunches, no bunch trains) and those of physics data-taking ($\langle\mu\rangle \sim 200$, hundreds to thousands of high-intensity bunches grouped in trains with diverse patterns). Such shifts can arise, for instance, from rate-dependent effects in solid-state sensors or LUCID photomultipliers; from bunch-pattern-dependent “out-of-time electronic pileup” (in which the electrical signal from a given 25 ns bunch slot leaks into the following bunch slot); in the case of track counting, from a residual pileup dependence of the tracking efficiency; or, in randomly triggered readouts of bunch-integrated inner-tracker luminosity data, from subtle deadtime effects through which a higher-luminosity bunch can shadow a small fraction of the triggers in the immediately following bunch slot. All of these effects have been observed at some level in Run 2 at $\langle\mu\rangle \sim 50$, and required $\mu$- and time-dependent corrections to the luminosity scale that could exceed 10% during high-luminosity operation.

The HGTD has several characteristics that will aid in constraining, and hopefully reducing, such systematic uncertainties. To better monitor the time stability, the region instrumented with the luminosity readout will be segmented into 16 sub-regions, with 4 divisions in $\eta$ and 4 divisions in $\phi$, as shown in Figure 10.8. Each region has sufficient statistical sensitivity to determine the luminosity independently of the other regions. Regions at different $\eta$ will accrue radiation damage at a different rate, therefore comparing their response can help determine the degradation due to radiation. The partitioning of the regions can be controlled in software running in the Luminosity Software, described further in Section 10.3.8, so that a different layout than the one described here can be used if found to be more optimal.

While such internal consistency checks will undoubtedly prove valuable, they are unlikely
to be sufficient, if only because any bias or drift that is correlated across all 16 regions
remains undetectable by the HGTD alone. Experience at LHC has repeatedly shown that
<figure><img src="image_153.png" /><figcaption>Figure 10.8: Sketch of the partitioning of the sensors into 16 regions for the luminosity determination. Each of the regions can be used to determine the luminosity independently of the others. Regions at different radii will be subject to different levels of radiation over time.</figcaption></figure>

independent checks based on several luminometers using different technologies are essential for controlling the systematic uncertainties to the level required by the physics program.

Built into the HGTD design are several features that are expected to reduce the magnitude of the calibration-transfer correction (if any), as well as help constrain the associated uncertainties:

* the pixel-cluster counting technique is intrinsically linear, and only very small $\mu$-dependent corrections are expected to be necessary at the highest bunch luminosities expected at the HL-LHC, as was illustrated in Figure 10.7(a);

* for a given bunch pattern, the most likely reasons for the hit count to deviate from strict proportionality to the true luminosity are afterglow and instrumental noise. The exquisite time resolution of the HGTD, combined with the methodology outlined in Section 10.3.4, provides a unique strategy to control these effects to the level needed;

* the most likely reason for a bunch-pattern dependence of the HGTD hit count is again the afterglow, the magnitude of which is sensitive to the length of, and the separation between, bunch trains. The above-mentioned afterglow subtraction at the bunch-by-bunch level should eliminate this potential bias;

* electronic out-of-time pileup from one BCID to the next is presumably eliminated by the extremely short pulse duration of HGTD pixels;

* eliminating deadtime effects associated with large $\mu$ variations from one BCID to the next, is one of the motivations for the trigger-less, 40 MHz readout of the luminosity information discussed in Section 10.3.6.
10.3.6 Occupancy readout at 40 MHz

Experience with luminosity determination at the LHC shows that the capability to read out
a luminometer at 40 MHz, i.e. on every single bunch crossing, is critical to its function as
an independent device that must provide bunch-by-bunch (bbb) luminosity measurements,
with the best possible precision both online and offline. In LHC Runs 1 and 2, this require-
ment was satisfied only by LUCID and BCM; the fact that it was out of reach for track and
pixel-cluster counting methods proved a significant limitation to the final precision of the
integrated luminosity in both ATLAS and CMS in Run 2.

In view of the more exacting luminosity-precision requirements of the HL-LHC physics
program, the 40 MHz readout of the occupancy is key to a full exploitation of the HGTD
potential as a stand-alone, high-precision luminometer for both online and offline use. This
becomes apparent when one considers

* the unrivalled statistical power of reading out every single bunch crossing, thereby collecting, in a fully unbiased manner, all the potentially available luminosity data from every single bunch slot,

* the TDAQ implications of a readout triggered by sampling randomly selected colliding-bunch pairs,

* some of the requirements associated with the van der Meer calibration,

* use cases of bunch-by-bunch luminosity measurements in both the online and the offline environment, and

* some features specific to the HGTD-based luminosity determination.

If the luminosity measurement were to be carried out using a detector which is not read out
on every bunch crossing, the following considerations would have to be addressed.

* The luminosity must be determined from an unbiased sampling of collisions, therefore it is unlikely that data passing physics triggers can be used. Such triggers normally require a lot of activity in the detector, e.g. the presence of high momentum leptons or jets. They are typically sensitive to pileup effects, and therefore not representative of the luminosity; they also are severely statistics-limited.

* The traditional method for overcoming the trigger bias is to use a dedicated random trigger, sampling each bunch crossing evenly. The bandwidth for such a trigger comes at the expense of that available for physics, thus effectively representing a loss in data-taking efficiency.

* A random trigger does not result in a completely unbiased dataset for the luminosity determination. There is a shadowing effect from the standard trigger deadtime, in which more luminous bunches shadow collisions in subsequent, less luminous bunch
slots. The associated corrections are unlikely to be negligible for a bunch-integrated
measurement, but could be corrected for in a bunch-by-bunch measurement with the
knowledge of the number of times a bunch is sampled.

* Even if the luminosity extraction could be performed online using the luminosity back-end electronics to analyze Level-0 triggered data, it would reduce the available statistics by several orders of magnitude: this would make the HGTD inadequate as an online luminometer, as further argued below.

* If the luminosity-extraction analysis can only be carried out offline, the event data has to be saved to disk, further degrading the statistics usable for luminosity-related applications.

The vdM calibration technique requires evaluating, as a function of the transverse beam separation, the four-dimensional overlap integral (over *x*, *y*, *z* and time) of the proton-density distributions in each colliding-bunch pair. Since the proton population and the transverse-density distributions vary significantly from one bunch to the next, fitting a vdM scan curve obtained by summing the interaction rate over all colliding-bunch pairs (rather than fitting a separate scan curve for each pair) would result in unpredictable and non-reproducible biases to the absolute luminosity scale. This fundamental requirement, on its own, implies that the HGTD must provide statistically precise bunch-by-bunch luminosity measurements over the full *µ* range covered during a vdM scan (2 × 10⁻⁵ to 0.5).

The above span in interaction rate, combined with the LHC bunch-revolution frequency of 11 kHz and with a typical integration time of 60–100 s during individual vdM scan steps, implies that a readout based on randomly triggered colliding-bunch crossings would have to be restricted to a fraction of the available colliding-bunch pairs in order to accumulate data with per-bunch statistics sufficient for a vdM analysis. Triggering the HGTD readout during the vdM scan using some kind of independent track- or hit-multiplicity trigger is not optimal, since it requires determining the absolute efficiency of said trigger, at some cost in systematic uncertainty. While both of these techniques have been used successfully for track counting in 2012 vdM scans, they unavoidably degrade, at some level, the uncertainty affecting the bunch-averaged visible cross-section. This chain of arguments explains why, during LHC Run 2, no direct vdM calibration of track- nor pixel-cluster-counting algorithms was ever attempted by ATLAS. These inner-tracker-based luminosity algorithms were instead cross-calibrated to LUCID in data-taking at *µ* ~0.5 during the vdM session, thereby making their absolute calibration fully correlated with that of LUCID.

During both routine physics operation and during special runs, the need (both online and offline) for a luminosity readout that provides high statistics in each bunch slot over the full *µ* range is fundamentally related to the intrinsic variation of the emittance, bunch intensity and instantaneous luminosity across the colliding-bunch pairs. During Run 2, these bunch-by-bunch variations in the luminosity sometimes exceeded 20–30%.
10 DAQ, calibration, luminosity and control

In the present ATLAS online-luminosity architecture, bunch-by-bunch luminosity measure-
ments provide the basic input to the computation of the bunch-integrated luminosity value,
that is used, for instance, to select the most appropriate ATLAS trigger settings; inform
the online monitoring tools of various ATLAS subdetectors; optimize collisions; control
the luminosity-leveling protocols; monitor accelerator performance, etc. Depending on the
application considered, the required refresh times vary from one to a few tens of seconds.

In addition to a precise bunch-integrated measurement, bunch-by-bunch measurements that
are statistically stable (≪ 0.5%) and reasonably accurate on an absolute scale, are required
online for several purposes, such as:

* providing $\mu$-dependent corrections to calorimeter-based triggers, with a refresh rate of a few minutes;

* supplying the accelerator with diagnostics such as bunch-by-bunch specific-luminosity values, which offer a better estimate of the beam-averaged emittance than state-of-the-art accelerator instrumentation. Such diagnostics have proven essential to the steady improvement of LHC performance. They are needed not only during physics running for detailed analysis of accelerator operation, but also in real time with refresh rates of a few seconds for periodic emittance scans, as well as for some accelerator-development sessions, during which the beam parameters are tailored on a bunch-by-bunch basis and the required refresh rates are at the few-seconds level.

Use cases for bunch-by-bunch measurements in the offline environment include, for in-
stance:

* computing the bunch-integrated luminosity eventually used in physics analyses from the sum of per-bunch luminosity values, after recalibration and application of bunch-dependent corrections, such as residual *μ*-dependence or afterglow subtraction;

* refined $\mu$- (and therefore bunch-) dependent corrections to the cell-by-cell energy measurements in the liquid argon calorimeter;

* bunch-by-bunch comparisons of the relative consistency of the luminosity values across multiple luminometers. Such studies have revealed significant $\mu$- and bunch-position dependent biases in all the bunch-by-bunch luminometers available in Run 2, and again demonstrated that comparing independent luminometers is a key ingredient to precision luminosity measurements.

Finally, the potential use of the occupancy information in the Level-0 trigger outlined
in Section 10.3.11 is entirely dependent on the availability of dedicated occupancy data at
40 MHz.
### 10.3.7 Luminosity back-end electronics

For every bunch crossing of the LHC, each ASIC in the region $2.4 < |η| < 2.8$ will send occupancy counts in the central time window and in the sideband time window. These counts are encoded into 7 and 5 bits, respectively. In addition 4 bits are used for encoding, using the 6b8b encoding scheme, resulting in 16 bits sent per ASIC for every bunch crossing. Thus there is a steady data rate of 40 MHz times 16 bits, or $640 \text{ Mbit s}^{-1}$, from each ASIC. The luminosity data is sent via lpGBTs dedicated to the luminosity readout to the back-end electronics, requiring 152 lpGBTs for each of the four disks of the HGTD, i.e. 608 links for the whole detector. The data sent by the lpGBTs are collected by the luminosity back-end electronics, consisting of dedicated FELIX units. These units are separate from the FELIX units handling the timing data, as shown in Figure 10.1. Each FELIX I/O card can take up to 24 input fibres at $10 \text{ Gbit s}^{-1}$ (with two such I/O cards present in one FELIX unit). One FELIX I/O card will handle all the occupancy data from one quadrant of one single-sided layer (4 FELIX I/O cards per disk layer, 8 cards per double-layered disk, 32 FELIX I/O cards to handle all the occupancy data from the 4 HGTD disks). Each FELIX I/O card is connected to 133 modules, or equivalently 266 ASICs.

The luminosity back-end electronics aggregates the central time window data and the sideband data separately, for each ASIC separately and for each of the 3564 BCIDs of the LHC except one which is used to synchronise the data stream. The BCID used for synchronisation will be in the abort gap, where no collision data is expected. In total the FELIX card will keep track of $266 \times 2 \times 3563 \approx 1.90 \text{ million sums}$. The FELIX will store these sums in registers in the FPGAs, and update them continuously with the new data for every bunch crossing. If the data transfer speed between the FELIX cards and the host server allows it, an option would be to store and update the sums using software running on the host server instead of in firmware running on the FPGA which would give greater flexibility and ease maintenance. This option will be investigated further in the upcoming years.

The maximum number which can be obtained for the hit count sum in the central time window for a single BCID over a period of around one second (which is the maximum integration time considered before data is sent downstream), if every collision would saturate the maximum hit count of 127, is $40 \cdot 10^6/3564 \times 127 = 1,425,448$. This is a number which can safely be stored in 4 bytes. The amount of memory used to store all the sums is therefore at most $1.90 \times 4 = 7.6 \text{ MB}$, something which can safely be accommodated already in the existing versions of the FELIX FPGAs.

These sums are the raw data needed for determining the luminosity, which is only needed with a frequency of approximately once per second. Assuming that the luminosity data gets pushed out of the FELIX at a rate of 2 times per second, and using 4 bytes to store each of the integers, the total data rate out of the luminosity back-end electronics is only $7.6 \times 2 = 15.2 \text{ MB s}^{-1}$. Thus, the luminosity data represents a negligible strain on the network downstream of the back-end electronics, and the data flow is independent of the
10 DAQ, calibration, luminosity and control

trigger. The conversion from the occupancy sums to a calibrated luminosity will happen
in dedicated software algorithms. These software algorithms can run on any downstream
computer, most likely in the Luminosity Software.

10.3.8 Processing of the occupancy data in the Luminosity Software

The software running in the Luminosity Software will receive the occupancy sums for each ASIC as input, and by applying appropriate algorithms and calibrations convert these into an estimate for the luminosity. This corresponds approximately to some of the tasks performed by software called the Online Luminosity Calculator in Run 1 and Run 2.

The Luminosity Software will be responsible for aggregating data into time windows corresponding to ATLAS Luminosity Blocks (LB), typically of the order of one minute. A LB is the smallest unit of data for which the offline luminosity is determined. The raw counts for each of the ASICs for one LB will be stored in files with a dedicated format or a database for offline storage. This allows for exclusion of individual ASICs in the determination of the offline luminosity due to data quality issues discovered after dedicated analysis. In the current layout, there are 8,512 ASICs used for luminosity determination. If 4 bytes is used for each of the 2 sums for one ASIC, and separate sums are stored for each BCID, this corresponds to approximately 243 MB of data stored offline for each LB (or 4 MB s⁻¹ assuming a LB length of 60 seconds).

The Luminosity Software will also have the flexibility to combine several ASICs into regions which are large enough to be calibrated in the vdM scans, and which can be used to determine the luminosity independently of each other. One possible configuration of regions, dividing the disc into 16 partitions, was shown in Figure 10.8. Each such region would then combine the hit count information from many ASICs.

10.3.9 Per-event luminosity information stored in the ATLAS raw data

In the processing of the luminosity data by the back-end electronics, the per-event informa-
tion is lost when the data is aggregated. To allow for per-event occupancy data to be stored in
the raw data for events passing all the stages of the trigger, the luminosity back-end electron-
ics have to implement a buffer to store the data for each event separately, until a L0 trigger
accept is received and the corresponding occupancy information can be sent. Whether this
capability will be implemented, and per-event occupancy information will be recorded in
the ATLAS raw data, has not yet been decided. Eventual difficulties with synchronisation of
the data with the rest of the event will also have to be investigated. The per-event occupancy
in the central time window provides no unique information over what can be calculated
from the HGTD precision timing data (modulo the fact that the time windows used for the
timing and occupancy data are slightly different). It would merely serve as validation of
the luminosity and precision timing data, but it could be very beneficial for this purpose. The information about the occupancy in the sideband time window does provide unique information compared to the HGTD timing data, and could potentially have use cases in e.g. searches for new, slow-moving particles.

Assuming the same pipeline depth for the occupancy data as for the timing data buffered in the ASIC, the capacity to buffer per-event level data for 1,400 consecutive bunch crossings is needed. For each bunch crossing, each of the 266 ASICs sending data to one FELIX sends two bytes of data (16 bits). Adding an additional two bytes for header information for every ASIC, a total of 266 × 1400 × 4 ≈ 1.49 MB of memory is required in the FELIX FPGA. As was already discussed in Section 10.3.7, this can easily be accommodated by existing versions of the FPGAs.

Provided that the capability to buffer per-event luminosity data is implemented in the luminosity back-end electronics, the payload to be stored in the ATLAS raw data would be the occupancy data (16 bits) for each of the 8,512 ASICs used for the luminosity determination (approximately 17 kB per event).

### 10.3.10 Operation in non-Stable Beams conditions

As with other silicon sensor-based detectors close to the LHC beamline, the HGTD will only ramp up the full High Voltage on the sensors once Stable Beams have been declared, in order to avoid destroying the detector in case of catastrophic beam losses. At the same time, there is a need from the accelerator operations perspective to have an estimate of the luminosity at the ATLAS interaction point in conditions where Stable Beams have not been declared. This situation occurs at the start of every physics run, and can also be necessary during periods of machine commissioning.

Providing an online luminosity estimate in non-Stable Beams operation reinforces the need for ATLAS to have several different luminometers at the HL-LHC, employing different detector technologies. Less precise, but more radiation tolerant, detectors could then be the primary sources of luminosity measurements by ATLAS when Stable Beams have not been declared. Whether a safe operation mode can be found for the HGTD during non-Stable Beams conditions is still to be investigated. A possibility of operating just the outermost regions (regions 1, 8, 9 and 16 in Figure 10.8) at a reduced HV setting could be safe. The reduced HV setting would result in a lower hit efficiency, and thus a different relationship between the instantaneous luminosity and the average number of hits expected in the HGTD, compared to operating at nominal HV conditions. A separate calibration of the luminosity determination for such an operating mode can be accommodated in the Luminosity Software. Whether a safe operating mode of the detector in non-Stable Beams conditions can be found will require extensive tests of the sensors and possibly also operating experience with the full detector.
### 10.3.11 Minimum-bias trigger at Level-0

The data made available at 40 MHz for the luminosity measurements can also be used to provide a L0 trigger signal in order to record minimum-bias events under low-$\mu$ data-taking conditions. Such data-taking conditions are expected during e.g. heavy-ion runs, van der Meer scans or for runs dedicated to soft-QCD measurements. The HGTD will be installed where the current MBTS detector is located. The MBTS detector has been used extensively for these purposes during Run-1 and Run-2, e.g. during the heavy-ion runs where it played a crucial role. However, the MBTS will not be present at the HL-LHC. With improvements of several orders of magnitude in both granularity and time resolution, the HGTD can provide all the functionality of the MBTS. The number of hits in the time window centred around the nominal collision time provides good separation between empty bunch crossings and those with pp collisions. A simple threshold for the minimum number of hits using the occupancy information is straightforward to implement in the luminosity back-end electronics. Such a binary trigger decision can then be communicated directly to the central trigger. The latency for reaching the Level-0 global trigger processors in time for a decision is not expected to be a problem.

## 10.4 Detector Control System

In order to ensure the coherent and safe operation of the HGTD, a Detector Control System (DCS) will be put in place. The main tasks of the DCS are to bring the detector in any desired operational state, while ensuring that any action can not put the detector in a situation where safety reactions are necessary, to monitor its operational parameters and to signal any abnormal behaviour, thus allowing manual or automatic corrective actions. The DCS provides a homogeneous interface between the operator and the detector and its infrastructure, enabling tasks such as detector calibration, commissioning and operation.

The DCS elements are distributed over various detector components: front-end electronics, services, back-end electronics and DCS servers. A Finite State Machine (FSM) structure will be implemented and integrated in the ATLAS FSM tree during data taking, and will support operation in stand-alone mode during commissioning and maintenance. Real-time monitoring of critical parameters will be implemented, and alerts will be raised as soon as critical conditions are reached or connection to one or more hardware devices is lost. All relevant DCS parameters will be archived for debugging, performance tuning and offline studies.

The DCS will control and monitor the following parameters: the power, both high- and low voltages, supplied to the detector; temperatures of the detector modules, peripheral electronics and cooling; humidity and overpressure inside the vessel.
Standard ATLAS DCS front-end (FE) components and communication interfaces are used whenever possible. However, due to constraints on physical space, in some cases DCS data share the communication infrastructure of the on-detector electronics based on the lpGBT chipset, interfaced with the off-detector back-end via Versatile Links (optical) and the FELIX system, with other types of data (read-out and trigger), as detailed in the next sections.

### 10.4.1 High Voltage

The HV supply system will include the hardware and software components for being connected to the DCS for control and monitoring of both voltage and current. For the HV supplies the behaviour at the selected current limit is preferably programmable to not only be in trip mode but also for current-limiting operation. The supplies will be based on commercial multi-channel rack mounted units located in the service cavern.

As detailed in Section 8.1, during the lifetime of the sensors the bias voltage must be adjusted due to gain degradation with received radiation dose. In combination with the non-radial geometry this results in a limited possibility to connect several modules to the same bias supply. The ultimate choice is to use individually adjustable voltages to allow for optimal operation of the sensor modules in view of radiation damage. This is kept as an option while at the start of operation, due to cost, on the average one high voltage channel will supply two sensor modules.

The leakage current will be closely monitored to have an estimate of the radiation damage in the sensors at different radii. The hit efficiency together with the leakage current measurements will be used to adjust the HV setting in different locations of the detector in order to ensure the full depletion of the sensors. The adjustment of the bias voltage will be performed during interfill periods (ideally during technical stops if possible) and after an IV scan to ensure safe operation of the sensors to higher voltages.

### 10.4.2 Low voltage

The low voltage needed by the front-end and peripheral electronics will be provided by a three-stage system, as detailed in Section 8.2.

The bulk 300 V supplies as well as the 300 V to 10 V DC-DC converters are assumed to be commercial products. Both of them must include provisions for communication with DCS allowing for control and monitoring of voltage and current. The voltages from the DC-DC converters on the peripheral boards and the voltages received at the front-end ASICs are monitored via multiplexers and ADC channels on the lpGBT ASICs of the peripheral boards, as described in Section 10.4.4. From the lpGBTs the information is sent via optical fibres to FELIX boards of the DAQ system for transmission to the DCS system. The optical links to the lpGBTs from the DAQ FELIX boards will exchange data bits, embedded in the data
10 DAQ, calibration, luminosity and control

streams, for switching on and monitoring the status of the DC-DC converters powering
the front-end ASICs. However, several DC-DC converters per peripheral boards must be
controlled by DCS over wires, as they will power the lpGBTs, which will control the rest of
the DC-DC converters on the board.

At the moment of writing this document, for the bulk 300 V supplies as well as the 300 to
10 V DC-DC converters (stages 1 and 2) a commercial product is considered as it fulfills
not only the above requirements, but also in terms of radiation hardness and tolerance to
magnetic fields.

ALTIROC ASIC monitoring

The voltage provided to power the digital and analog parts of the ALTIROC ASICs will be monitored by DCS using the ADC of the lpGBT circuit in the peripheral boards. A detailed description of the proposed monitoring of ALTIROC is given in Section 6.8. Three signals ($Vdda_{prob}$, $Vddd_{prob}$ and $Gnda_{prob}$) for the monitoring of the power supply voltages inside the two chips and two signals ($Vtemp1$ and $Vtemp2$) for the measurement of the temperature inside the two ASICs are connected to the ADC of the lpGBT circuit via FLEX cables. More details on the temperature monitoring are given in Section 10.4.3.

10.4.3 Environmental monitoring

Cooling system

The cooling system is based on the evaporative CO2 2-Phase Accumulator Controlled Loop (2PACL) concept, extending the technology implemented for the ATLAS Insertable B-Layer (IBL) detector, while relying on industrial standards. It will be integrated in the general cooling system developed for the ATLAS ITk detector.

The on-detector cooling layout is detailed in Section 11.3. The cooling plant is protected against overpressure with safety valves set to 130 bar. This value is used as the maximum design pressure on the cooling loops. The cooling system parameters will be monitored using the DIP protocol.

Temperature monitoring

The temperatures of the sensor modules will be monitored in two independent ways: as voltages from temperature sensors, embedded in each ALTIROC front-end ASIC, via the same multiplexers and ADCs used for the module voltage monitoring, and from Negative
Temperature Coefficient (NTC) or PT10k sensors, via EMCI boards [88]. The temperature at the peripheral boards will be monitored through temperature sensors inside the lpGBTs.

The temperature measurements from the modules and the peripheral electronics is only available when the detector is powered. When the peripheral electronics is not powered the information about the temperature inside the detector vessel will be obtained from two sources:

* by means of NTC or PT10k temperature sensors located on the cooling plates, directly connected to off-detector EMCI units installed in the patch panels;

* and from the Interlock system, which will monitor additional NTC sensors installed on the detector modules, as described further below in Section 10.4.8.

The 10 kΩ NTC thermistors are good candidates for temperature sensors due to their high radiation hardness and the large signal that they produce, which support transmitting the signals over a long distance using only two wires per sensor. The signals of all these NTC or PT10k sensors will be routed via cables directly to input modules in the Interlock Matrix Crate (IMC). To optimize the use of local services, several temperature sensors may be interconnected inside the detector vessel using an OR logic. Information from the temperature sensors will be provided to DCS using EMCI boards, also located in the IMC crate.

The number of these temperature sensors has not been finalized yet, and is expected to be of the order of a few hundred.

## Humidity and pressure monitoring

To keep a dry atmosphere inside the detector volume, an overpressure of the flushing N₂ gas must be maintained at all times. It is important to monitor the humidity inside the vessel and the pressure difference between the vessel volume and the UX15 cavern atmosphere.

Radiation hardness is an issue for humidity sensors. Studies are ongoing to select appropriate radiation tolerant sensors. The first option would be sensors based on optical fibres (FOS), that are being developed in ATLAS for ITk. Alternatively, the humidity can be measured at the exhaust of the gas system with standard humidity sensors in a low radiation area.

The overpressure monitoring can be implemented using pressure difference sensors, which can be located in the USA15 cavern and connected to the detector volume and the environment via two rigid pipes keeping the sensors away from high radiation areas. At the moment of writing this document the type of pressure difference sensors and their interface to DCS have not been defined yet.
### 10.4.4 Peripheral electronics

The peripheral electronics transfers data between the detector modules and the DAQ, DCS and luminosity systems. As mentioned in the previous sections, it has a central role in the monitoring of sensor temperatures and supplied low voltage. The system is based on CERN-developed lpGBT ASICs. In total 160 peripheral boards will be instrumented.

The detector modules are connected to the peripheral boards via FLEX cables, whereas signals to and from the DAQ, DCS and luminosity systems are transferred to the counting room over optical fibers. The DCS data and commands are embedded in the data streams via the DAQ optical fibers. Control signals to and from the ALTIROC ASICs are transmitted via I²C bus where the commands and data are embedded in the data streams transmitted to and from the detector TDAQ system, as detailed in Section 10.1.

#### DC-DC converters

As mentioned in Section 10.4.2, the peripheral electronics also includes the 10 V to 1.2 V DC-DC converters for the digital and analog voltage supplies to the ALTIROC ASICs and the lpGBT ASICs, and the DC-DC converters for the Versatile Link plus (VL+). The DC-DC converters are based on the bPOL12V ASIC developed by CERN for the HL-LHC upgrade.

The voltages from the DC-DC converters on the peripheral boards and the voltages actually received at the front-end ASICs are monitored via multiplexers and ADC channels on the lpGBT ASICs of the peripheral boards, as described in Section 10.4.2. From the lpGBT ASIC the information is sent via optical fibers to FELIX boards of the TDAQ system for transmission to the DCS system. The optical links to the lpGBTs from the TDAQ FELIX boards will exchange data bits, embedded in the data streams, for switching on and monitoring the status of the DC-DC converters powering the front-end ASICs.

On-detector DC-DC converters will be used to power both the modules (ALTIROCs) and the electronics on the peripheral boards:

* 5472 bPOL12V supplying ALTIROCs (LGAD modules)

* 640 bPOL12V supplying lpGBTs and VL+'s

With 2008 modules per disk, 1188 DC-DC converters on the peripheral electronics per disk are needed to power the front-end electronics. A further 152 DC-DC converters per disk are required for powering the lpGBTs that will control the rest of the DC-DC converters on the board, and must be controlled by DCS over wires.

Each peripheral electronics board will receive an external 1 V control signal to switch on the DC-DC converters supplying the lpGBTs and the optical links. The status of these converters is reported and monitored through the lpGBTs via external electric cables (open drain) Power
Good output and on I/O lines other than those they supply to allow to differentiate between
possible power failures and lpGBT failures. Further I/O lines on the DAQ lpGBTs are used
for switching on and monitoring the status of the DC-DC converters supplying voltages to
the ALTIROC ASICs. These DC-DC converters are switched on by applying a voltage (at
least 850 mV) which is generated via general purpose I/O lines from DAQ lpGBTs. They are
enabled through EMCI boards on the patch panel, and monitored through optical links to
the FELIX boards in the counting room.

LGAD module monitoring

An additional requirement of the ALTIROC ASIC is to be able to monitor two closely related
aspects of the LGAD: its operating temperature and its leakage current. More details about
the temperature monitoring are given in Section 10.4.3.

Probing of the power voltages at the module level is useful to detect latch-up events on an
ASIC. With the resolution of 1 mV of the lpGBT ADC and a parasitic resistance of 100 mΩ
on the FLEX cable, minimal variation of 20 mA (considering an attenuation of 1/2 on the
probing) can be detected, much smaller than the expected current rise in a latch-up event.

The analogue signals of monitoring coming from the modules are digitized by the converter
implemented inside each lpGBT circuit of the peripheral board. The number of channels
of this ADC being limited to eight, a multiplexing is required at the input of each channel.
Multiplexers (MUX 64:1) are thus implemented to interface the signals coming from the
modules to the ADC on the peripheral board. Using a multiplexer circuit which selects one
output from 64 inputs, up to 8 × 64 signals can be interfaced to each lpGBT-ADC. A full
custom 64-to-1 multiplexing circuit will be developed with a radiation tolerance suitable for
its implementation on the peripheral board. The 6-bit bus required to control the addressing
of each MUX is provided by the programmable parallel port of the lpGBT circuit which is
controlled through its I²C interface.

10.4.5 Configuration

The I²C bus will be used to control and configure the ALTIROC ASICs as well as to configure
the luminosity system lpGBTs and the DAQ lpGBTs. The DAQ lpGBTs are foreseen to be
pre-programmed using e-fuses to accept configuration commands using DCS bits embedded
in the DAQ data stream between the FELIX and the lpGBTs. For redundancy, each peripheral
board (160 boards) will have a cable-based I²C from EMCI units in the patch panel area.
Embedded commands, via the DCS bits, in the bidirectional optical links between the FELIX
and DAQ lpGBTs will be used for control and configuration of the luminosity system lpGBTs
and the ALTIROC ASICs through I²C-bus via masters on the lpGBTs.
10.4.6 DCS software

The HGTD DCS structure is shown in Figure 10.9. The DCS software will run on a local control station (LCS) in the ATLAS service cavern USA15. All DCS operations will be performed from this server. The DCS project will be integrated in the ATLAS central DCS. At a higher level, the ATLAS Global Control Station (GCS) controls all sub-detectors, collects data from external systems interfaced to the ATLAS DCS, such as the LHC collider status information or the Detector Safety System, and sends the data to sub-detectors via dedicated DCS Information Servers (IS).

<figure><img src="image_154.png" /><figcaption>Figure 10.9: HGTD DCS layout</figcaption></figure>

A Finite State Machine (FSM) structure will be implemented with rules for performing actions on the detector modules, the front-end and the back-end electronics and the infrastructure, while states will be propagated to the appropriate upper nodes. The DCS software consists of three layers. The lower layer establishes communication with different hardware (device) units. An intermediate layer is responsible for overall data processing, storing data to databases, mapping and calculations. The upper layer is responsible for overall detector operation and visualisation. The JCOP Finite State Machine FSM toolkit will be used to build a representation of the detector as a hierarchical, tree-like structure of well-defined subsystems, called FSM units. The HGTD FSM tree is shown in Figure 10.10. The tree consists of two main nodes: the infrastructure and the detector. The infrastructure node includes all common devices, while detector nodes are split first on a functionally level into
<figure><img src="image_155.png" /><figcaption>Figure 10.10: HGTD FSM layout</figcaption></figure>

high voltage, low voltage and temperature, and then in a geographical level into the two vessels and down to the individual modules.

### 10.4.7 External systems

Beside the control and monitoring of the detector parameters, the DCS will help to protect the detector from various risks raised from infrastructure failures. Several external systems are essential for the optimal and safe operation of HGTD. These systems are under the responsibility of other groups, and hence there are no means of control by HGTD. Monitoring of several parameters from these systems will be put in place:

* CO₂ Cooling System (CCS)

* water cooling system

* N₂ gas system

* Detector Safety System (DSS)

* Beam Interlock System (LHC-BIS)
10 DAQ, calibration, luminosity and control

These external systems are not connected to the ATLAS Technical Network ATCN but to the
Technical Network.

The CO₂ cooling system provides the cooling of all module elements installed inside the HGTD volume. The main parameters to be monitored are: temperature set point, accumulator saturation temperature, plant state (ready, running, off, interlock), and status flags.

The water cooling system provides cooling to all equipment outside the HGTD detector
volume, e.g. the crates located on the patch panel. The main parameters to be monitored are:
gas flow, pressure, states, and status flags.

The Detector Safety System (DSS, whose sensors watch the general environment such as cooling, presence of smoke or flammable gas in the air etc.) and the Beam Interlock System (BIS) provide hardwired signals which will be routed into the HGTD Interlock system and are used to switch off parts of the detector or even the entire detector in case of abnormal behavior of a parameter, failure or loss of communication. Such actions are imminent and may have a coarse impact on the detector. To deal with this the DSS actions can be delayed, allowing the DCS to implement more sophisticated control sequences on the equipment before the actions triggered by DSS are executed.

Beside the risks described in the previous sections, these systems handle additional safety conditions like e.g. smoke, cooling rack failures etc. Together with the hardwired signals, more information from these systems should be available via DIP, as e.g. for the handshake procedure, which defines the transition of the experiment from standby to data-taking and vice versa.

10.4.8 Interlock system

The HGTD Interlock system (HIS) is a standalone safety system that protects the detector against a variety of risks. The Interlock system must always be running and its components must never be disconnected. The HIS will be built according to the rules applied to safety systems. In particular, all its components must be connected by wire, it must be powered by an uninterruptible power supply (UPS) and a positive safety logic must be applied in the design. The last requirement means that any break in connections or loss of power would cause a failure in the system, which would result in the generation of interlock signals. HIS hardware will be designed and implemented in an Interlock Matrix Crate (IMC) located in USA15, similarly to ITk.

As one of the main dangers for silicon detectors is overheating, several hundred temperature
sensors will be installed on detector modules to monitor their temperature, as described
in Section 10.4.3. In the IMC crate the analog NTC or PT10k signals will be converted to
binary signals by means of discriminators with a predefined threshold, and then processed
by an Interlock Logical Unit (ILU) in accordance with the preprogrammed Interlock Action
## 10.5 Roadmap for DAQ, luminosity and control system

Matrix (IAM). In parallel to the binary processing, information from the temperature sensors will be provided to DCS.

In the event that the temperature in any active zone of the detector exceeds 40°C, the power will be cut from all modules in that zone by interlocking the relevant HV and LV power supplies. In addition to temperature data, the signals related to risks due to common infrastructure failures or safety issues will also be included in the Interlock matrix. Various fault signals from the CO₂ cooling plant are processed by the DSS, which provides the resulting signal to the HIS indicating the loss of cooling power to the detector. In the event of external safety or environmental alarms such as signals from the cooling system, smoke or flammable gas detection, magnet vacuum or cryogenics failures (risk from water due to condensation melting), ATLAS emergency stop, flooding or ATLAS wide safe-for-beam interface, the DSS will request the HIS to switch off the power on the detector as a means to protect personnel and equipment. The signals corresponding to failures of common infrastructure, such as UPS power, rack cooling, N₂ gas system failures, will be available from the DSS system, and some of them, depending on their severity, will be included in the Interlock matrix, along with the unstable beam conditions signal from the Beam Interface.

All off-detector power supplies, HV and both type of LV (the 300 V bulk PS and 300 V to 10 V DC-DC converter units) must have an interlock functionality with sufficient granularity, to remove power from their outputs as soon as the interlock signal is raised by the HIS system.

## 10.5 Roadmap for DAQ, luminosity and control system

Different working groups have been defined for DAQ, luminosity and DCS. General DAQ activities including ATLAS common readout and calibrations will be integrated in the demonstrator activities described in Section 14.3.

Development of the luminosity data handling in the backend electronics will be initiated during 2020. The FELIX board has been delivered to CERN and is undergoing final tests by the TDAQ group before being handed over to HGTD. Initially input data will be generated within the FPGA, subsequently tests will be carried out with signals generated on an external FPGA and communication via optical links. The first iteration of the ASIC which will be capable of sending occupancy data will be ALTIROC2, once these ASICs are available integration tests of ALTIROC2 communication via optical links to the luminosity backend FELIX will be tested. In parallel to the tests of the backend electronics, the Luminosity Software will be written and tested, first with generated input data and thereafter with communication from the FELIX to the host where the Luminosity Software is running. An FDR is planned for Q1 of 2024, before launching the preproduction, and an PRR in 2025, as outlined in Figure 15.5.
10 DAQ, calibration, luminosity and control

The preliminary design review for the DCS and interlock system will start on Q1 of 2022 as described in Table 15.6. The installation of the EMCI/EMP boards and DCS servers is planned to start on Q2 2024. The standard DCS software (SCADA, OPC servers) will then be installed and commissioned until Q3 of 2026. The interlock system consists of temperature sensors for the detector modules and EMCI/EMP boards for read-out, the Interlock Matrix Crate, and the connections to the DSS and external systems. The installation of the different items of the interlock system will start on Q2 2024 and commissioned on Q3 2026. The connection of the servers to the network and the hardware (power units, EMCI/EMP boards and interlock) will start on Q4 of 2026, followed by tests to verify the hardware connections and the response of the software. DCS hardware and software must be operational before the installation for testing and commissioning.
# 11 Detector Mechanics

## 11.1 Engineering design overview

This chapter describes the global detector structure and its main mechanical sub-assemblies, in particular the hermetic vessel, the front and back covers, the inner and outer rings, the moderator, the on detector support and cooling disks, the bolting and the alignment device to LAr calorimeter end-cap cryostat wall and the peripheral cooling lines. The cooling system, a common project between ATLAS and CMS, is also presented including cooling requirements and main components from the chiller up to the detector hermetic vessel. A summary schedule of the HGTD can be seen in Figure 15.7.

<figure><img src="image_156.png" /><figcaption>Figure 11.1: General view of the HGTD detector showing the silicon sensors inside the hermetic vessel. The green outer crown is the peripheral electronics limited by the outer ring which is holding the total amount of tight electrical connectors and the proximity cooling lines.</figcaption></figure>

As presented in previous sections, the space allocated to the HGTD equipped vessel is very limited in (r,z). In addition, the routing of the services should fit inside a gap of 17 mm
in z against the end-cap calorimeter wall. These requirements are a challenge for many of the engineering parameters, like the stiffness and thermal insulation of the hermetic vessel, the thickness of the flex and connectors, the size of the support and cooling plates with embedded CO2 channels and manifolds, the peripheral electronics boards and their tight connectors. Due to life time maintenance, the detector must be designed for easy and fast integration into the ATLAS detector, and it should be constructed to permit quick removal and re-installation of the active layers in the high-radiation environment while maintaining the beam pipe in position.

The HGTD system includes two identical detectors fixed at both calorimeter end-caps. The various components of a single detector are shown in Figure 2.4. They consist of a cylindrical hermetic cold vessel (front cover with heaters and back cover, also with heaters, both bolted to the inner and outer rings) that encapsulates two instrumented disks and an inner part of the neutron moderator. Each instrumented disk (Figure 11.1) represents a cooling support plate composed of two separate half disks with silicon modules installed on both sides, as shown in Figure 2.9. The radial extent of the active area is 120 mm to 640 mm, which yields an acceptance from pseudo-rapidity of 2.4 to 4.0.

To protect the ITk and the HGTD from back-scattered neutrons produced in the end-cap and forward calorimeters, 50 mm of moderator is installed in front of the LAr end-cap cryostat, as in the current ATLAS detector. The envelope in z for the full detector, including the moderator, supports, front and back covers, and the free gap with calorimeter front wall is 125 mm (or 75 mm without the moderator). The moderator is made out of two disks of different radii to provide more peripheral space inside the vessel. This space allows electrical services, tight electrical connectors and CO2 distribution lines to fit inside the restricted envelope.

The detector will partially occupy the ATLAS end-cap regions that presently house the Minimum-Bias Trigger Scintillators (MBTS) and moderator. The cold vessel will be located at z positions of 3420 mm < z < 3545 mm from the interaction point. The mid-plane of the first and last active layers will be located at z = 3446 mm and z = 3472 mm. The position of the two HGTD end-caps within the ATLAS detector is shown in Figure 2.3. The overall dimensions are summarised in Table 2.1. The total weight per end-cap is estimated to be 350 kg including the moderator disks and to be 275 kg without the external moderator disk. The heaviest components are the internal and external disks of the moderator, amounting to 75 kg each, followed by the half-circular instrumented disks, weighing 30 kg each.

## 11.2 Detector overall layout

An illustration of the HGTD detector components is shown in Figure 2.4. The front view of the two double-sided layers that will be placed on each end-cap are shown in Figure 11.2. In this drawing they have a rotation of 20° with respect to each other to facilitate the entrance
of the cooling pipes inside the cooling disks. A detailed depiction of the detector in the

<figure><img src="image_157.png" /><figcaption>Figure 11.2: Front view of the two double sided layers that are placed inside the HGTD vessel. These two disks (right and left figures) have a rotation of 20° with respect to each other to take into account the needed space for the PEB (Peripheral Electronic Boards).</figcaption></figure>

$(r,z)$ direction, in the inner radius region close to the beam pipe, is shown in Figure 11.3. It includes two cooling/disk supports where the double-sided layers of the detector are mounted, the front and back covers of the vessel and the inner and outer layers of moderator. The full assembly, including 50 mm of moderator, will match the envelope of 125 mm in the $z$ direction.

A detailed breakdown of the $(r,z)$ dimensions of the detector components is presented in Table 11.1, and also the materials and estimated weight of various components. The bottom of the table lists each component of a double-sided layer of detector modules mounted on the cooling support. The measured thickness of the current prototype of the sensor-ALTIROC ASIC assembly is about 1 mm thick. This gives a comfortable margin with respect to the final envelope assembly protocol, with an expected thickness of module package (detector unit) of 4.2 mm. Considering the longest readout row, the maximum amount of stacked flex cables will be 19. With the estimated thickness of one flex cable of 0.22 mm, it gives the total thickness of flex cables stack of 4.2 mm per side. Considering the additional 1 mm integration gap, it should be possible, though challenging, to fit all the components within the design envelope.
<figure><img src="image_158.png" /><figcaption>Figure 11.3: (R,Z) cross section of the detector assembly from beam pipe axis up to service penetration outer ring. It details the two instrumented double sided layers, installed on the cooling and support plates, the front and back covers, the internal and external moderators, as well as the inner ring centred on the calorimeter central tube.</figcaption></figure>

## 11.3 CO₂ cooling system

The cooling system is based on the evaporating CO₂ 2-Phase Accumulator Controlled Loop (2PACL) concept. It will be integrated with the general cooling system developed for the ATLAS ITk [86]. CO₂ cooling is chosen because it makes significant mass savings inside the detector possible, due to the use of tubes of smaller diameter than in systems, which are based on conventional cooling liquids. CO₂ evaporates at much higher pressures than common refrigerants, keeping the vapour compressed and therefore the volume low. The boiling temperature depends on the pressure and, as this pressure is relatively high, a pressure drop in the lines due to small-diameter piping does not cause much change in the evaporating temperature. In addition to the benefit of high pressure, CO₂ also has a low viscosity and high latent heat, so that less flow is needed than with other refrigerants. The narrower pipes can accommodate much higher flow speeds, which is a benefit for the overall boiling heat transfer coefficient.

Taking into account the radiation environment in which the HGTD will operate, CO₂ is one of the most appropriate refrigerants because of its radiation hardness and low activation. The CO₂ will be pumped in liquid state from an external primary chilling source and will partially evaporate as it absorbs the heat dissipated by the HGTD components. Within each pipe, a small amount of CO₂ flows at high pressure in the form of small drops, and enough space is left for the vapour to circulate. A highly-efficient heat extraction is achieved by making use of the large latent heat for a liquid to vaporise, meaning that not only less fluid is