sct characterisation requirements

Peter W. Phillips

SCT/Pixel RODDAQ workshop, CERN, February 2002

SCT Characterisation Requirements

Peter W PhillipsRutherford Appleton Laboratory

Gareth MoorheadThe University of Melbourne

Peter W. Phillips


Contents

•Abstract•Expert Characterisation and Debugging Mode•Components and Communication•Requirements•Controller Actions•Operator Actions•Parameters available to the Controller•Parameters available to the Operator•Triggers, Bursts, Scans and Occupancy data•Examples•References

Peter W. Phillips


Abstract

SCT modules have complex behaviour depending on their environment and radiation history, and are highly configurable, requiring extensive characterisation to optimise performance. Characterisation of modules and systems of modules is a process involving successive adjustment of settings both on- and off-module, the measurement of physical and performance parameters, and the analysis of results.

We discuss the functionality needed by expert operators during the detailed characterisation, validation and debugging of large systems of modules, particularly during the commissioning of major SCT macro-assemblies and in ATLAS. Key requirements are the availability during the execution of the characterisation process of intermediate results and analyses, and of communication with various parts of the DAQ and DCS systems. Furthermore, since each module may have significant interactions with its neighbours and the rest of the system, the characterisation process will require system-wide coordination of measurements.

Peter W. Phillips


Expert Characterisation and Debugging Mode (1)

The SCT requires a system for the characterisation and debugging of systems of modules controlled and read out using SCT RODs. We expect this facility to be implemented using, where possible, services provided by the Online packages of DAQ-1 and by the mainstream SCT-Pixel ROD DAQ, but a significant extension of these facilities may be required.

One possibility is that this so-called Expert or Characterisation Mode is a special type of DAQ-1 “run” entered from the Configured state of the Run Control utilising services of the running DAQ system. Another possibility is that it runs as a completely stand-alone application requiring only synchronisation of notification of the correct Idle-Ready state of the system for hand-over of control. In this second option, there would be much re-use of SCT-Pixel ROD DAQ code at Compile time and less use of running services. With a few specific exceptions, the initial system start-up would always be performed by DAQ-1 as for normal running.

Peter W. Phillips


Expert Characterisation and Debugging Mode (2)

This is expected to be used by SCT expert operators for:

The Characterisation and Validation of the performance of individual modules upon their installation in a large-scale system.The Characterisation of systems of modules with particular emphasis on coherent effects and the interaction of modules with their environment.The execution of detailed investigations which may be required at systemtests and commissioning facilities, but are not expected to be generally required in ATLAS. (Experience suggests that there will be many special and one-off studies…)The development of procedures later to be incorporated into automated calibration activities.The interactive debugging of problems, both at the module level and at the system level.The provision of an ‘expert mode’ in ATLAS for the use of on-call SCT shift personnel.

Peter W. Phillips


Not a Calibration run!

In contrast, a standard SCT Calibration Run will ultimately become a fully automated procedure. Such a procedure can, and will, be frequently executed by the non-expert ATLAS shift crew without detailed understanding of its effects or its implementation.

Expert Characterisation and Debugging Mode will differ from a standard run types in that it should provide an operator interactive environment allowing an expert operator to execute an arbitrary sequence of actions from a range of possible standard actions, to receive resulting occupancy data occupancy, to perform analysis, and then to continue with more actions depending on the results.

Peter W. Phillips


Components

• We expect that such a mode would require two types of component (without specifying their implementation):– An Operator Environment, possibly running on the

Online PC, but potentially in one or more dedicated PCs, providing interactivity and analysis.

– A method for passing new lists of actions to Interactive Controllers running on the ROD crate processors handling direct interaction with the RODs and TIMs via the intermediate libraries in direct response to messages from the operator environment. Such interactive controllers could be implemented within the standard crate controller environment with the addition of a communication mechanism, or could be implemented as standalone applications which never-the-less reproduce the standard controller functionality re-using as much code as possible.

Peter W. Phillips


Communication

Communication between the Operator Environment and multiple instances of the Interactive Controllers is of two types:

Short messages for control and acknowledgment, with the possibility to broadcast system-wide requests.

Occupancy Data collected from the RODs by the Controller sent as required to the Operator Environment for analysis.

With these definition and assumptions, we can specify requirements.

Peter W. Phillips


Requiremements (1)

• The Operator Environment shall provide a general-purpose command-line interface for the execution of individual actions or of a script or macro. A specialised GUI is not necessary.

• Actions can be sent to the controllers as single items or as lists to be executed sequentially, where necessary with global timing and event coordination.

• The Operator Environment shall provide the analysis functionality of a programming language.

• The Operator Environment shall provide for the general purpose graphical presentation of numerical results including those generated interactively.

Peter W. Phillips


Requiremements (2)

• The Operator Actions may involve communication with one or many Interactive Controllers, with the Trigger, Timing and Control (TTC) system through the SCT Master TTC Crate, with the Detector Control System using the Detector-DCS Communications package of the Online system.

• The Interactive Controllers running in each ROD crate processor receive and execute Action requests sent by the Operator Environment, returning messages and, when requested, occupancy data blocks.

• The Actions will be a well-defined set of possible activities mapping closely onto the functionality implemented for the standard SCT controllers via the intermediate libraries.

Peter W. Phillips


Requiremements (3)

• The Interactive Controllers are not expected to change rapidly once the basic set of actions is well established. Flexibility is built into the system at the Operator level.

• The Interactive Controllers shall provide for the coherent execution of actions across many modules by coordinating the configuration of actions and the control of TTC signals, for example, to allow system-wide simultaneous triggers, or system-wide re-configuration of all modules between bursts of triggers.

• The Action message shall implement a scope specification allowing for each action to be requested at all appropriate levels: an individual strip, chip or module or across the whole system.

Peter W. Phillips


Requiremements (4)

• Definition of whether a Partition, Crate, ROD or Module is present in the system is by configuration of the Database or at the level of Run Control, not inside the Expert Characterisation mode.

• Moderation of the effect of action requests shall be by Control Parameters. For example, modules or individual chips may be marked as Inactive-in-Scans such that scanned variables are not changed for those specific chips or modules during scans but the modules are still read out. This scheme could be further developed to allow families of modules, eg, the nth in each cooling loop, to be affected distinctly.

Peter W. Phillips


Controller Actions (1)

• Set Control Parameters (control parameters are set immediately)

• Get current Control Parameter settings

• Publish the complete Control Parameter class contents

• Configure Module Parameters (module parameters are not set until the sending of the necessary slow commands is initiated and completes)

• Initiate transmission of Module Parameter slow commands

• Report Status of slow command transmission

• Report current Module Parameter settings

• Publish the complete Module Parameter class contents

Peter W. Phillips


Controller Actions (2)

• Execute a single Burst

• Report Status of Burst execution

• Publish Burst Occupancy Data objects

• Configure Scan Sequences

• Execute Scan Sequences

• Report Status of Scan Sequences execution

• Publish Scan Sequence settings

• Publish Scan Occupancy Data objects

Peter W. Phillips


Operator Actions

• Set system-wide Timing Parameters

• Get system-wide Timing Parameters

• Request setting of Module DCS parameters

• Request getting of Module DCS parameters or readings

• Request setting of non-module-specific DCS parameters

• Request getting of non-module-specific DCS parameters or readings

• Get DCS alarms status

The Operator Environment shall also permit implementation of special actions for local hardware, e.g., for X-ray survey.

Peter W. Phillips


Parameters available to the Controller

• Burst Control Parameters• System Control Parameters (includes master TIM)• Partition Control Parameters• Crate Control Parameters• BOC Control Parameters• ROD Control Parameters• System Mapping Parameters• Module Parameters• ABCD Chip Parameters

Peter W. Phillips


Parameters available to the Operator

• Burst Control Parameters• System Control Parameters (includes master TIM)• Partition Control Parameters• Crate Control Parameters• BOC Control Parameters• ROD Control Parameters• System Mapping Parameters• Module Parameters• ABCD Chip Parameters• System DCS Parameters• Partition DCS Parameters• Module DCS Parameters

Peter W. Phillips


Burst Control Parameters

• trigger_source Trigger source• trigger_type Trigger type (L1A, nL1A, CAL+L1A etc.)• n_l1a_per_trig number of L1A per single execution

of a trigger of type trigger_type• n_trigs_per_burst number of triggers• n_trigs_to_throw number of events to throw away

(if n_l1a_per_trig>1)• l1a_spacing nBCOs between triggers

(if n_l1a_per_trig>1)• burst_duration Duration of Burst (milliseconds)• (in the case burst length is set by duration rather than trigger count)• do_cal_loop Loop over the four calibration buses

and merge histograms as appropriate

Peter W. Phillips


System Mapping Parameters

• module_name Module name / serial number

• partition partition number

• primary_crate Primary clock/command path

• primary_rod

• primary_channel

• redundant_crate Redundant clock.command path

• redundant_rod

• redundant_channel

• active Does module participate in scans?

• occupancy_type occupancy type

• publish_data publish occupancy data

Peter W. Phillips


Module Parameters

Module Configuration– ABCD_chip[12] ABCD Chip Parameters (see next slide)

– update_config Has the chip configuration changed since the

configuration bitstream was last sent?

– update_trims Has the TrimDAC configuration changed since

the trim bitstream was last sent?

– select present state of select line

– bypass predefined bypass configurations, covering

all possibilities

– known_mask predefined mask configurations, used during testing

– timeout Timeout [ms]

Peter W. Phillips


ABCD Chip Parameters

Control Parameters– active Does this chip participate in scans?

Calibration data– c_factor capacitor correction factor

– rc_function Response Curve function type

– rc_params[3] Response Curve data

Configuration Register - Direct– cal_mode select cal line (0-3)

– compression select data compression criteria (0-3)

– trim_range set trim range (0-3)

– edge_detect set edge detect bit (0-1)

– send_mask set send mask bit (0-1)

– accumulate set accumulate bit (0-1)

Peter W. Phillips


ABCD Chip Parameters

Configuration Register - Abstract– role acts upon master, end and redundancy bits

Other Registers - Direct– vthr threshold DAC

– vcal calibration DAC

– delay strobe delay register

– preamp preamp current DAC

– shaper shaper current DAC

– mask mask register (128 * 1 bit)

– trimDAC trim DAC (128 * 4 bits)

Other Registers - Abstract– qthr set threshold in fC (according to response curve)

– qcal set calibration level in fC (with C correction factor)

Peter W. Phillips


Module DCS Parameters

• Module serial number

• Mapping DCS <> DAQ identifier

(as requested)– Select_set

– Vdet_set Idet_limit

– HV_ramp_rate

– Vdd_set Idd_limit

– Vcc_set Icc_limit

– Vpin_set

– Vvcsel_set

– Overcurrent_reaction_time

– Tlimit plus any additional limits set in software

• Request_Hard_Reset

Peter W. Phillips


Module DCS Parameters

(as monitored)• Vdet Idet

• Vcc Icc Vcc_output Vcc_return_sense

• Vdd Idd Vdd_output Vdd_return_sense

• Vpin Ipin

• Vvcsel Ivcsel

• T0 T1

• T_LV_card T_HV_card

• T_power_pack I_power_pack

• LV_channel_status LV_card_status

• HV_channel_status HV_card_status

• Power_pack_status

• Date and Time of last update

Peter W. Phillips


Triggers

Triggers are sequences of ABCD fast commands including at least one Level 1 Accept, but also may include, for example, Calibration Strobe, Pulse Input, Soft Reset or BC Reset.

Triggers may originate at the ROD, at the local TIM, at the Master TIM or from the external TTC system. In the case triggers originate in the ROD they are not synchronous across any wider part of the system than one ROD, but can be easily despatched in well-defined numbers. However, in the case the triggers do not originate in the ROD, the numbers of triggers in a burst must be controlled or counted at a crate or system-wide level complicating book-keeping at the ROD level.

The parameters trigger_type and trigger_source which should be the same across all elements of the system control the type of burst, including bursts executed as parts of scans or sequences of scans, as well as moderating the actions taken by each type of controller.

Peter W. Phillips


Bursts and Scans

A burst is a programmed sequence of triggers resulting in occupancy data.

A scan is a sequence of bursts separated by changes to at least one local parameter. Scans may be selected from a range of standard scans, or can be assembled from an arbitrary sequence described by the type and new setting of the variable to be changed at each burst.

Scans are always executed according to the currently defined trigger type, with the responsibility for initiating triggers resting with the currently defined trigger source.

Most of the commonly scanned variables can be found in the Module Parameter list, but this is not fully inclusive. It will sometimes be necessary to study module performance as a function of the parameters of BOC, TIM, or even certain DCS parameters such as VcSEL drive currents. Clearly in the latter case, the scan is no longer confined to the scope of the controller.

Peter W. Phillips


Occupancy Data

Occupancy Data is accumulated by ROD DSPs from a sequence of events and transmitted as a collection as required. Occupancy data formats will be determined by DSP primitives, and can be independent of the scan or burst types.

We can envisage several types of occupancy data including:

– Concatenated sequences of raw events for offline analysis;

– Simple histograms of the number of hits per channel

– Histograms of the number of hits per channel as a function of one (or more) scanned variable(s)

– Computed histograms, for example, the 50% transition point and/or width of an s-curve in a threshold or calibration amplitude scan

– Histograms of error rates as a function of one or more scanned variables (OK, not strictly occupancy data, but useful whilst tuning the performance of the optical datalinks)

Peter W. Phillips


Example 1 - Setting the Strobe Delay

The Strobe Delay register adjusts the timing of the charge injection pulse. The step size varies strongly as a function of temperature, hence it is recommended that the strobe delay setting be checked before any measurement involving charge injection.

Possible Algorithm:• Set threshold to 2fC (from the response curve)• Set Injected charge to 4fC• Scan Strobe Delay from 0 to 63, step size 1• Fit the rising and falling edges of the summed strobe delay

peak for each chip• Calculate a point one quarter of the distance between the two

edges• Set the Strobe Delay register of each chip to the calculated

value

Peter W. Phillips


Example 1 - Setting the Strobe Delay

Peter W. Phillips


Example 2 - Determination of the Response Curve

• A series of threshold scans are recorded for different values of injected charge.

• The complementary error function is fitted to each scan to yield values for the point of 50% efficiency and sigma for each channel.

• For each channel, a functional fit is made to the matrix of 50% values, from which the gain and offset is calculated. The sigma values are divided by the gain to estimate the input noise of the channel.

• For each chip, a functional fit is made to the average of the 50% values for each charge value across all the channels. This is the response curve which is used to set up the operating threshold for the chip in the experiment.

• Estimates of the gain and noise of each chip are also calculated.

Peter W. Phillips


Example 2 - Determination of the Response Curve

Peter W. Phillips


Example 3 - The Fastest Possible Test!

During macro-assembly it will not always be convenient to cool down the structure before making the first test of a newly connected module: cooling down takes several hours!

How quickly can we demonstrate the correct connection of a module? Is it so fast (<10s?) that we can run without cooling? – Turn on power– Configure for primary clock/command– Read few events (SendID mode?)– Record V, I (including diagnostics)– Turn off power– Check events for errors, voltages and currents for

anomaliesThis is one of the few scenarios where the standard DAQ-1

system startup may not be adequate!

Peter W. Phillips


Where we’re coming from: SCT module test DAQ (1)

JAVAapplication

DatabaseResults File

(Text)

Analysis Macro

Test Macro

ST.cpp

ROOTCINT

stdll

Sequence Macro

RAW DATA(ROOT FILE)

Plots(Postscript)

Histograms(ROOT FILE)

CLOAC

MuSTARD

SLOG

SCTHV

SCTLV

VME

System Configuration File

Module ConfigurationFiles

Peter W. Phillips


Where we’re coming from: SCT module test DAQ (2)

• The basic routines to communicate with each VME board are implemented in the form of a static library written in C. Higher level functions have been implemented in a small number of C++ classes that are linked together with the static libraries, and some of the ROOT libraries, to form the dynamic link library stdll. This is the full extent of the compiled code: everything else runs through the CINT interpreter.

• Within ROOT, the user runs the top-level macro ST.cpp to load stdll, to initialise the system and to present the system menu. Each tests is implemented in the form of a discrete ROOT macro which may be run by pressing a button within the menu system or by direct user input at the command prompt.

• The test macro may directly modify the state of the system of modules as a result of the test.

Peter W. Phillips


References

• Characterisation Requirements Document:http://sctpixel.home.cern.ch/sctpixel/Workshop2002/charac007.pdf

• Operation of Barrel Modules - Present and Future:http://hepwww.rl.ac.uk/atlas-sct/documents/Operating_modules_06.pdf

• Electrical Tests of SCT Hybrids and Modules: http://hepwww.rl.ac.uk/atlas-sct/documents/Electrical_Tests.htm

• SCT Module Test DAQ home page:http://atlas.web.cern.ch/Atlas/GROUPS/INNER_DETECTOR/SCT/testdaq/testdaq.html

• SCT System Test home page:http://asct186.home.cern.ch/asct186/systemtest.html

sct characterisation requirements

Documents