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

***BTeV Trigger Requirements***

**BTeV Document 0001**

**02 February 2001**

**Editors\
**

Joel Butler, Erik Gottschalk, Vince Pavlicek, Michael Haney

[***1** **Introduction 2***](#introduction)

[2 High Level Requirements 2](#high-level-requirements)

[2.1 Rate Requirement 3](#rate-requirement)

[2.2 Algorithm Requirement 3](#algorithm-requirement)

[2.3 Output Data Rate Requirement 3](#output-data-rate-requirement)

[2.4 Rejection and Efficiency Requirements
3](#rejection-and-efficiency-requirements)

[2.5 Livetime & Uptime Requirements 5](#livetime-uptime-requirements)

[2.6 Excess Capacity & Scalability 5](#excess-capacity-scalability)

[2.7 Flexibility Requirement 5](#flexibility-requirement)

[2.8 Fault Tolerance & Security 6](#fault-tolerance-security)

[2.9 Detector Performance Envelope 6](#detector-performance-envelope)

[2.10 Control & Monitoring 6](#control-monitoring)

[2.11 Support for Commissioning and Debugging
7](#support-for-commissioning-and-debugging)

[3 Electrical Requirements 7](#electrical-requirements)

[3.1 BTeV Standards 7](#btev-standards)

[4 Software Requirements 7](#software-requirements)

[4.1 Software Development 8](#software-development)

[5 Safety Requirements 8](#safety-requirements)

[Dependency Appendices 9](#dependency-appendices)

[A. DAQ Dependencies 9](#a.-daq-dependencies)

[A.1 Trigger Interface to DAQ Data Links to Front-End Electronics
9](#a.1-trigger-interface-to-daq-data-links-to-front-end-electronics)

[A.2 Trigger Interface to Level 1 Buffers
9](#a.2-trigger-interface-to-level-1-buffers)

[A.3 Global Level 1 Interface to the DAQ
9](#a.3-global-level-1-interface-to-the-daq)

[B. Pixel Detector Dependencies 9](#b.-pixel-detector-dependencies)

[B.1 Trigger Interface to the Pixel Detector
9](#b.1-trigger-interface-to-the-pixel-detector)

[C. Muon Detector Dependencies 10](#__RefHeading___Toc505760103)

[C.1 Trigger Interface to the Muon Detector
10](#c.1-trigger-interface-to-the-muon-detector)

[D. Forward Tracker Dependencies 10](#d.-forward-tracker-dependencies)

[D.1 Trigger Interface to the Forward Tracker
10](#d.1-trigger-interface-to-the-forward-tracker)

[E. BTeV Detector Dependencies 10](#e.-btev-detector-dependencies)

[E.1 Detector Dependency 10](#e.1-detector-dependency)

#   {#section .unnumbered}

# Introduction

This document describes the high level requirements for the BTeV Trigger
System. The purpose of the BTeV Trigger System is to accept or reject
beam crossings that occur in the C0 interaction region. Beam crossings
that are accepted are recorded on archival storage. The goal is to
record only those beam crossings that contain events that would
plausibly survive all the requirements of the BTeV data analysis
programs and contribute to physics signals (as well as special
calibration and monitoring data), while rejecting all other beam
crossings. This goal would be easily achievable if the full BTeV offline
analysis could be run for each beam crossing at the beam-crossing rate
of 7.6 MHz. At present, this is not feasible with a reasonable
expenditure on the trigger, so compromises must be made to come as close
to the ideal as possible. The requirements that are listed in this
document are based on detailed investigations of algorithms and
technology, which have led to a baseline set of trigger requirements
that are believed to enable the experiment to achieve its physics goals
while being both affordable and technically achievable. The detailed
design is discussed elsewhere. The Baseline Requirements for the BTeV
Trigger System determined by these investigations are presented here.
The considerations that have gone into determining these requirements
include:

-   The physics goals of the experiment

-   The physical characteristics that distinguish events of interest
    from those that are not interesting

-   The characteristics and performance of the Tevatron and the C0
    interaction region

-   The characteristics of the detector systems and their "performance
    envelopes"

-   The funding available to the trigger task

-   The performance and cost of various electronics and computing
    technologies involved in the trigger system -- including projections
    of these when they must be procured

-   The cost of data storage and data access at the time the experiment
    runs

-   The complexity and technical risk of various approaches

It is important to recognize that the performance of the trigger depends
on the quality of the inputs to it from the detector, the performance of
the Tevatron, and even some unverified physics assumptions about the
largely unexplored forward rapidity region. The trigger must be able to
cope, up to some reasonable extent, with deviations from these
assumptions.

The current design of the BTeV Trigger System implements the trigger in
three levels called Level 1, Level 2, and Level 3. Level 1 consists of
several subsystems. The *Pixel Trigger*, which is the primary physics
trigger for BTeV, receives data from the pixel detector to perform its
task of reconstructing tracks and vertices to produce a trigger
decision. The *Muon Trigger* receives data from the muon detector to
search for muon tracks that come from the interaction region. This
trigger operates independently from the Pixel Trigger, and can be used
to perform a cross check of the efficiency of the Pixel Trigger. Other
triggers that are part of Level 1 include triggers that combine
information from more than one detector (for example, a trigger that
uses information from the pixel detector and muon detector), prescaled
minimum bias triggers, alignment and calibration triggers. The hardware
that receives the trigger results from all of the Level 1 subsystems and
decides whether to accept or reject a particular beam crossing is called
Global Level 1. In the event that Global Level 1 issues a Level 1 accept
for a beam crossing, data for the beam crossing are sent to Level 2 by
the DAQ. For a Level 1 reject the data for the beam crossing are flushed
from Level 1 buffers so that the memory can be used for data from
subsequent beam crossings. At Level 2 more refined calculations and
selection criteria are used to determine which beam crossings will be
rejected, and which ones will be passed on to the Level 3 Trigger. Level
3 performs additional calculations and selects the beam crossings that
are recorded on archival storage.

# High Level Requirements 

This section describes the high-level trigger requirements that are
necessary for BTeV to achieve its physics goals. The primary goal of the
BTeV Trigger system is to reject beam crossings with minimum bias
interactions, while maintaining high efficiency for beam crossings with
*B*-decay modes of interest to the experiment and modest efficiency for
charm decay modes. The trigger decision for a beam crossing, accept or
reject, is produced by Global Level 1 after it receives trigger results
from Level 1 subsystems, such as the Pixel Trigger and Muon Trigger.

## Rate Requirement

BTeV is designed to operate at a luminosity of 2 10^32^ cm^-2^ s^-1^
with a 132 ns beam-crossing interval. This corresponds to an average of
2 interactions per beam crossing. The BTeV trigger must be able to
handle this collision rate with good efficiency and rejection.

-   **Requirement 2.1-1 (Level 1 trigger rate):** The Level 1 trigger
    must make trigger decisions at the beam-crossing rate, every 132 ns
    on average.

-   **Requirement 2.1-2 (Number of interactions per beam crossing):**
    The BTeV trigger must be able to handle an average of two
    interactions per beam crossing, and maintain good efficiency for *B*
    events (see section 2.4) accompanied by an average of two minimum
    bias events.

## Algorithm Requirement

BTeV requires the ability to study a broad range of decays of particles
containing b-quarks, including B~d~, B~u~, B~s~, B~c~, and all types of
b-baryons. BTeV intends to study the decay of these particles into a
wide variety of final states including those that contain only charged
hadrons, those containing charged and neutral hadrons, photons and ^o^s,
electrons, and muons. Moreover, BTeV requires a broad range of flavor
tagging techniques, including muon and electron tags, kaon tags,
same-side tags, jet-charge tags, etc.

-   **Requirement 2.2-1 (Trigger algorithm):** The BTeV trigger must
    base its decision on the characteristic properties of *B* decays so
    as not to limit the physics potential of the experiment. These
    properties must be determined well enough so that any needed
    corrections do not unduly limit the physics reach of the experiment.

## Output Data Rate Requirement

Analyses of the costs of data storage and retrieval have led to the
conclusion that the output data rate should be no more than 200 Mbytes
per second. This corresponds to 2 PetaBytes per Snowmass year (10^7^
seconds of effective running) of raw data.

-   **Requirement 2.3-1 (Output data rate):** The output of the trigger
    must average to no more than 200 MByte/sec at design luminosity.

## Rejection and Efficiency Requirements

An analysis of simulated data indicates that an average event size
(after sparsification by the readout or front-end electronics) of 200
Kbytes per beam crossing is achievable. A further reduction by a factor
of 4 can be obtained by eliminating some away-side information, which is
not useful to the final analysis, some information clearly associated
with the non-*B* events on the signal-side, summarizing and condensing
the remaining information, and possibly applying a compression algorithm
somewhere between the trigger and data storage. The result is that the
average amount of data per beam crossing written to archival storage is
50 Kbytes, which implies a factor of 4 reduction. This also implies that
the output rate must be less than 4000 beam crossings per second.

-   **Requirement 2.4-1 (Output crossing rate):** The BTeV trigger must
    accept no more than 4000 beam crossings per second.

The efficiency of the trigger depends on the particular parent *B*
particle and its final state decay topology. The efficiency is defined
for a particular analysis that is tuned to have acceptable signal to
background to achieve the physics goals of the analysis. The events that
survive the analysis cuts represent the sample of events used to
determine the trigger efficiency. The efficiency is defined as the
fraction of these events that survive the trigger. Extensive simulations
have shown that an efficiency of greater than 50% can be achieved for
most decay topologies with at least two charged hadrons associated with
the *B* vertex, or the *B* vertex and an associated charm vertex. In
cases with only one charged particle emerging from the *B* vertex and a
non-charm decay such as a K~s~, or a charm decay that has only one
prong, the efficiency will be somewhat lower but should be at least
greater than 10%. This determination of the trigger efficiency assumes
100% pixel efficiency and does not take into account the trigger
livetime and uptime, which have their own requirements and are described
in section 2.5. Inefficiencies in the pixel detector influence the
trigger performance, and we specify a dependency on the pixel detector
in Appendix B. Although we encourage the pixel group to strive towards
100% pixel efficiency, we require that the trigger efficiency does not
drop below 45% as long as the pixel detector is operating within its
performance envelope.

-   **Requirement 2.4-2 (Efficiency):** The efficiency of the trigger
    must be greater than 50% (not including livetime or uptime, and
    assuming 100% pixel efficiency) for nearly all *B* decays having two
    or more charged particles emerging from the *B* or daughter charm
    vertex. The trigger efficiency must be greater than 45% when the
    pixel detector is operating within its performance envelope.

-   **Requirement 2.4-3 (Single prong efficiency):** The efficiency for
    less well defined states such as those with a single prong and a
    K~s~ must be greater than 10%.

Extensive studies have been carried out to determine realistic goals and
corresponding baseline algorithms for the trigger. The baseline design
subdivides the trigger processing into Levels 1, 2, and 3. Each level is
associated with a set of selection criteria that determine which beam
crossings are accepted, and which are rejected. For Level 1 the
selection criteria are implemented in Global Level 1, which receives
trigger results from different Level 1 subsystems such as the Pixel
Trigger and the Muon Trigger. Global Level 1 combines these results to
produce a trigger decision for each beam crossing at Level 1. For Levels
2 and 3 selection criteria are imposed on a beam crossing by the
processor that has been assigned to handle the data for that beam
crossing. The selection criteria for all levels are tuned to improve the
trigger efficiency (as defined above) for interesting events with *B*
decays, while rejecting beam crossings with uninteresting events.
"Rejection" is defined as the fraction of beam crossings that are
rejected by a particular trigger level relative to the number of
crossings that are processed by that trigger level.

The first level of the trigger must inspect every beam crossing and must
make a decision on average every 132 ns (a decision rate of 7.6 MHz).
This limits the amount of time available to Level 1, which is further
limited by the amount of data it can deal with (the total data rate
after sparsification is 1500 Gbytes per second). Level 2 has to deal
with beam crossings that survive Level 1, so if the Level 1 rejection is
R~1~, then Level 2 receives beam crossings at a rate of (1- R~1~) 7.6
MHz and must make a decision every 132 / (1- R~1~) ns. Similarly, if the
Level 2 rejection is R~2~, then Level 3 will receive beam crossings at a
rate of (1- R~1~) (1- R~2~) 7.6 MHz and must make a decision every 132 /
(1- R~1~) (1- R~2~) ns. Finally, if the Level 3 rejection is R~3~, then
the total rejection must be such that (1- R~1~) (1- R~2~) (1- R~3~) 7.6
MHz is less than 4000.

Level 1 Rejection and Efficiency:

-   **Requirement 2.4-4 (Level 1 rejection):** The Level 1 rejection
    must be at least 99% of all beam crossings.

-   **Requirement 2.4-5 (Level 1 efficiency):** The Level 1 efficiency,
    as defined above, must be greater than 55% for *B* decays having two
    or more charged decay particles. The efficiency must be greater than
    50% as long as the pixel detector is operating within its
    performance envelope.

Level 2 Rejection and Efficiency:

-   **Requirement 2.4-6 (Level 2 rejection):** The Level 2 rejection
    must be greater than 80% of beam crossings sent to Level 2.

-   **Requirement 2.4-7 (Level 2 efficiency):** The Level 2 efficiency
    must be greater than 90%.

Level 3 Rejection and Efficiency:

-   **Requirement 2.4-8 (Level 3 rejection):** The Level 3 rejection
    must be greater than 75% of beam crossings sent to Level 3.

-   **Requirement 2.4-9 (Level 3 efficiency):** The Level 3 efficiency
    must be greater than 95%.

## Livetime & Uptime Requirements

The trigger performance can be affected adversely by factors both within
the trigger and outside of it. Factors outside of the trigger system
include an unusually "dirty" beam that produces extra background in the
detector, badly imbalanced bunch populations, poorly performing or noisy
detectors, etc. These "external factors" have the effect of reducing the
pipeline "length" as measured in beam crossings and can therefore cause
the front end systems to run out of buffer space during the trigger
decision time, or can cause the trigger decision time to be longer than
average due to noisier than average events. "Internal factors" include
high failure rates for processors or bottlenecks in the data-transport
network, which would prevent processors from being used efficiently. Any
of these problems can cause the processing to fail to keep up with the
beam-crossing rate and must inevitably result in data being discarded
and therefore lost.

-   **Requirement 2.5-1 (Livetime):** With a suitably pipelined
    architecture, the trigger should have almost no deadtime. We set the
    livetime requirement based on factors "internal" to the trigger to
    be greater than 95%.

The trigger design must be such that it is robust against individual
component failures and is fault tolerant, which means that the trigger
can continue to run (perhaps at reduced efficiency) in the presence of
some failures. Moreover, an uptime requirement for the trigger imposes
limits to reduce the amount of downtime, which can come from time spent
on system initialization or system resets.

-   **Requirement 2.5-2 (Uptime):** The trigger uptime must be greater
    than 95%.

## Excess Capacity & Scalability

While extensive simulations have been and continue to be carried out to
verify the trigger performance, it is impossible to predict exactly what
reality will be like. It is therefore important that the trigger has
extra capacity built in, and that the architecture be such that
additional expansion is possible with incremental funding.

-   **Requirement 2.6-1 (Capacity):** The trigger must have at least 50%
    extra capacity.

-   **Requirement 2.6-2 (Scaleability):** The trigger architecture must
    permit an increase in capacity of at least a factor of 2 in
    processing and data throughput at every level, and a factor of 2 in
    the size of buffer memories.

## Flexibility Requirement

The trigger architecture must be capable of including possible expansion
to satisfy new physics goals that might arise in the future.

-   **Requirement 2.7-1 (Flexibility):** It must be possible to add
    additional types of triggers.

## Fault Tolerance & Security

Fault tolerance and redundancy must be designed into the architecture of
the trigger system. Moreover, the trigger system must have adequate
computer security for computing systems that are part of the trigger and
are accessible from systems external to the trigger.

-   **Requirement 2.8-1 (Component failure):** The trigger must continue
    operating, perhaps at reduced capacity and efficiency, in spite of
    the failure of processors, network connections, etc.

-   **Requirement 2.8-2 (Trigger arbitration):** If the trigger system
    is having difficulty keeping up with the data rate, it must be able
    to drop less important triggers and calculations so that it can
    maintain high efficiency for the most important physics.

-   **Requirement 2.8-3 (Trottling):** The trigger system must be able
    to throttle the input data rate when the rate is too high. A
    mechanism that logs data loss due to throttling must be implemented.

-   **Requirement 2.8-4 (Timeouts):** Timeouts must be used to impose
    limits on excessive calculations that tie up resources. The system
    must monitor and record the frequency of timeouts as a warning and
    diagnostic tool.

## 2.9 Detector Performance Envelope {#detector-performance-envelope .unnumbered}

Detectors never perform perfectly. BTeV detectors will have specific
performance envelopes that must be achieved and maintained. The trigger
must be able to achieve its efficiency and rejection goals when all of
the detectors are within their performance envelopes. There should also
be enough overhead for the trigger to degrade gradually if one or two
detectors move slightly outside of their worst acceptable performance.
Since the performance of the trigger depends on detector performance, we
have included appendices at the end of this document to describe the
dependencies. These dependencies are still under development as we
improve our understanding of the trigger and detector performance.

-   **Requirement 2.9-1 (Performance envelope):** The trigger must
    achieve efficiency and rejection requirements when all detectors
    that affect the trigger performance are within their performance
    envelopes.

## 2.10 Control & Monitoring {#control-monitoring .unnumbered}

The trigger system will have at least two control and monitoring systems
that are interfaced to the control and monitoring system for the BTeV
experiment. The first of the two control and monitoring systems for the
trigger will be used for Level 1. The second will be used for Levels 2
and 3. The Level 1 system requires a dedicated computer system that
manages control and monitoring functions using distributed high-speed
links to subsystems, such as the Pixel Trigger, Muon Trigger, Global
Level 1, and any other system that is part of Level 1. Examples of
functions performed by the Level 1 control and monitoring system include
Field Programmable Gate Array (FPGA) programming, Digital Signal
Processor (DSP) programming and initialization, in-situ diagnostics and
testing, performance monitoring, as well as status and error message
reporting. In addition to performing these functions, the Level 1
control and monitoring system must be able to receive commands from and
report back to the BTeV control and monitoring system. It must record
any unusual conditions or problems in the trigger system and report
them. A similar control and monitoring system will be used for Levels 2
and 3.

-   **Requirement 2.10-1 (Control and monitoring):** The control and
    monitoring systems must receive commands from and report back to the
    BTeV control and monitoring system.

-   **Requirement 2.10-2 (Read-back for programmable devices):** The
    control and monitoring systems must be able to read data that are
    stored in programmable devices in Levels 1, 2, and 3. This includes
    the programs, parameters, device configurations, status and error
    messages, any temperature and voltage measurements, as well as
    processed data at useful probe points in the data stream.

## 2.11 Support for Commissioning and Debugging {#support-for-commissioning-and-debugging .unnumbered}

The trigger system must be able to support not only steady-state
operation but also commissioning and runtime troubleshooting. It will be
necessary to test new trigger algorithms and new trigger hardware (for
example, burning in a new set of processors). During commissioning,
several detectors may be running almost autonomously for debugging or
calibration purposes. The trigger system must be able to support
partitioning. This means that it must simultaneously provide several
different and independent triggers for different subsystems, send data
to different groups of processors, and be able to write data to
different output streams.

-   **Requirement 2.11-1 (Partitioning):** The trigger system must be
    able to support partitioning.

-   **Requirement 2.11-2 (Testing):** All programmable devices that are
    part of the trigger must be testable in-situ.

The trigger system encompasses a large number and different types of
programmable devices, a large number of data links into and out of
trigger subsystems, as well as numerous interconnections between devices
within each subsystem. The commissioning and debugging of such a large
system requires a resource identification and configuration database to
keep track of all hardware and software used in the system. The database
is used to track the location of individual devices (such as crate and
slot number and whether the device is in use), device configuration
information that includes firmware revision numbers, device status
indicating whether the device is operational or not, and a maintenance
history. A separate software database (see Section 4.1) that keeps track
of software developed for the trigger will need to be used in
conjunction with the resource identification and configuration database.

-   **Requirement 2.11-3 (Database):** A resource identification and
    configuration database must be used to keep track of hardware used
    in the trigger system.

# Electrical Requirements

## BTeV Standards

The hardware that is designed and built, or purchased to implement the
trigger will consist of digital electronics. This hardware must comply
with the *BTeV Digital Electronics Standards* document. This document
contains requirements, standards, and recommendations that apply to all
digital electronics in BTeV. The subjects that are addressed in the
document include interfaces, grounding, EMI, shielding, infrastructure,
safety, reliability, and maintainability.

-   **Requirement 3-1 (Electronics standards):** The trigger system must
    comply with the *BTeV Digital Electronics Standards* document.

# Software Requirements

The "software" for the trigger system refers to algorithms, specialized
operating system code, as well as diagnostic and testing code developed
for programmable devices in the three trigger levels, Global Level 1,
and the control and monitoring system. The software includes FPGA (Field
Programmable Gata Array) firmware, software developed for specialized
processors such as DSPs (Digital Signal Processors), and software
developed for general purpose processors.

## Software Development

Software must be developed using standard software tools that allow
version tracking, assist code reviews, encourage documentation, and help
with maintainability. The software must be robust and stable. Software
bugs that could stop operation or induce errors in the trigger must be
eliminated.

-   **Requirement 4.1-1 (Error detection):** Processes that regularly
    verify code purity and run standard datasets for testing purposes
    must be part of the development process, and must be used for
    testing the trigger after the development of the trigger has been
    completed.

-   **Requirement 4.1-2 (Database):** Trigger parameters and constants
    (such as geometry and alignment constants) must reside in a database
    so that the particular values used to process data can always be
    identified.

-   **Requirement 4.1-3 (Software repository):** All software must
    reside in a software repository that must be used to keep track of
    different versions of the software during development.

-   **Requirement 4.1-4 (Version control):** The version numbers of
    software used to process data must be managed in such a way that the
    particular version that was used to process data can always be
    identified and reproduced.

# Safety Requirements

The trigger system does not pose safety concerns beyond the usual and
customary issues associated with low-voltage digital electronics:

-   **Requirement 5-1 (Low voltage, high current safety):** If the
    trigger electronics uses high-current (greater than 10 amps
    operating or 50 amps rated current) low-voltage (less than 50 volts)
    power supplies, the safety requirements for low-voltage,
    high-current power distribution systems must be followed. These
    requirements are detailed in the Fermilab ES&H Manual, Occupational
    Safety And Health section on Electrical Safety.

-   **Requirement 5-2 (General safety):** The trigger system must comply
    with all Fermilab ES&H safety standards.

# Dependency Appendices {#dependency-appendices .unnumbered}

# A. DAQ Dependencies {#a.-daq-dependencies .unnumbered}

### A.1 Trigger Interface to DAQ Data Links to Front-End Electronics {#a.1-trigger-interface-to-daq-data-links-to-front-end-electronics .unnumbered}

The trigger system receives a large amount of data at fairly high rate.
The data must be relatively error free so that the best possible trigger
decisions can be made. This places constraints on front-end electronics
and those portions of the DAQ (such as data links) that deliver data
from the front-end electronics to the trigger. We have not yet performed
the necessary simulations to determine an acceptable error rate for data
links that deliver data to the trigger, and it is possible that the
acceptable error rate will be less than the error rate that is
established for the DAQ system.

-   **Dependency A.1-1 (Link error rate):** The limits on error rates
    that can be tolerated for DAQ data links that deliver data to the
    trigger must be better than some number (to be determined) to avoid
    degradation of the trigger performance.

### A.2 Trigger Interface to Level 1 Buffers {#a.2-trigger-interface-to-level-1-buffers .unnumbered}

The trigger system accesses L1 buffers for various purposes, such as
saving raw data and intermediate trigger results for subsequent trigger
calculations.

-   **Dependency A.2-1 (L1 Buffering):** The DAQ must be able to receive
    raw data and intermediate trigger results from the Level 1 Trigger
    at the beam-crossing rate of 7.6 MHz, and save these data until
    requested by subsequent stages of the trigger.

### A.3 Global Level 1 Interface to the DAQ {#a.3-global-level-1-interface-to-the-daq .unnumbered}

The Global Level 1 Trigger accepts trigger results from the Pixel
Trigger, Muon Trigger, and any other Level 1 Triggers. Global Level 1
uses these results to generate a Level 1 accept or reject for each beam
crossing, and transmits this signal to the DAQ.

-   **Dependency A.3-1 (Level 1 trigger rate):** The DAQ must be able to
    receive trigger decisions at the beam-crossing rate of 7.6 MHz.

# B. Pixel Detector Dependencies {#b.-pixel-detector-dependencies .unnumbered}

### B.1 Trigger Interface to the Pixel Detector {#b.1-trigger-interface-to-the-pixel-detector .unnumbered}

-   **Dependency B.1-1 (Input data requirement 1):** The input pixel hit
    data must include the beam crossing number, chip identification
    number, and the pixel hits for that beam crossing.

-   **Dependency B.1-2 (Input data requirement 2):** The pixel data must
    have row and column numbers, and pulse height information for each
    hit.

-   **Dependency B.1-3 (Pixel efficiency):** The pixel efficiency must
    be greater than some number (to be determined).

-   **Dependency B.1-4 (Noise and hot channels):** The number of extra
    hits due to noise or hot pixel channels must be less than some
    number (to be determined).

-   **Dependency B.1-5 (Alignment):** The alignment of the pixel system
    must (to be determined).

-   **Dependency B.1-6 (Pixel resolution):** The pixel resolution must
    be better than some number (to be determined).

# Muon Detector Dependencies

### C.1 Trigger Interface to the Muon Detector {#c.1-trigger-interface-to-the-muon-detector .unnumbered}

-   **Dependency C.1-1 (Beam-crossing requirement):** The muon hit data
    for one beam crossing must be delivered to the Muon Trigger before
    data from any other beam crossing is delivered.

-   **Dependency C.1-2 (Octant-arm requirement):** All views (R, U,
    V, R) of all stations (1, 2, 3) for [one]{.underline} arm of
    [one]{.underline} octant must be delivered to the same \"place\".
    The data may arrive on multiple fibers per octant. However, the
    16-fold symmetry of the trigger, with complete octant-arm
    independence, demands that no channel connected to the trigger
    contain data from more than one octant.

-   **Dependency C.1-3 (Radially-ordered data):** The data delivered to
    the Muon Trigger must be radially ordered from outermost to
    innermost muon hit.

-   **Dependency C.1-4 (Muon detector efficiency):** The muon detector
    efficiency must be greater than some number (to be determined).

-   **Dependency C.1-5 (Noise and hot channels):** The number of extra
    hits due to noise or hot muon detector channels must be less than
    some number (to be determined).

-   **Dependency C.1-6 (Alignment):** The alignment of the muon detector
    system must (to be determined).

-   **Dependency C.1-6 (Muon detector resolution):** The muon detector
    resolution must be better than some number (to be determined).

# D. Forward Tracker Dependencies {#d.-forward-tracker-dependencies .unnumbered}

### D.1 Trigger Interface to the Forward Tracker {#d.1-trigger-interface-to-the-forward-tracker .unnumbered}

-   **Dependency D.1-1 (Straw and strip efficiency):** The straw and
    strip efficiencies must be greater than some number (to be
    determined).

-   **Dependency D.1-2 (Noise and hot channels):** The number of extra
    hits due to noise or hot channels must be less than some number (to
    be determined).

-   **Dependency D.1-3 (Alignment):** The alignment of the straw and
    strip systems must be (to be determined).

-   **Dependency D.1-4 (Straw and strip resolution):** The straw and
    strip resolution must be better than some number (to be determined).

# E. BTeV Detector Dependencies {#e.-btev-detector-dependencies .unnumbered}

### E.1 Detector Dependency {#e.1-detector-dependency .unnumbered}

-   **Dependency E.1-1 (Event size):** The average event size (after
    sparsification by the readout or front-end electronics) must not
    exceed 200 Kbytes per beam crossing.