Available on CMS information server CMS NOTE 2007/000

![](media/image1.png){width="7.385416666666667in"
height="1.5833333333333333in"}

December 14, 2006

Summary of CMS Pixel Group Preparatory Workshop on Upgrades

D. Bortoletto

*Purdue University, West Lafayette, IN, USA*

K. Burkett, J. Butler, H. Cheung, E. Gottschalk, S. Kwan

*Fermilab, Batavia IL, USA*

> A. Dominguez
>
> *University of Nebraska, Lincoln, NE, USA*
>
> **Abstract**

This is the summary report of a workshop held by the CMS Pixel Group at
Fermilab on October 9-12, 2006. The performance of the CMS Pixel
Detector will begin to degrade after exposure to a fluence of \~6x10^14^
particles/cm^2^. This fluence will be reached approximately 4-5 years
into LHC operation. This is earlier than the end of the first phase of
LHC operation, which will achieve an integrated luminosity of more than
300 fb^-1^. After Phase 1, there will be a long shutdown to upgrade the
machine for 10^35^ cm^-2^s^-1^ peak luminosity, followed by a Phase 2 of
several years of running at this higher luminosity. Upgrades to most
electronics systems, the trigger, the data acquisition system and some
detectors will be required due to higher occupancies and radiation
levels, and possibly shorter bunch crossing intervals. The goal of the
workshop was for members of the Forward Pixel Group, along with
colleagues in the Barrel Pixel Group, to formulate the requirements of
these two upgrades and to outline a program of R&D of a design to meet
those requirements.

Summary of workshop held at Fermilab*,* October 9-12, 2006

Preliminary version

1.  Executive Summary

The performance of the CMS Pixel Detector will begin to degrade after
exposure to a fluence of \~ 6 x 10^14^ particles/cm^2^, which will be
reached 4-5 years into LHC operation. This is before the end of the
first phase of LHC operation, which will achieve an integrated
luminosity of more than 300 fb^-1^. An intermediate upgrade of the pixel
detector may be necessary to maintain good tracking until the end of
this phase of CMS. After Phase 1, there will be a long shutdown to
upgrade the machine for 10^35^ cm^-2^s^-1^ peak luminosity, followed by
a Phase 2 of several years of running at this higher luminosity.
Upgrades to most electronics systems, the trigger, the data acquisition
and some detectors will be required due to higher occupancies and
radiation levels, and possibly shorter bunch crossing intervals. CMS is
also considering the addition of a new requirement of the upgraded
detectors: to provide track information to the Level 1 (L1) trigger.

The goal of the workshop was for members of the Forward Pixel Group,
along with colleagues in the Barrel Pixel Group and other interested
parties, to formulate the requirements of these upgrades, including
possible incorporation of tracking triggers, and to outline a program of
R&D to meet those requirements. Three working groups were established to
carry out the charge of the workshop.

1.1 Major Findings

1.1.1 Interest of US groups in pixel/tracker upgrades:

An important aspect of the workshop was to determine the level of
interest in the pixel groups for carrying out this R&D, and to determine
whether other collaborators in CMS share this interest. The attendance
at the workshop was excellent. More then 50 people participated in some
phase of the activities. When asked by their working group leader, most
expressed a desire to work on upgrade R&D and on the upgrade projects.

1.1.2 Urgency to begin R&D

The design and construction of the tracking and trigger systems for CMS
took a decade. The upgrades are less extensive, but by necessity, more
ambitious and complex. It is necessary to begin the R&D very soon.

1.1.3 Relationship to definition of the SLHC upgrade

The overall luminosity goals for the SLHC are defined. However, key
details such as the bunch crossing interval are not yet specified. Early
efforts in SLHC R&D should concentrate on key areas that do not depend
on characteristics of the upgraded LHC that have not yet been fixed or
should address technology issues that occur under any of the potential
upgrade scenarios.

1.1.4 Relationship to other CMS and LHC efforts

While this workshop was hosted by the CMS pixel group, it was attended
by members of the Silicon Strip Tracker and the Trigger Groups. While
the current detector has two tracking technologies, pixels to about 15
cm in radius and strips from 20 cm on out, the upgraded detector may
have more technologies and may have different transition radii. Some
layers may be introduced specifically to facilitate triggering. The
pixel group should participate in the Tracking Upgrade and in CMS
upgrade workshops and activities as well as activities involving other
LHC experiments.

1.1.5 Possible opportunities for external collaboration to develop new
technologies

The short time scale, the complexity, and the cost of the new
technologies that are likely to be needed for the SLHC upgrade strongly
argue for collaboration with other LHC experiments and with industry.

1.2 Recommendations

1.2.1 General recommendations

1.  The Pixel group should adopt a formal structure and organization to
    pursue the SLHC R&D. The group structure adopted for this workshop
    could provide the basis for this organization.

2.  The Pixel Upgrade effort should be part of the overall CMS Tracking
    upgrade effort, which is in turn part of the CMS SLHC upgrade
    effort. Either through the tracking upgrade or by some other
    arrangement, the Pixel Upgrade effort must maintain close
    collaboration with the trigger upgrade.

3.  A simulation package that permits one to easily modify the geometry
    of the tracking system and to add layers of different types is
    essential to developing the tracking and trigger upgrades. The
    package should permit a "prompted" reconstruction with a method for
    adding alignment errors, inefficiencies, confusion, backgrounds, and
    noise. The existing CMS simulation packages should be evaluated for
    their suitability to this task before one considers developing a new
    program.

1.2.2 Recommendations of Working Group 1 - Sensors and Readout Chips

1.  Development is needed to find a radiation hard technology for layers
    below 8 cm that minimizes charge trapping, such as 3D detectors,
    diamond, amorphous silicon and other novel techniques.

2.  At larger radii, financial constraints require the employment of
    more standard strip or pixel detectors. For radii between 10 and 25
    cm detectors with n-type silicon pixels on p-bulk substrates allow
    the collection of electrons rather than holes and good charge
    collection without full depletion. These detectors are potentially
    cheaper since they require single-sided processing but most particle
    physics detectors have used p-strips on n-bulk. R&D is required to
    understand these novel detectors and to develop the necessary
    front-end electronics.

3.  Currently bump bonding dominates the construction cost of pixel
    modules. We recommend R&D on integrated detectors (such as MAPS,
    SOI, 3D-packaging detector) which do not require bonding and on
    cheaper and more widely available commercially bonding solutions.

4.  One of the current solutions for including track information in the
    trigger relys on closely spaced sensors to quickly find mini-vectors
    and measure tracks Pt. This is called "stacked layers." The pixel
    size for this scheme is of the order of 20 x 200 m^2^, or 50 x 500
    m^2^. The senso thickness must be 50 m compared to the 300 m thick
    sensors currently used. If stacked layers are needed, development of
    radiation hard thin detectors is critical. Candidates are SOI and
    3D-IC detectors.

5.  Readout data losses increase with luminosity. Many of the current
    solutions to reduce the readout data loss rate in LHC phase 2
    require 130 nm technology instead of the 250 nm currently used in
    CMS. R&D to determine the radiation hardness of the 130 nm
    technology is needed.

1.2.3 Recommendations of Working Group 2 - Detector Geometry,
Construction and Assembly

1.  Fully benchmark the current detector by verifying the current
    material in the simulation and measuring the cooling
    capacity/performance of the current system, which may be
    over-designed.

2.  For upgrades/replacements to survive until the end of Phase 1,
    explore the re-use of the existing cooling and support structure and
    study the feasibility of replacing individual radiation-damaged
    components. Another simple option is to leave the current disks in
    place and install the third disk at each end.

3.  As there are many different possible configurations, especially in
    Phase 2, it is important to develop tools that allow different
    designs to be evaluated rapidly.

4.  Steps should be taken to reduce detector material. With 40-50% of
    the material coming from cooling, possibilities for altering the
    cooling scheme should be pursued. In addition, the multi-layered
    structure of the current detectors should be evaluated and
    simplified or optimized if possible.

1.2.4 Recommendations of Working Group 3 - Level 1 Tracking Triggers
using the Pixel Detector

1.  Identify specific "benchmark" physics analyses that help to
    establish the physics case for a CMS tracking trigger. The goal is
    to use these physics analyses to evaluate the performance of
    different trigger algorithms and use the performance metrics to
    select a baseline trigger design.

2.  Develop a "toy geometry" that can be used with the existing CMS
    simulation package to perform a realistic evaluation of the proposed
    Stacked Trigger concept.

3.  Develop a "toy geometry" that uses less complex geometrical shapes
    (compared to the complete CMS detector geometry) for detectors in
    the pixel and inner silicon strip tracker volumes. The geometry file
    should be documented so that it can serve as a basis for trigger
    studies by CMS physicists who are not familiar with the intricacies
    of geometry files.

4.  Perform more realistic simulations to evaluate the performance of
    currently proposed L1 tracking trigger schemes.

```{=html}
<!-- -->
```
2.  Background

This report constitutes a summary of the outcome of the CMS Pixel Group
Preparatory Workshop on Future Upgrades \[[^1]\], held at Fermilab from
October 9-12, 2006. The beginnings of the formulation of requirements
asked for in the Workshop Charge are given in this report, as well as a
start on an R&D plan.

Participants in this workshop consisted of members of the Pixel Group
and interested collaborators in CMS working on a variety of other
projects, especially the CMS silicon strip tracker and trigger. This is
both natural and desired, given the interdependence of developing an
upgraded pixel detector, upgraded tracking detector, and the
introduction of an L1 tracking trigger for SLHC. Included in this report
is our proposal for the next steps in the establishment of requirements
and proceeding with an R&D plan. One of these steps is to join in with
the existing CMS SLHC Group and start to participate in the wider
discussion within the Tracker Group and with the CMS SLHC Group. This
report therefore also serves to inform the Tracker and CMS SLHC Groups
of our interest in participating in the work for a CMS upgrade.

2.1 Charge for the Workshop

As background, we have included in this section the text from the charge
given to the CMS Pixel detector upgrade workshop \[[^2]\].

The performance of the CMS Pixel Detector will begin to degrade after
exposure to a fluence of \~ 6 x 10^14^ particles/cm^2^. This fluence
will be reached approximately 4-5 years into LHC operation. This is
earlier than the end of the first phase of LHC operation, which will
achieve an integrated luminosity of more than 300 fb^-1^. After Phase 1,
there will be a long shutdown to upgrade the machine for 10^35^
cm^-2^s^-1^ peak luminosity, followed by a Phase 2 of several years of
running at this higher luminosity. Upgrades to most electronics systems,
the trigger, the data acquisition system and some detectors will be
required due to higher occupancies and radiation levels, and possibly
shorter bunch crossing intervals.

The US Research Program includes funding for R&D to design a replacement
pixel detector that can survive and perform well through the end of
Phase 1, and another replacement that can survive and perform in Phase
2. It does not include funds to construct either detector. Funds for
construction would have to be negotiated separately.

There have been meetings to begin to formulate the R&D for the upgrades
of all aspects of the CMS detector to handle 10^35^ cm^-2^s^-1^ peak
luminosity. The Forward Pixel (FPIX) community has participated in these
meetings but has not yet developed an R&D plan for either upgrade.

The goal of the workshop was for members of the Forward Pixel Group,
along with colleagues in the Barrel Pixel Group, to formulate the
requirements of these two upgrades and to outline a program of R&D of a
design to meet those requirements.

An important aspect of the workshop was to determine the level of
interest in the FPIX and BPIX groups for carrying out this R&D, and to
determine whether other collaborators in CMS share this interest. The
Silicon Strip Tracker will also carry out an upgrade for Phase 2
(although no intermediate upgrade is currently planned), and may
consider pixel detectors for the replacement of the inner layers of the
Tracker Inner Barrel. It may make good sense for the "vertex detector"
and "tracker" parts of the overall CMS tracking effort to work together
to accomplish the upgrades. One goal of the workshop was to prepare the
FPIX group to participate effectively in the wider discussion within the
Tracker Group.

CMS is considering the addition of a new requirement of the upgraded
detectors: to provide track information to the Level 1 (L1) trigger.
This is a daunting problem, given the event rates, the amount of data,
the high radiation levels, the severe constraints imposed by the
existing trigger architecture (short Level 1 latency), and the very
limited cable plant. This is a new area of R&D, and is the subject of
this section of the report as any L1 tracking trigger is expected to
have strong implications for the design of the pixel detectors and the
electronics. Moreover, the designs of the total upgraded pixel system,
tracker and trigger are inextricably linked at such a deep level that
upgrade designs of any of these elements must be closely coupled to the
others. It was a major goal of the workshop to begin to establish the
requirements for the tracking trigger at L1 and to formulate a plan for
meeting them for Phase 2. Also we needed to consider during the workshop
the possible incorporation of triggering for the intermediate detector.

Although R&D for a possible upgrade of the pixel detector during Phase 1
running is mentioned in the above charge, it should be mentioned when
this upgrade may take place. There will need to be a long shutdown of
the LHC to upgrade the LHC with a new beam dump, and to improve the RF
and other elements in order to take the luminosity above about 310^33^
cm^-2^s^-1^. This would provide an opportunity to put in or replace a
pixel layer of a new design.

An excellent resource of information is the CMS SLHC web site, which
includes a link to the draft Expression of Interest \[[^3]\]. The draft
EOI includes an executive summary with a very good overview and outlook
for CMS upgrades. The four CMS SLHC workshops held so far provide an
excellent source of information on current and past work in almost all
areas of CMS SLHC upgrade R&D.

A notional timeline for the upgrade steps can be seen in Fig. 1.

![](media/image2.jpeg){width="6.0in" height="0.9861111111111112in"}

Figure 1: Timeline for steps in the Tracker upgrade

2.2 The Charge for Individual Working Groups

To provide some structure to the discussions of the workshop, we divided
into three working groups. The schedule was arranged to encourage
interactions among the three groups. The charge to each group is given
here

2.2.1 Charge to Working Group 1 -- Sensors and Readout Chips

The goals for the working group are to understand the limitation of the
current detector and technology as radiation dose and luminosity
increases, formulate the requirements of the two phases of the upgrades,
evaluate the technical challenges, explore the advances in sensors and
electronic technology, outline a program of R&D to address these
challenges using promising technologies, and identify areas in which the
US groups have expertise and a strong interest in participation.

2.2.2 Charge to Working Group 2 -- Detector Geometry, Construction, and
Assembly

The goals are to review the experience in construction the current
detectors to see whether they could be simplified to make them easier to
build and maintain, to investigate how to reduce the amount of material
in the detector, and to consider the changes in the geometry required to
cope with the higher occupancies and radiation levels. The group should
consider what geometry (pixels, strips, sizes) is most appropriate at
each radius and pseudorapidity, especially in light of the requirement
to provide tracking triggers, at Level 1. The group should outline a
plan of R&D to address these issues.

2.2.3 Charge to Working Group 3 -- Level 1 Tracking Triggers using the
Pixel Detector

The goal for the working group is to explore the use of CMS pixel
detectors to provide data to a tracking trigger at Level 1. Specific
tasks for the working group are to begin developing requirements for the
two phases of upgrades, identify technical challenges, and outline a
program of R&D, including identifying areas of expertise for US groups
and identifying groups with a strong interest in participation.

2.3 Agenda and Participation

The agenda included plenary talks and the parallel sessions of the three
working groups. Joint sessions were scheduled to promote interactions
among the groups. On the afternoon of October 12, the final day of the
workshop, each working group presented a summary of its work and its
plans for the next step in the development of the upgrades.

The full agenda is given in Appendix 1. A full list of participants is
given in Appendix 2. The talks from the workshop are available on the
CMS Indico Server at the following link.

<http://indico.cern.ch/conferenceDisplay.py?confId=6904>

3 Report of Working Group 1 -- Sensors and Readout Chips

WG 1 focused on the sensors and the readout technology required for
operation in Phase I and Phase II of the LHC. For Phase I we assume a
LHC operation scenario where the luminosity increases to 2.5 ×10^33^
cm^-2^s^-1^, 5 ×10^33^ cm^-2^s^-1^, and 7.5 ×10^33^ cm^-2^s^-1^ in year
1, 2 and 3 respectively. The machine reaches the luminosity of 10^34^
cm^-2^s^-1^ in year 4, and then continues operating at this level until
a long shutdown for the SLHC upgrade. The SLHC will then operate at an
instantaneous luminosity of 10^35^ cm^-2^s^-1^ in Phase II.

The performance of the silicon sensors at both phases of the LHC is
challenging because of the high track rate and the radiation
environment. Radiation effects lead to increase of the depletion
voltage, increase of the leakage current and decrease of the charge
collection efficiency. In order to retain high tracking efficiency and
spatial resolution a replacement of the pixel detector and the inner
tracking layers is needed. Further constraints on the tracking upgrade
are due to the necessity to include tracking information in the trigger
to limit the L1 rate in Phase II of the LHC. The trigger issues were
discussed in detail by WG 3. A promising L1 tracking trigger called
"Stacked Triggers" has been proposed for SLHC. It relays on closely
spaced sensors to quickly find mini-vectors, measure tracks Pt, and
reduce the L1 rate. The pixel size required for this scheme is of the
order of 20 m by 200, or 50 m by 500 m. The sensors thickness must be 50
m which is technically challenging since most of the silicon sensors
currently operating at hadron colliders are about 300 m thick.

Working Group 1 was devoted to understanding the technical limitations
of the current detector, the requirements of the two phases of the
upgrades, the possible sensor and readout electronics technologies that
are of interest and possible areas of research that will be of interest
to the US groups. The main goals for the workshop for Working Group 1
are:

-   To understand the limitations of the current detector and technology
    as radiation dose and luminosity increase;

-   To formulate the requirements of the two phases of the upgrade;

-   To evaluate the technical challenges, explore the advances in sensor
    and electronics technology;

-   To outline a program of R&D to address these challenges using
    promising technologies; and

-   To identify areas in which the US groups have expertise and a strong
    interest in participation

3.1 Lifetime of the Current Detector

It is generally agreed that sensor is the source of degradation during
Phase I but that the readout chips should survive the radiation dosage
till the end of Phase I.

**3.1.1 Sensor**

The current CMS pixel detector uses n-on-n^+^ hybrid pixel technology
with p-spray and p-stop isolation in the barrel (BPix) and the end-cap
(FPix) respectively. Test beam measurements indicates that the sensors
will able to maintain good tracking efficiency up to a dose of \~
1×10^15^ particles/cm^2^ and then their performance will rapidly
degrade. For the CMS barrel located at 4.3 cm from the interaction
region a fluence of 1×10^15^ particles/cm^2^ will be reached after a
luminosity of 300 fb^-1^ towards the end of the phase I of the LHC. We
expect the fluence to decreases as r^1.5^ where r is the radius since
the 1/r^2^ dependence is modified by the magnetic field. For the inner
radius of the forward plaquettes at 5.8 cm, we expect a total dose of 6
×10^14^ particles/cm^2^ after 300 fb^-1^. Therefore, both barrel and
forward pixel sensors should be sufficiently radiation hard to survive a
300 fb^-1^ Phase 1 of the LHC even if their performance might be
degraded.

In Phase II we expect to collect a total luminosity of 2500 fb^-1^ which
corresponds to a dose of 1.4×10^16^ particles/cm^2^ and 7.8×10^15^
particles/cm^2^ at a radius of 4.3 and 5.8 cm respectively. New
technologies are necessary for both the inner barrel and end-cap layers
if physics requires a layout similar to the one adopted for the current
BPix and FPix. Moreover finer granularity will be required to maintain
the current performance due to the increased instantaneous luminosity.

**3.1.2 Readout chips**

While the pixel readout chip would survive the fluence that it would
receive during Phase I, as the luminosity increases, the data losses
become more significant. Using a high rate X-ray machine, the PSI group
has been able to show that as the hit intensity grows, the data loss
will become more severe and this is dominated by loss due to the
timestamp buffer overflow. As the pixel multiplicity rises, data buffer
overflow will also become a problem. As can be seen in figure 2, there
will be a steep rise of inefficiency due to the buffer limitations. To
reduce the data loss at high fluences, the size of the data buffers will
need to be increased.

![](media/image3.png){width="4.485416666666667in" height="3.6625in"}

Figure 2: Simulation of data loss at the full LHC luminosity of 10^34^
cm^-2^s^-1^ compared with measurements on a pixel detector done in a
high rate X-ray box (which provides a photon fluence up to 300
MHz/cm^2^) and a high rate 300 MeV ^+^ test beam at PSI (variable
intensity up to 120 MHz/cm^2^) .

The influence of the buffer size on the inefficiency of the readout
chips could be seen in Figure 3. The present PSI46v2 pixel readout chip
has 12 time stamp buffers and 32 data buffers. On average at the nominal
LHC luminosity of 10^34^ cm^-2^s^-1^ the average multiplicity per
readout chip is 2.2. So, the inefficiency due to the current size of the
buffer is negligible. However, as the nominal luminosity increases by a
factor of 2.5, one can see that the buffer size will need to be expanded
to 24 for the time stamp and 64 for the data buffers in order to keep
the data loss at a minimum. In the SLHC environment where the luminosity
will reach 10^35^ cm^-2^s^-1^ the time stamp buffer will need to be
increased to 60 and the data buffers to about 190 to lower the data
loss.

![](media/image4.png){width="5.172916666666667in"
height="3.467361111111111in"}

Figure 3: Influence of buffer size on data loss for a pixel layer at 4cm
from the beam as a function of luminosity.

2.  The SLHC Requirements

3.2.1 CMS Tracker Upgrade

As described earlier in this document, a replacement pixel detector that
can survive and perform well through the end of Phase 1 of LHC operation
will likely be needed. Although little else of the detector will change,
this may present an opportunity to include components that would make it
possible to use pixel data in the CMS L1 trigger, or to demonstrate some
pieces of technology needed for Phase 2. After Phase 1, there will be a
long shutdown to upgrade the machine for 10^35^/cm^2^-s peak luminosity.
The Phase 2 running at higher luminosity will likely require us to
design a replacement pixel detector that can be used for an effective L1
tracking trigger.

Some parameters of the SLHC accelerator upgrade are not yet decided, but
are undergoing active deliberation, discussion, and study. It seems that
the most likely candidates for bunch crossing intervals are 12.5 ns, 25
ns and 75 ns.

Upgrades of the CMS detector for SLHC are also not yet decided and are
also undergoing consideration. Extensive R&D is needed before a decision
can be made. However, it is likely that part of the pixel detector will
be replaced during Phase 1 operation of the LHC, and for Phase 2, all of
the pixel detector and the inner part of the strip detector will be
replaced. This gives the physical volume for which upgrades can be made.

The timescale for the R&D was taken to be that given in the CMS SLHC
draft EOI. A summary of the proposed roadmap is given below \[[^4]\].

Within 5 years of LHC start

-   New layers within the volume of the current pixel tracker which
    incorporate some tracking information for an L1 trigger

    -   Room within the current envelope for additional layers

    -   Possibly replace existing layers

-   "Pathfinder" for full tracking trigger

    -   Proof of principle, prototype for larger system

-   Elements of a new L1 trigger

    -   Utilize the new tracking information

    -   Correlation between systems

Upgrade to full new tracker system by SLHC (8-10 years from LHC Startup)

-   Includes full upgrade to trigger system

Over the last couple of years, there have been four CMS upgrades
workshops. In considering the Tracker upgrades, these workshops have
highlighted the following issues:

1.  Power will be a major concern despite the trend to lower supply
    voltage going to 0.13 µm or lower CMOS processes.

2.  Material budget should not increase.

3.  The cost must be contained. The present pixel system costs about 500
    CHF/cm^2^ and is dominated by bump-bonding. Even if significant
    reduction can be made by going for example, to larger pitches and
    hence open up to more commercial bump-bonding vendors to do the
    flip-chip process, the cost of hybrid pixel detector will remain
    considerably higher then the current microstrip system costs.

4.  Large tracking systems are hard to build. R&D and qualification time
    is always underestimated.

5.  Sensor radiation hardness is a major concern, especially for the
    innermost layers.

6.  Off-detector electronics will benefit from technology evolution.
    However, because of the special constraints imposed by the tracker
    construction, these will remain challenging, e.g. optical links,
    laser drivers.

7.  The trigger requirement is vital to the upgrade for the SLHC and it
    poses stringent requirements to the design of the front-end
    electronics.

    2.  **SLHC environment**

At a luminosity of 10^35^ cm^-2^s^-1^ , the SLHC creates very
challenging technical problems with the high data rates, heavy radiation
damage, and event selection. Figure 4 shows the track rates as a
function of the radius at SLHC luminosity. Roughly, at the SLHC, we will
see similar rates at 18cm, 30cm, and 50cm as for the current pixel
detector at r=4cm, 7cm, and 11cm.

![](media/image5.png){width="3.196527777777778in"
height="2.6305555555555555in"}

> Figure 4: SLHC track rate versus radius of the layer.

There has been quite a lot of work to predict the detector environment
and the fast hadron fluence expected at the SLHC. Figure 5 shows the
expected neutron, pion, and proton fluence as a function of the tracker
radius. As one can see, at a radius below 10cm, the fluence will be
dominated by slow pions.

![](media/image6.png){width="2.495833333333333in"
height="1.8979166666666667in"}

Figure 5: The expected neutron, pion, and proton fluence at the SLHC.
The data is from S. Baranov, et.al. "Activation and Shielding
Optimization in ATLAS", ATL_GEN-2005-001, January 2005.

In the current LHC detector, we can identify three different regions to
match the expected radiation damage during the lifetime of the detector
and the occupancy at the peak LHC luminosity. This is summarized in
Table 1. One can see that the radiation fluency increases by about a
factor of 10 from one region to the other.

  --------- ------------- ------------------------------------------------
  R         Total Fluence Technology

  \> 50 cm  10^13^        p-on-n strips, 500 m thick, high resistivity,
                          200 m pitch

  20-50cm   10^14^        p-on-n strips, 320 m thick, low resistivity, 80
                          m pitch

  \< 20 cm  10^15^        n-on-n pixels 270 m thick sensors low
                          resistivity, oxygenated
  --------- ------------- ------------------------------------------------

Table 1: Current CMS detector trcker choices

As we move from the LHC to SLHC, the radiation fluency will increase by
a factor of 10. This poses a severe technical challenge. In Table 2, we
list the same three regions and the possible detector technology.

  --------- ------------- ------------------------------------------------
  R         Total Fluence Technology

  \> 50 cm  10^14^        Present rad-hard technology (or n-on-p)

  20-50cm   10^15^        Present n-on-n pixel or n-on-p pixels

  \< 20 cm  10^16^        RD needed
  --------- ------------- ------------------------------------------------

Table 2: Possible choices of Tracker technology for SLHC

3.3 Advances in Sensor and Electronics Technology

3.3.1 RD50 on radiation-hard sensor for the SLHC

Strategies to reach the level of radiation hardness required for the LHC
are actively investigated by the CERN-RD50 collaboration. The main
effects of the radiation are the increase of the leakage current,
trapping and the space charge. The space charge increase which leads to
the increase of the depletion voltage is reduced for silicon containing
a high concentration of oxygen. The RD50 collaboration is currently
studying oxygen enriched materials such as MCz silicon. Current results
point to thick p-type MCZ silicon as a low cost solution up to fluences
of \~ 2×10^15^ particles/cm^2^ where it yields a S/N \>15. A layout of
n-type silicon pixels on p-bulk substrates allows the collection of
electrons rather than holes and good charge collection without full
depletion. These detectors are potentially cheaper since they require
single-sided processing. They are good candidates in for radii between
10 cm and 25 cm. R&D on MCZ silicon is currently already ongoing in the
US, at Purdue University, Rochester and BNL.

The increases in leakage current and in charge trapping are not affected
by oxygenation. The increased leakage current can be controlled by
increase cooling. The reduction of the signal due to charge trapping
presently challenges the use of planar silicon detectors at a radius
below about 8 cm at the SLHC. A promising technology for the inner
layers is the so called 3D technology which is currently pursued by RD50
with IRST, by the 3Dc collaboration and Sintef. In 3D sensors the p+ and
n+ electrodes are processed inside the silicon bulk, instead of being
implanted on the wafer surface. The advantages of the 3D design compared
with the traditional planar geometry is that since the electric field is
parallel to the detector surface, the charge collection distance can be
several times shorter. This leads to a faster collection time and lower
voltage to reach full depletion. Therefore 3D detectors are more
radiation hard than planer ones. In fact the charge colleted with 3D
detector after heavy irradiation is similar to diamond as shown in
figure 6. The 3D technology is up to now the best to use very close to
the beam line. Two main drawbacks characteristics of this geometry are
that the columnar electrodes are dead-regions, and that the regions
located in the middle between electrodes of the same type present a
''zero-field'' region. This leads to a delay in the collection of
carriers generated in such zones that slowly move by diffusion until
they reach a region with a sufficient electric field. ATLAS is actively
pursuing R&D on 3D detectors as a possible replacement of their B-layer
at 4.00 cm from the interaction region.

![](media/image7.pct){width="5.054861111111111in"
height="4.189583333333333in"}

3.3.2 Novel concepts

One of the issues with the hybrid technology used in the current pixel
detector is the bonding between the sensors and the readout chip. BPix
is pursuing in-house bonding using indium. FPix is using a solder bump
bond process at IZM (Berlin, Germany) and RTI (NC, USA). The cost of
bump bonding is currently one the dominant construction cost both for
barrel and encap modules.

Alternative to hybrid pixel are provided by Monolithic Active Pixel
Sensors (MAPS) which have generated a lot of interest and excitement in
High Energy Physics. In MAPS the detector and front end electronics are
combined on the same substrate using a commercial CMOS process. MAPS
offer relatively small signal level and the electronics is generally
limited to NMOS devices in a P-well. It is not well established if MAPS
are sufficiently radiation hard to operate at the SLHC.

Several presentations at the workshop focused on SOI detectors formed by
bonding wafers with low and high resistivity using a silicon oxide (SOI)
bond. The electronics can be processed on the low resistivity wafer
while the high resistivity wafer will provide the sensing elements. SOI
Active Pixels Systems have advantages over MAPS. For example, larger
signals can be achieved since the signal is proportional to the
thickness of the resistivity substrate. Many activities are ongoing in
the US using SOI processes such as OKI 0.15 μm and ASI (American
Semiconductor Inc.) 0.18 μm process. Hamamatsu, which successfully
produced the silicon strips for the CMS, is also interested in the
development of SOI sensors for the SLHC. We expect this technology to be
radiation hard since the sensors and read-out chip will be processed
separately. Nonetheless the expected yield is unknown and there is a
concern about adopting a technology that is not an industry standard.
R&D is needed to determine the feasibility of this approach. Both MAPS
and SOI are potential candidates for the stacked triggering layers.

The development of VLSI 3D-IC packaging in industry presents
opportunities for tracking and vertexing in particle physics. Improved
ROC performance has been achieved by transistor scaling to increase the
frequency response and the radiation hardness of transistors.
Nonetheless these advancements are limited by the interconnections
between discrete components and integrated circuits because the planar
layout. In fact, these interconnections consume a significant fraction
of the power dissipated and, cause increased latency and noise
degradation in digital systems. The development of technologies that
extensively utilize the vertical dimension to connect components solves
these problems. A 3D-IC chip is comprised of 2 or more layers (called
tiers) of active semiconductor devices which might have been fabricated
in difference processes that have been thinned, bonded and
interconnected to form a "monolithic" circuit. 3D-IC pixel detectors
offer many advantages including higher functionality in a pixel cell,
NMOS and PMOS transistors, and increased circuit density. The bonding
between the different layers could be achieved though oxide to oxide
fusion, copper-tin eutectic bonding and polymer bonding. Wafer to wafer
bonding using SOI is especially interesting since it permits very thin
layers which could be suited for the implementation of stacked
triggering layers. Since the 3D-IC technology is new, work is needed to
understand its radiation hardness, the cross talk between devices on
different levels, and issues connected with the power distribution and
the cooling. Fermilab is currently engaged in this R&D, but the effort
is currently focused on the ILC and not on the SLHC.

3.3.3 PSI Pixel Readout Chip Development

As described in section 2.2, as we go to higher luminosity, the size of
the time stamp buffer and data buffer on the pixel readout chip will
need to be increased to lower the data loss rate. In the current PIS46v2
chip, the size of the buffers is about 800 m. It's rather straight
forward to double the buffer sizes in the same 0.25m CMOS technology and
the design should take no more than one month. However, to increase the
buffer sizes to meet the need of the SLHC, it is necessary to migrate to
130nm technology just due to chip size considerations. In this case, the
buffer size would be about 1200 m.

Assuming that this limitation die to buffer sizes is removed, Figure 7
shows the data loss as function of luminosity and the various
contributing factors to this data loss. One can see that the pixel size
is not a big factor for all fluences and that data loss due to "pixel
busy" is not significant. The major source of inefficiency is the data
drain per double column. To reduce this data loss, it is conceivable to
go from a double-column architecture to single column. By doing so, we
can reach a 7% inefficiency at a luminosity of 4.5x 10^34^ cm^-2^s^-1^.
However, it is not clear whether this change can be implemented in the
0.25m process. More likely, process with smaller feature size will be
needed.

At the SLHC luminosity, as can be seen in Figure 8, the data loss below
a radius of 7cm will be far too high for the current architecture. For
higher radii, data loss will be dominated by readout losses. There are
two possible solutions to these problems. One of the solutions includes
a new parallel readout scheme which would require a new Token Bit Manger
(TBM). Another solution requires the development of a more complex
buffer logic which will allow continuous data acquisition without the
need of a column reset. In any case, these solutions can only be
implemented in the 130nm technology and will require major R&D.

![](media/image8.png){width="4.298611111111111in"
height="2.986111111111111in"}

Figure 7: Data loss in pixel readout chip assuming that there are no
buffer size limitations.

![](media/image9.png){width="4.156944444444444in"
height="2.4694444444444446in"}

Figure 8: Data loss at different radii for SLHC luminosity.

3.3.4 130nm CMOS and beyond

During the last 2-3 years, the HEP community has started R&D on
designing chips using processes with feature sizes below 0.25 µm. In the
previous section, we have stated several times that in order to meet the
requirements imposed by the SLHC environment, there is a need to adopt
the 130nm process. However, it has to be pointed out while such
processes offer some advantages over the 0.25 mm process, there are
other potential issues which have to be considered carefully.

In Figure 9, we show the cost of NRE and mask set for different CMOS
processes. It can be seen very clearly that the cost also follows the
Moore's law. This has of course severe implications for prototype and
even for small production runs.

![](media/image10.png){width="3.8895833333333334in"
height="2.3944444444444444in"}

Figure 9 Mask costs for different CMOS processes.

Another issue is the rise in power density. Processes with smaller
features sizes will need lower supply voltages. However, this translates
into large current and IR drop on the cables will become more of a
problem. Figure 10 shows the increase in power density as we go to
deeper submicron process.

![](media/image11.png){width="3.401388888888889in" height="2.03125in"}

Figure 10: Increase in power density of electronics over the years.

3.4 Areas of R&D

One of the goals of the CMS Pixel Detector Upgrade Workshop is to
develop an R&D plan for the Pixel Group that meets the goals of the CMS
collaboration and recognizes the interdependence between an upgraded
pixel detector, upgraded tracking detector, and the introduction of an
L1 tracking trigger for SLHC. In order to achieve these goals we must:

-   Work closely with CMS and the other working group to optimize the
    detector geometry

-   Develop a radiation hard technology for layers below 8 cm that
    minimizes charge trapping

-   At larger radii, financial constraints require the employment of
    more standard strip or pixel detectors. For radii between 10 cm and
    25 cm detectors with n-type silicon pixels on p-bulk substrates
    allow the collection of electrons rather than holes and good charge
    collection without full depletion. These detectors are potentially
    cheaper since they require single-sided processing but have not been
    traditionally used in particle physics experiments where most
    detectors have used p-strips on n-bulk. R&D is required to
    understand these novel detectors and to develop the necessary
    front-end electronics.

-   If stacking trigger layers are needed, development of radiation hard
    thin detectors is critical.

-   Development of 130 nm electronics.

    1.  **Sensor R&D**

To understand better the effect of radiation on sensor, we should work
on more detailed modeling of irradiated sensors. The Hamburg model has
been extensively used to determine the long term damage due to
radiation. According to this model the main effects of hadronic
irradiations are the removal of shallow impurities and the introduction
of deep levels that build up a negative space charge in the depleted
region leading to n-type material inversion to p-type. In this model the
uniform type inversion is parameterized as:

![](media/image12.pct)

where *N~eff,0~* is the initial charge carrier density, is the flux*, t*
the time and *T* the temperature. *N~C~* , *N~A~* and *N~Y~* describe
the stable damage, the annealing, and the anti-annealing respectively.

Experimental test beam data have shown that the Hamburg model does not
describe correctly the evolution of the depletion voltage for heavily
irradiated silicon sensors. Models with a doubly-peaked electric field
correctly predict the measured charge collection profiles measured in
heavily irradiated pixel sensor. It is clear that these models must be
used to describe the charge-sharing behavior and resolution functions of
irradiated detectors. Such effects must be implemented in the Monte
Carlo in order to fully evaluate tracking, vertexing, and triggering at
the SLHC

It is also interesting to compare the predictions of a modified Hamburg
model with the evaluation of the depletion voltage measured at CDF. The
detectors have been exposed to 2 fb^-1^ of data and the sensors closer
to the interaction region (L0) have not yet inverted. The data indicates
a weaker dependence of the depletion voltage on the fluence than the one
predicted by a semi-empirical Hamburg model which was developed to
estimate the lifetime of the CDF silicon. This could indicate a less
harsh radiation environment for the LHC and the SLHC.

We should also participate actively on sensor R&D. This is urgently
needed because as yet, there has not been identified a suitable sensor
technology for the inner layer at the SLHC.

**3.4.2 Front-end Electronics**

At this workshop, we have heard a variety of presentations reporting on
various promising and emerging technologies. In Table 6.1, we list some
of the items and issues that have been discussed and will be of interest
to the SLHC upgrade:

-   Pixel Technology

    -   Hybrid -- cheaper bump bonding

    -   Larger pixels or strixels for outer layers

    -   MAPS, SOI, 3D integration

-   Geometry

    -   Pixel size, thickness etc

    -   Module size and types of modules

    -   Layout of inner/outer pixels

-   Triggering layers (how many, location, size of pixel, type of
    modules, manufacturability)

-   Readout

    -   When to move to 130nm? Cost of prototyping? Radiation tolerance
        and single event effects?

    -   New architecture for pixel ROC

    -   New TBM

    -   Correlator chip for trigger needs

-   System issues such as power distribution, cooling, manufacturability
    of interconnects and hybrids, and system tests.

Since most of us will be busy with the construction and commissioning of
the current tracker until mid-2008 and that the production orders for
the Phase 1 upgrade have to be placed no later than the first half of
2010, there is not much time left at least for the Phase 1 R&D. We will
need as soon as possible a list of boundary conditions for the upgrades,
such as cabling, cooling, mechanical, and space constraints. Moreover,
we should develop an R&D plan which is focused and in-line with the
overall CMS upgrade effort. There should be no duplication of effort and
that we should not follow too many paths. From this menu, we should
identify areas in which the US groups have expertise and interest and
develop a well-thought out plan. To this end, we should give a lot of
thought on the system needs up front.

4.  Near-Term R&D Plan

For the immediate future we propose the following tasks:

-   Identify people interested in the sensor & ROC R&D in the US
    pixel/strip community and establish a unified working group with
    other CMS members already involved in the R&D for an upgraded pixel
    detector, tracker, and tracking trigger.

-   Have regular meetings in order to exchange ideas and setup R&D
    plans.

-   Since the trigger and geometry working groups have also been setup,
    there need to be a unified forum for these groups to actively
    interact.

-   Participate actively in the overall CMS Tracker upgrade effort. This
    means attending future CMS upgrade workshops, helping out on the EOI
    and LOI, and communicating with groups working on the Silicon
    Microstrip Tracker upgrade and be part of the overall CMS Tracker
    upgrade plan.

4 Report of Working Group 2 - Detector Geometry, Construction, and
Assembly

In this section we summarize the meetings of Working Group 2 at the
Pixel Group Preparatory Workshop on Future Upgrades, held October 9-12
at Fermilab. Here we present summaries of the presentations and
discussions in WG2, along with a few recommendations for subsequent
work.

The theme of WG2 was Detector Geometry, Construction, and Assembly. As
the range of possibilities for a replacement pixel detector is still
quite broad, the leaders of WG2 chose to focus on what has been learned
in the assembly of the current detector and what is available for
studying new designs. The presentations in WG2 were then focused around
the following general themes:

-   Overview of the current detectors

-   Lessons already learned in building the current detector

-   Software tools for evaluating detector designs

4.1 Pixel Detector and Assembly

4.1.1 Overview of current pixel detector

The current pixel detector consists of a barrel detector with three
layers spanning 4.3 to 11 cm in radius, and a forward detector with two
disks at each end in *z*. The two disks are at distances of 34.5 and
46.5 cm from the nominal interaction point. The barrel pixels are made
up of rectangular modules connected together to form a ladder. A full
ladder has eight modules, which each contain 16 Readout Chips (ROCs). In
the three layers of the barrel pixels there are a total of 672 modules
and 11528 ROCs. The forward pixel have a turbine geometry, with 24
blades in each disk. Each blade is rotated by 20*^o^* with respect to
the *z*-direction to promote charge sharing between pixels since they
are nominally perpendicular to the 4T magnetic field and have little
charge sharing due to the Lorentz drift. Each blade holds seven modules,
yielding of total of 672 plaquettes and 4320 ROCs in the FPIX.

The pixel size is common to both the barrel and forward detectors, 100 x
150 m^2^, yielding spatial resolution of 10-20 m. There are 48 million
pixels in the barrel sensors, and 18 million in the forward. Taken
together, the barrel and forward pixels produce three precision points
for tracking out to \| 2.25.

4.1.2 Description of FPIX modules

As described above, the forward pixels have a turbine geometry with 24
blades in each disk. Each blade is a multi-layered structure, with two
panels sandwiched around an aluminum cooling channel. Each blade is
double-sided with a panel on each side. The panels facing the
interaction region contain four plaquettes and the panels on the
backside of the blade contain three plaquettes shadowing the gaps in
coverage from the front side. The plaquettes hold the sensors,
bump-bonded to the ROCs, and a VHDI. Considering all the parts, each
blade is a 21-layer structure, including three layers of glue. A drawing
of a cross-section of a blade can be seen in Fig. 11.

![](media/image13.png){width="5.904861111111111in"
height="4.580555555555556in"}

Figure 11: Cross-section view of the 21-layer structure of the forward
pixel blades. Note that the two panels sandwiched around the cooling
channel have the same layer structure, though they will have different
numbers of modules/plaquettes.

For each of the components that make up one of the FPIX blades, there
are multiple types. This variety includes:

-   5 types of plaquettes

-   7 types of VHDIs

-   5 types of sensors

-   4 types of HDIs

-   4 types of panels

The variety of components means that the overlap of sensors on a blade
can be kept to a minimum (\~2.5%) and the use of space on the blade can
be optimized.

4.1.3 Assembly of FPIX modules

Because of the multi-layered structure of the FPIX modules, their
assembly is a multi-stage process. Initially, the HDI is laminated to a
beryllium substrate and several components are then soldered onto the
laminated HDI. Similarly, the VHDI is laminated to a 300 m silicon wafer
for mechanical support and the laminated VHDI is stuffed with several
capacitors. Sensors and ROCs are bump-bonded by an outside vendor, and
then the modules are attached to the VHDI first by adhesive and then
bump-bonded, to form the plaquettes. The plaquettes are then attached to
the panels with adhesive and the VHDI is bump-bonded to the HDI.

The multi-stage process of assembling the panels and blades means that
strict quality control is needed at every step, to assure that a problem
has not developed with one of the components before continuing with
further steps in the assembly. In addition, because of the wide variety
of components needed for each blade, planning of parts production is
crucial to maintain continuous panel production.

4.1.4 Material

The amount of material in the tracker is an important consideration. The
effect of the tracker material on track reconstruction will be discussed
in a later section. Here, we consider the amount of material that is
assumed to be present, based on engineering specifications.
Approximately half of the material budget comes from cooling, so the
components should be considered carefully. Completed panels are mounted
on opposite sides of a cooling channel, which is made from an aluminum
block, with a channel machined into the block such that two halves are
connected to form a the complete channel. Other extraneous material from
the original aluminum block is also machined away. Neighboring cooling
channels are connected by nipples. Three cooling channels together form
a cooling loop, and there are four cooling loops in each half-disk.

The total material budget for the tracker is shown in Fig. 12 \[[^5]\].
The plot on the left shows the number of radiation lengths, broken down
by the contribution of different components. The plot on the right shows
the same distribution, but now broken down by the sub-systems of the
tracker. Note that a large fraction of the material attributed to the
pixels around \|\|=2.0 is due to the services for the barrel pixels, and
does not come from any component of the forward pixels.

![](media/image14.png){width="3.8513888888888888in"
height="1.8770833333333334in"}

Figure 12: Preliminary study of the integrated material distribution of
the tracker as a function of . The left-hand plot shows the number of
radiation lengths separately for the contributions of different
components, including services. The plot on the right shows the number
of radiation lengths separated by the sub-detector of the tracker.

Figure 13 shows the material distribution over a forward pixel blade. A
single blade constitutes 2-13.5% of a radiation length, depending on
where a particle passes. The regions with the largest material are the
nipples that join cooling channels. For a particle passing at normal
incidence, a single plaquette contributes approximately 1.5% of a
radiation length and 0.4% of a nuclear interaction length. Two panels on
a disk, including cooling constitute an average of 4% of a radiation
length. It should be noted that these numbers seem lower than what would
be expected from the plots in Fig. 12. Approximately 10% of the material
is coming from the sensors alone, while \>40% comes from the cooling
(the fluid and aluminum support).

![](media/image15.png){width="2.652083333333333in"
height="2.734027777777778in"}

Figure 13: Number of radiation lengths for a particle crossing a forward
pixel blade at normal incidence. The effect of the cooling channels and
the nipples that join neighboring channels can be clearly seen.

4.2 Track Simulation and Reconstruction in CMSSW

CMS has in the past year adopted a new software framework, known as
CMSSW. This framework contains both simulation and reconstruction
packages. The path of generating, simulating, and reconstructing a Monte
Carlo event sample can be broken down into a few main steps:

1.  Event generation,

2.  Simulation of the passage of particles through the detector and
    creation of SimHits,

3.  Digitization, to simulate the electronics signals that are recorded
    by the detector, and

4.  Track Reconstruction.

4.2.1 Event Generation

Event generation is currently handled with either PYTHIA or a Particle
Gun which can generate single or multiple particles in flat
distributions throughout the detector. An important tool for
understanding the performance of tracking or vertex detectors is a
proper simulation of the beamline. Currently there is only a flat or
Gaussian smearing of the event vertex distribution. Tools are under
development to allow for a beamline that is displaced from the nominal
position and has a slope through the detector. In addition, there are
plans to implement the hourglass shape of the beamline in the
simulation. However, these do not yet exist so their performance can not
be evaluated. Simulation of multiple interactions is being implemented
in upcoming CMSSW releases and an initial version should be available on
the timescale of this report.

4.2.2 Simulation

Simulation of the particles passing through the detector is handled by
GEANT. Simulation of the pixels has been tuned to match the performance
observed in test beam data.

An important component in the simulation is the implementation of the
detector geometry. All components of the detector are implemented to
properly include the effects of detector material. The geometry is
written in Detector Description Language (DDL) in XML files. Both active
and passive elements are included, though the placement of the active
elements is most important. The positioning of these elements has been
verified with respect to engineering drawings. The implementation of the
material in the geometry is still being reviewed.

4.2.3 Digitization

During the digitization stage, there are simple attempts at modeling the
pixel detector inefficiencies due to radiation damage and data loss.
More sophisticated efficiency losses could be fairly easily implemented
to account for the non-uniform nature of the damage as a function of
distance from the interaction region.

4.2.4 Track Reconstruction

The algorithm most commonly used for track reconstruction is the
Combinatorial Track Finder (CTF). Here, tracks are reconstructed from
inside-out based on a pair of seed hits in the pixel detectors. All
pairs of hits are considered that pass cuts on and point back toward the
interaction region in *z*. The pixel seed is an initial trajectory which
is then extrapolated outward. At each layer, all hits within a window
based on the uncertainty on the trajectory and the possible material
scattering are considered. If the hits match with the trajectory, they
are added and the trajectory is updated. This process relies on the idea
of layer navigation, where the next layer to be reached by the
trajectory can be quickly located.

Since there are many possible configurations for a new detector, it
would be useful to have a framework where the detector geometry can be
easily modified and tracking performance re-evaluated. Unfortunately, as
it stands currently, this does not exist. Since the current geometry has
been implemented and can be simulated, the tools clearly exist to
simulate any configuration. However there are multiple pieces of code
that would have to be changed to implement a new framework.

The most obvious is the geometry XML files. It has taken the efforts of
several people to properly implement the current geometry. It would be
straightforward to modify the positions of existing elements, but
implementing new ones would be more challenging.

The next place where modification would be needed is likely in the
detector numbering scheme. The numbering scheme is used to assign a
unique 32 bit unsigned integer to each module, known as the DetId. The
DetId can be decomposed into several separate fields that are used to
identify for example +/-*z*, disk, blade, panel, etc. The number of bits
that have been assigned is based on the current number of modules. If
the number of elements were changed such that it exceeded the number of
bits currently specified, then the numbering would have to be re-worked,
with code modified elsewhere to adapt to the new numbering.

There is also the detector topology, which holds parameters such as
pixel size. These values are currently hard-coded and would have to be
modified if these parameters were changed in a new detector. Finally, it
is likely that the pattern recognition code might have to be changed as
well. There are assumptions in the track reconstruction code about the
sub-structures of the tracker. These would likely have to be adapted to
any new detector configuration.

4.2.4.1 Pixel Stubs

There is a new aspect of the pattern recognition algorithm currently
being implemented that uses the individual cluster shapes from the
barrel layers to estimate the track incidence angle in . Since this
angle can be extracted from a single layer, it can be used during
pattern recognition and could improve the combinatorics of track finding
greatly. It is also possible that this technique could be used during a
fast track finding phase of an upgraded L1 trigger since the cluster
shape points you to the cluster in the next layer. Estimates of the
resolution of this angle are shown in Figure 14. Any changes in pixel
geometry would affect this technique. In particular, it works best for
high segmentation (small pixels in the direction parallel to the beam)
and for thicker sensors.

![](media/image16.pct)

Figure 14: Method for extracting the track incidence angle (in ) from a
single cluster in the barrel pixel detector. The plot on the right shows
the resolution of this angle versus the cluster width. Changes to the
pixel geometry, including detector thickness, affect this method.

4.3 Effect of Material on Tracking

The material budget of the detector has important implications for
tracking. First, because the detector has several radiation lengths of
material, it has a significant effect on reconstruction of electrons and
photons. But there are also serious implications on the reconstruction
of hadrons. Figure 15 \[[^6]\] shows the reconstruction efficiency for
single pions with P~T~ = 1, 10, and 100 GeV/c, measured with Single
Particle Gun Monte Carlo in ORCA. The plot on the left shows the
algorithmic efficiency, which considers only those tracks which at the
simulation level had at least two hits in the pixels and eight total
hits. The plot on the right shows the global efficiency, considering all
simulated tracks. The difference between the left and right plots can be
seen as the effect of particles that interact and do not pass through
eight layers of the tracker. This can also be viewed as the overall
efficiency. Note that even for 100 GeV pions, there is a 20% loss of
efficiency in the regions with the most material.

![](media/image17.png){width="2.9270833333333335in"
height="2.803472222222222in"}![](media/image18.png){width="2.8680555555555554in"
height="2.7472222222222222in"}

Figure 15: Efficiency for reconstructing single pions with P~T~ = 1, 10,
and 100 GeV/c in the tracker. The left-hand plot shows the algorithmic
efficiency, where the denominator contains tracks with at least two
pixels hits and hits in at least eight tracker layers. The plot on the
right shows the overall efficiency, including the effect of tracks that
interact in the inner layers and do not reach the outside of the
tracker.

4.4 Considerations for Upgrades

4.4.1 Material and Cooling

As described above, the material in the tracker has a significant effect
on tracker performance. Any upgraded tracker should attempt to keep the
material budget down. In starting from the current design, the question
should be asked if all of the current components are necessary. The
cooling is a large contributor to the material, but a clear
specification of the cooling necessary is not available, and neither is
the current cooling capacity well-known. The current cooling was
designed with DMILL chips in mind, which consume four times more power,
and thus require more cooling.

There is a second effect that the material can have, which can act
counter to technological improvement in the detector. Even if the pitch
of the strips is decreased, if there is too much material then the
search windows for hits in pattern recognition will have to be increased
to compensate. As a result, though the strips are smaller, the
"effective granularity" would remain the same.

4.4.2 Ease of Assembly

The large variety of components has effects on module production that
have been discussed. While a reduction in variety can lead to an
increase in material, due to increasing overlaps, some reduction in
module variety could be achieved which could significantly streamline
production and assembly. This would especially be true if the size of
the pixel detector increased significantly to include parts of the
current TIB.

4.4.3 Physics

In the end, if the detector can not be used for doing physics, then it
is not very useful. If hits can\'t be found because there are too many
overlapping hits on a channel, then the performance of pattern
recognition will be significantly degraded. As there are already a
fairly small number of layers in the tracker (13 in the barrel region),
the loss of a single layer can cause a drop in efficiency. This can be
recovered of course, but at the cost of a higher fake rate.

For physics of the SLHC era, the highest priority will likely be to
retain the ability to correctly identify high P~T~ leptons. The second
priority will be to tag displaced vertices for use as both a tag and a
veto.

As a simple model for the SLHC environment, one can study the
performance for heavy ion events in the current detector. Figure 16
shows the % occupancy per channel in nominal heavy ion events as a
function of layer number for the current tracker.

![](media/image19.png){width="5.622916666666667in"
height="5.210416666666666in"}

Figure 16: % channel occupancy per layer for heavy ion events in the
current CMS tracker. The heavy ion environment is taken as a first
approximation to the occupancy that will seen in the SLHC era.

Note that there are significant discontinuities going from the pixels to
the TIB and from the TIB to the TOB. The highest occupancy is on the
innermost layer of the subdetector. Layer 4, the innermost layer of the
TIB, has an occupancy over 30% and would be nearly useless under such
conditions. Replacing this layer with either short strips or pixels
would dramatically improve the situation. This demonstrates the
importance of modeling the occupancy in simulating any new detector
configuration, and thus the importance of correctly modeling the
underlying event and pileup.

4.5 Conclusion

In the following discussions, we refer to the options available for
Phase 1 and Phase 2. The Phase 1 upgrade will occur after 4-5 years of
LHC operation. It is assumed that at this time, only the pixel detectors
will be replaced, and the geometry is essentially confined to the
current geometry. The Phase 2 upgrade will lead to the SLHC era and will
allow for a substantial redesign of the tracker, including the Tracker
Inner Barrel (TIB).

1.  Initial Tests

There are a few open questions that need to be answered to fully
benchmark the current detector.

1.  Verify the current material in the simulation. The amount of
    material in the simulation does not seem to match with accounting
    from engineering drawings. This should be understood.

2.  Measure the cooling capacity/performance of the current system. Is
    it over-designed for the current detector, such that no increase
    would be needed if moving to a system with higher power consumption.

4.5.2 Simple Upgrades for Phase 1

Any possible upgrade for Phase 1 is constrained by the likely re-use of
the existing cooling and support structure. As the innermost plaquettes
will receive a higher dose than the outermost plaquettes, the
possibility of replacing individual panels or plaquettes on panels
should be considered. This means understanding the technical feasibility
of replacing a single component, as well as the feasibility of
completing all replacements within the time allotted during a shutdown.

Another simple option for Phase 1 would be to leave the current disks in
place and install the third disk at each end. Tracks passing through the
inner plaquettes of the first and second disk would still pass through
the third disk. Hits on those inner disks might still be found, but any
lost hit would be recovered by the third disk. While this would increase
the amount of material in the forward region, it would not require
removing any of the old plaquettes or panels, and could easily fit into
the current space.

4.5.3 Development of Software Tools

As there are many different possible configurations, especially in Phase
2, it is important to develop tools that allow different designs to be
evaluated rapidly. Currently, going much beyond the scope of the current
detector would require significant work and would require learning by
many non-experts.

The first test should be to simply include the third forward disk, to
understand the effect on the rest of the simulation and reconstruction
chain of even such a small change. Once this has been accomplished then
a more radical change to the tracker geometry should be attempted. If
this is done carefully, and all required changes carefully documented,
then the completion of this task will enable others to more easily
change and test new designs. Since this will require a significant
amount of learning, and should not take away from the ongoing duties of
the experts, it would be best if a new post-doc or higher level
scientist is given this task.

4.5.4 Reduction of Detector Material

The effects of material in the tracker have been described above. As
they have significant effects on physics, steps should be taken to
reduce detector material. With 40-50% of the material coming from
cooling, possibilities for altering the cooling scheme should be
pursued. Can cooling channels be made from another material? How much
overhead is required in the cooling system? Can one try a bold design
where no cooling is used?

In addition, the multi-layered structure of the blades, as shown in Fig.
11, should be carefully checked. There are multiple supporting layers
and multiple epoxy layers. The layer-to-layer connections, whether epoxy
or bump-bonding, should be considered and optimized.

5 Report of Working Group 3 - Level 1 Tracking Triggers using the Pixel
Detector

5.1 Goal and Charge for Working Group 3

Working Group 3 was devoted to consideration of an L1 tracking trigger
using the pixel detector, and in particular the requirements placed on
the pixel detector design by any L1 tracking trigger. The main goals for
the workshop for Working Group 3 are listed here:

-   Begin developing requirements for Phase 1 and Phase 2 upgrades\
    (e.g. requirements for simulation software)

-   Identify technical challenges

-   Outline a program of R&D

-   Identify areas of expertise for US groups

-   Identify groups with strong interest in participation

Another goal that is not included in the list was to prepare members of
Working Group 3 so that they could participate effectively in future CMS
SLHC workshops.

Members of Working Group 3 are comprised of both members of the Pixel
Group and interested collaborators in CMS working on a variety of other
projects. This is both natural and desired, given the interdependence of
developing an upgraded pixel detector, upgraded tracking detector, and
the introduction of an L1 tracking trigger for SLHC. Included in this
report is our proposal for the next steps in the establishment of
requirements and proceeding with an R&D plan. One of these steps is to
join in with the existing CMS SLHC Group and start to participate in the
wider discussion within the Tracker Group and with the CMS SLHC Group.
This report therefore also serves to inform the Tracker and CMS SLHC
Groups of our interest in participating in the work for a CMS upgrade.

The outline of the report is given below:

-   Describe the SLHC upgrade and time scale, setting the context for
    this report.

-   Describe technical challenges for an L1 tracking trigger.

-   Describe what trigger studies have already been done for SLHC.

-   List what additional studies are needed for developing an L1
    tracking trigger.

-   Describe what tools are available, and what needs to be developed.
    This will form the basis for the "**requirements for simulations**".

-   Present **preliminary trigger requirements for Phase 1 and 2**.

-   Present a **plan for R&D**, including identifying groups with
    expertise and groups with interest in working on an L1 tracking
    trigger.

As described earlier in this document, a replacement pixel detector that
can survive and perform well through the end of Phase 1 of LHC operation
will likely be needed. Although little else of the detector will change,
this may present an opportunity to include components that would make it
possible to use pixel data in the CMS L1 trigger, or to demonstrate some
pieces of technology needed for Phase 2. After Phase 1, there will be a
long shutdown to upgrade the machine for 10^35^/cm^2^-s peak luminosity.
The Phase 2 running at higher luminosity will likely require us to
design a replacement pixel detector that can be used for an effective L1
tracking trigger.

5.2 Aspects of the LHC upgrade particularly relevant to the trigger

Some parameters of the SLHC accelerator upgrade are not yet decided, but
are undergoing active deliberation, discussion, and study. It seems that
the candidate values for bunch crossing intervals under discussion are
12.5 ns, 25 ns, and 75 ns.

Upgrades of the CMS detector for SLHC are also not yet decided and are
also undergoing consideration. Extensive R&D is needed before a decision
can be made. However, it is likely that part of the pixel detector will
be replaced during Phase 1 operation of the LHC, and for Phase 2, all of
the pixel detector and the inner part of the strip detector will be
replaced. This gives the physical volume for which upgrades can be made.

The effectiveness of any L1 tracking trigger is inextricably
interconnected with the upgrades of many other parts of the CMS
detector, including the pixel and strip tracking systems, the front-end
readouts and buffering, the L1 trigger components, and depends on the
amount of space available and the amount material in an upgraded CMS
detector. This means that it is not useful to consider any L1 tracking
trigger in isolation, and that the R&D must be closely coupled with R&D
involving other areas of CMS upgrades and LHC accelerator upgrades.

To make progress with consideration of requirements for a pixel upgrade
for a L1 tracking trigger, we have nevertheless attempted to clearly
state the challenges that must be met when considering the constraints
as outlined in the CMS SLHC draft EOI. These constraints come from cost
considerations in addition to the likely upgrade scenarios of the CMS
detector and the LHC accelerator.

The timescale for the R&D was taken to be that given in the CMS SLHC
draft EOI and given in Fig. 1 above. A summary of the proposed roadmap
from the perspective of trigger upgrades is given below \[Error:
Reference source not found\].

**Within 5 years of LHC start**

-   New layers within the volume of the current pixel tracker which
    incorporate some tracking information for an L1 trigger

    -   Room within the current envelope for additional layers

    -   Possibly replace existing layers

-   "Pathfinder" for full tracking trigger

    -   Proof of principle, prototype for larger system

-   Elements of a new L1 trigger

    -   Utilize the new tracking information

    -   Correlation between systems

**Upgrade to full new tracker system by SLHC (8-10 years from LHC
Startup)**

-   Includes full upgrade to trigger system

5.3 Technical Challenges for the L1 Trigger

The work presented at the four CMS SLHC workshops and presented in the
CMS SLHC EOI shows that CMS must meet a significant number of
challenges. One of these is to upgrade the L1 trigger to handle the
increased luminosity. This is often illustrated by the single muon rates
for various L1 and HLT selections as shown in Fig. 17 for a luminosity
of 10^34^cm^-2^s^-1^, taken from the DAQ TDR which also appears in the
CMS SLHC draft EOI \[[^7]\]. It can be seen that a p~T~ threshold of
about 20 GeV/c is required to keep the rate below 10 KHz, which is 10%
of the maximum L1 rate. Even with a linear extrapolation to 10^35^
cm^-2^s^-1^, too high of a p~T~ threshold would be required to obtain a
reasonable rate. Moreover the curve flattens out, which means that one
requires large increases in the p~T~ threshold to make small reductions
in the rate. Effectively the L1 trigger would likely be "broken" at the
SLHC.

This motivates the use of tracking information in the SLHC L1 trigger.
It appears that tracking information is required at L1 to reduce the L1
rates to acceptable levels. For example the data shown in Fig. 17 show
that a reasonable L1 rate is achievable by requiring the presence of a
spatially matched track for a high-p~T~ lepton and use of the track
momentum measurement to sharpen the lepton p~T~ threshold. However, even
this minimal requirement introduces significant technological
challenges.

It should be pointed out that the data in Fig. 17 uses offline track
information to sharpen the muon p~T~ threshold since the tracking system
has ten times the p~T~ resolution of the muon system. Detailed studies
are still needed using a realistic L1 tracking algorithm to check the
performance at L1. Also, as was discussed during the workshop, it was
not clear that simply requiring a matching track stub/jet and sharpening
the p~T~ threshold is enough for certain trigger channels, for example
tau-jets \[[^8]\], more work on this is required.

![](media/image20.jpeg){width="4.090277777777778in"
height="3.845138888888889in"}

Figure 17: HLT single-muon trigger rates as a function of the p~T~
threshold for a luminosity of 10^34^ cm^-2^s^-1^. The rates are shown
for L1, L2, and L3, with and without isolation for L2 and L3 (HLT). The
rate generated in the simulation is also shown. At L2, using information
available at the HLT, a muon must be reconstructed in the muon system
and have an valid extrapolation to the collision vertex. At L3 a muon
must have more than 5 silicon hits in total in the pixel and strip
tracking system \[Error: Reference source not found\].

To provide trigger primitives in the CMS L1 trigger system will require
a replacement of at least part of the tracking system and possibly a
change in detector technology. Also, to find track stubs requires some
association of data between different layers. This in turn requires
readout of a fraction of the data off-detector, thereby introducing
complications of cabling, power, and additional material in the tracking
detector. The data rate for the barrel pixel has been estimated to be
about 10 Gbit/cm^2^/s, some reduction of the data to be readout would
probably be required either on-chip or on-detector. One suggestion of
how this could be achieved is via closely stacked sensors to create hit
doublets before the off-detector readout. Another possibility is to
implement specialized trigger readout for groups of pixels. A
significant challenge is to keep the amount of material to a minimum,
since the introduction of any additional detector layers or other
material is a serious concern.

The maximum L1 rate and the maximum L1 latency are related, but
separate, issues. Given the discussions in the working group, it should
be pointed out that the maximum L1 rate is related to the readout time
of the front-ends after a L1 accept, while the L1 latency is related to
the maximum buffer depth of the detector front-ends.

The proposed increase of the L1 latency given in the CMS SLHC draft EOI
is 6.4 s, a doubling of the current 3.2 s latency. An additional
increase of the L1 latency is limited by cost. The L1 latency is limited
by the front-end analog storage capacity of the tracker and preshower
electronics, but these should to be replaced for SLHC running. Assuming
that they are replaced, then the next limitation is the ECAL digital
memory depth of 256 40MHz samples corresponding to 6.4 s. Running at 13
MHz (75 ns bunch crossing interval) will not increase the latency since
the ECAL has a fixed 40 MHz sampling. The ECAL front-end buffer is
located on electronics attached to the back of a crystal and its
replacement is not envisioned. The CMS SLHC L1 latency baseline is
proposed to be 6.4 s in the CMS SLHC draft EOI. This short L1 latency
for accessing the trigger primitives, for track stub reconstruction, and
for track stub association for track pattern recognition presents a
serious challenge.

It is proposed in the CMS SLHC draft EOI to hold the L1 rate to 100 KHz
to avoid rebuilding much of the front-end and readout electronics as
much as possible. These were designed for an average readout time of
less than 10 s. Therefore, for the readout after an L1 accept, the
maximum L1 accept rate should be 100 KHz. This limits any hardware level
trigger that might sit between L1 and the HLT, like that proposed for
ATLAS, at SLHC or used at CDF. Although such an intermediate hardware
trigger could further reduce the rate of triggers going to the HLT, its
use would be limited if the L1 rate could not be increased to take
advantage of this. All it could provide is a redistribution of the same
L1 rate between different physics triggers, as is the case for ATLAS.

Besides the challenge of developing an L1 trigger that is intertwined
with the development of detectors, the DAQ, the cable plant and power
considerations; an L1 tracking trigger also depends on changes
introduced by upgrades of the LHC, for example, the beam crossing
interval. Operation at a beam crossing rate of 80 MHz would require a
rebuilding of trigger primitive calculations, and the CMS trigger
system, and presents the challenge of possibly reading and reseting the
pixel sensor every 12.5 ns.

The time scale itself is a challenge given the interdependency with the
tracker system, and integration with other CMS components. The
effectiveness of any L1 tracking trigger could be very dependent on the
sensor technology and detector geometry, e.g. using pixels *vs.* short
strips, using very small or large pixel sizes, using thick *vs.* thin
sensors, using stacked layers *vs.* well separated layers. These may
also govern what fraction of the tracking data can actually be used at
the L1 stage. Depending on the exact trigger strategy or algorithm, the
radiation damage of a detector can also be an important consideration.
For example, radiation damage can affect the charge sharing in thick
sensors.

A summary of the challenges for designing a pixel detector for use in an
SLHC (Phase 2) L1 tracking trigger is given below.

-   Keeping the data rate needed for L1 trigger primitives small enough
    to be brought off-detector for association of data between layers.

-   Doing enough processing to have an effective L1 tracking trigger,
    but still staying within the L1 latency of 6.4 s.

-   Keeping up with reading and resetting pixels at a high beam crossing
    rate.

-   Keeping within the material and power budget.

-   Performing sufficiently detailed studies of enough trigger
    strategies soon enough to influence the new tracking system.

-   Managing the significant interplay of the tracking trigger with
    design choices of the tracking system and other relevant CMS
    systems.

-   Getting sufficient performance of an L1 tracking trigger given the
    constraints of the tracking system design, and the constraints
    imposed by other parts of CMS.

-   Getting enough resources to produce a tracking trigger "technology
    demonstrator" for Phase 1.

Although the current CMS L1 trigger would be effectively "broken" at the
SLHC (Phase 2), we believe it would not be broken in Phase 1. However,
any replacement of some part of the tracking system for Phase 1, or the
addition of new layers or disks gives us an opportunity to install a
tracking trigger "technology demonstrator" for Phase 2 -- either a proof
of principle or a prototype for a larger system.

5.4 Status of Studies for an L1 Tracking Trigger

5.4.1 Stacked Trigger

A promising L1 tracking trigger strategy has been proposed for SLHC
called "Stacked Triggers". The main idea is to use stacks of closely
spaced sensors (SoI-MAPS) to quickly find mini-vectors to reduce by more
than a factor of 10-100 the data that needs to be readout off-detector.
This reduces power and cabling. Furthermore, with an appropriate choice
of the separation between the stacked layers and pixel sizes,
reconstructed mini-vectors would have to meet suitable minimum p~T~
requirements. This would be done using either one stacked barrel layer,
or two sets of stacked layers. Two sets of stacked layers would be
needed to infer the track p~T~.

The idea of Stacked Triggers is illustrated in Fig. 18. Two closely
separated layers of small pixels are used to find mini-vectors. These
mini-vectors are defined by matching single hit pixels from the two
layers, e.g. in zero or one pixel in phi (in the figure the match shown
is for zero pixel in x). The choice of this matching "road" together
with the pixel size and the layer separation determine the p~T~ cut and
p~T~ threshold turn-on resolution, as well as the level of background
rejection and thus data reduction. Two stacked layers are needed to
infer the p~T~ of tracks. Use is also made of the z-location of hits.
Further details on this the Stacked Trigger can be found elsewhere
\[[^9]\].

Although the proposed Stacked Trigger is a promising idea, from the work
presented at the workshop it appears that a lot of additional work would
have to be done to show that the idea can really work in a real detector
under real conditions, and also be able to pass any external review.

![](media/image21.jpeg){width="4.9847222222222225in"
height="3.377083333333333in"}

Figure 18. Illustration of the idea of Stacked Triggers.

The design of the Stacked Trigger scheme places strict requirements on
mechanical aspects of the design. The pixel size needs to be small for
this scheme to work. Various sizes have been considered such as 20 m by
200 m pixels, or 50 m by 50 m pixels. The sensor thickness must also be
thin, on the order of 50 m. These considerations constrain the type of
sensor technology that must be used, and has implications for the
alignment of the pixel system. The need for closely stacked layers is
probably not ideal for offline track reconstruction, so this is not the
most efficient use of the space available. Another major issue is that
the studies that have been performed were done with a simple standalone
Monte Carlo that omits many important effects that need to be simulated
to properly evaluate the Stacked Trigger idea. Some of the things
missing in the simulation include: Multiple Coulomb Scattering, and
including all of the material in the simulation between the IP and each
tracking layer; delta ray generation; charged sharing in a magnetic
field; smearing of the beam spot; misalignment and miscalibration of the
pixels; Poisson distributed pileup (with tails instead of a fixed number
of pileup collisions); noise in the detectors; non-Gaussian tails; and
realistic geometry (e.g. flat sensors instead of cylindrical ones and
possibly overlaps with offsets in "r"). Fortunately all these effects
can easily be included if use is made of the standard CMS simulation for
further studies. These additional studies need to be done to demonstrate
that the Stacked Trigger can work.

5.4.2 Other Initiatives

Other L1 tracking ideas have been presented at CMS SLHC workshops. One
such idea from the Pisa group, but not presented at this workshop, is to
use a more traditional regional track finding strategy similar to that
used by CDF, for example, but using only the pixel hits \[[^10]\]. Track
finding is done in phi sectors and only in certain regions, using the z
information and beam spot size. The simulations were done assuming full
offline information for the pixels. The idea is based on the standard
CMS L1 trigger philosophy of migrating HLT algorithms to L1 where
possible. Although the simulations are more realistic in that the usual
details are included, this trigger idea is less advanced than that of
the Stacked Triggers, in the sense that little attention has been paid
to solving the challenge of getting the full data off the pixel detector
for processing at L1. One option proposed is to implement this trigger
not at L1 but between L1 and the HLT, as is proposed for ATLAS (see
below).

5.5 Further Tracking Trigger Ideas Presented Beyond that described in
the CMS LHC Draft EOI

Other ideas for tracking triggers based on geometries different from
stacked layers were presented, like a fast tiny triplet finder based on
BTeV experience, or pattern recognition in sectors as is done in CDF and
proposed for ATLAS. Ideas for a pre-trigger that could be done after 3.2
s and before 6.4 s were presented and discussed during the workshop
\[[^11]\]. Also presented was the idea behind a proposal for ATLAS, and
used in CDF, where a copy of the data after an L1 accept is obtained to
perform a hardware-based L1.5 trigger that could redistribute the L1 100
KHz rate among different physics triggers. This would allow lowering of
some thresholds at L1 for ATLAS for some L1 triggers while raising other
L1 thresholds \[[^12]\]. A similar idea, using constraint-based regional
tracking in sectors with the full granularity for CMS, but at L1, was
presented by members of the Pisa group in a past CMS SLHC workshop
\[Error: Reference source not found\]. Another idea presented is the
scheme used by the D0 L1 tracking trigger, where the trigger is divided
into many radial sectors. For each radial sector, pre-computed track
patterns for a few momentum ranges, taking into account the beam spot
location and its size, are stored in FPGAs. The tracks hits in the event
are compared to the preloaded track patterns to generate a L1 trigger
for a given momentum bin within the sector.

Some of the ideas presented from offline reconstruction, like the
reconstruction of mini-pixel vectors, might be of use as part of a set
of L1 trigger primitives. These mini-pixel vectors are reconstructed
using the pixel cluster shapes together with knowledge of the pixel
charge sharing shapes. These mini-pixel vectors have shown to be useful
for offline in reducing the pattern recognition load and may be
interesting to investigate for an online trigger \[[^13]\].

As mentioned previously, the inner layers of the silicon strip tracker
may be replaced by pixel layers. However, one should consider not only
the pixel detectors while developing the L1 tracking trigger, the use of
some the silicon strip tracker hits together with the pixel hits should
also be explored. It should be noted that just because some ideas, or
the use of some information were not included here does not mean we are
ruling out any particular options. We intend to be as inclusive as
reasonably possible while making sure we also stay focused on our
primary goal of making a L1 trigger that will work for CMS running at
the SLHC.

5.5.1 Trigger Signals on the Existing BPix and FPix Hardware

Only tracking strategies based on the barrel pixel have so far been
studied. Ideas for using the forward pixel data in an L1 trigger still
need to be studied. There has been no work on what L1 tracking trigger
algorithm one could develop by using "existing" ROC barrel pixel trigger
signals, or how well such an algorithm would work in SLHC. The
availability of trigger primitives from the pixel detector is also an
issue.

The pixel readout chip (ROC) includes a differential trigger primitive
output \[[^14]\]. The normal data for each sensor read out by a ROC
consists of data for 52 columns (size 150 m) and 80 rows (size 100 m).
The trigger primitives consist of double columns, and two thresholds can
be used to configure these primitives: The first threshold is the number
of pixels that must be hit in a double column for the double column to
be considered "hit"; the second threshold is the number of double
columns that must be "hit" for the ROC to output a trigger signal. The
trigger signal is an analog output with the number of hit double columns
encoded in it. This could be used for a multiplicity or jet trigger, but
a segmentation of the size of one sensor/ROC maybe too coarse for
effective track pattern recognition or even matching to a high p~T~
lepton. This should be studied before upgrades of the pixel system for
Phase 1 running is finalized.

Another issue with using the trigger primitives is the availability of
the output. For the barrel pixel the HDI routes the 16 differential
trigger signals from the 16 ROCs to a central MTC (Module Trigger Chip).
This chip has been designed in a 0^th^ version but has never been
tested. It is currently not mounted, but besides acting as a signal
concentrator, it could be used to do processing of the trigger data from
the 16 ROCs. The output signals of the MTC would still need to be
finalized and produced, but existing traces on the HDI can route these
signals to the module signal cable (21 traces in total) and end up in
ZIF plugs at the endflange that is currently under design. That's where
the signals end and nothing has been implemented to bring the signals
onto the supply tube and to extra optical links (which do not exist
either). The availability of the ROC trigger signals is worse for the
forward pixel system. The trigger signals in the FPIX ROC end in the HDI
for each panel. There is no provision for a MT chip, or traces to bring
the output to the edge of the HDI, and of course no cables are available
to bring the signals off the detector either as in the case of the BPIX.
It is unlikely that one could get the trigger signals off the FPIX
detector without rebuilding the FPIX panels \[[^15]\].

5.5.2 Existing Software Tools

It seems obvious that a significant simulation effort is needed. We
describe the existing tools in CMS that could be used for the studies
required to evaluate and demonstrate the effectiveness of any L1
tracking trigger strategy or algorithm. As far as possible if the
existing CMS software tools can be used for our studies, or could be
used with a relatively small effort, it is preferable to do this and
thereby contribute to the main CMS tools rather than spend time
developing external ones.

A fully functioning simulation of the CMS detector based on Geant4 is
available in CMSSW_1_1_0, including pileup. Reconstruction of tracks and
high-level objects are also available in this version of CMSSW.
Currently the only general purpose generator available is Pythia, though
other more specialized generators like MadGraph, CompHEP, TopRex,
StaGen, Charybdis, or a particle gun are also available. The interaction
point can be smeared by a Gaussian distribution using the official code,
but additional user code is needed to simulate a crossing angle or an
hour-glass effect. These features should be straightforward to
implement.

The geometry for the tracking system, like the rest of the CMS detector
in the simulation is complete. Some work is ongoing to update the
materials for the forward pixels but this need not interfere with any
studies needed for SLHC. The geometry is fairly modular, and structured
in a hierarchical fashion, where each part is specified by an XML file.
Changing the geometry requires understanding the detector description
language (DDL) used in these XML files. Moving existing pixel components
around, like layers, disks, plaquettes or panels are fairly easy to do,
and the simulation need not be changed except for a piece of code that
maps sensor positions with detector IDs (the numbering scheme). Changing
the pixel size and sensor thickness is also very straightforward, as
only the digitizer needs to be configured to handle these changes
through a configuration file. For more radical geometry changes one has
to learn DDL and created new Geant4 volumes. This takes some learning
but again, for simple geometric shapes this is not so difficult and we
have expertise in the forward pixel group. For SLHC studies, we would
include all the necessary material, but would initially try to use
simple geometric shapes when defining volumes. Also for new volumes we
would not initially include some of the complexities we have in the
standard FPIX geometry, like individual nipples on each blade, but just
average out the material in some simple geometric shapes. We will call
these simpler detector layouts, "toy geometries". These toy geometries
will have fewer components and simpler shapes but they should be
suitable for fast comparisons of different possible geometries. Once the
XML files are created for one such toy geometry it should be possible
for other non-DDL experts to modify it to study variations of particular
toy geometries.

The only tool for checking and testing the geometry is Iguana, which is
a version of the standard CMSSW executable that is used for Geant4
visualization. One can use this to check the geometry visually, except
for Boolean solids, which seem to have a flaw in the implementation. The
only way to really test if the geometry is correctly simulated in the
Monte Carlo is to manually run a simulation and check the output. This
is probably

For the pixels, the simulation provides "simhits". These are space
points in local (sensor) coordinates for entry and exit locations in the
sensor, and include the energy deposited. Note that at the simulation
(Geant4) stage the whole sensor is simulated as a single volume.
Individual pixels are not simulated at this level. Separate digitizer
code is used to convert these simhits to get "digis" which give pixel
hits in local coordinates and the charge deposited in ADC counts. The
charge sharing code accounts for the magnetic field and calibrations.
Knowledge of the global geometry is necessary at this point to get the
correct magnetic field for charge sharing. A further routine is used to
make "rechits" which are clusters of pixels, also in local coordinates.
Only at the track reconstruction stage are the rechits relocated in
global coordinates. This means that it would be easy to change the
geometry without needing to change the digitizer or rechit generator
code.

Though not part of the official CMSSW reconstruction code, there is a
"PixelNtuplizer" that takes the simhits and uses the official CMSSW
digitizer and rechit code to produce a file of rechits located in local
coordinates. This file of rechits, if trabslated to global coordinates
would be extremely useful for people who want to just try out pattern
recognition and tracking algorithms in their own "sand-box", and thus
reduce the overhead for new people to get involved in investigating
pattern recognition and tracking algorithms. However, to understand
reconstructable events one would need some way of doing the tracking and
analysis with this rechits output file. A prompted tracking program may
be sufficient instead of full track pattern recognition for comparisons
of different trigger algorithms. Comparisons would be based on
efficiencies for particular physics signals *vs.* rejection of min-bias
events.

The Iguana visualization seems to be very difficult to use for
visualizing hits and tracks to study pattern recognition problems. This
is because of reported instability issues, and the absence of a feature
that lets a user save settings in a configuration file. If the
PixleNtuplizer was used to create an external rechits collection in
global coordinates, one could easily visualize the hits in some other
way. A rechits and track visualizer would be useful for debugging and
studying what is going on when pattern recognition problems arise.

Besides the full simulation, CMS also has a fast simulation, FAMOS,
however this is not yet completely ported to CMSSW, the new CMS
framework. We propose that in future simulations we use CMSSW rather
than the old framework. We have to investigate the ease of use of FAMOS
for the various simulations studies that are needed.

Enough simulation samples will need to be generated. CMS already has a
mechanism for simulation sample production, and we should just try to
use this for generating enough samples for SLHC studies.

5.6 Requirements for L1 Trigger Studies

Detailed simulation is the key for developing an upgraded pixel detector
and L1 tracking trigger for SLHC that achieves the physics objectives of
CMS. Geometry and detector simulations are needed, as are analysis tools
to study both trigger performance and the impact of a tracking trigger
on physics analyses. Optional tools such as visualization software can
be useful in the development of an L1 tracking trigger.

Ideally the development of an L1 tracking trigger should involve the
**evaluation of several different trigger algorithms**. These algorithms
should be evaluated by studying rejection of minimum bias events with
the level of pileup that is anticipated for SLHC in different operating
scenarios, and should demonstrate acceptable trigger performance by
calculating signal efficiencies for specific final states that are
considered crucial for CMS physics.

At least two approaches are possible to perform simulations for trigger
studies. One approach is to take advantage of the machinery that is
under development for CMS physics analyses including CMS event
generators, GEANT simulation of the CMS geometry, detailed detector
simulations that include all material in detector subsystems, and the
CMSSW analysis and visualization environment. A second approach is to
use a fast parameterized simulation and analysis environment that
permits quick changes to detector geometries without having to recode
analysis software. Using a fast, parameterized simulation has the
advantage that pixel and tracking detector designs that differ
significantly from the current CMS detector can be evaluated easily, but
this approach suffers from the lack of detail that is available in
currently existing CMS simulations, reconstruction and analysis
software. One of the conclusions from the CMS Pixel Detector Upgrade
Workshop is that many (if not most) of the tools needed for pixel
detector and trigger simulations are available today. Ease of use of
existing tools and development of additional tools will require further
evaluation.

Trigger studies should take advantage of the complete geometry of CMS
wherever possible. This is referred to as the **reference geometry** for
the purpose of comparisons to other geometries. In some cases a
simplified geometry may need to be implemented when details of a
proposed pixel detector design are not available.

The following capabilities are required to perform the simulations and
studies that will be needed to develop, design, and validate an L1
tracking trigger for SLHC.

5.6.1 Geometry Studies

Development of a new pixel detector for SLHC, optimization of a proposed
geometry, and the evaluation of different trigger algorithms will
require changes to the existing CMS geometry. These geometry changes are
expected to include the following: introduction (or removal) of pixel or
tracking detector layers (for example, the introduction of a "stacked"
pixel layer for triggering), simplified geometries to evaluate new types
of pixel detector technologies, introduction (or removal) of material
associated with support structures, cabling, cooling and power.

A flexible geometry specification that is relatively easy to manipulate
is required. The CMS Detector Description Language (DDL) implemented
with XML appears to be adequate in that it allows very complex
geometries and implementation of simplified geometries. Replication of
detector subsystems is accomplished through the use of "algorithms."
Visualization and verification of the implementation of a specific
detector geometry is accomplished by using Iguana.

5.6.2 Detector Studies

Trigger studies will require the evaluation of many details of proposed
pixel detectors. These include pixel size, sensor size, configuration of
sensors in modules, and overlap schemes to name a few. Optimizing the
design of an upgraded pixel detector within the context of an L1
tracking trigger will depend on simulations that demonstrate detector
and trigger performance.

5.6.3 Pixel Detector Simulations

Detailed pixel detector and readout-chip simulations are crucial in the
design of an L1 tracking trigger that depends on pixel data. Simulations
of charge collection and charge sharing for adjacent pixels including
effects from low-energy delta rays are important when one considers the
trigger response in a high-rate environment such as CMS. These
simulations should also provide input to simulations of pixel
readout-chip designs to study data rates out of the chip and into the L1
trigger hardware.

5.6.4 Studies of Different Accelerator Operating Scenarios

A complete set of simulations needs to be performed to study the
performance of pixel detector designs and trigger algorithms for
different accelerator operating scenarios and varying beam conditions.
Of primary importance is the LHC bunch crossing time, proposed values
range from as low as 12.5 ns to as high as 75 ns in different scenarios.
Studies will need to be performed for proposed changes to the luminous
region of the IR, and changes in beam position over time. While certain
proposed scenarios are likely to be unrealistic, one should expect
requests for studies of detector and trigger performance for different
operating conditions.

5.6.5 Trigger Performance Studies

Each L1 tracking trigger algorithm that is proposed for SLHC will need
to satisfy studies of trigger performance. Algorithms will need to be
tested with regard to rejection of minimum bias interactions with
varying degrees of pileup anticipated for SLHC, and must demonstrate
required trigger performance for specific final states considered that
are representative of crucial measurements for CMS physics. Trigger
algorithms must also be evaluated with realistic detector efficiencies,
and trigger performance must be determined in an environment with noise
levels that exceed design specifications.

5.6.6 Simulation and Analysis Tools

A number of simulation and analysis tools will be needed to study
proposed L1 tracking trigger algorithms, develop a baseline design for a
tracking trigger, and evaluate performance characteristics. The ability
to generate many different signal and background data sets for different
accelerator operating conditions, different detector geometries, and
different types of pixel detector designs is important. Some of the
capabilities that will be needed are the following:

-   rudimentary event display to explore and develop new trigger
    algorithms

-   visualization software to verify implementation of detector
    geometries

-   ability to write files with pixel hits in global coordinates

-   ability to write files with silicon strip tracker hits in global
    coordinates

-   match trigger primitives and reconstructed tracks with MC tracks

-   modify beam conditions in the simulation code

-   ability to implement different models for charge sharing in pixels

-   ability to implement different levels of noise in the pixel system

An important aspect of the simulations needed to develop a CMS tracking
trigger for SLHC will be the use of **common simulation and analysis
tools**. This will be important when comparing results obtained for
different detector designs and different trigger algorithms.

5.7 Proposed R&D Plan for an L1 Tracking Trigger Using the Pixel
Detector

One of the goals of the CMS Pixel Detector Upgrade Workshop is to
develop an R&D plan for the Pixel Group that can be aligned with R&D
efforts in other groups. An important aspect of the overall R&D plan is
that it should acknowledge the interdependence of developing an upgraded
pixel detector, upgraded tracking detector, and the introduction of an
L1 tracking trigger for SLHC.

We present a proposed R&D plan for the Pixel Group to contribute to the
CMS SLHC effort. This R&D plan is given to provide a basis for
discussion and to help with the planning process. This plan is based on
experience obtained from ten years of R&D devoted to the development of
a pixel-based Level-1 tracking trigger for the BTeV experiment. After an
initial period of three to six months devoted to help establish a pixel
group to work on SLHC upgrades, the plan identifies three high level
activities: "Algorithms and Simulations," "Trigger Design," and "Trigger
Prototyping." Assigning these particular names to the high-level
activities should not suggest that these would be the only activities
that would occur during a particular period. Instead, the name of the
high-level activity suggests the primary focus during that period in
time. For example, during the two-year "Algorithms and Simulations"
phase the emphasis would be on developing a baseline algorithm that
satisfies the requirements of an L1 tracking trigger. Efforts geared
towards exploring possible trigger designs and initial efforts in
prototyping hardware are likely to occur during this period as well.
However, the primary focus would be on developing the algorithms and
simulations that would lead to a baseline algorithm that meets CMS SLHC
requirements.

5.7.1 Help Establish a Pixel Group for the SLHC (3-6 months)

Help establish a Pixel group that will work on developing and
contributing to the CMS SLHC L1 tracking trigger:

-   Identify new and existing group members to help form a unified
    working group

-   Identify specific physics analyses to make the physics case for a
    tracking trigger

-   Collaborate with CMS tracking, trigger, and DAQ SLHC groups to help
    establish (joint) requirements

-   Contribute to SLHC Expression of Interest (EOI) and SLHC workshops

-   Evaluate suitability of CMS simulation software for trigger studies

-   Edentify tools that will be needed, and begin development of those
    tools

5.7.2 Algorithms and Simulations (2 years)

Develop and evaluate L1 trigger algorithms using the BPIX and FPIX
together with the other CMS SLHC groups and perform simulations. This
phase corresponds to the "Monte Carlo" phase for the "Full Tracker" in
the CMS SLHC Expression of Interest (EOI).

-   Perform studies and simulations outlined above

-   Refine simulations as CMS data becomes available

-   Evaluate different trigger algorithms

-   Select a baseline trigger algorithm (**milestone**)

5.7.3 Trigger Design (2 years)

Participate in the development of the baseline L1 trigger using the BPIX
and FPIX in collaboration with other CMS SLHC groups. This phase
corresponds to the "Concept" phase for the "Full Tracker" in the CMS
SLHC Expression of Interest (EOI).

-   Develop hardware design to implement the baseline L1 trigger

-   Update L1 trigger algorithm as detector design develops

-   Use CMS data to refine the trigger design

5.7.4 Trigger Prototyping (2 years)

Develop trigger prototype hardware and implement hardware for a Phase 1
"technology demonstrator" if possible. This phase is not explicitly
mentioned in the CMS SLHC Expression of Interest (EOI).

5.8 Summary and Future

We had very productive working group sessions in this workshop,
discussing the possibility and design of a L1 tracking trigger using an
upgraded pixel detector. We made progress on outlining what we need to
work on in the near future and made a first attempt at defining some
requirements and a longer term R&D plan. We hope to continue this
momentum after the workshop. Many people have expressed an interest in
participating in the work needed to develop an L1 tracking trigger.
These people are listed as authors of this report.

For the immediate future we propose the following tasks:

-   Identify new group members and help establish a unified working
    group with those CMS SLHC members already involved in the R&D for an
    upgraded pixel detector or tracking trigger.

-   Setup a "toy geometry" for a CMSSW simulation with a Stacked Trigger
    layer added to the standard CMS geometry to enable more realistic
    simulations of the Stacked Trigger idea.

-   Perform more realistic simulations to evaluate the performance of
    currently proposed L1 tracking trigger schemes.

-   Setup a "toy geometry" that uses less complex geometrical shapes for
    detector volumes within the pixel and inner strip tracker volume.
    This geometry file should be documented to a level where a non-DDL
    expert can easy modify simple parts of the geometry, and would be
    the basis for non-experts to do various simulation studies.

-   Help develop tools that will enable someone to work on hit and track
    pattern recognition without the overhead of having to learn the
    whole suite of CMS software, or having to deal with problems that
    might arise with frequent changes to the CMS software version.
    Initially develop code to the output the collection of rechits from
    both the pixel and strip tracker systems in global coordinates.

-   Investigate the status of FAMOS, and the ease and suitability of its
    use for the simulation studies needed.

-   Identify people to work on the different tasks and help them make
    progress.

Following the Roadmap given in the draft EOI, we should participate in
the CMS SLHC workshops, and in particular, join the "Pixel system and
triggering working group" that will soon be formed as part of the CMS
SLHC effort \[[^16]\].

It is important that we stay focused on the main goal of showing that we
can get the required performance for a L1 trigger at the SLHC for high
p~T~ physics, and other physics that might be important during SLHC
running. This will require the use of present software tools for doing
the more detailed studies that are needed to ensure that any proposed
tracking trigger will work at the SLHC. We should also improve the
tools, when needed, or develop new tools, if required. There are people
who are interested in contributing to this main goal. These software
tools can in turn be used for studies of other tracking trigger
strategies for high p~T~ physics or even optimizing the triggering of
other physics that people are interested in.

Although the primary purpose of this working group was to set
requirements for the pixel detector that can be used in an effective L1
tracking trigger, as noted by everyone throughout this workshop, the
design of all the different components: pixel detectors, readout,
trigger, DAQ, construction and assembly, are all inextricably linked.
Progress must be made in the R&D for a L1 tracking trigger in parallel
with the design of the pixel detector. For the moment we believe we can
provide very little guidance to pixel-detector designers on a specific
implementation for a pixel tracking system. We should revisit this in a
time frame of 6 months to one year.

**Appendix 1: Agenda of Talks**

**Monday October 9:**

15:00-17:00 Working Group 3 Kick off talk on SLHC Trigger and DAQ Wesley
Smith (Univ of Wisconsin)

**Tuesday October 10:**

9:00- 13:00 Plenary Session

09:00-09:45 SLHC Issues and Strategies **JordanNash** (*CERN*)

09:45-10:30 Considerations for Future Large Pixel System **Roland
Horisberger** (*PSI*)

10:45-11:15 Report on Work of CERN RD50 **Mara Bruzzi** (*Dipartimento
di Fisica, Universita di Firenze*)

11:15-11:45 Overview of Current CMS Tracking Systems **Lenny Spiegel**
(*Fermilab*)

11:45-12:15 CMS Silicon Microstrip Tracker Upgrade **Joseph Incandela**
(*University of California, Santa Barbara)*

12:15-13:00 Overview of Technologies for Future Detectors **Ray Yarema**
(*Fermilab*)

14:00-16:00 Parallel Sessions (WG2 and WG3)

Working Group 2:

14:00-14:05 Introduction

14:05-14:35 Assembly and Construction Experience from FPIX **Michael
Eads** (*University of Nebraska*)

14:35-15:05 Impact of New Designs on Assembly and Testing **Sudhir
Malik** (*University of Nebraska*)

15:05-15:25 Gaps in Active Regions **Max Bunce** (*University of
Colorado*)

15:25-15:55 ATLAS Plans for Pixel Upgrades **Aaron Dominguez**
(*University of Nebraska*)

Working Group 3:

14:00-14:15 Introduction and Charge **Erik Gottschalk (***Fermilab***)**

14:15-15:10 Current Trigger and its Limitations **Sridhara Dasu
(***University of Wisconsin***)**

15:10-16:00 CMS/SLHC Tracking Trigger Studies **John Jones**

Working Group 3 with Working Group1 and 2 invited

16:00-16:30 Track Triggering Studies for SLHC **Jinyuan Wu**
(*Fermilab*)

17:00-17:30 Where did the Trigger Primitives in the Pixel ROC GO? **Alan
Hahn** (*Fermilab*)

**Wednesday, October 11:**

09:00-13:00 Working Group 2 and Working Group 3 Joint Session

09:00-09:30 Pixel Simulation Status and Tutorial **Xingtao Huang**
(*University of Puerto Rico, Mayaguez*)

10:00-10:30 Status of Pixel Geometry **Vesna Cuplov** (*Purdue
University, Calumet*)

11:00-11:30 CMSSW Tracking Software **Kevin Burkett** (*Fermilab*)

12:00-12:30 CDF Tracking Trigger Jahred Adelman *(University of
Chicago)*

09:00-13:00 Working Group 1

09:00-9:30 3D Detectors **Cinzia da Via** *(Brunel University, London)*

09:30-10:00 ROC Developments at PSI **Han-Christian Kaestli** (*PSI*)

10:00-10:30 Sensor R&D at PSI **Tilman Rohe** (*PSI*)

10:30-11:00 Sensor R&D at Purdue **Gino Bolla** (*Purdue*)

11:00-11:30 Modeling of Heavily Irradiated Silicon Sensors **Morris
Swartz** (*Johns Hopkins University*)

14:00-16:00: Working Group 3 with Working Group 1 and Working Group 2
invited

14:00-14:30 Ideas for a Hardware Tracking Trigger at ATLAS **Erik
Brubaker** *(University of Chicago)*

15:00-15:30 The BTeV Trigger **Mike Wang** (*Fermilab*)

16:00-18:00 Plenary Session

16:00-16:30 Summary of the LHC Electronics Workshop **Guilherme Cardoso
de Cardoso** (*Fermilab*)

16:30-17:00 Serial Powering **Marvin Johnson** (*Fermilab*)

**Thursday October 12:**

09:00-11:00 Working Group 3

09:00-09:30 D0 L1 Trigger **Meenakshi Narain** (*Brown University*)

09:00-11:00 Working Group 1

09:00-09:30 Radiation Hardness Experiences in CDF **Ignacio Redondo**
(*CIEMAT, Madrid*)

09:00-11:00 Working Group 2

09:00-09:30 Impact of Pixels and Strips on b-tagging and Vertexing Joe
Incandela (*UCSB*)

09:30-10:00 Cabling and Services **Kevin Stenson** (*University of
Colorado*)

10:00-10:30 Lessons from Construction of Plaquettes/Modules at Purdue
**Kirk Arndt** (*Purdue*)

15:00-17:00 Workshop Summary and Discussion

15:00-15:30 Working Group1 Report

15:30-16:00 Working Group 2 Report

16:00-16:30 Working Group 3 Report

16:30-17:00 Discussion

**Appendix 2** : **List of Participants**

G. Landsberg, M. Narain

*Brown University*

C. da Via

*Brunel University, London*

K. Ecklund

*University of Buffalo, NY*

J. Nash

*CERN*

J. Adelman, E. Brubaker

*University of Chicago*

I. Redondo

*CIEMAT, Madrid*

M. Bunce, K. Stenson, S. Wagner

*University of Colorado*

J. Alexander, J. Thom

*Cornell University*

D. E. Pellett

*University of California, Davis*

J. Incandela

*University of California, Santa Barbara*

B. Baldin, K. Burkett (WG2 co-lead), J. Butler, G. Cardoso, H. Cheung
(WG3 co-lead), D. Christian, M. Demarteau, E. Gottschalk (WG3 co-lead),
J. Howell, M. Johnson, U. Joshi, S. Kwan (WG1 co-lead), V. Pavlicek, L.
Spiegel, P. Tan, M. Turqueti, L. Uplegger, M. Wang, Jin-yuan Wu, R.
Yarema

*Fermilab, Batavia IL, USA*

M. Bruzzi

*Universita di Firenze*

C. Gerber

*University of Illinois, Chicago Campus*

J. Jones

*Imperial College, London*

C. Newsom, L. Perera

*University of Iowa*

T. Bolton

*Kansas State University*

A. Bean

*University of Kansas*

L. Cremaldi

*Louisiana State University*

S. Eno, N. Hadley

*University of Maryland*

A. Dominguez (WG2 co-lead), M. Eads, S. Malik

> *University of Nebraska, Lincoln, NE, USA*
>
> W. Erdmann, R. Horisberger, H. Kaestli, D. Kotlinski, T.Rohe
>
> *Paul Scherer Institute*

X. Huang, A. Lopez

*University of Puerto Rico*

K. Arndt, G. Bolla, D. Bortoletto (WG1 co-lead), M. Jones, P. Merkel, I.
P. Shipsey

*Purdue University*

V. Cuplov, N. Parashar

*Purdue University, Calumet*

E. Bartz, S. Schnetzer

*Rutgers University*

M. Artuso

*Syracuse University*

M. Swartz

*Johns Hopkins University*

S. Spanier

*University of Tennessee*

P. Sheldon

*Vanderbilt University*

W. Smith, S. Dasu

*University of Wisconsin*

[^1]: **References**

    \[?\] <http://www.uscms.org/fpix/pixel_wksp_06/>

[^2]: \[?\]
    <http://www.uscms.org/fpix/pixel_wksp_06/Oct06_Charge_v2.pdf>

[^3]: \[?\]
    <http://cmsdoc.cern.ch/cms/electronics/html/elec_web/common/slhc.html>
    and
    <http://cmsdoc.cern.ch/cms/electronics/html/elec_web/docs/slhcusg/slhc-eoi-0.95.pdf>

[^4]: \[?\] See talk presented by Jordan Nash at this Workshop, slides
    located at
    <http://indico.cern.ch/materialDisplay.py?contribId=1&amp;materialId=slides&amp;confId=6904>

[^5]: \[?\] Riccardo Rainieri, "Tracker Material Budget", presented at
    the Tracker Quality Assurance and Detector Performance Meeting, 19
    September 2006.

[^6]: \[?\] CMS Physics TDR, Volume 1.

[^7]: \[7\] <http://cmsdoc.cern.ch/cms/TDR/DAQ/daq.html> page 308.

[^8]: \[8\] See talk by Sridhara Dasu, slides located at
    <http://indico.cern.ch/materialDisplay.py?contribId=13&amp;sessionId=1&amp;materialId=slides&amp;confId=6904>

[^9]: \[9\] See talk by John Jones, slides located at
    <http://indico.cern.ch/materialDisplay.py?contribId=14&amp;sessionId=1&amp;materialId=slides&amp;confId=6904>

[^10]: \[10\] See talk from Fabrizio Palla and Marcel Vos, slides
    located at
    <http://indico.cern.ch/materialDisplay.py?contribId=s1t5&amp;sessionId=s1&amp;materialId=0&amp;confId=a053123>

[^11]: \[11\] See talk from Jin-Yuan Wu, slides at
    <http://indico.cern.ch/materialDisplay.py?contribId=15&amp;sessionId=2&amp;materialId=slides&amp;confId=6904>

[^12]: \[12\] It was noted after the workshop by Wesley Smith that the
    basic design as stated in the draft CMS SLHC EOI is to read out all
    detectors to BU/HLT nodes directly after L1, thus a L1.5 trigger
    similar to the ATLAS proposal would not be accommodated.

[^13]: \[13\] See talk by Kevin Burkett, slides located at
    <http://indico.cern.ch/materialDisplay.py?contribId=18&amp;sessionId=3&amp;materialId=slides&amp;confId=6904>

[^14]: \[14\] Alan Hahn, private communication.

[^15]: \[15\] See talk by Alan Hahn, slides located at
    <http://indico.cern.ch/materialDisplay.py?contribId=42&amp;sessionId=2&amp;materialId=slides&amp;confId=6904>

[^16]: \[16\] See email from Geoff Hall to Tracker Group, or the link
    [http://cmsdoc.cern.ch/Tracker/Tracker2005/TKSLHC/Tracker SLHC
    working
    groups.htm](http://cmsdoc.cern.ch/Tracker/Tracker2005/TKSLHC/Tracker SLHC working groups.htm)