SlacTestBeamDec2014

Introduction

The LBNL Atlas R&D group performed a series of measurements using a 15 <noautolink>GeV</noautolink> e- test beam at SLAC's ESTB facilities in December 2014. The following serves as a guide to the running of the equipment during test beam, shifter training, results, analysis, and relevant simulation results.

Motivation and approach

TODO

General ESTB info

Safety - emergency (non-life threatening): x-7777

Safety - contact:

Test beam concerns:

On call experts (?)

Setup

The dut's are mounted to Carbon-fibre backing and screwed to each side of an Aluminium ramp at various positions, depending at which angle the ramp is inclined. Screws have been positioned at pre-measured points for each of the angles under which to test to facilitate measurements during beam-time. The entire setup is mounted on a remote-controlled x-y table, to move the DUT's into position and align during run-time.

 
 
 
Setup from above in the test beam area. The setup is mounted to an x-y table. 
 

 
 
 
All powering for the DUT's is on the x-y table, below the rack. 
 

Information about the test setup at LBNL, used to prepare for test beam can be found here: http://phyweb.lbl.gov/atlaswiki/index.php/RCE_test_setup.
Please note that LBL Wiki access is required to view.

DUT

Name	FE and sensor type	High voltage (sensor)	Low voltage (FE)	Nominal FE current (before/after configuration)	Picture	Notes	IV scan (sensor)	Configuration files, various tunings (mvp)
Guin's module	FE-I4A, 3D FBK	Depletion ~10V, breakdown ~30V, nominal ~15V (compliance 30uA)	Separate Ana and Dig supplies. Ana: 1.5V (compliance 0.5A), Dig: 1.2V (compliance 0.2A)	Ana: 0.03A, 0.3A; Dig: 0.08A, 0.03A	Guin's module	FE-I4A chip, NO REGULATORS, power analogue and digital separately (1.5V and 1.2V respectively).	Characteristic IV - 3D FBK (Guin)	Guin 3000e, 2000e, 1500e, 1000e
22-08-25	FE-I4B, 3D FBK	Depletion ~10V, breakdown ~9.9V, nominal ~9-11V (compliance 50uA)	2V (compliance 0.5A)	0.24A, 0.36A	22-08-05	LOW BREAKDOWN SENSOR - HV <= 11V MAX.	Characteristic IV - 3D FBK (22-08-25)	22-08-25 3000e, 2000e, 1200e
93-04-03	FE-I4B, planar	Depletion ~60V, breakdown ~350V, nominal ~ 150V (compliance 40uA)	1.5V (compliance 1A)	0.45A, 0.73-0.85A	93-03-04	FE-I4B chip, DIGITAL REGULATORS BYPASSED, 1.5V max.	Characteristic IV - planar (93-03-04)	93-04-03 3000e, 2000e, 1500e, 1000e
94-01-04	FEI4B, planar	Depletion ~60V, breakdown ~250V, nominal ~150V (compliance 100uA)	2.0V (compliance 1A)	1.07A, 0.72A	TODO	LVDS0 FE chip is analog dead. See elog entry.	Characteristic IV - disconnected, connected, configured (94-01-04)	94-01-04 3000e, 2500e, 2000e, 1500e, 1200e, 1000e
60-03-03	FEI4B, 3D	Depletion ~10V, breakdown 8V, nominal : as close to 8 as you can get (compliance 1A)	2.0V (compliance 0.5A)	0.28A, 0.41A	TODO	Low breakdown sensor, cluster of analog dead pixels in middle of module	n/a	60-03-03 3000e, 2000e,1000e

Retired DUT

Name	FE and sensor type	High voltage (sensor)	Low voltage (FE)	Nominal FE current (before/after configuration)	Picture	Notes	IV scan (sensor)	Configuration files, various tunings (mvp)
33-01-02	FE-I4B, planar	Depletion ~60V, breakdown ~320V, nominal ~150V (compliance 40uA)	1.5V (compliance 1A)	0.31A, 0.63-0.74A	33-01-02	FE's broken - module no longer functional FE-I4B chip, DIGITAL REGULATORS BYPASSED, 1.5V max.	Characteristic IV - planar (33-01-02)	33-01-02 3000e, 2000e, 1500e, 1000e

Readout

Overview

Please see attached pdf for an overview of the setup : TB2014 Overview.

• Readout from the FE-I4 chips is done via an ethernet link to the HSIO cosmic's board. The HSIO controls the outlinks (data from each chip) and the shared inlinks (cmd, clk) and generates the chip clock.
• The HSIO passes the data to the CIM (Cluster Interconnect Module) in the ATCA crate via a fibre.
• The CIM passes the signals to the functioning RCE's (Reconfigurable Cluster Element) along the back plane of the crate.
• The rce's issue commands and perform all of the histogramming during the run.
• The CIM is also connected to the PC running the relevant software to take data during the run via ethernet cable.
  It is recommended that both the ethernet connection between PC-CIM and HSIO-FE-I4 be shielded, cat6 cables.
  There is only one functioning RCE in the ATCA crate at ESTB: rce #20.

 
 
 
HSIO connections 
 

 
 
 
CIM connections 
 

 
 
 
RCE connections 
 

Procedure

At the start of a new run

In the beam hall

1. Check that the modules are drawing nominal current from the LV supplies. Note that if these modules have not yet been run in the setup, they are likely unconfigured and will have different values than if they are configured. Please check the table for typical values for each module. Make a note of the current, configured and unconfigured before leaving the test beam area.
2. Check the ethernet connections between the FE-I4 adaptor cards and the HSIO CosmicsBoard. Please make a note of which module is attached to which ethernet connector on the cosmicsBoard. This will enable debugging connectivity issues later if necessary.
3. Take a look at the LCD screen on the HSIO. It shows the connection between the CIM and the board: a good connection will be of the form: Lxxx, where x is any number or letter. A problem will be shown with a Pxxx, an error with Exxx. Since we are only using one connection on the HSIO we expect the LCD screens to display 1 Pxxx message and 1 Lxxx message. If both display a Pxxx message, check the fibre connection.
4. Check the RCE display. POPO is good.
5. Before starting the run, make sure we can communicate with all the modules! We'll do this first in the TB area, directly on the SunPC. This will then be repeated in the counting room before beam.

 
 
 
HSIO status 
 

 
 
 
RCE status 
 

Check module communication with calibGui

For this you will be using a Sun machine, running RHEL. Username: tbslac Password: tb2014

Open a terminal window.

1. Much of the software was designed, and will only run, in a tcshell. To check you are in the right environment type: $0. If this does not return tcsh, then type tcsh and try again.

            $ echo $0
            -bash
            $ tcsh
            % echo $0
            tcsh

1. Change into the daq/rce directory. From here source an enviromental setup script and the StartPartition scripts:

          $ cd ~
          $ cd daq/rce
          $ source scripts/setup_rce-04-00-01.csh
          $ rce_killall
          $ ipc_server &
                    [1] 28545
          $ LOG 2014-Nov-24 10:26:53 [int main(...) at ipc/bin/ipc_server.cc:307] ipc_server for partition "initial" has been started.

          $ rce_ipc_server &
                    [2] 28554
          $ LOG 2014-Nov-24 10:27:34 [int main(...) at ipc/bin/ipc_server.cc:307] ipc_server for partition "rcetest_pixel" has been started.

          $ rce_is_server &
                    [3] 28558
          $ LOG 2014-Nov-24 10:27:51 [int main(...) at is/server/main.cc:113] number of workers is set to 7
                    LOG 2014-Nov-24 10:27:51 [int main(...) at is/server/main.cc:114] number of concurrent callbacks is set to 8
                    LOG 2014-Nov-24 10:27:51 [int main(...) at is/server/main.cc:176] the 'RceIsServer' IS server started in the partition 'rcetest_pixel'

NB You should only have to run rce_killall after a major crash or on the very first run. The rce can be fragile to kill commands, if in doubt just don't do it!

1. Then load the rce with the following script:

          $ rce_load rce20
                    HOST => rce20: reboot
                    HOST <= rce20: Rebooting...
                    HOST => rce20: setenv TDAQ_PARTITION rcetest_pixel
                    HOST <= rce20: OK
                    HOST => rce20: setenv TDAQ_IS_COMPRESSION_THRESHOLD 100000000
                    HOST <= rce20: OK
                    HOST => rce20: setenv TDAQ_IPC_INIT_REF                                                   IOR:010000001600000049444c3a6970632f706172746974696f6e3a312e3000000001000000000000006c000000010102000c0000003139322e3136382e312e3100fba3000016000000ff6970632f706172746974696f6e00696e697469616c00000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100
                    HOST <= rce20: OK
                    HOST => rce20: download 10421844 bytes
                    HOST <= rce20: OK
                    HOST => rce20: Uploading module.
                    HOST <= rce20: OK
          $

This command may fail for a number of issues. Often it is simply because the rce has crashed. A quick way to check is to see if you can ping rce20. If not try and reset the rce by pushing the rce pin. The pin is deep, so a pen won't fit - try using a piece of sturdy wire provided. See this document for further debugging.

1. To run calibGui, simply type 'calibGui' into the terminal.
2. Before running scans always check the data directory, so you are not overwriting anybody's work. See images below for instructions.
3. A digital and analogue scan should be enough to determine if there is a connection. Note that if even one module is connected incorrectly all scans will fail. If this is the case, try iterating through the module includes on the staveA tab to figure out which one it is and check the outlink the rce expects is the one that the module is connected to!

 
 
 
Front panel for calibGui. 
 

 
 
 
Notes for calibGui use. 
 

 
 
 
Module panel in calibGui 
 

 
 
 
Notes on Module panel 
 

 
 
 
This is where results are displayed 
 

            FEI4B: addModule (A1-1, 33010200, 0, 0, 68, )
            FEI4B: addModule (A1-2, 33010201, 0, 1, 68, )
            FEI4B: addModule (A2-1, 93040300, 1, 2, 68, )
            FEI4B: addModule (A2-2, 93030400, 1, 3, 68, )
            /home/pixel
            RCE 68: Mask Stage 0
            RCE 68: Mask Stage 1
            RCE 68: Mask Stage 2
            RCE 68: Mask Stage 3
            RCE 68: Mask Stage 4
            RCE 68: Mask Stage 5
            RCE 68: Mask Stage 6
            RCE 68: Mask Stage 7
            RCE 68: Mask Stage 8
            RCE 68: Mask Stage 9
            RCE 68: Mask Stage 10
            RCE 68: Mask Stage 11
            RCE 68: Mask Stage 12
            RCE 68: Mask Stage 13
            RCE 68: Mask Stage 14
            RCE 68: Mask Stage 15
            RCE 68: Mask Stage 16
            RCE 68: Mask Stage 17
            RCE 68: Mask Stage 18
            RCE 68: Mask Stage 19
            RCE 68: Mask Stage 20
            RCE 68: Mask Stage 21
            RCE 68: Mask Stage 22
            RCE 68: Mask Stage 23
            RCE 68: Mask Stage 24
            RCE 68: Mask Stage 25
            RCE 68: Mask Stage 26
            RCE 68: Mask Stage 27
            RCE 68: Mask Stage 28
            RCE 68: Mask Stage 29
            RCE 68: Mask Stage 30
            RCE 68: Mask Stage 31
            RCE 68: Downloading
            Analyzing
            Digital test analysis
            Done

In the counting room

Since we know that everything is working from the beam hall we can rely on the physical connections all being correct so any problems we experience in the counting room are purely network/software. Also, be aware that the counting room pc has no external internet/network connection. If you want to go online, use your own computer.

1. First, ssh into the test beam computer, remember the -XY for x11 forwarding so you can see the Gui. When we checked this pc had a static IP.

                 ssh -XY tbslac@172.27.104.28.slac.stanford.edu

1. Then run through setting up the partition again (no killalll command) and connecting to the rce. This time try running cosmicsGui:

 
 
 
CosmicGui front panel 
 

 
 
 
Notes - front panel 
 

 
 
 
CosmicGui DUT panel 
 

 
 
 
Notes - DUT 
 

 
 
 
CosmicGui monitoring panel 
 

 
 
 
Notes - monitoring panel 
 

From the DAQ standpoint, we are now ready for beam.

Assuming beam is present:

With the module physically aligned, we need to align the arrival of the trigger and the chip latency. This is done with cosmicsGui.

1. Adjusting the timing such that triggers fall on the arrival of data usually involves adjusting just one parameter: the DUT latency on the cosmicsGui front panel (see image above).
2. In the graphic above you can see three separate events. Event 1 is not large enough to trigger the chip (below threshold), so produces no output. Event 2 is large enough to be recognised as a hit but has its Trig_Latency value fall out of time with the trigger. Event 3's Trig_Latency and trigger exactly match up, so it is read out. This is what we are doing when adjusting the trigger latency: coinciding the output of the chip with the beam clock trigger to get an output.
3. A good latency value to start with is 235 (i.e. 255 - 20), in units of bunch crossings/clock cycles (25ns). When trying to find the correct latency, set 16 consecutive triggers - that will effectively give you a larger window with which to identify the correct latency.
4. Play around in steps of 5 above and below 235 until you start to see hits on the occupancy histogram, in the live monitoring output. Wait at least 5 seconds before trying a new time.
5. When you start to see hits look on the timing histogram. Ideally, you want all the entries to be centered in the middle of the range of the number of consecutive triggers. During runtime we'll try running with 8 consecutive triggers, so try and tune the timing such that the median entry is 4. Please see some screenshots below for examples of a tuned latency.

 
 
 
Example of a few hits of the live occupancy. 
 
 

 
 
 
Latency tuned to 6 for 12 consec. triggers 
 

Run plan

Link to google spreadsheet: https://docs.google.com/spreadsheets/d/1fm4cSXEVXGUrT0D5Ck6xEeMZ8lo1HTHVJBkB9E-9h8I/edit#gid=0

Shifts

Analysis task list

Please click here for google doc. You may need to request access: https://docs.google.com/spreadsheets/d/1xLIXKW_T_jJk9n64ZqAyXJwgW34_VcVP_QzqW6X4R88/edit?usp=sharing

<!-- ********************************************************* --> <!-- Do NOT remove the remaining lines, but add requested info as appropriate --> <!-- ********************************************************* -->

<!-- For significant updates to the topic, consider adding your 'signature' (beneath this editing box) --> Major updates:
-- RebeccaCarney - 16-July-2014 <!-- Person responsible for the page: Either leave as is - the creator's name will be inserted; Or replace the complete REVINFO tag (including percentages symbols) with a name in the form TwikiUsersName -->
%RESPONSIBLE% RebeccaCarney
<!-- Once this page has been reviewed, please add the name and the date e.g. StephenHaywood - 31 Oct 2006 -->
%REVIEW% Never reviewed

-- RebeccaCarney - 2014-11-13