*************************************** * * * Data Block Data Capture and Readout * * * * and * * * * Monitor Data Capture and Readout * * * * in the * * * * Run II Trigger Frameworks * * * *************************************** Original: 21-FEB-1997 Revised: 13-MAR-1997 Introduction ------------ The purpose of this file is to describe in detail the capture and readout of both Data Block Data and Monitor Data in the Run II Level 1 and Level 2 Trigger Frameworks. Although the capture and readout of these two types of data are logically separate, they are interrelated and thus are both described in this file. This file specifically does NOT describe what data is included in each class, nor are any data formats, addressing, etc. described. This file typically uses the Level 1 Trigger Framework in examples, but the information applies equally to the Level 2 Trigger Framework. Data Descriptions ----------------- 1. Data Block Data Data Block Data is the data which is captured for inclusion in the D0 Event Data Block. It is captured in response to each Level 1 Accept message received on the Serial Command Link (via the VRB card), and is read out via the VRB-VRBC-VBD card chain. The first stage of this readout, from THE Card to the VRB, occurs in a "push" fashion over the HP Glink fiberoptic cable, and is fast, taking approximately 8 us. It is controlled by the BSF FPGA on THE Card. All Data Block Data in the Frameworks is captured simultaneously, and each element remains in a Holding Register until the readout is complete. There is only a single Holding Register per data element, therefore no new L1 Accept messages are allowed during the readout. Note that the Level 1 Accept message for Beam Crossing lags the actual processing of the data for Beam Crossing by several Beam Crossings. Every element of Data Block Data must be held during this lag period in a Beam Crossing History Shift Register. This is true not only for the Frameworks, but in fact all Front Ends must have this Beam Crossing History Shift Register. 2. Monitor Data Monitor Data is the data which is captured for Monitoring and Run Database building purposes. It is captured upon a request from the TCC. TCC must specifically request the capture of this data in one of two ways: "capture immediately" or "capture at next L1 Accept." TCC reads this data out via VME. This readout is slow, taking on the order of milliseconds. As with the Data Block Data, all Monitor Data is captured simultaneously, and each element remains in a Holding Register (separate from the Data Block Data Holding Register) until the readout is complete. Again there is only a single Holding Register per data element, therefore TCC should not request the capture of new Monitor Data until it has completed reading out the "old" Monitor Data. Every Data Block Data element is also a Monitor Data element. These Monitor Data "copies" of Data Block Data must flow through the Beam Crossing History Shift Register. There are additionally many Monitor Data elements which are *not* copies of Data Block Data elements. These "Monitor Only" data elements *also* flow through identical Beam Crossing History Shift Registers. This is necessary to ensure that the "Monitor Only" data elements are captured from the same Beam Crossing as the Monitor Data copies of Data Block Data elements, simplifying calculations which may use both types of Monitor Data. Detailed Protocol ----------------- 1. Data Block Data On THE Card, a special-purpose data/control bus, called the High Speed Readout Bus, is used to support the Data Block Readout. This bus includes the following signals: Capture HSRO Data*: a dedicated signal, enables the loading of all Data Block Holding Registers when low. Signal will be high for a full 132 ns tick. BX Clock: a High Quality Timing Signal, used to clock the Beam Crossing History Shift Register and also the HSRO Control logic on each MSA FPGA. This is a once/132 ns clock, and may also be used by the triggering logic on THE Card. HSRO Data(15:0): 16 bits of data, driven via tri-state drivers by the BSF FPGA and the 16 MSA FPGA's, received (via TTL-ECL convertors) by the Finisar module. HSRO Data(19:16): 4 bits of "outband" data, driven by the BSF FPGA, received (via TTL-ECL convertors) by the Finisar module. HSRO Data Valid: 1 "strobe" signal, driven via tri-state drivers by the 16 MSA FPGA's, received by the BSF FPGA Daisy Chain Enable*: a daisy-chain signal, launched by the BSF FPGA, passing through each of the 16 MSA FPGA's, and returning to the BSF FPGA Frame Clock: 53.104 MHz accelerator clock, received directly from P1 Backplane Timing Signals (not via BSF FPGA), received (via TTL-ECL convertors, and AC-coupled) by the Finisar module Converter Latch: driven by the BSF FPGA to the HSRO Data and HSRO Flag TTL-ECL convertors, which can either latch the HSRO Data/Flag information or allow these convertors to operate in transparent mode DAV*: driven by the BSF FPGA to the Finisar module (via TTL-ECL convertors) to indicate that the data on the HSRO Data bus is currently valid and should be transferred as DATA CAV*: driven by the BSF FPGA to the Finisar module (via TTL-ECL convertors) to indicate that the data on the HSRO Data bus is currently valid and should be transferred as CONTROL Within a single THE Card FPGA (either Main Signal Array or Board Support Functions), all Data Block Data is clocked (by the BX Clock) into its Beam Crossing History Shift Register. Note that if this card has MSA Input Latches, the BX Clock can also clock these latches (on the same edge). In this fashion, as the data for BX "n" is latched at the MSA Input Latches, the data for BX "n-1" is clocked into the BXHSR. This gives maximum setup time for the data being latched into the BXHSR. There is no data hold time requirement for Xilinx CLB flip-flops. This Shift Register has a maximum of 32 stages (matching the maximum L1 Accept latency). One stage of this Shift Register is "tapped" and feeds the Data Block Data Holding Register (and also the Monitor Data Holding Register). Which specific stage is tapped depends on the latency of the L1 Accept signal, but does not vary from event to event. Note that the L1 Trigger Framework is internally pipelined, and the two pipeline stages use different taps. Each Beam Crossing results in either an explicit L1 Accept message or an implicit L1 Reject message being transported from the L1 Trigger Framework to all Front Ends via the Serial Command Link. The Trigger Frameworks, for readout purposes, are themselves Front Ends and thus receive Serial Command Links. The L1 Framework's SCL terminates at a VRBC. If the VRBC receives an L1 Accept message, it passes that message to multiple VRB's, which then each pass the message to multiple THE Cards via Low Speed Command Links. On THE Card, the Low Speed Command Link is received by the BSF FPGA. L1 Reject messages are not passed from the VRBC to the VRB. Upon receipt of a L1 Accept message, the BSF FPGA activates the Capture HSRO Data* signal on THE Card. The phase of this signal must be controlled with respect to the BX Clock: the Capture signal must become active (low) prior to the rising edge of the BX Clock, and must not be active for more than one 132 ns tick. The BSF FPGA first presents its Data Block Data (which may be one or more 16-bit words) to the Finisar module. It asserts DAV* for a single 18.8 ns frame for each 16-bit word. The phase of DAV* must be controlled with respect to the 53.104 MHz Frame Clock: DAV* must become active (low) prior to the rising edge of the Frame Clock, and must not be active for longer than 18.8 ns. The BSF FPGA then launches Daisy Chain Enable to the first MSA FPGA. With each rising edge of BX Clock, the first MSA FPGA provides a 16-bit word to the Finisar module on HSRO Data, and with each falling edge of BX Clock asserts HSRO Data Valid* to the BSF FPGA. The BSF FPGA uses HSRO Data Valid*, along with the 53.104 MHz Frame Clock, to assert DAV* for a single 18.8 ns frame as before. When the first MSA FPGA is providing its the Data Valid* signal for its final 16 bit-word, it also passes the Daisy Chain Enable* signal to the next FPGA in the HSRO chain, which (on the next BX Clock rising edge) begins presenting its Data Block Data to the Finisar module. Note that only one FPGA at a time is allowed to drive the HSRO Data and Data Valid* signals. When the last MSA FPGA has provided its final 16-bit word, it returns the Daisy Chain Enable to the BSF FPGA, which then sends a final word to the Finisar module to indicate the end of the data for this L1 Accept. There are several ways this indication could be done, either using one of the HSRO high-order Data bits, or by asserting CAV* rather than DAV*. A final decision on this issue will be postponed until more information is available. Once the BSF FPGA has indicated the end of event data to the Finisar module, it deasserts the Daisy Chain Enable to the first MSA FPGA. The first MSA FPGA then deasserts its Daisy Chain Enable to the next MSA FPGA, etc, until the deassertion of Daisy Chain Enable is returned to the BSF FPGA. The HSRO Control logic on each FPGA has a Control/Status Register, visible via VME, which is used to control and monitor the HSRO Data Readout. The detailed functions of this register are not yet specified. 2. Monitor Data As with the Data Block Data, every data element is clocked into a Beam Crossing History Shift Register during every 132 ns tick. The BSF FPGA receives two P1 Timing Signals, which are under the control of TCC at some level, but still convey precision timing information: Capture Monitor Data Immediately: this signal will be active for a single 132 ns tick to indicate that Monitor Data should be captured during that tick. Arm Monitor Data Capture for next L1 Accept: this signal will be asserted to indicate that Monitor Data should be captured upon the next L1 Accept. It will remain asserted at least until the next L1 Accept, but will be deasserted before any subsequent L1 Accepts (i.e. within 8 us of the L1 Accept) The BSF FPGA uses these two signals, in conjunction with the L1 Accept command from the VRB, to generate the Capture Monitor Data* signal, which is a dedicated signal passed to all MSA FPGAs in parallel. It is used to enable clocking of the Monitor Data Holding Register, in a fashion analogous to the Capture HSRO Data* signal. The Monitor Data Holding Registers are visible via VME. TCC reads these registers via normal VME reads. Note that these registers will be overwritten upon the capture of new Monitor Data, it is TCC's responsibility to ensure that new Monitor Data is not requested until it has read all of the Monitor Data Holding Registers (or chosen to give up reading these registers).