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

1
Silicon Track TriggerStatus report 7 Oct.
1999(Horst D Wahl)
Outline

• 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

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, contd

• 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, contd

• 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, contd

• 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.