1. STT simulations (Horst Wahl, 25 February 2000) l trigger simulation  (Silvia Tentindo-Repond, Sailesh Chopra, John Hobbs with help from Brian Connolly, Harrison Prosper, + Dave Toback) l queueing studies  (Stephan Linn) l VHDL code for STC and circuit simulation  (Bill Earle, Sailesh Chopra, Roberto Brown, Reginald Perry,…) Outline:

2. Trigger simulation (Silvia Tentindo-Repond, Sailesh Chopra,..) l Recent modifications/improvements:  most of the code committed to CVS t70  L2STT Simulator code split into three packages: s tsim_l2stt (main package) s l2stt_fitting s l2stt_util  CTT roads: snow integrated into main package; stemporarily, use function for translation from CFT to SMT coordinates (translation map for downloading into FPGA being developed)  l2stt_util: schanges to accommodate roads and tracking  new functionality: scan create a text file that contains SMT hits in cable-format, to be used as an input for debugging and testing of VHDL code for clustering. (RCP switch)  clusters provided with their own ntuples  tests of roads and clusters with t tbar and Z to bbar + 2 MB events show results compatible

3. Trigger simulation, cont’d l tracking (with John Hobbs, Wendy Taylor):  l2stt_fitting contains all possible tracking algorithms (for testing);  main package will only have final choice of algorithm  still being debugged l Chunks:  FT_L1 input chunk and SMT_FE input chunk exist,used as new UnpDataChunks.  STT_L2 output chunk has been created and encoded in CVS t64; temporarily contains information about Clusters, CFT tracks plus Ps and (fake) STT tracks.  Need STTChannel class; code that creates the STTChannel written, being debugged; need support from expert

4. Clusters from one t tbar event

5. Clusters from 100 t tbar events

6. Clusters from t tbar events l only from barrels

7. SMT clusters in CTT roads

8. Road centers in SMT

9. Clusters in roads for 100 t tbar events

10. CTT roads (100 t tbar events) l Clusters in roads l nb. Of CTT tracks

11. Queueing Studies (Stephan Linn) l Questions to be answered by queueing studies:  how much processing (e.g. track fitting) time can we afford before deadtime becomes unacceptably high?  where are the potential bottlenecks in the data flow through the trigger?  additional buffering needed? l Queueing simulation software  previously, used RESQ (IBM product) únot supported anymore, only runs on IBM platforms  look for alternative l Ptolemy :  simulation package developed by EE and comp.science dept. at UC-Berkeley  can simulate complex systems at different levels of detail and with different time scales  elements of system represented by “queue and serve galaxies” úspecified by service time and queue depth úevent defined by starting time and data value (event number)

12. STT Model in Ptolemy l use latest specifications (note by U.Heintz at http://physics.bu.edu/~heintz/STT_q.pdf)  parameterize (from MC data) úN t = number of tracks úN h = number of hits úH = clusters per hit úT = clusters per track  transmission speeds  data sizes l model:  STT modeled as 6 independent sectors  random numbers N t, (hyperexponential) N h (double gaussian), track fitting time (double exponential, from JH+WT studies)  correlations between module delay times (depend on N t, N h )  PCI bus “arbitration” (priority to road transfer over filtered clusters)  STC filter waits for roads from FRC  (see draft of note by Stephan Linn at http://www-d0.fnal.gov/~linn/d0_private/queue.ps)

13. STT Queuing model

14. PCI bus model

15. distributions used l hit multiplicity l trackmultiplicity l track fitting time

16. Queuing simulation results l latency  for one STT sextant:  latency for one sextant reproduces track fit delay  full system latency: worst-of-N convolution with five other sextants  total deadtime: < 1% (for nominal values) (not counting deadtime due to min. time between L1 accept)  16 event buffer before track fitting takes care of 50  s track fitting time -- never filled to capacity.  no additional buffer necessary

17. VHDL code for STC l STC VHDL code:  input stage of STC: sreceive SMT data from VTM s recognize data (chip ID, address, pulseheight, header,....) spedestal/dead channel corrections scluster SMT hits s expand SMT strip addresses sdetermine and format cluster pulse height sbuffer hit clusters (and pulseheights) for hit filtering sbuffer hit clusters (and pulseheights) for L3 sbuffer 90deg hits for ZVC and L3  hit-filtering: sreceive/format L1CTT roads sassociate clusters with roads sbuffer associated data for L3 ssend associated data to TFC l status:  preliminary conceptual design by Bill Earle  coding: tedious learning curve  delay;  very recently recruited expert  expect faster progress from now on sbig part of code written, being tested and debugged

18. Conclusion l STT trigger simulation tools close to being ready;  tracking part operational before Christmas  alternative clustering schemes to be implemented in January  investigate possibility of using VHDL to C translators (help ensure that algorithms in trig.simulation correspond to firmware implemented in hardware) l queueing simulation package operational  have STT queueing model which is quite realistic  studies so far show no major bottleneck in design  can easily adapt to new specifications as design progresses l VHDL code for STC  addition of new expert (Reginald Perry) will help a lot getting the job done  first version of clustering code being tested (using VHDL tool to funnel MC data into VHDL code)

19. SMT processor galaxy