USBPix software status and plans

1. USBPix software status and plans Dr. Jens Weingarten

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

3. What is PixLib? to application… • PixLib is the functional layer of the current ATLAS Pixel DAQ software. • Testsystem sw == Detector sw • represents FE hardware functionality • abstract interface to DAQ hardware actual hardware (i.e. ROD or USBpix) inherited from base class • DB interfaces for configuration and scan data • custom, ROOT-based DB PixConfDBInterface RootDB PixModuleGroup PixScan PixModule PixModule PixModule PixFe PixFe PixFe PixMcc PixMcc PixMcc PixController to hardware… Jens Weingarten, Uni Goettingen

4. 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, probe- station, etc.) • measure DCS quantities through USB or GPIB (e.g. on-board ADCs, SMUs, etc.) •  e.g. probecard (inherited from PixDCS) Jens Weingarten, Uni Goettingen

5. Applications: ModuleAnalysis • 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

6. Hardware interface There is one single class in PixLib (PixController) 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 RodPixController was derived from that and uses common ATLAS VME and custom ROD/BOC classes. For the USB system a new USBPixController 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

7. Why PixLib? • provides access to complete FE configuration (global and pixel register) • uses custom ROOT-based DB format • can read and write TurboDAQ 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 • PixController 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

8. Available functionality • Scans • 0D scans (e.g. digital, analog scan) and 1D scans (e.g. threshold scan) available • every FE DAC available as scan parameter • ‘DCS’ scans: IV curve, DAC calibration using GPIB or USB interfaces • 2D 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 LVL1 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

9. Validation I 188.7e 217.3e 212.8e 428.2e Threshold and noise results as expected from TurboDAQ. Jens Weingarten, Uni Goettingen

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

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

12. 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-I4 class starts soon • change register sizes • adapt PixLibs scan mechanisms (possible because FE-I4 command structure very similar to FE-I3) • significant changes needed in analysis (histogram sizes hardcoded in some places) • module emulator needed for debugging •  can be reused for ROD operation • analysis fortest-chains to be implemented  compare bit-sequences Jens Weingarten, Uni Goettingen

13. Plans • Production testing: • 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) • 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

14. 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 • implement data taking mode in USBPix 6 telescope plains Beam DUT TLU EUDAB readout Jens Weingarten, Uni Goettingen

15. Backup Jens Weingarten, Uni Goettingen

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