1. * Initialization (power-up, run)
    * Error reporting
    * Spy buffer implementation - depth, format, freezing, reading
Other details for VME/ATCA registers
Software items in Alberto talk
    * Version control and repository for firmware and online software
* Monitoring

2. * Initialization (power-up, run)
Test Mode/Run Mode: during Tmode (a) memories, input Fifos R/W and Spy buffers write function available to VME/ATCA (b) FSMs are halted to ini state (c) exit with INIT
INIT_event & Reset: INIT_event should empty everything that is event-specific: the pipeline registers, reset FSMs, reset errors in EE Word, exit TMODE; Should not touch memories content, Input Fifos, VME Error registers, Spy buffers ….. Experience during running under test will adjust the INIT procedures. They should be two INIT procedures: Reset and INIT_event. Reset should be used to reset also things that INIT_event do not touch (Input Fifos..). Both produced by VME/ATCA. IMPORTANT: provide both the Reset and INIT_ev signals to all FPGAs on your board.
At power on: like Reset all pipeline registers, all FIFOs, all Spy Buffer pointers and overflow flags….. Optional

3. Errors
Each classified error should have one bit reserved in the EE word and in a VME Error register (Read Only register, with clear from VME write)
Parity or CRC error – for each link between boards Parity (PA) should be calculated at the link starting point and checked at the end point (automatic in serial links?). Parity Error detection should be registered
FIFO Overflow – each FIFO full flag should produce error if set.
Internal Overflow (for example overflow in a HLM in a DO)
Invalid Input data (for example invalid HIT from ROD)
Lost Synchronism (event tags in different streams do not match)
Truncated output (for example too many roads in output)
…….
What else?

4. Spy Buffers: what They are?
INPUT FIFOs
as derandomizers
Spy Buffers: what
They are?
Hold
Pointer: incremented each time a word is popped from FIFO or sent to output.
When it overflows it wraps around and an ‘overflow flag’ is set → circular memory
TWO MODES: SPY or FREEZE
Hold
Hold
To be read
by VME
Copying data
during run

5. Spy Buffers: where they are? @each designer boundary
Board-board
Connector
4 DOs
AMBoard
4 TFs
4 HWs
Slinks or cables
Final Fit-HW
Clustering in parallel –
48 DF: cross-point for clusters -
ROS
DOs AM
4 TFs
4 HWs 32
boards
FLIC
224 Rols
128 PUs = 512 pipelines
ROS
Final Fit-HW
4 DOs
AMBoard
4 TFs
4 HWs PU

6. Spy Buffers: when and how they are frozen?
TWO different cases:
One bit in the EE word received on input stream means ‘freeze immediately after you have finished to process the current event’. The event to be monitored will be chosen by DF that will set the EE bit into all FTK streams
One severe error happened: Freeze is sent immediately to the previous board together with the event tag meaning ‘As soon as the event is processed, set the freeze’. The Freeze can be set in the outgoing EE word for the following boards (is it really necessary?).

7. Spy Buffers & FIFOs: how much deep? Format?
Deep: 8 streams → Fifos + 8 spy buffers = 24 mem-blocks. In the chip we have 172 blocks of 1000 locations → equally distributed?
~6000 locations/object (6 <events>)
Format: each function block has its optimized data format of input and output? Ex. AMBFTK has different words size for hits (15 bits) & roads (32 bits). Is it an exception? What about DO and TF? Time info should be stored at each clock? 32 bit for timing?
AMBFTK input chip A. Stabile

8. Processing Time measurements
L1 accept time
4 DOs
AMBoard
4 TFs
4 HWs DF
Final Fit-HW
FLIC
ROS
Each engine starts a counter at L1 accept time and when a word of the right event is written in the Spy buffer uses the right counter and writes the time ? (in each engine we need as many counters as many events are in the whole pipeline. How many?) OR
The first engine starts a counter from L1 Accept, than with the first word sent to the second engine it starts the counter of the second engine and sends to it its counts up to that moment to be added ?

9. Other kind of measurements (simpler)
First event word of an event starts a counter when it is extracted from FIFO, last EE word of the same event stops the counter → event processing time inside the engine.
Measure time a FIFO is empty: empy_flag starts and stops a counter
Measure time a FIFO gives Hold: HF_flag starts and stops a counter
Inside FPGA measurements can be added in the future if space is available.

10. HW diagnostics Each board: Debugging features Cable/fiber diagnostic
Must have a VME/ATCA program that fully tests the board
Ideally the test should tell where the problem is
E.g. minimize hardware debugging as mush as possible
Internal self test would be nice (optional)
Debugging features
Spy buffers for each IO connection
Possibility to load data in input spy buffers (or FIFOs?) to stimulate the board
Possibility to load data in the output spy buffers to send data to downstream board
Cable/fiber diagnostic
Use input/output spy to test each cable

11. Hierarchical HW diagnostic
DF & FTK_IMs test f.
FTK_IM test function
DF test function
PU test function
AMB test f.
AUX card test f.
DF to PU test f.
PU to final board test f.
DF to PU to final test f.
DF to … to FLIC test f.
Interboard test not trivial  run control based (?)
First prepare modular function then study inter board test DF
FTK_IM
AMB
LAMB
AUX
card

12. Standard VME/ATCA registers/memories
Space standardization? Common Firmware?
Error register – WR = clear
For each FIFO: flag register (empty, HFull, Full) - RO
For each FSM: state machine - RO
Output Status (Hold flags) – RO
Output register (or output spy buffer): a VME wr will send data on a link
For each Spy Buffer: Spy Buffer register: Pointer, OVFL flag, status(freeze/spy. WR=clear of Pointer & flag. Status is RO
Severity error register: for each error bit 1 (or 2) bit is dedicated to enable an ‘action’ in case of error. Will activate the stop-less removal and/or freeze signal.
Board ID or chip firmware ID? (ex PROM-ID-see next slide)
Input FiFos: R/W
All associated memories R/W
Registers for Timing measurements

13. Version control (Annovi proposal)
Each board should have these registers:
FW Version register: major 31:16 & minor 15:0
Major version will change when software changes as well
Minor version change are internal changes
PCB version register: to keep track of prototypes
Ideally this number is hardcoded to one FPGA (e.g. use 3 pins connected to VCC and GND in the PCB)
Board serial number (we will need this)
Suggestion: use a small flash to write & store it during board test
Also write it on the PCB to be read without power
Ideally all FPGAs (or at least those with VME/ATCA access)
Should have a FW version register + FW date register

14. Version control and repository for firmware and online software
Downloading of MC or real events in each board
Input FIFOs downloaded by VME- random generation
In particular starting from the DF
Monitoring (which standard plots? Timing and #roads, #hits…?)
Version control and repository for firmware and online software
See Alberto Slides