Silicon Track Trigger Status report 7 Oct. 1999 (Horst D Wahl)

1. Silicon Track TriggerStatus report 7 Oct. 1999(Horst D Wahl) • funding • ongoing activities • what next? • schedule • Webpage of STT group: • http://www-d0.fnal.gov/~wahl/vtxt.htm --- has links to other relevant pages at Boston U., Stony Brook, Columbia Outline:

2. STT Funding History (chapter 1999) • 15 October 1998: PAC at Fermilab: Committee sympathetic, but want more information • 5 January: submit addendum to proposal to PAC • 15 January 1999: PAC at Fermilab: PAC grants stage I approval • 15 February 1999: submit MRI proposal to NSF (consortium of four universities: Boston U., Columbia U., Stony Brook, FSU) • March 1999: submit STT proposal to DOE (same consortium of four universities: Boston U., Columbia U., Stony Brook, FSU) • June 1999: NSF funds project at 1.1 M$(requested 1.3M$, with ~0.5M$ matching from universities (BU, CU, SB, FSU) and foreign collaborators (Nijmwegen, IN2P3)) DOE promises to make up for missing money (~250k$) • October 1999: money becomes available, subcontracts being issued

3. Recent and ongoing activities • examined alternate designs • L1 DFE board option: use standard L1 digital front-end boards for STT implementation -- conclusion: cannot use DFE board as is (board too small -- only 6U), but adopt some features; in particular adopt concept of same motherboard for all parts of the STT • studies of track fitting: • optimize tracking algorithm for time and efficiency • strategy for picking hits in CFT roads (have to go through all hit combinations?) • timing studies in different implementations (integer DSP, floating point DSP, Alpha, Altera 10k..) • have finished implementation in Altera 10k100; too slow -- now investigate possibility of using integer algorithm to gain speed

4. Ongoing activities, cont’d • queueing studies: • now use Ptolemy, since RESQ not supported; • first studies confirm results previously obtained with RESQ • detailed timing specifications formulated -- will allow further refinement of model for more realistic simulation • questions to be answered: • identify potential bottlenecks in data flow through the trigger • additional buffering needed, and where? • link with L1CTT: • influence of truncation (limit on number of tracks reported) on efficiency • how to minimize number of duplicate tracks in broadcasting • develop code for FPGA on L1CTT-to-L2STT broadcasting board

5. Ongoing activities, cont’d • Trigger simulation: • main package, input, output, clusterfinding done and implemented • hit filtering and track fitting exist as stand-alone packages, to be implemented into package • vertex finding package to be designed • presently only one clustering algorithm implemented -- other possible algorithms to be included to allow comparative performance studies

6. Engineering design • real engineering design work started few months ago • decisions taken recently: • use standard 9U VIPA crates • common motherboard for all of STT • daughter cards provide functionality for data receiving, transmitting and processing • use point-to-point links (LVDS) for fast data flow within STT • input from SMT and L1CTT over G-link via VTM (D0-CDF standard) • Cypress hotlink for output to L2CTT • propose to use PCI bus for data transfer on motherboard • detailed specifications of STT data links, data flow, protocol in progress • have conceptual design of clusterfinding logic, studies of clustering algorithms underway • VHDL coding of clusterfinder and hitfilter for STC in progress

7. Trigger simulation • components designed, implemented and released: • tsim_L2STT (main package), • getSMT_FE ( read out for the input chunk from the SMT front end • getFT_L1 ( read out for the input chunk of CTT L1) • doClustering ( calculate clusters from SMT hits by using one possible clustering algorithm) • fillNtuples ( fills local STT Ntuples that can be directly integrated into the Ntuple Maker) • fill_L2STT ( creates the L2STT output chunk ) • testing of implemented code: • used MC events (t tbar with superimposed min. bias events) to test package, and in particular cluster algorithm performance

8. Trigger simulation, cont’d • components designed and developed as standalone programs (to be implemented in package): • doRoads ( associates SMT clusters into 'roads' defined from CTT tracks ) • doTrackFitting ( reconstruct STT tracks from the SMT clusters in roads) • components to be designed and implemented: • doVertexing (reconstructs Z vertex from Z clusters ) • other things to be done: • implement other cluster algorithms • do performance studies

9. Monitoring • Levels of monitoring: • STT internal monitoring: this monitoring capability must be foreseen in the design of the STT hardware; try to use/copy/modify existing monitoring plans (e.g. for central tracker read-out system) • Level 2 global on DEC Alpha in L2 global crate: adapt standard L2 tools, but in hardware design must foresee relevant information to be available to L2 global • Level 3 under Windows NT: code to be developed, adapting standard L3 tools • Online monitoring using EXAMINE: code to be developed • Offline batch monitoring: code to be developed

10. D0 STT project • Present participants : • Boston University: Ulrich Heintz (f), Meenakshi Narain (f), Bill Earle (e), Eric Hazen (e), John Yook (s) • Columbia University: Hal Evans (f), Bill Sippach (e), Georg Steinbrueck (p), Maurice Leutenegger (s) • Florida State University: Stephan Linn (f), Harrison Prosper (f), Horst Wahl (f), Sailesh Chopra (p), Silvia Tentindo-Repond (p), Brian Connolly (s), Roberto Brown (s), (Simon Foo (f)) • Stony Brook: John Hobbs (f), Wendy Taylor (p), Chuck Pancake (e) • Tentative schedule: • Nov. 1999 specification complete • March 2000: first prototype • Oct 2000: 2nd prototype • March 2001: production begins • June 2001: production complete

11. What next • For next engineering meeting (19 Nov): • Finalize and sign off on motherboard design • finish cluster finder and hit filter • optimize + finalize track finding algorithms, decide on processor • sign off on data transmission protocols • make sure that tools for testing, monitoring, in situ diagnostic are foreseen in design • make sure we understand all quantities (e.g. alignment info, beam position,…) that need to be available to trigger, provide for their downloading and storage • need more MC events for more physics studies (need disk space!) • study influence of misalignment • get good understanding of efficiencies • influence of algorithm choice • specify other tasks (e.g. beam position monitoring, alignment,..), and identify manpower for them • bimonthly engineering workshops, last 24 Sept, next 19 Nov.