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 transparencies at 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
    single 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)
(see transparencies in http://d0server1.fnal.gov/WWW/Stt/boston/wt990611.ppt
and http://www-d0.fnal.gov/~wendyt/stt_tfc_11jun99.htm )

   * 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?)

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)

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