User Tools

Site Tools


febv2_fw_req

FEBV2 Firmware structure and requirements

One main idea is to keep the possibility to replace the Master FPGA with an LpGBT chip on the final design So we need to use:

  • elink data transmission
  • I2C configuration

A bonus will be to have a first version of the SEU mitigation but it's not compulsory at this stage.

Master FPGA needs

It is responsible of all communication, synchronisation and data formatting

GBT communication

Protocol

The underlying protocol is provided by the CERN IP

Messages

Backend to Frontend

The message structure is the following:

  • 84 bits
  • 82-83 : reserved
  • 81-80: EC (unused)
  • 0-79: 5 last payload long words (16 bits)
  • Extra data:
    • 0-8: register address
    • 9-11: nword
    • 12-15: unused
    • 16-31: first payload long word
Frontend to Backend

The message structure is the following:

  • 84 bits
  • 82-83 : reserved
  • 81-80: EC (unused)
    • 0 never happens
    • 1 register response
    • 2 data
    • 3 never happens
  • 0-79: 5 last payload long words (16 bits)
  • Extra data:
    • If register response:
      • 0-8: register address
      • 9-11: nword
      • 12-15: unused
      • 16-31: first payload long word
    • if data:
      • 2 first payload words

GBT synchronisation

No documentation found on GBT-FPGA, expected special data with 32 bits encoded (see CIC doc)

The GBT firmware should handle BC0 and RESYNC commands:

  • BC0 generate pulse (channel 0) and all TDC FPGA
  • RESYNC resets counters on all TDCFPGA

EPort TDC reception

  • Data collection from the 3 EPort links
  • Potentially:
    • T0 subtraction
    • Y measurement
    • Cluster reconstruction
  • Data packaging and transfer to GBT

I2C slow control to TDC

  • 3 I2C buses with mechanism to write and read remote registers
  • GBT interface:
    • decode incoming GBT frames to write I2C transfer
    • encode I2C response to GBT frame

It should be simple but the GBT interface is not trivial.

Backup readout

DCC synchronisation

We need to implement the block getting the BC0 from the start of the window and propagating back a BUSY. One line is also dedicated for RESYNC (no firmware)

There is also a TRIGGER line that should be connected to one TDC channel, but no firmware is needed

Wiznet (Ethernet) communication

It's being implemented currently but not yet tested, 3 separated sockets mechanism

  • 10001 Slow control PETIROC
  • 10002 Slow control TDC (calibration,masking,reset)
  • 10003 Data

Each socket should have a block to decode incoming data to register and a block to encode outgoing buffer (packet structure)

FTDI (USB2) readout

Additional debug port , firmware can be inherited from SDHCAL (ILC) DIF boards. It's a low priority

TDC FPGA firmware

EPort TDC transmission

Data collection from all TDCs is done via a switch IP , a first version is being implemented on FEBV1.

The EPort IP should be part of the GBT-FPGA firmware from CERN and should be interfaced to the the switch.

BUSY is generated by an OR of all TDC channel (almost Full FIFO) and should be propagated to Master FPGA

I2C slow control communication

Pending block to the master FPGA one:

  • Read/write local registers
  • Triggers action already implemented on FEBV1 :
    • PETIROC Slow control
    • TDC calibration
    • LUT readout

TDC blocks

Two parts:

  • Single channel TDCs including TDL, encoder, LUT, output FIFO, interface to slow control
  • Switch IP to collect all channels data from Output FIFO + generation of BUSY

Ongoing work on those blocks for a new version of FEBV1

PETIROC FSM

Standalone block that mitigate the RESET of the latch on PETIROC. Copy from FEBV1 firmware

febv2_fw_req.txt · Last modified: 2021/07/10 23:21 (external edit)