From evans@nevis1.nevis.columbia.edu Wed Feb 17 16:13:14 1999 Date: Tue, 16 Feb 1999 13:15:40 -0500 From: Hal Evans To: Meenakshi Narain Cc: "J. Linnemann" , meena@d0sgim.fnal.gov, wahl@fnal.gov, John Hobbs , Ulrich Heintz Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) Resent-Date: Tue, 16 Feb 1999 13:16:34 -0500 (EST) Resent-Date: Tue, 16 Feb 1999 12:15:53 -0600 (CST) Resent-From: wahl@FSHEB1 Resent-From: WAHL@D0GS01.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 Hi, I don't remember what my concern with the CPS information was either... And I agree with Meena that it shouldn't be a big problem to accommodate. Hal ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v | Hal Evans | | evans@nevis1.columbia.edu | | Physics Dept. Nevis Labs | | Columbia University PO Box 137 | | 550 W 120th Mailcode 5215 136 S Broadway | | New York, NY 10027 Irvington, NY 10533 | | Tel: (212)854-3334 (914)591-2815 | | Fax: (212)854-3379 (914)591-8120 | v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ On Tue, 16 Feb 1999, Meenakshi Narain wrote: > Jim, > > As far as I understand we can include the CPS information as well another > 2bits for Cutts for dE/dx information. So the REQUESTED data transfered by > now out of the STC will be more than 32 bits out of the STC to the TFC. > I think > the input from FRC card (ie info from CFT) is currently planned to be > 24 bits, we can easliy add 4 more bits for that and extend it to 28 bits. > This can be done both via the J3 backplane OR with a point-to-point link, > which we will talk about on Friday. I'm not usre of Hal's concern here - > it will hopefuly be part of Friday's discussion > > ie carrying CPS info in and out of STT is doable... > > Regards, Meenakshi > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Fine with me, I am comfortable with the bus definition not being frozen > > yet--but I had gotten resistance from Hal about carrying along 4 extra bits > > for CPS information, so perhaps I had the impression that things were firmer > > than they are in fact. > > > > I am concerned about the pin count, since it may be a real constraint on > > what can be done on the backplanes. > > > > Jim > > > > -----Original Message----- > > From: Meenakshi Narain [mailto:meena@d0sgim.fnal.gov] > > Sent: Tuesday, February 16, 1999 9:07 AM > > To: Horst D Wahl > > Cc: Hal Evans; Ulrich Heintz; John Hobbs; Meenakshi Narain; > > linnemann@pa.msu.edu > > Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) > > > > > > > > > > Horst and Jim, > > > > I think it is vcery premature to count J2/J3 backplane pins. > > At least for the STC we have come up with different solutions > > than the bus (in order to address some of Sippach concerns). > > We will present the ideas we have developed here at BU at > > the Nevis meeting. > > > > I think that is the purpose of the meeting.... > > > > I know that Jim spoke to Ulirch about the yesterady and I would > > liek to echo to him the same comments - we did some backplane pin > > counting last year - at the July workshop or earlier. At that time > > we concluded that there were enough pins for the J3 backplane. Since > > then and in the last two weeks we have different suggestions to pass > > around data - which could eliminate some buses. > > > > So, my request is: can Jim hold off on this until until the meeting, > > after all we are going there to work - isn't it? > > Regards, Meenakshi > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > Date: Mon, 15 Feb 1999 18:23:16 -0500 > > > From: "J. Linnemann" > > > To: wahl@fnal.gov > > > Subject: FW: stt backplanes > > > Resent-Date: Mon, 15 Feb 1999 18:17:14 -0500 > > > Resent-Date: Mon, 15 Feb 1999 17:13:37 -0600 (CST) > > > Resent-From: wahl@FSHEW8 > > > Resent-From: WAHL@D0GS01.FNAL.GOV > > > Resent-To: wahl > > > Resent-To: wahl@fsheb2 > > > > > > > > > > > > -----Original Message----- > > > From: Jim Linnemann at MSU (517) 355-3328 [mailto:LINNEMANN@pa.msu.edu] > > > Sent: Monday, February 15, 1999 3:59 PM > > > To: LINNEMANN@pa.msu.edu > > > Subject: stt backplanes > > > > > > > > > MSU 517-355-3328, > > > 15-FEB-1999 > > > > > > Horst, > > > > > > I was quite unclear on the proposed location in the present L2STT > > design > > > of the various busses. Could someone look at the available pins on J2 > > > (after > > > standard pins) and on J3 (after VTM and grounding) and assure me that > > there > > > are sufficient signals and grounds available for the busses contemplated? > > > > > > Jim > > > > > > From wahl@sg1.hep.fsu.edu Wed Feb 17 16:13:30 1999 Date: Tue, 16 Feb 1999 13:06:15 -0600 (CST) From: Horst D Wahl To: Bram Dwijngaard , Brian Connolly , Dan Karmgard , Frederic Stichelbaut , Graham Wilson , Hal Evans , Harrison Prosper , Horst D Wahl , John Hobbs , Meenakshi Narain , Paul Balm , Sijbrand de Jong , Silke Duensing , Silvia Tentindo-Repond , Simon Foo , Stephan Linn , Susan Blessing , Terry Wyatt , Ulrich Heintz , Wendy Taylor Subject: L1CFT Output format (fwd) (from Dave Toback) ---------- Forwarded message ---------- Date: Tue, 16 Feb 1999 12:58:22 -0600 (CST) From: Dave Toback To: "Horst D. Wahl" Cc: Gerald Blazey Subject: L1CFT Output format Hi Horst, I've tried to put down the basic arguements for the various L1CFT output format into a document. This issue has simmered for a while and we really should try and settle it. The three proposals are A and H, H and Pt, and a hybrid. I didn't include the option which is to cut at L1 on different values than we send to L2. My understanding is that this was an idea that was floated by Fred, but since it was never really thought of as being easily feasible it is no longer being actively considered. I should also mention that Marvin and I had talked about an A and PT proposal, but I haven't heard from him in a while. He mentioned that if the new boards split up the right way this becomes an option in a way that didn't use to be feasable. There certainly have been a number of studies about the effects of the different proposals at L1 and L2 and some attempts to try and quantify the effective road widths and efficiencies for these methods. Have you confirmed that the H and Pt does in fact give you wider roads and reduced efficiency? If the loss is intolerable does the hybrid solution meet your needs? Hopefully, putting down the arguements will enable us to try and find a way to put this question to rest. Comments? Thoughts? Thanks, Dave ************************************************************************** The old Format (what most people remember, A and H format): FE_board Number (0-79) H layer fiber number (0-43) Offset (0-15) Sign (0-1) This information is equivalent to passing the A and H layer hit information. Advantages: 1) Some studies have shown that this method defines a good road width in the SMT. 2) The STT algorithms are simplified. Also, well studied. Disadvantages: 1) To decide if a track passes a trigger threshold, it must be in a trigger bin. These are defined by offset. => Fixed turn on curves (can only group offsets) => Slow turn on curves (see plot) 2) The Pt is not a function of Offset. Said differently, a track with offset of 7 may have a higher Pt than a track with an offset of 8 and vice versa. This causes (not unsurmountable) sorting problems in L2CFT. 3) Because we only look at tracks with Pt>1.5 GeV, the largest offset used is 13. Thus, we loose two bits off the 4 bit full scale. ******************************* H and PT proposal: Sort the equations at L1 and make the trigger thresholds (bins) by Pt rather than by offset. Send Pt and H information to L2. Advantages: 1) Significantly sharpens the L1 threshold turn-on curves (See plot) 2) Allows us to dial the location of the turn on curves 3) The 4 threshold bins would be indicated by the two most significant bits of PtWord. The output from the concentrator more closely resembles the L1 decision and algorithms. 4) Sorting by PtWord in L2CFT is the same as sorting by Pt. This helps L2CFT. 5) The information sent to L2CFT is already sorted in the first two bits. Thus, only the lower bits need to be sorted. This significantly reduces the sorting time in L2. 6) The number of tracks per bin are more equitably spaced and again help the sorting. Disadvantages: 1) Makes the L2STT algorithm (potentially) more complicated 2) May make the road width larger (studies still in progress). This is very dependent on the number of different bins allowed (4 bits vs. 6 bits). Comparison to A-H method: To compare the Pt-H and A-H methods, we have tried to quantify the discussion by comparing the road widths at the A layer. In the A-H method, the A-H method the road width is, by definition, 1 fiber width. In the Pt-H method, the road width is not as well defined. For a given track, when all 8 hits are used in a full track fit, the routines return a range of Pt's which when averaged and combined with the H information uniquely specify a location in the A layer. Studies comparing this position to the true position (i.e, DeltaPhi(Pred-True)) yields a gaussian with an RMS of about a 1/4 of a fiber width. This makes sense since using more fiber information should yield a better estimate of where the track went through the A layer. However, to be fully efficient, one must integrate the full gaussian and to be 100% efficient requires going to almost a full fiber width (Marvin tells me that by removing the low probability tracks from the list we can reduce the tails of this distribution). Finally, the real problem is that we do not get the best information (i.e, the equation number or pt ranges) from the tracker, rather for every track the Pt equations are grouped. The equations in each group determine both the RMS and the tails of the road width. On average it is better than for A-H, but to be 100% efficient the road width can be worse (depending on the Pt binning). ***** Hybrid proposal: Since the road width problem appears to be mostly for low Pt bins, we could use a hybrid system. A-H for low Pt, H-PT for high Pt. Advantages: 1) Allows us to use PT for high PT where the trigger decisions are made (gives sharper and adjustable turn on curves). 2) Potentially allows A-H road width for where the most tracks are for L2STT. This may be an advantage (studies still in progress). 3) Allows a single method for when the L2STT is in the system and when it is not. Disadvantages: 1) 5 years from now it will be hard to remember what the Pt is given a value of 0010 in the "PT word". 2) It's not clear we need it. We wouldn't use this if the STT weren't there. Fred's current proposal is to make the Pt information come in 6 bits: 2 bits to denote the threshold bin and 4 bits to denote the Pt value within the bin. This would work by sorting the equations first into the four Pt threshold bins by Pt value, and them sorting the maximum and high bins by Pt value within each threshold bin. To satisfy the requirements of the STT it looks like we must sort the medium and low Pt threshold bins by offset value. Extending the Pt index from 4 to 6 bits gives us 16 possible bins within each Pt threshold bin. But we will keep the total number of bins to 16 and will use the extra bits to allow us to distribute those bins anywhere within the 4 Pt threshold bins. We can only assign indexes to the tracks once, so the scheme needed for STT and L2CFT must be the one used for L1Muon. From evans@nevis1.nevis.columbia.edu Wed Feb 17 16:14:34 1999 Date: Mon, 22 Jun 1998 08:25:28 -0400 (EDT) From: Hal Evans To: STTpp Group -- John Hobbs , Hal Evans , Meenakshi Narain , Ulrich Heintz , Horst Wahl Subject: RE: RESQ cross-checks (fwd) Resent-Date: Mon, 22 Jun 1998 8:24:58 -0400 (EDT) Resent-From: wahl@FSHEB1 Resent-To: wahl Hi Everyone, In case you're interested - here is Jim Linneman's response to my question about cross-checks that have been done to test the validity of RESQ.... Hal ---------- Forwarded message ---------- Date: Fri, 19 Jun 1998 22:58:36 -0400 From: "Jim Linnemann at MSU (517)355-3328" To: evans@nevis1.nevis.columbia.edu Subject: RE: RESQ cross-checks MSU 517-355-3328, 19-JUN-1998 The checks on RESQ are of two kinds 1) simple models for which closed-form solutions exist. it's fine within limits of MC accuracy BUT be sure to let it equilibrate before using the results Jay used several sets of 100K events and looked for stability 2) the most disgusting result we'd had was that of the behavior of a farm with the requirement for serial reporting. Without serialization, deadtime was 3%; with serialization, the deadtime soared to 70%. I wrote a Fortran program to cross-check and got the same result. This is a situation too complex for standard closed-form solutions. 3) Intuition sucks with queueing theory, is my experience. Yes, there are simple things like you can't exceed the mean capacity, but things get very sensitive to tails, eg; huge difference between gaussian vs exponential vs hyperexponential in how close to nominal you can get. You can usually understand direction of effects if you ponder enough, but quantitative, you need the oracle. Jay used it pretty black-box; I did a bit better than he in guessing results, but got singed plenty of times. If you cannot prove an effect is irrelevant, it usually screws you. Your intuition in the form of combining "serial" and "parallel" stuff is pretty poor; I had a student do some studies but didn't put them out as a d0 note. 4) actual data: usually, things actually are worse than RESQ says because you always leave out some dirty details. You also never get the distributions you input right. We should talk some specifics of the results you find dubious. Jim --------------------------------------------------------------------------- > From: SMTP%"evans@nevis1.nevis.columbia.edu" 15-JUN-1998 08:45:51.00 > To: LINNEMANN > CC: > Subj: RESQ cross-checks > > Date: Mon, 15 Jun 1998 08:45:30 -0400 (EDT) > From: Hal Evans > To: James Linnemann > Subject: RESQ cross-checks > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Hi Jim, > > Can you tell me what kind of cross-checks have been made on the validity > of RESQ? Have its predictions been compared with Run I results? > > The reason that I ask is that I found a few of the results presented in > the STT meeting last Friday to be a bit counter-intuitive (not that > my intuition is to be trusted either!). No one at the meeting was able > to say to what extent we should believe the predictions though. > > Cheers - Hal > > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > | Hal Evans | > | evans@nevis1.columbia.edu | > | Physics Dept. Nevis Labs | > | Columbia University PO Box 137 | > | 550 W 120th Mailcode 5215 136 S Broadway | > | New York, NY 10027 Irvington, NY 10533 | > | Tel: (212)854-3334 (914)591-2815 | > | Fax: (212)854-3379 (914)591-8120 | > v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ > From LINNEMANN@pa.msu.edu Wed Feb 17 16:15:47 1999 Date: Wed, 11 Nov 1998 21:07:00 -0500 From: Jim Linnemann at MSU 355-3328 To: WAHL@fnal.gov Subject: L2stt output medium Resent-Date: Wed, 11 Nov 1998 21:06:49 -0500 (EST) Resent-Date: Wed, 11 Nov 1998 20:06:37 -0600 (CST) Resent-From: wahl@FSHEB1 Resent-From: WAHL@D0GS01.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 MSU 517-355-3328, 11-NOV-1998 Horst, We are ordering L2 parts for the L2 crates. It had been my understanding that the output of the L2STT would be cypress, not G-link. The difference is in the number of FIC's needed. It will not be very easy to order more FIC's, so we need to be fairly sure on this point. I believe the difference is the possible need for an output buffer in the L2STT processors, as the cypress outputs (16MB/s) are almost surely sufficient for the actual output bandwidth, provided they are buffered, but would have a longer transfer time that G-link, which MIGHT be able to run without buffering, but would require more FIC's at the L2STT input, particularly during the time we were doing the transition between the systems. Could you run this by the people thinking about the outputs? I had noticed the assumption of fiber outputs with some surprise in the PAC document... Jim From evans@nevis1.nevis.columbia.edu Wed Feb 17 16:16:03 1999 Date: Thu, 12 Nov 1998 09:40:20 -0500 From: Hal Evans To: James Linnemann Cc: STTpp Group -- John Hobbs , Dan Karmgard , Hal Evans , Meenakshi Narain , Ulrich Heintz , Horst Wahl Subject: Re: question from Jim Linnemann about L2stt output medium Resent-Date: Thu, 12 Nov 1998 9:42:00 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Hi Jim, Here are my thoughts on the suject of STT output format. First off, given the current CFT proposal of sending each STT crate (60 degrees) information from ~120 degrees of CFT tracks we get a maximum amount of data to transmit to CFTL2 (assuming that each 60 degree CFT sector can have a maximum of 48 tracks) of: (2 CFT 60 deg sectors) * (48 trk/sector) * (64 bit STT info/trk) = 6144 bits (max) Transfer over Cypress (16MB/s) would take ~50 us, however, we may go with more than one processor which would reduce this. Although this is a large number, my feeling from listening in on discussions of G-link technology is that including G-link transmitters in our system would give us more engineering headaches than it would save us in speed. I think that adding output buffering and perhaps more than one cypress transmitter per crate would be a much easier solution. I'll talk with Bill Sippach and Al Gara about this and get their views as well. Regards - Hal ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v | Hal Evans | | evans@nevis1.columbia.edu | | Physics Dept. Nevis Labs | | Columbia University PO Box 137 | | 550 W 120th Mailcode 5215 136 S Broadway | | New York, NY 10027 Irvington, NY 10533 | | Tel: (212)854-3334 (914)591-2815 | | Fax: (212)854-3379 (914)591-8120 | v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ On Thu, 12 Nov 1998, Horst D. Wahl wrote: > > > ---------- Forwarded message ---------- > Date: Wed, 11 Nov 1998 21:07:00 -0500 > From: Jim Linnemann at MSU 355-3328 > To: WAHL@fnal.gov > Subject: L2stt output medium > Resent-Date: Wed, 11 Nov 1998 21:06:49 -0500 (EST) > Resent-Date: Wed, 11 Nov 1998 20:06:37 -0600 (CST) > Resent-From: wahl@FSHEB1 > Resent-From: WAHL@D0GS01.FNAL.GOV > Resent-To: wahl > Resent-To: wahl@fsheb2 > > MSU 517-355-3328, 11-NOV-1998 > > Horst, > > We are ordering L2 parts for the L2 crates. It had been my > understanding that the output of the L2STT would be cypress, not G-link. The > difference is in the number of FIC's needed. It will not be very easy to > order more FIC's, so we need to be fairly sure on this point. I believe the > difference is the possible need for an output buffer in the L2STT processors, > as the cypress outputs (16MB/s) are almost surely sufficient for the actual > output bandwidth, provided they are buffered, but would have a longer transfer > time that G-link, which MIGHT be able to run without buffering, but would > require more FIC's at the L2STT input, particularly during the time we were > doing the transition between the systems. > > Could you run this by the people thinking about the outputs? I had > noticed the assumption of fiber outputs with some surprise in the PAC > document... > > Jim > From evans@nevis1.nevis.columbia.edu Wed Feb 17 16:16:18 1999 Date: Wed, 13 Jan 1999 08:48:32 -0500 From: Hal Evans To: "Horst D. Wahl" Subject: Re: STT, Sippach, SLIC Hi Horst, Bill has indeed been looking at the STT with an eye toward reusing parts of the SLIC to build some of the components. I had a long talk with him about it yesterday. He had made some incorrect assumptions about what data was needed to do the fits - which makes his original scheme (that you might have heard rumors about) unworkable. Nevertheless, it looks like we might be able to use some of the functional elements of the slic including their detailed layouts as elements of the stt. Specifically, the data busses and DSP sections of the slic could probably make our lives a lot easier in the stt. Bill and I are looking into this and should have something concrete to say by the beginning of next month - in time for the technical meeting. I'm also keeping in mind that this should not (and cannot) become a 'Nevis Only' project and will try to come up with a sensible division of labor if it turns out that Bill's proposal is a significant modification of what we already have. (To set your mind at ease, the changes we've talked about are not fundamental - so I think that this shouldn't be a problem.) Anyway, I certainly won't start making 'Modest Proposals' in the middle of the PAC preparations. A lot more thought needs to go into Bill's ideas before it would be useful to discuss them in a broader group. If questions about our agressive schedule come up during the PAC discussions though, I think that we can say that we are making strong efforts to reuse already existing components in our design to minimize the development time. I'll be at Fermilab late this afternoon - so we can talk more then. Regards - Hal ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v | Hal Evans | | evans@nevis1.columbia.edu | | Physics Dept. Nevis Labs | | Columbia University PO Box 137 | | 550 W 120th Mailcode 5215 136 S Broadway | | New York, NY 10027 Irvington, NY 10533 | | Tel: (212)854-3334 (914)591-2815 | | Fax: (212)854-3379 (914)591-8120 | v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ On Wed, 13 Jan 1999, Horst D. Wahl wrote: > Hello Hal, > > How are things at Nevis? I hear via the grapevine that Bill Sippach has > been studying the STT conceptual design, while also working on the SLIC. > In this context he apparently asked the question why one could not use the > SLIC in the STT. Have you had any discussions with him about the STT > lately? It would be very good to get more information from Bill about > his thoughts on this. In the interest of not distracting from the next > hurdle (i.e. PAC) I would urge you not to talk about this to anyone before > the end of the week. > > Regards, > Horst > From evans@nevis1.nevis.columbia.edu Wed Feb 17 16:17:04 1999 Date: Tue, 9 Feb 1999 11:54:28 -0500 From: Hal Evans To: Horst Wahl Subject: Thoughts from Nevis Resent-Date: Tue, 9 Feb 1999 11:55:26 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Hi Horst, Below is the summary of Bill Sippach's thinking about the STT. Could you send it along to the full STT mailing list? I see that it's now grown to huge proportions - and I don't want to leave anyone out. Thanks - Hal ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v | Hal Evans | | evans@nevis1.columbia.edu | | Physics Dept. Nevis Labs | | Columbia University PO Box 137 | | 550 W 120th Mailcode 5215 136 S Broadway | | New York, NY 10027 Irvington, NY 10533 | | Tel: (212)854-3334 (914)591-2815 | | Fax: (212)854-3379 (914)591-8120 | v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ ----------------------------------------------------------------------- Hi Everyone, Here's a brief review of the status of Bill Sippach's thinking about the STT. It's mainly a recap of what I said in the meeting on Friday, but I've also include some new thoughts and links to some useful documents. First off, I'll spell out what Bill (and I) see as his role in this period where he's been looking at the STT conceptual design. 1) Understand globally the system and its constraints. 2) Identify aspects in our design which are technically difficult or unfeasible. 3) Identify areas where time can be saved by reusing components that have already been laid out. A few comments on the above points. Part 1) is an ongoing process. Bill likes to do this by coming up with ideas and seeing if they match with the parameters and constraints of what we want. This means that a lot of the things he proposes will be wrong because he's still wading through the numerous data formats and requirements. Comments on anything below are therefore very helpful because while discussing these ideas with Bill, I can easily miss out on subtle points of STT or L2. Another thing that we are keeping in mind is that, while point 2) is crucial to come up with a working system in the end, point 3) is more tricky. It's certainly desirable to minimize the time to build the system, but we don't want to needlessly redesign for the sake of aesthetics. Bill is definitely sensitive to this - but keep in mind point 1). OK, with all that said, let's see what the current state of thinking is. The most serious issue Bill has identified is: i) Bussing data across the VME backplane at 40 MHz is extremely risky and probably unworkable. This is mainly a problem for the FRC-->STC road transfer and the STCs-->TFCs assoiciated hit transfers. Bill is working on the SLIC card which, at least functionally, is supposed to solve a similar problem for the muon L2 system. (In fact that's currently taking almost all of his time since Al Gara has left Nevis.) Briefly, the idea behind the SLIC is to do the following: a) Accept data on multiple input ports in Cypress Hotlink format. b) Put the data from all input ports onto a single bus which does point-to-point transfers of 32 data bits + controls at 40 MHz between buffers which allow the system to 'hold' if the data backs up anywhere. c) This transfer is controlled by FPGAs that attach routing information to the data indicating which of four processing DSPs is the destination of the data word. d) These DSPs are part of plug-in daughterboards that include an input fifo for data from the bus (80 MHz transfers of 32 bit words), serial inputs (for commands) and outputs (for processed data) and SBSRAM. e) The processing DSPs output their results via a serial output port (at 40 Mbit/s) to the data bus mentioned above. f) Finally a 5th DSP connected to the data bus does final processing of the data (either from the DSPs or raw data appropriately flagged) and sends the results off the board in hotlink format. There is a more detailed description of the SLIC including diagrams of the functional components in a talk by Mike Fortner at the recent L2 review. There's also a draft TDR for the SLIC. The urls for these are: http://niuhep.physics.niu.edu/~fortner/d0/trig/slic/slic_tdr.PS http://niuhep.physics.niu.edu/~fortner/d0/trig/slic/slic_review.PS Bill is currently trying to decide whether any parts of this system are appropriate for inclusion in the STT. He's thinking along the lines of an architecture where (nearly) interchangable blocks of data links and processor elements (like in the slic) do the job of the STT in two steps corresponding to two levels of boards as we've always assumed except that now the boards are built of the same basic elements: 1a) Cluster SMT Data b) Associate to Roads c) Normalize to physical space d) Route to proper processor 2a) Fit This has a few advantages: o A solution to the data link problem that is flexible and programmable through VME. o An canned desing for implementing the kind of DSP that is one of the options for the fit card - including power distribution, and communications with the outside world. o Worked out VME commuincation. Bill is coming to the conclusion that, at least for parts 1a) and b) the parallel FPGA solution may be optimal. But he still wants to think a little more about it. He's worried about the time taken by the fit processor (aren't we all) and thinks that it would be nice to do as much of its work as possible upstream - hence his suggestions for parts 1c) and d). There are (of course) some problems which mean that we won't be able to just simply take the existing design and rename it the STT. The basic worry is that the data path for the links described above is rather serial while we have always thought along the lines of parallelism. Whether the SLIC-type links can handle the STT bandwidth is the main thing we're looking into right now. Specific things that haven't been well thought-out and will certainly require redesign of SLIC components are: 1) The bottleneck in the SLIC bus is the serial port output from the DSP that runs at 40 Mbit/s. This is almost certainly too slow to allow the existing DSP daughterboard to be used as is in the TFC. There is the possibility of putting the DSP results out onto the data link by the normal DSP data lines (at 80 MHz for 32-bit words) but this hasn't been thought out. 2) The slic is currently designed to receive data in hotlink format on twisted pair cables. The L1CTT information and the data from the SMT come on G-link fibers which are converted to electrical signals by VTMs. We need to understand how to use signals from the VTM in any design we adopt. (And the slic can give us no help there). 3) Even the data link forseen for the slic may prove to be too slow since, although it runs at 40 MHz like our spec's, it must transmit data from several SMT fibers and the CFT roads. Something we need to think about here (and in any other design also) is how we plan to truncate SMT and L1CTT data for pathological events. 4) The interconnection of data is rather complicated here. We need to think out carefully how cable routing would be done to get the right data to the right place(s). That is more-or-less where we stand with things at Nevis. As you can see there are still a lot of troubling questions. I think that the strategy Bill is employing to solve them is a good one though: identify problem areas and see if solutions exist in things we already have experience with. Hopefully by the Engineering Meeting we will have made more progress on this. Please let me know if you have any comments and/or worries that I haven't yet thought about. Best Regards - Hal From hobbs@sbhep.physics.sunysb.edu Wed Feb 17 16:17:20 1999 Date: Wed, 10 Feb 1999 15:43:28 +0000 From: hobbs@sbhep.physics.sunysb.edu To: wahl@fnal.gov, uli@fnald0.fnal.gov, meena@fnal.gov, evans@fnal.gov Subject: Re: Thoughts from Nevis about STT design (fwd) (from Hal Evans) Resent-Date: Wed, 10 Feb 1999 15:45:07 -0500 (EST) Resent-Date: Wed, 10 Feb 1999 14:44:21 -0600 (CST) Resent-From: wahl@FSHEB1 Resent-From: WAHL@D0GS01.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 Hi Hal and all, Thanks for sending along Bill's thoughts. I'll present a summary of the various processing options at the meeting, and add a transparency about the coordinate conversion (since it's come up). While I don't really care where the coordinate normalization is done, there may be two reasons to postpone it to the fitting cards: (1) It probably can be done in a lookup table on-the-fly. I calculated something like 2-3 Mb of (fast) static RAM to perform the lookup for each sector. Thus, it has zero impact on the processing time and trivial cost (<$100/board). (2) In principle the look up could go either on STC or TFC (track fit). It seems to me that the TFC is more natural in light of our data-transfer problems because the physics coordiates are more bits than the basic cluster address we currently envisage sending. Also, one might conceivably form a pseduo-lookup (ala CDF) to get binned results. This look up could be performed using the original cluster address without any coordinate converstion. While I don't like this method as much as the fit, it does change the "coordinate" used in the "fitting". Of course, this may be a moot point if we would simply turn off the conversion upstream without causing an impcompatibility in the data transfer protocol. (3) On the other hand, I'll take as much real estate as I can get... The change to the Stony Brook budget is to (partially) accomodate the upgraded number of tracks coming from CTT level one. Given my calculations of board space and power consumption, I cannot see getting more than 16 processors on a single TFC. (I may be wrong. I'll go through this at Nevis in detail.) Given this, I have asked for enough money to build a 64 processor (four boards/crate) system. This would handle 64 tracks in the current model. Still not the 96 discussed at the colloboration meeting, but... This, of course, assumes that I can get two more slots in the crate. Finally, I was asked ages ago to give a lunch seminar at U of Chicago on STT. It's scheduled for Monday (I actually had forgotten until I got a reminder). I thought I'd pretty much stick to the material in the public presentations. I plan to avoid discussing the vertex z-postion stuff for a variety of reasons. Comments and suggestions are welcome... Regards, John From linnemann@pa.msu.edu Wed Feb 17 16:17:36 1999 Date: Mon, 15 Feb 1999 18:23:16 -0500 From: "J. Linnemann" To: wahl@fnal.gov Subject: FW: stt backplanes Resent-Date: Mon, 15 Feb 1999 18:17:14 -0500 Resent-Date: Mon, 15 Feb 1999 17:13:37 -0600 (CST) Resent-From: wahl@FSHEW8 Resent-From: WAHL@D0GS01.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] -----Original Message----- From: Jim Linnemann at MSU (517) 355-3328 [mailto:LINNEMANN@pa.msu.edu] Sent: Monday, February 15, 1999 3:59 PM To: LINNEMANN@pa.msu.edu Subject: stt backplanes MSU 517-355-3328, 15-FEB-1999 Horst, I was quite unclear on the proposed location in the present L2STT design of the various busses. Could someone look at the available pins on J2 (after standard pins) and on J3 (after VTM and grounding) and assure me that there are sufficient signals and grounds available for the busses contemplated? Jim From meena@d0sgim.fnal.gov Wed Feb 17 16:18:06 1999 Date: Tue, 16 Feb 1999 08:07:29 CST From: Meenakshi Narain To: Horst D Wahl Cc: Hal Evans , Ulrich Heintz , John Hobbs , Meenakshi Narain , linnemann@pa.msu.edu Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) Horst and Jim, I think it is vcery premature to count J2/J3 backplane pins. At least for the STC we have come up with different solutions than the bus (in order to address some of Sippach concerns). We will present the ideas we have developed here at BU at the Nevis meeting. I think that is the purpose of the meeting.... I know that Jim spoke to Ulirch about the yesterady and I would liek to echo to him the same comments - we did some backplane pin counting last year - at the July workshop or earlier. At that time we concluded that there were enough pins for the J3 backplane. Since then and in the last two weeks we have different suggestions to pass around data - which could eliminate some buses. So, my request is: can Jim hold off on this until until the meeting, after all we are going there to work - isn't it? Regards, Meenakshi +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > ---------- Forwarded message ---------- > Date: Mon, 15 Feb 1999 18:23:16 -0500 > From: "J. Linnemann" > To: wahl@fnal.gov > Subject: FW: stt backplanes > Resent-Date: Mon, 15 Feb 1999 18:17:14 -0500 > Resent-Date: Mon, 15 Feb 1999 17:13:37 -0600 (CST) > Resent-From: wahl@FSHEW8 > Resent-From: WAHL@D0GS01.FNAL.GOV > Resent-To: wahl > Resent-To: wahl@fsheb2 > > > > -----Original Message----- > From: Jim Linnemann at MSU (517) 355-3328 [mailto:LINNEMANN@pa.msu.edu] > Sent: Monday, February 15, 1999 3:59 PM > To: LINNEMANN@pa.msu.edu > Subject: stt backplanes > > > MSU 517-355-3328, > 15-FEB-1999 > > Horst, > > I was quite unclear on the proposed location in the present L2STT design > of the various busses. Could someone look at the available pins on J2 > (after > standard pins) and on J3 (after VTM and grounding) and assure me that there > are sufficient signals and grounds available for the busses contemplated? > > Jim From heintz@buphy.bu.edu Wed Feb 17 16:18:20 1999 Date: Tue, 16 Feb 1999 09:16:48 -0500 From: Ulrich Heintz To: Jim Linnemann Cc: Hal Evans , John Hobbs , narain@bu.edu, Ulrich Heintz , Horst Wahl Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) Resent-Date: Tue, 16 Feb 1999 9:17:33 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Dear Jim, Sometime last year I looked at the number of available pins on these backplanes. There is a 25-line TTL bus on the SVX-J3 backplane and there are any number of pins available on the J2 backplane. I don't know whether the TTL bus on J3 can be used at the speed we need. However a large fraction of the possible pins on J2 are unused by VME (80%?). We may have to design our own J2 backplane, but we could certainly fit the buses. There are many technologies in the discussion including not using a bus at all but point-to-point links. I hope that we will make some progress on this at the NEvis meeting. You can rest assured that we will count the pins before we build the thing. It just seems a bit premature right now, while we first need to fix the engineering design. greetings, Ulrich > -----Original Message----- > From: Jim Linnemann at MSU (517) 355-3328 [mailto:LINNEMANN@pa.msu.edu] > Sent: Monday, February 15, 1999 3:59 PM > To: LINNEMANN@pa.msu.edu > Subject: stt backplanes > > > MSU 517-355-3328, > 15-FEB-1999 > > Horst, > > I was quite unclear on the proposed location in the present L2STT design > of the various busses. Could someone look at the available pins on J2 > (after > standard pins) and on J3 (after VTM and grounding) and assure me that there > are sufficient signals and grounds available for the busses contemplated? > > Jim > From linnemann@pa.msu.edu Wed Feb 17 16:18:31 1999 Date: Tue, 16 Feb 1999 11:05:46 -0500 From: "J. Linnemann" To: Meenakshi Narain Cc: me , wahl@fnal.gov, hobbs@fnal.gov, heintz@bu.edu, evans@nevis1.columbia.edu Subject: RE: FW: stt backplanes (fwd) (from Jim Linnemann) Resent-Date: Tue, 16 Feb 1999 11:01:43 -0500 (EST) Resent-Date: Tue, 16 Feb 1999 10:01:02 -0600 (CST) Resent-From: wahl@FSHEB1 Resent-From: WAHL@D0GS02.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] Fine with me, I am comfortable with the bus definition not being frozen yet--but I had gotten resistance from Hal about carrying along 4 extra bits for CPS information, so perhaps I had the impression that things were firmer than they are in fact. I am concerned about the pin count, since it may be a real constraint on what can be done on the backplanes. Jim -----Original Message----- From: Meenakshi Narain [mailto:meena@d0sgim.fnal.gov] Sent: Tuesday, February 16, 1999 9:07 AM To: Horst D Wahl Cc: Hal Evans; Ulrich Heintz; John Hobbs; Meenakshi Narain; linnemann@pa.msu.edu Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) Horst and Jim, I think it is vcery premature to count J2/J3 backplane pins. At least for the STC we have come up with different solutions than the bus (in order to address some of Sippach concerns). We will present the ideas we have developed here at BU at the Nevis meeting. I think that is the purpose of the meeting.... I know that Jim spoke to Ulirch about the yesterady and I would liek to echo to him the same comments - we did some backplane pin counting last year - at the July workshop or earlier. At that time we concluded that there were enough pins for the J3 backplane. Since then and in the last two weeks we have different suggestions to pass around data - which could eliminate some buses. So, my request is: can Jim hold off on this until until the meeting, after all we are going there to work - isn't it? Regards, Meenakshi +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > ---------- Forwarded message ---------- > Date: Mon, 15 Feb 1999 18:23:16 -0500 > From: "J. Linnemann" > To: wahl@fnal.gov > Subject: FW: stt backplanes > Resent-Date: Mon, 15 Feb 1999 18:17:14 -0500 > Resent-Date: Mon, 15 Feb 1999 17:13:37 -0600 (CST) > Resent-From: wahl@FSHEW8 > Resent-From: WAHL@D0GS01.FNAL.GOV > Resent-To: wahl > Resent-To: wahl@fsheb2 > > > > -----Original Message----- > From: Jim Linnemann at MSU (517) 355-3328 [mailto:LINNEMANN@pa.msu.edu] > Sent: Monday, February 15, 1999 3:59 PM > To: LINNEMANN@pa.msu.edu > Subject: stt backplanes > > > MSU 517-355-3328, > 15-FEB-1999 > > Horst, > > I was quite unclear on the proposed location in the present L2STT design > of the various busses. Could someone look at the available pins on J2 > (after > standard pins) and on J3 (after VTM and grounding) and assure me that there > are sufficient signals and grounds available for the busses contemplated? > > Jim From meena@d0sgim.fnal.gov Wed Feb 17 16:18:55 1999 Date: Tue, 16 Feb 1999 11:32:03 -0600 (CST) From: Meenakshi Narain To: "J. Linnemann" Cc: meena@d0sgim.fnal.gov, wahl@fnal.gov, hobbs@fnal.gov, heintz@bu.EDU, evans@nevis1.nevis.COLUMBIA.EDU Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) Resent-Date: Tue, 16 Feb 1999 12:34:43 -0500 (EST) Resent-Date: Tue, 16 Feb 1999 11:34:02 -0600 (CST) Resent-From: wahl@FSHEB1 Resent-From: WAHL@D0GS01.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 Jim, As far as I understand we can include the CPS information as well another 2bits for Cutts for dE/dx information. So the REQUESTED data transfered by now out of the STC will be more than 32 bits out of the STC to the TFC. I think the input from FRC card (ie info from CFT) is currently planned to be 24 bits, we can easliy add 4 more bits for that and extend it to 28 bits. This can be done both via the J3 backplane OR with a point-to-point link, which we will talk about on Friday. I'm not usre of Hal's concern here - it will hopefuly be part of Friday's discussion ie carrying CPS info in and out of STT is doable... Regards, Meenakshi +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Fine with me, I am comfortable with the bus definition not being frozen > yet--but I had gotten resistance from Hal about carrying along 4 extra bits > for CPS information, so perhaps I had the impression that things were firmer > than they are in fact. > > I am concerned about the pin count, since it may be a real constraint on > what can be done on the backplanes. > > Jim > > -----Original Message----- > From: Meenakshi Narain [mailto:meena@d0sgim.fnal.gov] > Sent: Tuesday, February 16, 1999 9:07 AM > To: Horst D Wahl > Cc: Hal Evans; Ulrich Heintz; John Hobbs; Meenakshi Narain; > linnemann@pa.msu.edu > Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) > > > > > Horst and Jim, > > I think it is vcery premature to count J2/J3 backplane pins. > At least for the STC we have come up with different solutions > than the bus (in order to address some of Sippach concerns). > We will present the ideas we have developed here at BU at > the Nevis meeting. > > I think that is the purpose of the meeting.... > > I know that Jim spoke to Ulirch about the yesterady and I would > liek to echo to him the same comments - we did some backplane pin > counting last year - at the July workshop or earlier. At that time > we concluded that there were enough pins for the J3 backplane. Since > then and in the last two weeks we have different suggestions to pass > around data - which could eliminate some buses. > > So, my request is: can Jim hold off on this until until the meeting, > after all we are going there to work - isn't it? > Regards, Meenakshi > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > ---------- Forwarded message ---------- > > Date: Mon, 15 Feb 1999 18:23:16 -0500 > > From: "J. Linnemann" > > To: wahl@fnal.gov > > Subject: FW: stt backplanes > > Resent-Date: Mon, 15 Feb 1999 18:17:14 -0500 > > Resent-Date: Mon, 15 Feb 1999 17:13:37 -0600 (CST) > > Resent-From: wahl@FSHEW8 > > Resent-From: WAHL@D0GS01.FNAL.GOV > > Resent-To: wahl > > Resent-To: wahl@fsheb2 > > > > > > > > -----Original Message----- > > From: Jim Linnemann at MSU (517) 355-3328 [mailto:LINNEMANN@pa.msu.edu] > > Sent: Monday, February 15, 1999 3:59 PM > > To: LINNEMANN@pa.msu.edu > > Subject: stt backplanes > > > > > > MSU 517-355-3328, > > 15-FEB-1999 > > > > Horst, > > > > I was quite unclear on the proposed location in the present L2STT > design > > of the various busses. Could someone look at the available pins on J2 > > (after > > standard pins) and on J3 (after VTM and grounding) and assure me that > there > > are sufficient signals and grounds available for the busses contemplated? > > > > Jim > > From evans@nevis1.nevis.columbia.edu Wed Feb 17 16:19:13 1999 Date: Tue, 16 Feb 1999 13:15:40 -0500 From: Hal Evans To: Meenakshi Narain Cc: "J. Linnemann" , meena@d0sgim.fnal.gov, wahl@fnal.gov, John Hobbs , Ulrich Heintz Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) Resent-Date: Tue, 16 Feb 1999 13:16:34 -0500 (EST) Resent-Date: Tue, 16 Feb 1999 12:15:53 -0600 (CST) Resent-From: wahl@FSHEB1 Resent-From: WAHL@D0GS01.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 Hi, I don't remember what my concern with the CPS information was either... And I agree with Meena that it shouldn't be a big problem to accommodate. Hal ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v | Hal Evans | | evans@nevis1.columbia.edu | | Physics Dept. Nevis Labs | | Columbia University PO Box 137 | | 550 W 120th Mailcode 5215 136 S Broadway | | New York, NY 10027 Irvington, NY 10533 | | Tel: (212)854-3334 (914)591-2815 | | Fax: (212)854-3379 (914)591-8120 | v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ On Tue, 16 Feb 1999, Meenakshi Narain wrote: > Jim, > > As far as I understand we can include the CPS information as well another > 2bits for Cutts for dE/dx information. So the REQUESTED data transfered by > now out of the STC will be more than 32 bits out of the STC to the TFC. > I think > the input from FRC card (ie info from CFT) is currently planned to be > 24 bits, we can easliy add 4 more bits for that and extend it to 28 bits. > This can be done both via the J3 backplane OR with a point-to-point link, > which we will talk about on Friday. I'm not usre of Hal's concern here - > it will hopefuly be part of Friday's discussion > > ie carrying CPS info in and out of STT is doable... > > Regards, Meenakshi > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Fine with me, I am comfortable with the bus definition not being frozen > > yet--but I had gotten resistance from Hal about carrying along 4 extra bits > > for CPS information, so perhaps I had the impression that things were firmer > > than they are in fact. > > > > I am concerned about the pin count, since it may be a real constraint on > > what can be done on the backplanes. > > > > Jim > > > > -----Original Message----- > > From: Meenakshi Narain [mailto:meena@d0sgim.fnal.gov] > > Sent: Tuesday, February 16, 1999 9:07 AM > > To: Horst D Wahl > > Cc: Hal Evans; Ulrich Heintz; John Hobbs; Meenakshi Narain; > > linnemann@pa.msu.edu > > Subject: Re: FW: stt backplanes (fwd) (from Jim Linnemann) > > > > > > > > > > Horst and Jim, > > > > I think it is vcery premature to count J2/J3 backplane pins. > > At least for the STC we have come up with different solutions > > than the bus (in order to address some of Sippach concerns). > > We will present the ideas we have developed here at BU at > > the Nevis meeting. > > > > I think that is the purpose of the meeting.... > > > > I know that Jim spoke to Ulirch about the yesterady and I would > > liek to echo to him the same comments - we did some backplane pin > > counting last year - at the July workshop or earlier. At that time > > we concluded that there were enough pins for the J3 backplane. Since > > then and in the last two weeks we have different suggestions to pass > > around data - which could eliminate some buses. > > > > So, my request is: can Jim hold off on this until until the meeting, > > after all we are going there to work - isn't it? > > Regards, Meenakshi > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > Date: Mon, 15 Feb 1999 18:23:16 -0500 > > > From: "J. Linnemann" > > > To: wahl@fnal.gov > > > Subject: FW: stt backplanes > > > Resent-Date: Mon, 15 Feb 1999 18:17:14 -0500 > > > Resent-Date: Mon, 15 Feb 1999 17:13:37 -0600 (CST) > > > Resent-From: wahl@FSHEW8 > > > Resent-From: WAHL@D0GS01.FNAL.GOV > > > Resent-To: wahl > > > Resent-To: wahl@fsheb2 > > > > > > > > > > > > -----Original Message----- > > > From: Jim Linnemann at MSU (517) 355-3328 [mailto:LINNEMANN@pa.msu.edu] > > > Sent: Monday, February 15, 1999 3:59 PM > > > To: LINNEMANN@pa.msu.edu > > > Subject: stt backplanes > > > > > > > > > MSU 517-355-3328, > > > 15-FEB-1999 > > > > > > Horst, > > > > > > I was quite unclear on the proposed location in the present L2STT > > design > > > of the various busses. Could someone look at the available pins on J2 > > > (after > > > standard pins) and on J3 (after VTM and grounding) and assure me that > > there > > > are sufficient signals and grounds available for the busses contemplated? > > > > > > Jim > > > > > > From blazey@niuhep.physics.niu.edu Wed Feb 17 16:19:25 1999 Date: Tue, 16 Feb 1999 12:42:59 -0600 From: blazey@niuhep.physics.niu.edu To: evans@nevis1.nevis.columbia.edu, wahl@fnald0.fnal.gov Subject: Thoughts on Nevis report Resent-Date: Tue, 16 Feb 1999 13:44:22 -0500 Resent-Date: Tue, 16 Feb 1999 12:40:40 -0600 (CST) Resent-From: wahl@FSHEW8 Resent-From: wahl@D0GS01.FNAL.GOV Resent-To: wahl Resent-To: wahl@fsheb2 Hi Horst and Hal Thank you for sending me your "thoughts from Nevis". I hope my comments to follow will be helpful in sorting out possible options for the STT hardware. I think the FIC+SLIC combination provides adequate throughput and computing power for clustering and road association if we want to calculate impact paratmeters only. I think the FIC+SLIC combination is indequate if we want to include transmission of all clusters to L2 or L3. In other words the viabilty of the FIC+SLIC really depends on the scope of the STT. Let me outline my reasoning. Both items 3 and 4 in the last list of your note are solved by the FIC. The FIC has an onboard VTM which converts the L1CTT information into something a MBT or SLIC can accept. In fact the FIC was designed to solve just the problems cited in items 3 and 4. The FIC will also properly buffer transmissions from the SMT. To be fair one must worry about the robustness and format of the data transfer through the FIC, but my understanding is that this is not an insurmountable problem. Item 1 in the list is a problem if there is no data reduction in the current STT model. The SLIC should be sufficient for impact parameter calculation if there is data reduction. This would require reordering the tasks in the first list of your note to 1d (done by proper cabling and the SLIC FPGA) 1b (here is the data reduction) 1a (cluster around a road) 1c (normalize to physics coordinates) So for a L2STT that does just impact parameter calculations the FIC+SLIC should serve. I don't know how the fitting would be done after this but at least you'd have the L1CFT track and hits in a road in the same data packet. Anyway the two issues are nicely decoupled. If you want to add a slow path for data to L3 to z fitting a modified SLIC will be required. I don't know if it has sufficient bandwidth to move the data. If you want to do L2 z fitting the SLIC will not work. In fact I'm not at all clear how this can be done at all. So, to me at least, it appears the suitability of the SLIC or the design of its equivalent all comes down to scope. Do we want the added features of Z at L3 or L2? Maybe this will be the toughest question we will face at Nevis: Scope versus cost and time of avialability of the trigger. Jerry From toback@fnal.gov Wed Feb 17 16:19:53 1999 Date: Tue, 16 Feb 1999 12:58:22 -0600 (CST) From: Dave Toback To: "Horst D. Wahl" Cc: Gerald Blazey Subject: L1CFT Output format Hi Horst, I've tried to put down the basic arguements for the various L1CFT output format into a document. This issue has simmered for a while and we really should try and settle it. The three proposals are A and H, H and Pt, and a hybrid. I didn't include the option which is to cut at L1 on different values than we send to L2. My understanding is that this was an idea that was floated by Fred, but since it was never really thought of as being easily feasible it is no longer being actively considered. I should also mention that Marvin and I had talked about an A and PT proposal, but I haven't heard from him in a while. He mentioned that if the new boards split up the right way this becomes an option in a way that didn't use to be feasable. There certainly have been a number of studies about the effects of the different proposals at L1 and L2 and some attempts to try and quantify the effective road widths and efficiencies for these methods. Have you confirmed that the H and Pt does in fact give you wider roads and reduced efficiency? If the loss is intolerable does the hybrid solution meet your needs? Hopefully, putting down the arguements will enable us to try and find a way to put this question to rest. Comments? Thoughts? Thanks, Dave ************************************************************************** The old Format (what most people remember, A and H format): FE_board Number (0-79) H layer fiber number (0-43) Offset (0-15) Sign (0-1) This information is equivalent to passing the A and H layer hit information. Advantages: 1) Some studies have shown that this method defines a good road width in the SMT. 2) The STT algorithms are simplified. Also, well studied. Disadvantages: 1) To decide if a track passes a trigger threshold, it must be in a trigger bin. These are defined by offset. => Fixed turn on curves (can only group offsets) => Slow turn on curves (see plot) 2) The Pt is not a function of Offset. Said differently, a track with offset of 7 may have a higher Pt than a track with an offset of 8 and vice versa. This causes (not unsurmountable) sorting problems in L2CFT. 3) Because we only look at tracks with Pt>1.5 GeV, the largest offset used is 13. Thus, we loose two bits off the 4 bit full scale. ******************************* H and PT proposal: Sort the equations at L1 and make the trigger thresholds (bins) by Pt rather than by offset. Send Pt and H information to L2. Advantages: 1) Significantly sharpens the L1 threshold turn-on curves (See plot) 2) Allows us to dial the location of the turn on curves 3) The 4 threshold bins would be indicated by the two most significant bits of PtWord. The output from the concentrator more closely resembles the L1 decision and algorithms. 4) Sorting by PtWord in L2CFT is the same as sorting by Pt. This helps L2CFT. 5) The information sent to L2CFT is already sorted in the first two bits. Thus, only the lower bits need to be sorted. This significantly reduces the sorting time in L2. 6) The number of tracks per bin are more equitably spaced and again help the sorting. Disadvantages: 1) Makes the L2STT algorithm (potentially) more complicated 2) May make the road width larger (studies still in progress). This is very dependent on the number of different bins allowed (4 bits vs. 6 bits). Comparison to A-H method: To compare the Pt-H and A-H methods, we have tried to quantify the discussion by comparing the road widths at the A layer. In the A-H method, the A-H method the road width is, by definition, 1 fiber width. In the Pt-H method, the road width is not as well defined. For a given track, when all 8 hits are used in a full track fit, the routines return a range of Pt's which when averaged and combined with the H information uniquely specify a location in the A layer. Studies comparing this position to the true position (i.e, DeltaPhi(Pred-True)) yields a gaussian with an RMS of about a 1/4 of a fiber width. This makes sense since using more fiber information should yield a better estimate of where the track went through the A layer. However, to be fully efficient, one must integrate the full gaussian and to be 100% efficient requires going to almost a full fiber width (Marvin tells me that by removing the low probability tracks from the list we can reduce the tails of this distribution). Finally, the real problem is that we do not get the best information (i.e, the equation number or pt ranges) from the tracker, rather for every track the Pt equations are grouped. The equations in each group determine both the RMS and the tails of the road width. On average it is better than for A-H, but to be 100% efficient the road width can be worse (depending on the Pt binning). ***** Hybrid proposal: Since the road width problem appears to be mostly for low Pt bins, we could use a hybrid system. A-H for low Pt, H-PT for high Pt. Advantages: 1) Allows us to use PT for high PT where the trigger decisions are made (gives sharper and adjustable turn on curves). 2) Potentially allows A-H road width for where the most tracks are for L2STT. This may be an advantage (studies still in progress). 3) Allows a single method for when the L2STT is in the system and when it is not. Disadvantages: 1) 5 years from now it will be hard to remember what the Pt is given a value of 0010 in the "PT word". 2) It's not clear we need it. We wouldn't use this if the STT weren't there. Fred's current proposal is to make the Pt information come in 6 bits: 2 bits to denote the threshold bin and 4 bits to denote the Pt value within the bin. This would work by sorting the equations first into the four Pt threshold bins by Pt value, and them sorting the maximum and high bins by Pt value within each threshold bin. To satisfy the requirements of the STT it looks like we must sort the medium and low Pt threshold bins by offset value. Extending the Pt index from 4 to 6 bits gives us 16 possible bins within each Pt threshold bin. But we will keep the total number of bins to 16 and will use the extra bits to allow us to distribute those bins anywhere within the 4 Pt threshold bins. We can only assign indexes to the tracks once, so the scheme needed for STT and L2CFT must be the one used for L1Muon. From cutts@hep.brown.edu Wed Feb 17 16:20:12 1999 Date: Tue, 16 Feb 1999 18:51:59 -0500 From: Dave Cutts To: "'wahl@hep.fsu.edu'" Subject: FW: study for a dE/dx slow particle trigger with the STT Resent-Date: Tue, 16 Feb 1999 18:56:56 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] hi Horst, well, i've done a bit of work related to the STT trigger, for a heavy stable (slow) particle. i plan on doing more, with a student, but could you take a quick look at this to tell me if my imagining the hardware is all wet? i'd like to quickly fix what ever is misunderstood and re-run the simulation, if necessary. Uli & Meenakshi haven't had a chance to reply yet (i only sent this at noon) thanks dave -----Original Message----- From: Dave Cutts [mailto:cutts@hep.brown.edu] Sent: Tuesday, February 16, 1999 11:55 AM To: 'heintz@bu.edu'; 'meena@fnal.gov' Cc: 'cutts@brown.edu' Subject: study for a dE/dx slow particle trigger with the STT hi Uli, as i said on the phone, re-reading your and Meenakshi's notes about the possibilities of incorporating a dE/dx measurement into the STT, i was suddenly struck by the worry that i may be slightly wrong in my assumptions about the STT hardware. could you advise me what's wrong? i'll cc: Menakshi as well. thanks dave p.s. sorry for this last minute thing. Greg L. is beating up on me to get something to him which i promised for his SUSY/Exotic 1998 FNAL study report. it is now very overdue p.p.s. i have a student starting who will be helpful in pushing these studies further --------------------------------------------------------------------------- D\O\'s new silicon microstrip tracker provides interesting possibilities for triggering on slow moving particles. Since a slow particle's energy loss as a function of its velocity goes as 1/beta**2, the excellent dE/dx energy resolution of the silicon chip provides a good handle for offline identification. For example, the energy deposited in one silicon layer is shown in Figure xxx, as measured in a test beam. [ref here] More importantly for the detection of slow moving particles, there are possibilities to exploit these measurements at the trigger level, with the approval recently of D\O\'s Silicon Tracker Trigger (STT) as a component of the Level 2 Trigger System. The hardware design for the STT may allow for the inclusion of several additional backplane lines to carry dE/dx information along with the other data associated with each cluster of hits. We have studied the basic capabilities of such trigger hardware to explore its capabilities for slow particle identification. Our simulation of the STT slow particle trigger is based on a simple Monte Carlo generator which returns an ADC value appropriate for the spectrum shown in Figure xxx. We assume that two backplane lines per SMT hit are available, and we encode each ADC value into these two bits of data, or four bins. After trying various values for the three bin edges, we have chosen to define the bins by those ADC values below which lie 67\%, 95\% and 99\% of the data. The STT Level 2 trigger processor finds tracks using four layers of silicon, so for each track the hardware would provide four samples of this two bit dE/dx data. At this point the trigger would use some algorithm to combine the four samplings most advantageously. The major concern for correct identification of a slow moving particle is the very long Landau tail on the energy loss distribution, and the likelihood of false signals from a 1-MIP particle, due to an occasional response in this tail. Based on a few studies, our preliminary suggestion is simply to sum the 3 lowest values, rejecting the largest digitization of the four. The data then provides a parameter, related to a particle's dE/dx in the silicon tracker, which has 10 possible values (0..9). From our simulation we derive this distribution as shown in Figure Y1, for a beta=1 particle (equivalent to the test beam pion). In this "back-of-the-envelope" study, we model the ADC response of a slow moving particle by simply scaling the ADC distribution of Fig. XXX with the factor 1/beta**2. The resulting distributions in our dE/dx trigger parameter, for slow particles, are shown in Figure Y2. There is a clear separation in this parameter compared to the beta-1 distribution. To estimate the effectiveness of the STT dE/dx trigger we consider a selection which tags as a slow particle those whose dE/dx parameter is greater than or equal to some value. We vary this selection to study the efficiency for slow particles (at highest possible beta) while maintaining a strong rejection. Figure Z1 shows for several possible choices of this parameter, the effect of the selection as a function of a particle's velocity. Indications are that the STT Level 2 dE/dx trigger would provide an efficient tag for slow particles up to beta=0.7 with a worst case rejection of beta=1 particles of 3*10**3. For a good efficiency up to beta=0.5, the beta=1 rejection is 10**6. The above study illustrates the potential of a STT dE/dx trigger. It does assume that the 1-MIP particle ADC distribution is as seen in the test beam. Corrections will be needed for the inclination of the track, which will result in smearing of this distribution, as will differences in the silicon chip response over the detector. Nonetheless, the STT will provide very useful information early in a slow particle's lifetime, which can be combined with other data to create an efficient trigger for these interesting objects. From evans@nevis1.nevis.columbia.edu Wed Feb 17 16:20:28 1999 Date: Wed, 17 Feb 1999 09:13:06 -0500 From: Hal Evans To: Horst Wahl Subject: Re: Thoughts on Nevis report (fwd) Resent-Date: Wed, 17 Feb 1999 9:13:57 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl ---------- Forwarded message ---------- Date: Wed, 17 Feb 1999 09:05:17 -0500 From: Hal Evans To: blazey@niuhep.physics.niu.edu Subject: Re: Thoughts on Nevis report Hi Jerry, Here are a few comments about your ideas for using a fic/slic system to do the clustering/association in the STT. First off, I think that it's a very good idea to keep this option in the back of our minds in case we don't get the MRI. If we do get the MRI, then we can afford to be more elaborate and design a system with more flexibility and adaptability. The fic/slic system doesn't leave us much elbow room and would be very sensitive to tails in the distribution of hits in the SMT. If we don't have any resources though we may be forced to cut corners and then this system at least gives us something. Now for what I consider to be the main problem areas with adapting the existing fic/slic to the STT clustering/assoc. 1) Input badwidth at the FIC. The cypress hotlink is a factor of 6.3 slower than the G-link. On average each SMT input cable has 60 hits (120 words) and at max has 200 hits (from simulation!). This gives the following transfer times per SMT input. Ave Max G-Link 1.0 us 3.2 us Cypress 7.5 us 25.0 us This mostly latency, but note that at some point down the road all of the hits have to be loaded into the fit processor before it can begin. Note also that things get worse much faster for the cypress option than for the G-link if our max estimate turns out to be wrong. 2) Output bandwidth of the DSP. All DSP outut in the current slic goes through a serial port running at 40 Mbit/s. This means a 32 bit word (this is what needs to be sent due to dsp requirements) will take 0.8 us. From simulation we expect a total of 42 associated clusters per 60 degree sector on average and a maximum of 500. These get distributed over many (~20) dsp's but at the high end things are still pretty uncomfortable. The comments that I made above about latency and robustness also apply here. So it looks like the fic/slic option would certainly not be optimal. With enough cleverness though it could probably be made to work (although definitely at a cost in functionality) and is therefore a good backup in case things don't go well monetarily (is that a word?). One other comment. I don't think that at the current point it's worthwhile spending effort thinking up the clever ideas that would make the fic/slic possible. As long as we have some hope of getting the project funded we should try to pursue the best possible solution. I do think that it's a good thing to have a plan B (even if it is non-optimal) in case everything falls to ruin. This should be mentioned at Friday's meeting - not as an alternative to the current design but as something to make the project more robust against funding disasters. I hope that these comments are useful. Let me know what you think. Cheers - Hal ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v | Hal Evans | | evans@nevis1.columbia.edu | | Physics Dept. Nevis Labs | | Columbia University PO Box 137 | | 550 W 120th Mailcode 5215 136 S Broadway | | New York, NY 10027 Irvington, NY 10533 | | Tel: (212)854-3334 (914)591-2815 | | Fax: (212)854-3379 (914)591-8120 | v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ On Tue, 16 Feb 1999 blazey@niuhep.physics.niu.edu wrote: > > Hi Horst and Hal > > Thank you for sending me your "thoughts from Nevis". I > hope my comments to follow will be helpful in sorting out > possible options for the STT hardware. I think the FIC+SLIC > combination provides adequate throughput and computing > power for clustering and road association if we want to > calculate impact paratmeters only. I think the FIC+SLIC > combination is indequate if we want to include > transmission of all clusters to L2 or L3. In other words > the viabilty of the FIC+SLIC really depends on the scope of the > STT. Let me outline my reasoning. > > Both items 3 and 4 in the last list of your note are solved > by the FIC. The FIC has an onboard VTM which converts the L1CTT > information into something a MBT or SLIC can accept. > In fact the FIC was designed to solve just the problems > cited in items 3 and 4. The FIC will also properly > buffer transmissions from the SMT. To be fair one must > worry about the robustness and format of the data transfer > through the FIC, but my understanding is that this is not > an insurmountable problem. > > Item 1 in the list is a problem if there is no data > reduction in the current STT model. The SLIC should be > sufficient for impact parameter calculation if there is > data reduction. This would require reordering the tasks > in the first list of your note to > 1d (done by proper cabling and the SLIC FPGA) > 1b (here is the data reduction) > 1a (cluster around a road) > 1c (normalize to physics coordinates) > So for a L2STT that does just impact parameter calculations > the FIC+SLIC should serve. I don't know how the fitting > would be done after this but at least you'd have the L1CFT > track and hits in a road in the same data packet. Anyway > the two issues are nicely decoupled. > > If you want to add a slow path for data to L3 to z fitting > a modified SLIC will be required. I don't know if it has > sufficient bandwidth to move the data. > If you want to do L2 z fitting the SLIC will not work. In > fact I'm not at all clear how this can be done at all. > So, to me at least, it appears the suitability of the SLIC > or the design of its equivalent all comes down to scope. > Do we want the added features of Z at L3 or L2? > Maybe this will be the toughest question we will face at > Nevis: Scope versus cost and time of avialability of the trigger. > > > Jerry > > >