USBPix software status and plans Dr. Jens Weingarten

hardware h/w libraries Software framework Jens Weingarten, Uni Goettingen 2 ROD USBPix RodDaq SiUSBLib RodPix Ctrl USBPix Ctrl PixLib::PixController PixLib Applications new changes needed 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.

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 What is PixLib? Jens Weingarten, Uni Goettingen 3 PixModuleGroup PixModule PixFe PixMcc PixModule PixFe PixMcc PixModule PixFe PixMcc PixScan PixController PixConfDBInterface RootDB to application… to hardware…

Applications: STcontrol Jens Weingarten, Uni Goettingen 4 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)

Applications: ModuleAnalysis Jens Weingarten, Uni Goettingen 5 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)

Hardware interface Jens Weingarten, Uni Goettingen 6 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.

Why PixLib? Jens Weingarten, Uni Goettingen 7 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

Available functionality Jens Weingarten, Uni Goettingen 8 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)

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

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

Issues Jens Weingarten, Uni Goettingen 11 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!

Plans Jens Weingarten, Uni Goettingen 12 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 for test-chains to be implemented  compare bit-sequences

Plans Jens Weingarten, Uni Goettingen 13 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 !

Testbeam Jens Weingarten, Uni Goettingen 14 Beam 6 telescope plains DUT EUDAB readout TLU 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

Jens Weingarten, Uni Goettingen 15 Backup

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