VEPIX53 Simulation and Verification Environment:Hit generator
Sara Marconi, Elia Conti, Jorgen Christiansen, Pisana Placidi
2
• Introduction• Preliminary benchmarking
– Evaluation of commercial tools
• VEPIX53: Verification and Simulation Environment• VEPIX53: Hit generator
– Classes of hits– Monitoring generated hits– Use of the tool for architectural studies
• Conclusion and future work
OUTLINE
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
3
• Very versatile and generic• Different kinds of data sets
– constrained random distributionsto generate realistic (and extreme) pixel hits and triggers
– particle hits from externalMonte Carlo simulationsand sensor simulations
– mixed data
• Automated verificationfunctions
• Simulation of alternativepixel chip architectures atincreasingly refined level asdesign progresses [J. Christiansen, M. Garcia-Sciveres, RD53 proposal, 2013]
Proposed simulation framework for RD53Introduction
• Hardware Description and Verification Language (HDVL): SystemVerilog– standardization, reusability Universal Verification Methodology (UVM) library
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
4
Preliminary benchmarking - Evaluation of commercial tools (I)
• Simulation performance is one of the main issues of the framework
• A study has been carried out in order to compare different simulators that are a reasonable option:
− Vendor A− Vendor B
• In order to obtain meaningful results,a fully developed and specific OVM-Verification Environment and Pixel Chip has been used (FEI4_B provided by ATLAS)
• Both (partial) gate level and RTL model have been used for the DUT
• The comparison has been done on the time spent by the simulator in:
1. Compilation of libraries2. Elaboration of the design hierarchy3. Actual Simulation
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
5
Vendor A Vendor BMachine Intel(R) Xeon(R) CPU X5680
@ 3.33GHz(6667 bogoMips)
Intel(R) Xeon(R) CPU X5677 @ 3.47GHz (6916 bogomips)
Gate level(mostly)
RTL level(mostly)
Gate level(mostly)
RTL level(mostly)
Compilation time ~12s ~12s ~ 4s (3x) ~ 4s (3x)
Elaboration time ~1min50s (5x)
~1min50s (5x)
~10min(DUT)
~10s (TB)
~10min(DUT)
~10s (TB)
Simulation time:run 80us ~2min10sec ~1min30s ~ 30s (4x) ~ 30s (3x)
run next 80us ~1min ~1min ~ 10s (6x) ~ 10s (6x)
Memory usage - - 2732.9M total
2164.9M total
• Detailed comparison:
Preliminary benchmarking - Evaluation of commercial tools (II)
• A non negligible difference has been observed in terms of elaboration time and of simulation time
• The tool used assures good simulation performance
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
6
• DUT: behavioral, time-based description of a simple pixel chip• UVM verification components connected to interfaces defined in DUT
– hit generation and injection– monitoring of pixel chip input and output– conformity checks and statistics collection
• SystemVerilog interfaces currently defined:
TRANSACTION LEVEL
Hit interface
• Analog input hit signal
Trigger interface
• Input trigger signal
Readout interface
• Pixel chip output
Analysis interface
• Virtual flag signals related to DUT status for statistical information collection (dead time, buffer occupancy, …)
VEPIX53: Verification Environment (I)
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
7
VEPIX53: Verification Environment (II)
• An environment for each interface:– hit environment– trigger environment– readout environment output monitoring– analysis environment conformity checks and statistics collection
top env
DUTPixel Chip Harness
top virtualsequencer
Pixel Chip
hit env
triggerenv
top level tests
Pixel Chip InterfacesClock/resetgenerator
trigger hit analysis readout
readout envanalysis env
BEHAVIORALTIME-BASED
UVM VERIFICATION COMPONENTS input stimuli injection, monitoring and
statistics collection
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
8
VEPIX53: Verification Environment (III)
• An environment for each interface:– hit environment– trigger environment– readout environment output monitoring– analysis environment conformity checks and statistics collection
top env
DUTPixel Chip Harness
top virtualsequencer
Pixel Chip
hit env
triggerenv
top level tests
Pixel Chip InterfacesClock/resetgenerator
trigger hit analysis readout
readout envanalysis env
BEHAVIORALTIME-BASED
UVM VERIFICATION COMPONENTSFOCUS of my current work
input stimuli injection, monitoring and statistics collection
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
9
VEPIX53: Hit generator – Classes of hits (I)
Classes of hit generated at each BX:1. Single tracks
- randomly distributed in the pixel chip- variable number of hit pixels per cluster- at a given angle
2. Loopers - low energy particles- single track crossing at around 90°
3. Jets- multiple clusters concentrated in a given area- can be seen as multiple tracks- clusters can be overlapping
4. Monsters- very “long” tracks
5. Noise hits- not correlated with tracks
Definition of “hit”?- time (BX - with possibly random delay to be added)- random amplitude (TOT or charge)
Interaction point
Sensor
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
10
VEPIX53: Hit generator - Classes of hits (II)
1.Single tracks• Defined parameters:
– track rate per cm2
– track angle (position in detector)– level of charge sharing (LEV_ZERO/ONE)
– percentage of hit pixels in charge sharing envelope
• Examples of generated clusters:1) Square (track angle = 90°)
charge sharing % hit pixels: 10% (a), 50% (b), 80% (c), 100% (d)
Interaction point
Sensor
(a) (b) (c) (d)
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
11
VEPIX53: Hit generator - Classes of hits (III)
1.Single tracks• Defined parameters:
– track rate per cm2
– track angle (position in detector)– level of charge sharing (LEV_ZERO/ONE)
– percentage of hit pixels in charge sharing envelope
• Examples of generated clusters:2) Elongated (lower track angle)
charge sharing % hit pixels: 10% (a), 50% (b), 80% (c), 100% (d)
Interaction point
Sensor
(a) (b) (c) (d)RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
12
2. Loopers• Defined parameters:
– looper rate per cm2
– level of charge sharing
Square loopers (1x1)
VEPIX53: Hit generator - Classes of hits (IV)
Interaction point
Sensor
RD53 WG3 – 4th Meeting during collaboration days
13
VEPIX53: Hit generator - Classes of hits (V)
3. Jets• Defined parameters:
– jet rate per cm2
– average tracks per jet (poisson distribution)– jet area (n.pixels)– track parameters for each track
Interaction point
Sensor
JET
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
14
Monster on z direction Monster on ϕ direction
All graphical results obtained from simulation output files (Matlab)
Interaction point
Sensor
4. Monsters• Defined parameters:
– monster rate per cm2
– monster direction (z or ϕ)
VEPIX53: Hit generator - Classes of hits (VI)
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
15
• The hit subscriber is responsible of dumping/analyzing generated hits (hits are therein accumulated)
• It is possible to choose between different levels of detail• Defined switches for output files:
– dump each bx – dump histograms– level of monitoring of actual hit rate (NONE/ONLY_TOTAL/DETAILED)
hit histo-grams
VEPIX53: Hit generator - Monitoring generated hits (I)
hit env
hit mastersequencer
hit master seq lib
hit master agent
hitmap file
hit monitor
hit master driver
hit subscriber
stati-sticsfile
hit histo-grams
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
16
• Example of simulation output: histograms- Hit rate: 2 GHz/cm2- Full pixel matrix (hit generation): 512x512 pixels, pixel size 50x50 µm2, Sensor thickness: 100 µm- Simulation run for 500,000 BX cycles- tracks at 90° angle
VEPIX53: Hit generator - Monitoring generated hits (II)
Uniform distribution of generated hits across the full pixel matrix observed
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
17
• Example of simulation output: detailed hit rate monitoring- Full pixel matrix (hit generation): 512x512 pixels, pixel size 50x50 µm2, Sensor thickness: 100 µm- DUT (subset under study): 4 x 4 PR- Simulation run for 100,000 BX cycles- Simultaneous generation of tracks (track rate:1GHz/cm2), loopers (looper rate:2GHz/cm2), jets (jet
rate: 500MHz/cm2, 2 tracks per jet), monsters (monster rate:7MHz/cm2) and noise hits (noise hit rate:2GHz/cm2)
VEPIX53: Hit generator - Monitoring generated hits (III)
Observed hit rates per cm2 match with expected ones
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
18
• The hit generator is currently used for the study of buffering architectures
• DUT: it contains a group of pixel unit cells (PUCs) of parameterized size Pixel Region (PR)
• Two architectures have been implemented so far– independent PUC buffers– shared zero-suppressed FIFO
• Preliminary results have been obtained and will be presented– Refer to upcoming talk from Elia Conti: 11/4/2014 11:00, Salle Curie
(https://indico.cern.ch/event/296570/session/8/contribution/16)
VEPIX53: Hit generator - Use of the tool for architectural studies
indipendent PUC buffers shared zero-suppressed FIFO
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
19
Conclusion and future work
VEPIX53 v1.0 up and running in RD53 WG3 repository– bit.ly/rd53wg3 (request access to Tomasz Hemperek)– a realistic hit generator has been implemented inside the framework– we now have an “engine” to use for architecture study– preliminary results will be presented
➔ Further developments on the DUT:– more buffering architectures will be implemented (e.g. FE-I4 scheme)– replication of PRs in pixel chip for further buffering study and arbitration
study– alternative descriptions of pixel chip could be considered
➔ Further developments on the Verification Components:– integration with hit patterns from physics simulations– refinement of the hit generation model– more quantities to be monitored– reference model to be improved in generality/flexibility– integration of graphical analysis in the framework (C++ interfacing)
RD53 WG3 – 4th Meeting during collaboration days – Sara Marconi
20
BACKUP SLIDES
21
• In order to keep hit generation as general as possible a simple ToT converter module has been defined which abstracts the behavior of the analog front-end
• Current ToT converter does not produce time-walked hits
Pixel Unit Cell (PUC)
DigitalPUC
ToTconverter
ANALOG HITSDISCRIMINATOR
OUTPUTS ToAToT
PIXEL BUSY FLAGS
Class-based SystemVerilog Verification Environment – DUT (II)
22
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)
2323
• 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
1) NONE: the statistics_file.txt is NOT GENERATED at all2) ONLY_TOTAL: the file contains only info on observed TOTAL HIT RATE
PER CM2 (possibly coming from different sources)3) DETAILED: the file contains info on both TOTAL HIT RATE PER CM2 and
CLASSIFIED HIT RATE PER CM2 depending on the source:a) ONLY TRACKSb) ONLY LOOPERSc) ONLY JETSd) ONLY MONSTERSe) 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
Configuring the monitoring level
24
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
Charge Sharing
Previous
Loopers, Jets, Monsters and Noise Hits parameters
25
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?A. 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 )
B. Observed hit rate per cm2
• Different levels of monitoring have been defined:• NONE , ONLY_TOTAL, DETAILED
26
Hit environment structure (I)
hit env
hit mastersequencer
hit master seq lib
hit master agent
hit _config
hit masterconfig
hit monitor
hit master driver
• Basic hit environment structure• when no switch for output files is active• Only master agent with:
• sequencer• driver• monitor
27
Hit environment structure (II)
hit env
hit mastersequencer
hit master seq lib
hit master agent
hit _config
hit masterconfig hit
map file (each BX dumped)
hit monitor
hit master driver
hit subscriber
• 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 histo-grams
stati-sticsfile
28
Hit environment structure (III)
hit env
hit mastersequencer
hit master seq lib
hit master agent
hit _config
hit masterconfig
hitmap file (each BX dumped)
hit monitor
hit master driver
hit subscriber
• If DETAILED monitoring on hit rate is activated separate ports towards the subscriber are used and separate histogram accumulation is performed
hit histo-grams
stati-sticsfileNEW
TOTALTRACKSLOOPERS
JETS
NOISE HITS
MONSTERS
29
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• monster rate = 7MHz/cm2
(1 monster per BX)• PHI direction
• noise hit rate = 100MHz/cm2
30
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
31
The VEPIX53 Verification Components – Conformity checks and statistics collection
• Reference model: pixel chip output prediction• Scoreboard: conformity checks between predicted and actual output
(comparator matches/mismatches reported in log file)• Lost hits subscriber: classification of lost hits (PUC busy/PR busy)• Buffer subscriber: histogram of PR buffer occupancy
analysis env
analysis master agent
analysis monitor
analysis reference model
analysis scoreboard
hittrigger readout
analysis buffer subscriber buffer
occupancyoutput file
analysis lost hits subscriber lost hits
output file
32
The VEPIX53 DUT
• Pixel chip contains a group of pixel unitcells (PUCs) of parameterized size Pixel Region (PR)
• Pixels in a PR share part of digital logic• Main pixel chip functions:
– conversion of hits intodiscriminator outputs
– computation of hit time of arrival (ToA)and amplitude (time over threshold, ToT)
– trigger selection– column arbitration
• Our current focus: study ofbuffering architectures
• 2 architecturesimplemented so far:– independent
PUC buffers– shared
zero-suppressedFIFO