USBPix software status and plans Dr Jens Weingarten

USBPix software status and plans Dr. Jens Weingarten

Software framework Applicati ons changes needed (not necessary for a lab test system) Pix. Lib Software is based on a collection of C++ classes (Pix. Lib) that encapsulate the functionality of the Pixel hardware (both Pixel module and readout hardware). Pix. Lib: : Pix. Controller Rod. Pix Ctrl USBPix Ctrl new h/w libraries Rod. Daq Si. USBLib hardware ROD We started development for USBPix from a Pixel DAQ version from about 3 years ago, not to have to use full infrastructure. Applications layer needs very few changes to work with single FE-I 3. Can otherwise be used out of the box. New hardware necessitated new interface class, based on FPGA and micro-controller firmware provided by bonn. USBPix Jens Weingarten, Uni Goettingen 2 02. 10. 2020

What is Pix. Lib? to application… Pix. Conf. DBInterface Root. DB Pix. Lib is the functional layer of the current ATLAS Pixel DAQ software. Testsystem sw == Detector sw • represents FE hardware functionality Pix. Module. Group Pix. Module Pix. Fe Pix. Scan Pix. Fe Pix. Mcc • DB interfaces for configuration and scan data Pix. Controller • custom, ROOT-based DB to hardware… Jens Weingarten, Uni Goettingen • abstract interface to DAQ hardware actual hardware (i. e. ROD or USBpix) inherited from base class 3 02. 10. 2020

Applications: STcontrol • load/edit/save FE configurations • configure/reset FE • configure/execute scans (some pre-defined, no hidden presets in scan configuration) • view/analyze/plot results (optimized for low memory usage) • control external hardware (e. g. power supplies, meters, probestation, etc. ) • measure DCS quantities through USB or GPIB (e. g. on-board ADCs, SMUs, etc. ) e. g. probecard (inherited from Pix. DCS) Jens Weingarten, Uni Goettingen 4 02. 10. 2020

Applications: Module. Analysis • display contents of results file (memory saving) • load selected/all items in a file • various pre-defined analyses: • threshold/noise distributions • crosstalk • spectrum from TOT data • refitting of scan data (s-curves, TOT calibration, etc. ) • comparisons between scans (difference, ratio, correlation of quantities) • uses ROOT (plot options, command line, macro execution) Jens Weingarten, Uni Goettingen 5 02. 10. 2020

Hardware interface There is one single class in Pix. Lib (Pix. Controller) that encapsulates the hardware interface. This class sends FE configurations, executes scans, downloads histograms, and sets the run mode of the system (occupancy, TOT histograms or raw data). For the ATLAS Pixel system the Rod. Pix. Controller was derived from that and uses common ATLAS VME and custom ROD/BOC classes. For the USB system a new USBPix. Controller was derived which uses DLLs provided by Bonn. These encapsulate micro-controller and FPGA functions on the board, allowing execution of one scan loop on the board, histogramming and a raw data mode. The type of controller is determined in higher hierarchy levels by dynamic cast, making it safe and easy to use the same software with both systems. Jens Weingarten, Uni Goettingen 6 02. 10. 2020

Why Pix. Lib? • provides access to complete FE configuration (global and pixel register) • uses custom ROOT-based DB format • can read and write Turbo. DAQ format config files • lots of standard scan algorithms implemented and debugged • used during ATLAS Pixel system test • scan configuration completely accessible easy non-standard scans • modular design will allow for easy transition from single-chip to multi-chip module • Pix. Controller class single h/w dependent component • easy implementation of new hardware through inheritance from base classes • FE-I generations • peripheral h/w: DCS, probestation • (mostly) platform-independent implementation • all developments are compatible with current and future DAQ systems and can be used in the experiment software Jens Weingarten, Uni Goettingen 7 02. 10. 2020

Available functionality Scans • 0 D scans (e. g. digital, analog scan) and 1 D scans (e. g. threshold scan) available • every FE DAC available as scan parameter • ‘DCS’ scans: IV curve, DAC calibration using GPIB or USB interfaces • 2 D scans (e. g. TDAC/FDAC tuning) available • timewalk and intime threshold scan under investigation (hardware timing resolution > 1 ns) • crosstalk and source scan being tested Histograms • occupancy available, all maps for a threshold scan fit into on-board memory • TOT available, TOT_mean and TOT_sigma calculated offline • S-Fit histograms available, calculated on host as post-loop action • no LVL 1 histograms General • strobe duration adjustable • all standard masks available • selftrigger being tested • unavailable ROD functionality caught by exceptions • limitations through USB accesses apparent when downloading data (but saving to disk dominates) Jens Weingarten, Uni Goettingen 8 02. 10. 2020

Validation I 188. 7 e 217. 3 e 428. 2 e 212. 8 e Threshold and noise results as expected from Turbo. DAQ. Jens Weingarten, Uni Goettingen 9 02. 10. 2020

Validation II FDAC tuning as expected Jens Weingarten, Uni Goettingen TOT calibration as expected 10 02. 10. 2020

Issues issue with retrieval of last scan histogram There also some indications of a difference in threshold between STcontrol and Turbo. DAQ with the same settings problems with DAC setting? under investigation A bug, not a feature! Jens Weingarten, Uni Goettingen 11 02. 10. 2020

Plans Prototype characterisation: • implementation of test-chains should be straight-forward if firmware supports it • will provide access to every configuration bit through standard config interface (‘global’/’pixel register’) • implementation of FE-I 4 class starts soon • change register sizes • adapt Pix. Libs scan mechanisms (possible because FE-I 4 command structure very similar to FE-I 3) • significant changes needed in analysis (histogram sizes hardcoded in some places) • module emulator needed for debugging can be reused for ROD operation • analysis for test-chains to be implemented compare bit-sequences Jens Weingarten, Uni Goettingen 12 02. 10. 2020

Plans Production testing: 1. Wafer level: • • • probestation control is being implemented run standard set of tests and analyses using ‘primitive list’ function (available) creation of a wafermap to be implemented in analysis software (automated analysis plus geographical representation using position from probestation) 2. Module level: • • • single-chip module: done! multi-chip module: should be straight-forward from software side (firmware main construction site) multi-board operation necessary ! Jens Weingarten, Uni Goettingen 13 02. 10. 2020

Testbeam Multi-IO board was designed to be compatible with EUDET trigger-logic-unit integration ‘on DAQ level’ straight-forward; USBPix data producer needed, telescope readout incl. tracking, alignment provided by EUDET experience exists after integration of standard Pixel test system TLU implement data taking mode in USBPix DUT 6 telescope plains Jens Weingarten, Uni Goettingen Beam EUDAB readout 14 02. 10. 2020

Backup Jens Weingarten, Uni Goettingen 15 02. 10. 2020

Why Pix. Lib? A diverse application layer based on Pix. Lib has been/is being developed for ATLAS Pixels, which can be re-used for IBL Synergy CASTOR local storage Calib. Results DB Meta. Data DB Histogram server ROD DSP code Calibration Console Analysis Scheduler Analysis Tasks IS DB server On-Line Off-Line DCS Conn DB Jens Weingarten, Uni Goettingen Conf DB 16 02. 10. 2020