Referee trigger info call and L0 trigger thoughts
Dear trigger friends, 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 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 Sep http://lhcb.cern.ch/notes/postscript/98notes/98-052.ps
- latency of whole system. We have to fix the maximum needed latency "soon". 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.
- L0 vs cal and muon lay-out, matching/pointing etc.. Clearly this will be the note of our requirements for the detector implementations.
- sensitivity of algorithms to >1 overlapping events, structure functions, multiplicity, beam-crossing angle etc.
- Any more? Do we want a subgroup to look into data-links etc, or do we leave this to the different implementation scenarios separately?
Meeting with referees Wednesday Sep-2: Do we have anything new since the last LHCb week? I could think of full comparision of new algorithms for Cal and mu with the TP values.
Regards, Hans Dijkstra.