1. Some thoughs about trigger/DAQ … Dominique Breton (C.Beigbeder, G.Dubois-Felsmann, S.Luitz) SuperB meeting – La Biodola – June 2008

2. BABAR implementation FECROM 1Gbit/s Optical links 60MHz clock Setup and control FCTS Subsystems control Setup and control 60MHz clock L1 accept Read event DAQ 16 serialized commands sent in parallel every clock cycle Same command words serialized at 60MHz (geographically dedicated lines) 16 60Mbits/s links

3. What is really specific to BABAR acquisition system : mostly the fact that the ROM is the only link to FEE, through a pair of optical fibers taking care of : 60MHz clock Encoded fast commands (L1 accept, Read_event, …) Event data readout. Parameter setup and control. Event data is not sent to ROM upon L1 accept but upon Read_event. This permits an easier handling of ROM buffers But this increases a little bit the size of buffers on the FEE Pros : simple unique bidirectionnal links between ROMs and FEE Cons : in order not to add jitter to the L1 accept, latency has to be added to the latter if one wants to interleave fast commands and detector control. We can keep the same philosophy, but we need to make it run faster. Other specificity : the trigger latency is rather long and has a certain jitter, this leading to a large (1µs) time window for data readout. The long latency is linked to the quality of the algorithms which prevent from using a L2 trigger system. Its variability is linked to the slow signals of the calorimeter crystals which don’t allow to point to a T0 with a precision better than 125ns and to synchronization with the 4MHz clock used for the EMC ADCs. BABAR implementation

4. ROM-to-FEE “global” commands last 12 clock periods. 5 bits of trigger tag are included in the L1 accept command. “Local” commands are sent on the same link. Their length can go up to 32 bits. FE elements are addressed geographically through bit position in a 16-bit word. This is fine for local commands because one avoids using address bits. But this is a huge loss of bandwidth for global commands which are sent 16 times in parallel. Seen the trigger rates in BABAR, this wasn’t a problem. Anyway, there is currently no strong reason not to change the principle of mixing commands in SuperB. FCTS architecture on FEE could get closer to that of LHC experiments, where clock and L1 accept are decoded at the end of the fiber and distributed on dedicated links to the detector electronics. FCTS-to-ROM L1 commands are the bottleneck for the L1 accept minimum spacing because of frame length (104 bits) and 60Mbit/s rate. As this is really a problem, we could use 2.5Gbits/s serialized links for FCTS- to-ROM links. BABAR philosophy

5. With the radiation, the smaller = the better for the FEE buffer size. A solution with small buffers on the FEE is better if feasible (safe storage is especially hard close to beam). Reducing L1 trigger latency might be possible with modern electronics. Using a 2.5Gbits/s link, 32 bits of command can be sent within 16ns between ROMs and FEE. This can cover both global and local commands, even including address bits. Then 2 options are feasible for distributing L1 accept to FE elements : through a single pulse (« à la LHC ») => trigger tagging has to be performed in the FEE (by sampling a counter) through a 60MHz serial command (« à la BABAR ») => takes more time but gives less work to FEE In the FEE, once data has been transferred from the latency buffer to the multi- event buffer, only the mean trigger rate has to be considered for data transfer. This offers up to 25kbit/event/link. The multiplexing ratio of the FEE towards the links will then depend on the amount of data to read per channel. It is important to know the exact amount of necessary data time slices per event for each subdetector. The Read_event command is not very expensive in terms of buffering, so if it does help on the DAQ side, it could be kept. Moving to SuperB (1)

6. The main new problem on SuperB compared to BABAR is the channel occupancy. This leads to two different types of problems : For detectors with slow signals (like EMC barrel), physics events may sit on the queue of large background events (pile-up). Two consecutive physics events may reside within the trigger time window (overlapping). The question is : can we afford keeping the fixed trigger time window in such a situation, especially if the inter-trigger minimum delay can go down to ~200ns ? Should the window be systematically larger for the EMC barrel ? This increases the mean amount of data per event. This makes the second problem worse. The window length could then be defined on a per event basis, thanks to a few bits sent with the L1 accept command. For overlapping events, FEE should be able to deal with close triggers, and send data in consequence (reducing the size of posterior events) The idea of addressing data in the ring buffer could be raised if transmission links are not able to deal with the shortest interval between successive L1 accept. This is linked to : the L1 trigger itself the number of bits transmitted in the L1 accept command. Moving to SuperB (2)

7. In terms of buffering size in the FEE : Dealing with overlapping events is free. Choosing the window length is cheap : buffer size has to take extra required window length into account. Using the Read_event command in addition to L1 accept might be costly if the requested extra buffering is large. Having an addressable ring buffer is expensive : it may almost double the buffer length requirement. In terms of complexity in the FEE : Using Read_event is free. Dealing with overlapping events is cheap : one just has to measure the distance between L1 accepts and send the corresponding time slices Choosing the window length is cheap : it’s just going farther back in the ring buffer Having an addressable ring buffer is more expensive. In terms of length of L1 accept command (and thus of transmission time) : Dealing with overlapping events is free. Choosing the window length is cheap (3 bits should be sufficient). Using Read_event has a cost in terms of link occupancy (one per L1 accept). Having an addressable ring buffer is the most expensive. Conclusion

8. Example of possible SuperB implementation FECROM 2.5Gbits/s Optical links 60MHz clock L1 accept Read event Setup and control FCTS Subsystems control Setup and control 60MHz clock L1 accept Read event DAQ 1 32-bit command word every clock cycle Same command word serialized at 60MHz (dedicated or broadcasted) 16 ? Max jitter << 100ps