1 / 32

VEPIX53: Progress on hit rate monitoring inside the framework

VEPIX53: Progress on hit rate monitoring inside the framework. Sara Marconi. OUTLINE. Monitoring hit rate New output file Configuring the monitoring level Hit environment structure Some simulation results. New output file.

nitza
Download Presentation

VEPIX53: Progress on hit rate monitoring inside the framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. VEPIX53: Progress on hit rate monitoring inside the framework • Sara Marconi

  2. OUTLINE • Monitoring hit rate • New output file • Configuring the monitoring level • Hit environment structure • Some simulation results

  3. New output file • It is possible to generate a new output file (statistics_file.txt) to collect statistics on observed hit rates per cm2, at the same time: • for the all matrix • for the simulated DUT sub-matrix (so far: 2x2 PR) • What is printed in the file? • Parameters than have been set in the test: • hit configuration object parameters (generation matrix size, pixel chip area, etc.. – see top_test3.sv file ) • hit sequence parameters (number of BXs, sensor thickness, track angle, charge sharing level, track/looper/jet/monster/noise hit rates per cm2, etc.. – see top_test3.sv file ) • Observed hit rate per cm2 • Different levels of monitoring have been defined: • NONE , ONLY_TOTAL, DETAILED

  4. Configuring the monitoring level • Configuring the monitoring level through the configuration object of the hit environment • switch: DUMP EACH BX • switch : DUMP HISTOGRAMS • number of CYCLES OF ACCUMULATION OF HISTOGRAMS • New switch: LEVEL OF MONITORING OF ACTUAL HIT RATE PER CM2 • NONE: the statistics_file.txt is NOT GENERATED at all • ONLY_TOTAL: the file contains only info on observed TOTAL HIT RATE PER CM2(possibly coming from different sources) • DETAILED: the file contains info on both TOTAL HIT RATE PER CM2and CLASSIFIED HIT RATE PER CM2depending on the source: • ONLY TRACKS • ONLY LOOPERS • ONLY JETS • ONLY MONSTERS • ONLY NOISE HITS • It is reasonable to use the DETAILED level just when running the sequence with tracks,loopers.. (i.e. top_test3) • for top_test1,2 a warning is generated if DETAILED level is chosen 4

  5. Hit environment structure (I) • Basic hit environment structure • when no switch for output files is active • Only master agent with: • sequencer • driver • monitor hit monitor hit env hit master agent hit master sequencer hit master driver hit _config hit master seq lib hit master config

  6. Hit environment structure (II) • The hit subscriber is responsible of dumping/analyzing generated hits (hits are therein accumulated) • Build only if DUMP EACH BX and/or DUMP HISTOGRAMS and/or HIT RATE MONITORING switches are active hit monitor hit env hit master agent hit subscriber hit master sequencer hit master driver hit _config hit master seq lib hit master config hit map file (each BX dumped) hit histo-grams stati- stics file

  7. Hit environment structure (III) • If DETAILED monitoring on hit rate is activated separate ports towards the subscriber are used and separate histogram accumulation is performed hit env hit subscriber hit master agent TOTAL hit monitor TRACKS hit master sequencer LOOPERS JETS hit _config MONSTERS NOISE HITS hit master config hit master driver hit master seq lib hit map file (each BX dumped) hit histo-grams stati- stics file NEW

  8. Some simulation results: test1 • Output example (I) with: • the simple test1 running (with 50% probability of hitting each pixel per each BX) • hit monitoring level : ONLY TOTAL Parameters set from the test Observed hit rate in the 2x2 simulated pixel chip Measured hit rate per cm2 is as expected: 50% probability per BX per pixel => 20MHz per pixel => 20MHz divided by area of single pixel = 873820342537,57 very close to the result

  9. Some simulation results: test3 (I) • Output example (II) with: • more realistic test3 running (sequence generating tracks, loopers, etc..) • hit monitoring level : DETAILED • Hit sequence parameters set from the test: • No charge sharing • sensor thickness = 100 um • track rate = 400MHz/cm2 • 90 deg angle => 1x1 clusters • lopper rate = 100MHz/cm2 • jet rate = 80MHz/cm2 • average 10 tracks per jet • monsterrate = 7MHz/cm2(1 monster per BX) • PHI direction • noise hit rate = 100MHz/cm2

  10. Some simulation results: test3 (II) • Observed hit rates per cm2: • from tracks: ~399 MHz/cm2(whole matrix), ~371 MHz/cm2 (2x2 sub-matrix) • from loopers: ~100 MHz/cm2(whole matrix), ~109 MHz/cm2 (2x2 sub-matrix) • from jets: ~787 MHz/cm2(whole matrix), ~328 MHz/cm2 (2x2 sub-matrix) • ~80MHz/cm2 x 10 tracks per jet • 2x2 matrix cannot be hit by complete jets => lower rate observed • from monsters: ~1707 MHz/cm2(whole matrix), ~1398 MHz/cm2 (2x2 sub-matrix) • total hits = 256 (monster size ) x number of BX cycles • from noise hits: ~100 MHz/cm2(whole matrix), ~109 MHz/cm2 (2x2 sub-matrix) • Results seem quite adherent to imposed rates

  11. Some simulation results: test3 (III) • Other output (III) example: • test3 running with same rates as previous (for 50000 BX) • hit monitoring level : DETAILED • Changing track angle to 30 degrees => 4x1 clusters, no charge sharing • Observed hit rates per cm2: • from loopers, monsters and noise hit ~ SIMILAR • from tracks: • ~1597MHz/cm2 (whole matrix) with expected 400x4=1600MHz/cm2 • ~612 MHz/cm2 (2x2 sub-matrix) – lower since 1 track => max 2 hit pixels (instead of 4) • from jets: • ~3045MHz/cm2(whole matrix) with expected 80x10(tracks per jet)x4= 3200 MHz/cm2 • 2x2 matrix cannot be hit by complete jets => lower rate observed

  12. Some simulation results: test3 (IV) • Output example (IV): • test3 running for 100000 BX • hit monitoring level : DETAILED • Testing low rates (different algorithm from rates that cause less than 1 track/looper/etc.. per BX) • first simulations: systematically higher rates observed • with NON-ZERO but quite low rates (ex: 100kHz/cm2) the “percentage” of BX cycles where a track/looper/etc.. was being rounded off to an int, causing in some cases a non-negligible factor) • Modified: • instead of using 100 as a total (%), 100000 (%000) has been used • to obtain significant effect while rounding off one should go with rates 1000 lower) • Running with all rates fixed to 100kHz/cm2 • Results on next slide

  13. Some simulation results: test3 (V) • Observed hit rates per cm2: • from tracks: ~408 kHz/cm2(whole matrix), ~0 kHz/cm2(2x2 sub-matrix) • expected: ~100kHz/cm2 x 4 pixel per cluster = 400kHz/cm2 • from loopers: ~98 kHz/cm2(whole matrix), ~0 kHz/cm2(2x2 sub-matrix) • from jets: ~3764 kHz/cm2(whole matrix), ~ 0 kHz/cm2(2x2 sub-matrix) • expected ~100kHz/cm2 x 10 tracks per jet x 4 pixel per cluster = 4000 kHz/cm2 • from monsters: ~24.7 MHz/cm2(whole matrix), ~17.5 MHz/cm2 (2x2 sub-matrix) • expected ~100kHz/cm2 x 256 pixel per monster = 25.6 MHz/cm2 • from noise hits: ~95 kHz/cm2(whole matrix), ~0 kHz/cm2 (2x2 sub-matrix)

  14. Backup slides

  15. 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

  16. 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

  17. 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)

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

  19. 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)

  20. 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

  21. 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)

  22. 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

  23. 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

  24. 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  • Direction of the monster (Z/PHI)  • 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

  25. 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)

  26. 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

  27. 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)

  28. 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

  29. 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

  30. 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

  31. 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

  32. Supporting TLM model of the chip • Still 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

More Related