STT meeting at Boston =========== Friday, 11 June 1999, 13:00 to 14:00 at Boston University Agenda: * Welcome (M. Narain) * Status of FRC (H. Evans) * Status of STC - Overview, System Simulation (U. Heintz) - Cluster Finder (W. Earle) - Trigger Simulation/Clustering Algorithm (S. Tentino-Repond) - Input Stage of Cluster Finder (R. Brown) * Status of TFC - Altera Simulations (W. Taylor) - Physics and Timing Studies (J. Hobbs) * Crate/Backplane Layout, Data Links (E. Hazen) * L1CTT Input Format - L1CTT Data Format (H. Evans) - Is proposed format acceptable? (all) * Discussion (all) - Card Specifications (I/O, Communication Links) - Monitoring Issues - Downloading * Discussion of Resources/Summary (M. Narain) People present at Meeting: ========================== Roberto Brown, Brian Connolly, Bill Earle, Hal Evans, Eric Hazen, Ulrich Heintz, John Hobbs, Marvin Johnson, Jim Linnemann, Meenakshi Narain, Chuck Pancake, Wendy Taylor, Silvia Tentindo-Repond, Horst Wahl, John Yook. 1. Status of FRC (Hal Evans): ----------------------------- * try to "steal" as much as possible from other cards which are being designed: receiver of G-link from VTM, FIC receiver of SCL information: MBT * open questions: - biases in truncation scheme (32 OK?) (Columbia summer student will do studies) - header information (event number,..) - define road info data format (track number identifier,..) - decide where reformatting of L1CTT info will be done - choose communications protocol - identify SCL info needed - define data to L3 - define buffer control protocol - monitoring data / monitoring control see transparencies (http://www.nevis.columbia.edu/~evans/stt/talks/bu_frc.pdf) 2. STC overview (Ulrich Heintz): -------------------------------- System simulation being done in VHDL, using Mentor Graphics software (John Yook) 3. Cluster Finder (Bill Earle): ------------------------------- (see http://ohm.bu.edu/~hazen/my_d0/11Jun99/) have first attempt at conceptual design for cluster finder implementation in FPGA, assuming fixed cluster size of five strips; lots of open questions, need input from simulations. 4. Input stage to cluster finder (Roberto Brown): ------------------------------------------------- Roberto has done FPGA implementation of input stage to cluster finder, i.e. part which receives and recognizes input data from SVX2, and activates submodules depending on data type. (Software used is Altera MaxPlusII, version 9.1) see transparencies at http://d0server1.fnal.gov/WWW/Stt/boston/rab990611.ppt. 5. Clusters in L2STT trigger simulator (Silvia Tentindo-Repond) -------------------------------------- A "neighbor clustering algorithm" has been implemented in the trigger simulator framework; other algorithm with max. of five strips being implemented. Results are presented for clustering algorithm without clustersize limit; find 800 clusters/event in ttbar events without add'l interaction (9.5 in singlr muon events), ave clustersize 2.8 (no big difference between muon and ttbar events) (but have not looked at clustersize vs STT layer Meenakshi expects difference in innermost layer) Things to do next: -Study cluster occupancies in chips, HDIs etc vs kind of events (single -tracks / t tbar / t tbar + min bias ) - study clusters with very high size (where do they come from - how often) - study clusters with more than one maximum, improve Algos to calculate appropriate centroid(s) - implement FPGA vsn of tsim Clustering (STT emulator) - consider possible choices of LUT and implement LUT in Algo(s) - improve cluster algorithm: deal with dead/noisy channels, (see transparencies in http://d0server1.fnal.gov/WWW/Stt/boston/str990611.ppt) 6. Altera implementation of track fitting (Wendy Taylor) ----------------------------------------- * using MaxPlus Altera software, have simulated performance of track fitter in Altera Flex10k130E (running at 50MHz); * Z to bbbar event takes 16mus for SR4, 72 mus for SR3; * note that code is not optimized; * problem is that there is trade-off between optimization for timing (more parallelism) and resource utilization (chip too samll?) (see transparencies in http://d0server1.fnal.gov/WWW/Stt/boston/wt990611.ppt and http://www-d0.fnal.gov/~wendyt/stt_tfc_11jun99.htm) 7. Track fitting algorithm studies (John Hobbs): ---------------------------------- There is D0note summarizing these studies findings is in preparation, preliminary version exists (see http://sbhep1.physics.sunysb.edu/~hobbs/l2stt/stt.html for link) Outline of algorithm studies: Data samples used: Z to b bbar with 0 and 2 additional interactions, WH to jets with 0 additional interactions, MB mix algorithms tried: static road with 4 SMT hits (SR4) static road with 4 SMT hits (SR3) dynamic road with 4 SMT hits (DR4) dynamic road with 4 SMT hits (DR3) all combinations with 4 SMT hits all combinations with 3 SMT hits criteria for judging algorithm performance: purity: = fraction of reconstructed tracks having only hits from one MC track efficiency: fraction of tracks reconstructed among those with hits in at least 3 layers and chisq > 3 trigger efficiency: for dedicated triggers of PAC98 trigger menu Main findings: --------------- track efficiency vs pt: rather flat, best for SR3 vs impact parameter: flat for b < 1mm, but drop-off beyond that; drop-off worst for SR4 (biases against large impact parameters) timing: * DSP and Altera times are comparable * Alpha appreciably faster (factor 4 or more) conclusion: * need to accept 3 layers * best would be to use DR3, but cannot afford time requirement * propose to use "current 3-layer algorithm" (= SR4 with 2nd iteration, dropping worst layer) estimate time needed to be 2x SR4, i.e. 8mus in Alpha, 35mus in DSP/Altera * given timing performance and recent price decrease, Alphas become viable alternative; (but have to understand possible problems) to be done: * investigate integer algorithm * understand better implications of Alpha choice - rack space - availability of Alpha chips - availability of obsolete PCI interface chips - how many needed? assume 4 tracks per alpha => 4 workers, 1 administrator, 1 MBT per sector, for total of 24 8. Crate/backplane layout, communication, data links (Eric Hazen) ---------------------------------------------------- * timing (see http://ohm.bu.edu/~hazen/my_d0/11Jun99/timing.pdf) - min. time between L1 accepts is ~7mus (not 100mus shown in diagram about system timing) (7 mus = SMT read-out + 2 to 3 crossings + refilling pipeline) - question of time needed for fiber tracker road data to get to the STT: communication from Marvin Johnson (18 June): Manuel thinks that this time is still under 2.8 micro seconds. Thus, roads will be available before any silicon hits arrive. Manuel is working to get a more accurate number but you should use this for now. * data link for road information (see http://ohm.bu.edu/~hazen/my_d0/11Jun99/links.pdf): would like to avoid using backplane for FRC to STC communication, rather use point-to-point connection, e.g. National Semiconductor LVDS (21 bit, 66MHz) link (CMS uses it) * crate (see http://ohm.bu.edu/~hazen/my_d0/11Jun99/crate.pdf): suggest VITA/VIPA crate (Jim Linnemann: see L2 page for link to specifications; URL http://www.pa.msu.edu/hep/d0/l2/, follow link to Hardware|Vme for Physics) * data path (see http://ohm.bu.edu/~hazen/my_d0/11Jun99/DataPaths.pdf): question: use J3 backplane for communication of FRC with STC or point-to-point connection? SVX J3 backplane: not enough pins for road information 9. L1CTT broadcast information (Hal Evans, discussion) ------------------------------ (see Hal's transparencies, pp 3 to 7 (http://www.nevis.columbia.edu/~evans/stt/talks/bu_frc.pdf)) Consensus that information broadcast is OK. some minor clarifications are needed from Kin Yip. Here is a summary of the discussion and findings (mail message from Hal Evans): 1) We will pass through all L1CTT information sent to us to the L2CTT. This includes all tracks sent to each sector regardless of whether they have SMT hits or not and the PS information packed in the L1CTT track words. This means that the L2CTT will have to deal with duplicate tracks from the overlap regions that are passed to different STT crates. Note, that the details of how we do all of this are still under discussion. 2) The scheme of sending A-Offset information to the STT for the low Pt bins and Pt information for the high Pt bins seems to be a good one from our point of view. We are in contact with Kin Yip to clarify a few points about how exactly the A-Offsets are derived. 3) The truncation scheme proposed seems to be safe; however, Hal will have one of his summer students verify it using several signal and background MC samples with an eye towards seeing if it can be tightened. 10. Other discussion points: ---------------------------- 10.1 connections: * connection of FRC to STC and TFC via bus, point-to-point or daisy chain? -- tentative yes to daisy chain * backplane: note that mixed backplane is possible, i.e. backplane in crate could be different, eg., for (FRC and STC) from that for TFC. * connection FTC to L2CTT: use hotlink 10.2 monitoring: * use the board being developed by tracking group? (Dave Buchholz & Co) * must foresee to send every few seconds "unbiased event", e.g.: L1CTT all clusters filtered clusters all fitted tracks/hits/parameters * information to be monitored: event counter, busy, buffer full, system hung 10.3 check of data integrity: * should foresee data quality checks, e.g. longitudinal parity, checksum,.. * SCL: FRC needs to send error information back to trigger framework - required: event mismatch, - optional: whatever else we want 11. things that need attention: ------------------------------- general: downloading monitoring unbiased events FRC: see list in Hal's transparencies STC: input cluster finding (establish better communication BU -- FSU) Mentor simulation tester cards (Marvin?) serial control box for testing -- foresee add'l serial link to allow testing parasitically on-line? hitfilter links, buses, protocols TFC: integer arithmetic processor choice Next engineering meeting: Monday, 16 August at Fermilab