Description of the ADF-2 Data Path Fpga Created : 14-May-2004 Working Draft Revision: 28-May-2004 This is the functional description of the ADF-2 Data Path FPGA Firmware. The ADF-2 circuit board where this FPGA is located is described in the file adf_2_circuit_board_description.txt found in http://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/adf_2/general/ The target device for this firmware is part of the Virtex-II family of Xilinx FPGA, and specifically the XC2V1000-4FG456C wire-bond fine-pitch (1.00 mm pitch) Ball Grid Array package. This FPGA has 1 million system gates, 5,120 "Slices", 40 "SelectRAM blocks", and this package has 324 I/O pins including 16 clock input pins. The name "Data Path FPGA" was chosen to emphasize its function within the operation of the ADF system. This FPGA firmware processes the 10-bit raw ADC Energies (output from the analog section of the ADF-2 Card), and produces the Trigger Tower Transverse Energies (input to the Channel Link transmitter section of the ADF-2 Card). Each Data Path FPGA is responsible for 8 Trigger Tower EM and HD signal pairs, thus each Data Path FPGA handles 16 10-bit ADC inputs. Each ADF-2 circuit board holds two Data Path FPGAs, nicknamed F0 and F1, while their official reference designators are U801 and U901, repectively. Two Data Path Fpga Sites; One firmware content ============================================== Both FPGAs F0 and F1 perform exaclty the same functions on their respective Trigger Tower inputs and outputs. FPGA F0 has been designated to generate the additional card wide, non channel-specific information that needs to be sent to the TABs via the Channel Link Transmitter section of the ADF-2 Card. FPGA F0 provides the Begin of Frame bit to identify the beginning of the data for a give Crossing, as well as the Beam Crossing Tick Number and the global parity bit. FPGA F0 and F1 are independent of each other, and do not communicate directly with each other, with only one exception. FPGA F1 needs to send information about the local parity of its Trigger Tower Et output data which it is sending directly to the Channel Link transmitter chips. FPGA F0 will use this local information from F1 along with its own local information to generate the card-wide parity information as part of the Channel Link data payload. The Channel Link Output is described in more details in a dedicated section below. These and any discrepencies between F0 and F1 will remain transparent to the FPGA firmware, so that the same firmware is loaded in both FPGAs F0 and F1. Some output pins may be unused and unconnected, while some input pins may be unused and grounded on the circuit board. FPGA Configuration ================== FPGA Configuration is the process of loading firmware into the FPGAs. The Data Path FPGAs are configured by TCC over VME. Registers in the ADF-2 Board Control PAL allows TCC to acomplish the firmware configuration. This process is (will be) described in full details [elsewhere...] List of I/O Pins and Net Names ============================== The list of Net names and the pin allocation is available in a separate file. cf. data_path_fpga_pin_list.txt http://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/adf_2/net_lists/ Clock Input =========== The Data Path FPGA uses a single input clock generated on the ADF-2 circuit board from the SCLD Beam Crossing Clock received from the VME backplane by all ADF-2 cards and driven by the Maestro ADF-2 of the ADF crate. This single input clock to the Data Path FPGA is at 8 times the Beam Crossing Frequency. This corresponds to 60.7 MHz or a period of 16.5 ns and is called BX_X8_CLK (whith net name BX_X8_CLK_F0 on FPGA #0). BX_X8_CLK is received on a clock input pin, distributed inside the FPGA by Global Clock Buffers on Global Clock Network resources of the Virtex-II. The only other essential timing information needed as input to the Data Path FPGA is a mean to identify which of every 8th edge of the BX_X8_CLK clock corresponds to the beginning of a new Beam Crossing time slice, called Beam Crossing frame. This information is provided by the FIRST_X8_EDGE input signal (with net name FIRST_X8_EDGE_F0 on FPGA#0) which is also generated on the ADF-2 circuit board . FIRST_X8_EDGE then becomes an enable signal to be used in synchronous logic clocked by BX_X8_CLK. We will call the 8 periods of the BX_X8_CLK "Sub-Ticks" of the 132 ns Beam Crossing periods which are already called 132ns Ticks. We number each of the 8 Sub-Ticks of BX_X8_CLK from 0 to 7. The operation of the Data Path FPGA will be pipelined, with a certain latency. A new set of 8-bit Filtered Et data needs to be determined every 8 Sub-Ticks and one bit slice of this serialized Et data needs to be transferred to the TAB via the Channel Link Serializer every sub-tick. SCLD Input Signals ================== The Data Path FPGA does not directly receive the Beam Crossing clock as was already mentioned in the Clock Input section. The ADF-2 circuit board instead derives from it and provides to the data path FPGA the BX_X8_CLK and the FIRST_X8_EDGE input signals. The rest of the SCL and custom control signals distributed by the SCLD to each ADF crate is available as input to the Data Path FPGA. These signals are received as BEGIN_TURN (net name RCVD_BEGIN_TURN) ------------------------------------- This is the Begin of Turn Marker distributed by the Serial Command Link. This signal is used to locate the input data corresponding to Tevatron bunch P1 crossing at DZero, which needs to be labelled as Bunch Crossing Tick #1. The Data Path FPGA needs to capture the state of this backplane signal at the rising edge of Sub-Tick #0. The Tick Number internally maintained by the Data path FPGA needs to be incremented at each Beam Crossing, and reset at each Begin of Trun. There are 159 Ticks (#1:#159) before the next Begin of Turn Marker. There are four factors that need to be taken into account in order to properly locate the ADF-2 output corresponding to Tick #1. - The charge drift time after energy deposit inside the calorimeter and the propagation to the BLS cards, the analog signal processing within the BLS cards, the propagation through the cables from the platform to the input of the ADF-2 cards. - The ADF-2 introduces its own latency while converting its analog input energy E to digital numbers, then filtering, and finally converting the filtered data into its transverse component Et before sending that data to the Channel Link transceivers. - The SCL is specified to advertize the BOT signal ahead of the actual occurence of bunch P1 crossing D0 by a defined and fixed number of 132ns ticks constant for all DZero Front-End Crates. - The distribution of the SCLD signals to the ADF Crate backplane has some inherent latency, and the SCLD may have to introduce an additional delay to the Beam Crossing Clock (and all other SCL Markers with it) by a certain number of 53.1 MHz cycles (18.8 ns) in order to adjust the time at which the ADF-2 system starts transferring serial data to the TAB cards relatively to the Beam Crossing clock. All these factors will remain constant during Run IIb. Any adjustement of SCLD timing will need to be determined early during commissioning. The effect of all factors combined will thus be determined only once, and for the whole system. This will define the operational latency between the occurence of the BOT marker (as captured at the input of the Data Path FPGA) and the availibility of the Et data corresponding to this Tick #1 as tagged and sent to the TAB crate. The ADF subsystem is responsible for determining this latency and the TAB subsystem will not need to re-determine it. LIVEBX (net name RCVD_LIVEBX) ----------------------------- This is the Live Beam Crossing Marker distributed by the Serial Command Link. This signal is used to identify which of the 132ns Ticks actually had some Beam particles. The ADF-2 system produces and sends Et output to the TAB Crate every 132ns, and it could also use this Live Crossing information to guarantee that it advertizes non-zero Trigger Tower energy only for crossings containing beam. The suppression of Energy output for ticks not corresponding to Live Crossings will be implemented as a run-time configuration option. The Data Path FPGA needs to capture the state of this backplane signal at the rising edge of Sub-Tick #0. The Live Crossing Marker suffers from exactly the same latency issues as the Begin of Turn Marker, and needs to be adjusted in the exact same way to properly locate the corresponding output Ticks. L1_ACPT (net name RCVD_L1_ACPT) ------------------------------- This is the Level 1 Accept Marker issued by the Level 1 Trigger Framework and distributed by the Serial Command Link. This signal is asserted every time the L1 Framework makes a Level 1 Accept decision that requires collecting data from the L1CAL system. The Data Path FPGA needs to capture the state of this backplane signal at the rising edge of Sub-Tick #0. The latency between a particular crossing and a L1 Accept corresponding to this Beam Crossing is fixed and involves two factors. - The fixed latency at which the L1 Framework is advertizing the L1 Trigger Decisions and the fixed latency of transmission by the SCL. - Any delay introduced by the SCLD plus propagation to the ADF Crate backplanes. There is currently no usage planned for this information in the ADF Crates. The Data Path FPGA will take no action when this signal is asserted. The Data Path FPGA will continue processing all 132ns Ticks and sending its output to the TAB crate at all times. All the data readout from the L1CAL system and sent to the L2 and L3 Trigger Levels will come from the TAB Crate. The ADF Crate sends Trigger Tower Et information to the TAB Crate, and the TAB Crate is responsible for remembering and reading out the proper slice of Et information after each L1_Accept. SAVE_MONIT_DATA (net name RCVD_SAVE_MONIT_DATA) ----------------------------------------------- This is a control signal generated by logic on the SCLD from a number of sources and requirements. cf. scld_adf_crate_control.txt in http://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/adf_2/general/ The Data Path FPGA needs to capture the state of this backplane signal at the rising edge of Sub-Tick #0. The simple case to consider is when the SCLD has been told to distribute the next issuance of the "Collect Status" L1_Qualifier associated with a L1_Accept issued to the ADF's Geographic Section. When the Data Path FPGA finds the SAVE_MONIT_DATA signal asserted, it needs to capture (or preserve) the monitoring data corresponding to the Beam Crossing that caused this L1_Accept. In order to capture the correct crossing (or locate within previously recorded crossings), the Data Path FPGA will need to take into account the latency described in the description of the RCVD_L1ACPT signal. Besides the Collect Status L1_Qualifier mechanism for capturing Monitoring Data, the SCLD can issue the SAVE_MONIT_DATA signal from other stimuli, e.g. an explicit request from TCC. The ADF-2 Data Path FPGA will respond in the same manner independently of the original stimulus that caused the assertion of the SAVE_MONIT_DATA signal. SCL_INIT (net name RCVD_SCL_INIT) -------------------------------- This is the SCL Initialization signal distributed by the Serial Command Link. The Data Path FPGA needs to capture the state of this backplane signal at the rising edge of Sub-Tick #0. No firmware will be reloaded, and no involvement from TCC is required to respond to SCL_INIT. The SCL_INIT signal may be used in the implementation of the Data Path FPGA to forcibly reset apropriate resources, but no major activity is envisioned for the initial implementation of the Data Path FPGA. The ADF-2 will not communicate back to the SCLD after an SCL_INIT is received. The SCLD will handle the SCL Initialization protocol and will automatically send the required Init_Ack signal back to the SCL Hub End after a fixed delay. SPARE (net name RCVD_SPARE) --------------------------- This is a reserved signal from the SCLD. Beam Crossing Tick Number and Sub-Tick Number ============================================= The ADF-2 will reconstruct the 8-bit Beam Crossing Tick Number (from 1 to 159) of each Beam Crossing being analyzed. Each ADF-2 card will send to the TAB Crate the Tick Number corresponding to the crossing in the accelerator which generated the Energy deposit being reported. The ADF-2 will also generate, for its own internal usage, a 3-bit Sub-Tick Number (from 0 to 7) to label each of the eight BX_X8_CLK sub-ticks within each Beam Crossing Tick Number. These two numbers are generated together by an 11 bit (8+3) synchronous counter with synchronous load. The lower 3 LSBs form the Sub-Tick Number while the upper 8 MSBs form the Beam Crossing Tick Number. The SCL Begin of Turn Marker will be used to set the phase of this 11-bit counter. When the BEGIN_TURN Marker input is found asserted, this synchronous counter will be reset to a fixed preset value. This preset value would be 00000001000 (in binary) if the BEGIN_TURN Marker were received exactly when the ADF-2 is outputing the Trigger Tower Et Energies from Bunch Tick #1. The BEGIN_TURN marker will not be received at that time because of all the sources of latency described earlier in this document. This simply means that the preset value for this counter will need to be a specific number empirically measured and defined during commissioning. This preset number will be identical for all ADF-2 Cards in all 4 ADF Crates, and constant for the life of the system. This synchronous counter will also need to "rollover" from the value 10011111111 (binary) to 00000001000 (binary) to go from the last Sub-Tick (#7) of the last Tick (#159) to the first Sub-Tick (#0) of the first Tick (#1). The rest of this document will use the Sub-Tick Number to identify the occurence of various activities on the ADF-2 Cards. All control of the synchronous logic within the Data Path FPGA will be achieved by distributing the BX_X8_CLK signal and the Sub-Tick number on Global Clock Networks. The sub-tick information can be used to select individual sub-ticks within each 132 ns tick to perform certain logic operation, e.g. generating the ADC Clock. The ADF-2 will also generate, for its own internal usage, a 2-bit partial Turn Number (from 0 to 3) used to generate memory addresses for monitoring data that needs to record more than one turn worth of data. Trigger Tower ADC Input ======================= The Data Path FPGA receives the output of 8 pairs of EM and HD Trigger Tower ADC's. Each ADC input is 10 bit wide. The Data Path FPGA provides individual ADC Encode Clocks signals to each of the 16 ADC channels it controls. The initial implementation of the Data Path FPGA will drive all the ADC conversion synchronously at 4 times the Beam crossing frequency, i.e. every 33 ns. Providing individual encode clocks to each ADC converter leaves enough future flexibility to allow splitting the ADC channels in two halves, mutually shifted by 180 degrees (if this were shown to generate less system wide noise), or allowing individual selection of the phase for each ADC (if this were shown to be necessary to achieve better filter performance). The AD9218 dual ADC chip used on the ADF-2 board is a pipelined converter that takes 5 of its input clock cycles to produce the digital output of a given ADC conversion. Data is guaranteed valid at the output of the ADC chip 6 ns after the rising edge of its encode clock input, and remains valid untill 3 ns after the next rising edge of the encode clock input. The Data Path FPGA could assert the ADC encode clock at the rising edge of a given sub-tick and comfortably capture the ADC data at the rising edge of the following sub-tick. If lowering latency becomes an issue, the data path FPGA could probably gain one sub-tick by capturing the ADC data at the same sub-tick that it starts asserting the ADC encode clock. The ADC data captured at the input of the Data Path FPGA corresponds to the analog input voltage to the ADC present 5 enable clock cycles earlier. This means that the ADC data is captured by the Data Path FPGA with a latency of aproximately 5 x 33 + 16.5 ~ 182 ns, to which one needs to add the latency of the backplane connection and ADF-2 analog front-end to form a global latency from the ADF-2 input connector. Channel Data Path Signal Processing =================================== Once the Trigger Tower raw ADC quantities have been received, the data path FPGA needs to: 1) Adjust the skew in latency between Trigger Towers 2) Record the full stream of raw ADC data for monitoring purposes 3) Select between the latency adjusted raw ADC data and user defined simulation data 4) Filter the 10-bit raw ADC Energy input streadm sampled at 4 times the Beam Crossing Frequency to produce one 10-bit filtered Energy Quantity every 132ns Tick. 5) Scale this 10-bit Energy to its transverse component to produce a computed 8-bit Et Output 6) Select between the computed Et Energy, or a constant value, or user defined simulation data 7) Optionally suppress output energy for all 132ns Ticks that were not marked as Live Crossings by the SCL. The fixed (non-zero) Zero Energy Response should be output instead. 8) Record the stream of Final Et Output for monitoring purposes 9) Serialize the Final Et 8-bit Output value The first eight steps are represented in the diagram data_path_fpga_signal_processing.pdf in http://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/adf_2/drawings/ The final ninth step is part of the section of the logic that interfaces to the Channel Link Transmitter output section and is shown in the diagram data_path_fpga_output_to_channel_link.pdf found in the same directory. This final step involves all channels and involves computing a card wide parity before driving ouput pins with all the serialized Final Et data sent to the Channel Link tramsitter. All these steps are described in more details in separate sections below. Latency Adjust ============== The bump in the analog input signal corresponding to the energy deposited in the Calorimeter for a particular Beam Crossing reaches the input of the ADF-2 cards with a latency of about 700 ns. All 1280 Trigger Towers are not subjected to the same latency, and the skew between different Trigger Towers is about 100 ns [to be verified]. This effect is compensated for by the ADF-2 Data Path FPGA. For a given Trigger Tower, the position of the peak energy deposit can jitter as a function of the depth of the energy deposit within the Trigger Tower. This crossing to crossing jitter can be of order +/- 30 ns [to be verified]. This effect cannot be directly compensated for by the ADF-2 Data Path FPGA, while apropriately chosen algorithms can try to account for this effect. Each Data Path FPGA will separately delay each ADC channel to line up in time the signal from all 1280 Trigger Towers before any processing takes place. The 10 bit raw ADC data is received at 4 times the Beam Crossing frequency, and is delayed through a 10 bit wide shift register with programmable length. This step happens right after the Raw ADC data has been received and latched at the FPGA input I/O pins. The shift register length for each EM or HD Trigger Tower ADC input can be adjusted individually to 0, 1, 2, 3 or 4 time slices which allows for relative delays of 0, 33, 66, 99, or 132 ns. Monitoring Data and Simulated Data ================================== The Data Path FPGA needs to support Monitoring and Commissioning by providing the following functionality: 1) Capture the 10 bit ADC Raw Data at the full 4x Beam Crossing rate and be able to save this information when a SAVE_MONIT_DATA request is issued by the SCLD. This data can be read back by TCC and used for general monitoring purpose during normal operation. This Raw ADC Data will also be used to study and calibrate the operation of the filtering section of the data processing. 2) Simulate arbitrary Raw ADC data at the full 4x Beam Crossing rate and for a significant number of successive Beam Crossings. This data can be written by TCC and used to support testing and commissioning of the ADF-2 Cards, and of the complete L1CAL system. 3) Capture the final 8 bit Et output at the full Beam Crossing rate and be able to save this information when a SAVE_MONIT_DATA request is issued by the SCLD. This data can be read back by TCC and used for general monitoring purpose during normal operation. This Raw ADC Data can also be used to verify the operation of the filtering section of the data processing. 4) Simulate arbitrary Trigger Tower Et at the full Beam Crossing rate to be sent to the TAB Crate for a subsequent number of consecutive Beam Crossings. This data can be written by TCC and used to support testing and commissioning of the TAB subsystem. The Virtex-II family of FPGA includes dedicated blocks of 18kbit dual-port memory resources distributed across the chip. Xilinx calls this type of resources "Block SelectRAM Memory". The two configurations of Block SelectRAM of special interest for this application are 1k x 18 bits and 2k x 9 bits. The Data Path FPGA usage of Block SelectRAM resources is also described in adf_2_fpga_memory_resources.txt found in http://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/adf_2/general/ Items #1 and #2 above use the same dual port memory resource, with the same address generator. This memory is used in write mode to record raw data, and used in read mode to replay computer prepared simulated raw data. The Data Path FPGA will use a 1kx18bit Dual Port RAM where the 10-bit address is generated from the 8-bit Tick Number (upper address bits), and the upper two bits of the 3-bit Sub-Tick Number (lower address bits). Items #3 and #4 above use the same dual port memory resource, with the same address generator. This memory is used in write mode to record Final Et output data, and used in read mode to replay computer prepared simulated Et output data. The Data Path FPGA will use an 18-bit memory for this purpose, shared to simultaneously record the 8-bit EM and 8-bit HD Et channels. This function will use a 1kx18bit Dual Port RAM where the 10-bit address is generated from the 8-bit Tick Number (lower address bits), and a locally generated 2-bit Turn Number (upper address bits). These two memory resources can be independently set to be in Read of Write mode. The L1CAL TCC will control how the memory resources are used at any given time. The normal mode of operation will be to continuosly record the Raw ADC data and the Final Et Output data by continuously writing to these monitoring data buffer managed as circular buffers with newer data cyclicly overwriting older data. Capturing Monitoring data will be accomplished by suspending this writing operation. The ADF-2 system uses the SAVE_MONIT_DATA control signal managed by the SCLD and synchronously distributed to all the crates to orchestrate the recording and capture of the monitoring data. When the SCLD asserts the SAVE_MONIT_DATA signal, all the Data Path FPGA of the system will synchronously stops overwriting all their monitoring buffers. The L1CAL Trigger Control Computer can then slowly read out all the monitoring data it wants. The data path FPGAs will also capture a snaphot of the Tick Number a the time of the occurence of the SAVE_MONIT_DATA request and TCC can thus locate the data corresponding to the particular Tick that caused the SAVE_MONIT_DATA request. L1CAL TCC can exercize and verify the filtering logic of the Data Path FPGA by setting up and playing an arbitrary pattern (one whole turn) of simulated raw data at 4 times the beam crossing rate and capturing the Et output. This method will verify the operation of the system at full design speed, and at least a whole turn of data at a time. L1CAL TCC will be able to exercize the TAB algorithm by loading a prepared arbitrary pattern (up to 4 whole turns) of simulated Et output data to be sent to the TAB crate. All ADF-2 cards are synchronized and will march through their patterns syncrhonously, and can thus replay whole arbitrary events. To support this type of test, the TAB system will also need to be able to synchronously capture monitoring information for at least at least one crossing (preferably many). L1CAL TCC will be able to exercize the full ADF+TAB+GAB system (minus the analog front-end) by loading simulated raw data patterns, and verifying the TAB and GAB decisions. EM and HD Filtering =================== This is the step outlined above where the stream of 10-bit raw ADC samples captured at 4 times the Beam Crossing frequency is filtered into a stream of 10-bit Filtered Energy at 1 time the Beam Crossing frequency. The goal of this filtering is to recover the original energy deposit. This filtering may also try to reject some of the high frequency and low frequency noise that may affect the analog signal, as well a as correct for the influence of energy deposited in earlier crossings. The pedestal (the ADC count corresponding to a zero energy input) will have been adjusted to a fixed value [tentatively defined as 32 counts] with no beam in the machine. This pedestal needs to be preserved at the output of the filter. The detailed operation of this filter will be described separetaly. This filtering is one of the original motivations for upgrading L1CAL. The ADF-2 circuit board and the rest of the Data Path FPGA are providing the infrastructure necessary to make this filtering possible. This filtering process will need to be implemented as a syncrhonous algorithm producing one 10-bit output every 132 ns with a fixed latency with respect to the input stream. This latency still needs to be determined. This filtering algorithm operates on the input stream of raw ADC data and can achieve its goal using a number of techniques: - averaging several of the 4 samples in the current tick - locating peak values - applying a correction based on samples from the previous 4 samples - applying a correction based on samples from the next 4 samples Note that this algorithm may use more than only the 4 samples from a given 132ns Tick. It can remember older samples and build running sums. It can also include samples nore recent than the current input Tick by waiting for more information to arrive and systematically delaying its answer at the cost of some fixed latency between the tick number of the data being output with respect to the tick number of the data at the input stream. The output of the filter will consist of one 10-bit Filtered Energy number and one optional overflow bit. If the algorithm detects an overflow of one of its processing stages, it can assert the overflow bit, and the Data Path logic downstream from the filter will force an energy value corresponding to full scale. This will save extra logic in the filter algorithm to protect against rollover of the 10-bit Energy output, while this feature can be implemented "for free" in the E->Et scaling lookup. This filtering will not have access to the information identifying which 132 ns Tick contains Live Crossing information. This filtering should avoid introducing a "rectifier effect" and should be ready to output "negative energies" as well as positive values for noisy inputs. E->Et Scaling ============= Each EM or HD Channel will use a 2kx9 memory lookup to convert the Filtered 10-bit Trigger Tower Energy to its transverse component Et as an 8-bit number. 2k corresponds to 11 address lines. The lower 10 address bits (A0-A9) will be driven by the 10-bit output from the filter algorithm, while the upper address bit (A10) will be driven by the overflow bit, also generated by the filter logic. This lookup will implement the scaling of E to Et, and the slope of this lookup is slolely driven by the trigger tower Eta coordinate. This lookup could easily implement a symmetric low energy cut to suppress low energy noise values, but it is currently envisioned that the TAB system will not need such a feature, and can internally implement any low energy cut. This scaling will need to preserve the Zero Energy Response of (tentatively) 32 counts of 10-bit Filtered Energy becoming 8 counts of 8-bit Filtered Et. This memory will be initialized by TCC once at power up. Channel Link Output =================== Digital Signal processing on the Data Path FPGA ends with the generation of EM and HD 8 bit Et Energy quantities. This is the information that is sent to the TAB Crate for input to the TAB Cards. The Channel Link section of the Data Path FPGA handles the transmission of this information to the TAB Crate. Each ADF-2 sends 3 identical copies of the same information to 3 different TAB Cards. Without this tri-plication, the TAB algorithms would be missing neighbor tower information at the edge of their coverage, or have to transmit and share information among neighboring TAB cards. Each FPGA serializes the 8 bit Et Energy quantities from all its 8 pairs of EM and HD Trigger Towers and produces 8 time slices with the Least Significant Bits sent first. The data payload transported by the Channel Link transmitter of the ADF-2 card consists of 42 user bits, with 8 time slices sent every 132 ns Tick, corresponding to one slice of 42 user bits sent for every period of the BX_8X_CLK clock. Each user bit is a serialized 8 bit number, with the least significant bit sent first. The 42 user bits of the 3 Channel Link transmitters are bussed and each user bit is driven from one single output pad from one of the two Data Path FPGAs. All ADF-2 Cards in the system will start transferring each Beam Crossing information at the same time, with a skew driven only by the propagation time of the SCLD control signals along the VME backplane. All Data Path FPGAs will start transferring the LSB of a new Crossing on the same sub-tick, and the time skew between different ADF-2 cards will be less than 10 ns. The 42 user bits transported over the Channel Link consist of - 32 bits of Trigger Towers EM and HD Et energies with 16 bits coming from each Data Path FPGA, and this aspect is handled identically in F0 and F1. - 1 bit for the Tick Number - 1 bit to signal the beginning of a new serial frame of 8 bits corresponding to the information from a new Beam Crossing. - 7 unused bits, always low. - 1 parity bit formed as the XOR of the other 41 bits for each time slice. Each FPGA sends its 16 serialized Et quantities to the Channel Link transmitter. FPGA additionally F0 sends the Tick Number bit, the Beginning of Frame bit, and the parity bit. F0 sends 4 of the unused bits, and F1 sends 3. This is the only section of the Data Path FPGA where F0 and F1 are not used in exactly the same way. The crucial point here is that this discrepancy is made transparent to the firmware, and the exact same configuration is loaded in both F0 and F1. FPGA F0 must be able to compute a global parity that needs to include the contribution of the 16 Trigger Tower Et bits from FPGA F1, however F0 never sees the actual state of the 16 bits generated by F1. FPGA F1 will thus compute a local Et parity for these 16 bits and send that one bit of parity information on its LOC_PARITY_OUT_F1 output pin directly to F0 on its LOC_PARITY_IN_F0 input pin. F0 must be able to line up, for each time slice, the local Et parity from F1 with its own local parity, and send this parity out to the channel link transmitter along with the Et Parity from F0 and F1 for this same time slice. This is accomplished by F1 computing and outputing its local parity for a given bit slice at the beginning of a certain sub-tick #N, but delaying sending its Et information for that time slice by one sub-tick and sending it instead at the beginning of sub-tick #N+1. During sub-tick #N F0 will receive and combine the local Et parity from F1 with its own local Et parity, as well as with the serialized Beam Crossing and the Begin Frame bit to generate a global parity bit. F0 will then output all its serial information, including the global parity bit for that time slice on the following sub-tick #N+1, which also corresponds to the time when F1 sends its information for that time slice. All 7 unused bits are always low, and do not contribute to the parity calculation. cf. data_path_fpga_output_to_channel_link.pdf in http://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/adf_2/drawings/ FPGA Status Output ================== Each Data Path FPGA separately sends 4 status signals (net names FPGA_0_STATUS(0:3) for FPGA #0 and FPGA_1_STATUS(0:3) for FPGA#1) to the Board Control PAL. The state of these status signals can be read by TCC from a register in the Board Control PAL. There are currently no defined usage for these Status Signals. Calibration =========== Four aspects of the ADF-2 data signal processing will need to be calibrated separately for each Trigger Tower EM and HD channel. 1)The pedestal of the analog input signal and the analog input circuitry must be adjusted to produce a fixed Zero Energy Response of (tentatively) 32 counts of raw ADC data while digitizing the BLS signal when there is no beam in the accelerator. This is accomplished by setting the pedestal control value to a default value, then collecting montioring data and histograming the raw ADC data output, then ramping the pedestal control value up or down until the desired zero energy response is reached. 2)The shift register delay for the Latency Adjustment stage of the Data Path FPGA needs to be determined using raw data captured with beam in the accelerator. This is accomplished by collecting a number of energy deposit signals sampled as raw ADC data, and locating the average position of the peak of the signal, and deriving delay settings from it. This data can actually be collected with no impact on the rest of the DAQ system during normal runs. 3)The coefficients and parameters of the filtering stage need to be determined (depending on the filtering algorithm chosen) using raw data captured with beam in the accelerator. This is accomplished at the same time as step #2 above by collecting a number of energy deposit signals sampled as raw ADC data, and deriving the proper parameters and coefficients for the filtering algorithm. This data can also be collected with no impact on the rest of the DAQ system during normal runs. 4)The E to Et transfer coefficient needs to be tuned by comparison between the trigger tower energy determined by the ADF-2 filter and the precision readout from the calorimeter electronics. This is accomplished by studying a large set of real events collected by the full DAQ system over a period of time and analyzed offline.