\documentstyle[11pt,a4wide]{article} \title{Eurogam Trigger System} \author{Ian Lazarus} \date{Edition 2.0\\August 1990} \begin{document} \begin{titlepage} { \hoffset=1truein \hsize=5.25truein \vsize=10.25truein \font\small=cmssbx10 at 14.4truept \font\medium=cmssbx10 at 17.28truept \font\large=cmssbx10 at 20.74truept \hrule height 0pt \parindent=0pt %\parskip=0pt \hskip 3.9truein \large EDOC022\par \vskip .5truein \large EUROGAM PROJECT\par \vskip 1.5truein \hrule height 2pt \vskip 20pt \large NSF DATA ACQUISITION SYSTEM\par \vskip .5truein Eurogam Trigger System\par \vskip 20pt \hrule height 2pt \vskip 1truein \medium Edition 2.0\par \vskip 5pt Aug 1990\par \vfill \medium NSF Eletronics Development Group\par \vskip 5pt UK Science and Engineering Research Council\par \vskip 5pt Daresbury Laboratory\par \vskip .5truein } \end{titlepage} \maketitle \section{Introduction} This document relates only to Eurogam and will differ from the Euroball trigger specification in many places. The main difference is that the Eurogam trigger is not pipelined in its first implementation. Eurogam will use the simpler approach of having a common deadtime across the whole system in its first phase, upgrading first to parallel and then to the full parallel and pipelined system envisaged for Euroball. This system specification is intended to allow these two upgrades with the minimum of change. This document describes the trigger system and is not intended to fully define the master trigger logic unit which will be specified properly elsewhere. Revision 2 reflects the two major changes agreed at the electronics/physicists meeting held 5th,6th~June~1990 at Daresbury Laboratory. The first of these is the Compton suppression using the immediate ring of 10 BGO elements in the shield surrounding each Ge will be performed on the appropriate Ge card. Shared suppression using 2nd (and 3rd?) rings of BGO will be performed in software. The second change is that the event reject signal has been removed and the validation may now occur as soon as the fast trigger has been generated. This does not affect performance of the common deadtime system, just the logic of its operation. Other, smaller, changes have also been made to refine the specification and one of the three possible features from the old section 13 have been removed due to lack of interest from physicists. {\em I will include comments and notes (mainly to remind me about details) using this italic typeface to distinguish them from the trigger specification. Marginal notes indicate changes to the specification or rewritten sections where a section has been clarified rather than changed. Most changes come from the 5th/6th June meeting or from Alphonse Richard's document `UTILISATION DES LIGNES VXI'} \section{What is a trigger system?} The question in the title may sound elementary but I have discovered that different people mean different things by `trigger'. I will explain here what I mean by the term trigger in this document. The trigger system identifies and confirms the existence of an interesting physics event. The trigger in Eurogam will take place in two stages: the fast trigger and the validation. The fast trigger must happen before the Ge pulse shapers reach a peak, and the validation must happen after the fast trigger but before ADC readout. The trigger system also defines the interaction of the modules which comprise the system with the fast trigger and the validation. Thus the trigger system requires certain behaviour of the Ge cards, the BGO cards and the readout cards. \subsection{Definitions} \begin{description} \item [Trigger] Signals generated by the master trigger logic as a result of a physics event to indicate that the event is to be collected by the data acquisition system. Trigger is a generic term which covers both fast and slow components (see below). \item [Fast trigger] This signal has two uses: logical and timing. The timing use is that the front edge stops the TAC in each Ge or BGO channel which was started earlier by the CFD in that channel. The logical function is to confirm that the possible trigger denoted by the CFD firing is in fact part of an event which is to be collected. \item [Slow Trigger] Validation of the fast trigger (see Validation). \item [Validation] A signal generated by the master trigger logic after a trigger to indicate that another, slower, set of criteria has confirmed that this is a good event and is to be collected. \item [Deadtime] The time taken by the system to process an input during which it is unable to distinguish or accept any further inputs. \item [Pileup] There are two types of pileup, pre-pulse and post-pulse:\\ \marginpar{{\em Change rev~2.0}} {\bf Pre-pulse Pileup} occurs when the pre-amp signal under consideration arrives while the pulse shaper is still processing the previous pre-amp signal, but on the post-peak tail. In this case only the second pulse will be lost.\\ {\bf Post-pulse Pileup} occurs when a second pre-amplifier signal arrives before the peaking time of the pulse shaper which is processing the first pre-amp signal, thus distorting the peak. In this case both pulses are lost. \item [Pipelining] A method which improves the rate of trigger acceptance by allowing triggers to happen closer to together in time. This is achieved by splitting signal processing into 3 phases: shaping, conversion and readout. A pipelined system (or channel) may thus deal with 3 triggers during the time taken for a single trigger using the common deadtime approach. \item [Parallelism] A method which improves the rate of trigger acceptance by making only the active part of the array dead for an event. Typically less than a third of the Ge channels will be involved in a single event; parallelism allows the rest of the array to accept another (non-overlapping) event while the first is being processed. This is effectively a spatial improvement in efficiency. \end{description} \section{Implications of Ge shaping method for Trigger Timing} \marginpar{{\em Rewritten rev~2.0}} Eurogam pulse shaping has been discussed at length and the choice between semi-gaussian shaping, triangular shaping, deficit correction methods and gated integrators involves many factors. The critical two are the quality of the spectrum produced (peak shape) and the throughput of the electronics which is normally quantified as percentage deadtime for a given event rate. The trigger system is involved in attempts to increase throughput by pipelining and by parallel operation and this section of the specification explains the repercussions of some different approaches to pulse shaping for system throughput. Eurogam electronics has been designed on the premise that the shaped pulse should be available to the ADC within 5$\mu$s of the $\gamma$-ray interaction in the Ge. For semi-gaussian shaping this allows a time constant of 2$\mu$s which has a peaking time of 4.4$\mu$s. Triangular shaping would use a similar time constant and peaking time. For a gated integrator we would use an integration time of 5$\mu$s. Resolution measurements on large HPGe detectors with various shaping times with and without deficit correction are still being made, but it seems likely that by using time constants of 2$\mu$s and deficit correction it is possible to obtain resolution comparable with a gated integrator set to an integration time of 5$\mu$s. Given these figures, we can see that the time to return to baseline (0.1\%) for semi-gaussian shaping is around 13$\mu$s, so there is an 8$\mu$s period after peaking when following pulses will cause pileup, so the channel is effectively dead. It is possible to recover some of this time using an LBL technique\footnote{IEEE NS30 page 301. Goulding, Landis and Madden} for pileup detection which permits some degree of pulse overlap so long as the second peak occurs after the end of the first pulse tail. This technique reduces the post-peak amplifier deadtime to about 5$\mu$s. So, in the best possible case the amplifier is still dead for the entire ADC conversion phase and so there is no benefit in 3 stage pipelining. Pipelined readout only (i.e. readout during the shaping of the following pulse) would reduce the channel deadtime to 10$\mu$s (5$\mu$s for peaking plus 5$\mu$s for conversion) if we use the LBL pileup technique, but conventional pileup detection forces an amplifier deadtime of 13$\mu$s which covers most of the readout phase too. The conclusion is that there is no benefit at all in pipelining without using the sophisticated LBL pre-pulse pileup detection system, and even then we can only regain the readout time. Parallel trigger handling is not affected by these amplifier deadtime problems, neither is the common deadtime method, since both expect a channel to be dead from the time the pulse arrives from the pre-amp until it is read out of the card in digitised form. It should, however, be noted that the 13$\mu$s amplifier deadtime represents a 13\% singles deadtime in each channel at a 10KHz singles rate. The trigger system requires that the shaped signal is ready to be digitised after 5$\mu$s. It also requires that after 15$\mu$s (common deadtime) or 5$\mu$s (pipelined) that the shaping amplifier is ready to accept a new input. For the common deadtime system either amplifier type could meet these requirements, but for pipelining we must use the gated integrator or reduce the semi-gaussian shaping time. \section{Deadtime} For a fold of 3 or more in a 70 Ge system the coincidence rate is around \marginpar{{\em Rewritten rev~2.0}} 30 KHz, so the typical 15$\mu$s deadtime represents 45\%. It is proposed that we will have a pipelined trigger system for the 70 Ge system which will reduce the deadtime to the 5$\mu$s pulse integration time which is only 15\%. For common deadtime we need only consider a 45 detector system, hence a 20~KHz coincidence rate leading to a deadtime of 30\%. Deadtimes greater than 10-20\% are undesirable because they alter the distribution of collected events by making it more regular, leading to non-Poisson statistics. Thus we must try to reduce our deadtime by using additional trigger criteria. The rate reduction for data handling means that we must look for ways to select the data of higher quality and to reject the low quality data. We will, for example generate a clean Ge multiplicity as well as the raw Ge multiplicity, so the two may be used together to select a reaction multiplicity from the raw Ge and to only try to collect data from that reaction if there is a sufficiently high number of clean Ge's too. This information is used to allow or prevent the fast trigger which defines an event. Another selection criterion is the Daresbury recoil mass separator (RMS). The new high efficiency RMS will detect recoil fragments between 0.5$\mu$s and 2$\mu$s after the event (depending on reaction) with efficiency of typically 20 to 30\%, theoretically as high as 50\% for some reactions. In this case we use the RMS information to validate an accepted event after the fast trigger. Even if validation fails, the channels involved will be dead until their amplifiers have recovered to their baseline so the effective size of array for the next 10$\mu$s to 15$\mu$s is reduced by however many channels were involved in the event which was rejected or ignored. (Pipelining will alleviate this problem.) \section{Information used in a trigger decision} In gamma ray spectroscopy the primary trigger method is the multiplicity of coincident hits in Ge detectors. Secondary information will include the Compton suppressed multiplicity, recoil fragment identification, energy sum, beam pulse timing\footnote{NSF Linac produces beam bunches of sub-nanosecond width at a rate which is a sub-harmonic of 150~MHz, typically 9.375~MHz or 4.6875~MHz}, additional detectors (BGO ball, charged particle ball, neutron wall, SUSAN) and other parameters specific to the experiment. The primary timing task of the trigger system is to check the Ge multiplicity quickly and accurately with a well defined coincidence window. \section{Implementation} There are many possible methods of implementation and many questions arise such as whether the trigger system explicitly aborts unsuccessful events or relies on timeouts in the Ge cards, whether we use a centralised trigger or a distributed trigger system and how we calculate multiplicity. The distributed versus centralised trigger discussion has major implications for upgrading the system to pipelined operation and so in order to make the system upgradable we will use a distributed trigger mechanism. (A distributed system is also essential for any parallelism in trigger handling.) \subsection{Fast Trigger} A distributed trigger system means that the Ge/BGO channels must be self timing, defining their own trigger acceptance window timed from the moment the CFD fires. If no fast trigger pulse is received by the end of this window then the Ge/BGO channel will know that nothing interesting happened and it must reset itself. In practice this will mean that the Ge/BGO channel will not convert the shaped value. It is unlikely that a reset circuit can be provided in an accurate shaping amplifier, so the channel stays dead anyway until the shaping amplifier returns to baseline. (Or will have returned to baseline before the following peak. See section 3, footnote 1) The effect of the trigger on the energy part of the Ge/BGO channel is to define those channels which are part of an event and to allow or to prohibit conversion\footnote{Note that in rev 2 we now have 2 types of validation and if coding validation is used then the condition for coding to start is not only the presence of a fast trigger but also a subsequent coding validation.}. It is used by the timing part of the Ge/BGO channel to time against the CFD firing for neutron rejection (or maybe some other purpose). \subsection{Validation} Once the fast trigger has been generated \marginpar{\em{Changed rev~2.0}} we are ready to consider the validation. In Eurogam there are 2 possible validation types of which only one is used in any particular experiment. The first is a coding validation and the second is a readout validation. Difference between the two is in the timing; the coding validation arriving before the shaped pulse peaks and the readout validation coming after peaking. If coding validation is used then readout is authorised by the coding validation too. In both cases, the validation is checked against a validation acceptance window by each Ge/BGO channel. By defining a fixed time between fast trigger and validation signals it is possible to make a parallel or a pipelined trigger system. \subsection{Very Slow Devices} The Euroball `very slow trigger' concept (after readout) will not be supported in hardware by the Eurogam trigger system. It will, however, be possible to delay the end of readout to wait for these slow devices. This will obviously increase the deadtime and will not be a normal mode of operation, but the facility to delay will be provided. The delay will be limited by a programmable timeout in the master trigger unit. The slow devices will receive only the two standard triggers: the fast trigger and the validation and if the timing is not suitable then it is the responsibility of the user to generate his own timing signals using his own logic cards. \subsection{Readout} The trigger system will authorise crate readout by sending the validation pulse \marginpar{{\em Rewritten rev~2.0}} to every crate in the system and, in common deadtime mode, will receive an acknowledgement by way of a wired `OR' signal from every crate meaning Readout Complete (see section 7.4). This will be buffered from the VXI backplane by the slot 0 module. As readout takes place in a crate the Ge/BGO cards each release the backplane `donn\'{e}es \`{a} transmettre' line\footnote{If we implement a simple pipelined mode on the Ge cards, releasing them for the next event when the data are in the Ge card's FIFO rather than the crate readout controller, then we will use `fin de codage' instead of `donn\'{e}es \`{a} transmettre'.} until the signal indicates the end of readout. When all crates have indicated Readout Complete the common deadtime trigger system knows that the data are stored in the readout controller buffers and so it may look for a new fast trigger. Note that this is totally decoupled from readout over the DT32 bus from the other side of the readout controller FIFO buffers and the trigger unit has no direct connection to the DT32 bus. The current Eurogam system design has a derandomizing buffer of 16 words in the readout controllers. There are two possible ways to correlate events: distributed event counters (1 per crate, incremented by triggers) and broadcasting event number with validation. The latter method has been selected and the master trigger logic unit will distribute a 4 bit number to the slot 0 card to be distributed on the VXI backplane with each validation using the bottom 4 bits of the event counter. For backplane readout the event is selected by a 4 bit code on the VME address lines which can easily be used as an internal tag for data in the readout controller by using four $n \times 9$ FIFOs. In parallel or pipelined mode, there is no need for the trigger unit to wait for readout to end before allowing the next trigger, so its only involvement is in generating a validation which is the authorisation for readout of an event. Once this has been issued, the readout controller and all the Ge/BGO cards know that readout will take place, so the readout controller must gain control of the VME bus and send out a readout enable token along with an event number on the VME address lines. (NB there is a requirement that the Ge and BGO cards block the REN signal if they have data for the selected event even if it is not yet ready. See section 18.) \subsection{Multiplicity} The obvious method for calculating the Ge multiplicity is to inject current on the VXI analog sumbus which is intended for exactly this type of usage. Each active CFD will cause the injection of a current of 1mA by its Ge channel for a programmable period. Now that we have decided to use Ge/BGO card pairs (coax) or triplets (stacks) \marginpar{{\em Changed rev~2.0}} so that Ge and BGO cards are mixed within a crate it is necessary to generate additional sumbuses since we require 3 (raw Ge, clean Ge, BGO). These two additional sumbuses are allocated to 2 local bus lines. The local bus lines will sum the clean Ge and the BGO currents, while the VXI sumbus line will be used for raw Ge. In all three cases 1mA is injected per hit. A stack detector is regarded as a single detector and so will inject 1mA if one or more of its planars is hit. Each crate's 3 sumbuses are buffered to the master trigger unit by the slot~0 card via a star network of cables. \subsection{Trigger logic decisions} There may be several possible trigger conditions, so the master trigger logic unit will have 4 (possibly 8 depending on space) logic modules operating in parallel on the trigger information for both fast trigger and validation. Inputs will be aligned in time and then fed in parallel to the logic modules. The exact capability of the logic module can vary with the application, the simplest being just combinational logic in an electrically erasable gate array (or a RAM lookup table), with some sort of gate and delay circuit (or maybe a fixed monostable) on the output to fix the fast trigger/validation pulse width. More complex decisions can be made with additional gate and delay units for example to look for a recoil particle a fixed time after detecting a gamma ray interaction. The i/o specification, pinout, and programming method for the logic modules will be specified so that special units may be easily produced to cope with unusual trigger conditions. The Fast Trigger Logic Modules each generate a Fast Trigger Request to the fast trigger generation unit which will latch the pattern of requests when it generates a fast trigger for later use by the validation logic. \subsection{Summary} The master trigger logic unit will comprise the sections described above (see fig 1): \marginpar{{\em Changed rev~2.0}} \begin{itemize} \item Analogue comparators with programmable thresholds for Ge and BGO multiplicity checks. (2 summing nodes for Ge, one for BGO plus one spare, each of these four nodes having 4 comparators) \item Logic inputs with time alignment from front panel connectors, 12 for fast trigger (plus the 4 sumbus decisions) and 8 for validation plus up to 8 fast trigger signals. \\ {\em Time align all or some inputs?}\\ The front panel inputs will have many uses such as using beam timing pulses in trigger decisions or accepting a signal from the autofill to say that the dewars are being filled and so data acquisition should be temporarily halted to prevent the collection of data corrupted by microphonics. \item Logic modules to operate on time aligned logic inputs and generate fast trigger or validation signals. (Total 4, maybe 8, with half used for fast trigger and half for validation.) \item Infrastructure comprising bus interface logic, diagnostics etc. \item 4 ADCs to code the multiplicity from the 4 sumbuses. \end{itemize} \section{Trigger System Signal Definitions} The following signals are passed within the distributed trigger system and illustrated in the diagrams fig 2 and fig 3: \subsection{CFD analogue multiplicity outputs} These signals are sourced by the Ge or BGO channels onto the VXI backplane \marginpar{{\em Rewritten rev~2.0}} sumbuses and used to count coincident hits on either the Ge channels or the BGO channels. Each active channel sources 1mA for a programmable period which must be long enough to cover the worst case Ge-Ge skew time (typically 50-100ns) plus the comparator resolution period for the Ge sumbuses and the worst case BGO-BGO skew plus comparator resolution time for the BGO sumbus. These outputs, along with the response time of the master trigger logic unit, define the coincidence window. The signals are controlled from the Ge and BGO cards and must be aligned by a CFD output delay so that the only Ge-Ge skew is introduced by the charge transit times in the Ge detectors. The master trigger logic unit will fan in buffered versions of the sumbuses from all crates to comparators. Buffered analog sumbuses are front panel inputs to the master trigger logic unit. The sumbus will be buffered in each Ge/BGO crate by the Slot~0/RM module. \subsection{Fast Trigger} This signal is generated by the master trigger logic unit in response to inputs according to a user defined set of checks and logic functions. Typically these checks would be only multiplicity, maybe in coincidence with some machine parameter such as beam bunching or polarization state. The signal must be sent over matched path lengths to all crates and distributed via the VXI STARX lines to every module. This means that it must be routed via the Slot~0/RM module in every crate. There are two effects of the fast trigger within the Ge or BGO channel: one is to stop a TAC which was started when the channel's CFD fired, hence the need for good matching, and the other is to logically include that channel in an event if it is present at the start of that channel's fast trigger acceptance window. The back edge of the fast trigger pulse will be used to stop TACs so that we \marginpar{{\em Changed rev~2.0}} can include short lived isomers in an event and distinguish them later with TACs within a relatively long fast trigger window. Using star lines and matched cables means that the fast trigger arrives at all channels with a skew of under 2ns from channel to channel although pulse to pulse variation within a channel will be much less. (2ns STARX skew is the limiting factor.) The fast trigger also has the logical function in a Ge/BGO channel of including that channel within the event provided it is present at the start of the channel's fast trigger acceptance window (see 7.5). The logical inclusion means that the \marginpar{{\em Changed rev~2.0}} channel may progress to conversion when pulse shaping is complete. (But see also section 7.3.1, Coding Validation) Within the master trigger logic unit, in common deadtime mode the production of a fast trigger inhibits the production of any further fast triggers until either the end of readout or a failed validation. This is indicated by the Eurogam defined VXI inhibit line which will be driven by the master trigger logic unit. In parallel or pipelined mode the generation of the next fast trigger will be limited only by the validation window width or the internal recovery time of the master trigger logic unit, whichever is the greater. The timing limits are defined by the Ge-Ge resolving time at the earliest, and the end of the TAC range (2$\mu$s) at the latest. In practice the coincidence of Ge's will be the main trigger criterion so the fast trigger will normally be generated within a few hundred ns of the $\gamma$-ray interaction. Pulse width is programmable in conjunction with the Ge/BGO trigger acceptance window such that the front edge of the window falls within \marginpar{{\em Changed rev~2.0}} the fast trigger pulse with defined setup and hold times (min 5ns). The back edge of the fast trigger pulse must come before the end of the fast trigger window. {\em Note the changes here: the back edge is used to stop the TAC instead of the front so that we can extend the fast trigger for isomers up to 2$\mu$s and still use TACs to find out what is happening. The change in the windowing to overlap the back edge of the fast trigger enables us to match fast triggers to channels at the time when the TAC is stopped.} The fast trigger is also available to non-VXI devices where its meaning is that an event of some type has occured and might be collected after some further checks. \subsection{Validation} There are now two types of validation: coding validation and readout \marginpar{{\em Changed rev~2.0}} validation although the two are mutually exclusive, using the same line but different timing. In both cases the validation pulse is generated by the master trigger logic unit and it always means that readout will take place for the event being validated. The signal is distributed via the Slot 0/RM module in each crate. It is not time critical and so will use one of the TTLTRIG lines. The validation signal is available to non-VXI equipment. In this case its meaning is that readout will take place as soon as data are available in VXI crates and so the non-VXI equipment should organise its own readout for the current event. Each event is labelled with a 4 bit event number when it is validated so that it can be identified in a parallel trigger system. All four VXI local bus event number lines will be used for event tagging because 4 VME address lines are used during readout to identify the event being read. \subsubsection{Coding Validation} Coding validation is a validation between the fast trigger signal and the \marginpar{{\em Changed rev~2.0}} peaking time of the shaped pulse. It means that the event will be coded and also that readout will take place. It is a decision which is typically made on a 2$\mu$s timescale on such information as the presence or absence of a recoil fragment in the RMS. If the checks prove that the event is not interesting then no validation pulse is produced and the Ge/BGO channels included in the event will timeout in their validation acceptance window (see 7.6). Coding validation replaces the old Event Reject signal which is no longer used in Eurogam. It has the advantage of being compatible with the parallel and/or pipelined upgrade. The timing constraints are that the earliest start of the coding validation pulse must come after the fast trigger and there must be a period of at least 500ns between the end of the fast trigger and the start of the coding validation. The end of the coding validation pulse must be before the end of the Ge PDS gate. Timing is that the front edge of the validation acceptance window must come within the the validation pulse with defined setup and hold times (min 100ns). {\em Note that this is different to the timing on the fast trigger and its window because we use a daisy chained TTLTRIG line to send the validation instead of a fast star connection.} \subsubsection{Readout Validation} Similar to coding validation except that it takes place after the shaped pulse \marginpar{{\em Changed rev~2.0}} has peaked and it has no effect on coding. The timing constraints are that it must start after the end of the PDS gate and it must end before the end of coding. Timing is that the front edge of the validation acceptance window must come within the the validation pulse with defined setup and hold times (min 100ns). {\em Note that this is different to the timing on the fast trigger and its window because we use a daisy chained TTLTRIG line to send the validation instead of a fast star connection.} \subsection{Readout Complete} This signal is used in common deadtime mode only. It is a high active open collector type signal from all slot~0/RM controllers, and any non-VXI equipment involved in data collection, to the master trigger logic unit. In fact there are two physical signals which can \marginpar{{\em Changed rev~2.0}} perform the logical function of indicating readout complete; the `donn\'{e}es \`{a} transmettre' line or the `fin de codage' line. Which is used depends on whether the Ge cards are operating in the mode where all data is removed from the Ge card before the next event may be started, or the mode where the next event may start as soon as all the card's data are in the FIFO on the Ge card. Both these signals exist on the VXI backplanes and are buffered via the slot~0/RM modules to the master trigger logic unit. In common deadtime mode the master trigger logic unit will wait for the end of which ever line is programmed to mean readout complete (software selection of either `donn\'{e}es \`{a} transmettre' or `fin de codage') before allowing the next event. In parallel or pipelined mode the next event may start as soon as it can be recognised and processed unambiguously which means that it is governed either by the fast trigger resolving and recovery time or the width of the validation window. There is no interaction with crate readout in these cases, but the master trigger unit will stop generating new triggers while the Inhibit line is asserted in any VXI crate by either a readout controller with no spare event buffer space (i.e. containing 16 events) or by a Ge or BGO card which has a full pipeline and cannot accept another event. \subsection{Fast trigger acceptance window} This is a time window defined in each Ge/BGO channel during which that channel is waiting for a fast trigger. At the start of the window the front edge is used to sample the state of the fast trigger pulse on the VXI STARX line and if it is present then the channel is included in the event and can convert the input it is shaping. If there is no fast trigger pulse when it is sampled the channel allows the amplifier to return to baseline with no further action. The start of the window is defined by a programmable delay (0 to 2$\mu$s in 10bits) from the CFD detecting an input, and the width must be programmed in conjunction with the fast trigger pulse in the master trigger logic unit so that the back edge of the fast trigger pulse which stops the TACs is included inside the fast trigger acceptance window. \marginpar{{\em Changed rev~2.0}} Absolute maximum is the end of the TAC range (2$\mu$s) but typical value is a few hundred ns. The initial Eurogam Ge cards will not implement the full window, just a single sampling point equivalent to the front edge. The Fast trigger acceptance window and the CFD pulse width will both be programmed on a per card basis. \subsection{Validation acceptance window} This window is very similar to the fast trigger acceptance window and will also be programmed for width on a per card basis. It is timed from the CFD \marginpar{{\em Changed rev~2.0}} firing initially using a ramp generator in the Ge and BGO cards. Timing is programmed from 0-10$\mu$s in 10 bits on a per card basis. There is also a software flag to tell the local trigger in the Ge/BGO cards whether the validation is a coding or readout validation. The front edge of the window pulse samples the validation pulse, the presence or absence of validation indicating readout or abandonment of event respectively. Note that the initial Eurogam Ge cards will not implement the full window, just a single sampling point equivalent to the front edge. \subsection{Clear} There is no clear signal. The reason is that the trigger system is distributed and self timing. In the case of VXI modules the question of clearing does not arise because all channels will fail (or be aborted) at the end of either the shaping or readout phase or else successfully complete to readout; in any case an explicit reset is not required since the amplifier/gated integrator is effectively free running, the ADC returns to a sensible state after conversion and the readout register is overwritten by successive words. TACs are self clearing too. There is, however, a VXI `Initialise' signal to facilitate recovery from error conditions \marginpar{{\em rewritten rev~2.0}} (such as timeouts) which stops all activity and resets everything. \section{Non-VXI devices supplying data} In order to accept data from non-VXI devices such as Camac FERA ADCs or the Daresbury High Efficiency Recoil Mass Separator with its NIM ADCs plus NIM-FERA converters, we must use the common readout complete signal between the master trigger logic unit and the non-VXI readout controller. The non-VXI readout controller must also \marginpar{{\em rewritten rev~2.0}} incorporate the derandomising buffers used in the VXI readout controllers. Alternatively the non-VXI devices may be interfaced via simple VXI cards which would feed into the VXI backplane readout instead of the DT32 readout. For non-VXI devices it may sometimes be necessary to generate a local `clear' signal (e.g. for NIM ADCs), and this could be derived from the back edge of the wired `or' readout complete signal. This would need a timeout in case readout did not take place. The fast trigger and validate signals will be available to non-VXI devices, but the timing may not be very helpful in generating ADC gates etc. {\bf All non-VXI timing is the responsibility of the user.} \section{User triggers} The user may use the CFD and LE discriminators on each Ge/BGO channel to construct complex triggers using CFD timing and LE energy thresholds. These may be either validations or fast trigger inputs. The master trigger logic unit will accept 12 front panel inputs for fast trigger and 8 for validation. In both cases the logical function to be performed on these inputs and the analogue multiplicity comparator is programmable. In addition the analog summing nodes will be available via LEMO outputs from \marginpar{{\em Changed rev~2.0}} the Master Trigger Logic unit for use by users. \section{Compton Suppression} Compton suppression takes place in two stages. Most of the benefit can be obtained by using just the immediate shield around the Ge as a veto, but an even better peak/total can be achieved with shared suppression using a second and third ring of BGO elements. Hardware Compton suppression is performed by physically placing Ge and BGO \marginpar{{\em Changed rev~2.0}} cards adjacent in VXI crates (in pairs for coaxial Ge or triplets for stack Ge). The veto signal generated by each shield is passed over the VXI local bus (with the facility for a duplicated front panel connection) and may, under software control, disable the local trigger of vetoed Ge's. The veto is always used to generate a clean Ge multiplicity. Shared suppression is performed later in software using the bit patterns collected from the BGO cards of hits in each shield. \section{Data supplied by trigger system to readout} The master trigger unit will supply the following information during backplane readout: \marginpar{{\em Changed rev~2.0}} \begin{itemize} \item Event Header, including at least 4 bits of event number %\item Real Time timestamp (64 bits; programmable to 100ns or 1$\mu$S %resolution) \item Optionally Fast Trigger and Validation type number from each logic module in the trigger card. \item Optionally up to 4 multiplicities coded with ADC from sumbuses. \item Optionally data from trigger TDCs \end{itemize} N.B. Since these data words, including the event header, are supplied via the \marginpar{{\em rewritten rev~2.0}} normal VXI backplane readout process it places 2 very important restrictions on the master trigger logic card: \begin{bf} \begin{itemize} \item The trigger card must be in the first crate to be read on the DT32 chain. \item It must be the first device to be read over the backplane within its crate. \end{itemize} \end{bf} This will mean that the crate containing the master trigger logic card will have its normal slot~0/RM card in slot~0, the Readout Controller in slot~1, and the trigger card in slot~2, leaving slots 3 to 12 for Ge/BGO cards. Failure to observe these restrictions will mean that the data stream will no longer start with an event header! \section{Diagnostics and monitoring} It is important that the users are able to check exactly what the trigger system is doing. The main monitoring facility will be by VME accessible scalers measuring the following: \begin{itemize} \item Fast Triggers \item Validations (Slow Triggers) \item Fast Triggers rejected while busy (per logic module) \item Fast Triggers accepted (per logic module) \end{itemize} \section{Additional features} During discussion of trigger requirements several new features have come to \marginpar{{\em rewritten rev~2.0}} mind. This section will describe those features and if there is sufficient interest from physicists the features will be incorporated. The first two features arise from discussions of isomer experiments. One possibility is to measure energy from a short lived (under 1$\mu$s) isomer by having effectively two fast triggers, the second being armed by the first. The second trigger would be programmed to look for the isomer by looking for, for example, one or two gamma rays (or anything in an inner ball detector) within the expected isomer lifetime. This will only work for short isomer lifetimes because of randoms problems (is it really an isomer). The additional detecting elements would respond to the second fast trigger (using the STARY lines) using a second trigger window in the Ge cards set slightly later than the first. Obviously this will complicate the Ge cards and the trigger system, but if it allows new or interesting physics then it might be worthwhile. {\em No interest shown so no further work done. Probably too late to incorporate the changes in the Ge cards by now (4th July)} The second feature is the inclusion of TDCs in the master trigger logic unit. These would overcome the fixed TAC start/stop limitations in the Ge cards, having access to all the signals at the trigger logic unit (Ge front panel CFD/LE signals, beam timing, fast trigger(s), multiplicity etc.). They could perhaps be started and stopped by logic modules similar to those used for fast trigger generation. They would be simple counter style TDCs which would probably have a resolution of between 5 and 10ns per bin, and a range limited only by the counter width (32 bits at 10ns = 400ms; 16 bits = 6.5$\mu$s). They could even time event separation if that were thought to be useful. They would be included in the readout only if selected. {\em Some interest shown recently so will be included in master trigger unit but if there are space problems then it will be one of the first things to be removed.} The third feature is the recording of multiplicity in the event data: there are now 4 sumbuses of which 3 are defined in VXI and the fourth is free for users to define. It will be possible to code the values of any or all of these sumbuses using ADCs. This feature will be included. The ADC will code the value at the time when the trigger is generated so for a delayed fast trigger such as would be used in an isomer experiment it is the second, typically much lower, multiplicity which will be recorded. \section{An example experiment} This trigger setup is shown in fig 4. \marginpar{{\em rewritten rev~2.0}} Consider an experiment where the user runs Eurogam with the Daresbury high Efficiency Recoil Mass Separator (RMS). A typical trigger condition might be $\gamma$-$\gamma$-recoil (after Compton suppression) but additionally we might want to collect any $\gamma$-$\gamma$-$\gamma$-$\gamma$ coincidences (also after Compton suppression) regardless of recoil particle detection. In this case the time of arrival of the `recoil present' signal will be between 0.5$\mu$s and 2$\mu$s after the event depending on the reaction. The gamma rays will arrive at the Ge's within 1~ns of the reaction. The readout of the Ge will be ready in 10$\mu$s and the readout of the recoil separator TAC's will be ready about 6$\mu$s after the `recoil present' signal (via TFA, CFD, TAC, NIM ADC and NIM-FERA converter). The fast trigger decision must be made on Ge multiplicity alone since this is the only information available initially. We will define a minimum coincidence period in the master trigger logic unit's fast trigger logic module and will arrange the CFD analogue pulse widths from the Ge channels such that they overlap for at least that period. Using hardware anti-Comptoning we have both clean and raw Ge multiplicities available for the fast trigger but we will use only the clean in this case, taking it to two different fast trigger modules, one looking for clean Ge$\geq$2, and a second for clean Ge$\geq$4 The fast trigger signal to VXI crates will be a logical OR of the two conditions and since the clean Ge$\geq$2 includes the clean Ge$\geq$4, then the clean Ge$\geq$2 will determine the rate of fast triggers. The two fast trigger conditions are latched when the fast trigger is issued and become logic inputs to the validation modules. The validation condition will now be either clean Ge$\geq$4 from the fast trigger conditions or else the detection of a recoil fragment. Both these decisions can be made well before the 5$\mu$s peaking time so we use coding validation rather than readout validation so as to stop the event as early as possible if neither condition is true. If at least one condition is true we allow coding and readout to take place. This decision can be made with the help of a timeout period, set to be slightly longer than the latest expected recoil particle. If no `recoil present' signal arrives before the timeout and the clean Ge multiplicity is not at least 4 then no validation is generated. The Ge cards and BGO cards will be programmed to look for a validation after perhaps 2.5~$\mu$s from the CFD firing and if the master trigger unit is not issuing a validation at that time then they will not allow coding and will get ready for the next event. If a validation is to be generated then obviously the master trigger unit must be programmed so that it generates a validation at the time when the Ge/BGO cards are programmed to look for it. The wait for the recoil particle must not be set any longer than necessary to avoid the problems caused by a second reaction occuring during deadtime and sending a reaction particle into the RMS which gets collected with the first interaction's $\gamma$-ray energies. The validation pulse also means that readout will take place, so the readout controllers in the VXI crates and RMS readout controller for the NIM ADCs/NIM-FERA converter know that they will take part in event readout. Each VXI card asserts the common donn\'{e}es \`{a} transmettre line and releases it after its data have been read. The status of donn\'{e}es \`{a} transmettre is buffered via the slot~0/RM card's ECLline connectors (as an open emmitter signal) from each VXI crate (and the RMS readout controller) down a single ribbon cable to the master trigger logic card. When all crates have finished readout and the ECLline donn\'{e}es \`{a} transmettre line is no longer asserted the trigger system knows that the event is complete and it may look for a new event. This state is reached after 2.5$\mu$s if the validation fails, but the amplifiers used for the failed event will not recover for another 10$\mu$s so the useful array size is reduced by at least 2 Ge channels for that period. The RMS requires a clear signal for its NIM ADCs (the TACs are Ortec 566 and will self clear). The clear can be generated from the end of the common `readout complete' signal and fed to the ADCs via the NIM-FERA converter. Alternatively if the event is not validated then the absence of a validation within a fixed time of the fast trigger may be used as a clear. \subsection{Another example experiment} This trigger setup is shown in fig 5. \marginpar{{\em Rewritten rev~2.0}} This time we will consider an isomer experiment. We might want to collect $\gamma$-$\gamma$-$\gamma$-isomer coincidences using an external isomer TAC and raw Ge multiplicity. We will assume a 60ns isomer which is to be included in the fast trigger. The signals used will be the internal sumbus comparator looking for 3 or more $\gamma$s, an external TAC and an external NIM comparator connected to the raw Ge sumbus output looking for a return to 0~$\gamma$'s followed by at least one $\gamma$ (the isomer)\footnote{It {\em might\/} be possible to put this logic in the master trigger logic unit, but this cannot be guaranteed at the moment.}. The external TAC will start with the front of the fast trigger and stop with the external comparator detecting the isomer. It will produce a logic signal from which the TAC's NIM ADC knows to convert the pulse, typically after about 2$\mu$s. This will be used as a validation test. The time is short enough to allow a coding validation. The fast trigger logic modules will act as set/reset flip flops: they start the fast trigger with a set and end it with a reset input. The fast trigger requests will be logically ORed and the pattern of Fast Trigger requests latched on the back edge of the Fast Trigger output. We will use two modules, both starting their fast trigger request as soon as the 3~$\gamma$ comparator fires. This will start the Fast Trigger pulse. The 3~$\gamma$ comparator will also be delayed by a time greater than the isomer lifetime plus the external logic propogation time as a timeout and this will feed one reset in the first logic module. The first logic module will be reset by the logical OR of this timeout and the detection of an isomer by the external comparator. This `isomer detected' logic input must be delayed so that the fast trigger pulse remains long enough for the Ge channel with the isomer to include itself in the event. The second logic module will be reset by a direct (non delayed) version of the `isomer detected' logic signal or the timeout. Since the Fast Trigger output is the logical OR of the fast trigger inputs, the later of the two to be removed will define when the pattern is latched, so if we see an isomer the logic module 1 will define the time and the pattern will contain only logic module 1 since module 2 was reset by a non-delayed version of `isomer detected'. If there was no isomer then the two would be reset together by the timeout and both would be in the pattern. Thus we can distinguish an isomer from a timeout in the validation phase. The latched pattern and the TAC logic signal are available for a decision 2$\mu$s from the start of the fast trigger as to whether or not to validate the event. The validation condition is that only fast trigger module 1 is in the fast trigger request pattern and that the TAC logic input is true. In this case a validation is issued and we have a good event with an isomer, otherwise we start to look for the next event and leave the 3 Ge channels without converting or reading them, effectively reducing the array size by 3 for the remaining 10$\mu$s of the amplifier recovery time. \section{Electrical and Mechanical Connections} \subsection{Electrical Connection} All digital \marginpar{{\em Changed rev~2.0}} signals will be 10K series ECL, using normal 10K series thresholds on the ECLline cables, and fast NIM for the external logic inputs and trigger outputs. The analog sumbus signals will be 1mA per channel for both BGO and Ge, up to the maximum defined in the VXI specification (520mA, but note there is a voltage limit of $\pm 3V$ and two 50$\Omega$ terminations which means there is no point in using more than 120mA). \subsection{Mechanical Connection} Fast trigger signals are distributed and analogue sumbuses received in a star topology with the master trigger module at the hub of the network and a path of equal delay from the hub to every backplane via their slot~0/RM module. The fast trigger signals all travel as single ended signals over coaxial cable using 1 pin LEMO sockets to the Slot~0/RM unit from the master trigger logic unit. The Master trigger logic unit will have 8 outputs for the fast triggers (8 crates). The analogue multiplicity inputs and outputs will be 1 pin LEMO sockets to accept 1 pin LEMO plugs mounted on the end of coaxial cable. There will be 8 inputs from which raw Ge multiplicity is calculated, 8 for clean Ge multiplicity, 8 from which BGO multiplicity is calculated and 8 spares for such things as the BGO inner ball. (8 allows up to 8 crates in the star formation.) The remaining control \marginpar{{\em Changed rev~2.0}} signals are bussed over 2 ribbon cables; one ECLline cable for the output signals (validation, event number, inhibit, test synchronisation), and one ECLline cable for input signals (donn\'{e}es \`{a} transmettre, fin de codage, inhibit). Both these ECLline cables will be multi-drop flat cables to or from each each Slot~0/RM module. These signals will connect to each crate only once, through the slot~0/RM card, for ease of cabling and to prevent excessive loading. Non-VXI crates may also connect each ECLline cable to only one module for the same reasons. The trigger and validation logic inputs to the master trigger logic unit's front panel will use 1 pin LEMO sockets with fast NIM signal levels. The CFD+Leading edge discriminator signals from Ge cards will use 16 way IDC \marginpar{{\em Changed rev~2.0}} cables, one for LE and one for CFD signals.\\ {\em Is there a viable alternative to Lemo 00 connectors?} \section{Interface with Ge card} All signals travel via the Slot~0/RM card and the VXI backplane except where \marginpar{{\em Rewritten rev~2.0}} noted. \subsection{Signals output from Trigger System to Ge} \begin{itemize} \item Fast Trigger Pulse (STARX) \item Validation Pulse (TTLTRIG6 Validation line 3) \item Event number (LBUS 8-11) \end{itemize} \subsection{Signals received from Ge by Trigger System} \begin{itemize} \item Raw Ge analog multiplicity level (SUMBUS) \item Clean Ge analog multiplicity level (LBUS0) \item CFD Logic pulse (Front Panel, 1 per Ge channel) \item Leading edge discriminator pulse (Front Panel, 1 per Ge channel) \end{itemize} \subsection{Programmable timers etc. required by trigger system inside Ge card} \begin{itemize} \item Width of Fast Trigger acceptance window / Fast trigger sample point \item Width of CFD pulse/VXI Sumbus current pulse \item Width of Validation acceptance window / Validation sample point \item Validation Type \item DAC for CFD trigger level \item PDS Gate width \item Local Bus Veto disable \item Pileup reject/mark event \end{itemize} Further details will be found in the Ge specification.\ In addition to these timers there is also a requirement that the Ge card provides logic using the timers in the way described in this document. \section{Interface with BGO card} {\em This section depends partly on exactly what the BGO card will do and \marginpar{ Rewritten rev~2.0} contain. It will be revised when a BGO specification is written and available.} \subsection{Signals output from Trigger System to BGO} \begin{itemize} \item Fast Trigger Pulse \item Validation Pulse \item Event Number \end{itemize} \subsection{Signals received from BGO by Trigger System} \begin{itemize} \item Analog multiplicity level (LBUS1) \end{itemize} \subsection{Programmable timers etc required by trigger system inside BGO card} \begin{itemize} \item Width of Front Panel CFD pulse \item Width of Fast Trigger acceptance window \item Width of VXI Sumbus current pulse \item Width of Validation acceptance window \end{itemize} In addition to these timers there is also a requirement that the BGO card provides logic using the timers in the way described in this document. \section{Interface with Readout card} All signals sent between the readout controller and the master trigger logic \marginpar{{\em Rewritten rev~2.0}} unit will pass via the VXI backplane and the Slot~0/RM module. \subsection{Signals output from Trigger System to Readout Card} \begin{itemize} \item Validation (TTLTRIG6) \item Event Number (LBUS8-11) \end{itemize} \subsection{Signals received from Readout card by Trigger System} \begin{itemize} \item Fin de codage or Donn\'{e}es \`{a} transmettre (TTLTRIG0/1)\\ (To be used if the readout controller buffer has just read its 16th event and so has no room for another event. In this case whichever of the 2 lines is in use as 'readout complete' should be held by the readout controller until it can accept another event. This will prevent further triggers in common deadtime mode.) \end{itemize} \subsection{Logic and timers required inside Readout card} The trigger system expects that the Readout card will use the Validate pulse to initiate readout as soon as it is possible. The Readout card must accept this initiation of readout during, or even before, the ADC conversion phase without losing data. This assumes FERA style REN/PASS operation and that the Ge/BGO cards block REN during conversion. The trigger broadcasts 4 event number bits and expects the readout controller to use some other mechanism such as VME address lines to identify events during readout, and to contain a 16 event buffer. If this operation is not implemented the readout controller must still look to the trigger system as if it is implemented! \section{Interface with Slot 0/RM card} \marginpar{{\em Rewritten rev~2.0}} \subsection{Signals output from Trigger System to Slot 0/RM card} \begin{itemize} \item Fast Trigger Pulse (for distribution on backplane, STARX) \item Validation Pulse (for distribution on backplane TTLTRIG6) \item Event Number (for distribution on the backplane LBUS8-11) \end{itemize} \subsection{Signals received from Slot 0/RM card by Trigger System} \begin{itemize} \item Buffered analog sumbuses (3) (SUMBUS, LBUS0, LBUS1) \item Fin de codage (TTLTRIG0) \item Donn\'{e}es \`{a} transmettre (TTLTRIG1) \end{itemize} \subsection{Logic and timers required inside Slot 0/RM card} No logic or timing is required of the Slot~0/RM card, but it must be designed such that board to board variation in timing from the front panel Fast Trigger input to the VXI STARX lines is less than 2ns (this is in addition to the 2ns slot to slot skew allowed in the VXI specification for STARX distribution over the backplane). All trigger signals in and out of the VXI crate will be routed via the Slot~0/RM card (except Ge/BGO front panel CFD and LE signals for user triggers). \section{Interface with non-VXI equipment} \subsection{Signals output from Trigger System to non-VXI equipment} \begin{itemize} \item Fast Trigger \item Validation (start readout when ready) \item Event Number \end{itemize} \subsection{Signals received from non-VXI equipment by Trigger System} \begin{itemize} \item `Readout complete' (Wired OR) \item Input(s) to Fast Trigger logic decision \item Input(s) to Validation logic decision \end{itemize} \subsection{Logic and timers required inside non-VXI equipment by Trigger System} There is no specific requirement for logic or timers but some more general points must be observed. The first is that the non-VXI equipment must timeout and clear itself in the absence of an expected Fast Trigger: there is no centrally generated clear in the proposed distributed trigger system other than the event rejection signal. Secondly the non-VXI equipment must negate whichever of `fin de codage' and donn\'{e}es \`{a} transmettre is used to indicate `readout complete' in response to Validation if it has data to be included as part of the current event, and it must release `readout complete' when the data are successfully read. \newpage \begin{verbatim} +------------+--+-----------+--------------------+------------+----------+ | Two |T | | | | VME i/f | | Front Panel|I | 8 | Logic Module(s) | | for +--+ | 34 way i/p +M |-/---------+ for Validation | | setup | | | |E | latched | (minimum 4) | | control | | | 8 for | |ftrequest 8| | | testing |P1| | Validation |A | -----/-+ +----+ | | | | and 12 +L |-+ | | | | | | | Fast Trig. |I | | +--------------------+ | | | | | logic i/p's|G | | | +-+-----+--+--+ +------------+N | | +--------------------+ | | | | | |M | | | | | +--+ | | | Analogue |E | | 12 | Logic Module(s) | | | | +--+ |Multiplicity|N | +---/-----+ for Fast Trigger | | | +--+ | | inputs and |T | | (minimum 4) | | | | | | comparators|& | 4 | | | | |P2| | +D-|-----/-----+ +--+ | | | | |8 Ge inputs |E | | | | | | | | |8 BGO inputs|L | +--------------------+ | | | | | | |A | | | | +--+ | |Y | | | | | +------------+------------+ Fast Trig req. 8 | | | | | Outputs | |<------------------/-----+ | | +--+ | | Control | Validation req. 8 | | | | |Fast Trigger| Logic |<------------------/-------+ | | | |Validation | | | |P3| |Event reject| | | | | | 8 o/p each | | | | | |time aligned| | 6 +------------------+-+ | | +------------+ +---------/---->| Scalers for | +--+ |inputs | | | Monitoring | | |rdout comp | | | (VME readable) | | +------------+------------+---------------+--------------------+---------+ Fig 1 Temporary Block Diagram of Master Trigger Logic Module ------------------------------------------------------------- \end{verbatim} \newpage \begin{verbatim} time in us 0 2 5 10 15 ---------- | | | | | Event starts * | | | | | | | | | Fast trigger | | | | | allowed here ********* | | | | | | | | Coding | | | | | validation | ************* | | allowed here | | | | | | | | | | Readout | | | | | validation | | ********************* | allowed here | | | | | | | | | | +-------+-----------+-------------------+-------------------+ For BGO |Shape | Convert |Await Ge conversion| Readout phase | +-------+-----------+-------------------+-------------------+ For Ge | Shaping phase | Conversion phase | Readout phase | +-------------------+-------------------+-------------------+ ------> ------> permit conversion(Ge) permit readout Permit conversion = Fast trigger (if using readout validation) (Ge) OR Fast trigger AND validation (if using coding validation) Permit readout = end of conv. AND validation (if using readout validation) (Ge) OR end of conversion (if using coding validation) For BGO Permit conversion = Fast trigger Permit readout = Delayed (end of conversion AND validation) (In the absence of a new BGO spec I am assuming that the BGO card uses the ADS 7800 3microsecond ADCs described in the latest version I have.) Fig 2 Overview of Trigger System timing --------------------------------------- \end{verbatim} \newpage \begin{verbatim} STOP TAC \/ Fast Trigger __________ _________________ \___________/ Fast Trigger ________________ ______ Acceptance Window \______________/ Setup time (min 5ns) ***** Hold time (min 5ns) ***** /\ Channel in/out of event decision Validation ______ _____________ \_______________/ Validation ________ ______ Acceptance window \________________/ Setup time (min 100ns) ********* Hold time (min 100ns) ******** ALL SIGNALS SHOWN ACTIVE LOW Figure 3a Detail of Eurogam System Trigger Timing ---------------------------------------------------- \end{verbatim} \newpage \begin{verbatim} STOP TAC \/ Fast Trigger __________ _________________ \___________/ Fast Trigger ________________ ____________________ Acceptance Pulse \/ Setup time (min 5ns) ***** Hold time (min 5ns) ***** /\ Channel in/out of event decision Validation ______ _____________ \_______________/ Validation ________ ___________________ Acceptance pulse \/ Setup time (min 100ns) ********* Hold time (min 100ns) ******** ALL SIGNALS SHOWN ACTIVE LOW Figure 3b Eurogam Initial Trigger system using sampling, not windows ---------------------------------------------------------------------- \end{verbatim} \newpage \begin{verbatim} +--------------+ Clean +-------+ +----------+ +-------+ | Sumbus | 4 Ge | 0 dly | | FT logic | | | | Comparators +------->|-------|----->| module |FT req 1 |Fast | | | Clean | 0 dly | | no. 1 +--------->|Trigger| | +------->|-------|--+ | | |Circuit| +--------------+ 2 Ge | | | +----------+ | | Fast | Time | | | +--------> | Align | | | | Trigger | or | | +----------+ | | | Delay | | | FT logic | | | | | +-->| module |FT req 2 | | | | | no. 2 +--------->| | | | | | | | | | +----------+ +-------+ | | |FT reg | | | +-+---+-+ | | Latched FT requests 2| 1| | | +---------------------------+ | | | | +-----------------------------+ | | | | +----------+ +-------+ | | | | |Validation| | | | | | +>| logic |Val req 1 | Val. | | | | | module +--------->|Circuit| | | | | no. 1 | | | | | | +----------+ | |Validate | | | | +--------> | | | | | | | | +----------+ | | | | +-->|Validation| | | Recoil detected (logic) | 0 dly | | logic |Val req 2 | | ----------------------->|-------|----->| module +--------->| | | | | no. 2 | | | +-------+ +----------+ +-------+ Validation req 1 = FTR1 Validation req 2 = (FTR2) & (Recoil detected) Figure 4 Example Experiment to detect either 4 clean Ge or recoil gamma-gamma ----------------------------------------------------------------------------- \end{verbatim} \newpage \begin{verbatim} S (set) = start pulse R (reset) = end pulse +-----------+ +-------+ +----------+ +-------+ |Sumbus |Raw | 0 dly | S| FT logic | | | |Comparators+-----+->|-------|-----+-->| module |FT req 1 |Fast | | |3 Ge | |1us dly| | R| no. 1 +--------->|Trigger| | | +->|-------|-+------>| | |Circuit| +-----------+ | 300ns | | | R| | | | Fast +->|-------|-------->| | | +--------> | | delay | | | +----------+ | | Trigger | | | | | S+----------+ | | | | | | +-->| FT logic | | | Isomer detected | |0 dly | | R| module |FT req 2 | | ------------------+->|-------|-------->| no. 2 +--------->| | logic pulse from | | | R| | | | ext. discriminator | | +------>| | +-------+ | | +----------+ |FT reg | | Time | +-+---+-+ | align | Latched FT requests 2| 1| | or | +-------------------------------+ | | delay | | +---------------------------------+ | | | | +----------+ +-------+ | | | |FTR1 |Validation| | | | | | +---->| logic |Val req 1 | Val. | | | | FTR2 | module +--------->|Circuit| | | +------>| no. 1 | | | TAC output OK (logic)| 0 dly | | | | |Validate -------------------->|-------|-------->| | | +--------> (maybe SCA?) | | +----------+ | | | | | | | | | | | | | | +-------+ +-------+ Validation = (FTR1) & (NOT FTR2) & (TAC_OK) Figure 5 Example Experiment to detect an Isomer after gamma-gamma-gamma ----------------------------------------------------------------------- \end{verbatim} \end{document}