02/25/2002 XTRP_2Track-Trigger_Design_Notes.txt XTRP 2-Track-Trigger Board Table of Contents: 0. XTRP Overview*** 1. 2-Track-Trigger Clocks*** 2. VME Interface*** 3. Data Flow Overview 3.1 HitCodes 3.2 Code RAMs 3.2.1 TrackCode Algorithm 3.2.2 TrackCode Implementation 3.2.3 WedgeCode Algorithm 3.2.4 WedgeCode Implementation 3.3 Trans_x 3.4 Tsort(c)_x 3.5 Trigger RAMs 3.6 TRIG_L 8. FPGA Configuration Scheme:*** 9. ID PROM:*** ***See XTRP_Data_board_Design_Notes.txt 3. Data Flow Overview The 2-Track Trigger Board receives data from 12 XTRP Data Boards. It outputs data through a Transition Module to Pre-FRED and retains a Level 2 Buffer for VME Readout. The essence of the 2-Track Trigger board is to compare up to 6 XFT tracks/event against each other with discriminators to reject uninteresting collision events. 3.1 HitCodes The Lookup RAMs on the XTRP Data Boards are programmed to select which XFT tracks are candidates for the 2-Track Trigger. The 12 Data Boards do not communicate with each other to determine the number of XFT track candidates. This function is performed by the 2-Track Trigger itself. Each of the 24 wedges in the data boards generate a 2-bit HitCode. All 48 HitCodes are sent to the 2-Track Trigger across the P3 Backplane. The Backplane is routed so that each HitCode path is unique; the 2-Track Trigger can determine the origin of the slot and wedge each HitCode came from. HitCode: 00 - 0 XFT Track candidates 01 - 1 XFT Track candidate 10 - 2 XFT Track candidates 11 - more than 2 XFT Track candidates(only 2 tracks will be sent) On the 2-Track Trigger schematic, the HitCodes are presented as HITCODE_Wy_(1:0), y=wedge number(0-23). They are latched into HitCode Registers on the rising edge of CLK132_3, 66ns after HitBits from the Data Board Lookup RAMs were latched. 3.2 Code RAMs The latched HitCodes are passed on to the address lines of the Track and Wedge Code RAMs. The Code RAMs are large lookup tables to generate TrackCodes and WedgeCodes. The Code RAMs are organized into quadrants, with each quadrant assigned to 6 data board wedges. Each quadrant has a single Track Code RAM and two Wedge Code RAMs. The outputs of the HitCode Registers, QxHIT(11:0), x=quadrant(0-3) are passed to the addresses of the Code RAMs while Track and Wedge Codes are output the data lines. The outputs of the Hit Code registers may be disabled and either simulated HitCodes or a configuration address may be presented by Topc_x onto the QxHIT busses. 3.2.1 TrackCode Algorithm XFT Track candidates are assigned to 6 Track Busses, A-F. The assignment is in linear wedge-numbered order with the XFT track from the least-ordered wedge assigned to track bus A. In the case of 2 XFT Track candidates from a given wedge, two sequentially adjacent track busses would be assigned to that wedge, for example: C & D. Once all 6 track busses have been assigned, any remaining XFT Track candidates are assigned a null TrackCode. The 2-Track Trigger will flag the event and any further processing on data from that event is to be ignored. In the first quadrant, wedges 0-5, the Track Code RAM can completely assign all candidate XFT tracks from wedges 0-5 to track busses. The Wedge Code RAMs tally up the number of XFT track candidates and output the result to the second quadrant. The second quadrant Code RAMs receive both the latched HitCodes from wedges 6-11 as well as the summation of XFT track candidates from the first quadrant. For the Track Code RAM, the summation serves as the starting track bus to assign XFT track candidates from wedges 6-11. The second quadrant Wedge Code RAMs add the number of XFT track candidates from wedges 6-11 to the summation of tracks from wedges 0-5 and pass this new result to the third quadrant. The third quadrant operates in a similar fashion to the second quadrant, assigning track busses with regard to summation data from the previous quadrant and the number of XFT track candidates from wedges 12-17. The same holds for the fourth quadrant as it handles wedges 18-23. The propogation delay to determine all TrackCodes for all wedges, with wedges 18-23 taking the longest time to resolve, is most dependent on the propogation time to traverse 4 RAMs. wedges 0-5 -{RAM}->resolved in 1 RAM delay | wedges 6-11 -{RAM}->resolved in 2 RAM delays | wedges 12-17 -{RAM}->resolved in 3 RAM delays | wedges 18-23 -{RAM}->resolved in 4 RAM delays 3.2.2 TrackCode Implementation Three bits are sufficient to encode a track bus number. One permutation is reserved for no track assignment, 6 for each track bus, and the eighth is for assignment for 7+ tracks. TrackCode: 000 - no Track Bus assignment 001 - Track Bus A 010 - Track Bus B 011 - Track Bus C 100 - Track Bus D 101 - Track Bus E 110 - Track Bus F 111 - invalid Track Bus assignment Each data board wedge receives a TrackCode. For wedges that have 2 XFT track candidates, only the least-ordered track bus code is returned. In these cases, it is implied that not only the explicit track bus encoded in the TrackCode is granted to the given wedge but also the next sequential track bus. For example, wedge N sends HitCode 10 to the 2-Track Trigger and receives TrackCode 100. In this instance, wedge N utilizes track busses D and E. The Code RAMs all have an 18-bit data bus. The structure of 6 wedges/quadrant nicely encompasses full utilization of the data bus. The TrackCodes from the RAMs, QxTRC are latched into a Track Code Buffer on CLK132_1, TKCODE_Wx_(2:0). All TrackCodes must be generated within 66ns of the latching of the HitCodes. TKCODE_Wx_() is sent back to the data boards through the P3 backplane. A second buffer, Track Code/VME buffer, permits TrackCodes to be simulated and gives VME access to the data lines of the Track Code RAMs. The control lines of the two buffers (transceivers?) come from the Topc_x Fpga. The Track and Wedge Code RAM address width is 15 bits - 12 bits for HitCodes within a given quadrant plus 3 bits for previous track summary information. 3.2.3 WedgeCode Algorithm The Wedge Code RAMs provide the wedge number for the track busses. Since any track bus may be assigned in any quadrant, any quadrant may need to assign a WedgeCode to any track bus. Therefore, each quadrant does indeed supply a WedgeCode for each track bus. Most of the 24 generated WedgeCodes will obviously want to be ignored, and only up to 6 retained. Invalid WedgeCodes are assigned a number that can be ignored. Since space was available in the utilization of the data bits of the Wedge Code RAMs, two XFT track candidate summations are generated. Each quadrant maintains a total summary from wedge 0 up to the given quadrant plus a second summary of candidate tracks found only within the given quadrant. The total summary is sent to the next sequential quadrant, while the local summary is useful for debugging. The propogation diagram shown above is applicable for WedgeCodes as well. The maximum number of RAM propogation is 4. 3.2.4 WedgeCode Implementation As stated previoulsy, each quadrant has two Wedge Code RAMs, referenced as WedgeABC and WedgeDEF. Wedge Codes for Track busses A,B and C are covered be WedgeABC and track busses D,E and F are covered by WedgeDEF. 5 bits are required to encode a wedge number: 24 permutations for each of 24 wedges, 7 declared invalid, and one permutation for a purposely nulled WedgeCode. WedgeCode: 00000-10111 Wedge numbers 0-23 11000-11110 Invalid 11111 Null WedgeCode Since both Wedge Code RAMs supply codes for 3 track busses, 15 bits of each RAM data bus is consumed for this purpose. The remaining 3 bits allow track summation encoding. WedgeABC RAMs yield a local summation of XFT track candidates from each quadrant. WedgeDEF RAMs yield a total summary of tracks. WedgeABC: Q0SUM(2:0) - sum of tracks found in wedges 0-5 Q1SUM(2:0) - sum of tracks found in wedges 6-11 Q2SUM(2:0) - sum of tracks found in wedges 12-17 Q3SUM(2:0) - sum of tracks found in wedges 18-23 WedgeDEF: Q00SUM(2:0) - sum of tracks found in wedges 0-5 Q01SUM(2:0) - sum of tracks found in wedges 0-11 Q02SUM(2:0) - sum of tracks found in wedges 0-17 Q03SUM(2:0) - sum of tracks found in wedges 0-23 Note: Q03SUM is sent to the Trig_x Fpga; a value of 111 indicates more than 6 track candidate were found. The data lines of the Wedge Code RAMs, yQx_WNUM and QxSUM, are connected to the VME data bus through Wedge Code Transceivers. The controls for the transceivers are sourced by the Topc_x Fpga. The WedgeCodes, yQx_WNUM (y=A-F, x=0-3) are also sent to a bank of open-collector registers. These register latch the WedgeCodes on the rising edge of CLK132_1. As with the TrackCodes, the WedgeCodes must be generated within 66ns. The open-collector registers are wired to perform a logic-AND of the WedgeCodes across all 4 quadrants. The null WedgeCode of 11111 is wiped out in the logical-AND operation. A final set of WedgeCodes, WEDGE_y (y=A-F) is generated, one final WedgeCode for each track bus. These WedgeCodes are sent to the Trans_x Fpga. 3.3 Trans_x The data boards receive the TrackCodes and issue track busses on 3 time-multiplexed track channels. To see how that is done, refer to data board documents. The Trans_x fpga merges the XFT track data with the WedgeCodes. A conversion is done inside Trans_x to combine the segment and wedge numbers into a linear segment/wedge phi number: Seg./Wedge = Wedge * 12 + segment. 3.4 Tsort(c)_x Two time-multiplexed 9-bit busses, one of phi data (segment/wedge#), and one of Pt data(Pt,Short,Isolation) are created for each pair of track busses by Trans_x. TRK_PT_AD(8:0) TRK_PT_BE(8:0) TRK_PT_CF(8:0) TRK_PHI_AD(8:0) TRK_PHI_BE(8:0) TRK_PHI_CF(8:0) These busses are routed to the 6 Tsort_x Fpgas. The Tsort_x fpgas demux the track data and generate track pairs. The intent was to have a single universal Tsort_x algorithm for all 6 Tsort_x Fpgas, but an error prevented that solution. Instead, Tsortc_x was necessary. The assignment of track pairs amongst the Tsort_x fpgas was done in a manner such that each Tsort_x fpga requires only 2 time-multiplexed TRK_PT(PHI)_xx busses TRK_PT_AD, TRK_PT_BE -> Tsort_x #2 TRK_PT_BE, TRK_PT_CF -> Tsort_x #3 TRK_PT_CF, TRK_PT_AD -> Tsort_x #4 TRK_PT_AD, TRK_PT_BE -> Tsort_x #5 TRK_PT_BE, TRK_PT_CF -> Tsort_x #6 TRK_PT_CF, TRK_PT_AD -> Tsort_x #7 The Tsort_x Fpga sends track pairs to the Trigger RAMs. Each Tsort_x fpga sources 5 Trigger RAMs. There are 15 permutations possible when pairing 6 tracks amongst each other. Since pairings are done for both Pt and Phi data, 30 pairings are performed. A B C D E F ------------------------ A| - AB AC AD AE AF B| - - BC BD BE BF C| - - - CD CE CF D| - - - - DE DF E| - - - - - EF F| - - - - - - The Tsort_x fpgas are matched up so that 5 pairwise combinations of Pt data for a given Tsort_x fpga are identical to the 5 pairwise combinations of Phi data for a second Tsort_x fpga. Pt: Phi: Tsort_x #2 #5 AD, AB, AE, BD, DE Tsort_x #3 #6 BE, BC, BF, CE, EF Tsortc_x #4 #7 CF, AC, CD, AF, DF 3.5 Trigger RAMs There are 30 512Kx8 Trigger RAMs on the 2-Track Trigger Board. The 19-bit addresses are sourced by 18-bit track pairs of either Pt or Phi data. The 19th bit provides a 2-phase lookup algorithm. Each of the 8 data lines is programmed to detect some trigger threshhold. During a 132ns clock cycle, the 2 phases of the lookup table x 8 bits yields 16 possible triggers for each track pair. One of the triggers will be overwritten by a Greater-than-6 flag for quantity of XFT track candidates. The Pt and Phi Trigger RAMs of each track pairs are treated as a common entity during VME transactions. During VME configurations, bits 7:0 of the VME Data Bus are directed at the Pt RAM and bits 15:8 of the same transaction are targeted at the Phi RAM. The control lines of the Trigger Transceivers are sourced by the Trig_x Fpga. 3.6 TRIG_L TRIG_L(7:0)is a trigger summary bus. The Trigger RAMs can provide 8 simultaneous trigger threshholds, thus the width of TRIG_L. The outputs of the Trigger RAMs, TRG_PT_xx(7:0) and TRG_PHI_xx(7:0) are active-high when a trigger threshhold is detected. For a trigger to be detected, both the Pt and Phi Trigger RAMs must assert their trigger conditions. The Pt and Phi trigger bits of each track pair are NAND-ed together to yield a low-active trigger. Ex. (suppose only one track pair exists...) TRIG_L(x) = ~(TRIG_PT_AB(x) * TRIG_PHI_AB(x)), x= 7:0 On the 2-Track Trigger Board, the NAND gates are 74F38s, open-collector outputs. Furthermore, the TRIG_L(x) signals are tied in common across all 15 track pairs. If any track pair satisfies both the Pt and Phi threshholds for some bit, then the TRIG_L line for that bit will be asserted. x=7:0 TRIG_L(x) = [~(TRIG_PT_AB(x) * TRIG_PHI_AB(x))] * [~(TRIG_PT_AC(x) * TRIG_PHI_AC(x))] * ... [~(TRIG_PT_EF(x) * TRIG_PHI_EF(x))] TRIG_L is fed into the Trig_x Fpga. Inside Trig_x, the trigger summary bus is demuxed and stored in a Level 1 Pipeline and Level 2 Buffer. It is also passed out of Trig_x to the Transition Module and sent to Pre-Fred. TRIG_GRP_A(6:0) - triggers while CLK132_0 = 1 TRIG_GRP_A(7) - greater than 6 flag TRIG_GRP_B(7:0) - triggers while CLK132_0 = 0