I.Tomalin, M. Pearson

Last Update: 27/07/04

FED Requirements still to be implemented (Summer 2004).

This a summary of required/desired features that are not yet implemented in the FED. For further details, refer to items flagged by the text "Missing Feature" in the summer.

Required

  1. Ability to read any FED register which can be written to. -- Currently not true for clock-skews or Trim-DAQ.

  2. FED firmware version for all FPGAs -- Currently missing for delay FPGA.

  3. VME access to which FED channels have APVs with pipeline addr. out of sync, error bit set or missing (out-of-time) frames. At the very least, the total number of bad APVs per FED must be available.

  4. Data format:
            a) In raw data mode, the ADC value should be stored as a 10 bit number and not padded out to 16 bits.
            b) In zero-suppressed mode, the common-mode offset should not be output with the data. This could be accomplished by adding an additional FED mode (a 'zero_suppresion_no_cm' mode).
            c) The "packet code" should not be present in the channel data, since the FED mode is specified in the event header and all channels must be operating in the same mode.
            d) Replace the 2-byte packet length by a 1-byte number of clusters.

  5. Error-handling:
            a) If a FED data buffer overflows, it must continue to output empty events, so as to preserve synchronisation. The event header should indicate that the data was lost. The FED should provide VME access to the number of buffers in error.
            b) If the FED trigger buffer overflows, this problem must be signalled either via VME or via TTS OUT_OF_SYNC.
            c) If the external clock is lost, since the FED reverts back to the internal clock and executes a hard reset. It should stop transmitting data and signal the problem by setting a register or via TTS OUT_OF_SYNC.

  6. RESYNC protocol (known as RESET in the FED URD)- currently not followed:
            a) When the FED receives a TTC-B resync command it will assert BUSY on TTS. It should then wait about 21ms to receive any more data from the APVs.
            b) The FED will then clear its buffers, error flags and counters (except bunch counter, event counter and APV frame counter).
            c) De-assert BUSY

  1. Approximately 10 -- 30 MB/s available via VME. (Possibly using the 64 data lines of VME64x ?).

  2. Set error bit in a register, or in the data buffer, if the emulated APV pipeline address (sent via TTC) disagrees with observed one.

  3. Upon receipt of a TEST_ENABLE on TTC channel B the FED should flag the next event as a calibration event, by setting a bit in the data buffer header.

  4. A VME readable error bit should be set if the number of bunch crossings seen between successive TTC BCR signals is not equal to the number of bunches in an LHC orbit.

  5. A flag for each APV indicating if its inverter is enabled. -- Currently, there is only a flag for each pair of APVs.

Desirable

  1. Ability to take laser alignment / calibration data during physics, preferably by switching the FED to raw data mode during a private orbit, taking a global calibration trigger during the subsequent orbit gap (indicated by TEST_ENABLE on the TTC line) and then asserting BUSY until the FED has changed back to normal data taking mode. This requires negotiation with the DAQ group as well as firmware changes, to ensure that this sequence is possible. NOTE: most probably not required.

  2. Ability to synchronise capture of Spy Channel data to the arrival of an APV frame, so that at low trigger rates one doesn't capture lots of empty data.

  3. A "Multi-Mode" data-taking mode, appropriate for taking data when the APV is in multi-mode operation (i.e., gives 3 consecutive frames per trigger).

  4. The option of reducing the gain by a factor of 2 on any specified FED input channel, when in zero-suppressed mode, by dropping the MSB and LSB instead of the two LSBs from the original 10 bits of raw data.

  5. VME access to buffer occupancies, especially of FE and Trigger FPGAs. Perhaps store maximum occupancy during last N bunch-crossings. Also store the number of events lost due to data buffer overflow.

  6. FED fills monitoring histograms of occupancy vs. #BX, common-mode level, buffer occupancies etc, to get higher statistic monitoring than if the histograms were filled in the crate-controller.

  7. When taking zero-suppressed data, a bit in the data-stream for each APV indicating that its common-mode offset was abnormally large. i.e. The APV will be inefficient due to the HIP effect.

  8. The percentage buffer occupancy above which a THROTTLE signal is generated should be VME programmable.

  9. Inbuilt test features:
            a) Verify that zero-suppression algorithm performs correctly event-by-event, by comparison of zero-suppressed data with raw data read over spy channel. -- Requires a way to know which event the spy channel data corresponds to.

  10. The front-panel LEDs should be multi-coloured. They should show (in addition to curently implemented things) (i) FPGAs loaded OK (ii) trigger received (iii) some APVs are in error (iv) FED buffers filling/full (vi) clock error occurred since last reset. Stick on labels to indicate the meaning of the LEDs would be nice.