		Abstract


	We have designed and are fabricating a Trigger 
Supervisor module for use in nuclear physics experi-
ments at CEBAF. The functionality and implementa-
tion of the module will be discussed.


 			I. Introduction


	The Continuous Electron Beam Accelerator Facil-
ity (CEBAF) is scheduled to begin delivering 4 Gev 
electron beam to three experimental halls in `94-95. 
We are in the process of designing a common data 
acquisition architecture capable of high event rates 
(10 khz) for use in each of the experimental facilities. 
The system is based on Fastbus front end electronics 
(ADC's, TDC's), with data collected in parallel by high 
speed readout controllers (ROC). Event fragments 
from the ROC's are assembled and routed to a proces-
sor farm for analysis before movement to storage. 


	To reduce dead time in a high rate environment 
the system is designed to support buffered front end 
modules. Having on-board buffering decouples the 
readout dead time from the actual front end dead 
time, allowing a properly integrated system to run as 
fast as the front end operation permits. The CEBAF 
data acquisition system has been designed to take 
advantage on-board buffering for up to 8 events.


	The trigger supervisor is the interface between the 
experiment specific triggering system and the data 
acquisition system. Acting as the central control point 
for acquisition activity, the CEBAF trigger supervisor 
performs the following major functions: 	(1) accepts and 
prescales multiple sources of triggers, 	 both physics 
and calibration types, 	(2) maintains system busy while 
an input trigger is being 	 processed, 	(3) generates sig-
nals for gating and timing of front 	 end electronics, 	(4) 
couples the levels of multi-level trigger systems, 	(5) 
communicates triggering information to the system's 	 
read out controllers, 	(6) keeps track of the number of 
events currently in the 		front end module buffers.


	The trigger supervisor (TS) allows for a trigger 
system of up to 3 logical levels. 12 independent level 1 
trigger streams can be accepted simultaneously, and 8 
of these can be prescaled. Each input is programmed 
as one of 3 possible trigger classes corresponding to 
their requirement for higher level trigger activity. A 
level 1 trigger that passes through the prescale cir-
cuitry will lock up the TS, latch the values of the trig-
ger lines, and generate up to 8 simultaneous level 1 
accept signals out. The accept signals asserted have a 
precise time relationship to the input trigger and are 
used to generate front end control signals (ADC gates, 
TDC starts/stops). The pattern of accept signals out 
are a function of the latched trigger pattern, with this 
dependence being programmable. If the input trigger 
demands the activation of higher levels of the trigger 
system, the TS issues signals to do this. The TS moni-
tors the pass/fail responses from the higher level trig-
ger systems. For a fail the TS issues a fast clear signal 
to the front end electronics. For a pass the TS will 
start the next trigger level if it exists, or else store 
triggering information in an internal buffer for com-
munication to the system ROCs. When used in con-
junction with buffered front end modules the system 
can go live before the event is read out. The TS sup-
ports a total of 32 ROCs. The trigger information com-
municated to the ROCs is in the form of a 4-bit 
programmable readout code determined from the 
latched trigger pattern. Thus up to 16 independent 
readout control functions are permitted.


 		II. Trigger Supervisor Operation


	We now expand on the brief description of the Trig-
ger Supervisor operation given in the Introduction.


	A simplified block diagram of the Trigger Supervi-
sor (TS) and its connections to the trigger system, 
front end electronics, and readout controllers (ROC) 
are shown in Figure 1. The TS allows for three logical 
trigger levels that can be associated with three stages 
of gating of the front end electronics. Any number of 
physical trigger levels may make up a logical level.


	Up to 12 independent level 1 trigger streams can 
be accepted simultaneously. The level 1 triggers can be 
required to be in coincidence with a common strobe. 
Each trigger input can be individually disabled within 
the TS. Inputs 1-4 can be prescaled by up to a factor of 
1 million, while inputs 5-8 can be prescaled by up to 
16K. Each input is programmed as one of 3 possible 
trigger classes:


	Class 1 - no higher level trigger decision is required to 		
have event readout. Level 2 and level 3 trigger 		
logic is not started. For calibration type triggers, 		
or systems with no higher level trigger logic. 	


Class 2 - only level 2 pass is required to have event 		read-
out. Level 3 trigger logic is not started. 		For trig-
gers not requiring a 3rd level of logic.


 	Class 3 - both level 2 and level 3 pass are required for 		
readout. For complex physics triggers.


 	We discuss the operation of the TS for a class 3 
trigger. Differences for class 1 and class 2 will be 
described after this. 


	The TS is ready to accept triggers when all of the 
following conditions are satisfied: 	- it is user enabled, 	- 
no TS cycle is currently active, 	- no input trigger is 
currently latched, 	- "front end busy" is not asserted, 
and 	- "external inhibit" is not asserted. 	When the TS is 
ready to accept triggers a level 1 trigger that passes 
through the prescale circuitry will lock up the TS and 
latch the values of the trigger lines. This latched trig-
ger pattern addresses a memory lookup unit (MLU) 
whose outputs generate 8 level 1 accept signals. The 
level 1 accept signals asserted have a precise time 
relationship to the input trigger (35ns delay), and are 
used by external gate circuitry to generate ADC gates 
and TDC starts/stops. At the same time the TS will 
issue level 2 start signal to begin the level 2 trigger 
system. The issuance of level 1 accept signals also 
results in the start of the TS main state sequencer. 
The sequencer will wait for a pass or fail response 
from this trigger system. If a level 2 fail is returned, 
the sequencer will issue a clear signal, which will be 
used to generate (externally) a fast clear to the front 
end electronics. In this case, the TS will remained 
locked up until the front end is no longer busy (front 
end busy). Then a new level 1 trigger may be accepted. 


	If a level 2 pass is returned instead, a level 2 
accept signal is issued by the sequencer along with 
level 3 start. Level 2 accept is used to generate addi-
tional gating to the front end (e.g. digitize data), and 
level 3 start initiates level 3 trigger logic. The 
sequencer will wait for a pass or fail response from 
this trigger system. If level 3 fail is returned, the 
sequencer will issue clear and remain locked up until 
front end busy is no longer asserted. Then a new level 
1 trigger may be accepted by the TS. 


	If level 3 pass is returned the event is to be read 
out. Lev 3 accept is issued by the sequencer to gener-
ate additional gating signals if required (e.g." buffer 
data"). Trigger information for the event must be made 
available to the read out controllers. Like data from 
the front end modules, this trigger data is presented to 
the ROC's in a buffered fashion. The TS supports a 
total of 32 ROC's on its 4 independent ROC branches 
(see Fig 1). Each branch consists of an 8-deep buffer 
memory (FIFO), buffer counter, and read sequencer 
located on the TS, with an external cable that links up 
to 8 ROC's. The trigger information carried along 
these branches is in the form of a 4-bit readout code 
output from the ROC MLU. Thus up to 16 indepen-
dent readout control functions are permitted. The 
latched trigger pattern forms the address of this MLU. 
Two additional data bits that will be described later 
also appear on the branch cable for the event.


	When front end busy is no longer asserted, the TS 
main sequencer will load the code for the event into 
the next available location in each of the buffers. All of 
the buffer counters are incremented upon this load. If 
none of the buffers is now full (buffer count = 8), the 
main sequencer drops level 1 accept, level 2 accept, 
level 3 accept, and re-arms itself to accept new level 1 
triggers. Otherwise the sequencer will hold its state 
and wait for space to become available in all buffers 
before dropping the accept signals and re-arming 
itself.


	The following describes the communication of trig-
ger information on one of the branches. The same 
activity occurs concurrently and independently on all 
4 branches. Once the read sequencer on the branch 
notices that its buffer is not empty (buffer count > 0), 
the transmission of trigger information for the event 
to the ROC's along the branch begins. The read 
sequencer places the readout code from the first valid 
buffer location onto data lines data(2-5) and strobes 
these with strobe. The ROC's along the branch receive 
this data and proceed to read out the event fragments 
according to the function defined by the readout code. 
Each ROC is assigned a unique acknowledge line on 
the branch cable. When a ROC on the branch is fin-
ished processing the event it asserts its acknowledge 
line. Upon receipt of acknowledges from all ROC's on 
the branch, the read sequencer resets data(2-5), drops 
strobe, and decrements its buffer counter. Each ROC 
lowers its acknowledge upon detecting the negation of 
strobe. The read sequencer cycle is completed when it 
detects that acknowledge has been lowered by all 
ROC's on the branch. These cycles on the branch will 
continue as long as there is valid trigger data avail-
able in the buffer.


	For class 1 and class 2 trigger types the activity of 
the TS main sequencer is somewhat different. For 
class 1, no higher level trigger decision is required so 
the level 2 start and level 3 start signals are never 
issued. The sequencer must generate the level 2 and 
level 3 accept signalsthat may be necessary for front 
end gating. The delays for these signals (after level 1 
accept) are programmable and are loaded into the TS 
at run start time. Once front end busy is no longer 
asserted, the TS will behave as described earlier. 


	For class 2 triggers the TS generates level 2 start 
and the sequencer waits for the level 2 trigger deci-
sion. If level 2 fail is returned the sequencer asserts 
clear and gets itself ready for a new trigger. If level 2 
pass is returned the sequencer issues level 2 accept, 
but not level 3 start. The level 3 accept signal is gener-
ated by the sequencer at a programmed time as 
described for class 1 triggers. Once front end busy is 
no longer asserted, the TS will behave as described 
earlier. 


	For systems that exclusively have front end mod-
ules with no buffering capability, the depth of the TS 
branch buffers can be set to 1. In this situation the TS 
will be able to accept new triggers only when the pre-
vious event has been completely read out.


	The TS also supports a mixed system of buffered 
and non-buffered front end modules. One branch 
(branch 4) can be set to have a buffer depth of 1 inde-
pendent of the other branches. All non-buffered front 
end modules must have their ROC reside on branch 4 
when such a mixed system is used.


A. Simultaneous triggers


	The case may arise where several triggers of dif-
ferent classes have occurred simultaneously. The TS 
must be able to decide what sequence to perform in 
this case. This is accomplished using the trigger class 
MLU. This high speed memory is addressed by the 
latched trigger pattern with the output bits defining 
the trigger class. An additional bit of this MLU is 
available to tag unacceptable trigger patterns. When 
this bit is asserted a fast trigger clear feature will 
reset the TS with no issuance of level 1 accept.


B. Synchronization


	In our system the ROC's will be reading data from 
front end module buffers and may be several events 
behind the trigger. Only the position in the buffers 
link the pieces of data as an event. There lies a danger 
that if a hardware error occurs resulting in a misalign-
ment of data (e.g. a module misses a gate), subsequent 
events will be corrupted. 	To avoid this potentially 
large loss of data the TS-ROC system is designed to 
periodically test for synchronization automatically. 
This is done as follows. The TS will be programmed 
with a synchronization count at run start time. When 
the TS has accepted this number of events, it asserts 
and writes the synchron- ization bit along with the 
readout code to the branch buffers. As long as the sync 
bit remains asserted the TS main sequencer will hold 
its state, unable to accept new triggers. The read 
sequencers on the branches continue to send trigger 
information for events that remain in the branch buff-
ers, and the ROC's continue to read the event frag-
ments from the front end modules in normal fashion. 
Just as always, a "no data" response from any front 
end module indicates loss of synchronization, and the 
block of events since the last successful synchroniza-
tion must be noted as corrupt. The last event in all 
branch buffers is the synchronization event, and the 
sync bit appears as data(0) on the branch cable when 
the read sequencer reaches this event. The ROC's read 
this event from the front end modules as normal, but 
do not yet respond with acknowledge. At this point all 
front end module buffers should be empty. Each ROC 
attempts at least one more event read to assure that 
no additional data is found, also indicative of a syn-
chronization problem. When this process and any 
bookkeeping associated with it is completed, the ROC 
finally issues acknowledge. When all ROC's have 
responded, the synchronization bit and the synchroni-
zation counter are reset, and the TS cycle is completed 
with the re-arming of triggers. 	The synchronization 
can also be forced to be done at any time by the user. 
When the request is made the TS disables new trig-
gers and waits for any current cycle to finish. Then the 
TS establishes a zero readout code as a tag, and 
asserts and writes the synchronization bit along with 
the readout code to the branch buffers. The read 
sequencers on the branches continue to send trigger 
information for events that remain in the branch buff-
ers, and the ROC's continue to read the event frag-
ments from the front end modules in normal fashion. 
When the ROC's recognize the zero readout code along 
with data(0) asserted, they know that the front end 
module buffers should be empty. As for the scheduled 
synchronization described above, each ROC attempts 
at least one more event read to assure that no addi-
tional data is found. When this process and any book-
keeping associated with it is completed, the ROC 
finally issues acknowledge. When all ROC's have 
responded, the synchronization bit and the synchroni-
zation counter are reset, and the user requested syn-
chronization cycle is completed with the re-arming of 
triggers. 


	The ability to synchronize may be disabled by the 
user.


C. Compatability with existing front end 
modules


	The basic scheme illustrated in Figure 1 assumes 
that the front end modules will be told explicitly when 
to load the digitized results into its buffer. However, 
some commercially available buffered front end mod-
ules do not operate in this way. Consider as an exam-
ple the LeCroy 1882F FASTBUS ADC. When a gate is 
issued to this device it will sample and hold the analog 
input. The hold time is programmable, and when it 
elapses the data will be digitized and loaded into the 
buffer. Only a clear signal during the hold time will 
successfully purge the data. The clear issued by the TS 
results from a level 2 fail or level 3 fail received from 
the trigger system. If such a fail signal comes after the 
hold interval elapses the data is destined for the buff-
ers, and the TS must declare this event as accepted to 
the ROC.


	To do this the TS has a programmable timer. 
Started on the issuance of level 1 accept, the TS will 
behave as described earlier as long as this timer has 
not expired. If this period elapses before the highest 
level decision required of the trigger occurs, clear is 
disabled and the TS continues to wait for a decision. If 
it is a pass there is no difference from what was 
described earlier. If it is a fail the TS tags the event as 
a late failure by asserting and writing a late fail bit 
along with the readout code to the branch buffers. This 
bit appears as data(1) on the branch cable when the 
read sequencer reaches this event in the buffer. The 
ROC's can use the late fail tag to flush the data for this 
event from the front end module buffers if desired.


	This timer may be disabled by the user.


 			III. Implementation


	The trigger supervisor is implemented as a single 
10 layer printed circuit board using high speed ECL 
and TTL components. Extensive use is made of pro-
grammable logic devices. The trigger supervisor is 
accessed as a 32-bit VME slave. The form factor is that 
of a `D' size (340 x 367 mm) VXI module (VME exten-
sion for instrumentation). This configuration allows 
the device to plug directly into the VXI based trigger 
system of one experimental hall, as well as into stan-
dard 32-bit VME backplanes (with suitably modified 
card cage) of the other experimental facilities.



The CEBAF Trigger Supervisor


E. Jastrzembski, D. R. Quarrie, W. A. Watson III


Continuous Electron Beam Accelerator Facility

