TIF Pixel Guide

---

---

Cold Start

• Plug in power supplies to test boards (6V)
  • Check for welcome message on the test board
  • Check for red LED on the interface board

• Connect aqua fiber to laser channel 0 (farthest from sticker)

• Wiring of LEMO connectors on the test board
  • LEMO 4 - test board output
  • LEMO 5 - trigger
  • LEMO 6 - PLL and event # reset
  • LEMO 7 - clock

• Turn on VME crate

• Turn on NIM crate
  • Test board output from LEMO 4 on test board goes to the scope
  • Trigger from the TTC goes into the level translator and to the scope from the level translator
  • Output from level translator (TTL) goes to the counter and the test board
  • Channel 0 of VME controller goes to the level translator, output goes to the PLL reset on the test board (LEMO 6)
  • Clock goes from TTC to the level translator (terminated on the input), TTL output goes to the test board clock (LEMO 7)

• Turn on the scope
  • Channel 1: test board output
  • Channel 2: decoded output of channel A and B (other end is connected to the second input from left) on FED ch24
  • Channel 3: Trigger
  • Channel 4: TBM header detected signal (FED does not detect the event if there is not a TBM header signal) - on FED ch24

• Turn on laptop
  • login: PCCMSKU01/tifteam (Pccmsku01)
  • Open terminal (cmd)
  • cd \Firmware\meier_b_40MbpsPseudoRan\meier_b_40Mbps\projekte\aohtest\aohtester\Release
  • execute "aohtester.exe log.txt"
  • issue "init"
  • lldw ch# value - to write value to channel # (channel should be 0)
  • lldr ch# - to read value of channel #
  • set to bias = 15, gain = 1

Here is a link for ... https://twiki.cern.ch/twiki/bin/viewauth/CMS/PixelPireKU

Editing Firmware

• Start Quartus
• Click on 'open existing project'
• Open: \Firmware\400MbpsTbmSim_New\meier_b_40Mbps\projeckte\aohtest\fpgapixel\cdg001
• Click on `cdg001` - upper left corner
• Edit the firmware - e.g. scroll down to SER_DATAupd and change the # of pixel hits per roc
  • Double click on the box that `parameter box`
  • Click on the `parameter` tab
  • Change the value!
• Compile by clicking on the `start compilation icon` on the tool bar - right-center

Adding FED to ControlHub

• Look up the MAC address for the FED you wish to add using "sudo tshark -i eth1"
• Login to the ControlHub pc at xtaldaq@cmsuppixchNOSPAMPLEASE.cern.ch
  • Ask someone in lab for the password
• Add MAC address to the /etc/ethers file and give it a unique name
• Add new IP address with the same unique name in /etc/hosts
• Follow steps 3 & 4 on the pc you are using for your project

Changing Firmware on the test board

• Connect to USB-Blaster to laptop (make sure there are no other usb connected to the laptop) and jtag connection on the test board - use the one that is closer to the LEMO connectors
  • To check the status of the connection go to Quartus and click on the `Programmer icon` on the tool bar - right-hand side
  • Hardware Setup should read `USB-Blaster [USB-0]`
• From All Programs click on `Altera 12. Build 178`
• Click on `Nios II EDS 12.0`
• Click on `Nios II 12.0 Command Shell`
• cd /Firmware/400MbpsTbmSim_New/meier_b_40Mbps/projeckte/aohtest/software/programmer/
• execute `./flash`
  • check for the blue light on the blaster
• power cycle the test board - check for the welcome message on the test board
• If it complains about Nios II processors not being available and PLD not configured correctly,
  • go to programmer in Quartus and click 'start'. Make to see '100% successful' message on the up-right corner.
  • execute './flash' again

There are already compiled firmware in folders /2hit and /3-1hit

• cd /Firmware/400MbpsTbmSim_New/meier_b_40Mbps/projeckte/aohtest/software/programmer/2hit OR /3-1hit
• execute `./flash`
  • check for the blue light on the blaster
• power cycle the test board - check for the welcome message on the test board

As of 10/09/2013

• Helmut's new firmware for the test board and the daughter board are located in the laptop(PCcmsku01) at Desktop/Helmut_Firmware
• To change the test board firmware follow the above steps
• To change the firmware on the daughter board use Quartus programmer

Phase Finding on the Daughter Board

• Start Quartus
• Open Desktop/Helmut_Firmware/ArriaCDR_b
• Goto 'Tools->In-System Memory Content Editor'
• Choose Instance Index 22 (PH_l)
• 'F5'

Test Software on cmsfpix2 machine

• Log in to cmspixels@cmsfpix2 (cmspixels)
• cd OL320test/pxlfed/
• ./pxlfed
• '7' for PLL reset
• 'k' for FED reset
• '2' for sending a trigger
• 'a' for reading out once
• 'c' for multiple reading out

Test Software for test board

• Make sure laptop is connected to test board via ftdi
• Turn on laptop
• login: PCCMSKU01/tifteam (Pccmsku01)
• Open Visual Studio 2010 -> testboard
• 'F5' for build
• '0' Gets version of the ftdi device
• '1' Welcome message on the test board
• '2' Write laser bias and gain //TxBuffer[2] = register (0=bias, 3=gain), TxBuffer[3] = register value
• '3' Read laser bias and gain
• '4' Counter reset
• '5' Fill data pattern
• '6' Pll reset

As of 27/05/2014

• Pilot w/ 2 daughter boards are @ TIF
• New firmwares are located on the laptop, Desktop/Helmut_Firmware

JTag connection to the Daughter Board

• This is the firmware we use ArriaCDR_c_22Oct2014.jic
• Start Quartus
• Goto 'Tools->In-System Memory Content Editor'
• If needed click on setup and choose the appropriate USB-Blaster as hardware
• Once the instances are found you should see 10 of them 0-9
• 0 - PF_p - Phase finding algorithm
  • bit[0] enable phase change during data taking and not only during idle pattern
  • bit[1] 1 code error allowed before phase is incremented
  • bit[2] 16 -----------------------------"-------------------------
  • bit[3] 512 ------------------------------"-------------------------
  • one of the bits[3..1] has to be set ! default bit[1]=1
  • bit[5..4] time to detect code errors 00 ...62ms 01 ... 125ms 10 ...250ms
  • bit[7..6] reserved
• 1 - MP11 - sets the phase for fiber#11, from 8 to f (each moving the phase by 312ps)
• 2 - LedM changes fiber link, can do 'f5' and write a different ch
• 3 - TP_M - test pin mux
• 4 - N_la - data from channel a
• 5 - N_lb - data from channel b
• 6 - TR_A - 0s and 1s from channel a
• 7 - TR_B - 0s and 1s from channel b
• 8 - VERS - version of the firmware
• 9 - COM1 - communication from FED to Piggy board - numbers you see are the numbers that is sent to Piggy board from the FED (case'6' of pxpilotfed.cpp)
• 10 - PH_l - phase of channel l
• 'F5' to read and 'F7' to write
• TP_M options
  • 0 - CDR400Mbd
  • 1- TBM_channel_a
  • 2 - TBM_channel_b
  • 3 - ROC marker channl_b
  • 4 - Trailer marker channel_b
  • 5 - Trailer marker channel_a
  • 6 - Code Error
  • 7 - WE to FED channel_a
• LedM options - selects only the LEDs and in the in In-System Memory Content Editor items PH_l; N_la and N_lb
  • 0 - fiber 12
  • 1 - fiber 11
  • 2 - fiber 10
  • 3 - fiber 9
  • 4 - fiber 8
  • 5 - fiber 7

Changing the firmware on the Daughter Board and front FPGAs

• Start Quartus
• Goto 'Programmer'
• Choose the right hardware, Daughter Board connection is same as before, for the front FPGAs a blaster w/ a small connector needs to be attached to each of the front fpga connections (should be done one at a time)
• Click on "AutoDetect" if the device hasn't detected, if problems with the chain -> power cycle the crate
• Click on 'Add File' and choose the right firmware to upload, firmware files live in 'Desktop/Helmut_Firmware'
• Click on 'Program/Configure' and 'Verify'
• Once the file is added, click 'Start'

Submitting a Faulty Report for broken vme electronics (just in case) - we had a power supply failure

This is the link for the CERN Electronics Pool: http://ph-dep-ese.web.cern.ch/ph-dep-ese/pool/pool.html

• Click on `Power supplies`
• Click on `Maintenance/repair`
• Click on `fault report`
• Click on `Items` tab
• Fill in the search parameters - LHC Inventory No and Serial No
• Click on `search`
• Click on `enter faulty report` and fill in the report

Take the power supply with the fault report to the CERN Electronics Pool (Bdg 13-R-009) open between 10h-12h and 14h-16h. Repairing process should take 3 to 5 weeks!

Sending vme electronics for repair

The person you need to contact is Tina Vernon, a Fermilab secretary based at CERN.

• Office: 591/R-008
• Phone: 79779
• Mobile: 162403

You need to provide,

• The full address and receiver's name
• A budget code
• Estimated value for the electronics that you send

Registering a PC to a network outlet and configuring the outlet as a fanout

• cern network portal : https://network.cern.ch/
• move and reconnection of a device
• search cmsfpix2 // or any other PC
• use the outlet ID:0B04/07 // or any other

Once a PC is registered to an outlet, configure the outlet as a fanout!

• cern service portal : https://cern.service-now.com/service-portal/
• log in
• report an issue -> submit a ticket

Call Service desk - 77777

• If something breaks - like A.C.

Links for requesting an internal/external transport via EDH

• https://edh.cern.ch/Document/SupplyChain/TransportRequest
• https://edh.cern.ch/Document/SupplyChain/SHIP

Useful Links

• http://cms.web.psi.ch/phase1/psi46dig/index.html
• FNAL test stand: https://twiki.cern.ch/twiki/bin/view/Sandbox/FPixPhase1UpgradeTestStandAtFNAL

Test stand set up in clean room with new PC

• Log in as cmspixp1@pixp1daq
• Open terminal with five tabs (the script teststand_terms.sh on the desktop will open all five with nice titles for you, already =cd=ed into the right directories):
  • In first tab

    cd ~/build/TriDAS/pixel/BPixelTools/ccu
    . setup.bsh
    ../../../FecSoftwareV3_0/ThirdParty/APIConsoleDebugger/bin/linux/x86_64_slc6/ProgramTest.exe -crateReset
    ../../../FecSoftwareV3_0/ThirdParty/APIConsoleDebugger/bin/linux/x86_64_slc6/ProgramTest.exe -fec 9 -ring 8 -reset
    #../../../FecSoftwareV3_0/ThirdParty/APIConsoleDebugger/bin/linux/x86_64_slc6/ProgramTest.exe -fec 9 -ring 7 -reset
    ./run.bsh
    

  • In second tab

    cd ~/build/TriDAS/pixel/BPixelTools/test
    . ~/build/TriDAS/setenv.sh
    python testPortCard.py
    

  • In first tab

    #For BmO
    pixdcdc on 2 7e
    
    # turn on laser biases and gains
    i2c 10 10 22
    i2c 10 11 22
    i2c 10 12 22
    i2c 10 18 22
    #i2c 10 13 3f #2bits for each channel
    #i2c 10 1b 3
    

  • In third tab

    cd ~/build/TriDAS/pixel/BPixelTools/pxfec
    . setup.bsh
    ./run.bsh
    # enable a pixel on every ROC
    arm 4 4 # corresponds to DC=2, PXL=152
    

  • In fourth tab

    cd ~/build/pxlpilotfed/ttcci_standalone
    . ~/build/TriDAS/setenv.sh
    ./run_ttcci.csh
    # open a firefox tab to http://pixp1daq.cern.ch:1974/urn:xdaq-application:service=hyperdaq (bookmarked as "TTCci standalone xdaq")
    # open a firefox tab after connecting to your cmsusr account to http://vmepc-s2b18-08-01.cms:1974/urn:xdaq-application:service=hyperdaq
    # click on "ttc TTCciControl"
    # click "configure"
    # click "enable"
    

  • In fifth tab

    cd ~/build/pxlpilotfed
    . ~/build/TriDAS/setenv.sh
    ./pxlpilotfed
    # check phases with 6, reload firmware and reset with 2, 3, 4, send trigger and readout with a
    

RingAddress is defined in 4 places. BPixelTools/ccu/src/ccu.cxx - line: 1699 and 1724, BPixelTools/test/testPortCard.py - line: 39, BPixelTools/pxfec/data/d.ini - line: 4, BPixelTools/ccu/data/fec_ring_ccu_channel_group.txt - line: 1

• HistoViewer
  • cd ~/build/TriDAS/pixel/PixelHistoViewer
  • . ~/build/TriDAS/setenv.sh
  • ./StartAll 2001
  • open a firefox tab after connecting to your cmsusr account to http://vmepc-s2b18-08-01.cms:2001/

Pilot Blade Installation

TkFEC is installed in slot 9, PixFEC is installed in slot 12 and Pilot FED is installed in slot 15.

BmO
             mFEC/Piggy Card     Ribbon #              USC                             PP0                     HC Connection               
TkFEC             8                         3           S1G03-up Slot 10-11        -z up right 2: 7                  CCU
PixFEC            8                         5           S1G01-Mid Slot 10(R)      -z down right 2: 5          PC/mDOH
FED                Up                        2           S1G03-up Slot 12-13       -z down right 2: 4            PC/POH

BmI
              mFEC/Piggy Card     Ribbon #              USC                             PP0                      HC Connection               
TkFEC              7                         3             S1G03-up Slot 12-13       -z down left 2: 7               CCU
PixFEC             7                         4             S1G03-up Slot 10-11         -z up left 2: 3              PC/mDOH
FED              Down                      2             S1G01-Mid Slot 10(L)         -z up left 2: 5                PC/POH

Pilot Blades are implemented in DCS under 'CMS Tracker/PixelEndCap/Blade' tab.

BmI and BmO have separate tabs with DCDC, control power and ROG1 (for BmI).

• This is the map of CAEN Main frame to pilot electronics:
  • Ch0235 - BmI module direct power
  • Ch0247 - BmI PC/CCU
  • Ch0293 - BmI DC-DC (eternal loads only)
  • Ch0298 - BmO DC-DC (module power + eternal loads)
  • Ch0305 - BmO PC/CCU
• This is the complete map: https://twiki.cern.ch/twiki/bin/viewauth/CMS/PixelCaenSpareComponents
• Typical values for currents
  • BmI Direct Power
    • I_dig=2.26A (@ 16C), 2.22A (@ -10C)
    • I_ana=1.17A (@ 16C), 1.15A (@ -10C)
  • BmI DC-DC (Port0 enabled)
    • I_dig=0.48A
    • I_ana=0.34A
  • BmI PC/CCU
    • I=1.41A
  • BmO DC-DC (Port2 enabled)
    • I_dig=0.68A
    • I_ana=0.44A
  • BmO DC-DC (Port1&&Port2 enabled)
    • I_dig=1.17A
    • I_ana=0.85A
  • BmO PC/CCU
    • I=1.37A
• In /nfshome0/pixelpilot/build/TriDAS/pixel/BPixelTools/test there are two scripts to program delay25 registers
  • testBmI_PortCard.py and testBmO_PortCard.py
  • for BmI RDA(0x30) is needed to be set to 0x52 (instead of 0x56 - clean room value) to have green light on PixFEC mFEC

• Port Card registers
  • 0x30 - RDA
  • 0x31 - RCLCK
  • 0x32 - SDA
  • 0x33 - CTR
  • 0x34 - CLCK

DC-DC control via CCU PIA channel

I (JMT) modified ProgramTest in FecSoftware to take another command -piaDCDC, which calls testPIADCDCJMT in APIAccess.cc. The cables are hooked up such that the two LSB of the PIA register 0x30 are the control or powergood bits for the two DC-DC outputs, with 1 being off and 0 being on. This function is just to demonstrate control through the software. It

• initializes data direction register (DDR) to 0 (input)
• initializes data register to 0xFF (so we don't blast random junk out when we set DDR to output)
• sets DDR to 3 (output on two LSB)
• sets data register to 0xFC (turn on both outputs)
• sets data register to 0xFF (turn off both outputs)
• sets data register to 0xFC (turn on both again)
• sets data register to 0xFF (turn off)
• sets DDR to 0 (all back to input)

with a printf and getchar() between each step so you can watch the currents change on the caen screen. Make sure you run ProgramTest with the right CCU address, e.g. -ccu 7E. Reading the powergood bit back through CCU 0x7d is demonstrated in some commented out code in testPIADCDCJMT.

More control is available with my mods to the BPixelTools/ccu program. You set the CCU and PIA channel addresses with

ccu 7e
piaChannel 30

which piaChannel and which addresses work, but the group command remains ignorant of PIA channels.

The raw command

pia get|set status|gcr|ddr|data hex_value

lets you get or set the contents of the different PIA registers. You could follow the above plan to set DDR and data registers to control the power.

But a high-level command lets you turn on/off the DC-DC in one go:

pixdcdc on|off portNumber [CCU address for enable] [CCU address for disable]

where portNumber = 0 (J1+J4), 1 (J2+J5), or 2 (J3+J6) to control the DC-DC converter connected to those ports on the CCU board. The current scheme has the PIA lines for CCU at 0x7e hooked up to the enable lines on the DC-DC boards, and the lines for CCU 0x7d hooked up to the powergood lines. If the scheme changes you should be able just to supply the different addresses as the optional arguments to the pixdcdc command.

pixdcdc calls pixDCDCCommand in ServerAccess.cc. It figures out the bits to twiddle based on portNumber. Before doing anything it checks the state of the powergood lines: if power is off but asked to turn off, or on and on, it gives up without doing anything. If things are OK, it tries to turn power on/off, waits 5 ms, then checks that the powergood bits are as they should be. One probably needed change is to use PiaChannelAccess objects so that the removePiaAccess cleanup is done automatically even if exceptions are thrown somewhere, but resetting the whole state of the program by quitting/restarting should work too...

For BmO - portNumber=2 for the module power, portNumber=1 for the for the external loads

For BmI - portNumber=0 is for the external loads

TBM Delay Settings

Delays: Token In (1bit), H/T (1bit), RocPort1 (3bit), RocPort2(3bit)

Module Hubid: 6 - N_BB_906 (Nebreska)

• 201 - 11001001 - no pixel data
• 210 - 11010010 - 4 Rocs w/ pix data for core a, 6 Rocs w/ pix data for core b
• 219 - 11011011 - Pixel data from all Rocs
• 228 - 11100100 - Pixel data from all Rocs
• 237 - 11101101 - Pixel data from all Rocs
• 246 - 11110110 - Pixel data from all Rocs
• 255 - 11111111 - Pixel data from all Rocs
• 0 - 00000000 - Pixel data from all Rocs
• 9 - 00001001 - 6 Rocs w/ pix data for core a, no pix data for core b
• 18 - 00010010 - no pixel data

Module Hubid 7 - M_FL_902 (Purdue)

• 201 - 11001001 - no pixel data
• 210 - 11010010 - 4 Rocs w/ pix data for core a, 8 Rocs w/ pix data for core b
• 219 - 11011011 - Pixel data from all Rocs
• 228 - 11100100 - Pixel data from all Rocs
• 237 - 11101101 - Pixel data from all Rocs
• 246 - 11110110 - Pixel data from all Rocs
• 255 - 11111111 - Pixel data from all Rocs
• 0 - 00000000 - Pixel data from all Rocs
• 9 - 00001001 - 1 Rocs w/ pix data for core a, 5 Rocs w/ pix data for core b
• 18 - 00010010 - no pixel data

Module Hubid 15 - M_LL_906 (Purdue)

• 201 - 11001001 - no pixel data
• 210 - 11010010 - 3 Rocs w/ pix data for core a, 8 Rocs w/ pix data for core b
• 219 - 11011011 - Pixel data from all Rocs
• 228 - 11100100 - Pixel data from all Rocs
• 237 - 11101101 - Pixel data from all Rocs
• 246 - 11110110 - Pixel data from all Rocs
• 255 - 11111111 - Pixel data from all Rocs
• 0 - 00000000 - Pixel data from all Rocs
• 9 - 00001001 - 1 Rocs w/ pix data for core a, 7 Rocs w/ pix data for core b
• 18 - 00010010 - no pixel data

Vana Settings (from FermiLab)

For module (M_FR_902) at 25C vs. 0C:

• Vana at 25C/0C
• ROC0 120 / 115
• ROC1 145 / 144
• ROC2 124 / 122
• ROC3 124 / 120
• ROC4 125 / 123
• ROC5 149 / 146
• ROC6 129 / 125
• ROC7 134 / 139
• ROC8 120 / 114
• ROC9 134 / 139
• ROC10 129 / 127
• ROC11 129 / 125
• ROC12 120 / 114
• ROC13 129 / 130
• ROC14 139 / 141
• ROC15 134 / 135

For module (M_CR_913) w/ ROC version 2.1

• Vana at 25C/0C/-25C
• ROC0 79 / 75 / 75
• ROC1 72 / 68 / 68
• ROC2 75 / 68 / 68
• ROC3 80 / 74 / 74
• ROC4 74 / 65 / 65
• ROC5 80 / 70 / 71
• ROC6 72 / 68 / 68
• ROC7 69 / 65 / 66
• ROC8 79 / 78 / 78
• ROC9 67 / 64 / 64
• ROC10 65 / 64 / 64
• ROC11 73 / 78 / 78

HV Connection at TIF

HV power supply is hooked up at TIF setup. Voltage: -120V, Current: ~0.1uA. In order turn off HV, one MUST get the voltage to 0V and then press 'operate'. Otherwise spike may damage the module. THIS IS REALLY IMPORTANT!! HV_supply.jpg, PortCard.jpg, CableConnection.jpg, ConnectionOnPC.jpg

PixFED register poking with python

On a machine with the Cactus/IPbus software installed (for Pilot, this could be vmepc-s2b18-08-01), first set up environment variables:

export LD_LIBRARY_PATH=/opt/cactus/lib:$LD_LIBRARY_PATH

export PATH=/opt/cactus/bin:$PATH

Example python script to reset the Slink Sender Core (needs to be done once after powerup)

import uhal
uhal.setLogLevelTo( uhal.LogLevel.WARNING)
manager = uhal.ConnectionManager("file://FEDconnection.xml")
fed = manager.getDevice("FED")
device_id = fed.id()

fed.getNode("pixfed_ctrl_regs.slink_core_gtx_reset").write(1)
fed.dispatch()
fed.getNode("pixfed_ctrl_regs.slink_core_gtx_reset").write(0)
fed.dispatch()

fed.getNode("pixfed_ctrl_regs.slink_core_sys_reset").write(1)
fed.dispatch()
fed.getNode("pixfed_ctrl_regs.slink_core_sys_reset").write(0)
fed.dispatch()

Another example to read some status registers is also attached