Testbeam Extensions to SCTDAQ

Gareth Moorhead


Contents

Introduction

The SCT has carried out many testbeams at both the CERN SPS H8 and the KEK PS Pi-2 beamlines. For a number of years the workhorse processor at both of these facilities has been our CES 8253 RAID, a single-VME board computer using a 30MHz MIPS3000 CPU and the EP/LX real-time UNIX operating system. Originally at CERN and lately at KEK we have used a data acquisition software environment 'PDAQ'; more recently at CERN we have used the LHC prototype DAQ environment 'RD13'. In both of these DAQ's we have used essentially the same set of VME modules for module readout and the same common libraries of C functions generally going under the collective name 'sctdaq'. This environment also formed the basis of the original set of software developed for the Systemtest using the Mustard/Slog/SCTLV binary readout hardware during late 1998.

During 1999 the systemtest and module-testing elements from the RAID sctdaq were ported to a PC system, and have now evolved into the core of the SCTDAQ environment. This SCTDAQ uses much faster, commodity processers, a modern language and compiler (MS Visual C++), a modern analysis and macro package (ROOT), and perhaps most importantly provides site-independence. The RD13 package is heavily linked to commercial licenses and specific database servers making its use outside CERN extrememly difficult. For these reasons, we decided to expand the SCTDAQ to include the full set of testbeam hardware readout and a simplified testbeam acquisition algorithm and buffer management system. This work was started in late 1999 and first used at the December 1999 testbeam at KEK.


User Online Instructions

The run control environment is provided by the interactive user interface to a ROOT session. The main operations are all implemented as ROOT macros, at present executed from the command line. A graphical interface may be provided in the future.

To start a session, first start ROOT, eg, from a desktop icon. Then execute the following functions from the main ROOT command-line window or menubars:


.X ST.cpp     [Loads and executes the basic SCTDAQ environment
               Creates the main sctdaq object "e"
               All SCTDAQ public variables and functions are now available, 
			   including calibration

*** Do an "ExecuteConfigs" from the main SCTDAQ menubar to initialise
  the SCT hardware 

.L TB.cpp     [Loads the testbeam macro TB.cpp]

TBStart()     [Initialises the hardware, books histograms etc.,
               and creates the main testbeam object "t"]

*** Do any further configuration here

TBRun()       [Starts a run]

Note that TBRun() automatically increments the run number, and prompts the user for some descriptive information. However, TBRun() does not change any conditions; the run conditions must be established by executing explicit commands between runs.

Also note that at present a run cannot be interrupted except by using Control-C to kill the ROOT session. This is harmless, but does mean that the full initialisation must be repeated to re-start data-taking.

All of the SCTDAQ standard variables and functions are available from the usual buttons or by invoking member functions of the object "e". As well, some testbeam variables may be modified between runs by invoking member functions of the object "t" including:

   t->SetTriggerDelay(int new_delay);
   t->SetEventsRequested(int new_req);
   t->SetScanDescription(int new_typ, float new_val);
An alternative to TBRun() is TBScan(type,start,stop,step) which performs a series of runs while scanning any one of the SCTDAQ variable types (eg, 1 for threshold) from the [start] to [stop] in steps of [step]. This is intended for quick surveys of module performance.

Monitoring Plots and Information.

Monitoring analysis is performed on all or some events by the DAQ processes. The resulting information is summarised as text in the ROOT main window, and also recorded to a run summary file "tbsummNNN.dat", where NNN is the current run number, located in the data directory (usually D:\sctvar\data).

Histograms are presented in various canvases including:

The efficiency information presented as text and in the summary files is: The bins in the efficiency graph correspond to these numbers.

Configuration

Configuration of SCT modules is done by the standard SCTDAQ functions. Default conditions are established from the standard SCTDAQ configuration files (st_system_config.dat and the detector .det files) when ST.cpp is executed or restarted.

Configuration of the testbeam extensions is done primarily by editing the run macros in the file TB.cpp, or by explicitly executing the member functions such as those listed above.


Software Installation

The online testbeam environment requires first the installation of the basic SCTDAQ, ROOT and NI-VXI software environments as described here . Then, the directories for the extra hardware, the low-level library (tblib) and the ROOT-interface (tbdll) must be copied into the top sctdaq directory, usually C:\sctdaq. At present these are:

In addition, the basic run macro TB.cpp must be copied into a directory in the ROOT search path, eg, C:\sctdaq\stdll.

These files and directories may be obtained from the atlas.wgs in the same place as the basic SCTDAQ files, although at present they are not available under CVS.

Each of the libraries should be built in turn, first the IRAM, V262 and TDC, then tblib, then tbdll. The settings for MS Visual C++ etc. are much the same as for the main SCTDAQ.

Importantly, since installations of ROOT may vary, the source files tbdll\tbdll_cint.cpp and tbdll_cint.h should be regenerated by executing the batch file maketbdict,bat located in the tbdll directory.

On occasion it may be necessary to re-specify the ROOT static libraries. These should be located in the root/lib directory, e.g., C:\root\lib. First open the tbdll workspace file tbdll\tbdll.dsw in MS Visual C++. In the "FileView", left-click on "Library files". Delete all files with names commencing "Root_". Then right-click on "Library files", and open "Add Files to Folder". In the resulting dialog box, select all the root static library files, e.g., from C:\root\lib (you have to change the file extension type to ".lib"), and restore them to the project workspace file.

The run macro TB.cpp should also be copied from tbdll into a directory in the ROOT search path, e.g., sctdaq\stdll.
Offline Version
The "offline" version of tbdll an be built without requiring the full SCTDAQ installation or any of the hardware or NI-VXI libraries. It requires:

In the source file tbdll\TTB.cpp, comment out or otherwise de-activate the define "#define ONLINE" near the top of the file. This prevents calls to stlib or tblib functions so that they are not required for compilation or linking.

To run the online monitor analysis code on events read from a data file, first initialise the system by executing at the ROOT prompt:

TBStart()
then call
TBOffline(NNN, num_events)
This will read and analyse [num_events] events from the data file for run NNN, tbrunNNN.dat where NNN is the integer run number, which should be in the default data directory, e.g., D:\sctvar\data.
Testbeam Hardware
The testbeam hardware consists of a scintillator trigger system including photomultiplier power supplies, discriminators and coincidence units, a trigger system which prepares the raw scintillator trigger and gates it with a busy made by combining the logical busies from a number of sources as explained below, a system for providing state monitoring and control between the executing software and the combinatorial logic, a TDC to measure the time delay between raw random triggers and clock-synchronised output triggers, a Telescope system to provide high-resolution tracking with silicon detectors read with Viking analogue electronics, and the standard array of SCTDAQ hardware for power, control and readout of SCT modules.

A number of NIM and VME modules in addition to those standard in the SCTDAQ package have been used in the testbeam version. These include:

A key hardware item for the testbeam version of SCTDAQ is the CLOAC clock and control module which is part of the standard SCTDAQ system. In the testbeam, this module receives the final externally generated trigger signal (which is random relative to the system 40MHz clock), synchronises this to the next clock transition, emits a prompt synchronised trigger (used to start the TDC and to trigger the Viking Telescope readout) and a delayed synchronised trigger, a trigger which has been delayed by the correct integer number of clock cycles such that the correct time-bucket is ready to be read from the SCT front-end electronics pipeline.

Another key set of hardware items is the CAEN V262 I/O unit coupled with a standard NIM dual-timing unit, e.g., a CAEN N93, with its output pulse length set to "Infinite" (i.e., stays active until it receives a Reset pulse). The V262 provides an interface between the software and the "real" world. It has several NIM input levels (used for monitoring various system states), several NIM output levels (used for controlling various system states), and several NIM output pulses ("SHP", shapes).

The controls used in SCTDAQ are:

The main event sequence is for an incoming trigger to cause the Dual Timer to become active, preventing any further triggers and causing a state-change at the V262 NIM IN 1. This is monitored by the executing software, which then performs all the necessary readout functions, filling the event buffers as quickly as possible before completing. As soon as event readout is completed, the software causes a pulse out from V262 NIM SHP OUT 1 which resets the prompt busy, releasing the system for further triggers.

Note that the software is also polling the other inputs and can take appropriate action. The HARDWARE BUSY is a logical OR (made by a NIM logic fan-in) of the hardware busy outputs of all the readout modules. The accelerator SPILL is the state of the beam cycle; it is used as another busy, so that triggers are prevented out-of-spill. Once the software has detected the end of a spill, it drains all readout modules of unread events, and then performs all the necessary event formatting, recording of data to disk, monitoring analysis and update of histogram displays. All of this activity is deferred until the spill has ended so as to minimise deadtime during the spill.


Logical Schematic
Not yet available.

VME Addresses

In order to fit the required number of address ranges within the limit of 4 user windows under National Instruments VXI, the CLOAC A24 address range has been expanded to provide a general purpose A24 window for use by the various testbeam modules. CLOAC was chosen as it is most likely to be present but itself uses a small window (0x100 bytes), so the extra space will not interfere with normal non-testbeam SCTDAQ operation.

At present it is assumed that the four windows are mapped for CLOAC (512k A24), SLOG and Mustard (A32), SCTLV (A24, fixed location) and IRAM (A16). BiLED is not yet supported in tblib. The IRAM units require both A16 and A32 space, the A32 space being sited within the generic SLOG A32 window.

Module Name Space Range
CLOAC (A24) A24 0x880000 - 0x8fffff
TDC A24 0x8a0000 - 0x8affff
V262 A24 0x8b0000 - 0x8bffff
SLOG0 (A32) A32 0x1800000 - 0x181ffff
MUSTARD0 A32 0x1900000 - 0x19fffff
IRAM-A32 A32 0x1d00000 - 0x1efffff
IRAM-A16 A16 0x4000 - 0x8fff
SCTLV A24 0xff0000 - 0xffffff

suggestions/corrections