Home Trigger E-mail Notes Meetings Subsystems Search

Home Trigger E-mail Notes Meetings Subsystems Search

[ Home | Contents | Search | Post | Reply | Next | Previous | Up ]


vertex trigger implementation

From: Hans.Dijkstra@cern.ch
Date: 10/22/97
Time: 10:09:58 AM
Remote Name: 137.138.115.189
Remote User: Hans Dijkstra

Comments

Meeting on vertex trigger implementation: Wednesday Oct-15, 1997. Present: Jan Buytaert, Hans Muller, Beat Jost, Pere Mato, Mike Koratzinos, Hans Dijkstra.

Presentations by: - Hans M on the FPGA solution. - Jan on look-up tables rather than FPGA. - Mike+Pere on the full processor solution.

Some points which came out of the meeting: . A significant part of the total processing time has to be performed in processors with the present algorithm, whatever the solution. Due to the tails in the time/event distributions, the maximum latency cannot be "small", i.e. few*10 micro-s, even if we could get an average time to few*10 micro-s. Hence: we need few*100, say 256 micro-s. . The part of the algorithm which has to be performed in the processors in any solution needs a sizeable fraction of the data (10-30% minimum). Selecting only 10% of the data/event by pulling the data based on say the triplet tracks causes a considerable overhead since the data is distributed over many stations&sectors. Hence, it seems that in any solution it is better to push the complete data to a processor for those events which cannot be rejected just based on the rz information. . It seems feasable to distribute the data we have (average 2kbytes/event, maximum 4 kbytes/event) over the processors at a rate of 1 MHz. The question on in-house or commercial does not have to be answered now, given the fast developments in this area. It should be noted that an in-house concept exists and seems feasable in case no commercial solution meets the requirement of aggregate throughtput (4GBytes/s) and number of in and output nodes.

. Remains the question on the necessity of the hardware preprocessing: points in favour: - reduce the number of processors, maybe with a factor 2. This might result in a cost reduction, but accounting is a difficult job. - reduce total time, but compared to necessary maximum latency this seems 10-20%, hence negligible. points against: - reduces flexibility, puts constraints on detector design/alignment. - need to design/built/maintain 2 systems, since we always need the processors.

Plan: produce two notes on trigger implementation (one on the hardware option from Hans Muller, Fabio Formenti (and Jan Buytaert?), one on the processor implementation from Pere Mato and Mike Koratzinos). These notes can then be referred to in the TP to show that we studied the problem from several angles, giving the full processor solution as the base-line option.

Regards, Hans Dijkstra.

Home Trigger E-mail Notes Meetings Subsystems Search