140 likes | 282 Views
VEPIX53 interfaces. Elia Conti, Sara Marconi. Trigger interface and transactions. Contains the physical trigger, represented with a simple yes-no signal Corresponding trigger transactions: Same transaction at generation and monitoring side :
E N D
VEPIX53interfaces Elia Conti, Sara Marconi
Trigger interface and transactions • Contains the physical trigger, represented with a simple yes-no signal • Corresponding trigger transactions: • Same transaction at generation and monitoring side: • Only one field: time reference value corresponding to BX cycle • Sequence generates transactions only if there is a trigger
VEPIX53: Simulation of RTL pixel chip • Starting from the simplest environment top level tests top env analysis env readout env hit env triggerenv top virtualsequencer RTL2TLM analysis RTL2TLM TLM2RTL TLM2RTL RTL2TLM TLM interfaces (i.e. transactions) RTL2TLM readout Clock/resetgenerator RTL interfaces Pixel Chip DUT trigger analysis hit readout • Pixel Chip physical interfaces
Trigger environment and TLM- signalconversion trigger env trigger master agent trigger subscriber trigger master sequencer trigger master driver tlm trigger _config trigger master seq lib trigger monitor sig2tlm trigger master config to analysis env trigger data file trigger master driver tlm trigger if
Trigger environment and TLM- signalconversion • First trial with a TLM interface for trigger environment • conversion into signal done by a tlm2sig driver • monitoring: • so far monitoring signals through monitor sig2tlm • idea is to use a switch for the chip description level (at TLM the tlm driver itself provides info to subscriber and analysis env) • Synchronization: • handled through clock for both the drivers (and the monitor) • it means a clock cycle of difference exists between driver tlm and tlm2sig • Defined switches (trigger config object): • dump_each_trigger • Data dumped by the (added) subscriber into the output text file • monitor_actual_trigger_rate • Observed rate as expected
VEPIX53: a flexible Verification Environment for PIXel chips in RD53 (I) • 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 TRANSACTION LEVEL analysis env top level tests hit env readout env triggerenv top env top virtualsequencer UVM VERIFICATION COMPONENTS Clock/resetgenerator Pixel Chip Harness Pixel Chip DUT hit analysis trigger readout Pixel Chip Interfaces BEHAVIORAL TIME-BASED
VEPIX53: a flexible Verification Environment for PIXel chips in RD53 (II) • 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 TRANSACTION LEVEL analysis env top level tests hit env readout env triggerenv top env top virtualsequencer • 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, …) UVM VERIFICATION COMPONENTS Clock/resetgenerator Pixel Chip Harness Pixel Chip DUT hit analysis trigger readout Pixel Chip Interfaces BEHAVIORAL TIME-BASED • Interfaces are synchronous • clock signal used to handle timing of physical drivers/monitors (clocking blocks)
Hit interface and transactions • Contains a bi-dimensional array of “analog” hit signals that represent the amplitude of the hit that is fed to each PUC of the pixel chip • real analog_hit[PIXEL_CHIP_Z-1:0][PIXEL_CHIP_PHI-1:0] • Corresponding hit transactions: Used at generation side time reference value corresponding to BX cycle associative array of amplitude values Used at monitoring side 2-dimension array of ToA 2-dimension array of amplitude values
Trigger interface and transactions • Contains the physical trigger, represented with a simple yes-no signal • Corresponding trigger transactions: Used at generation side isTrig bit: used to decide whether or not to generate a trigger signal for a certain BX; such a decision is taken depending on the trigger_rate_khz field (used to pass to each transaction the trigger rate specified from the sequence) time reference value corresponding to BX cycle Used at monitoring side such a transaction is produced only if the trigger signal is sensed information related to the time when the trigger has been detected
Readout interface and transactions • Communication with the pixel chip output • Currently contains output signal from column bus • Corresponding readout transactions: Used for independent pixels architecture 2-dimension array of ToA 2-dimension array of ToT Used for zero-suppressed FIFO architecture unique ToA for the hit packet 2-dimension array of ToT Hit map field depending on memory organization
Analysis interface and transactions • Contains virtual flag signals related to DUT status: • ToT_conv_busy • DUT_busy • PR_busy (shared architectures only) • buffer_occupancy • Corresponding analysis transactions: Used for independent pixels architecture buffer overflow flag busy flag (PUC is busy measuring the TOT) busy (PUC is “blind” because digitally processing a hit) flags used to get information on buffer occupancy Used for zero-suppressed FIFO architecture additional busy flag (PR is busy when one or more pixels are fired)
VEPIX53: Simulation of TLM pixel chip top level tests analysis env hit env readout env triggerenv top virtualsequencer TLM interfaces (same) DUT TLM Pixel Chip
Discussion: how to make VEPIX53 support TLM pixel chips • Redefine hit transactions • 1 transaction, full pixel matrix (current) • 1 transaction, hit pixels only • 1 transaction per hit pixel • Equalize generated (driven) and monitored transactions • Leave trigger interface independent / merge with other interfaces that will be defined (e.g. command interface) • Make verification components generic (readout_env and transaction, reference model, scoreboard, …) • Make drivers and monitors independent from clock