Requirements list L0 (lhcb-trig)
Time: 7:15:57 AM
Remote Name: 18.104.22.168
Hallo, I just noticed that the attachment of the requirements list does not
work with our mailing system, hence I include it directly in this mail for your
Subject: L0 trigger requirements and milestones
the time scale for the steps leading to decisions for the L0 baseline
implementations are the following:
- end 1998: define list of requirements to allow comparison (this mail).
- 1/4/99: all implementation studies have provided a written document(s) addressing the requirements.
- 1/7/99: if possible the trigger group recommends baseline implementations to the LHCb management, if no agreement within the
trigger group: we ask for a review board to decide for us.
- mid 2001: TDR ready (real deadline given to referees 31/12/2001).
List of items recommended to be fulfilled by the various implementation studies:
1) An overall scheme of the data flow and its hardware implementation from the Front-End via the actual
processors to the L0 decision unit, and
the L1 buffer of the output of the trigger. For the calorimeters liaise with the FE
designers to agree upon the assumptions. Hopefully this will also be possible for the
muons soon (maybe January next year a FE responsible will start his work for the muons).
2) A cost estimate based on the above mentioned scheme.
Some basic rules
. wherever high speed links are involved, do not assume a certain price, single them out to allow an equal
(to be recommended by LHCb) cost estimate of these links. Mention their length (which
should be agreed upon with Frank Harris) and band-width.
. Always base the price on procurement in 1999.
. For components where a large price difference is expected in the
future, supply a second price for expectations when bought in 2003.
. wherever large scale integration in the FE is assumed, make it clear that the trigger electronics part of these
FE boards is included in the trigger price.
3) Wherever the processing is asynchronous:
show that the trigger will run up to a sustained luminosity of 5x10**32, or show the loss
as a function of L. Typically some simulation of the asynchronous, or other
"non-trivial" parts is expected. The baseline generator to provide the input
will be decided soon (by the physics group), after which a new sample of MC will be
4) The latency should be provided based on the above overall scheme and the
simulation, in agreement with Ioana Videau.
5) Explain what is assumed for the FE
synchronisation. How do you synchronise the FE data. How does your system deal with parts
of your system (or the FE) having missed a clock, or suffers from single-event-upsets. How
are these detected, how long to reset them, etc.. How is your system monitored/debugged.
Yuri Ermolin has agreed to look into these items, and collect and compare the various
6) If your solution restricts the algorithm as being implemented in SICB,
provide the corresponding code to be able to check the physics consequences of these
changes. Please check with the coordinators for muons (Renaud Le Gac) and calorimeters
(Ivan Korolko) that they are aware of your special requirements, and that the performance
of your algorithm is checked against noise/pile-up/background etc... in an identical way.
All studies to be performed with the baseline generator as outlined above. We will have to
fix a certain cal/muon lay-out, and cannot wait for "final" detector
7) Suppose your implementation is chosen as the baseline solution:
. what do you foresee to provide up to the TDR?
. where does the manpower necessary (please make an estimate) come from to actually realize the trigger? Inversely
if your solutions turns out not to be the preferred one:
. what manpower could you provide for the chosen solution.
Since LHCb weeks are to crowded to allow in depth discussions, we
plan to organise a few days of workshop in between LCHb week dedicated to the L0
implementation. Regards, Hans Dijkstra.