Preliminary Notes 5-MAR-1997 System Control of High Speed Readout (and temporary notes on Monitoring Data) Points of view to consider Initialization Monitor / Diagnostics Error detection Special test mode Initialization Controlled loading of Board Support FPGA and Main Array FPGA What happens *while* the FPGA configurations are loaded? Need to be able to disable the HSRO function (and interrupts if any) Need to be able to Reset/Start the HSRO function Can we reset the VRBs: Yes, via the Geographic Section Serial Link Monitor / Diagnostics Monitoring current/static state of transfer interrogate BS-FPGA for current transfer count (a few bits enough) interrogate BS-FPGA for current state of FINISAR interrogate MA-FPGAs in the chain to see who's currently reading out interrogate MA-FPGAs on number of pieces of information they read out Monitoring dynamic performance of readout (see flaky links that lose synch) average transfer time resettable counter of transfer count (for 5 s @ 10kHz = 16 bits) resettable counter of integrated transfer time for averaging Error detection Detect/investigate/locate a problem when the readout is stuck or when pieces are missing and alert the TCC/TRGMGR/Alarm/TRGMON, or simply have the information available Each card BS-FPGA can detect when the low speed link command receiver loses frame synchronization Each card BS-FPGA can detect unexpected HSRO requests and wake up TCC when there was no previous L1 Accept when the circuitry was disabled by TCC when an unexpected command type arrives over the slow link. Each card BS-FPGA can detect unexpected L1 Accept and wake up TCC when a new L1 Accept comes before finishing the readout of the previous Accept. Each Card BS-FPGA can detect incomplete transfer, where the number of words sent is incorrect at the time the daisy chain enable signal comes back when the transfer is hung (timeout counter) Each Card BS-FPGA will field the request on the slow command link for resynchronization of the High Speed Link. This should only happen once during power-up/setup/initialization Any request during the run is a sign of flaky VRB/cable/connectors... and should be dtected and flagged. Special test mode Disable readout totally disable one card (i.e. no data/flags sent to finisar) make card send "minimal" block (zero or BS header with protocol flags) individually skip/shunt MA-FPGA in the chain individually skip entries within one FPGA MSU commissioning/test/exercizing of HSRO circuitry trigger HSRO without low speed link command readout BS-FPGA without Finisar/VRB hardware readout BS-FPGA+MA-FPGA without Finisar/VRB resynch finisar without low speed link DZero commissioning/test of the HSRO circuitry trigger HSRO (with error detection) but send nothing to Finisar During "othe"r Exercizer/Diagnostics Tests of the framework prevent test from perturbing the link Panic when HSRO request comes during tests =============================================================================== Which Beam Crossing to capture for Monitor Data Capture a copy of (i.e. spy on) all data for the next L1 trigger accept. This includes all data included in the HSRO and a lot more. We need some circuitry that can be armed and then ready to capture "the information" at the next L1 Accept. It is preferable that this circuitry be centralized so that TCC only talks to one place and not all the cards. TCC also needs to have the ability to force a capture when no L1 Accept are naturally occurring. This circuitry needs to be protected from an L1 Accept signal that may be happening while it is being armed. It must either be syncrhonized with the gaps in the accelerator bunches, or TCC must "micro-pause" the run while enabling the circuitry. Optimally: capture the data corresponding exactly to the same Beam Crossing as the one that generated the L1 Accept Minimally: Fixed skew of Beam Crossing from the one that caused the L1 Accept. This skew will/might not be constant for all pieces of information in the system. Luckily, the skew will be towards more recent Beam Crossings; this implies that scaled quantities will be guaranteed to include the result of the Beam crossing that caused the L1 Accept. Some quantities might still need to be treated as special cases and circuitry be added to capture the right crossing. For example, it is desirable that the state of the Front-End Busy signals match the crossing that caused the L1 Accept. This type of signal is already naturally located towards the end of the Pipeline and close to be contemporary to the desired crossing. Monitor data captured TRM: And-or Term scalers AONM: TDM: And-or Fired scalers individual disable source scalers? FOM: L1 Accept scalers Note: all monitor stuff is to be from same BX. This means that even monitor-only data needs to have the BX history fifo. Recall that this fifo is one stage deeper on TRM+AONM than on TDM+FOM. Depth NOT programmable but fixed. implication: can NOT see "current" BX data. If we decide we need current data IN ADDITION to this, need additional monitor-only storage registers. ================================================================================