STT simulations (Horst Wahl, 10 Dec. 1999)

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

2. Trigger simulation(Silvia Tentindo-Repond, Sailesh Chopra,..) • Recent modifications/improvements: • most of the code committed to CVS t64 • L2STT Simulator code split into three packages: • tsim_l2stt (main package) • l2stt_fitting • l2stt_util • CTT roads: • now integrated into main package; • temporarily, use function for translation from CFT to SMT coordinates (translation map for downloading into FPGA being developed) • l2stt_util: • changes to accommodate roads and tracking • new functionality: • can 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 events show results compatible

3. Trigger simulation, cont’d • tracking (with John Hobbs, Wendy Taylor): • l2stt_fitting contains all possible tracking algorithms (for testing); • main package will only have final choice of algorithm • presently being debugged • 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 • 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) • Clusters in roads • nb. Of CTT tracks

11. Queueing Studies(Stephan Linn) • 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? • Queueing simulation software • previously, used RESQ (IBM product) • not supported anymore, only runs on IBM platforms  look for alternative • 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 • use latest specifications(note by U.Heintz at http://physics.bu.edu/~heintz/STT_q.pdf) • parameterize (from MC data) • Nt = number of tracks • Nh = number of hits • H = clusters per hit • T = clusters per track • transmission speeds • data sizes • model: • STT modeled as 6 independent sectors • random numbers Nt, (hyperexponential) Nh (double gaussian), track fitting time (double exponential, from JH+WT studies) • correlations between module delay times (depend on Nt, Nh) • 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 • Track multiplicity • hit multiplicity • track fitting time

16. Queuing simulation results • 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 • STC VHDL code: • input stage of STC: • receive SMT data from VTM • recognize data (chip ID, address, pulseheight, header,....) • pedestal/dead channel corrections • cluster SMT hits • expand SMT strip addresses • determine and format cluster pulse height • buffer hit clusters (and pulseheights) for hit filtering • buffer hit clusters (and pulseheights) for L3 • buffer 90deg hits for ZVC and L3 • hit-filtering: • receive/format L1CTT roads • associate clusters with roads • buffer associated data for L3 • send associated data to TFC • status: • preliminary conceptual design by Bill Earle • coding: tedious learning curve  delay; • very recently recruited expert  expect faster progress from now on • big part of code written, being tested and debugged

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