Minutes of LVL1 CTP and LVL1/LVL2 session of ATLAS Trigger/DAQ Workshop Rome, 16 October 1996. Agenda ------ LVL1 central trigger processor I. Brawn Interface to the LVL2 trigger B. Blair Interface from LVL1 muon trigger Ph. Farthouat Interface from LVL1 calorimeter trigger E. Eisenhandler Multijet trigger for H->hh->bbbb J. Bystricky Minutes ------- Ian Brawn presented the Central Trigger Processor and the associated demonstrator prototype. The CTP combines information from LVL1 subtriggers (jet, missing ET, e/gamma, muon, hadron and calibration triggers) and makes the overall LVL1 trigger decision which it communicates to the TTC system. In the design for the final system, the CTP accepts as input 128 bits of information from the subtriggers (an example of how these might be used is given in the transparencies). The CTP allows one to require combinations of the input bits in coincidence, veto or "don't care". The LVL1 trigger is the OR of up to 96 such trigger combinations. Provision is made to gate triggers with individual vetos, a global external veto and a deadtime veto. High rate triggers can be prescaled. The deadtime logic imposes a minimum of 3 BC (75 ns) between consecutive trigger accepts and can, in addition, limit the number of LVL1 accepts in a longer interval (e.g. at most 16 accepts in any 16 microsec period). A block diagram of the architecture was shown. Synchronisation and alignment circuits are implemented at the input so that data from all the inputs arrive at the subsequent logic at the same time. The CTP provides data to be read out into ROBs: the input data and the trigger combination results before and after the prescaler, the overall decision and the BCID. With a readout window of up to 5 BCs, the maximum data rate is a few hundred Mbits/sec. Scalers are included to monitor the rates of each input and output (before and after prescaling). The design includes test facilities: playback memory and pseudorandom bit sequence generator. The latency of the CTP now estimated to be 2 BC + 7ns (less than earlier estimates thanks to careful design work). Ian also presented estimates of the latency of the combined CTP and TTC system which can be found in the transparencies. Concerning the CTP demonstrator, this is a scaled-down version of the system described above, with 32 inputs instead of 128 and 32 combinations instead of 96. It is implemented on a single 9U board and includes all the functionality on the critical time path. It does not include the readout functionality of a ROD, using a FIFO instead which is well matched to use in beam tests. Possible extensions for the final system are: bunch-by-bunch scalers, ability to veto bunches, trigger-type output and interface to LVL2. One may have to go to a system with several boards for the final CTP. The demonstrator makes extensive use of field-programmable logic. It is a fully-sychronous, pipelined processor operating with a 40 MHz clock. The PCB has 8 layers, including 4 ground layers. Software for the demonstrator aims to be compatible with the LVL1 calorimeter trigger demonstrator programme (plan joint beam tests). The user interface is based on Tcl/Tk and the underlying code is in C. It will run on a RAID processor running Lynx OS. The demonstrator status is that the hardware design is completed. The PCB is being manufactured and will be delivered in early November. Optimistically, the demonstrator CTP will be ready for use in beam tests around Easter 1997, connected to the calorimeter trigger demonstrator. Issues raised by Ian were: - Number of inputs for final system. - Do we send clocks from the subtrigger processors with the data and with groups of how many input bits? - Inputs for calibration triggers. - Maximum prescale factor. - Is any extra functionality required? In the discussion, Dick Hubbard asked if one could extend the design to provide more than 96 trigger combinations. Lorne Levinson asked how the SRAM was implemented (for demo it is one layer of SRAM plus CPLDs, for finally CTP one could use two layers of SRAM as in OPAL). Philippe Farthouat suggested that one could do some ORing prior to the prescalers. Alexander Mass suggested that it could be useful to be able to veto certain kinds of trigger for certain bunch crossings. Bob Blair presented the LVL1/LVL2 interface from the viewpoint of the LVL2 side of the problem. He raised the following points: - What does LVL2 need? - When do we need it? - What for would we prefer? - Review of what and how the supervisor will deal with this information. He emphasized that the aim was to have discussion with the LVL1 community. Bob gave a brief review of the proposed implementation of the LVL2 supervisor which consists of an ROI router, a steward processor, a number of CPUs that share the tasks of the supervisor and ROB request-routing hardware. He divided the tasks into LVL1 driven ones and LVL2 driven ones (more detail in transparencies). LVL1 driven: - Receive ROI data - Select processor chain (local+global in A/B or global in C) - Send ROB request (global processor gets ROI information in C) LVL2 driven: - Receive LVL2 decisions There are also non-data-driven processes related to allocation and monitoring of use of resources, for example. Bob presented some simple timing estimates (no guarantees). This was done assuming that there is no zero suppression for the muon ROI data and that all the pixel maps are received from the calorimeter trigger without preprocessing. For the ROI processors, assuming 5 ROI CPUs, the estimate is 6.2 microsec per event per CPU. Concerning the status and outlook, prototype PMCs have been done and the distribution bus has been demonstrated to do 200 MB/s. A final PMC for the demonstrator programme is being fabricated. Serious modelling is just beginning. Bob suggested a format for the ROI information: - Need something from each LVL1 subsystem for every L1A (CTP, e/gamma, jet, hadron, Etmiss, muon). - Would like to see it as soon as possible. - Use SLINK for sending the data. In this context, would like to use the 24 free bits in the SLINK header for L1ID for use in routing. For consistency, the first two data words should be L1ID and BCID. - Would like in a single document a description of each bit of data that will be received. Bob raised a few points for discussion: - How does one throttle the LVL1 rate. Would prefer to say "NO" when system is near full rather than sending a message for each L1A saying how many resources are left. - Should we check that TTC and SLINK data are consistent. Philippe Farthouat reviewed some points from his earlier presentation on the LVL1 muon trigger -- CTP interface that relate to the connection to LVL2 (see minutes of muon-trigger session). Bob Blair asked if the free bits in the SLINK header could be used for L1ID. During a long discussion on this point, Philippe expressed reservations about using the SLINK header for an application-specific function and suggested using the first data words instead. The latency for providing data to LVL2 was discussed in some detail. One must distinguish between minimum, average and maximum latency. In the best case (following a long period without LVL1 triggers), all of the derandomizing buffers are empty when the data arrive and the data can be made available to LVL2 quickly (< 10 microsec). However, following a sequence of several LVL1 triggers in quick succession (they can arrive every 75 ns), the latency could be much longer: up to about 7.5 microsec times the depth of the derandomizing buffer. The discussion turned to the related question of selecting the derandomizer depth, avoiding loss of data due to buffer overflow and considerations of deadtime. Clearly, the probability for buffer overflow or for having to introduce deadtime reduces as the buffer depth increases. However, a longer buffer implies a longer maximum latency (average latency hardly affected). Nick Ellis raised the question of how deadtime gets introduced in the LVL1 CTP. It is agreed that the minimum interval between LVL1 triggers should be 3 BC (75 ns). It is also foreseen to be able to limit the number of triggers in a given period; for this a maximum of 16 triggers in 16 microsec has been suggested. Nick suggested that this is not sufficient protection against overflow; given that buffers are emptied at a rate of about one event per 10 microsec, 16 triggers in 160 microsec would be better. In the discussion, it was noted that one could not fully protect against overflow in all FE systems. While one can predict in the CTP the buffer occupancy for systems with fixed-length data, this is not the case if the data are of variable length. It was agreed that further consideration should be given to the issue of preventing (or reducing the probability for) buffer overflow. In particular, the condition <= 16 events in 16 microsec should be reviewed. Eric Eisenhandler presented ideas on the LVL1/LVL2 interface from the point of view of the LVL1 calorimeter trigger. This followed an informal discussion at RAL with E. Eisenhandler, N. Gee, A. Watson, D. Hubbard, R. Middleton, J. Strong. Eric reminded the meeting about what was written in the Technical Proposal, pointing out limitations of this scheme from the point of view of LVL2: For the e/gamma trigger the position given is the corner (not the centre) of the cluster and it depends on the sharing of energy between cells and the threshold (this is not a big effect for e.m. showers). For the jet trigger the position given is the corner of the cluster (not the centre) and it depends on the energy sharing between cells and the threshold (this can be quite a large effect for jets). Eric then discussed improvements that could be made compared to the TP design, based on the following general criteria: - Coordinate information should be as accurate as the elements used in the trigger algorithm. - Should be enough information so that which ROIs caused the CTP to accept the event can usually be identified. For the e/gamma trigger, ROIs should cover eta < 2.5 and coordinates should have the trigger-tower granularity of 0.1*0.1. Coordinates should correspond to the local maximum in a 3*3 tower region. All ROI clusters should pass an ET threshold, probably the lowest and with no isolation requirement. This precise coordinate information (approx. 4000-bit map on 0.1*0.1 granularity) can be combined with coarser hit information to permit matching-up with CTP results: 8 256-bit maps corresponding to 8 threshold sets on a granularity of 0.4*0.4. Simulation seems to indicate that ambiguities in doing this matching are not serious. This proposal, if acceptable to LVL2, would avoid a serious and difficult redesign of the LVL1 trigger. It is possible, but not trivial, to supply information on: - Clusters passing more than one ET threshold (easyish) - Hit maps at the full 0.1*0.1 granularity (difficult). Eric argued that a clear advantage would have to be shown by LVL2 to justify the extra complexity. For the jet trigger, jet elements should cover eta < 3.2. ROI coordinates should have jet-element granularity, but the element size is not yet decided. To simply discussion, 0.4*0.4 elements have been assumed from now, with jet windows of 0.8*0.8 sliding by 0.4. The coordinates should correspond to an ET maximum, not just a pattern of hits above threshold. There are two possibilities: - local maximum jet element. - local maximum window. In combined proposal, coordinate is of local maximum jet element in a window passing one of the jet ET thresholds. This needs 3*3 environments, but simplifies jet declustering for the LVL1 trigger. Further studies of the above proposals are in progress. Jiri Bystricky presented results of a study of a multijet trigger for H->hh->bbbb. This was done for L = 10**33 with mH = 300 GeV and mh = 80 GeV, including 2.26 pileup events per BC. Windows of 0.8*0.8 sliding by 0.4 were used to find jets. Pulse shaping and BCID were applied to LVL1 0.1*0.1 regions, the digitization being done with an offset of 0.125 GeV and least count 0.5 GeV. The study was performed using a fast simulation program, with electronic noise of 200 MeV and using a pulse shape function. In contrast to older LVL1 algorithms (cut at 0.5 GeV and then digitize) the new, more realistic, approach (first digitize and then cut at 0.5 GeV) gives LVL1 jet values higher than LVL2 ones (from 16 GeV in the mean for low pT jets to 6 GeV for jets with pT > 400 GeV. Muon pT was added to LVL2 jet values if appropriate. The dependence of QCD jet rates on the efficiency of Higgs events was shown for different kinds of triggers. Some numbers are summarized below: LVL1 LVL2 Higgs efficiency Jet Rate S/B J80 - 80% 7 kHz 0.7 10**-4 J80+3J30 - 56% 2 kHz 0.2 10**-3 J80+3J35 - 44% 1 kHz 0.3 10**-3 J80+3J30 J100 33% 0.5 kHz 0.4 10**-3