Prototyping stacked modules for the L1 track trigger
This proposal describes a research program with the goal
of prototyping and testing a
module capable of providing
trigger primitives as required for an upgraded CMS
tracker in the LHC Phase 2 upgrade.
It is generally agreed that for the SLHC
at an instantaneous luminosity of 10
, or ten times the design
luminosity of the LHC, the current trigger based on muons plus hadronic and electromagnetic calorimetry will
need to be enhanced with information from the Tracker
. The total L1
trigger rate, without use of Tracker
data, is expected to exceed the nominal limit of 100kHz by a large factor, probably exceeding an order of
The challenge is a little different for each type of trigger. For muons the goal is primarily to add
information to discriminate between different muon chamber hit combinations which appear to make valid muon
trajectories. Using muon data alone at SLHC will include many fakes and thus does not provide a reliable
momentum estimate for the L1 trig
ger. For electrons the challenge is to associate hits in the tracker with
calorimeter objects to reject backgrounds from photons. The requirements for taus are not yet so clear but the
present jet trigger has a rate far higher than acceptable and improved
isolation of hits associated with tau jets
appears, from HLT experience, to offer a means to reduce the raw trigger rate. In addition, to the tasks above we
would like to be able to provide vertexing capabilities in the L1 trigger.
As the contributions to
the trigger rate will come about roughly equally from the central and forward regions
of the detector it is required that tracking information should be provided for the full
2.5 to +2.5.
One way to accomplish this is with one or more tracki
ng layers at a radius of about 25 to 45 cm with the
capabilities of discriminating hits based on the track p
Two sensors are placed in close radial proximity and
share hit data to allow the identification of matching patterns consistent with a high trans
verse momentum track
(where high means only a few GeV/c) but allow to reject low transverse momentum candidates. They are
generally referred to as “stacked” modules.
principle of the stacked layer to select low or high p
A concept for
a module that we believe can satisfy these requirements has been discussed in the trigger
primitive task force. This proposal outlines steps required to prototype and test such modules.
The basic concept
for the pT module has been presented in many CMS me
etings in the last few years and simulations have
demonstrated that the original idea, which was based on extremely small pixels relatively close to the beam, can
be extended to larger pixels at a higher radius.
The concept for the modules described in th
is proposal is based on technologies that are commercially
available with which we already have experience. This means that we have a high level of confidence that these
modules can be constructed and tested on the timescale outlined in this proposal. We c
onsider this very
important as, given the novelty of extracting trigger data from the tracker and the need for on
reduction, it is essential to evaluate real modules under realistic conditions in beam tests as soon as feasible. In
lternative designs will be explored to evaluate the benefits from utilizing more advanced
commercially available technologies.
stacked layer concept
, which was based on extremely small pixels relatively close to the beam,
extended to larger pixels at a higher radius. This is
for the tracking system since it is highly
undesirable to add significant material at low radii and it will be very challenging to approach the low material
budgets already demonstrated in the pr
esent pixel system using trigger layers in the inner pixels. Further material
reductions are expected in the Phase I pixel upgrade and there are strong reasons to consider it undesirable to
worsen this aspect of the future Tracker design.
In this proposal
we consider track
trigger modules that we believe can be constructed using technologies in
common use today. This is important as it is crucial to be able to demonstrate that these modules work and
provide the required functionality in beam tests over the
next few years. We will need this information in order
to write a tracker (and trigger) TDR. It is also important that we can actually build these modules. In this
proposal we will consider two slightly different types of modules. The different types of m
odules differ in how
the interconnects between the two sensor layers are done.
The top figure shows the pT module seen from above and the lower figure shows the module sideways, indicating the
connections required by the two sensor layers.
The first type of module is illustrated in Fig. In this design the hits are read out to the sides of the module
where the connections between the two sensors are made. The data are read out from a column of 128 pixels.
The pixel size is 100
m by 2.5 mm an
d the sensor is expected to be approximately 200 mm or less in thickness.
The module is envisaged to be 256 x 32 = 8192 pixels so with an approximate active sensor size of 26 mm x 80
Simulations of the performance of such layer
s have been carried out from which it seems very feasible to
achieve data reduction factors of 10
20 with a
GeV/c and quite simple algorithms
This is adequate to allow data to be removed from the Tracker for the trigger process
ing with a acceptable power
and number of high speed data links, which should allow a tolerable material budget.
Typical results from simulation studies of M. Pesaresi showing selection efficiency vs p
for single muons
in high pileup
~400 events/bx) for various sensor separations. The
on pixel row and column selection windows
for high efficiency
Performance vs sensor separation under the conditions of Fig. *
With a separation of about
2 mm between the two sensor
layers and pixel 2.5 mm long a hit in the inner of
the two sensors is compared to the hits in three columns on the outer sensor. For modules in the forward
the two sensors will be
offset to maximize the active area. Algorithms for matching hits in
to correspond to a
threshold will be studied using simulations. The algorithms implemented will need some level of
configurability to optimize the performance of the module.
Estimates of the power requirements have been mad
e which suggest that, using 130nm CMOS, a total
consumption of 150
r channel might be achievable,
W per channel consumed on the
. The readout ASIC (ROC) for each column is assumed to be a 128 channel front
ith amplifier and other circuits in each pixel, plus an "assembler" at the periphery where the trigger data are
temporarily stored and the comparisons of patterns between the two layers are made. Probably several columns
will be amalgamated into a single c
hip, perhaps with up to 8 adjacent channels (20mm wide). At the edge of the
module there is another ASIC, referred to as a "concentrator" which would be the interface to the GBT in both
input (clock, trigger, control data) and output (data for the track
(left) Schematic of possible layout of ROC chip to read out 128 pixel columns, in this case grouped in units of 4 ROCs per
chip. (right) Schematic of the
data flow to allow comparison lo
gic to be placed in the assembler
area of the ROC, at the
periphery of the sensor.
of contributions to power consumption on a pT module in
Source of estimate
amplifier, discriminator and
estimates made for
ATLAS pixel cell
in 130nm CMOS [ref].
Incorporated in ROC
Few PLLs/module requiring few mW
comparison logic and transfer
to assembler: 250µW/ROC
[ref to W Erdmann's talk]
across module to
transmission to remote GBT
2 hits per module/bx
time and address
PSI low power twisted pair
developments B. Meier
[TWEPP2008] which demonstrated
less than 10pJ/bit for distances of
bout 2m at 160Mbps.
Buffer data to and from GBT
2 ASICs @ 20mW each
Total with DC
80% efficiency assumed
Full readout of stored data
following L1 trigger
Comparison with pixel cell,
extrapolated to 130nm CMOS
to the total power required for pT layers
comes from the GBT links, which
are assumed to require 2W/channel for
3.2Gbps data rate (excluding error correction bits). These
to a requirement for 1000 GBT links to read out a layer of about 40M pixels at radius of 25cm, assuming a data
r of 20 and an occupancy of 0.5
% and 24 bits transmitted for each selected pixel. However
figures also assum
% use of the GBT bandwidth which is not very likely. A more realistic figure might be
% use of the GBT, so doubling the link power requirement to 6kW for the layer. The GBT transceivers
should be located outside the sensitive Tracker volume, probab
ly in the region presently occupied by the TEC
bulkhead. They will present difficult challenges to cool such a large number of transmitters and for component
The total power consumption for stacked layers with these pixel dimensions ca
n be estimat
ed [GH last talk]
to be about 9kW for 40M pixels at 25 cm radius, and 17kW for 75M pixels at 35 cm radius. The total number of
links required is 2900 and 5600 for the two cases; this does not allow for full readout of the layers, only track
trigger data. T
hese layers will therefore represent the major contribution to power consumption of a likely layout
of a new Tracker and great care will be needed not to allow either power, material or numbers of links to
increase significantly if the tracking performance
is to be maintained.
The ROC logic should reject large clusters which could not be consistent with a high
track. For the pixel
dimensions considered, the occupancy is estimated, by simulations a
nd extrapolations of values at 10
be less than 0.5
. This is sufficiently low that most columns will be empty and one hit per
column is the most likely case. Double hits in a column will occur but are most likely to be from charge sharing
between pixels. A method whi
ch would allow to read out small numbers of hits in each 40MHz clock cycle has
so that the comparison logic can be placed at the periphery of the module. If this scheme
proves not to be sufficiently robust at the maximum occupancy, alternatives will be studied, such as transferring
data to the periphery at 80MHz.
This logic and modu
le design allows the material to be minimized underneath the active region of the sensor,
which has obvious advantages. As the module design progresses it will be possible to evaluate more rigorously
the total material and attempt to optimise it. At presen
t, this concept also seems to be the most economical way
of accessing the data by avoiding transferring data at high speed between pixels in the two layers of the stack.
However, since the logical design is at a very early stage and this is a new area, it
is important to understand
well the trade
offs in decision logic by comparing with alternative concepts. It is also possible that module
assembly issues will prove to be important in manufacturing
modules on a large scale. Therefore a second
type of mo
dule design will also be developed (fig from Sandro) in which data will be transferred through an
intermediate substrate from one pixel layer to another. It seems that this may be achieved using advanced
assembly methods which are already in widespread use
in industry and this is being explored with potential
Fig * shows how such a module might be assembled using coarse pitch bump bonding to connect sensor to
ROCs and place the module on a low frame so the module can be assembled wi
th minimum material in the
Fig. Schematic of a possible assembly sequence
The second type of module is illustrated in Fig. These modules are vertically integrated, but make use of
fairly standard technologies, such as wirebonding and bumpbonding.
Fig. (left) Schematic
of a module, assembled from 18 ROCs bonded to a sensor.
Fig. Section through module showing two different possible assembly techniques
Need to expand more on this
comment on technologies and technology developments needed for this proposal
Sandro, Geoff, and others
Status of simulation studies
These ideas build on a significant simulation effort over the last few years which have developed the tools
needed to model and study stacked layers and have produced results
, presented already in many CMS meetings,
which demonstrate the feasibility of t
he module layouts which are proposed.
The main results which have been produced, and presented in many CMS and other meetings, include
demonstration that pixellated few mm x 100
m detectors at intermediate radius, with stack spacing in the few
can effectively reject low transverse momentum tracks and achieve a high efficiency above threshold,
estimates of occupancies in such layers, including from jets.
tudies of the algorithms which are required to select the higher
tracks, estimates of the
studies to validate results from the fast simulations variation of occupancy with sensor thickness studies of the
impact of orienting the sensors to take advantage of the Lorentz drift occupancy estimates in jets, and the
they do not produce significantly higher densities of hits in such pixellated layers
NB the contributions are still very provisional so we expect to add to and correct this information
Imperial College will contribute to the
tasks of performing simulation studies, developing the readout chip
and detector evaluations.
Other UK groups (tbc) are interested in simulations and aspects of module design as well as contributing to
the logic and readout development.
contribute to simulation studies and 'off module' electronics for a module evaluation and
participation in test beams and data analysis.
At CERN many aspects of the module design, including cooling and assembly, are of interest. The CERN
MIC group will con
tribute to several aspects of the readout and other ASIC developments and packaging.
The Perugia group would contribute to sensor and module development, including evaluation studies. Other
Italian groups that could contribute to the electronic
s and modul
development include Padova and Torino.
Topics and goals of
Below is a description of the R
&D activities that are proposed within this proposal. The goal of the proposal
is to demonstrate a module that will satisfy the requirements for
providing track trigger primitives for the SLHC
phase II upgrade by 2012.
Contributions to this section from CU + IC
The ROC and the associated logic for forming the track stubs should be simulated in detail to understand the
performance of the algorithms implemented. This work will build on the studies done within the track trigger
primitive simulation group.
Some of the goals for these studies involve:
Each pixel will have an adjustable threshold. For pixels having a charg
e deposit above this threshold a
clustering algorithm will be applied. This clustering algorithm could be implemented as a pattern that requires
2(3) or less pixels in a column. It can also be investigated to perform a two dimensional clustering where
elations are made across columns.
A column consists of 128 pixels in the strawman layout. One concept is that we would accept at most one
cluster per column. The impact on the efficiency from only accepting on cluster per column has to be studied. It
o be justified that this approach will work in dense tracking environments such as jets without any
significant loss of efficiency.
Results to date are encouraging.
The algorithm for comparing the found clusters in the two different stack members will need
to be simulated
to explore the efficiency for finding the track segments.
We will take the patterns of hits from the detector simulation and use as input to the electronic simulation to
predict the digital power associated with the logic.
We will simulate
the data volume produced by the proposed algorithms and the performance of the data
The tools for doing these simulations are now (mostly) in place. We have the fast and full simulation
working for different stacked detector geometries
. We need to produce code that emulates the proposed
hardware implementations at the 'bit level'.
The results from these studies will guide the development of the readout chip.
ROC design and digital logic
Contributions to this section from IC+CERN
is the design of the analog readout chip done in 130 nm technology.
Data concentrator and control
Contributions to this section from CERN
The 'data concentrator' chip as indicated in Fig. XXX has multiple purposes. (Similar in some sense to the
.) It will provide the interface
distribution of clocks, triggers, and other program
ing of the
ROC, and it
will also coordina
te the readout of many ROCs
and concentration of the data to better utilize the
bandwidth of the links.
We should cons
ider if we can develop the first prototype module without this data concentrator chip. See
further discussion in the section on prototype evaluation. Can we use GBT (prototypes) for this? (Will they be
Contributions to this section fro
Likely, there will be another submission the HPK sometime in early 2010. We should establish a
collaboration with the existing sensor effort to make a prototype sensor that is compatible with the module
proposed in this proposal.
ontributions from Aachen? Katja Klein?
Contributions to this section from CU+IC+CERN (D.A. and K.G.)
There are many
be addressed in assembling this type of module:
Detailed layout of the module.
Interconnection between the two sensors.
Mechanical support, and material budget.
Contributions to this section from CU + Padova?
The goal is to test these modules in a beam test, see next section. In order to program and readout these
modules we will need to have a test stand that is able to interface these modules. What is required here will
depend a bit on the exact plan for proto
typing these modules. In particular, if will include the data concentrator
chip in the (first) prototype or not.
Some of the requirements for the test stand include:
Program/initialize the front ends, including the track trigger primiti
Distribution of triggers. Including L0 triggers?
Charge injection generation. (Calsynch triggers.)
Synchronization with test beam pulses.
Readout data. What rate? Prescaling?
Are there existing test setups that we can use, or develop from?
Can we use commercial test boards. (Discuss
with Mark Raymond.) Would we want to build on existing CMS electronics (TTC, FECs, etc.)? I'm not sure that
this would make sense as most of this is likely to be replaced in the future, and is a rather complicat
Contributions to this section from CU + others?
It is crucial to test the performance of these
modules in a test beam. As Lorentz drift is an important issue
for the performance of these modules we need to be able to test these modules in a magnetic field. Goals from
the test beam would include:
Study the hit efficiency
Study the cluster size and c
on for different target thresholds.
ill be necessary to anticipate these beam tests well in advance so suitable ancillary equipment is available
to carry out the tests. This will include a suit
able beam telescope to measure trajectories of incident and outgoing
particles, possibly a
t more than one downstream location in case secondary particles are generated, eg using a
simple target, and the ability to rotate the pT module under test to study f
eatures such as charge sharing.
vity matrix' for the proposed R
&D is shown in Tabl
NB very provisional!!
s a list of the goals of this R
Simulate 'at the bit level' the functionality of the
module. This will guide the development of the
Understand how mechanically and electrically we can integrate one of these modules. This includes
Prototype the module and test it with a source and beam.
Relation to other WG
The goal is to have prototype modules that have been tested in a test beam by the end of 2012. This is a
rather ambitious goal, even though we are employing techniques that are well understood in our community.
schedule is shown in Table ….
al work will involve further simulation studies. This builds on the work done by the track
simulation group, but will focus on a more detailed simulation of the performance and requirements of the
proposed readout chip. The plan is to start the des
ign of the ROC, including the related correlation logic, by early
2010. The simulation work will continue in parallel to refine the algorithms. At the same time as the ROC is
being defined we will need to design the sensor. Later in 2010 we will start the
work on the module and
evaluation tools as the specific interfaces with the ROC and module are being specified. The last year will be
devoted to evaluation and beam tests, but will probably also involve iterations on different components.