====== 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