# Presentation: 281034

## 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:**

## 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

## 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**

## Clusters from one t tbar event

## Clusters from 100 t tbar events

## Clusters from t tbar events

- only from barrels

## SMT clusters in CTT roads

## Road centers in SMT

## Clusters in roads for 100 t tbar events

## CTT roads (100 t tbar events)

- Clusters in roads
- nb. Of CTT tracks

## 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)

## 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)

## STT Queuing model

## PCI bus model

## distributions used

- Track multiplicity
- hit multiplicity
- track fitting time

## 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

## 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

## 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)

## SMT processor galaxy