The Trigger Supervisor is the one major board designed at CEBAF to support the data acquisition system. It can interface with up to 3 levels of trigger logic, including 12 independently level 1 inputs (8 prescaled), and can control the operation of up to 32 ROC's (extensible with additional hardware).
Level 1 triggers passing a prescale (programmable up to 2^24) cause the 12 level 1 trigger inputs to be latched and passed through an MLU (memory lookup unit) to obtain 3 pieces of information:
The trigger type is used to determine whether level 2 and 3 trigger hardware is in use for this trigger. The event type is written to 4 onboard FIFO's to be sent later via 4 trigger cables to each ROC, (8 ROCs per cable). Simultaneously, the ADC's and TDC's digitize the event, and store the data in a data FIFO on the ADC or TDC board (a feature in some commercial 0FASTBUS modules).
At this point, the trigger system is re-enabled for the next event, so that the dead time of data acquisition system does not include any contribution from the readout controllers -- as long as they don't fall too far behind (typically 8 events, which is enough to de-randomize the event rate). If the ROC does fall behind by more than a programmable number of events, the trigger FIFO's signal a FULL condition, and the trigger supervisor does not re-arm the trigger until space in FIFO's is available. The depth of the trigger FIFO may be set to 1 (no pipelining) or 8, or may be set to 8 for 3 of the 4 trigger busses while the 4th bus runs without pipelining. The latter case is useful to support a few modules without data FIFO's (such as CAMAC modules) while the reset of the system takes advantage of pipelining.
Periodically the trigger supervisor disables the trigger, allows FIFO's to empty, and sends a special code to all ROC's causing them to check that all data FIFO's are empty. This prevents boards from getting out of sequence for longer than one synchronization period (a bucket), and flags that bucket of events as corrupt. The bucket length is programmable, and checking synchronization every thousand events should have negligible effect on the deadtime.