Atlas SCT Test DAQ Installation Notes

Lars Eklund , Bruce Gallop, John Hill , Gareth Moorhead and Peter Phillips


Contents

Hardware Requirements

The system comprises the following VME modules:

These are single-width 6U VME modules requiring a 6U VME crate. Each MuSTARD and Slog has 12 channels which in the simplest configuration supports six detector modules, since each detector module has two data links and two pairs of clock and control links. Each SCTLV has two sets of low voltage power and control channels and each SCTHV provides detector bias of up to 500 volts to four modules. A system for six detector modules therefore has one each of CLOAC, MuSTARD and SLOG, three SCTLVs and two SCTHVs. The system can be expanded in groups of six detector modules by adding extra pairs of MuSTARD and SLOG modules and SCTLV and SCTHV as required. Only one CLOAC is used per system. Software support is provided for system expansion along these lines.

Although these modules form the default system for electrically testing up to six modules, it is possible to operate a minimal system without CLOAC, SCTLV or SCTHV as described below. In the absence of CLOAC, SLOG can be configured to provide the clock and fast commands, though not to synchronise external triggers. In the absence of SCTLV and SCTHV the user must provide alternatives for the low voltage power, control signals (SELECT and HARD RESET) and detector bias.

CLOAC, SLOG and MuSTARD require a source of -5.2V which is not standard on all VME crates. If a CERN-standard (V430) crate is used, the -5.2V is supplied through the Jaux auxiliary backplane connector. If the modules are not to be used in a CERN crate, they should be ordered without the Jaux connector fitted because in many crates this connector prevents module insertion. (If it is absolutely necessary to use a module fitted with Jaux in a VME crate which does not accomodate the connector, this may be achieved by placing two 96 way wirewrap sockets between the module and the crate backplane.)

For crates without JAUX, the user must provide auxiliary -5.2V power via specific pins on the J2 backplane, and fit the relevant jumpers on each module. Further information can be found in the respective hardware write-ups. Please note that some of the pins of the J2 connector used for this connection are used for other purposes by SCTLV3, and that insertion of an unmodified SCTLV3 card into a slot wired to provide auxilliary -5.2V power will short across the supply. It is therefore recommended that each modified slot be clearly labelled, and that the number of slots modified should be kept to the minimum.

Note that if the modules are NOT supplied with Jaux (the small backplane connector between the two large ones), but you do wish to use them in a CERN crate, then the appropriate right-angle connectors can simply be soldered into place. Jumpers will then need to be set appropriately.

Some additional hardware is required for performing electrical tests of modules to provide signal routing, electrical buffering (of the LVDS high speed signals), convenient cabling etc. Normally these would include:

Note that the SCTDAQ distribution includes software support for many more types of VME module than are required for a basic module testing or Q/A system. These include modules for optical links at the systemtest and for temperature monitoring before the advent of SCTLV3. While code and libraries for these will be present in your distribution the hardware is not required for basic operation.


Cabling

Cables are required to transmit the various signals between the VME modules and the detector modules. The cards may be inserted into the VME crate in whatever order you may like, but two popular orderings are, from left to right:

MuSTARD --- CLOAC --- SLOG --- PPR --- SCTLVs (GFM)

SCTLVs --- CLOAC --- SLOG --- MuSTARD --- PPR (PWP)

The Clock, fast trigger and reset signals are distributed by means of short IDC-10 flat cables, e.g., 10cm. In a system which includes CLOAC, connect the first MuSTARD, MuSTARD0, to CLOAC FANOUT A to maintain compatibility with the VBURST routine. MuSTARD1, if present, should be connected to CLOAC FANOUT B. SLOG can be connected to any free socket. In very large systems, where the four CLOAC FANOUTS are exhausted, there is available a companion active fanout module.

To run without a CLOAC module you should move SLOG jumpers PL14 as described in section 3.3 of the SLOG manual to select SLOG's internal clock generator. A 10 way IDC cable can then be used to connect MuSTARD to either ECL A or ECL B of SLOG to provide clock and trigger signals. To run in this configuration, you should ensure that the software has been built to run without CLOAC by setting "CLOAC_NUMBER" to 0 in sct_hardware.h and rebuilding. An executable for windows compiled in this configuration is presently available for download.

The multiple, fanned-out copies of clock and control signals are then sent from the SLOG to the PPR via a short (e.g., 10-50 cm) IDC-50 flat cable or a single sector of twist&flat cable.

The data streams are read back from PPR to the Mustard via a short (e.g., 10-50 cm) IDC-26 flat cable or single sector of twist&flat cable.

All signals, two sets of clock and control for the two redundant sets of input links and the two data links back, are transmitted between PPR and the six module support cards via twisted pair cables with 7 pairs plus a ground wire. For typical use in the lab, twist&flat cable may be used. Lengths of 2-6m are commonplace. If much longer cables are needed, in excess of 15m, low-attenuation screened twisted pair cable is recommended. It is also recommended that user wishing to operate modules inside environmental chambers use screened signal and power cables.

The exact configuration of your signal cabling depends upon the support cards which you will be using. At the PPR end of each cable, an IDC-16 header socket is required. For use with the Liverpool forward support card, this is also true for the far end of each cable. Users of SC99, SC2000 or SC2001 support cards should fit an IDC-D15 plug to the far end, making no connection to the last wire of the cable. In both cases the conventional assignments of pin 1 are preserved.

Requirements under Windows

The currently supported computer control and readout components are:

Additional software tools which are useful but not essential for using SCTDAQ include:

A WINDOWS port to the BIT3 interface has been made by the Cracow group: contact Pawel Bruckman de Renstrom for further information.

Requirements under Linux

The currently supported computer control and readout components are:

With linux, a selection of useful additional software tools come for free!

A LINUX port to the BIT3 interface in being made by the Valencia group: contact Carlos Lacasta Llacer for further information.

We wish to thank Carlos for contributing GNUStop and numerous other aspects of the linux port.


National Instruments NI-VXI Installation

N.B. under linux, VXIEDIT is based upon an older version than that described here. Hopefully the differences are fairly obvious!

Install the VME-PCI interface kit according to the supplied instructions. The PCI-MXI-2 PCI card goes into a free PCI slot in the PC, the VME-MXI-2 VME module into a free slot in the VME crate, and the MXI cable is connected between them. Note that the cards should be physically installed in the PC and crate, and connected via the cable, and the crate powered, before installing the software so that the "Plug'n'Play" feature correctly sets up the full interface system.

For a system using only one VME crate, you may safely leave all switches set to the factory defaults. We do not normally order extra DRAM for the PCI or VME cards.

The VME-MXI-2 interface card is normally installed in Slot 1 (left-most slot) of the VME crate where it acts as the bus arbiter. If another arbiter is already installed the VME-MXI-2 can be installed in any other free slot.

Install the supplied NI-VXI and VISA software according to its instructions, after hardware installation, preferably into the directory c:\nivxi. After installation, the static library nivxint.lib used to build SCTDAQ should reside in c:\nivxi\win32\msc

At the time of writing, SCTDAQ does not work with NI-VXI version 3.1. Please stick with NI-VXI version 2.1. The Windows release of NI-VXI 2.1 that can be downloaded from the NI website includes versions for Windows NT and 2000.

NI-VXI version 2 includes an integrated product called the T&M Explorer (Test and Measurement Explorer). For systems running Windows NT, you will need administrative privileges to install this software.

After installing NI-VXI, reboot the PC and run T&M Explorer. Within T&M Explorer, run the VXI Resource Manager to initialise the hardware. Users running Windows NT will find that by default this can only be done from an account with administrative privileges. Since the VXI Resource Manager must be run after every crate power cycle or PC reboot, this can be very inconvenient. If you wish to configure your system such that any user may run the VXI resource manager or edit settings within T&M Explorer, you should edit the registry to give all users full access to the branch "HKEY_LOCAL_MACHINE/SOFTWARE/National Instruments/NI-VXI for Win32". Further instructions can be found on the National Instruments website. (The article on this subject is at this URL)

Within T&M Explorer, the "User window size" needs to be set to something large, eg, 16MB, as follows:

(Note: the large window size is due indirectly to a limitation of NI-VXI in that it can only have four user windows simultaneously open. SCTDAQ in many circumstances addresses more than four devices. We get around this by grouping all our A32 address ranges in one 8MB block 0x1800000 - 0x1f00000 so that only one A32 user window need be opened by the program. This in turn means that the user window needs to be larger than 8MB to accommodate all required A32, A24 and A16 address ranges.)

Also within the T&M Explorer you need to make entries for each VME module:

The standard settings for VME devices used in SCTDAQ are listed in the next section.

VME Addresses

Module Name Space Range
CLOAC A24 0x880000 - 0x8800ff
SLOG0 A32 0x1800000 - 0x181ffff
MUSTARD0 A32 0x1900000 - 0x19fffff
SCTHV0 A24 0xf00000 - 0xf0ffff
SCTHV1 A24 0xf10000 - 0xf1ffff
SCTLV A24 0xff0000 - 0xffffff

We identify SCTLV by crate rather than module, and count channels in pairs according to the module jumper setting: 0x0 for 0,1, 0x1 for 2,3 etc.

The hardware addresses are set via hex-switches or jumpers on the VME boards. Images showing the correct setting of these switches to values listed above can be viewed here, otherwise please refer to the documentation of each device. In the case that more than one CLOAC, SLOG or MUSTARD are to be installed, it is suggested to use the address spaces immediately above the initial module of each type.


ROOT

The ROOT package should be downloaded from its home site at CERN, http://root.cern.ch . The system has been built and tested with version 3.02/07 - the standard version, built without the experimental implementation of GDK. In the event that you should experience problems with this version of ROOT, and wish to revert back to version 2.24, a copy of this version can be found on our download page.

Download the zip file and unzip into the directory c:\root. This creates the full source tree along with libraries and executables.

For some old versions of Windows, you need also to get the dynamic library "MSVCIRT.DLL" which you should save into a Windows system directory already specified in your Windows default path. This is unlikely to be necessary, and is not necessary for Windows NT 4.

The main local configuration now required is to set the %ROOTSYS% environment variable to point to c:\root (or wherever else you installed ROOT). On Windows NT, in the Control Panel, select "System" then "Environment" then add a "System Variable" of the name "ROOTSYS" and value "c:\root". This may require Administrator privileges.

You should now be able to execute c:\bin\root.exe (you may wish to setup a Start or Desktop icon). Much more information may be obtained from the ROOT homepage, or from the Using ROOT in Windows page.

The main idea behind the ROOT user interface is the CINT C++ run-time C++ interpreter. The ROOT text console that appears when root.exe is executed is an interface to CINT. Interpreter commands are preceded by a dot, ".", eg, ".?" for help or ".q" to quit. All commands not commencing with a dot are interpreted as C++ language instructions to be executed. They may cause external files, macros, to be loaded and executed; they may cause ROOT menu bars and other objects to appear in other windows, called "Canvases" in ROOT terminology. Experienced PAW users may notice some points of similarity: essentially, CINT replaces the PAW macro interpreter, and C++ and the ROOT classes replace KUMACs.

A good first step is to attempt to run the ROOT demo macros by typing ".x demos.C" at the root system prompt. Note the capital "C" to signify the C++ language; ".cpp" may also be used for your macros. A simple menu bar with a number of histogram and drawing options should appear, and you should be able to execute these, displaying various fancy plots. These are described at the "Tutorials" section of the ROOT website.

The remaining customisation of ROOT is by means of the initialisation file .rootrc. ROOT uses the .rootrc file in the directory in which it is started, by default %ROOTSYS%\bin. An example .rootrc is included in c:\sctdaq. You can use this by altering the properties of your desktop root or sctdaq icons to start ROOT from c:\sctdaq, or you can alter the version in c:\root\bin. In either case, your .rootrc should contain the following SCTDAQ references on one line each:

WinNT.*.Root.DynamicPath: .\;$(ROOTSYS);$(ROOTSYS)\bin;c:\sctdaq\bin;$(PATH)
WinNT.*.Root.MacroPath:   .\;$(ROOTSYS)\macros;$(ROOTSYS)\tutorials;c:\sctdaq\stdll;c:\sctdaq\analysis;c:\sctdaq\macros;c:\sctdaq\tests;d:\sctvar\macros
and
# Rint (interactive ROOT executable) specific alias, logon and logoff macros
Rint.Load:               c:\sctdaq\rootalias.C
Rint.Logon:              c:\sctdaq\rootlogon.C
Rint.Logoff:             c:\sctdaq\rootlogoff.C
Rint.History:            c:\sctdaq\root_history.txt
These directories and files will be installed with the SCTDAQ distribution. It may be necessary to start ROOT within the SCTDAQ directory for these customisations to be picked up. Note that the dynamic link library stdll is now loaded at logon, so the system will not work if the file rootlogon.c cannot be found.


Sctdaq Files

The software is available in two formats:

The production version may be downloaded as a zip file from the SCTDAQ download site. Here you will find date-stamped archives of the full source tree, the latest in sub-directory "pro", and older ones in "old". If the "pro" version appears a little elderly, please request an update. The versions here should be reasonably tested and stable, and will typically correspond to a major release or an important testbeam or the like for which a reference copy should be maintained.

At the time of writing, zips are provided which include ready-built versions of the production code for the following two common hardware configurations:

Versions are provided for users of ROOT 2.24 or 3.02/07. If you have any additional hardware boards, wish to use non-standard base addresses or filesystem paths, or have a different version of ROOT, then you will have to build the system from scratch - sorry!!

The development version can down-loaded via CVS from the development repository. This is the version under current development, so may be unstable and not fully tested. It is not recommended except for people actively requiring and helping develop new features. Access to the repository is by request.

Installation procedure:


Microsoft Visual C++

For use with Root v 2.23/9 or later, MS VC++ version 6 is required. Set the following defaults under the "Tools" menu, and configure the compiler rather than the project. Tools -> Options -> Directories -> "Show directories for"> Include files: add c:\root\include c:\nivxi\include c:\sctdaq\include Executable files: c:\Program Files\root\bin c:\sctdaq\bin Library files: c:\root\lib c:\nivxi\win32\msc c:\sctdaq\lib It may sometimes be necessary to update the ROOT libraries specified in a project, for example, if the ROOT team changes the library organisation. Two versions of the project file stdll.dsp are included in the SCTDAQ distribution to accomodate the library naming conventions utilised in ROOT versions 2.24 and 3.02 respectively. If you are using any other version, you may need to change the files which are included in the project. In this case, it is simplest to delete all the ROOT libraries, and right-click in the FileView window to add them again from the local c:\root\lib directory. With ROOT 3.02 only the following files appear to be needed: libCint.lib libCore.lib libGraf.lib libHist.lib libMinuit.lib libRint.lib libTree.lib libWin32.lib In Root version 2.24 these are named Root_WIN32.lib, Root_Cint.lib etc. Also, the preprocessor directives should include: WINNT,VXINT,WIN32,NIVXI


CVS

CVS is a code version management utility, commonly used in the UNIX world to facilitate development of multi-author software projects. CVS can operate remotely over the internet to keep local copies of files and directories synchronised with the repository version, and thus also provides a mechanism for distribution of the current development version. We maintain sctdaq in a CVS repository on the AFS cluster at CERN. The repository is intended primarily for the program developers but is also available "read only" to anyone with a CERN AFS account provided appropriate read access has been granted (available on request.) In order to access files over the internet from outside CERN, we are required to use SSH, the Secure Shell, for automated encrypted file transfer.

If Windows versions of CVS and SSH are already installed on your PC, you can access the sctdaq files in "external" mode by setting the following environment variables, substituting your atlas login id for 'USER' and a specific machine (not a cluster alias) on which you have a CERN AFS account for 'MACHINE'.

  CVSROOT :ext:USER@MACHINE.cern.ch:/afs/cern.ch/user/s/sct/public/cvsroot/
  CVS_RSH ssh
using the standard CVS commands to checkout or update c:\sctdaq. You can also access the files locally at CERN via AFS, or on most UNIX systems where CVS is installed, in an analogous way, but be aware that if you checkout onto a UNIX or Linux system there may be problems with CR/LF translation when files are copied to the PC. Use of a UNIX connection to CVS and subsequent FTP in "ASCII" mode can be a very convenient alternative if only a few files, e.g., new macros, are required.

Note also that it is best to specify a specific machine, eg, atlas007.cern.ch, rather than a cluster alias such as atlas.cern.ch, to simplify certain security issues. By specifying a specific machine rather than a dynamically re-allocated alias the encryption key associated by your local machine with that name will not appear to change with each log-in, leading to security warnings. This may, however, lead to future problems if that machine becomes unavailable.

To install CVS and SSH on your PC you can obtain versions commercially or free from the internet. Versions of each commonly used in the sctdaq community on Windows NT 4 can be retrieved from our download site.


CVS & SSH Installation & Use

To install and use the versions of CVS and SSH which are commonly used under Windows NT 4 in the sctdaq community, follow these steps.

If you don't already have a suitable directory for utilities, e.g., c:\bin, make one, and append it to your system path, i.e., You could also put here utilities such as tar, gzip, gunzip etc. which you may find useful in your macro scripts for dealing with large amounts of data.

CVS Installation

SSH Installation

Checking out SCTDAQ

A new, clean installation of SCTDAQ on your local system should now be possible using standard CVS commands: To update an existing installation of SCTDAQ to the development version: It is common practice not to use update, but each time to rename c:\sctdaq to another name, and do a fresh checkout. Differences can be studied with windiff, and certain problems with file permissions avoided.

We particularly request that users do not attempt to commit any changes to the repository before first contacting the authors. The development account on AFS should be used only for administration of the repository and of the dependent web sites.

suggestions/corrections