VEPIX53: Progress on hit generation inside the framework and other issues

1. VEPIX53: Progress on hit generation inside the framework and other issues • Sara Marconi

2. OUTLINE • Classes of hits generated • Defined parameters • Examples from simulations • Configuring the specific tests: • Defining parameters • Switches for output files • Supporting TLM model of the chip

3. Classes of hits generated : single tracks • Single tracks:  • Parameters fixed for a sequence of n bunch crossing cycles: • Track rate (Hz/cm2)  • to be converted in number of clusters per pixel chip per BX given the pixel chip area • also low rates can be generated (less than one track per chip per BX) • Position on the detector (given as track angle 0°-90°)  • to be converted in “length of the cluster” (number of pixels from 1x1 to 1xN) • given a certain sensor thickness and the pixel dimension in the direction of the angle • Level of charge sharing: • possible parameter (LEV_ZERO. LEV_ONE) • to define how many pixels surrounding the 1x1-1xN central ones are interested • the amplitude of the surrounding pixels so far is simply decremented by 1 • plus additional parameter to randomize how many are actually hit inside the envelope (percentage of hit pixel in the envelope added to the defines) sensor thickness

4. Some examples of generated tracks: Zoom on single clusters with charge sharing • Track rate: 500 MHz/cm2 • Sensor thickness = 100 um • Track angle = 30° • Charge sharing: LEV_ONE • Percentage of hit pixel in the envelope :10% (a), 50% (b), 80% (c), 100% (d) (a) (c) (d) (b)

5. Classes of hits generated : Loopers • Loopers:  • Parameters fixed for a sequence of n bunch crossing cycles: • Looperrate (Hz/cm2)  • to be converted in number of loopers per pixel chip per BX given the pixel chip area • also low rates can be generated (less than one looper per chip per BX) • it calls the same routine used for single track generation • forcing 1x1 central hits (assuming 90° track angle)  • using defined parameters for  • charge sharing sensor thickness

6. Some examples of generated loopers: Zoom on looperswithout charge sharing • Looper rate: 200 MHz/cm2 • Pixel chip area = 6 cm2=> 30 loopers/BX/PC • Charge sharing: LEV_ZERO Zoom on square loopers (1x1)

7. Classes of hits generated : Jets • Jets: • Parameters fixed for a sequence of n bunch crossing cycles: • Jet rate (Hz/cm2)  • to be converted in number of jets per pixel chip per BX given the pixel chip area • also low rates can be generated (less than one jet per chip per BX) • Number of tracks per jet  • impose a certain distribution (e.g. poisson with a certain mean; certain min-max range) • so far: poisson with mean specified through the test (and random seed) • Size of the “jet area” (in cm2 or num of pixels  #pixels of z and phi edges)  • where central addresses of tracks are concentrated • at the generation level overlapping cluster are summed up(to be pointed out: how to merge hits in pixel?) • For each track: it calls the same routine used for single track generation  • choosing central address within the defined “jet area” • using defined parameters for: • position on the detector • level of charge sharing

8. Some examples of generated jets : Single jet • 10 tracks per jet (mean value of poisson distribution) • Jet area: 10x10 pixels (clusters overlap) • Sensor thickness = 100 um, Track angle = 20° • With charge sharing Details on the jet shown (for debug)

9. Classes of hits generated : Monsters • Monsters:  • Parameters fixed for a sequence of n bunch crossing cycles: • Monster rate (Hz/cm2)  • to be converted in number of monsters per pixel chip per BX given the pixel chip area • also low rates can be generated (less than one monster per chip per BX) • Size of the monster = a whole row/column (OK?) • Direction of the monster (Z/PHI) (OK?) • To be kept separated from generation of single tracks • Cluster dimension: 1xN with N = “Size of the monster” • Using same parameter for:  • level of charge sharing

10. Some examples of generated monsters: Zoom on single ones • Monster rate: 7 MHz/cm2 • Pixel chip area = 6 cm2=> 1 monster/BX/PC • Monster direction = PHI or Z • Size of the monster = whole Z (a) or PHI (b) length • Charge sharing: LEV_ONE • Percentage of hit pixel in the envelope : 100% (a) (b)

11. Classes of hits generated: Noise hits • Noise Hits:  • Parameters fixed for a sequence of n bunch crossing cycles: • Noise hit rate (Hz/cm2)  • to be converted in number of noise hits per pixel chip per BX given the pixel chip area • also low rates can be generated (less than one noise hit per chip per BX) • Just 1x1 patterns being randomly generated • Not correlated with tracks

12. Setting parameters in the define file • Parameters defined in the “ClassDefines.sv” file (used by the Verification Environment) • Sharedparameters • Single tracks: • track rate (Hz/cm2) • track angle • %hit pixels • Loopers • looper rate (Hz/cm2) • Jets • jet rate (Hz/cm2) • mean tracks per jet • jet area (pixels) • Monsters • monster rate (Hz/cm2) • Noise Hits • noise hit rate (Hz/cm2) All calculations moved OUT OF THE DEFINES FILE(only rates per cm2 therein specified)

13. Setting parameters and switches in the test (I) • Configuring the trigger and hit environment through the config object • switch: DUMP EACH BX • switch : DUMP HISTOGRAMS • number of CYCLES OF ACCUMULATION OF HISTOGRAMS • Configuring the analysis environment through the config object • switch: DUMP BUFFER OCCUPANCY • switch: DUMP CLASSIFICATION OF LOST HITS Every current output file has an associated switch to turn the feature on/off through the UVM test

14. Setting parameters in the test (II) • Configuring the specific hit and trigger sequences to be run: • defines can be used (as shown in previous slide) or numbers can be specified directly in the test Previous Charge Sharing Loopers, Jets, Monsters and Noise Hits parameters

15. Supporting TLM model of the chip • To do: • First step: need to take the TLM to RTL conversion out from the agents (at least hit/trigger) – so far they directly communicate with the interfaces towards the DUT  • Tuomas has uploaded a TLM description of chip (for defining the interfaces to the TLM chip) • To be investigated: impact on the rest of the environment (change of architecture, likely to be triggerless) Test class Top-level virtual sequence Configuration object Configuration object Sequence library Pixel ASIC RTL DUT Input agent Output agent TL2 RTL TL2 RTL Configuration object Pin-level signal agent TL2 RTL Slow Control agent TL2 RTL Sequence library Sequence library Analysis Components Configuration object

16. Backup slides

17. Class of hits to be generated: Introduction • Per each BX different kinds of hits to be generated: • Single tracks • randomly distributed in the pixel chip • variable number of hit pixels per cluster • at a given angle • Loopers • low energy particles • single track crossing at around 90° • Jets • multiple clusters concentrated in a given area • can be seen as multiple tracks • clusters can be overlapping • Monsters • very “long” tracks • Noise hits • not correlated with tracks • Definition of “hit”? • time (BX - with possibly random delay to be added) • random amplitude (charge or TOT) Sensor Interaction point

18. Some examples of generated jets : Pixel Chip map • Jet rate: 80MHz/cm2 =>14 jets/BX/PC, 10 tracks per jet (mean value of poisson distribution) • Jet area: 20x20 pixels • Sensor thickness = 100 um, Track angle = 20° • With charge sharing JET

19. Example with simultaneous generation of tracks and jets: Pixel Chip map • Jet rate : 80MHz/cm2, Jet area: 10x10 pixels, 10 tracks per jet (mean value) • Track rate: 500 MHz/cm2 • Sensor thickness = 100 um, Track angle = 20° • No charge sharing SINGLE TRACK JET

20. Statistical analysis on what is generated Possible options for statistical analysis on generation: • Writing (each BX) to a file only generated hits  • useful for debugging • to be read by Matlab/ROOT for statistical analysis • so far 3 columns (x,y and amplitude) are added to the file for each BX • switch added in the hit configuration object to enable/disable this feature • this feature is performed in a dedicated component (hit subscriber), built only if needed • Analysis (partially) within the framework:  • switch added in the hit configuration object to enable/disable this feature • using multidimensional arrays to accumulate histograms dedicated component (hit subscriber) for accumulating histograms • how to read the stored info: • write them to an output file every m BX cycles(m is a parameter that can be set in test) • Then imported in MATLAB for graphics: uniform distribution of tracks and jets observed • Analysis in the framework using C++ for graphics  - LOW PRIORITY • need to interface SV with C++ • to be investigated • C# expertise needed

21. Statistical analysis on what is generated: example of dumped histogram • Analysis (partially) within the framework:  • Jet rate : 80MHz/cm2, 10 tracks per jet (mean value of poisson distribution) • Jet area: 10x10 pixels • Sensor thickness = 100 um, Track angle = 20° • No charge sharing, histogram accumulated in 1000 BX cycles

22. General file strategy • Current output files: • dump every hit transaction into .dat(for debugging)  • dump periodically in separate files statistics on: • generation: • histograms of position of hit pixels  • buffering (Elia Conti) :  • buffer occupancy • lost hits (classified) • Strategy: use a switch in the configuration class of the related environment and set it in the UVM test • DONE for hit configuration object (see slide #13) • DONE for analysis configuration object (see slide #13) • In summary: every output file that can be currently generated has an associated switch to turn the feature on/off through the UVM test