Trigger System

1
Trigger System

• 19 March 2002
• Stanford Linear Accelerator Center
• Stanford CA

2
Trigger Functions

• What does it do?
• Accepts and conditions low level logic signals.
• Alignment
• Stretching
• Combines low level logic signals.
• Combinations are more useful.
• Produces trigger decisions (Trigger
  Requests/Acknowledge).
• Enforces dead time constraints.
• Cant trigger the instrument if it is not
  prepared.
• Involuntary.
• Imposes prescales.
• Voluntary.
• Monitors live time and the performance of itself.

3
Relevant Documents
LAT-SS-284 Trigger Level 4 Subsystem Specification
LAT-SS-285 Dataflow Level 4 Subsystem Specification
LAT-SS-286 Global Trigger Conceptual Design
LAT-TD-560 LAT Global Trigger and ACD Hit Maps
4
Why a Global Trigger?

• Physical Reason
• These functions demand many signals be brought
  together.
• Logical Reason
• Local Tower Trigger does not give the necessary
  rejection.
• 30 reduction with a local trigger.
• 85 reduction with a global trigger.
• Goal
• Cut the rate to an acceptable level
• Provide flexibility and robustness
• Get the most out of the LAT in a variety of
  conditions.
• It does not have to be perfect!

5
GLT Block Diagram

Flow Control
Algorithm Engine
Inhibits
Trigger Acknowledge Message
Parameterization
6
Front-End Trigger Signals

• Subsystems provide the following low-level
  signals
• ACD, LO and HI discriminator signals.
• LO is efficient for minimum ionizing particles.
• HI selects CNO events.
• CAL, LO and HI discriminator signals.
• LO anticipated threshold 100Mev.
• HI is used for very high energy (gt5-10GeV)
  events.
• TKR, Layer OR.
• Inputs can be disabled or by-passed.
• Front-End signal counts
• ACD, 216 inputs, 2 x 89 signals that are
  relevant.
• CAL, 16 inputs ? 2 outputs/tower.
• TKR, 72 input ? 1 output/tower

7
Trigger Signals First Level of Processing

• ACD Primitives 33 gt 17
• 16 tower vetoes.
• Tiles forming the tower umbrella will be
  programmable
• 1, OR of HI discriminators per front-end gt 1 OR
  of all tiles.
• 1, OR of HI discriminators per front-end. ?
• 15 signals
• OR of gt 1 tile/face (5 faces, LO discriminator).
  ?
• OR of gt 2 tile/face (5 faces, LO discriminator).
  ?
• OR of gt 3 tile/face (5 faces, LO discriminator).
  ?
• CAL 2 / tower
• OR of LO discriminator.
• 3-in-a-row coincidence of HI discriminator layer
  ORs.
• TKR 2 bits / tower gt 1 bit
• 3-in-a-row or 7/8 coincidence of layer ORs.
• 2 bits give the information on starting
  Z-position gt 1bit. ?

8
Trigger Signals-2nd Level of Processing

• CAL HI OR, 1 signal
• CAL LO OR, 1 signal
• CNO OR, 1 signal
• TKR 3-in-a-rows OR, 1 signal
• OR of (TKR 3-in-a-rows and ACD umbrellas, 1
  signal
• You can do the Boolean logic on this signal, but
  the intent is that it is true iff there is a
  3-in-a-row in the tracker, but no 3-in-a-row that
  is vetoed by its umbrella of ACD tiles
• Yeah, there is an
• External trigger input for testing
• CPU trigger for testing/calibration
• BUT lets ignore them, they are not relevant to
  this discussion!
• Bottom line is that there are 5 signals to the
  GLT.

9
Control/Prescales

• All signals into the OR gates have
  enables/disables
• Controls noisy channels
• Would like each tower based signal to also have a
  prescaler
• Allows one to control the rate from any given
  tower, without turning it off altogether
• Range of the prescaler need be 6-8 bits
• This prescale is understandable for the straight
  signals
• Likely not relevant or useful for the vetoed
  3-in-a-row
• By its nature this is global information
• Does prescaling the 3-in-a-row from a tower after
  the logic make sense or is it useful
• My guess is no
• Any ideas on this

10
GLT Block Diagram

Flow Control
Algorithm Engine
Inhibits
Trigger Acknowledge Message
Parameterization
11
Algorithm Engine

• Algorithm Engines maps Processed Trigger
  Primitives to Trigger Requests.
• Small number of primitives admits to a lookup
  table implementation (may or may not do this way)
• Address is formed from the state of the
  primitives.
• Contents is a list of the active Trigger Requests
  Messages.
• In all honesty, though, the number of useful
  combinations is limited.
• Throttled TKR 3-in-a-row (3-in-a-row CAL HI)
• TKR 3-in-a-row with CAL LO?
• Throttled TKR 3-in-a-row with CAL LO?
• TKR 3-in-a-row with CNO?
• In terms of trigger rate mitigation, only
  combining 3-in-a-row with CAL LO provides real
  relief.

12
GLT Block Diagram

Flow Control
Algorithm Engine
Inhibits
Trigger Acknowledge Message
Parameterization
13
Trigger Request -gt Trigger Acknowledge

• Trigger Request becomes an Acknowledge, if not
  inhibited by
• The global flow-control signal.
• Its prescaler.
• Occurrence based, decremented by Trigger Request.
• Hard to monitor, likely will not implement.
• Time based, decremented by clock.
• Trigger Acknowledge Message carries the following
  information.
• How to read out the front-end.
• Disable zero-suppress/auto-ranging for CAL/ACD (4
  bits).
• In the event of multiple requests, the messages
  are ORable
• A Trigger Acknowledge Message carries
• Event Identification.
• Dispatch Information, directing an event to a
  processing CPU.

14
Trigger Acknowledge Path

• Trigger Accept Message is transported to the
  front-ends by a dedicated wire.
• Avoids arbitration problems.
• FE saves/latches its current data upon receipt of
  Trigger Accept.
• Message arrives lt 2 usec after event T0.
• Message arrives with low jitter, 250 nsecs.
• The CAL and ACD have no internal buffering, so
  data moves directly output FIFOs.
• TKR has buffering, so after latching the data,
  some form of the trigger message must be queued
  to control the readout.

15
Dead Time Monitoring

• Global Trigger monitors dead-time.
• Two non-resetting counters are maintained
• A clock.
• A clock gated by the flow-control signal.
• Recorded with every event.
• Differences give the dead-time between the
  events.
• The monitoring of dead-time must include
• Contribution due to the flow-control signal
• Contribution due to the trigger itself.

16
Trigger Data

• GLT contributes a data block to the event.
• Two basic purposes
• Dead time monitoring
• Aforementioned counters.
• Dead time cause
• Integrity and performance monitoring
• Includes
• State of trigger inputs
• State of trigger primitives
• Trigger Requests
• Trigger Message
• Counters (TBD)
• Event Absolute Time (the Clock)

17
Issues

• Should we reduce the number of ACD primitives?
  (YES)
• Eliminate the 15 face primitives
• Collapse the CNO side and top signals to 1 signal
• Should we give-up pursuing 2 bits of TKR
  information? (YES)
• Should we add a 7/8 coincidence to the TKR
  3-in-a-row (YES)
• This would be added as an OR with the 3-in-a-row
• Should we support occurrence based prescalers?
  (NO)
• The GLT would work with 5 or 6 signals
• Prescales on the input
• Arbitrary combinatorial logic (is this necessary)
• Prescales on the output