Calibration, monitoring and testing of front-end electronics

The front-end electronics needs a large set of parameters to be defined and down-loaded before it can be used in a normal running mode. Many of these parameters must be determined during special calibration runs. Some parameters must be monitored/optimized during normal running by special software running in the DAQ system or on special processors spying on event data.

A dedicated document deals with these aspects of the LHCb front-end electronics.

Monitoring triggers

Special triggers ( monitoring, zero bias, random, no bunch crossing, etc. ) will be required at regular intervals to monitor the correct function of the front-end and the use of correct parameters ( pedestals, threshold, gain, noise, etc). These triggers should not require any special handling in the L0 part of the front-end as it will be impossible to inform the L0 electronics, on an event by event basis, the special status of these triggers.   In some detectors it may though be required that special processing is required for such events in the L1 front-end electronics  enable the calculation/monitoring of signal pedestals and thresholds. To inform the L1 electronics about the special status of these triggers the readout supervisor will via a short TTC broadcast inform the L1 front-end about the readout type of each event.

Calibration runs

During calibration runs it will be required that the different sub-detectors can run independently to perform their special calibration procedures. To support this the DAQ system, ECS system and the trigger system must be partitioned into independent sub-systems. The DAQ event building switch and the DAQ processor farm will be configured to work as a set of independent data acquisition systems. To drive the different front-end systems, each partition will be assigned its own readout supervisor which can be configured to generate well defined sequences of resets and triggers. It will also be required that the trigger system is capable of generating special triggers when isolated bunch interactions (no bunch interactions just before and just after) have been detected, to perform an exact and unambiguous phase and clock synchronization to the LHC machine.

Special Calibration signals can be injected into the front-end electronics controlled from the Readout Supervisor via a defined TTC broadcast command.

After individual sub-detectors have been calibrated it will be required to run the front-end system in a calibration/verification mode to verify the correct function of the whole system. In this case the master readout supervisor will generate the required sequences of resets and triggers to run the system. In such a verification run, the front-end of the different sub-detectors must be capable of emulating defined sequences of detector signals by either having predefined signal values store in the L0 pipeline or generate special reference signals on selected detector channels.

Testing of the trigger systems and their interface to the front-end must also be foreseen. The individual trigger subsystems must have their own verification test procedures, but it will also be required to perform extensive verifications of the interface between the trigger systems and the front-end (THIS MUST BE DEFINED BETWEEN SUB-DETECTORS AND THEIR RESPECTIVE TRIGGER SYSTEMS).

Use of consecutive triggers: The use of a sequence of consecutive triggers is very useful to capture detector signals over a time window of several clock cycles during calibration runs. This can be used during the time alignment to the bunch crossings of the LHC machine and also to measure baseline shifts related to induced detector signals.

In-situ hardware testing

In a system with the complexity of thousands of modules it will be required to have extensive hardware testing procedures to verify the correct function of all modules, and in case of a failure precisely identify the cause of the error (at the module level). Parts of the front-end system located in the detector cavern, where only limited access at specific times can be allowed, must be testable remotely to perform quick and efficient repairs.

This will require a whole hierarchy ( component, module, crate, sub-system, system, etc.) of test procedures which can be performed in-situ (while modules located in the system). If a module relies on external intelligence ( ECS or DAQ) for hardware tests the required performance from these must be defined. The required software to run the hardware tests of a module must be considered an integral part of the development of a given module. At the sub-system level, test procedures for the interconnects ( busses, links) must be defined and implemented (e.g standardized optical link test).

At the detailed hardware level the use of JTAG ( IEEE 1149.1 standard) scan paths can obtain very efficient hardware tests. At the component level ( FPGA's , processors, etc.) and at the system level commercial tools are available to support this kind of hardware testing. The use of JTAG also have significant advantages during debugging, design verification and production testing ( in-circuit testing and probing in many cases excluded because of the high component density and the use of modern SMD packages).

This page was last modified by JC on 10 May, 2006 . This page has been accessed number of times.