Specification for MuID Variable Delay

Vince Cianciolo, ORNL

Since MuID is a LVL1 trigger detector the struck-tube bit pattern for a given event must be valid at the corresponding beam clock edge. There are three possibilities for the timing distribution of the hits relative to the beam clock. These are illustrated in figure 1 below.

Figure 1. This figure illustrates the three different possibilities for the timing distribution of MUID hits relative to the beam clock. The trigger input at each beam clock will be the bit pattern valid at that beam clock. See text for description.

Referring to figure 1:

Case #1: All hits belonging to one interaction arrive within a time window shorter than the beam cycle. This is the ideal case - the hits edge-encode a series of flip-flops that are interrogated at the following beam clock edge.
Case #2: The hit time distribution is wider than the beam cycle, but we go with the same readout scheme as in case #1. Here the problem is inefficiency. Any hits which aren't valid until after the flip-flop interrogation will be lost. In the case of the MUID, every few nanoseconds is about a 1% drop in efficiency. There is also the problem that the late hits will show up in the next beam cycle. This level of noise should not be an issue.
Case #3: The hit time distribution is wider than the beam cycle, but the readout scheme is different. In this case we make the signals wide enough that at some point all signals from an event will be valid. We then time things so that the beam-clock edge overlaps this time. The problem here (as can be seen in the figure) is that early signals will also be valid on the previous beam tick. Since the time distribution is weighted towards early times (as I have attempted to depict) it is likely that a valid road through the MUID will trigger on two beam ticks. The earlier of these beam ticks is not the correct one, and so the data recorded when the trigger fires will be data from the previous crossing (junk!). Furthermore, that earlier trigger will block the correct the correct trigger from being accepted. Note that we cannot simply time things so that the earlier beam tick is the correct one - this would have the effect that the late hits are lost, as in case #2.

For these reasons, we feel that it is necessary to reduce the width of the hit time distribution below that of the beam clock. There are two terms which contribute to the time-difference spread for a given tube:

The largest affect is the drift time of electrons ionized by a passing particle to the anode wires in the Iarocci tubes. This is an inherent spread, virtually identical for each tube. We have taken two steps to minimize this spread. A single readout channel consists of two half-cell staggered Iarocci tubes. This ensures that a particle passing through at normal incidence will pass close to the wire in one of the two tubes. Also, we completed a gas R&D program to identify a gas which was fast, but which possessed an acceptable efficiency plateau and was relatively inexpensive and safe. A gas mixture was found, Isobutane/Carbon Dioxide in roughly equal proportions. Almost all hits are recorded within a spread of 80-90 nsec.
This spread is convoluted with the translation time of the pulse along the anode wire and with the flight time to a particular tube (for the moment we are only considering the panels in a single gap). Because the electronics end of the tubes is furthest from the interaction point, these two effects largely cancel, although not for the horizontal tubes of the central (small) panels. Both ends of these tubes are equally far from the interaction point. So in this worst case the combination of these effects will be 15 nsec.

Note that the resulting natural time spread of hits is almost the width of the beam clock gate. (Although the beam cycle is 106 nsec, we probably only get 96 nsec or so - the DMU requires signals be true for at least 5 nsec and I'm guessing that there is a similar dead spot at the beginning of the cycle for flip-flops to clear.) This forces the requirement for a rather precise match of the time between the earliest possible outputs of all tubes relative to the their DMU clock. We have proposed to satisfy this requirement by building a variable delay unit into the MuID ASIC with a maximum length of 60 nanoseconds with 15 adjustable (2-4) nanosecond steps. This delay is used to cancel out terms which don't change this natural spread for a given tube, but which do move the the earliest possible outputs of different tubes differently. The fineness of the steps is dictated by the fact that a T0 shift of 3 nanoseconds is roughly equivalent one percent efficiency. Based on a warning we received from the pCDR committee regarding skew in our long (15m) readout cables, this delay has been specified as having a per-channel adjustment.

The maximum length of the delay is given by adding a bit of a safety margin to the worst case scenario arising from the following five contributing terms:

First is different internal cable lengths and the difference in the average flight times to different tubes in a panel. Again, because the electronics are away from the interaction point, these effects largely cancel. There should be less than a 5 nsec shift between different tubes in a panel.
Second there is the difference in flight time to panels in different gaps. This is less than 8 nsec. This could in principle be canceled with careful cable-length tuning.
Third, there is the possibility of significantly different external cable lengths. Since the FEM crates are proposed to lie on the west wall, there is the possibility that the cables for the east panels would be 13 meters longer than the cables for the west panels. This would result in roughly 65 nsec of shift. We propose that all cable lengths be equalized, eliminating this contribution.
Fourth, there is the possibility that the signal cable delay time is significantly different channel to channel. We have been warned that this could be a significant effect (15 nsec) given the length of our signal cables.
Finally, there is skew inside the FEM itself from distribution of the beam clock to different readout cards. This contributes 7 nsec maximum, assuming we stick with ECL drivers and that we don't use a fancy serpentine to equalize trace lengths on the backplane.