CSCTF Online SW Guide

ToDo List

  • Anna needs to check that SPValidation works
  • clean-up the code
  • write and test an installation script
  • Migrate to SVN at P5

Documents

Document Comment
CMS IN-2009/003, "Control Software for the CSC Track Finder" Old document, but it contains the core of the information
and even if some are out of date, it is a useful reference

Access the Servers

Servers' names:

  • At P5: vmepcS2G18-10
  • At 904: vmepc-e1x07-27-01

How to access the CSCTF machines:

  • First log in the node:
    • At P5: ssh -X -l yourUserName cmsusr
    • At 904: ssh -X -l yourUserName cms904usr
  • At this point you can connect using friendlier aliases for the machine: ssh l1ts-csctf (at P5 you can even use the alias csc-tf)

Install the Code

Install XDAQ and TriggerSupervisor Frameworks

These are mandatory steps in order to have the CSCTF online code working

      sudo yum groupinstall "extern_coretools"
      sudo yum groupinstall "coretools" 
      sudo yum groupinstall "extern_powerpack"
      sudo yum groupinstall "powerpack"
      sudo yum groupinstall "database_worksuite"
      sudo yum groupinstall "general_worksuite"
      sudo yum groupinstall "hardware_worksuite"

      sudo yum groupinstall "triggersupervisor"

  • Extra package to communicate to database:
      sudo yum update sqlite sqlite-devel

  • Install root from sources
    • In general root to work needs you to set up environment variables in the .bashrc, but this will be done in ~csctfts/TS1_12_X/cactusprojects/csctf/environment.sh, once you install the CSCTF code from SVN
      mkdir /nfshome0/csctfts/code
      cd /nfshome0/csctfts/code
      wget ftp://root.cern.ch/root/root_v5.32.00.source.tar.gz
      tar -zxvf root_v5.32.00.source.tar.gz
      cd root
      ./configure
      make (this may take a while to finish)

Install the CSCTF SW

  • The instructions are a bit cumbersome b/c the CSCTF machine is accessible through a gateway machine, but it cannot see the svn repository

  • Checkout the svn code:
      ssh -X -l digiovan cms904usr # or cmsusr 
      xsudo -H -u csctfts bash -login # you need to use the csctfts user, so you can save the files with this username who will be the one needed to compile the sw 
      mkdir TS1_12_X
      cd TS1_12_X 
      svn co svn+ssh://yourUserName@svn.cern.ch/reps/cactus/trunk/cactusprojects/csctf cactusprojects/csctf # you will be prompted to type your lxplus password to access the svn
      svn co svn+ssh://yourUserName@svn.cern.ch/reps/cactus/trunk/cactusprojects/setup cactusprojects/setup # this will be useful for running the SW

At this point you need to check that the file /nfshome0/csctfts/TS1_12_X/cactusprojects/csctf/environment.sh is correct (e.g. is the root code location correct?)
What I would recommend is to add the following lines to the csctfts and yourUserName .barshrc file:

export CSCTF=/nfshome0/csctfts/TS1_12_X/cactusprojects/csctf
source /nfshome0/csctfts/TS1_12_X/cactusprojects/csctf/environment.sh
These lines will make sure everytime you log-in either as yourUserName or csctfts you setup the environment correctly

  • Compile the CSCTF SW:
      ssh -X -l digiovan cms904usr # or cmsusr
      ssh -X l1ts-csctf
      xsudo -H -u csctfts bash -login # you need to use the csctfts user, so you can save the files with this username who will be the one needed to compile the sw 
      cd $CSCTF
      make
      chmod -R 777 localConditions #the CSCTF online SW is writing some output in this folder but as the executable is run as yourUserName you need to make sure this folder has the right access sets

at 904:

      cp ts/worker/src/common/MTCCIIConfiguration.cc-904 ts/worker/src/common/MTCCIIConfiguration.cc # the default is the P5 configuration, need to change it for 904
      make

The Makefile will try to compile in order:
1) SPBaseInteractions
2) SPFunctions
3) SPLUTsAndFirmWare
4) ts/worker # the CSCTF online SW

  • Create the RPMs for the Setup:
      cd $CSCTF/../setup/l1ts904 # or l1ts
      cp $CSCTF/setupscripts/reinstall.sh . # this is an helper script useful later... no need to use it, if you do not like it :-)
      make rpm
      ls rpm/ | grep trigger # will show the rpm name as trigger-l1ts904-1.12.19-1.cmsos11.slc5.gcc4_1_2.x86_64.rpm. Make sure this is the name you have in reinstall.sh, if you plan to use the script

  • Install the CSCTF SW:
      ssh -X -l digiovan cms904usr # or cmsusr
      ssh -X l1ts-csctf
      cd $CSCTF/../setup/l1ts904 # or l1ts
      sudo reinstall.sh

Additional Packages

These are different utilities whose description is available at the "Packages Description" section

      ssh -X -l digiovan cms904usr # or cmsusr
      ssh -X l1ts-csctf
      xsudo -H -u csctfts bash -login
      cd $CSCTF

  • SPFunctions:
      cd $CSCTF/SPFunctions
      make
      cd $CSCTF/SPFunctions/test
      make bin


  • SPLUTsAndFirmWare:
      cd $CSCTF/SPLUTsAndFirmWare
      make
      cd $CSCTF/SPLUTsAndFirmWare/test
      make bin

  • SPStandAlones:
      cd $CSCTF/SPStandAlones/test
      make bin

  • SPValidation:
    • This package requires some dependencies from CMSSW software
      ssh -X -l digiovan cms904usr # or cmsusr
      kdestroy
      xsudo -H -u csctfts bash -login
      kinit yourUserName@CERN.CH # you will be asked for the password
      export CVSROOT=:gserver:cmssw.cvs.cern.ch:/cvs/CMSSW
      cvs co EventFilter/CSCTFRawToDigi/
      cvs co IORawData/CSCCommissioning/ 
      mv EventFilter/ IORawData $CSCTF/SPValidation/test
      # now you can log in and compile as usual
      ssh -X -l digiovan l1ts-csctf
      xsudo -H -u csctfts bash -login
      cd $CSCTF/SPValidation
      make # it will take quite some time to compile the vpp_ files with bit-by-bit CSCTF emulator
      cd $CSCTF/SPValidation/test
      make bin

Code Description

Repository

Packages Description

This Section describes the different kind of packages available in the repository, highlighting the main executable and features

SPBaseInteractions

Description

The SPBaseInteractions package builds the library that contains the core software objects responsible for direct communication with the Track Finder Crate. 
The objects contained within it depend only on libraries available through XDAQ and as such is the first of the CSCTF packages to be compiled. 
Most of the other CSCTF packages make use of and depend upon the core objects supplied.

The object central to CSCTF software is the ‘SPobject’. One SPobject is instantiated for each electronics board (12 SPs, a CCB and a MS) and it allows 
the user to directly read and write registers on that board. 

Users interacting with a whole crate of TF Boards rather than just a single one at a time should use a ‘TFCrateContainer’ object to construct 
and store their SPobjects. This container object allows the user to hold a single pointer through which they can access all of their boards. 

Important Feature

  • An SPobject created in standard mode will check the date stamps of the loaded firmware in all chips on the Sector Processor. If there is a mismatch between the expected firmware date and the one read then an error will be thrown and the SP will not be created. If one uses debug mode then a warning will simply be thrown and the object creation will continue regardless. The reference for the expected firmware versions is either parsed as part of the configurations key read out from the configurations database or in the case of standalone mode is read from the local file SPBaseInteractions/firmwareVersions.txt. Thus, if one (or more) boards do not have identical firmware version as specified in the file they will not be initialized and may appear as non-existing. Whenever changing the firmware on the crate, DO NOT forget to update the file firmwareVersions.txt.

SPFunctions

Description

The SPFunctions library contains common functions applied to the Track Finder Crate boards.

The CCB, MS and MPC have appropriately named classes which contain standard functions specific to that board.
These functions range from basic configurations to gets and sets of board parameters and modes, test pattern injections
and validating read outs.

The rest of the classes pertain to SP functionality. On the whole, the names give away the area of functionality. Classes
exist to configure the SP from scratch and to change the trigger mode. There is a class for getting and setting the
various timings and one for reading and testing the FMM STTS responses. There are classes to perform manipulations
on LUTs and to work out the real world meaning of the ETA window settings. There is a class to look after the
“monitorable” items in the Track Finder which involve all of the slow control readings. There is a command parser
allowing streams of commands to be sent to the crate boards and a couple of miscellaneous function classes containing
methods to make injections of files of data in to the hardware, corresponding methods for data read out over VME and
artificial triggers.

The methods contained in these classes are explained briefly in this subsection but for a more full understanding one
should refer to the interface files and the automatic documentation.

Main Executable

The test directory of the SPFunctions package contains short pieces of code that wrap functions found in the source
code into useful executable functions. The functions can be executed as is but are deliberately written so as to make the
process as transparent as possible to the user who may wish to modify them for his own means. They represent a rapid
stand-alone method of accessing the hardware bypassing any run control or trigger supervisor implementation.

The executables in the SPFunctions package that start with readCrate_ are all designed so that they can be run while
the crate is actively running and triggering without interfering. They do not alter any settings and typically serve only
to read out some stored information from the crate.

Executable available at SPFunctions/bin, upon compilation

  • readCrate_FWnConfig.exe: This is an executable that will read out the firmware dates of all of the Track Finder chips as well as the configuration key date string of all of the SPs. The core objects are built in “debug” mode so the process is robust against incorrect firmware, lack of clock and bad configuration as far as possible.
  • readCrate_AF.exe: This program returns information about the Alignment FIFO delay settings for each of the SP and the word count in the Alignment FIFO elastic buffer for each trigger link from the last resync. The output is a table where the columns represent Sector Processors and as one reads down one sees information about the board and then about each trigger link in order. There is a vector of output before the table that corresponds to the Alignment FIFO delay setting minus the word count divided by 2. This is a popular set of numbers to plot against fiber length.
  • takeVMEData.exe: This executable dump VME data continuously (or for a specified number of reads). Useful for DAQ debugging sessions on a test bench, i.e. 904

SPLUTsAndFirmWare

Description

This package deals with loading Lookup Tables (LUTs) to the SPs and firmware to the SPs, the Muon Sorter and the Clock and Control Board via VME.

_LUTs_:
Functions for SP lookup table manipulations are all contained within a single class; loadLUTs. Its header file is in SPLUTsAndFirmware/include/loadLUTs.h. 
This class provides functionality for loading LUTs to single chips as well as global wrappers for loading all the LUTs to a single SP or to the whole crate. 
It enables switching between binary and ascii mode for LUT file input and output and switches between VME block transfer and single writes mode. 
The class provides diagnostic routines whereby CRC checks can be run on loaded LUTs and the LUTs themselves can be dumped to local disk. 

For the Sector Processor, Clock and Control Board and Muon Sorter, code to upload firmware files to the boards exists in the SPLUTsAndFirmWare/bin/LoadFPGAconsole.
Again, important reminder: An SPobject created in standard mode will check the date stamps of the loaded firmware in all chips on the Sector Processor. 
If there is a mismatch between the expected firmware date and the one read then an error will be thrown and the SP will not be created. If one uses debug mode then a 
warning will simply be thrown and the object creation will continue regardless. The reference for the expected firmware versions is either parsed as part of the
configurations key read out from the configurations database or in the case of standalone mode is read from the local file SPBaseInteractions/firmwareVersions.txt.

_FIRMWARE_:
Typically new firmware is uploaded on on the advice of the board engineers and experts who will provide a link to the new firmware file. There is a template directory 
in SPLUTsAndFirmWare/firmware in which firmware files can be stored before being uploaded but in principle one can upload files from anywhere on the local disk. 
The main upload scripts are in SPLUTsAndFirmWare/scripts/ where the script names denote the board to which they apply. Typically, one edits the loading script with 
the path to the correct firmware files and then runs the executable. Sufficient examples exist inside the scripts for the users to be easily able to add in new firmware, 
but the form of the direct call to LoadFPGAConsole is given below nonetheless:

./LoadFPGAConsole -s8 -f1 -o1 -j1 -xAddressTable.xml my_chain1_fw.svf
./LoadFPGAConsole -s8 -f1 -o1 -j0 -xAddressTable.xml my_chain0_fw.svf

This code would load “my_chain1_fw.svf” to the chain 1 chips (Front FPGAs, VME FPGA, DDU FPGA) and “my_chain0_fw.svf” to the chain 0 (SP chip) to the SP in 
slot 8 using the registers defined in “AddressTable.xml”. If one looks inside the loading scripts then it is evident that it is essentially these 2 lines which need to be 
edited for the path to the most recent firmware file. The method of upload using the VME interface is using JTAG Boundary Scan. Firmware files to be loaded to the 
SPs are Serial Vector Format (.svf) and are an open format ascii representation of JTAG test patterns. The SPs take 2 separate .svf files; chain0 is the firmware loaded
to the SP core chip and chain1 contains the commands loaded to the rest of the chips. The uncompressed file sizes are typically of order 8.5 and 14MB respectively,
but vary a little from release to release. 

How To Load LUTs

Disclaimer: In this example I will be using LUTs which are in .bin version. During the last years we never used a different format, nevertheless it is possible to use ascii. This Section describes only the LUTs loading and not the configuration key implications. If you need to ALSO modify the configuration key, the instructions are available here.

  1. Generate the LUTs or have someone generating them for you smile
  2. Copy the LUTs in the folder, SPLUTsAndFirmWare/LUTs/bin/newLUTs
  3. Edit the file SPLUTsAndFirmWare/test/crateLoadLUTs.cpp, to tell the code where to pick the LUTs: the line to modify is std::string vers = "your_folder"; (in this case the code will look in SPLUTsAndFirmWare/LUTs/bin/newLUTsDir). IMPORTANT: do not forget to create a folder called monitorData in SPLUTsAndFirmWare/LUTs/bin/newLUTsDir where the CRC files will be dumped.
  4. Compile: cd $CSCTF/SPLUTsAndFirmWare && make && cd test && make bin
  5. Load the LUTs: cd $CSCTF/SPLUTsAndFirmWare/bin/ && ./crateLoadLUTs. The executable will dump some .dat files which will be used in the configuration process to check the LUTs are properly loaded in the SPs. These files will be indeed have to be put in the database when you create a configuration key. IF THE DAT FILE FOR A SPECIFIC KEY IN THE DBS WON'T MATCH THE ONE DUMPED FROM THE SCRIPT THE CONFIGURATION OF THE SPs WILL FAIL!
  6. Test the LUTs are correctly loaded modify crateRunCRC before using:
    • Change the line std::string vers = "your_folder"; of SPLUTsAndFirmWare/test/crateRunCRC.cpp pointing to the newLUTsDir
    • Compile: cd $CSCTF/SPLUTsAndFirmWare && make && cd test && make bin
    • Test them: cd $CSCTF/SPLUTsAndFirmWare/bin && ./crateRunCRC
  7. Optional: You can check that only appropriate LUTs have changed by running = $CSCTF/misc/diffLUTs.py oldLUTsDir/ newLUTsDir/=. Only changed files should not match.

How To Load Firmware

  1. Get the firmware from Lev Uvarov's page: http://www.phys.ufl.edu/~uvarov/SP05/SP05.htm and unpack it in the folder $CSCTF/TrigData/TrackFinderCrate/SectorProcessor2002/firmware/.
    Reminder:CSCTF SPs have two firmware kind:
    • "chain 0" firmware: it is to be loaded in the Main FPGA mounted on the mezzanine card (takes ~ 15 min. per SP)
    • "chain 1" firmware: it is to be loaded in the Front FPGA (F1,F2,...,F5) (takes ~ 5 min. per SP)
  2. Edit the script to load the firmware which is $CSCTF/SPLUTsAndFirmWare/scripts/loadFirmware.sh. This is actually a bash script. Open it and change the options inside to point to the right files. There are 2 blocks: the first for "chain 1" firmware and the second one for "chain 0". If you load chain 0 fw, the chain 1 block should be all commented out (and viceversa).
  3. Load the firmware: cd $CSCTF/SPLUTsAndFirmWare/scripts/ && ./loadFirmware.sh "slot number". Example of fw loading in SP 7 (slot 16) is "./loadFirmware.sh 16"
  4. After loading new firmware we have to change version of firmware at file $CSCTF/SPBaseInteractions/firmwareVersions.txt. For chain 0 change version of: SP SP dd/mm/yy while for chain 1 change version of SP FA dd/mm/yy, SP DD dd/mm/yy and SP VM dd/mm/yy.
  5. In order to have the TriggerSupervisor code acknowledge the changes you need to recompile it:
    • cd $CSCTF && make clean && make
    • sudo /sbin/service triggerd restart csctf-cell
  6. If you need to updated the configuration key, please refer to this link.

SPStandAlones

Description

The csctf/SPStandAlones area is where code to directly read and write Track Finder Crate registers resides. 
The main set of functions reside in SPStandAlones/test/readWriteRegisterFuncts. These executables are stand alone, 
there is no separate source code in this package. These read-write-register functions allow the user to directly read 
from or write to registers one by one and as such are assumed to be expert domain only. 

Examples (executable available at *SPStandAlones/bin, upon compilation):*

  • Write the CSR_PFD register on the SP2 (sitting on slot 7) to a value of 0x5: ./readwriteRegister -s7 -rCSR_PFD -cSP -mMA -pW -v0x5. The call above would write (-w) 0x5 (-v0x5) to the CSR_PFD register (-rCSR_PFD) on the SP chip (-cSP) of the SP in slot 7 (-s7).
  • Read CSR_PFD register on SP2: ./readwriteRegister -s7 -rCSR_PFD -cSP -mMA -pR

SPValidation

Description

The SPValidation library represents a suite of code to debug Sector Processor hardware and firmware. It is intended
that each time a new module is produced, an old one is repaired or a new firmware set is uploaded that the basic tests
would be run before any higher level processes incorporating the module are executed. For most of the executables in
SPValidation, one can obtain a listing of the arguments and functionality by parsing a -h argument.

Main executable available at *SPValidation/bin, upon compilation):*

  • The main test executable is SPValidation/bin/TestSPConsole. It runs several test. Example on SP7 (in slot 16): cd SPValidation/bin/ && ./TestSPConsole -s16. Select option "9" to run all tests and in case of problems, please report it to the CSCTF engineers, Alex Madorsky and Lev Uvarov
  • Pattern injection tests can be performed with SPValidation/bin/SPtester

Trigger Supervisor

Description

The trigger supervisor part of the CSCTF online framework resides in TriDAS/trigger/csctf/ts. This forms the “CSC Track Finder Trigger Supervisor Cell” 
and is responsible for the connection between the Track Finder control software and higher level CMS level-1 trigger control. The code controls
the hardware through functionality exported by the various packages and implements a SOAP interface with the “Trigger Supervisor Central Cell”.

* Main Classes:

  • Configuration: $CSCTF/ts/worker/src/common/MTCCIIConfiguration.cc
    • The function MTCCIIConfiguration::f_configure() is the one that is called by the Trigger Supervisor package when Trigger Control wants to configure the hardware. This is the code block which reads the dbs tables and perform the various configuration steps.

Monitoring

Monitored Registers

This list is chosen from a set of useful registers to be monitored and reported on Lev's document here.

Flashlist Name Stored on DBS Stored in /var/log/ Reported To L1 Page WHEN It is updated WHAT'S MONITORED ERROR TYPE
csctf_rates DONE DONE   if any value changes rate  
csr_af_efer DONE DONE   if any value changes/status changes optical link synchronization out-of-synch
csr_af_wordcount No DONE   if any value changes/status changes optical link synchronization out-of-synch
csr_cid_fw DONE DONE Stop as error if any value changes/status changes firmware firmware corruption
csr_cm1_lck1count No DONE   if any value changes/status changes    
csr_cm2_lck2count No DONE   if any value changes/status changes    
csr_lec_carrierextend No DONE   if any value changes/status changes    
csr_lec_errorword No DONE   if any value changes/status changes    
csr_lec_signalloss No DONE   if any value changes/status changes    
csr_lf_emptyflag No DONE   if any value changes/status changes    
csr_lf_fullflag No DONE   if any value changes/status changes    
csr_lf_wordcount No DONE   if any value changes/status changes    
csr_lnk_rxsd DONE DONE Stop as error if any value changes/status changes link status optical link error/broken
csr_osy_bxe DONE DONE ALERT! as warning if any value changes/status changes bx synchronization out-of-synch
csr_osy_bxl DONE DONE ALERT! as warning if any value changes/status changes bx synchronization out-of-synch
csr_osy_bxm DONE DONE ALERT! as warning if any value changes/status changes bx synchronization out-of-synch
csr_qdb_db_llck DONE DONE Stop as error if any value changes/status changes clock clock not locking
csr_qdb_lckd DONE DONE Stop as error if any value changes/status changes clock clock not locking
csr_qdb_lckq DONE DONE Stop as error if any value changes/status changes clock clock not locking
csr_ttcrq_llck DONE DONE Stop as error if any value changes/status changes clock clock not locking
dat_vpc_stubs No DONE   if any value changes rate  
dat_vpc_tracks No DONE   if any value changes rate  
emupageone No No   every 10 sec    
ms_rates DONE DONE   if any value changes rate  

How To Add A Register To Be Monitored

DISCLAIMER: this instruction is not complete and requires some amount of pre-existent knowledge of the code, but it is a good starting point.

  • Create a file $CSCTF/ts/src/worker/MonitorSource_RegisterName.cc (header file in /interface)
    • e.g MonitorSource_CSR_QDB_DB_LLCK.h (.cc)
    • You have to initialize a table and fill it according to what it is done in MonitorSource.cc
    • Structure it according to examples in the same directory, ie MonitorSource_CSR_LNK_RXSD.cc

  • step 0 is to check everything compiles:
    • edit $CSCTF/ts/worker/Makefile adding the compilation for the added class (under Sources)
    • compile: cd $CSCTF && make

  • step 1 is to edit the flashlist
    • cd $CSCTF/../setup/csctf
    • the example is still csr_lnk_rxsd.flash
    • be careful in defining the table and remember to give a unique periodic source name

    • modify the files in sensor/csctf-sensor(cell).sensor and sensor/general-las.las accordingly

  • step 2 is to edit the CellContext.cc adding the MonitorSource_RegisterName and compile

At this point you may want to check the flashlist appears before adding it to the tstore:

  • cd $CSCTF/ ../setup/csctf
  • ./reinstall

If you are convinced the code works and the fields get filled properly it is time to add the flashlist to the tstore

Useful Information

Where to Check the Quattor Profile

CAEN Driver

  • vmepc-e1x07-27-01: sudo /sbin/service a2818 [start/stop/status]

Some Info about JOB-CONTROL (xdaq-jc)

Without xdaq-jc working CSC CANNOT take local/global runs

It seems CSC is the only community using xdaq-jc with the TS. This had caused TS new releases to propagate CSC specific bugs, e.g. https://savannah.cern.ch/support/?112276. So whenever a new TS version is released please be careful about:

  • install XDAQ general_worksuite: "sudo yum -y groupinstall general_worksuite". This package does get installed by the TS installer.py script and it is contains the libraries like jobcontrol.so which need to be loaded by the xdaq
  • check that the log in /var/log/xdaq-jc.log does not report any error

How to fix errors:

  • Look into the xdaq web site https://svnweb.cern.ch/trac/cmsos. They announce there all the bug fixes with any new release
  • Since CSC community is much faster than TS one to update their software to the new XDAQ release, it is good to talk to CSC experts (Karoly and Jinghua)

Old Messy Instructions

COMPILING CVS CODE:

  • kinit digiovan@CERN.CH
  • cvs co TriDAS/trigger/csctf/
    • ALERT! It is checking out all the LUTs (TriDAS/trigger/csctf/SPLUTsAndFirmWare/LUTs/): is it needed? NO: remove them from the repository
    • ALERT! It is checking out all the firmwares (TriDAS/trigger/csctf/TrigData/TrackFinderCrate/SectorProcessor2002/firmware/): is it needed? NO: remove them from the repository

  • The SPValidation test needs the CMSSW dependency
    •  export CVSROOT=:gserver:cmssw.cvs.cern.ch:/cvs/CMSSW 
    • cvs co EventFilter/CSCTFRawToDigi/
    • cvs co IORawData/CSCCommissioning/
    • mv EventFilter/ IORawData TriDAS/trigger/csctf/SPValidation/test

Slc5X Migration

Prerequisites

  • Sysadmin installed the machine at 904, vmepc-e1x07-27-01
  • Connect to the machine:
    • first connect to the gateway machine ssh -X digiovan@cms904usr (same password as in P5)
    • Then you can connect to the CSC-TF machine, ssh -X vmepc-e1x07-27-01 or using the alias ssh -X l1ts904-csctf
  • From https://twiki.cern.ch/twiki/bin/view/CMS/TriggerSupervisor, the release to install is TS 1.12.0 and TTC 11.0.0 (compatible with SLC5 64 bits and XDAQ 11)

Steps

  • Install XDAQ, I followed https://twiki.cern.ch/twiki/bin/view/XdaqWiki/InstallWithYUM and installed the following suites:
    • sudo yum groupinstall "extern_coretools"
    • sudo yum groupinstall "coretools"
    • sudo yum groupinstall "extern_powerpack"
    • sudo yum groupinstall "powerpack"
    • sudo yum groupinstall "database_worksuite"
    • sudo yum groupinstall "general_worksuite"
    • sudo yum groupinstall "hardware_worksuite" <-- DOUBLE CHECK WITH KAROLY IF THIS DID NOT SCREW UP HIS CAEN INSTALLATION

  • Install TS:
    • sudo yum groupinstall "triggersupervisor"

  • sudo yum update sqlite sqlite-devel

COMPILING CVS CODE:

  • kinit digiovan@CERN.CH
  • cvs co TriDAS/trigger/csctf/
    • ALERT! It is checking out all the LUTs (TriDAS/trigger/csctf/SPLUTsAndFirmWare/LUTs/): is it needed? NO: remove them from the repository
    • ALERT! It is checking out all the firmwares (TriDAS/trigger/csctf/TrigData/TrackFinderCrate/SectorProcessor2002/firmware/): is it needed? NO: remove them from the repository

  • The SPValidation test needs the CMSSW dependency
    •  export CVSROOT=:gserver:cmssw.cvs.cern.ch:/cvs/CMSSW 
    • cvs co EventFilter/CSCTFRawToDigi/
    • cvs co IORawData/CSCCommissioning/
    • mv EventFilter/ IORawData TriDAS/trigger/csctf/SPValidation/test

  • COMPILATION:
    • Change x86_slc4 to x86_64_slc5 in all the Makefiles
    • SPBaseInteractions: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions && make" ( DONE! )
      • SPBaseInteractions/include/FWChecks.h -> extra-qualification error fixed
      • ALERT! src/common/SP_ReadLUT.cpp -> warning still there: ask Dayong if this is legacy code...
      • include/FPGAobject.h -> fixed the warnings
      • src/common/TrackFinderTest.cpp -> fixed the warnings
      • ALERT! src/common/SPObjectParser.cpp -> fixed the warnings, but is this legacy code? It seems used in several old SPFunctions/test routines, BUT it is used in SPValidation so cannot be removed -> we should clean all the pointer though...
      • src/common/utilities.cpp -> fixed the warnings
      • ALERT! ALERT! ALERT! when moving uint32_t to uint64_t I got the error below. Keep uint32_t in src/common/CCB_Setup.cpp, FPGAobject.ccp,TTC_Setup.cpp...
      •          src/common/CCB_Setup.cpp: In member function ‘long unsigned int ClockControlBoard::readFromRegister(char*, uint64_t)’:
                 src/common/CCB_Setup.cpp:86: error: no matching function for call to ‘ClockControlBoard::unmaskedRead(char*&, uint64_t*, uint64_t&)’
                /opt/xdaq/include/hal/HardwareDevice.hh:100: note: candidates are: virtual void HAL::HardwareDevice::unmaskedRead(std::string, uint32_t*, uint32_t) const
                make[1]: *** [/home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions/src/linux/x86_64_slc5/common/CCB_Setup.o] Error 1
        
                OR
        
                src/common/FPGAobject.cpp: In member function ‘short unsigned int FPGAobject::read(const char*, const char*)’:
                src/common/FPGAobject.cpp:61: error: no matching function for call to ‘FPGAobject::unmaskedRead(char*&, uint64_t*, long unsigned int&)’
                /opt/xdaq/include/hal/HardwareDevice.hh:100: note: candidates are: virtual void HAL::HardwareDevice::unmaskedRead(std::string, uint32_t*, uint32_t) const
                src/common/FPGAobject.cpp: In member function ‘short unsigned int FPGAobject::read(const char*)’:
                src/common/FPGAobject.cpp:85: error: no matching function for call to ‘FPGAobject::unmaskedRead(const char*&, uint64_t*, HAL::HalVerifyOption)’ 
                /opt/xdaq/include/hal/HardwareDevice.hh:100: note: candidates are: virtual void HAL::HardwareDevice::unmaskedRead(std::string, uint32_t*, uint32_t) const
                make[1]: *** [/home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions/src/linux/x86_64_slc5/common/FPGAobject.o] Error 1
                make[1]: Leaving directory `/home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions'
                make: *** [/home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions/.loop] Error 2
              
                OR
        
                src/common/TTC_Setup.cpp:68: error: prototype for ‘long unsigned int TTCvi::readFromRegister(char*, uint64_t)’ does not match any in class ‘TTCvi’
                /home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions/include/TTCvi.h:68: error: candidate is: long unsigned int TTCvi::readFromRegister(char*, uint32_t)
                src/common/TTC_Setup.cpp: In member function ‘long unsigned int TTCvi::readFromRegister(char*, uint64_t)’:
                src/common/TTC_Setup.cpp:75: error: no matching function for call to ‘TTCvi::unmaskedRead(char*&, uint64_t*, uint64_t&)’
                /opt/xdaq/include/hal/HardwareDevice.hh:100: note: candidates are: virtual void HAL::HardwareDevice::unmaskedRead(std::string, uint32_t*, uint32_t) const
                make[1]: *** [/home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions/src/linux/x86_64_slc5/common/TTC_Setup.o] Error 1
                make[1]: Leaving directory `/home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions'
                make: *** [/home/csctf/TS1_12_0/TriDAS/trigger/csctf/SPBaseInteractions/.loop] Error 2
        
    • SPFunctions: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPFunctions && make" ( DONE! )
      • include/CCBfunctions.h -> extra-qualifier error
      • ALERT! did not correct the warnings in SPYFIFOFuncs::test_core_only -> is this still needed? I think not: double check with Alex
      • ALERT! rawDataUtils -> still warnings from createLCTdataFile_fromORCAdata: suppress this function?
      • commandParser -> fixed warning and indenting in executeFile function
      • src/CCBfunctions.cc -> fixed warnings
      • src/registerSettings.cc -> fixed warnings: is this class used?
      • unit32_t -> uint64_t issue on src/msConfigs.cc,src/monitorables.cc
    • SPFunctions/test: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPFunctions/test && make bin" ( DONE! )
      • parseCommandFile.cpp -> fixed the warnings
      • ALERT! main.cpp -> fixed the warnings: is this still needed?
      • fullpatterntest.cpp -> fixed warnings and indented
      • unit32_t -> uint64_t issue on test/initCCB.cpp,test/init_MS.cpp, test/MSbits_test.cpp
    • SPLUTsAndFirmWare: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPLUTsAndFirmWare && make" ( DONE! )
    • SPLUTsAndFirmWare/test: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPLUTsAndFirmWare/test && make bin" ( DONE! )
      • crateLoadLUTs.cpp -> fixed the warnings
      • crateRunCRC.cpp -> fixed the warnings
      • compareLUTs.cpp -> fixed the warnings
    • SPValidation: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPValidation && make" ( DONE! )
      • ALERT! Not suppressed the warnings from Alex's code
      • replace <pair.h> with in include/SPtest.h
      • ALERT! SPtest_dumpState.cpp -> did not correct the warning, but not sure this code is used anywhere
    • SPValidation/test: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPValidation/test && make bin" ( DONE! )
      • Update the GNUMakefile to incorporate x86_64_slc5
      • Corrected all warnings
    • SPStandAlones/test: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/SPStandAlones/test && make bin" ( DONE! )
      • ALERT! generalUtilities/SPascii2bin.cpp has a warning about strstream, but leave it for the time being
      • unit32_t -> uint64_t issue on readWriteRegisterFuncts/readwriteRegister_CCB.cpp, readWriteRegisterFuncts/readwriteRegister_MS.cpp

  • TRIGGER SUPERVISOR: "cd $HOME/TS1_12_0/TriDAS/trigger/csctf/ts/worker && make" ( DONE! )
    • ALERT! did not suppress the warnings in src/common/MonitorSource.cc as this is going to be removed
    • src/common/MTCCIIConfiguration.cc -> fixed the warnings

Repository

The csctf repository in TriDAS is available at http://isscvs.cern.ch/cgi-bin/viewcvs-all.cgi/TriDAS/trigger/csctf/?root=tridas

  • slc5-V00-02: tagged at P5 on 14th September 2012:
    • Synchronize the repository with new firmware files, etc, etc before the technical stop starting 17th September 2012

  • slc5-V00-01: deployed at P5 on 19th March 2012 (Elog 756444):
    • Halo rate is read from a dedicated register (SP/DAT_HLC) and not anymore from the 3rd link of the SP. This was a request from the CSC community in order to have a more reliable halo rate
    • Monitor and record in the DBS the QPLL status for the CCB
    • Repository synchronized to the latest firmware change on the SP chip, SP 22/03/11

  • slc5-V00-00: deployed at P5 on 5th March 2012:
    • slc5 x86 64 bits architecture compatible
    • restructuring of the flashlists and database problem to fix issue with tables growing up exponentially, see https://savannah.cern.ch/support/?122779
    • removed csctf-pulser and moved from a single MonitorSource to multiple PeriodicSources which writes in the database only at value changes or if the status of the Cell changes
    • clean-up of about 3.5 Gb of firmwares files and LUTs committed to CVS (CVS is not meant to store such files)
    • commit of scripts to write CSCTF configuration key and pt LUTs in the dbs

  • slc4atP5 contains the code before the slc5 deployment of 5th March 2012 which was used throughout all the 2010-2011 data taking with minor changes

Migrate to SVN (Work in Progress)

Steps


*OLD INSTRUCTIONS TO HIDE*

Connect To CVS

At P5

Now you are ready to communicate to CVS from /nfshome0/csctfts/TriDAS/.

At 904

Since January 2012 904 has been configured as P5 so you need to follow the same prescription of P5:

  • Sysadmin installed the machine at 904, vmepc-e1x07-27-01

OLD CSCTF SLC4 MACHINE:

-- GianPieroDiGiovanni - 07-Dec-2011

Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r22 - 2013-12-17 - GianPieroDiGiovanni
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback