Agenda for LHCb Trigger meeting Sep 16.
Agenda for the trigger session during next LHCb week: Sep 16, 9:00h, 160-1-009.
09:00 - L0 decision box: Pascal Perret (15) - A Hardware implementation for the LHCb l0 electron and hadron trigger: Marco Bruschi (30) - L0 muon algorithm: Renaud Le Gac Renaud: (15) - Discussion on how to proceed with L0: Hans Dijkstra (30) ***coffee*** 11:00 - Pile-up events: Mike Koratzinos (20) - Summary of L1 vertex workshop July 22: Pere Mato (20) (to be confirmed) - Simulation and architectural studies for custom implementation of the L1 vertex switch: Oleg Bouianov (20) - Summary of meeting on L1-vertex August 8: Hans D. (10) - Discussion on how to proceed with L1: Hans D. (30)
Discussion on how to proceed for L0: Proposal: I would like one/two persons to collect all info on a certain subject, compare to Atlas/CMS where applicable, look at all our implementation approaches for that specific subject, present their findings to the collaboration and write a note about it. This way we collect a stack of written reports which will allow us to define our requirements and hopefully make an implementation choice based on published notes. At the next trigger meeting (Sep 16) I would like to discuss if people think this is the right way to go, and if yes, select some tasks and put names behind them. I add now a list of tasks which we could start to discuss:
- synchronization, single-fail-safe operation, reset, monitoring, interface to DAQ, etc.. Hopefully this will lead to a set of recommandations on how to make the systems as reliable as possible. An example of the things to think about is a similar note written for the vertex detector: LHCb 98-052 TRAC,, Vertex Detector Electronics - Timing and Synchronisation Issues, Y.Ermoline, 26 June 1998 http://lhcb.cern.ch/notes/postscript/98notes/98-052.ps
- latency of whole trigger system, L0 decision box, all links/boxes+delays. The front-end chip designers need to know this before the end of the year to fix the length of the pipeline in the front-end chips. Jorgen Christiansen has made a global estimate, we have to refine this. Jorgen's summary: I have tried to make a concervative guess on the L0 latency including a list of different delays. The time to perform the real trigger processing is though hard to guess. The level 0 trigger people must be consulted for a qualified (conservative) estimate of this.
Example: calorimeter trigger Particle flight time to cal.: 50 ns detector delay: 25 ns analog front-end delay: 50 ns data transmission off detector 100 ns digitisation: 50 ns local processing: 100 ns transmission to L0 processor 100 ns + 250 ns + 100 ns processing Tp ns Trans. to trigger supervisor 100 ns trigger supervisor 100 ns TTC distribution 100 ns + 250 ns + 100 ns. Local front-end distribution 100 ns Total: ~ 1600 ns + Tp ns
- use of real estate: how much floor space do we want where and can we get it. How much space on front-end cards etc. Where do we locate the trigger hardware: on the floor next to the detectors, in the barracks behind the wall? Pro/con of the different solutions, radiation/maintenance considerations etc..
- L0 vs cal and muon lay-out, matching/pointing etc.. Clearly this will be the note of our requirements for the detectors implementation.
- sensitivity of algorithms to overlapping events, structure functions, multiplicity, noise, beam-crossing angle etc. Improve algorithms?
- What level of prototyping/simulation do we require to check validity of a certain approach?
- Any more? Do we want a subgroup to look into data-links etc, or do we leave this to the different implementation scenarios separately?
Regards, Hans Dijkstra.