From SILVIA@d0fsub.fnal.gov Wed Feb 17 16:16:51 1999 Date: Tue, 26 Jan 1999 16:15:40 -0600 (CST) From: "Silvia Tentindo-Repond @D0" To: WAHL@d0fsub.fnal.gov, HARRY@d0fsub.fnal.gov Cc: SILVIA@d0fsub.fnal.gov Subject: STT data input - revised Resent-Date: Tue, 26 Jan 1999 17:16:41 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl THE INPUT DATA FLOW TO L2 STT TRIGGER CARD FROM SMT FRONT-ENDS 22-Jan-1999 Silvia Tentindo-Repond, Brian Connolly Florida State University ---------------------------------------------------------------------------- ABSTRACT - We review the existing information about data inputs to the L2 STT trigger card coming from the SMT front end. We specify the data flow from the SVXII chips to the L3 and MCH, through the SEQUENCER , the VRB and VBD path. We focus on the data flow after the SEQUENCER through the passive splitters to the VTM and then to the STT trigger card, and we define the consequent format of the data buffer. The finality of this study is to provide the FPGA Cluster Finder in the L2 STT Trigger Card with the needed input specifications. ----------------------------------------------------------------------------- 1. GENERAL The STT preprocessor in Level 2 receives input from two separate streams: the data from the Silicon Microstrip Tracker detector (SMT) AND the data from the Fiber Tracker (CFT) Level 1 Trigger. Both inputs are needed for STTpp to be able to accomplish his task of associating 'tracks' seen in the SMT detector with tracks reconstructed in CFT. Of course STT must reconstruct SMT 'tracks' first, by finding clusters and hits and fitting them into tracks. We concentrate on the data stream coming from the SMT detector, our primary task being to design and make operational the Cluster Finding Card in the STT Trigger Card, that needs these data as input to calculate Clusters and hits. 2. DATA FROM SMT DETECTOR into SEQUENCER Data from the SMT detector are collected at the Front End in SVXII chips. Data from each silicon ladder come in 8-bit words of channel address and channel signal alternated. There are 128 channels per SVXII chip. If the SVX is in 'zero-suppress' mode, only channels above pedestal are readout. Data from SVX are sent to a SEQUENCER via copper cable. There are 8 copper cables per SEQUENCER, and, per each cable, data are sent in form of 8 bit words every 18 ns ( 53 Mb/s). Each cable accepts from 3 to 9 chips maximum. During the readout (Ref.1) of the SVX chips, the 8 bits of data from each of 2 HDIs (flex circuit on which chips are mounted) is strobed into the FIFO memories of the SEQUENCER, and almost immediately readout into a G-Link Transmitter chip, at a rate. The FIFO memories accept only 16 bit data. Into the G-Link trasmitter, data are serialized from 16 bit to 1 bit, and the resultant serial si- gnal is fed into a laser optical driver, at a rate of 1.062 Gb/s ( 16 * 53 Mb/s), and from there data are sent to the VRB. 3. SEQUENCER Cards The SVX SEQUENCERs (Ref.1) make up the interface to the SVX chips in both the Silicon detector and the Fiber Tracker. They receive commands derived from the Serial Command Link and form the control signals necessary to run the SVX chips, moreover they route the data to the VRBs in the Counting House. There will be about 140 Sequencers in a total of eight crates located in the detector platform. Since they are located in an interlocked area, special diagnostic features are designed to isolate problems. 4. DATA from SEQUENCER to L3 A 160 ft fiber carries the signal out the front panel of the SEQUENCER card and to the VRB's in the MCH (Moving Counting House). Four such links emerge from each SEQUENCER, each VRB accepts four fiber links. The data stream recovered by the VRB consists of 8 bit words IN SUCCESSION. A VME Backplane connects the VRB (VME Readout Buffer) and VBD (VME Buffer Driver). Data are then sent via cable to L3 and from there to permanent storage. 5. GENERAL BLOCK DIAGRAM FOR DATA FLOW TO L3 AND MCH 8 bits 53 Mb/s 1 Gb/s /------\ | | | SVX |__ | | | | | | | \------/ | V V | | 8 bits 16 bits 1bit /------\ | /---------\ /--------\ | SVX | -----------|SEQUENCER|_______________| VRB |___ | |-------------| | | | | \------/ \---------/ \--------/ | . TOTAL: TOTAL: | | . 8 copper cables 4 optical fibers | | . | | . | |VME | |backplane /--------\ | | VBD |___| \--------/ TOTAL: | 8 SVX chips |data cable (4 pairs of HDI's) | /-------\ | L3 | \-------/ 6. DATA STRUCTURE TO L3 Every component in the data flow adds up one Header into the structure of the data buffer: SEQUENCER Header, VRB Header, VBD Header. At the end of each SEQUENCER there is also a SEQUENCE Trailer. (It is needed for reasons that we will discuss later, see VTM card). Remark that the "Channel" in the VRB Header refers to the 8 'Channels' i.e. strings of fiber optic cable that are fed into each SEQUENCER, wherever "CH" in the Chip 1, Chip 2, etc. buffers refers to the real ADC channels in the Silicon detector ? \ VBD Header / Byte count Total 8 \ 00 | Event # | Status 0 | Status | Channel 0 Byte Count | VRB Header " 1 " " | " 2 " " | " 3 " " | " 4 " " | " 5 " " | " 6 " " | " 7 " " / SEQ ID \ Sequencer Header HDI & SEQ STATUS / CHIP ID \ 00 | CH=03 | Chip 1 DATA | CH=5C | DATA / CHIP ID \ 00 | CH=0 | DATA | CH=1 | Chip 2 DATA | CH=7E | DATA | CH=7F | DATA / C0 \ Sequencer trailer C0 / 6.1 SEQUENCER's Data Readout HEADER The SEQUENCER ID is a number from 0 to 255; there will be 140 total SEQUENCERS in the detector. After the Sequencer ID, the next byte is defined, starting from the MSB, as follows: Downloaded Status bit 2 Downloaded Status bit 1 Downloaded Status bit 0 Control Link No_Synch Control Link Parity Error HDI # bit 2 HDI # bit 1 HDI # bit 0 The Downloaded Status bits are provided for general use and are set via 1553. The three HDI # bits are numbered 0-7 and are associated with the cables connecting to the HDI interface Modules as follows: 0 A half of top cable (WRT Sequencer Backplane) 1 B " " " 2 A " second " 3 B " " " 4 A " third " 5 B " " " 6 A " bottom " 7 B " " " 6.2 SEQUENCER's Data Readout TRAILER The Trailer for each HDI data stream will be hex C0 and will be appended to the data immediately, following the last data byte of the last chip on its HDI. The forced readout of channel 127 of the last chip on each HDI (a feature of the SVX2E chip) will not be used; the option to use this feature, however,still exists. It is also assumed that no chip will never have ID=C0. 6.3 REMARK The information we are interested from par. 6.1 and 6.2 limits to the HDI # . 6.4 REMARK In the VRB Header, Byte count total refers to how many bits the VRB is counting 9 could be 8 or 16 or 32. In the same VRB Header, the Event # information is provided to the VRB by the Serial Command Link. Note that this info is probably provided by the SCL also to all the single components of the Trigger System. 7. DATA TO L2 STT TRIGGER CARD When data come out of the SEQUENCER, passive splitters in the fibers allow the same signal that goes to the VRB to be trasmitted to a VTM ( VME transition module ), and from there to the L2 STT Trigger Card. (Ref.2). - Each VTM accepts 4 fibers ( and each fiber carries data from two detectors) -. The data are digitized into a FIFO whenever they are received, and are made ready for the Cluster Finder based on an FPGA processor that will process the data. 8. VTM ( VME TRANSITION MODULE ) The role of VTM is to receive the serial data from the SEQUENCER and to convert them to parallel. Its function is also to trasform the optical signal received from the SEQUENCER, through optical fibers, back to electronic signal. It feeds the 4 serial receivers to the J3 connector of the Backplane (of the STT Card ?). In the data stream, it reads the data buffer, looks for the SEQUENCER's trailer, and ignores all after that. (Ref. 3) 9. GENERAL BLOCK DIAGRAM FOR DATA FLOW TO L2 STT 8 bits 16 bits 1 bit /------\ /---------\ /--------\ | SVX |_________|SEQUENCER|_________________| VRB | | | | | | | \------/ \---------/ | \--------/ | | | | | | | | /---------\ | VTM | | | \_________/ | | | /-------------------\ | STT Trigger Card | | | | /------------\ | | |Cluster | | | | Finder FPGA | | | \------------/ | \____________________/ | | 10. DATA STRUCTURE TO STT TRIGGER CARD As already remarked before, every hardware component in the data flow adds up one Header into the structure of the data buffer: SEQUENCER Header, VRB Header, VBD Header. In the data flow from SVX to STT, there is so no VRB and no VBD Header. Besides, given the role of VTM, who is only a receiver, no Header is added up from VTM. So the final data structure seen as input to STT Trigger Card is going to be as follows: SEQ ID \ Sequencer Header SEQ STATUS / CHIP ID \ 00 | CH=03 | Chip 1 DATA | CH=5C | DATA / CHIP ID \ 00 | CH=0 | DATA | CH=1 | Chip 2 DATA | CH=7E | DATA | CH=7F | DATA / C0 \ Sequencer trailer C0 / Question remains open: from where is STT going to get the information of the Event number, Status, and Total bit number that is provided in the VRB Header for the Normal (to L3) data stream. ** The Sequencer's trailer could effectively be used for 'end of event', but w'll probably need the Event # information anyway. 11 . CONCLUSIONS The FPGA processor in the STT Trigger Card, will receive SMT data in the format described in sect.10 of this report. The VTM module will provide them in form of 16-bit words. From there on, FPGA will process these data by appluing the clustering algorithms (Ref.4) that will provide STT clusters and hits to the following units : - the Track Fit Card in the L2 STT Trigger Card - the L2 CFT preprocessor and - L3 REFERENCES REF.1 - Mike Utes - "SVX Sequencer Board" D0 Engineering Note 3823.110-EN480 11/18/98 REF.2 - ' A Silicon Track trigger for the D0 Expt in Run II - Proposal September 22,1998 . D0Note 3516 REF.3 - Mark Bowden, "VTM" private communication REF.4 - Ulrich Heintz "Cluster Centroid Algorithm for STT" D0Note 3421 - 28 Oct 98 - From SILVIA@d0fsub.fnal.gov Wed Feb 17 16:21:34 1999 Date: Tue, 16 Feb 1999 16:24:16 -0600 (CST) From: "Silvia Tentindo-Repond @D0" To: WAHL@d0fsub.fnal.gov, HARRY@d0fsub.fnal.gov Cc: SILVIA@d0fsub.fnal.gov Subject: clustering, new vsn Resent-Date: Tue, 16 Feb 1999 17:24:57 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl DESIGN STUDIES FOR THE CLUSTER ALGORITHM IN THE SILICON TRIGGER CARD OF STT L2 STR, 15-FEBRUARY-1999 ______________________________________________________________________________ ABSTRACT In a previous note (D0NOTE 3599) we investigated about the format and rate of the data in input to the STC (Silicon Trigger Card) of STT L2. This information was essential for beginning studies about designing a Clustering Algorithm for the FPGA of the STC. In the present study a model is described of accessing the data from the SMT front end into STC, calculating cluster centroids 'on fly' into the FPGA units of STC, and buffering centroid information to the Road Cards and to the Track Fitting Cards of the STC . Its feasibility, especially the time constraints, has taken into account the results obtained from preliminary tests on FPGA's prototypes. _____________________________________________________________________________ 1 - DATA FLOW There should be one Cluster Finder unit (FPGA) for each optical fiber cable coming from the SEQUENCER ( and from VTM ) into the STC (Silicon Trigger Card) of STT. There are four optical cables per each SEQUENCER. - For more details, see D0NOTE 3599, Ref.1 -. Each optical fiber sends the data from up to 2 HDIs ( from 3 to 9 SVX chips for each HDI ), that are read out at a rate of two 8bit words ( channel address and channel content) every 37.6 ns. The Cluster Finder FPGA must so be able to calculate clusters at a cycle of 37.6 ns - on each optical fiber -, since every 37.6 ns a new pair of channel address and channel content words comes as input to FPGA. 2 - FPGA's PROTOTYPE TESTS Tests have been made (Ref.2) that a prototype FPGA has been able to perform all the operations required by clustering ( including the time consuming di vision through a look-up table and possibly by use of pipelining ) in the required time interval of two clocks (18.8 ns each clock). 3 - OCCUPANCY The present time constraint of 37.6 ns should then be partially 'released' by occupancy considerations : to each Cluster Finder FPGA there are up to 2 HDIs connected, and the average expected occupancy calculated from simu lation happens to be about 5%. The incidence of two contiguous clusters is so extremely low. Tracks crossing a wide angle or delta rays could also be the case of 'multiple clusters' or clusters of size bigger than normal. A normal size for a cluster (from MC data and Test Beam data, is 2.5 to 3 strips ). More details about occupancy are given in sect. 9... 4 - WHAT KIND OF CLUSTERS ?....... Here is a simple sketch of clusters configurations that we will be required to deal: 2 STRIPS SIZE CLUSTER : - - _ _ <-------- 2 ADC counts _ _ above pedestal _ _ _ _ _ _ _ _ <______ pedestal ---------------------- 4 STRIPS SIZE CLUSTER : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------- -------------------------- MORE THAN 4 STRIPS CLUSTERS : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ----------------------------------- ---------------------------------- Special cases are spurious signals ( isolated channels with ADC count above a given threshold or noise ) , or very wide clusters ( from delta rays or tracks crossing at wide angle ). 5 - DESIGN FOR THE CLUSTERING ALGORITHM The considerations, results and constraints described in sect. I , II and III, became compatible with the following sequence of logic steps that a Cluster processor should include: * step 0 - read and save locally the EVENT NUMBER information (it should be provided to STT anyway from TCC or similar, as well as to all the Trigger components) read and save locally the SEQUENCER Header information: HDI NUMBER * step 1 reset event counters ( like PED (Pedestals count), SEED, ID1 , ADC1 etc, see below) ________ > loop over data readout ** if channel address = C0C0 , then it is end of event, set EOE = 1. Otherways, EOE = 0. This info is sent by the SEQUENCER Trailer. * step 2 - read channel address (ID1). Save address as SEED for the cluster rename channel address as 1 ( 1 gives the relative position of strip inside cluster) * step 3 - read channel content. If < pedestal, increment PED, goto step 1. If > Pedestal, save channel content in ADC1 * step 4 - for the NOMINATOR, create element of SUM, N_1 , i.e. MULTIPLY N_1 = ID1 * ADC1 SUM NOMINATOR N = N_1 * step 5 - for the DENOMINATOR, create element of SUM, D_1 i.e. D_1 = ADC1 SUM DENOMINATOR D = D_1 * step 6 - DIVIDE N / D * step 7 save result of division in temporary Buffer 'CENTROID' = N / D ----------- > next data readout step 2 - read channel address. step 2' - check that channel address is adjacent to SEED . If not adjacent, set flag END_OF_CLUSTER. Goto End_of_Cluster If adjacent to seed, set ID2=2 step 3 - read channel content. If < Pedestal, increment PED, goto End_of_Cluster If > Pedestal, save channel content in ADC2 step 4 - for the NOMINATOR,create element of SUM, N_2 : i.e. MULTIPLY N2 = ID2 * ADC2 SUM NOMINATOR N = N_1 + N_2 step 5 - for the DENOMINATOR, create element of SUM, D_2 : SUM DENOMINATOR D = D_1 + D_2 step 6 - DIVIDE N / D step 7 - save result of division in temporary buffer 'CENTROID' = N / D __________________ > next data readout ............................ End_of_Cluster go here if cahnnel address is not 'adjacent' to SEED means that the 'old' cluster has ended, so it is time to step 8 - convert CENTROID 'relative' position ( from 1 to 4 is the relative position of the centroid in the cluster) into channel address CENTROID ADDRESS step 9 - SAVE CENTROID Information: * CENTROID NUMBER in EVENT * CENTROID SIZE * CENTROID ADDRESS = N / D * SEED * send EOE (End_of_Event) if EOE = 1 step 10 - SEND CENTROID Information to ROAD Card Reset local buffers- back to step 1 - End_of_Event If EOE = 1, then same as for End_of_Cluster, plus send END_OF_EVENT Info: PED = Pedestals count NOISE = Noisy channels count NCLUSTERS = Number of attempted Clusters NCENTROIDS = Number of found Clusters .... etc 6 - GENERAL ALGORITHM The position of the center of gravity of a cluster as calculated in sect. V does satisfy the time constraints and the data flow configuration typical of STT . A more general expression for what calculated above is described by : sum_i ( ADC_i * CHID_i ) CENTROID = ___________________________ i = 1,n sum_i ADC_i There is no constraint on the maximum number of strips n a cluster may have. The formule in the previous section allows to calculate the same value of center of gravity 'on the fly'. 7 - GENERAL CONSIDERATIONS. The sequence described in sect. IV should be general enough to account for all the possible configurations of clusters. Special kind of clusters are: 1- ONE STRIP size : it could be a spurious. In that case his ADC value could be used to identify it as noise, and count it down, the same way Pedestal channels are counted down 2 - TWO to FOUR strips size : normal size for cluster coming from one track at normal angle of incidence 3 - MORE than FOUR strips size : one track at high angle or delta ray or more than one track at normal angle. In case 3, all that could be done at this stage is to provide the track fitting stage with the info that more than one track " is possible". The cluster size information ( > 4 strips) would provide that information. In shch cases, that centroid position is anyways mismatched. For delta rays, the size of the cluster tends to be even bigger. It would be wise to set a max cluster size to cut delta rays. Unless we decide to use a much more refined algorithm,clusters of size bigger than 4 strips will produce anyway the wrong value for the cen troid position. 8 - Further remarks - A - For how the hardware readout is configured, there should not be any case of 'crossing' clusters, i.e. sequence of strips that belong to two different chips, or two different sequencers, or two different crates. The probability that the same track crosses two different PHYSICAL sectors is very low (from MonteCarlo results), and has been disregarded in the design. The probablilty that the same track belong to two different HARDWARE units is ( as far as I know) inhibited. B - There are several tasks that have been assigned to STC and here we briefly summarize them: 1 - Process data from all barrel sections of an azimuthal sector in one crate 2 - accept Glink input from SMT portcards 3 - correct SMT for pedestals, gains, mask out bad channels 4 - find hit clusters in SMT data 5 - convert cluster positions to hit coordinates, allowing for alignment corrections 6 - buffer cluster and road information for transmission to L3 Out of the tasks listed above, some may be impossible to be done because of time constraints, and we want just mention that may be task 3 belongs to that category. Only real tests with a prototype FPGA and simulated events will give the needed answer. Task 5 has been under discussion recently, and it may well be that it will be done at level of TFC (Track Fit Card ), where it could be done through a look-up table and on-the-fly. More in general, it should not be forgotten to pay attention since now to the quantities that we would like to use for monitoring ( and debugging) purposes. For example some special characteristics of clusters could be used to dire ctly give a measure of performance and efficiency of STT or to detect problems and diagnostic the sources. 9 - Note on typical occupancy From Meena's note : MULTIPLICITY of clusters per 30 degrees sector per layer : (ex. layer 3, inner barrel) AVG RMS -------------------------------------------------------------- 8 interactions-minimum bias events- 4.6 3.7 1 interaction " " " 1.0 1.5 Zto bb + 2int. 2.7 2.5 Zto bb + 5int. 4.6 3.1 MULTIPLICITY of strips per cluster : 2.5 to 3 10 - Note on HARDWARE segmentation ONE CRATE ( 60 deg sector ) = 12 SEQUENCERS ONE SEQUENCER = 8 HDIs ONE HDI = from 3 to 9 SVX chips ONE chip = 128 channels = 64 strips = 1/4 barrel layer --------------------------------------------------------- ONE layer (barrel) = 256 (50microns) strips ONE strip = 2 channels ( ONE Address ; ONE ADC Count )