miniBooNE Trigger Notes (Version 0.1)

Rex Tayloe, 3/5/02 (updated by A.G. 4/8/03)

Introduction

The purpose of this document is to continue to inform the collaboration how the miniBooNE trigger works more from the software end, to propose a preliminary trigger scheme, and to write down some details how this all works in our DAQ coding scheme. This is a follow-up to a talk I gave on this subject at the Wednesday analysis meeting 2/13/02. The slides from this talk may be found at: "http://www-boone.fnal.gov/software_and_analysis/meetings/02-13-02/minutes_02-13-02.html .

I only briefly describe some aspects of the hardware. See the fine write-ups listed below for many more details. Please give them a read.

QT Summary

(See Ref. 1, Section 4.2)

Preamps

Each miniBooNE PMT is connected to a single coaxial cable that provides the (positive) HV and routes the signal from the tank to the digitizing system. They are connected to a set of preamp cards which determine the HV to each tube (via a step-down resistor) and separates the PMT signal from the HV on the cable. This PMT signal is then amplified by approximately a factor of 20 and routed to the "QT" system.

QTs

The QT system consists of 12 VME crates of 16 cards with 8 channels per card. Each channel digitizes the time and charge info for each tube and stores this information into a dual-port sRAM at an address determined by the 11 bits of the 10 MHz system clock (the time-stamp address, "TSA"). "Dual Port" refers to the fact that each channel's ram chip can read and write in the same cycle. This dual-port sRAM serves as a circular buffer of length 2048. The data is continuously digitized and written this circular buffer which wraps around every 2048 x 100ns = 204.8 microsec. Data is read from this circular buffer at times (TSAs) that are determined by the trigger to be physics events. If the trigger is too slow in asking for data from a particular TSA, the circular buffer wraps around and the data of interest is lost. This is a condition known as latency (see below). When the data from a particular TSA is retrieved from the dual-port sRAM, it is downloaded into a QT FIFO where it is then retrieved under control of the QT single-board computer (SBC) via the VME bus. All 128 channels of data is gathered by the SBC, zero-suppressed, and then shipped to the host computer (via 100 Mb/s ethernet) where the events are assembled and written to disk.

PMT Sum System

Each QT crate also contains a PMT sum card on the end of the crate. This card counts the number of channels that fired (discriminator hit) in the last 2 clock cycles (200ns). This information is then routed to the trigger crate main and veto comparator cards which adds the numbers from the main and veto crates for an overall main and veto number of hits. There is time delay of 10 clock cycles for this PMT sum information to be available in the trigger crate.

Trigger Summary

(See Ref. 1, Section 4.3.1)

The miniBooNE trigger works by examining a pattern of bits within a piece of C-code. This code runs on a MVME 2304 single-board computer that sits in the trigger crate. The trigger crate contains a handful of other VME modules that (among other things) serve to gather and digitize the information that will be used within the trigger code to determine if a particular candidate event should be read out from the QT crates. This information consists of:

Note: The main and veto sums are formed by summing the 10 main and 2 veto QT crates separately.

If any of the bits (D1,V1,E4,E2) are set for more than ~150ns, then the data is latched to a trigger memory FIFO (this is a hardware action). The latched data consists of the bits described above (plus some diagnostic bits), plus the 16 bit binary clock (running at 10 Mhz corresponds to about 7ms). In total, 32 bits are stored. We often call this hardware action "asserting the trigger memory." Note that one of the 4 bits (D1,V1,E2,E4) must be true or the state of these bits at a particular (16 bit, 10 MHz) time will not be stored. This is important to remember!

The trigger code loops through the bit patterns stored in the trigger memory FIFO. It uses this information (plus any history that is stored by the code) to determine whether to call a particular 16 bit time stamp address (TSA) an "event". If an "event" is found, then the trigger sends this particular TSA to the trigger broadcast card which then distributes ("broadcasts") this TSA to the QT crates which initiates a download of the QT data.

In addition, the trigger code maintains an "activity stack". This is a list of TSAs and bit information that were in the trigger FIFO in the last 50 microseconds (adjustable within the code).

A "Strawperson" Trigger

Find below a proposal of how to set up the trigger for miniBooNE (the actual implementation is is version 1.0 and later versions of this document). The exact value for comparator levels will have to be adjusted when we see what the rates are and what each trigger requires.

Set detector comparator levels to:

trigger bit

setting

trigger bit

setting

DET1

# tank hits >= 5

VETO1

# veto hits >= 6

DET2

# tank hits >= 10

VETO2

# veto hits >= 4

DET3

# tank hits >= 40

E1

booster extract time - 5 microsec

DET4

# tank hits >= 100

E2

laser or cubes fire

DET5

# tank hits >= 200

E3

mu counters fire

E4

random strobe


Using these bits and appropriate logic within the trigger code, create these "windows":

window name

abbrev.

condition

time in effect

explanation

"beam window"

BW

E1

20 microsec

Time window around beam spill.

"veto holdoff"

VH

V1

10 microsec

Veto activity has occurred in near-past. Look for muon-decays.

"gamma window"

GW

BW && D4 && !V2

1000 microsec

A neutrino interaction has occurred. Look for neutron capture gammas.

"Michel window"

MW

B2 || B3

10 microsec

A veto or muon tracker event has occurred. Look for muon-decays.


With these bits and windows, for a particular TSA create these triggers and take these actions:

trigger name

condition

actions

explanation

neutrino beam

BW

- broadcast TSAs for activities on stack.
- broadcast the subsequent 200 TSAs.

Beam is on. Examine all data around spill and past activities.

fake beam

!BW && B4

- same as neutrino beam trigger.

Beam is not on. Take a "fake spill" for background investigation.

laser or cube

!BW && B2

- broadcast subsequent 16 TSAs.

Calibration event.

mu-tracker

!BW && B3

- broadcast subsequent 16 TSAs.

Calibration event.

gamma

!BW && GW && !VH && D1 && !V2

- broadcast subsequent 16 TSAs.

Look for n-capture gammas.

Michel

!BW && MW && !VH && D3 && !V2

- broadcast subsequent 16 TSAs.

Look for n-capture gammas.

Veto (prescaled)

!BW && V1

- broadcast subsequent 16 TSAs.

Look at (some) veto events.

Supernova

!BW && !VH && D2 && !D3

- broadcast subsequent 16 TSAs.

Supernova candidates.



Notes:

Deadtime and Latency

Deadtime

Readout of the QT cards does not cause the cards to halt digitization. In this sense, we have a "deadtimeless" system. However, there are times when the DAQ is not taking data. This "deadtime" comes in 2 types:

Macroscopic Deadtime
This is when we are not taking data when the beam is on (missing neutrinos) because the DAQ is not running. Like, in between runs, recovering from a crash, operator error, etc.
Microscopic Deadtime
This is when the DAQ is running, however we stop the trigger to: allow the QT cards to catch up, reset the QT cards, run an (automated) QT-check program.

We will have to come up with methods to measure both of these.

Latency

As mentioned above, "latency" is when the trigger is too slow in broadcasting TSAs of interest and by the time the data is requested from the QT sRAM, more than 2 microsecs has passed and the data is overwritten. It is known when this condition occurs as the trigger broadcast card returns the current time when a particular TSA is broadcast. If the current time minus the TSA is greater than 2 microsec then the data will be latent. This state is flagged for a given event by setting a latency bit.

The principle cause for this condition seems to be loading words into the trigger FIFO at too high a rate. The trigger can not unload and analyze these trigger words fast enough and data becomes latent. This effectively sets a lower limit on the detector and veto comparator settings (and the rate on the trigger memory card BNC inputs).

DAQ Coding Details

Historical note (4/8/03 A.G.) : Before April of 2002, the trigger software was quite simple. We used the programs tr_test, tr_e4, tr_michel, and tr_nhit to trigger on one trigger type at a time. The event type and Event ID fields (mentioned below) in the broadcast header were used, but we were not writing trigger data to the data stream yet. So, the only way that the trigger interacted with the data stream was that broadcasts were sent to the QTs on the TSA bus. These broadcasts had the event type and event ids encoded. Since we also ran one trigger type at a time, we also were not able to mix and match trigger types in the same run. (Well, we COULD, but we would not be able to tell the difference very conveniently since there was no separate trigger data stream). tr_nhit usually used DET1, and the setting of that comparator changed with time depending on what we wanted to do.

Event Types

The event type selected by the trigger will be set in the bit field called "Event Type" (6 bits, 18-23) in the Broadcast Write word (see ref 3). These are then transmitted via the TSA bus to the RCVR card and may be accessed in the RCVR words (bits 19-24). We will keep a list of these trigger types in an appropriate header file along with the number of TSAs that are broadcast for each event type. In this way, we can know how many TSAs to read on the QT end for each event without gymnastics with the RCVR EOF bit. There is a limit in the broadcast card of a window size of 32 TSAs. We can generate multiple broadcasts of 32 TSAs to get the larger window sizes desired (e.g. 200 TSAs for a beam spill. As can be seen above, we currently are thinking of writing 200 TSAs for neutrino beam events, 16 TSAs for everything else - but we can easily change this. There will be a mapping (in this .h file) of event type to TSA window size.

Event IDs

The event ID bit field in the Broadcast Write word (8 bits, 24-31) will be used as an event counter (albeit only 8 bits). This is also seen by the RCVR card. It will be kept with the rest of the RCVR header and compared in assembler to make sure that the subevents from individual crates match up correctly. This is currently implemented but not checked in assembler as TSA bus problems cause these bits to not match up. We need to fix this.

References

  1. LSND NIM paper: NIM A388, 149, '97.

  2. miniBooNE TDR

  3. "Data Acquisition Electronics and Programmer's Model, BooNE TN-038, Vern Sanberg, 2001.


Rex Tayloe

Last modified: Tue Mar 5 14:14:58 EST 2002