388
IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 56, NO. 2, APRIL 2009
Digital Architecture and Interface of the New ATLAS Pixel Front-End IC for Upgraded LHC Luminosity David Arutinov, Marlon Barbero, Roberto Beccherle, Volker Büscher, Giovanni Darbo, Robert Ely, Denis Fougeron, Maurice Garcia-Sciveres, Dario Gnani, Tomasz Hemperek, Michael Karagounis, Ruud Kluit, Vadim Kostyukhin, Abderrezak Mekkaoui, Moshine Menouni, Jan David Schipper, and Norbert Wermes
Abstract—A new pixel Front-End Integrated Circuit is being developed in a 130 nm technology for use in the foreseen b-layer upgrade of the ATLAS pixel detector. Development of this chip is considered as an intermediate step towards super-LHC upgrade, and also allows having a smaller radius insertable pixel layer. The higher luminosity for which this chip is tuned implies a complete redefinition of the digital architecture logic with respect to the current ATLAS pixel Front-End. The new digital architecture logic is not based on a transfer of all pixel hits to the periphery of the chip, but on local pixel logic, local pixel data storage, and a new mechanism to drain triggered hits from the Double-Column. An overview of the new chip will be given with particular emphasis on the new digital logic architecture and possible variations. The new interface needed to configure and operate the chip will also be described. Index Terms—Digital integrated circuits, FE-I4, front end electronics, pixel detectors, pixel electronics.
I. INTRODUCTION
I
N spring 2009, the LHC (Large Hadron Collider) is expected to begin colliding beams. The nominal LHC proton beam energy is 7 TeV and after a ramp-up phase the full deshould be reached. ATLAS sign luminosity of (A Toroidal LHC ApparatuS [1]) is one of the four main particle detector experiments located on the LHC ring. The ATLAS detector consists of four major components: the inner tracker, the calorimeter, the muon spectrometer and the magnet system. In the innermost part of the inner tracker [2], [13], a three-layer pixel detector [3], [4] covers radii from about 5 cm to 12 cm, and provides very high single point resolution close to the interaction region. In Section II, a description of two phases of luminosity upgrade foreseen for the LHC will be given, the first one —“b-layer upgrade”— projected for around 2012-2013, and the second —“super-LHC upgrade”— around 2016-2018. Manuscript received December 01, 2008; revised January 21, 2009. Current version published April 08, 2009. D. Arutinov, M. Barbero, V. Büscher, T. Hemperek, M. Karagounis, and N. Wermes are with the Institute of Physics, Bonn 53115, Germany (e-mail:
[email protected]). R. Beccherle, G. Darbo, and V. Kostyukhin are with INFN Genova, Genova 33-16146, Italy. R. Ely, M. Garcia-Sciveres, D. Gnani, and A. Mekkaoui are with Lawrence Berkeley National Laboratory, Berkeley, CA 94720 USA. D. Fougeron and M. Menouni are with CPPM Aix-Marseille Université, CNRS/IN2P3 Marseille, France. R. Kluit and J. D. Schipper are with NIKHEF, 1098 SJ Amsterdam, The Netherlands. Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TNS.2009.2015318
As the current pixel Front End (FE) Integrated Circuit (IC) cannot be used for the increased luminosity (see Section III), a new FE chip is being developed for the pixel detector upgrades. : The new pixel FE will be made of smaller pixels in z ( vs. for the present FE, FE-I3), a much improved active over inactive area ratio, and a new analog pixel chain tuned for low power and new detector input capacitance. The architecture used for FE-I3 is based on pixel hit transfer to End-of-Column (EoC) buffers located in the periphery, where data is stored and waits for arrival of ATLAS First Level Trigger (L1T), or is erased after the L1T latency. The transfer of all pixel hits recorded to the EoC buffers starts to be highly inefficient already at a few times the LHC design full luminosity, resulting in data losses intolerable at super-LHC luminosity. The changes required to the digital section of the FE to cope with the higher hit rate are introduced in Section III. In Section IV, different flavors of the new architecture concept are presented. The current ATLAS pixel module is based on 16 chips linked to a Module Control Chip (MCC). The new module will be based on a reduced number of bigger chips. Each of these FE will now handle functionalities that were previously included in the MCC. Section V briefly describes the interface of the new FE IC. In 2008, a prototype FE-I4_proto1 was submitted. It 14 analog pixel array and various peis made of a 61 ripheral blocks (current reference, DACs, Low Drop Out -LDO-regulator, divide by two DC-DC converter, command decoder). Other prototype submissions were done including a pseudo-LVDS transmitter/receiver chip (and tri-state version), a new shunt-LDO regulator for Serial Powering schemes and an SEU (Single Event Upset) test chip. In the following sections, the corresponding digital architecture needed for the full scale FE-I4 is introduced. A sketch of the digital architecture of the pixel array together with the periphery logic and interface blocks is shown in Fig. 1. II. UPGRADES TO THE ATLAS PIXEL DETECTOR The ATLAS pixel detector is composed of 3 barrel layers and 2 identical end-caps with 3 disks each. The innermost layer of 5 cm radius is designed to precisely reconstruct vertices from long lived particles containing c and b quarks. It is called the b-layer. Several phases of upgrade are planned for the LHC collider to increase its physics potential in the coming 10 years. With first upgrades in 2012, a potential peak luminosity could already be reached before 2016. Then a second more ambitious upgrade phase will take place to enhance
0018-9499/$25.00 © 2009 IEEE
ARUTINOV et al.: DIGITAL ARCHITECTURE AND INTERFACE OF THE NEW ATLAS PIXEL FRONT-END IC
Fig. 1. Block diagram of the new pixel FE, FE-I4. The sketch shows the pixel array (with the 4-pixel region), the periphery logic and the command decoder.
the luminosity of the machine to about ten times more, and is referred to as the “super-LHC upgrade”. Correspondingly, two phases of upgrade are planned for the ATLAS pixel detector, called “b-layer upgrade” and “super-LHC upgrade”. Some intervention will be needed around 2012-2013, due to potential performance degradation of the innermost layer of the pixel detector before 2016, either related to charge collection efficiency degradation of the irradiated sensor, or due to limitations in the hit rate that the current FE [3], [4] can handle at high peak luminosity. The currently favored option is actually not a replacement, but the insertion of a new smaller radius b-layer inside the current pixel detector together with a smaller radius beam pipe, an option referred as IBL (“insertable b-layer”) project. The inner detector is the part of ATLAS needing the most radical changes for super-LHC luminosity, and although plans for the upgrade are still in the process of being defined, some general points can already be drawn. For super-LHC, the pixel detector barrel could consist of 4 layers covering radii from about 3.7 cm to about 20 cm. A new sensor technology will be needed for the innermost pixel layer(s) because of inimical radiation environment at very high luminosity. It is also believed that the challenges for the design of the new FE for the smallest radii at super-LHC are too great to be overcome in a single technology step. It should finally be underlined that the hit rate at radii above 12 cm for super-LHC luminosity will be rather similar to the rate in the IBL before super-LHC upgrade. Thus, it was decided to design an FE for an intermediate hit rate, called “FE-I4”, with two goals: FE-I4 will target the IBL project needs in the years 2012-2013 and will also be compatible with the requirements for the pixel outer layers after super-LHC upgrade. It is understood that the innermost layer(s) at super-LHC would then require an appropriate IC development in a smaller feature size at a later time. In the next sections, a description of the new digital concepts the FE-I4 is based upon is given. An introduction to FE-I4 main
389
Fig. 2. Inefficiencies in FE-I3 at r = 5 cm as function of hit rate per DC. The correspondence between hit rate per DC and luminosity is shown. The double-hit inefficiency corresponds to the situation when a pixel is hit twice in a very short time and the LE of the second hit is never detected. Sources of inefficiency related to data shipment in the DC are labeled “busy/waiting” and “late copying”.
characteristics is given in [5]. A description of the FE-I4 analog pixels and of many peripheral blocks of interest can also be found in [6]. III. LIMITATIONS OF FE-I3 AT HIGH RATE AND THE NEW FE-I4 DIGITAL ARCHITECTURE In the current ATLAS pixel detector IC, FE-I3, each pixel has a discriminator which produces a digital signal when the amplifier output exceeds the set threshold. The moment when the comparator fires is called the Leading Edge (LE) and it time-stamps the particle detection. The comparator stays above threshold for a certain time which is approximately proportional to the recorded charge, and is called the Time-over-Threshold (ToT). technology, with enclosed FE-I3 was designed in 0.25 layout transistors for enhanced radiation-tolerance, and was tuned for LHC full design luminosity. The FE is organized in Double-Columns (DC), which allows a good separation of the analog and digital pixel sections. Due to space constraints it was not possible to implement large digital elements in the . Thus the FE-I3 architecture is based on a column drain concept, where each hit pixel sends timing (LE), charge (ToT) and pixel address information down to the EoC buffer. The data recorded in these DC buffers waits until ATLAS L1T latency, either for confirmation and readout, or for erasing. The process of transferring pixel hits inside the DC to its periphery is time-consuming, and a pixel that fires stays inactive until the data shipment to the next available EoC cell is finished. At higher hit rates, the number of hits to be transferred increases and the DC bus becomes very busy. Around a hit probability which corresponds to 3 times LHC luminosity for the 5 cm layer, the bus becomes saturated. This saturation translates into a steep increase in the time it takes for a pixel to copy its data down to the EoC and as a consequence into a steep increase in the corresponding sources of inefficiencies as seen in Fig. 2. Note that the hit rate is greater at smaller layer
390
IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 56, NO. 2, APRIL 2009
Fig. 3. Example of a few types of RLU. Pixels are bounded following the f or z directions. More details is given in text.
radius, which translates in even more challenging requirements for the IBL. The obvious solution for the new FE-I4 architecture is to stop transferring hits through the whole DC to the EoC buffer unless they are requested by a L1T. Thus, the new architecture is based on local storage of hits into some regional buffer inside the DC, until L1T. Implementation of Local Buffers (LB) is rendered possible thanks to the smaller feature size of the 130 nm technology, and its enhanced natural radiation-hardness (no enclosed layout transistor needed). Before going through a more detailed description of the new architecture and its optimization, a few main characteristics can be given: — In the new design, adjacent pixels in the DC are tied together from a logic point of view and are grouped in socalled Regional Logic Units (RLU). As real physics hits come usually clustered (charge sharing in adjacent pixels for real tracks), this structure allows a more efficient hit recording. RLUs are made of several adjacent pixels in the DC, tied together either in , z or in both directions —Fig. 3—. Note that the specific geometric grouping of pixels in RLUs is static (no dynamic allocation of RLUs). Hits with the same leading edge inside one RLU will occupy the same memory cell in the LB. When small charges are detected at the input of the analog chain, the LE of the hit can slip into the next bunch-crossing, a phenomenon called time-walk. The efficiency of the new RLU concept goes beyond saving memory cells but could also provide the option to record hits without any time-walk in an elegant way. With pixels tied together inside the DC locally, some extra feature can be implemented that allows recording of small pixel charge time-walk-free: if a pixel recording a small charge is in the vicinity of a pixel recording a big signal, both pixels can be associated to the big hit time-stamp. — The LB can be shared between one or several RLUs. Hits are stored in the LB until the L1T latency, and are then erased in 99.75% of the cases when no request for readout is issued (assuming a 100 kHz L1T rate). Only in 0.25% of the time will the pixel hit actually be transferred to the EoC. — The LB depth is dictated by a compromise between area available and the LB overflow inefficiency. A high level C++ simulation framework was developed to verify new architecture concepts and check for new sources of inefficiency. It is based on physics data which was produced
Fig. 4. Single pixel pile-up inefficiency (in percent) as a function of the mean ToT (in unit of bunch-crossings) as calculated analytically for a 3.7 cm layer for the new pixel size of 50 250 m .
2
using the Pythia event generator [7], including overlapping pile-up events to simulate the different luminosities (full , sLHC with either 25 ns or 50 ns design LHC, bunch-crossing structure). Detector volumes and pixel hit digitalization were done using Geant3 simulation package [8]. Two sources of inefficiency were identified. The first is related to standard pile-up inefficiency—a pixel is hit when its comparator is still high leading to time-stamp information loss for this pixel. This inefficiency is linearly dependent on the hit rate, the pixel area and the return to baseline characteristic of the analog chain (mean ToT). The second source of inefficiency is the LB overflow. It depends on the hit rate, the L1T latency time and the LB depth. Several flavors of the digital architecture were simulated. The input parameters for the simulation are the number of pixels in the RLU, the number of RLUs that share a common LB, the LB depth, and the mean ToT. IV. SIMULATION OF NEW FE-I4 ARCHITECTURE VARIATIONS In this section, several flavors for the new architecture are studied. They differ in RLU size and structure, in the number of RLU sharing one common LB and in the number of memory cells inside the LB. The first source of inefficiency is the double hit inefficiency (or pileup inefficiency). It is the easiest to model analytically as single pixel double-hit inefficiency is only related to the pixel hit probability and the mean ToT (the mean time the pixel is busy from an analog point of view). The analytic formula for a , where m is the recorded paralyzable system is count rate, n is the true interaction rate, and is the mean time the analog chain is paralyzed (mean return to baseline). In Fig. 4, and results of this simple model are given for LHC, luminosity based on Monte-Carlo (MC) physics data. Fig. 4 shows that to decrease pile-up inefficiency at a given luminosity, a more aggressive return to baseline (smaller mean ToT) or a smaller pixel area need to be aimed for. Still, for a mean ToT value tuned to 4 bunch-crossings, pile-up inefficiency luminosity for an inserted b-layer at 3.7 cm radius and is below 0.6%. Note that FE-I4 would also be efficient from
ARUTINOV et al.: DIGITAL ARCHITECTURE AND INTERFACE OF THE NEW ATLAS PIXEL FRONT-END IC
Fig. 5. Simulation of pile-up inefficiency as a function of the hit rate with and without truncation for the 3.7 cm layer and a mean ToT of 4. Pile-up inefficiency with no truncation is shown with open symbols, and with truncation with solid symbols (see text for more details). Inefficiency values for three luminosities are shown in the boxes. This plot is shown for a case where two RLUs made of two pixels each share one LB.
391
The second source of inefficiency encountered is the LB overflow which corresponds to the loss of new pixel hits when the LB is already filled by data waiting for either L1T confirmation or deleting. This source of inefficiency increases with the hit rate, the L1T latency, and is related to the size of the RLU, the number of RLUs tied to a single LB, and the number of cells available in the LB. To decrease the LB overflow inefficiency, either the size of the RLU can be expanded, or at a constant RLU/LB depth ratio, the number of RLUs can be increased (in both cases, local inefficiencies average out). Still the most obvious possibility is simply to increase the number of cells in the LB. The analytic formula to model LB inefficiency, borrowed from telecommunication theory [9], is shown below in the case of a 6-deep LB.
b b
traffic intensity of the system. service time (latency). input rate (pixel region hit rate). fraction of correlated events (2 RLUs recording hits at the same time). probability to have 6 busy resources (probability that the 6-deep LB is full).
Fig. 6. LB overflow (in percent) calculated analytically as a function of L1T latency (in bunch-crossings), for a 3.7 cm radius layer, with 2 RLUs of 2 pixels each tied to a single 6-memory cell LB.
a double-hit inefficiency point of view for the outer layers at super-LHC where the hit probability is at minimum a factor 2 . down with respect to the innermost layer at When designing the logic to manage multiple pixels, one must take care to keep this logic always sensitive to single pixel LEs (no logic induced dead-time). Otherwise the logic would effectively tie pixel together as if they had a single discriminator which would obviously increase the pile-up inefficiency proportional to the RLU area. It was initially thought that pixels in the RLU, although performing data recording as a unit, should still regain some level of independence if one of the RLU’s pixels detect a new LE. The on-going digitalization would then be stopped, and a ToT value for an active pixel would be truncated. This mechanism was called “truncation of digitalization”. Allowing truncation brings a decrease in pile-up inefficiency as can be seen in Fig. 5. The results of the full C++ simulation are in good agreement with the results calculated analytically. It should be noted that this mechanism comes at the cost of a small single point resolution degradation due to the lost ToT information for a small fraction of the events.
In the case shown here with a 6-deep LB, the pixel hit rate and the fraction of correlated 2-RLU hits were derived from MC physics data we had available. In Fig. 6, the result from the analytic modeling of the overflow inefficiency of the pixel region is shown as a function of the L1T latency for the innermost layer and luminosity. Note that the current at ATLAS L1T latency is 120 bunch-crossings. For the IBL, the rates calculated analytically show that a 6-deep LB structure is acceptable from the overflow inefficiency point of view. Results from this analytic modeling were compared to full C++ simulation output, showing again very good agreement. In Fig. 7, LB overflow inefficiency values as a function of the LB depth (given in number of cells) are shown for a 3.7 cm and the specific 2-pixel RLU, 4-pixel LB layer at configuration. This plot, based on the full simulation, shows that for this configuration, a 6-cell deep buffer is very likely optimal. This modeling effort was further expanded by Register Transfer Level (RTL) description and gate level simulation, with a Verilog architecture description, logic synthesis and post- Place & Route verification. With respect to the full C++ simulation modeling, the new simulation framework allows not only to estimate sources of inefficiency coming from architecture choices, but also to check for some implementation related further sources of inefficiency, and to give a first estimate for the power consumption and for the area needed to implement the local logic. A few selected results from this hardware simulation are presented in Table I.
392
IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 56, NO. 2, APRIL 2009
Fig. 7. Full simulation result. LB overflow inefficiency as a function of LB depth for the IBL. The structure used here consists of two RLUs of two pixels each sharing a single LB.
Fig. 8. Pixel clusters as extracted from the MC data sample for the 3.7 cm layer at 3 LHC luminosity. On the left '-projection, on the right projection along z.
TABLE I LB OVERFLOW INEFFICIENCY, POWER AND AREA ESTIMATE FOR 2 DIFFERENT RLU IMPLEMENTATIONS AT r = 3:7 cm
V. INTERFACE
In Table I, a comparison of two local region structures is shown, on the right two 2-pixel RLUs tied to a 6-memory cell LB, and on the left a new configuration consisting of 4 semi-independent pixels. These 4 semi-independent pixels time-stamp the events together (a common LE counter is provided for the 4 pixels), but record their analog information separately (individual ToT memories). This structure is simpler from the point of view of implementation, and is particularly well-tuned to the needs of the innermost layer where charge sharing also occurs between pixels adjacent in z as can be seen in Fig. 8. Results shown in Table I should be taken with a lot of care as area and power estimates were done only after Place & Route of the regional logic, thus do not include any further routing and buffering related to the communication protocol to the EoC, neither proper clock nor power distribution... In particular power consumption will increase by some rather large factor (first estimates show power consumption could easily go as high as two to four up). Nevertheless, despite the increased power/pixel value that will finally be reached, these estimates show that the target set for the FE-I4 digital power consumption of should be approached. These results show that for the IBL and the outer layers of super-LHC, this 4 semi-independent pixel structure with a 5-deep memory would be quite a good fit. This design is the current reference design the FE-I4 collaboration has agreed upon.
2
The last section of this article introduces the new command decoder which is needed for the new FE. The module presently used in the ATLAS pixel detector is based on 16 FEs tied to a single sensor, and controlled by a Module Control Chip (MCC). The MCC organizes event readout and event building from the 16 FEs, sends configuration data, L1T requests from ATLAS trigger system and propagates the clock to the FEs. In the new module concepts foreseen for the IBL, the new bigger FE-I4 [10] will be tied to single chip sensors, and the FEs will behave as rather independent units from a system point of view up to the End of Stave (EoS) card. In the outer layers for super-LHC, it is thought that some minimal level of organization of several FE-I4s (typically 4) is needed from the point of view of data transfer to the EoS, clock and configuration data distribution. Still the complexity of the new super-LHC outer layer modules can be kept rather low, with no need for a scheme using a dedicated complex chip at module level. Data could be organized with shared busses and a token passing scheme for example, or some simple multiplexing. As a consequence, functionalities that were previously covered by the MCC need now to be handled either at the EoS card level, or inside the new bigger FE. A prototype command decoder was designed as a standalone block in the FE-I4_proto1 IC submitted in spring 2008. This prototype command decoder has inherited much from its MCC predecessor. The aim of the command decoder is to handle commands that are sent from the EoS to the FE. The commands received can be divided in three main blocks: L1T, Fast and Slow commands. The L1T is the most frequent command issued (with a rate of 100 kHz in the current ATLAS detector). It is 5 bits long and is used to start the data acquisition from the FE. There are 4 Fast commands coded on 9 bits: BCR (Bunch-Counter Reset), ECR (Event Counter Reset), CAL (Calibration Pulse) and SYNC (Synchronization). Finally there are up to 16 Slow commands, which allow programming of the FE chip. These can be of variable length, from 17 bits to several thousands. If one of the Slow commands is issued, the pixel system is taken out of data acquisition mode.
ARUTINOV et al.: DIGITAL ARCHITECTURE AND INTERFACE OF THE NEW ATLAS PIXEL FRONT-END IC
The commands can have up to 5 different fields. The first field is used to discriminate between L1T and other Fast or Slow commands. The second field is unique for each of the Fast commands and allows to distinguish Fast commands from Slow commands. All other fields are only used for Slow commands. The command set chosen for the command decoder is optimized for a low rate of bit flip in the input data stream. In particular the command set satisfies the following requirements: 1) The most frequent command, L1T, is coded on a small data stream allowing for high L1T rate to be received from ATLAS trigger system. L1T commands are also tolerant to single bit flip, and are still well recognized in a single bit flip case. 2) A given Fast command is never mixed up with another Fast or Slow command in case of a single bit flip in the data stream. More details about the MCC functionalities can be read in [11]. Further work is on-going to tune the new command decoder to the FE-I4 needs as well as to fix a format for the output data protocol. Of particular importance for these digital blocks, SEU-tolerant latches and triplication logic will be used wherever necessary. SEU-tolerant blocks are of the highest interest for the overall digital architecture of the FE-I4, and a trade-off between area constraints and SEU-hardness needs to be reached. Special SEU-tolerant memories are being developed for storage of configuration. However storage of transient information in local memories is expected not to require any special SEU protection. Simulation of the effect of SEU on local memories remains to be done. Some SEU test structures were submitted and tested in 2008; more details are given in [12]. VI. CONCLUSION Development of the new ATLAS pixel FE-I4 is on-going. This new FE targets both the needs of the IBL and of the super-LHC outer layers. A reference digital pixel region is now
393
defined and development of the overall digital pixel array is pursued. This development is based on a parallel high level C++ simulation framework and transistor level modeling. An introduction to the optimization of the FE-I4 digital architecture with respect to inefficiencies, power and area available using MC physics data sample as input was given in this paper. Design of a full scale FE-I4 IC is foreseen for the year 2009. REFERENCES [1] G. Aad et al., ATLAS collaboration, “The ATLAS experiment at the CERN large hadron collider,” J. Inst., vol. 3, p. S08003, 2008. [2] ATLAS collaboration, Inner Tracker: Tech. Design Rep., 1 CERNLHCC-97-016 [Online]. Available: http://cdsweb.cern.ch [3] ATLAS collaborationG. Aad et al., ATLAS Pixel Detector: Tech. Design Rep., CERN-LHCC-98-013 [Online]. Available: http://cdsweb. cern.ch [4] G. Aad et al., ATLAS collaboration, “ATLAS pixel detector electronics and sensors,” J. Inst., vol. 3, p. P07007, 2008. [5] M. Barbero et al., “A new ATLAS front-end IC for upgraded LHC luminosity,” Nucl. Instrum. Methods Phys. Res. A, to be published. [6] M. Karagounis et al., “Development of the ATLAS FE-I4 pixel readout IC for b-layer upgrade and super-LHC,” in Proc. Topical Workshop Electronics for Particle Physics, Naxos, Greece, 2008 [Online]. Available: http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=21985 [7] T. Sjostrand, L. Lonnblad, S. Mrenna, and P. Skands, Pythia 6.3 Physics and Manual, FERMILAB-PUB-03-457, LU-TP-03-38, hep-ph/0308153. [8] S. Agostinelli et al., The GEANT4 Collaboration, “GEANT4—A simulation toolkit,” Nucl. Instrum. Methods Phys. Res. A, vol. A506, pp. 250–303, 2003. [9] D. Fakinos, “Theory and methodology on the M/G/K group-arrival loss system,” Eur. J. Oper. Res., vol. 44, pp. 75–83, 1990. [10] M. Garcia-Sciveres et al., “FE-I4 chip size,” ATLAS Pixel Upgrade for SLHC—Electronics, Internal Document, 2008. [11] R. Beccherle and G. Darbo, “MCC-I2.1 specifications,” ATLAS Pixel Internal Document, 2003 [Online]. Available: http://www.ge.infn.it/ ATLAS/Electronics/home.html [12] M. Menouni et al., “Design and measurements of SEU tolerant latches,” in Proc. Topical Workshop Electronics for Particle Physics, Naxos, Greece, 2008 [Online]. Available: http://indico.cern.ch/conferenceOtherViews.py?view=standard&confId=21985 [13] ATLAS collaboration, Inner Tracker: Tech. Design Rep., 2 CERNLHCC-97-017 [Online]. Available: http://cdsweb.cern.ch
