* Initialization (power-up, run) * Error reporting

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. 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 Slinks or cables Final Fit-HW AMBoard AM AMBoard Clustering in parallel – 48 DF: cross-point for clusters - DOs 4 DOs 4 DOs 4 TFs 4 TFs 4 HWs 4 HWs 4 TFs 4 HWs ROS ROS 32 boards FLIC 224 Rols 128 PUs = 512 pipelines Final Fit-HW 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 → 8 + 8 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 AMBoard DF Final Fit-HW 4 DOs ROS FLIC 4 TFs 4 HWs 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 wordof 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: • 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_IM FTK_IM • 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 functionthenstudyinterboard test FTK_IM FTK_IM AMB AUX card LAMB

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