Semesterarbeit

Institute for Particle Physics

ETH Zurich

September 11, 2006

Tests of CMS Pixel Detector Modules withRadioactive Sources

Kevin Schnelli

ETH Zurich

Abstract

A new testing procedure for CMS barrel pixel detector modules is presented. Detector modules are

irradiated with beta radiation, from the module-wide statistics we infer pixels, that are not correctly

bump bonded, as well as defective readout circuits of the readout chips. Results are compared with the

conventional bump bonding tests.

Contents

1 Introduction 31.1 LHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Pixel Detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Pixel Readout Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Testing Pixel Detector Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Experimental Setup 62.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 The Trigger Pixel Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Existing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.2 FPGA programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.3 Modification of takeData and r . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.4 Perl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 WBC and Delay Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Results 123.1 Hitmaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Module M0072 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.2 Module M0099 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Analysis of Module M0099 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Conclusions 17

5 Annexe 18

References 20

2

1 Introduction

1.1 LHC

The large Hadron collider (LHC) at CERN is a particle accelerator which is currently under con-

struction. Starting in 2007 the LHC is going to collide two beams of protons at a center of mass

energy of 14 TeV, which makes LHC the most powerful accelerator ever (cf. Tevatron at Fermilab

operating at 2 TeV). Later on beams of lead nuclei will be also accelerated, smashing together with

a collision energy of 1150 TeV.

The collider is contained in a 27 km circumference tunnel located underground, formely used

for the LEP accelerator. LHC can reach a luminosity of 1034

cm−2

s−1, when the two rings are

filled with 2835 bunches of 1011 protons each at a bunch spacing of 25 ns.

At LHC the following four experiments are hosted: ATLAS, CMS and LHCb, as well as

ALICE. The latter is the lead nuclei experiment, which may provide evidence for quark-gluon

plasmas and color superconducting phases. LHCb is looking for CP-violation in the b-system,

as well as for indirect evidences for ‘new physics‘ in flavor-changing neutral currents. ATLAS

and CMS are more general purpose detectors. People are hoping to detect eventually the Higgs

boson and perhaps, even signs for supersymmetry or other ‘new physics‘. Although both detec-

tors are built in different ways, ATLAS should be able to confirm the measurements of CMS and

vice-versa.

1.2 CMS

The compact muon solenoid detector has the following features: It is relatively small (roughly

eight times smaller than ATLAS). It is equipped with a powerful solenoid and it is optimized for

tracking muons [2]. The main goal of the CMS experiment is the exploration of TeV-physics,

especially the detection of the Higgs bosons and any evidence for supersymmetry. The detector

consists of four main parts: Tracker, calorimeter, solenoid and muon detectors. The tracker is the

innermost layer, it is surrounded by the electromagnetic and the sampling calorimeter for hadrons.

The tracker and the calorimetry are compact enough to fit inside the CMS solenoid which generates

a magnetic field of 4 Tesla. Outside the magnet follows the large muon detector.

In case of a decay of a Higgs bosons into a bb-pair, the b-quarks will hadronize. However, themean decay length of these hadrons is only 500 µm, which then implies, that the central tracker

should be placed very close to the point of interaction. Due to the high luminosity of LHC the par-

ticle density near the proton beams can reach 1 cm−2, which is too high for silicon strip detectors.

For this reason, the three innermost layers of the tracker consist of silicon pixel detectors, where

as the outer ones consist of silicon strip detectors.

1.3 Pixel Detectors

The pixel tracker consists of three barrel layers of pixel detectors, which are located at distances of

4.4 cm, 7.3 cm and 10.2 cm from the beam axis. The barrel is 53 cm long and closed by two endcap

disks on each side, shown in fig. 1. Each layer is composed into modular detector units. A module

consists of 16 sensor segments arranged in a double column. The sensor segments are so-called

readout chips (ROC), which consist of the silicon sensors and a token bit manager (TBM). Each

ROC is divided into 52× 80 pixels of lengths 100 µm× 150µm. The silicon pixels are connected

3

Figure 1: The CMS Pixel Detector.

to the sensor pixels on the readout chip via a bump-bond consisting of indium. The sensor pixels

are arranged in 26 double columns within the ROC, each ending in a data buffer on the edge of the

ROC, see fig 2.

Figure 2: Structure of a detector element.

1.4 Pixel Readout Electronics

In the semiconductor of the pixel free charges are separated by a high voltage (HV) of 150 V.

When a charged particles crosses the pixel a electron-hole pair is created. This signal is passed

through the indium bump bond to the readout circuit of the ROC (Pixel Unit Cell, PUC), where

it is preamplified and compared to a threshold voltage. If the signal exceeds this threshold, the

signal is stored in a capacitor. Meanwhile a so-called ColOr (column-OR) is sent to the periphery

4

of the double column indicating a hit. There the time-stamp of the hit is stored in the time stamp

buffer. Then the double column is read out by a token bit mechanism. A token bit is sent through

all the pixels. The pixels with a hit send their addresses and their stored analog pulse (from the

capacitor) to the periphery. The pixels without hits just pass the token bit signal to their neighbors.

The periphery stores these data plus the time stamp to a data buffer.

An external trigger controls the readout of the module. The external triggers come from the

detections systems outside the tracker. Only a small fraction of information stored in the data

buffers are considered interesting and are read out. In full operation of the LHC the trigger signals

arrive at a rate of approximately 100 kHz, and they have a delay of 128 bunchcrossings. The

pixel tracker itself is operated at 40 MHz. If a double column receives a trigger and has any hit

with a timestamp identical to the bunchcrossing minus the latency of 128 clockcycles, then it is

set into readout mode. The readout process is controlled by a token bit manager (TBM) on the

module. It works in the same way as the pixel readout. It sends a token bit through all the ROC

and its double columns. The ROC answer with a serial analog signal, consisting of an ‘ultrablack‘

signal (-80 mV at 200 Ω), a ‘black‘ signal (0 mV) and ‘last DAC‘, which are the ‘digital-to analogconverter‘ parameters of the ROC. For each ROC a set of 27 DAC parameters can be set (for

instance the above mentioned threshold voltage). This signal is then decoded outside the tracker.

1.5 Testing Pixel Detector Modules

The pixel detector modules for the endcaps are produced and tested at Fermilab, whereas the

modules for the barrel layers are produced and tested at PSI. Especially the indium bump-bonds

have to be tested intensively. The group of Prof. Langenegger at PSI has developed a procedure of

testing the modules. This procedure contains many different tests. We are particularly interested in

the results of the so-called ‘MECtest‘, which detects bad bump bonded pixels. With this standard

test procedure up to four modules a day can be tested [1]. An alternative test (source test) has

been developed using a radioactive source to irradiate a module. A scintillator placed behind the

test module is connected to a photomultiplier, which generates the external trigger signal for the

readout of the module [3], [4]. The task of this semester thesis is to standardize this alternative

test, i.e. adapting the given experimental setup and reorganizing the used software in order to take

automatic longtime measurements. Furthermore, everything should be glued together in such a

way that the results of both tests can be compared automatically.

5

2 Experimental Setup

2.1 Introduction

The basic idea of the source test is to irradiate a barrel module with β particles from a Strontium90source. As an external trigger for the module readout a scintillator is placed directly behind the

barrel module. When a β particles has crossed the scintillator, it induces scintillation light, whichis then converted in a photomultiplier (PM) into an electric signal serving as trigger for the read

out of the module.

The initial experimental setup is the same as used by Kung and Weber [3], see fig 3. The

module, the source and the scintillator/PM are placed in an aluminum box that was constructed for

this experiment. It provides a shielding from the β radiation. The source can be placed in threedifferent places 6 cm under the module. The scintillator is approximately 1 cm above the module.

Figure 3: Scheme of the experimental setup.

If the analog trigger signal from the PM exceeds a fixed threshold, it is converted in a dis-

criminator (NIM logic) to a negative square pulse with adjustable width. This signal is sent to a

counter and to a testboard. Before entering the testboard, the signal is given an adjustable delay of

some nanoseconds. The testboard is used as an interface between the module and a computer, its

main component is a field programmable gate array (FPGA). The FPGA is programmed in such

a way that it generates the actual trigger signal from the output of the discriminator and sends it

to the TBM of the module. The trigger signal is delayed to the actual hit on the pixel. While

reading out the module, one has to be careful to read out the hits that correspond to the delayed

trigger signal. This delay mainly depends on the experimental setup used to generate the trigger

originating from the scintillator. The so-called WBC value, counts the numbers of bunchcrossings

(of the testboard), that the trigger is delayed to the hit. The WBC value corresponds to the 128

bunchcrossing latency in the CMS experiment (see above). The WBC value has to be determined

experimentally. Given the correct WBC value, the FPGA sends the correct time-stamp of the hit

6

to the TBM for readout. The FPGA saves the data of the detected hits on a 64 MB SDRAM on

the testboard, which can be read out via USB port from the PC. Furthermore the testboard passes

a HV of 150 V to the module. The testboard itself has to be supplied with 6 V.

In order to standardize the source test we have modified the given setup. In a first step the used

HV-supply for the PM, the discriminator, the trigger delay and the counter were integrated in an

experimental box constructed at PSI (BA123) [5]. This new ‘Trigger Pixel Box‘ contains a HV-

supply (Hamamatsu, C4900-01) for the PM. The output voltage is adjusted with a potentiometer.

The incoming signal from the PM is amplified and digitized. The counting rate is displayed on a

3 digit LED display. The output signal is a TTL signal, either of 40 MHz or synchronized with

an external clock. Finally, there is an adjustable delay on the output TTL signal ranging from 1 to

250 bunchcrossing units. The box is supplied with 12 V.

2.2 The Trigger Pixel Box

There are two scintillators available, we have done the experiments with scintillator 1. In a first

step the pixel trigger box was only used as a HV-supply of the PM. The maximal HV output was

measured to be 965.5 ± 0.2 V. The characteristic plateau behavior, i.e. a plot of the countingrate of the scintillator/PM versus applied HV-Voltage is shown in fig. 4. In order to get a much

higher particle flux, than from the bare cosmic muons the strontium90 source (PSI Number 324)

was placed in the box under the scintillator (first position from the left) The counting rate was

measured with an S101250 MHz scaler, after having passed the LeCroy 623 discriminator (width:5 ns, threshold: -0.03 V).The measured plateau curve agree well with the plateau curve measured

with the old HV-Supply (Wiener, HVS100). The new HV-supply of the PM was then fixed to

900 V.

Voltage [V]700 750 800 850 900 950 1000

Co

un

ts [

MH

z]

2

4

6

8

10

12

14

16

18

20

22

Wiener HVS100CMS Pixel-Trigger

Figure 4: Plateau curve of scintillator 1 with different HV supplies.

In the next step the box was connected to the PM output. However, the counting rate was not

7

displayed and no reasonable output signal was measured. The box was then opened in order to find

the malfunction. All the electronic devices were measured to be supplied with the correct voltage

according to the circuit diagrams [5]. The clock rate as well was correctly passed into all devices.

However, the preamplifier of the discriminator did not correspond to the one shown in the circuit

diagrams in fig. 5. It turns out, that a preamplifier is not appropriate to treat the output signal from

the photomultiplier. A more efficient way to treat the signal is using a charge-to-voltage converter.

We have then replaced the preamplifier by a simple charge-to-voltage converter. The new electric

circuits is shown in fig 6.

Figure 5: Old analog entrance.

The modified box generates now the correct digital trigger signal. One last point had to be

done: the trigger entrance had to be modified in order to trigger on a TTL signal instead of a NIM

signal. There are now two different adapters for the testboard available, one for TTL and one or

NIM signals, but one must not put a NIM input on this TTL entrance. A further improvement

might be synchronizing the two clocks of the testboard and the trigger box. For this the FPGA

programming has to be changed in order to produce a clock output, that can be transferred via

Lemo cable to the clock entrance of the trigger box.

2.3 Software

For the source test experiment some different programs are needed. First the FPGA on the test-

board has to be programmed in such a way, that the testboard reads out the module, when a trigger

signal from the discriminator or the pixel trigger box is registered. The experiment is run by a

program named takeData, which controls the data taking with the testboard. The analysis of thedata taken is done by the program r, which produces a variety of plots, such as hitmaps or pulseheight diagrams. A ROOT macro named bumpcomp.Cfinally compares the results from the sourcetest and the standard tests for the modules.

The duration of one run is limited to about one minute (due to limited SDRAM). In order to

8

Figure 6: Modified analog entrance.

have enough statistics several runs have to be taken. Our task is now to write a program that takes

several runs, then analyzes each one separately with the program r and combines the results tothe final source test result for a module. Finally, the ROOT macro bumpcomp.Cshould be calledautomatically and compare the results of the two tests.

2.3.1 Existing Software

For the following we have used PC5522 and the working directory /home/ltester/sourceTests. Thesoftware takeDataexecutes a run and creates a binary file. The run parameter are set via a graph-ical user interface (GUI). The command module.inihas to be execute (in the GUI) in order toenable pixels. The program takeDatais started with the command ../bin/takeData -m 2(the option-m 2 sets the run mode to 2, which is the module testboard mode, the MTB mode) in the direc-

tory ./psi46expert. The program creates the binary output file (./btr05r< runnumber >/mtb.bin),which can be analyzed with the program r. This is executed with the command ./r -r < runnumber >.This program also creates a file named rhistos-mod.root. The ROOT macromergehistos.Ccollectsseveral such output files from different runs and merges them to the file result.root, which is thefinal result of the source test. The results from the standard test are typically stored in the file

FullTest.root. Finally, the ROOT macro bumpcomp.Ccreates a final hitmap for the source test andcompares the two files by creating plots, indicating on which pixels both tests agree and on which

pixels the tests deliver different results.

2.3.2 FPGA programming

For the field programable gate array on the used testboard a new design and a new software have

been developed. The testboard is equipped with an ALTERA Cyclone II FPGA, its design is pro-

9

grammed with the softwareQuartus II. However, programing has to be done under theWINDOWSoperating system as Quartus IIdoes not work properly under UNIX. The main part of the FPGAdesign is a virtual processor, this has the advantage of allowing the FPGA to be programmed in

C/C++, using a software called NIOS II, that has also been developed by ALTERA. The designof this virtual processor is also by ALTERA, the rest of the design is programmed in Quartus II,where the basic logical blocks are already implemented (for instance flip-flops, FIFOs) and more

sophisticated blocks (for instance state machines) can be programmed with the programing lan-

guage AHDL from ALTERA. The design of the FPGA is roughly the following: Once a trigger

signal enters the FPGA the virtual processor starts the reading out of the module, this readout (ana-

log) data are given a time-stamp and are encoded in 15 bit long samples. These samples are stored

in a 4 FIFO (first-in-first-out memory). From there they are stored on a 64 MB SDRAM, as soon

as the virtual processor has done all other higher priority tasks. After the run this SDRAM can

be read out via USB port using programs like psi46expertor takeData. Furthermore an adjustabletrigger delay in units of nanoseconds is integrated in the FPGA. This replaces the delay box used

by Kung and Weber [3], as well as the adjustable delay of the pixel trigger box (see WBC and

delay scan below).

The FPGA design used for this experiment is saved in the file atb.qpfin the folder atb 20060206

(version of 07/25/06) on PC5971. The program Quartus IIallows one to compile the design andto load it on the testboard via a ByteBlaster IIcable. As next step the virtual processor has to beprogrammed. This is done with the program NIOS II SDK IDE III, the software for the processoris also contained in the folder atb 20060206 (version of 07/25/06). One should note, that the

compilation of the virtual processor has to be done on a computer with the corresponding license

from ALTERA. It is advisable, to use the same computer to install design and software of the

FPGA, otherwise, it may happen, that some parts of the design are unwittingly overwritten with

parts of the software on the testboard flash memory.

Finally, the programs psi46expertor takeDataneed the testboardname, i.e. its serial num-ber. It can be found using the program usbview. The serial number must then be entered intothe file ./BasePixel/defaultParametersModule/config.dat. For this experiment we have used thetestboard 23 with the serial number DPCSPRPJ.

2.3.3 Modification of takeData and r

We have modified the takeDataslightly in order to run it several times in succession. We haveadded a batchmode, which runs the program without the GUI. The takeData reserves now a mem-

ory of 32 MB on the testboard, this corresponds to approximately 55 seconds of running with a

high trigger rate (HV of 900V). In the batchmode the run duration is set to 45 seconds and the

command module.iniis executed, such that the pixels are enabled. The dacParameters, which areneeded for a correct readout are taken from the moduleDBfrom the module test, which are in thedirectory ./psi46expert/setup/mtb. Finally, the run number is incremented by one, each time theprogram is run. In order to call the batchmode one uses the command ../bin/takeData -m 2 -binthe directory ./psi46expert.Next we have replaced the program r by the program t, which is its new version. The new

program creates some more plots than the old one. The new output file is thistos.root, whichis saved in the folder /home/l testbeam/log/bt05r < runnumber >. It should be mentionedthat this program has been designed for an experience at the PSI pion beam, where the triggering

10

procedure is much more complicated than for this source test. As a consequence, most part of the

lengthy code of t is not used. A refinement of the whole experiment might be slimming down thet program to those components needed. t is called with the command ./t -l -b -r < runnumber >in the directory /home/ltester/sourceTests/offline. The option -b calls the batchmode (no popups)and the option -l calls the levelbootstrap mode. The levelbootstrap mode has to be run once inorder that the address level information is collected and stored in the file levels-module.dat, whereit will be available for the next program runs.

2.3.4 Perl Script

We have written a perl script that handles the whole source test. It is executed with the com-

mand perl sourcetest.plin the directory ./sourceTest. For the time being the module number aswell as the number n of desired runs have to be entered by hand in the perl script. The perlscript calls then takeData ntimes. In the directory /home/l testbeam/log all intermediate re-sults from the takeDataare saved. For each run there is a subdirectory, it has the following name:/bt05r< runnumber >. In order to have the correct dacParameters, the perl script links the folder./psi46expert/setup/mtbwith the folder ./sourceTests/< modulename >, where one should storethe corresponding dacParametersas well as the file FullTest.root(see underneath).Next sourcetest.plevaluates each of the n runs with the program t (here with the option -b -l,

such that there are no popups from intermediate results). Then a new ROOT macro mergehis-tos.Cis created to merge together the results of the n runs, for this the template mergehistosTem-plate.Cis needed in the directory ./sourceTests/templates. Finally, the ROOT macro bumpcomp.Cis executed (the FullTest.rootfile is taken from the directory /home/l tester/sourceTests/M <modulenumber >). The final results are saved in PS Format in the new created directory:

../log/M < modulenumber >: run :< firstrunnumber > to < lastrunnumber >.

2.4 WBC and Delay Scan

For an effective readout it is necessary to adjust the WBC value. Without the correct WBC value,

we obtain for most trigger signals an empty readout. The program takeDatahas a WBC scanprocedure, which measures the efficiency of the readout procedure, i.e. the ratio of non-empty

readouts total readouts, as a function of the WBC value. Note that the WBC scan, as it is pro-

grammed now, has to be taken with a very low trigger rate. We found that for a WBC value

of 14 bunchcrossings, the efficiency is maximal with approximately 56.2%. This value can be

improved using an additional trigger delay. takeDatahas also the procedure scanDelay, whichcontrols the additional delay given to the trigger by the FPGA. This allows fine tuning of the total

delay. We found that for an additional delay of 12 ns the efficieny is approximately 99%. One

should remember that one unit WBC corresponds to 25 ns. Finally, note that the above values are

obtained for a total Lemocable delay of 14ns. The WBC value can be set in the file module.ini,which is located in /home/l tester/sourceTests/psi46expert. The delay has to be set in the filedaqFrame.ccin the above directory. The delay is set with the command SetDelay(10,< delay >)in the function initializeHardware()under MTB. Note that one has to recompile the takeDataafterhaving changed the delay.

11

3 Results

3.1 Hitmaps

3.1.1 Module M0072

We have taken a first run with the module M0072 (runnumbers: 6051-6078). It has been irradiated

for 5 minutes from all three positions for the strontium source. Fig. 7 shows on the left the hitmap

for these runs. In total we have around 3.3 million hits. The color indicates the number of hit for

one pixel, for instance a white pixel means that it has not registered a single hit. On the right side

of fig. 7 the result from the MECtest for this module is shown. On this graph the colored pixel

are found to have some bump bonding defect. The MECtest tests the indium bump bond and is

implemented the module testing procedure.

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

hitmap

Entries 3350131

Mean x 76.78

Mean y 193.5

RMS x 42.87

RMS y 91.07

0

50

100

150

200

250

300

350

400

hitmap

Entries 3350131

Mean x 76.78

Mean y 193.5

RMS x 42.87

RMS y 91.07

hitmap

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

Results MEC test

Figure 7: Hitmap for the source test (left) and map with defect pixels according MECtest (right) for module

72.

For this module we see that a whole readout chip is defect. From fig. 8 we can identify it as

ROC number 5. For this reason, this module will not be used in the CMS experiment. On the edges

of the ROCs we observe lines of pixels with more hits. These pixels are in fact bigger, hence have

more hits than their neighbors. At the top of the source test hitmap we observe a region without

hits, but the MECtest does not indicate this region as defective. The reason for this discrepancy is

found in the experimental setup of the source test. In the aluminum box the module is fixed over

the strontium source on the upper and lower edges. In the lower edge, there is a small strip without

12

Figure 8: Map with regions with increased shielding and ROC map of a module.

pixels, but in the upper edge there are pixels up to the very end. Those pixels are shielded from the

β radiation by their suspension, thus we observe hits to a much lesser extend.Furthermore we observe that the hit distribution indicated by color is not uniform on the source

test hitmap. On one hand this is due to the geometry of the setup. ROCs at the top and bottom

of the module are less irradiated than ROCs in the middle of the module. On the other hand, the

thickness of the modules is not everywhere the same. At thicker sites, such as the location of the

TBM in the center of the module, less β radiation crosses the module and less hits are registeredin the scintillator. Fig. 8 shows the positioning of different electric devices on the module. Under

the TBM (center of module, number 2 in the graph) and the module carrier (left and right edge of

module, number 6) there are about 50 hits per pixel. We also see that the capacitances mounted on

the board (number 1) provide screening from radiation. We can also identify the cable soldering

(number 3) of the HV cable with about 25 hits. Number 4 on the module is a HV capacitor, which

is especially thick, there the number of hits ranges from zero to about 20.

13

By inspection we find that most pixels considered as defect in the MECtest are also found to be

defect in the source test, although the opposite is not necessarily true. Under the TBM both tests

detect two pixels that are not working correctly. As the hit density under the TBM is approximately

50 hits per pixel, we may assume that it is sufficient to have in average 50 hits per pixel in order

to detect defect pixels. In the middle of the module, this density is reached within 5 minutes of

irradiation, in the lower part, this should be reached with longer duration of irradiation. However,

in the very top part of the module where it is suspended, this cannot be done in a reasonable time.

3.1.2 Module M0099

As next module we have tested number 99 (runnumbers: 6080-6118). According to the MECtest

this module is functioning properly and should be implemented in the CMS tracker.

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

hitmap

Entries 8695351

Mean x 77.55

Mean y 189

RMS x 41.9

RMS y 95.48

20

40

60

80

100

120

140

160

180

200

hitmap

Entries 8695351

Mean x 77.55

Mean y 189

RMS x 41.9

RMS y 95.48

hitmap

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

hitmap

Entries 8695351

Mean x 77.55

Mean y 189

RMS x 41.9

RMS y 95.48

0

200

400

600

800

1000

hitmap

Entries 8695351

Mean x 77.55

Mean y 189

RMS x 41.9

RMS y 95.48

hitmap

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

mBumps

Entries 66560

Mean x 80.51

Mean y 214.9

RMS x 43.35

RMS y 120.9

-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

mBumps

Entries 66560

Mean x 80.51

Mean y 214.9

RMS x 43.35

RMS y 120.9

Results MEC test

Figure 9: Hitmaps for the source test (left and middle) and map with defect pixels according MECtest (right)

for module 99.

For this module we have collected more data (8.8 million hits). The module has been irradiated

for 5 minutes from the central position, 10 minutes from the left position (upper part of module)

and for 15 minutes the right position (lower part of module). The hitmaps are shown in figure 9.

It has been drawn twice with different coloring options. In the left hitmap, we see better the hit

distribution. One observes that even an irradiation of 15 minutes is not enough, to obtain a hit

density higher than 20 hits per pixel for the HV capacitor (number 4 in fig. 8), however, in this

case no pixel has remained empty. The hit distribution is dense enough for a meaningful analysis,

14

apart from the module carrier on the left and right side, as well as on the top edge. On the second

hitmap, where only the coloring is changed, we can better see several pixels that seem unhit. For

the significant regions, these pixels do coincide with the pixels indicated as defect by the MECtest

(right graph) and are certainly badly bump bonded.

On the source test hitmap, we also observe that there is a line segment in ROC 4 that has

significant less hits than its surroundings. This line segment is a double column of pixels. This

double columns has roughly 10 times less hits than its adjoint‘s double columns. The conventional

testing procedure did not indicated that something is wrong with this double column, thus we

conclude that the bump-bonds do not have any malfunctioning. However, there seems to be a

problemwith the readout circuit of the double column. This problem requires further investigations

and a second MECtest should be done.

3.2 Analysis of Module M0099

Fig. 10 shows the distribution of the scintillator histogram (hS).We see that we have about 1800 pix-

els without a hit, these pixels mainly lie on the edges of the module. The average of hits per pixel

is 130.3. Most pixels have hits ranging from 80 to 250 only a few pixels have even more hits (up

to 500).

0 50 100 150 200 250 300 350 400 450 5000

200

400

600

800

1000

1200

1400

1600

1800

hS:Entries hd4Entries 66560Mean 130.3RMS 74.67

hS:Entries

Figure 10: Distribution of number of hits per pixel for module 99.

In Fig. 11 a better analysis of the scintillator hitmap is shown. On the left hitmap, the position

of pixels without or less than 5 hits are shown. Again, we see that on the edges there are a lot

of pixels without hit, due to the shielding, whereas in the center we find unhit pixels, that are

certainly not correctly bump bonded. The middle plot compares the number of hits of a pixel with

the number of hits its neighboring pixels, this difference is indicated by color. With this plot we can

highlight high differences of hits that are arranged systematically, as found for a double column of

pixels on ROC 4. This graph should show defects in the electric readout circuit, rather than bad

15

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

Few hit pixels pixel1

Entries 1827

Mean x 124.6

Mean y 319.4

RMS x 50.12

RMS y 124.8

Few hit pixels

0

50

100

150

200

250

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

Comparision of neighboring pixels pixel2

Entries 145001

Mean x 78.95

Mean y 188.7

RMS x 41.73

RMS y 97.45

Comparision of neighboring pixels

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 20 40 60 80 100 120 140 160

0

50

100

150

200

250

300

350

400

(scint.=prob.) && (elec.=prob.) pixel3

Entries 8

Mean x 94.75

Mean y 345

RMS x 31.96

RMS y 91.01

(scint.=prob.) && (elec.=prob.)

Figure 11: Analysis for module 99.

bump bonds. The plot on the right side shows these pixels, where the results of the MECtest and

the source test agree. There are 8 pixels, that are indicated as bad bump bonded, however, we have

to be careful: Whereas in the middle of the module, where the hits distribution for the source test

is high enough for an analysis, this is not the case on the edges. Hence only the two pixels in the

middle of the module are sure to fail good bump bonding, the pixels on the edges need further

investigations.

16

4 Conclusions

The measurements done show that the source test can in principle test the modules. If the module

is irradiated long enough, these results can be compared with the conventional test. In case of

module 99, we found that both tests agree on in the middle of the module. On the edges of the

module, due to its suspension in the box, most pixels are not irradiated correctly and no meaningful

analysis can be done. This problem could be solved with a better and smaller suspension, or by

moving slightly the module in the box between the runs.

In the given setup, the sourcetest works, however, several modifications can still be done: The

software of the program t should be simplified. Furthermore the perl script sourceTest.pltakes firstall runs and then evaluates them with t, this processes can of course be done in parallel once a firstrun has been taken, this would lead to a significant reduction in testing time. Finally, if the clocks

of the testboard and the pixel trigger box were synchronized, one could expect a higher efficiency

in the readout.

We have found that the source test has two main advantages compared to the conventional test.

First, it is less time consuming; in the conventional test up to 4 modules can be tested in parallel,

which takes roughly 10 hours. Second, the source test is the more ‘natural‘. Modules are tested in

the same manner as they will be used in the CMS experiment apart from the energy and time scale.

For instance we have found, that in module 99 the readout electronic of a double column seems to

be partially defect. Problems of this sort, are not yet detected in the conventional test. Henceforth

the above measurements are certainly leading to an improving of the testing procedure.

17

5 Annexe

For completeness we have added here the electrical circuits plan of the pixel trigger box (BA123).

Figure 12: Analog Electric Circuits of BA123.

18

Figure 13: CPLD of BA123.

19

References

[1] IN2006 006 (CMS Internal Note), ‘Test and Qualification Procedures of the CMS Pixel Barrel Modules‘,

http://kamor.ethz.ch/publ/2006/.

[2] The Compact Muon Solenoid, http://cmsinfo.cern.ch.

[3] B. Kung, M. Weber, ‘Test of CMS Pixel Detector Chips and Modules with Radioactive Sources and X-Raya‘,

semester thesis (2006), http://www.phys.ethz.ch/ursl/home/v0/projects/p02.pdf.

[4] A.K. Sanchez, G. Genoud, ‘Test of Modules for the Pixel Detector of CMS with the Help of Scintillators‘,

semester thesis (2006), http://www.phys.ethz.ch/ursl/home/v0/projects/p01.pdf.

[5] Ch. Lang, ‘CMS Pixel-Trigger, Number BA123, IPA Lang Ch. Nr. 316‘, contact: beat.meier@psi.ch.

20