• Keine Ergebnisse gefunden

The TDAQ/PixelDAQ software provides a complex and flexible framework to operate and con-trol the Pixel Detector. This environment is also used to integrate the operation of the IBL in parallel to the current Pixel Detector. Major changes of the PixelDAQ code had to be made in the calibration part which uses scan and configuration methods for the FE chip.

The TDAQ/PixelDAQ system had to be provided for lab setups for the IBL ROD-BOC development phase. Hence, it was extended with an additional local and simplified database with respect to the complex database setup used to operate the complete ATLAS Detector. One simple database file was used to store scan processes and results. A local script was provided to generate controller and chip configuration files for different controllers and FE chips.

In addition, much effort went into the installation of TDAQ at a lab environment. So far, the software was just installed by two experts and first attempts of previous installations failed.

With the urgent need of a TDAQ lab system for IBL this aim could finally be accomplished and several institutes engaged in the IBL project had an own TDAQ installation.

To implement the IBL in the PixelDAQ framework an extra development branch IBLDAQ was split from the PixelDAQ framework used for current detector operation. Since then, at the end of 2010, several developers have been working on the integration of the IBL into this framework. A necessary starting point was the restructuring of the class hierarchy. This included the disentanglement of classes and the removement of controller specific remnants in base classes.

An example are FE-I3 and RODPixController related usages which had been partially spread

6.7 The IBL Data Acquisition

over classes which fulfil a rather controller independent task.

With these preparations new controllers could be implemented into IBLDAQ. For example, theUSBPixController was introduced for test setups for FE-I4 tests. Furthermore, an IBLROD-PixController on the basis of the RODPixController has been added and modified to be able to communicate with the IBL ROD and the DSP, respectively. To implement the new readout chip a FE-I4 class has been introduced.

Scan results are now directly downloaded from the Fit Server and not via the VME interface.

A probable implementation to include this changes into IBLDAQ would be a request of the scan results via the IBLRODPixController. In that case the results have to be handed over to the appropriate classes for scanning. Another scenario is to directly download the results via the scan classes without a detour of using the IBLRODPixController class.

7 The Digital Signal Processor for the IBL ROD

7.1 Introduction

The Digital Signal Processor (DSP) is especially important if the detector is in calibration mode to configure modules and control scan processes. Within the IBL ROD development the software of the DSP has to be upgraded.

The code was originally written for the Master DSP of the Pixel Detector ROD. Several developers have designed this code. During the last years of detector operation it could be further improved and failures be eliminated. The DSP code has been developed to meet the requirements on the ROD. This includes a direct communication between the DSP and its environment. Through a continuously running loop the DSP permanently stays in contact with the host. The latter sends Primitives and Tasks which are executed on the DSP. Primitives are commands which are executed once. A Task is a process which can be stopped or runs until it finishes. At the same time the DSP sends back status information or data such that the scan procedure, which is executed on the host, can stop a running process if necessary. Furthermore, the DSP has access to all FPGAs and the four Slave DSPs on the ROD. Thus, it can write and read individual register values through which the DSP can control data path settings and request status information. These control mechanisms are needed while calibrating the detector and running scans.

The basic functionality of the DSP code on the IBL ROD and its main communication to the host and other on-ROD components stayed the same. Hence, it has been decided to use this code as a starting point for the IBL DSP code. This decision is supported by the fact that a successful functionality of the sophisticated and complex design of the current DSP code could already be shown in the past detector operations. As a result, adaptations regarding the properties of the new FE-I4 and the communication to the IBL ROD gives a fully functioning code for the IBL readout chain. Moreover, the time scale of the Fast Track IBL project does not permit the development of a completely new DSP design.

To start the DSP development for the IBL project the TDAQ and PixelDAQ environment had to be setup in the G¨ottingen lab. This is required as only with this software framework the module configuration can be read from a database and sent to the IBL ROD. Another example for the necessity of this environment are scan procedures which are only initiated by the TDAQ/PixelDAQ package. Hence, the existing PixelDAQ framework has to be extended to an IBLDAQ framework to be able to communicate with the IBL readout chain. These improvements are first integrated into the lab environment and are later used within the full operation of the ATLAS Detector.

At the time TDAQ was setup in G¨ottingen, only three existing installations had been present at CERN, SLAC1 National Accelerator Laboratory and the University of Genoa, Italy, which

1Stanford Linear Accelerator

7 The Digital Signal Processor for the IBL ROD

had been setup by two experts involved at CERN for a long time. A missing user-unfriendliness and, in addition, an upgrade of the SBC complicated the installation process2.