usbpix software status and plans dr. jens weingarten

USBPix software USBPix software status and plansstatus and plans

Dr. Jens Weingarten

hardware

h/w libraries

Software frameworkSoftware framework

03.05.23Jens Weingarten, Uni Goettingen 2

ROD USBPix

RodDaq SiUSBLib

RodPix

CtrlUSBPixCtrl

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?What is PixLib?


PixModuleGroupPixModule

PixFePixMcc

PixModulePixFePixMcc

PixModulePixFePixMcc

PixScan

PixController

PixConfDBInterfaceRootDB

to application…

to hardware…

Applications: STcontrolApplications: 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 PixDCS)

Applications: ModuleAnalysisApplications: 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)

Hardware interfaceHardware 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.

Why PixLib?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

Available functionalityAvailable 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)

Validation IValidation I


188.7e 217.3e

212.8e428.2e

Threshold and noise results as expected from TurboDAQ.

Validation IIValidation II


FDAC tuning as expected TOT calibration as expected

IssuesIssues


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 investigationA bug, not a feature!

PlansPlans


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

PlansPlans


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 !

TestbeamTestbeam


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


Backup

Why PixLib?Why PixLib?


Calibration

Console

RODDSP code

Histogram server

CASTOR

Analysis Schedule

r

Analysis Tasks

Conn DB Conf DB

CalibResults DB

MetaData DB

DB server

DCS

IS

local storag

e

On-LineOff-Line

A diverse application layer based on PixLib has been/is being developed for ATLAS Pixels, which can be re-used for IBL Synergy

usbpix software status and plans dr. jens weingarten

Documents