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