RU configuration over GBT

We currently configure the RU over the USB interface. This is done using a suite of Python scripts ("testbench.py") that interface via PyUSB to the Cypress FX3 chip on the RU, which controls the Wishbone bus inside the RU firmware.

The RU firmware supports configuration over the GBT optical link: special "single word transaction" transfers are interpreted as Wishbone commands. If FELIX could send and receive SWTs, we could configure the RU from the FELIX server with minimal changes to the Python control software.

• Understand the SWT protocol - talk to RU experts, read the VHDL code.
• Add some glue logic (a FIFO in each direction, per RU) to the FELIX firmware to interface between the register map and the GBT interface.
• Implement a "communication server" interface in software that accepts Wishbone commands from the Python software and does the appropriate register map writes and reads.
• Modify the testbench script to use the new communications server to control the RU.

Required skills

VHDL for firmware, Python for software; communication server might be easier in C/C++

Full-time effort

Two weeks to a month to get up to speed, a month to do the work.

Power board interface

We currently power the ALPIDE sensors using benchtop power supplies. The final system will use the ALICE Power Board: an array of voltage regulators that is controlled by the RU.

The current RU firmware and software already support control of the Power Board.

CERN uses a different remotely controlled power supply than we do - they use Hameg, we use HP. The Hameg control is built into the Python software used for RU configuration; we have separate Python scripts for the HP supplies.

• Connect the Power Board to the RU with a ribbon cable. Understand the power-up sequence for the Power Board and demonstrate control using the Python software.
• Connect the Power Board to ALPIDE sensors, need to solder some wires. Apply the correct power-up sequence for the ALPIDE.
• Additional goals: GUI? Integrate control of the HP power supplies with the RU software?

Required skills

Python. Basic soldering experience.

Full-time effort

One week to get up to speed and get the power board working. Additional goals may take more time.

Timing system interface

We currently clock FELIX through test points connected to the Si5345 clock manager IC, and trigger FELIX through a test point connected to FPGA input.

For sPHENIX, FELIX will receive an optical link from the sPHENIX timing system: a single fiber for clock, timing, and trigger. This fiber goes to an SFP module on a "timing mezzanine" card on FELIX. The sPHENIX timing system is still being developed but it is likely that the protocol will be essentially identical to PHENIX.

• Talk to the BNL experts who are designing the timing system and integrating it with the FELIX readout for the TPC, understand how much we can piggyback on their work.
• Set up a copy of the BNL timing system prototype (if available), design a minimal mockup, or set up the old PHENIX timing system.
• Recover a clock from the SFP input, align and decode the data.
• Interpret the trigger from the timing system and use it to trigger the MVTX readout chain.

Required skills

VHDL, specific experience with the Xilinx gigabit transceivers.

Full-time effort

Depends a lot on what BNL has already done for us. One to three months?

FELIX v2.0

We have been using FELIX v1.5, we now have FELIX v2.0. The final system will use FELIX v2.0; UT-Austin system has FELIX v2.0. In principle the changes between v1.5 and v2.0 are minimal: banks have been remapped, some I2C device addresses have changed.

The FELIX firmware we are using is based on the ATLAS firmware from early 2017. It may be prudent to update to current ATLAS firmware (which is supposed to fully support both v1.5 and v2.0) instead of trying to patch our current firmware to work on v2.0.

• Copy the MVTX-specific logic into the current ATLAS firmware, validate on one version of FELIX.
• Resynthesize and validate on the other version of FELIX.

Required skills

VHDL, Vivado.

Full-time effort

One month.

GBT-SCA

The GBT-SCA ASIC on the RU provides a slow controls interface (GPIO, I2C, JTAG, ADC/DAC) directly controlled over the GBT optical link. This is important for monitoring (voltage, temperature), communication to the ProASIC3 FPGA, and remote reprogramming of the ProASIC3 FPGA.

The current FELIX firmware contains an interface from the FELIX register map to the HDLC channel that communicates to the GBT-SCA. There is also a GBT-SC core developed by CERN that provides a full-featured interface to the GBT-SCA.

Required skills

Full-time effort

blah

stress tests/error logging

blah

Required skills

Full-time effort

blah

continuous mode readout

blah

Required skills

blah

Full-time effort

blah

RU configuration from flash/scrubbing

blah

Required skills

blah

Full-time effort

blah

TIming studies

blah

Required skills

blah

Full-time effort

blah

CANbus

blah

Required skills

blah

Full-time effort

blah