Modelisation of control of SuperB Common Front-End Electronics

1. Modelisation of control of SuperBCommon Front-End Electronics Christophe Beigbeder, Dominique Breton, Jihane Maalmi

2. Constraints concerning the Trigger • Trigger window : • Long latency (~ 5 µs ?) + jitter, due to machine and detector constraints, • >> potentiallly large trigger window (1µs max) for data readout - The Trigger Window could be reduced depending on the sub-detector in order to optimize the dataflow: • It should be fixed but programmable in the FEE • Consecutive Triggers : • - No minimum distance fixed at the architecture level. • - Min ~ 100 ns (highly probable) due to the time precision of trigger. • - No limitation fixed for their number in a burst. • => Those constraints should only depend on the trigger system itself • Problems : • - Two consecutive physics events may reside within the trigger time window (overlapping). • - For detectors with slow signals (like EMC barrel), physics events may sit on the queue of large background events (pile-up) • FEE should be able to deal with close triggers (Overlapping), and send data in consequence (reducing the size of posterior events) Jihane Maalmi - CERN - November 09th 2009

3. General Architecture proposed for SuperB Electronics Jihane Maalmi - CERN - November 09th 2009

4. Simulation of synchronous model • The FCTS sends a L1 trigger command optionally associated with a value corresponding to a time window. The FEE sends to the DAQ (ROM) the data contained inside a readout window, embedded in a frame including status, trigger tag and time, and length of data field. • Trigger is defined by three parameters: • - The latency: L (fixed in the FEE) • - The readout window: W (fixed in the FEE and sub-detector dependent) • - The time distance between triggers: D (measured in the FEE) • Constraints : • - No dead time in data processing • - Triggers with overlapping windows

5. Parameter Definition t0 L1 Trigger #0 Data to keep Data to dump L W Time M Baseline: latency pipeline always provides the oldest relevant data L: fixed latency W: window containing the relevant data for trigger #0 M: data sent to ROM Jihane Maalmi - CERN - November 09th 2009

6. Synchronous Model with a fixed readout window L : Latency W : Window D : Distance between triggers M : data sent to ROM Case 1 : D ≥ W Trigger #0 Trigger #1 D Non overlapping latencies with 2 different windows (green): no problem M1 = W L D ≥W W W M0 M1 Trigger #1 Trigger #0 Overlapping latency trigger with overlapping windows: trickier … The window W1 is then shortened! M1 = W – (W – D)= D Case 2 : D < W D W M0 W M1 Jihane Maalmi - CERN - November 09th 2009

7. M U X Synchronous Model : Dealing with Overlapping Case 1 : Dn ≥W : Mn = W Case 2 : Dn < W : Mn = Dn Mn : amount of data to send to ROM for trigger #n Trigger input Counter Dn Dn ≥ W? Clock 56 MHz W Fifo “M” !empty Mn FSM W end W enable Mn Counter Registers L L Start_flag, Mn Rd Clk to serializer Wr Clk Wr_en Latency Pipeline Data output Data input EVT_BUFFER Fixed Latency => Writing and reading Clock of the latency pipeline must be identical! 7 MHz for Barrel EMC, 14 MHz for Forward EMC, 28 MHz for DCH, 5-10 MHz( ?) for SV T

8. Event Reconstruction (ROM or PC?) wr_add rd_add Wr_en Rd_en Data from FEE Dataout from RAM RAM Event Data Dataout to serialiser Start_flag rd_add Go_back New_Start_flag Manager mn New_Go_back New_mn wn New_wn wr_add Jihane Maalmi - CERN - November 09th 2009

9. Verilog behavioral simulation results (1) 1- General view 2- single trigger

10. Verilog behavioral simulation results (2) 3- Overlapping case 4- Go back in time case + overlapping windows

11. Verilog behavioral simulation results (3) 5- Overlapping burst

12. Conclusion • This solutions seems to cover all the requirements. • Assuming that the L1 central trigger processor is able to easily produce triggers with a “fixed” latency: • - Like in Babar, the only necessary information to send to the FEE is the trigger tag (a few bits). • - This solution permits dealing with event overlapping and backing up in time.