From evans@nevis1.nevis.columbia.edu Mon Dec 11 10:33:35 2000 Received: from FSHEB1.HEP.FSU.EDU (fsheb1.hep.fsu.edu [128.186.110.21]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA01563 for ; Mon, 11 Dec 2000 10:33:34 -0500 Resent-Message-Id: <200012111533.KAA01563@sg1.hep.fsu.edu> Resent-Date: Mon, 11 Dec 2000 8:27:16 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from nevis1.nevis.columbia.edu by FSHEB2.HEP.FSU.EDU with SMTP; Mon, 11 Dec 2000 8:28:25 -0500 Received: from localhost (evans@localhost) by nevis1.nevis.columbia.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA71749; Mon, 11 Dec 2000 08:27:49 -0500 (EST) Date: Mon, 11 Dec 2000 08:27:48 -0500 From: Hal Evans To: Meenakshi Narain cc: "J. Linnemann" , Marvin Johnson , nomerot@fnal.gov, lipton@fnal.gov, STTpp Group -- John Hobbs , Ulrich Heintz , Horst Wahl Subject: Re: clarification on STT buffering In-Reply-To: <3A33BD64.31FE4356@bu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: Hi Meena, Sorry about the mail appearing slightly out of the blue - it was part of an ongoing discussion. You are correct in assuming that the road information would be buffered in the LRB. Buffering the SMT information would (as you mention) mean major changes to the design. Any suggestions involving SMT buffering have therefore been brutally suppressed. The reason for my mail was that I had heard rumors that the (incorrect) statement made by me that it would be impossible to buffer road information in the STCs was being used as a major argument against the APV chip. Any of the chip options being discussed would imply some changes to the STT, which we would need to study in detail. However, I thought it best to correct my misstatements quickly since they seemed to be having drastic consequences. 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 | | 538 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 Sun, 10 Dec 2000, Meenakshi Narain wrote: > Hi Jim, > > You may be right, but given that this is the first I hear about how Run2b > impacts the STC. So, maybe we should have a discussion of these issues > in the STT meetings before signing off. > > I haven't a clue what how the STC will be impacted - maybe others who > are not designing the STC have a better idea about how STC will > cope with it - so I would like to know how - at the minimum. > > So maybe a discussion within the STT group on Run2b issues > is required??? Or NOT? > > Meenakshi > > > "J. Linnemann" wrote: > > > Maybe I misunderstood, but I thought the idea was that the STC could still > > keep up with the SMT/FED data, but that the roads would now arrive first > > because of greater latency with the APV chips in the front ends. So it > > wasn't obvious to me that buffering for SMT data was an absolute > > requirement, only that there now should be a mechanism to verify that the > > SMT data and the road data were indeed from the same event, since they > > weren't directly associated by arrival time as now. > > > > I would imagine that this scheme could still have substantial implications > > for the STC card, as the nature of the arriving data would be substantially > > different: not 8bit addresses, but rather cluster locations in one option on > > the FED I'd heard. So the question would be whether the front-end > > clustering on the present cards could be bypassed by appropriate FPGA > > programming. > > > > Based on what I'd heard Friday, I don't think we are anywhere near a > > sign-off on the APV scheme, only that STT hasn't absolutely veto'd it yet. > > A STT veto may have been close to the conclusion drawn from the discussions > > on Thursday with an imperfect picture of the input buffering. Sorry because > > of video reservations I wasn't able to attend Thursday, and because of video > > performance, I was only on a speakerphone on Friday. I'm sure those who > > were present at the meetings will correct me if I misunderstood. > > > > Jim > > > > -----Original Message----- > > From: Meenakshi Narain [mailto:narain@bu.edu] > > Sent: Sunday, December 10, 2000 12:00 PM > > To: Hal Evans > > Cc: Marvin Johnson; nomerot@fnal.gov; lipton@fnal.gov; STTpp Group -- > > John Hobbs; Meenakshi Narain; Ulrich Heintz; Horst Wahl; James Linnemann > > Subject: Re: clarification on STT buffering > > > > Hi Hal, > > > > Hal Evans wrote: > > > > > Hello Marvin, Andrei and Ron, > > > > > > After some discussion in the STT meeting this Friday, we've realized that > > > the buffering situation in the STT is not as bleak as we led you to > > > believe in the APV meeting on Thursday. It turns out that the components > > > that receive the L1CTT roads from the Fiber Road Card (FRC) on the STCs > > > and TFCs include the capability of buffering a reasonable amount of data - > > > enough for 16 events (the L2 requirement). > > > > just to be sure - you are referring to the LRBs here. > > > > > > > > This fact should make it possible for the STCs to receive clustered SMT > > > data from the FEDs with the latency necessary to perform all the FED > > > functions (reordering, etc.). Of course, we would then need to have clear > > > event boundary markers and event number information included in the SMT > > > cluster data stream from the FED - but this shouldn't pose any difficulty. > > > > > > > There us no provision at this time to buffer the incoming data from the SMT > > onto the STCs. They get processed as soon as an event comes - this > > is built into the design due to the non-existance of event #. > > > > So if I understand this correctly, this means we need to add extra buffering > > capability to the STC ? 16 event buffers for SMT data can be large and > > for 8 channels on this overcrowded board will definitely require a > > new layout and an upgraded version of the board. > > > > Will we have a broader discussion of STT and Run2b in the STT group > > before you sign off? > > > > Meenakshi > From narain@bu.edu Mon Dec 11 11:04:38 2000 Received: from FSHEW7.HEP.FSU.EDU (fshew7.hep.fsu.edu [128.186.110.57]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA01630 for ; Mon, 11 Dec 2000 11:04:38 -0500 Resent-Message-Id: <200012111604.LAA01630@sg1.hep.fsu.edu> Resent-Date: Mon, 11 Dec 2000 10:01:20 -0500 Resent-From: wahl@FSHEW8 Resent-To: wahl Received: from buphy.bu.edu by FSHEB2.HEP.FSU.EDU with SMTP; Mon, 11 Dec 2000 10:00:56 -0500 Received: from bu.edu (TQUARK.BU.EDU [128.197.41.176]) by buphy.bu.edu ((8.9.3.buoit.v1.0)/8.9.3/(BU-S-10/28/1999-v1.0pre2)) with ESMTP id KAA3335024; Mon, 11 Dec 2000 10:00:22 -0500 (EST) Message-ID: <3A34EC86.68581C4C@bu.edu> Date: Mon, 11 Dec 2000 10:02:30 -0500 From: Meenakshi Narain Reply-To: narain@bu.edu Organization: Boston University X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Hal Evans CC: "J. Linnemann" , Marvin Johnson , nomerot@fnal.gov, lipton@fnal.gov, STTpp Group -- John Hobbs , Ulrich Heintz , Horst Wahl Subject: Re: clarification on STT buffering References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: Hi Hal, As I understand from Jim's message from yesterday that the data format may change too and maybe clustering done upstream. If I take it at face value, then this means if we go for a 3 chip STC design, then given the occupancy increases and scope changes, it is not only FPGA redesign but also the board layout changes as well. But since I do not know the whole story - I can only comment on yesterday's mail messages. Needless to say, I am worried about major implications to the STC and whatever has been said until now leads me to believe, that STC daughter boards (if we stick with the 3 or even 2 chip scenarios) can be thrown away for Run2b....does this put an additional constraint now on the STC design that all needs to fit in one huge FPGA ? I need to know this very very very soon. Meenakshi Hal Evans wrote: > Hi Meena, > > Sorry about the mail appearing slightly out of the blue - it was part of > an ongoing discussion. You are correct in assuming that the road > information would be buffered in the LRB. Buffering the SMT information > would (as you mention) mean major changes to the design. Any suggestions > involving SMT buffering have therefore been brutally suppressed. > > The reason for my mail was that I had heard rumors that the (incorrect) > statement made by me that it would be impossible to buffer road > information in the STCs was being used as a major argument against the APV > chip. Any of the chip options being discussed would imply some changes to > the STT, which we would need to study in detail. However, I thought it > best to correct my misstatements quickly since they seemed to be having > drastic consequences. > > 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 | > | 538 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 Sun, 10 Dec 2000, Meenakshi Narain wrote: > > > Hi Jim, > > > > You may be right, but given that this is the first I hear about how Run2b > > impacts the STC. So, maybe we should have a discussion of these issues > > in the STT meetings before signing off. > > > > I haven't a clue what how the STC will be impacted - maybe others who > > are not designing the STC have a better idea about how STC will > > cope with it - so I would like to know how - at the minimum. > > > > So maybe a discussion within the STT group on Run2b issues > > is required??? Or NOT? > > > > Meenakshi > > > > > > "J. Linnemann" wrote: > > > > > Maybe I misunderstood, but I thought the idea was that the STC could still > > > keep up with the SMT/FED data, but that the roads would now arrive first > > > because of greater latency with the APV chips in the front ends. So it > > > wasn't obvious to me that buffering for SMT data was an absolute > > > requirement, only that there now should be a mechanism to verify that the > > > SMT data and the road data were indeed from the same event, since they > > > weren't directly associated by arrival time as now. > > > > > > I would imagine that this scheme could still have substantial implications > > > for the STC card, as the nature of the arriving data would be substantially > > > different: not 8bit addresses, but rather cluster locations in one option on > > > the FED I'd heard. So the question would be whether the front-end > > > clustering on the present cards could be bypassed by appropriate FPGA > > > programming. > > > > > > Based on what I'd heard Friday, I don't think we are anywhere near a > > > sign-off on the APV scheme, only that STT hasn't absolutely veto'd it yet. > > > A STT veto may have been close to the conclusion drawn from the discussions > > > on Thursday with an imperfect picture of the input buffering. Sorry because > > > of video reservations I wasn't able to attend Thursday, and because of video > > > performance, I was only on a speakerphone on Friday. I'm sure those who > > > were present at the meetings will correct me if I misunderstood. > > > > > > Jim > > > > > > -----Original Message----- > > > From: Meenakshi Narain [mailto:narain@bu.edu] > > > Sent: Sunday, December 10, 2000 12:00 PM > > > To: Hal Evans > > > Cc: Marvin Johnson; nomerot@fnal.gov; lipton@fnal.gov; STTpp Group -- > > > John Hobbs; Meenakshi Narain; Ulrich Heintz; Horst Wahl; James Linnemann > > > Subject: Re: clarification on STT buffering > > > > > > Hi Hal, > > > > > > Hal Evans wrote: > > > > > > > Hello Marvin, Andrei and Ron, > > > > > > > > After some discussion in the STT meeting this Friday, we've realized that > > > > the buffering situation in the STT is not as bleak as we led you to > > > > believe in the APV meeting on Thursday. It turns out that the components > > > > that receive the L1CTT roads from the Fiber Road Card (FRC) on the STCs > > > > and TFCs include the capability of buffering a reasonable amount of data - > > > > enough for 16 events (the L2 requirement). > > > > > > just to be sure - you are referring to the LRBs here. > > > > > > > > > > > This fact should make it possible for the STCs to receive clustered SMT > > > > data from the FEDs with the latency necessary to perform all the FED > > > > functions (reordering, etc.). Of course, we would then need to have clear > > > > event boundary markers and event number information included in the SMT > > > > cluster data stream from the FED - but this shouldn't pose any difficulty. > > > > > > > > > > There us no provision at this time to buffer the incoming data from the SMT > > > onto the STCs. They get processed as soon as an event comes - this > > > is built into the design due to the non-existance of event #. > > > > > > So if I understand this correctly, this means we need to add extra buffering > > > capability to the STC ? 16 event buffers for SMT data can be large and > > > for 8 channels on this overcrowded board will definitely require a > > > new layout and an upgraded version of the board. > > > > > > Will we have a broader discussion of STT and Run2b in the STT group > > > before you sign off? > > > > > > Meenakshi > > From lipton@fnal.gov Mon Dec 11 11:28:12 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA01645 for ; Mon, 11 Dec 2000 11:28:12 -0500 Resent-Message-Id: <200012111628.LAA01645@sg1.hep.fsu.edu> Resent-Date: Mon, 11 Dec 2000 10:23:19 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from barry.mail.mindspring.net by FSHEB2.HEP.FSU.EDU with SMTP; Mon, 11 Dec 2000 10:24:28 -0500 Received: from [199.174.163.213] (user-33qt8ul.dialup.mindspring.com [199.174.163.213]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA04591; Mon, 11 Dec 2000 10:23:48 -0500 (EST) Message-Id: <200012111523.KAA04591@barry.mail.mindspring.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Mon, 11 Dec 2000 09:24:21 -0600 Subject: Re: clarification on STT buffering From: "Ronald Lipton" To: narain@bu.edu, Hal Evans CC: "j. linnemann" , marvin johnson , nomerot@fnal.gov, "sttpp group -- john hobbs" , ulrich heintz , horst wahl Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Status: RO X-Status: My last mail may have been lost by the server so I would like to repeat that the "clustering" in the FED is the equivilent of sparsification on the SVX. The FED contains a gate array which, for D0, would be programmed to deliver data to the STT in the same format as the current sequencer. The major issue for the STT in the APV is the latency incurred during readout. The APV uses about 7 microseconds for data setup, 7 microseconds for readout, and additional time (another ~7 microseconds) in the FED for digitization, sparsification, and data reordering (it comes out non-sequentially). It is this time, which affects the L2 processing budget, which is the issue. During the technical discussions it was suggested that since the APV is a deadtimeless chip one could add a buffer(s) to the FED and eliminate the resulting deadtime. I am not sure that this makes sense in the context of the other L2 systems, but in any case such a solution would require that there be equivalent buffering of the CFT roads to keep the STT information in sync. Hope this helps. Ron > Hi Hal, > > As I understand from Jim's message from yesterday that > the data format may change too and maybe clustering > done upstream. If I take it at face value, then this means > if we go for a 3 chip STC design, then given the occupancy increases > and scope changes, it is not only FPGA redesign but also > the board layout changes as well. But since I do not > know the whole story - I can only comment on > yesterday's mail messages. > > Needless to say, I am worried about major implications to > the STC and whatever has been said until now leads me to believe, > that STC daughter boards (if we stick with the 3 or even 2 chip scenarios) can > be thrown away for Run2b....does this put an additional constraint > now on the STC design that all needs to fit in one huge FPGA ? > I need to know this very very very soon. > > Meenakshi > > > Hal Evans wrote: > >> Hi Meena, >> >> Sorry about the mail appearing slightly out of the blue - it was part of >> an ongoing discussion. You are correct in assuming that the road >> information would be buffered in the LRB. Buffering the SMT information >> would (as you mention) mean major changes to the design. Any suggestions >> involving SMT buffering have therefore been brutally suppressed. >> >> The reason for my mail was that I had heard rumors that the (incorrect) >> statement made by me that it would be impossible to buffer road >> information in the STCs was being used as a major argument against the APV >> chip. Any of the chip options being discussed would imply some changes to >> the STT, which we would need to study in detail. However, I thought it >> best to correct my misstatements quickly since they seemed to be having >> drastic consequences. >> >> 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 | >> | 538 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 Sun, 10 Dec 2000, Meenakshi Narain wrote: >> >> > Hi Jim, >> > >> > You may be right, but given that this is the first I hear about how Run2b >> > impacts the STC. So, maybe we should have a discussion of these issues >> > in the STT meetings before signing off. >> > >> > I haven't a clue what how the STC will be impacted - maybe others who >> > are not designing the STC have a better idea about how STC will >> > cope with it - so I would like to know how - at the minimum. >> > >> > So maybe a discussion within the STT group on Run2b issues >> > is required??? Or NOT? >> > >> > Meenakshi >> > >> > >> > "J. Linnemann" wrote: >> > >> > > Maybe I misunderstood, but I thought the idea was that the STC could still >> > > keep up with the SMT/FED data, but that the roads would now arrive first >> > > because of greater latency with the APV chips in the front ends. So it >> > > wasn't obvious to me that buffering for SMT data was an absolute >> > > requirement, only that there now should be a mechanism to verify that the >> > > SMT data and the road data were indeed from the same event, since they >> > > weren't directly associated by arrival time as now. >> > > >> > > I would imagine that this scheme could still have substantial implications >> > > for the STC card, as the nature of the arriving data would be substantially >> > > different: not 8bit addresses, but rather cluster locations in one option on >> > > the FED I'd heard. So the question would be whether the front-end >> > > clustering on the present cards could be bypassed by appropriate FPGA >> > > programming. >> > > >> > > Based on what I'd heard Friday, I don't think we are anywhere near a >> > > sign-off on the APV scheme, only that STT hasn't absolutely veto'd it yet. >> > > A STT veto may have been close to the conclusion drawn from the discussions >> > > on Thursday with an imperfect picture of the input buffering. Sorry because >> > > of video reservations I wasn't able to attend Thursday, and because of video >> > > performance, I was only on a speakerphone on Friday. I'm sure those who >> > > were present at the meetings will correct me if I misunderstood. >> > > >> > > Jim >> > > >> > > -----Original Message----- >> > > From: Meenakshi Narain [mailto:narain@bu.edu] >> > > Sent: Sunday, December 10, 2000 12:00 PM >> > > To: Hal Evans >> > > Cc: Marvin Johnson; nomerot@fnal.gov; lipton@fnal.gov; STTpp Group -- >> > > John Hobbs; Meenakshi Narain; Ulrich Heintz; Horst Wahl; James Linnemann >> > > Subject: Re: clarification on STT buffering >> > > >> > > Hi Hal, >> > > >> > > Hal Evans wrote: >> > > >> > > > Hello Marvin, Andrei and Ron, >> > > > >> > > > After some discussion in the STT meeting this Friday, we've realized that >> > > > the buffering situation in the STT is not as bleak as we led you to >> > > > believe in the APV meeting on Thursday. It turns out that the components >> > > > that receive the L1CTT roads from the Fiber Road Card (FRC) on the STCs >> > > > and TFCs include the capability of buffering a reasonable amount of data - >> > > > enough for 16 events (the L2 requirement). >> > > >> > > just to be sure - you are referring to the LRBs here. >> > > >> > > > >> > > > This fact should make it possible for the STCs to receive clustered SMT >> > > > data from the FEDs with the latency necessary to perform all the FED >> > > > functions (reordering, etc.). Of course, we would then need to have clear >> > > > event boundary markers and event number information included in the SMT >> > > > cluster data stream from the FED - but this shouldn't pose any difficulty. >> > > > >> > > >> > > There us no provision at this time to buffer the incoming data from the SMT >> > > onto the STCs. They get processed as soon as an event comes - this >> > > is built into the design due to the non-existance of event #. >> > > >> > > So if I understand this correctly, this means we need to add extra buffering >> > > capability to the STC ? 16 event buffers for SMT data can be large and >> > > for 8 channels on this overcrowded board will definitely require a >> > > new layout and an upgraded version of the board. >> > > >> > > Will we have a broader discussion of STT and Run2b in the STT group >> > > before you sign off? >> > > >> > > Meenakshi >> > > > From narain@bu.edu Sun Dec 10 13:02:01 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA15936 for ; Sun, 10 Dec 2000 13:02:00 -0500 Resent-Message-Id: <200012101802.NAA15936@sg1.hep.fsu.edu> Resent-Date: Sun, 10 Dec 2000 11:57:10 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from buphy.bu.edu by FSHEB2.HEP.FSU.EDU with SMTP; Sun, 10 Dec 2000 11:58:17 -0500 Received: from bu.edu (TQUARK.BU.EDU [128.197.41.176]) by buphy.bu.edu ((8.9.3.buoit.v1.0)/8.9.3/(BU-S-10/28/1999-v1.0pre2)) with ESMTP id LAA3240698; Sun, 10 Dec 2000 11:57:40 -0500 (EST) Message-ID: <3A33B682.D0121421@bu.edu> Date: Sun, 10 Dec 2000 11:59:46 -0500 From: Meenakshi Narain Reply-To: narain@bu.edu Organization: Boston University X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Hal Evans CC: Marvin Johnson , nomerot@fnal.gov, lipton@fnal.gov, STTpp Group -- John Hobbs , Meenakshi Narain , Ulrich Heintz , Horst Wahl , James Linnemann Subject: Re: clarification on STT buffering References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: Hi Hal, Hal Evans wrote: > Hello Marvin, Andrei and Ron, > > After some discussion in the STT meeting this Friday, we've realized that > the buffering situation in the STT is not as bleak as we led you to > believe in the APV meeting on Thursday. It turns out that the components > that receive the L1CTT roads from the Fiber Road Card (FRC) on the STCs > and TFCs include the capability of buffering a reasonable amount of data - > enough for 16 events (the L2 requirement). just to be sure - you are referring to the LRBs here. > > This fact should make it possible for the STCs to receive clustered SMT > data from the FEDs with the latency necessary to perform all the FED > functions (reordering, etc.). Of course, we would then need to have clear > event boundary markers and event number information included in the SMT > cluster data stream from the FED - but this shouldn't pose any difficulty. > There us no provision at this time to buffer the incoming data from the SMT onto the STCs. They get processed as soon as an event comes - this is built into the design due to the non-existance of event #. So if I understand this correctly, this means we need to add extra buffering capability to the STC ? 16 event buffers for SMT data can be large and for 8 channels on this overcrowded board will definitely require a new layout and an upgraded version of the board. Will we have a broader discussion of STT and Run2b in the STT group before you sign off? Meenakshi From linnemann@kepler.pa.msu.edu Sun Dec 10 13:18:31 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA15948 for ; Sun, 10 Dec 2000 13:18:31 -0500 Resent-Message-Id: <200012101818.NAA15948@sg1.hep.fsu.edu> Resent-Date: Sun, 10 Dec 2000 12:13:40 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from kepler.pa.msu.edu by FSHEB2.HEP.FSU.EDU with SMTP; Sun, 10 Dec 2000 12:14:47 -0500 Received: from milesdavis (milesdavis.pa.msu.edu [35.12.162.180]) by kepler.pa.msu.edu (8.9.3+Sun/8.9.3) with SMTP id MAA12589; Sun, 10 Dec 2000 12:14:13 -0500 (EST) From: "J. Linnemann" To: , "Hal Evans" Cc: "Marvin Johnson" , , , "STTpp Group -- John Hobbs" , "Meenakshi Narain" , "Ulrich Heintz" , "Horst Wahl" Subject: RE: clarification on STT buffering Date: Sun, 10 Dec 2000 12:16:58 -0500 Message-ID: <000a01c062cd$00bb0c50$b4a20c23@pa.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <3A33B682.D0121421@bu.edu> Status: RO X-Status: Maybe I misunderstood, but I thought the idea was that the STC could still keep up with the SMT/FED data, but that the roads would now arrive first because of greater latency with the APV chips in the front ends. So it wasn't obvious to me that buffering for SMT data was an absolute requirement, only that there now should be a mechanism to verify that the SMT data and the road data were indeed from the same event, since they weren't directly associated by arrival time as now. I would imagine that this scheme could still have substantial implications for the STC card, as the nature of the arriving data would be substantially different: not 8bit addresses, but rather cluster locations in one option on the FED I'd heard. So the question would be whether the front-end clustering on the present cards could be bypassed by appropriate FPGA programming. Based on what I'd heard Friday, I don't think we are anywhere near a sign-off on the APV scheme, only that STT hasn't absolutely veto'd it yet. A STT veto may have been close to the conclusion drawn from the discussions on Thursday with an imperfect picture of the input buffering. Sorry because of video reservations I wasn't able to attend Thursday, and because of video performance, I was only on a speakerphone on Friday. I'm sure those who were present at the meetings will correct me if I misunderstood. Jim -----Original Message----- From: Meenakshi Narain [mailto:narain@bu.edu] Sent: Sunday, December 10, 2000 12:00 PM To: Hal Evans Cc: Marvin Johnson; nomerot@fnal.gov; lipton@fnal.gov; STTpp Group -- John Hobbs; Meenakshi Narain; Ulrich Heintz; Horst Wahl; James Linnemann Subject: Re: clarification on STT buffering Hi Hal, Hal Evans wrote: > Hello Marvin, Andrei and Ron, > > After some discussion in the STT meeting this Friday, we've realized that > the buffering situation in the STT is not as bleak as we led you to > believe in the APV meeting on Thursday. It turns out that the components > that receive the L1CTT roads from the Fiber Road Card (FRC) on the STCs > and TFCs include the capability of buffering a reasonable amount of data - > enough for 16 events (the L2 requirement). just to be sure - you are referring to the LRBs here. > > This fact should make it possible for the STCs to receive clustered SMT > data from the FEDs with the latency necessary to perform all the FED > functions (reordering, etc.). Of course, we would then need to have clear > event boundary markers and event number information included in the SMT > cluster data stream from the FED - but this shouldn't pose any difficulty. > There us no provision at this time to buffer the incoming data from the SMT onto the STCs. They get processed as soon as an event comes - this is built into the design due to the non-existance of event #. So if I understand this correctly, this means we need to add extra buffering capability to the STC ? 16 event buffers for SMT data can be large and for 8 channels on this overcrowded board will definitely require a new layout and an upgraded version of the board. Will we have a broader discussion of STT and Run2b in the STT group before you sign off? Meenakshi From narain@bu.edu Sun Dec 10 13:31:19 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA15955 for ; Sun, 10 Dec 2000 13:31:18 -0500 Resent-Message-Id: <200012101831.NAA15955@sg1.hep.fsu.edu> Resent-Date: Sun, 10 Dec 2000 12:26:27 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from buphy.bu.edu by FSHEB2.HEP.FSU.EDU with SMTP; Sun, 10 Dec 2000 12:27:34 -0500 Received: from bu.edu (TQUARK.BU.EDU [128.197.41.176]) by buphy.bu.edu ((8.9.3.buoit.v1.0)/8.9.3/(BU-S-10/28/1999-v1.0pre2)) with ESMTP id MAA3252151; Sun, 10 Dec 2000 12:27:01 -0500 (EST) Message-ID: <3A33BD64.31FE4356@bu.edu> Date: Sun, 10 Dec 2000 12:29:08 -0500 From: Meenakshi Narain Reply-To: narain@bu.edu Organization: Boston University X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "J. Linnemann" CC: Hal Evans , Marvin Johnson , nomerot@fnal.gov, lipton@fnal.gov, STTpp Group -- John Hobbs , Meenakshi Narain , Ulrich Heintz , Horst Wahl Subject: Re: clarification on STT buffering References: <000a01c062cd$00bb0c50$b4a20c23@pa.msu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: Hi Jim, You may be right, but given that this is the first I hear about how Run2b impacts the STC. So, maybe we should have a discussion of these issues in the STT meetings before signing off. I haven't a clue what how the STC will be impacted - maybe others who are not designing the STC have a better idea about how STC will cope with it - so I would like to know how - at the minimum. So maybe a discussion within the STT group on Run2b issues is required??? Or NOT? Meenakshi "J. Linnemann" wrote: > Maybe I misunderstood, but I thought the idea was that the STC could still > keep up with the SMT/FED data, but that the roads would now arrive first > because of greater latency with the APV chips in the front ends. So it > wasn't obvious to me that buffering for SMT data was an absolute > requirement, only that there now should be a mechanism to verify that the > SMT data and the road data were indeed from the same event, since they > weren't directly associated by arrival time as now. > > I would imagine that this scheme could still have substantial implications > for the STC card, as the nature of the arriving data would be substantially > different: not 8bit addresses, but rather cluster locations in one option on > the FED I'd heard. So the question would be whether the front-end > clustering on the present cards could be bypassed by appropriate FPGA > programming. > > Based on what I'd heard Friday, I don't think we are anywhere near a > sign-off on the APV scheme, only that STT hasn't absolutely veto'd it yet. > A STT veto may have been close to the conclusion drawn from the discussions > on Thursday with an imperfect picture of the input buffering. Sorry because > of video reservations I wasn't able to attend Thursday, and because of video > performance, I was only on a speakerphone on Friday. I'm sure those who > were present at the meetings will correct me if I misunderstood. > > Jim > > -----Original Message----- > From: Meenakshi Narain [mailto:narain@bu.edu] > Sent: Sunday, December 10, 2000 12:00 PM > To: Hal Evans > Cc: Marvin Johnson; nomerot@fnal.gov; lipton@fnal.gov; STTpp Group -- > John Hobbs; Meenakshi Narain; Ulrich Heintz; Horst Wahl; James Linnemann > Subject: Re: clarification on STT buffering > > Hi Hal, > > Hal Evans wrote: > > > Hello Marvin, Andrei and Ron, > > > > After some discussion in the STT meeting this Friday, we've realized that > > the buffering situation in the STT is not as bleak as we led you to > > believe in the APV meeting on Thursday. It turns out that the components > > that receive the L1CTT roads from the Fiber Road Card (FRC) on the STCs > > and TFCs include the capability of buffering a reasonable amount of data - > > enough for 16 events (the L2 requirement). > > just to be sure - you are referring to the LRBs here. > > > > > This fact should make it possible for the STCs to receive clustered SMT > > data from the FEDs with the latency necessary to perform all the FED > > functions (reordering, etc.). Of course, we would then need to have clear > > event boundary markers and event number information included in the SMT > > cluster data stream from the FED - but this shouldn't pose any difficulty. > > > > There us no provision at this time to buffer the incoming data from the SMT > onto the STCs. They get processed as soon as an event comes - this > is built into the design due to the non-existance of event #. > > So if I understand this correctly, this means we need to add extra buffering > capability to the STC ? 16 event buffers for SMT data can be large and > for 8 channels on this overcrowded board will definitely require a > new layout and an upgraded version of the board. > > Will we have a broader discussion of STT and Run2b in the STT group > before you sign off? > > Meenakshi From evans@nevis1.nevis.columbia.edu Sat Dec 9 13:53:06 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA14461 for ; Sat, 9 Dec 2000 13:53:06 -0500 Resent-Message-Id: <200012091853.NAA14461@sg1.hep.fsu.edu> Resent-Date: Sat, 9 Dec 2000 12:48:18 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from nevis1.nevis.columbia.edu by FSHEB2.HEP.FSU.EDU with SMTP; Sat, 9 Dec 2000 12:49:23 -0500 Received: from localhost (evans@localhost) by nevis1.nevis.columbia.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA89010; Sat, 9 Dec 2000 12:48:48 -0500 (EST) Date: Sat, 9 Dec 2000 12:48:48 -0500 From: Hal Evans To: Marvin Johnson , nomerot@fnal.gov, lipton@fnal.gov cc: STTpp Group -- John Hobbs , Hal Evans , Meenakshi Narain , Ulrich Heintz , Horst Wahl , James Linnemann Subject: clarification on STT buffering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: Hello Marvin, Andrei and Ron, After some discussion in the STT meeting this Friday, we've realized that the buffering situation in the STT is not as bleak as we led you to believe in the APV meeting on Thursday. It turns out that the components that receive the L1CTT roads from the Fiber Road Card (FRC) on the STCs and TFCs include the capability of buffering a reasonable amount of data - enough for 16 events (the L2 requirement). This fact should make it possible for the STCs to receive clustered SMT data from the FEDs with the latency necessary to perform all the FED functions (reordering, etc.). Of course, we would then need to have clear event boundary markers and event number information included in the SMT cluster data stream from the FED - but this shouldn't pose any difficulty. Before we can sign off on this issue completely though, we would need to do some queueing studies to see how the increased latency in the APV system would affect our contribution to L2 deadtime. We would also have to make sure that we could continue to use VTMs as the means of getting SMT data into the STCs. The rest of the STT group should chime in here in case I've forgotten anything important. 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 | | 538 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 mjohnson@fnal.gov Mon Dec 11 12:24:55 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA01954 for ; Mon, 11 Dec 2000 12:24:55 -0500 Resent-Message-Id: <200012111724.MAA01954@sg1.hep.fsu.edu> Resent-Date: Mon, 11 Dec 2000 11:20:03 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from fnal.gov ([131.225.9.20]) by FSHEB2.HEP.FSU.EDU with SMTP; Mon, 11 Dec 2000 11:21:11 -0500 Received: from fnal.gov ([131.225.224.100]) by smtp.fnal.gov (PMDF V6.0-24 #44770) with ESMTP id <0G5E00F9AW24SB@smtp.fnal.gov> for wahl@fsheb2.hep.fsu.edu; Mon, 11 Dec 2000 10:20:28 -0600 (CST) Date: Mon, 11 Dec 2000 10:26:34 -0600 From: Marvin Johnson Subject: Re: clarification on STT buffering To: Ronald Lipton Cc: narain@bu.edu, Hal Evans , "j. linnemann" , nomerot@fnal.gov, sttpp group -- john hobbs , ulrich heintz , horst wahl Reply-to: mjohnson@fnal.gov Message-id: <3A350025.76EDC042@fnal.gov> Organization: D0 MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <200012111523.KAA04591@barry.mail.mindspring.net> Status: RO X-Status: While I agree that the output of the FED would be similar to the SVX, there would need to be some minimal changes such as putting in the event number. If the events are buffered in the FED, some way of matching to the correct event for the CFT road will be required. Marvin From evans@nevis1.nevis.columbia.edu Mon Dec 11 15:49:33 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA02534 for ; Mon, 11 Dec 2000 15:49:33 -0500 Resent-Message-Id: <200012112049.PAA02534@sg1.hep.fsu.edu> Resent-Date: Mon, 11 Dec 2000 14:44:40 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from nevis1.nevis.columbia.edu by FSHEB2.HEP.FSU.EDU with SMTP; Mon, 11 Dec 2000 14:45:49 -0500 Received: from localhost (evans@localhost) by nevis1.nevis.columbia.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA84870; Mon, 11 Dec 2000 14:45:12 -0500 (EST) Date: Mon, 11 Dec 2000 14:45:11 -0500 From: Hal Evans To: Frank Filthaut cc: John Hobbs , Alice Bean , Meenakshi Narain , Ulrich Heintz , Horst Wahl Subject: Re: Impact of run 2b SMT on STT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: Hi Frank, Since the FRC does not receive or use any silicon information it is largely unaffected by the proposed changes in readout. (Of course I'd have to see the specifics of the final scheme before signing off.) The STC will be impacted, however, so I'm forwarding your mail along to Meena, Uli and Horst for their comments. (It's appended below.) 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 | | 538 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 Sun, 10 Dec 2000, Frank Filthaut wrote: > Hi Gentlemen, > > I'm sorry if Alice already contacted you about this... I > promised her to do so, but didn't yet get around to it. > > We're trying to come up with an SMT2 design that's at least > realistic enough for Alice to submit an MRI proposal by the > end of January. Regarding the STT, I realise that the choice > of readout chip is definitely an issue for you. However, > also the geometry of a new detector might affect you. > In particular, the question is in what way you are limited > by > - total channel count > - channel count / layer > - number of layers > > There is also a small chance (although for this MRI proposal > it won't be mentioned, and I have my doubts that D0 has enough > manpower to pursue this) that a L0 would consist of pixels. I > imagine that this could affect you even more? (Although if one > otherwise uses axial information only one might as well OR the > information from pixels only having different Z coordinates.) > > I sent this mail to you since I'd think only the FRC and the > TFC should be affected. I hope this is true? > > Regards, > Frank > From evans@nevis1.nevis.columbia.edu Mon Dec 11 16:57:25 2000 Received: from nevis1.nevis.columbia.edu (nevis1.nevis.columbia.edu [192.12.82.3]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02676 for ; Mon, 11 Dec 2000 16:57:24 -0500 Received: from localhost (evans@localhost) by nevis1.nevis.columbia.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA82950 for ; Mon, 11 Dec 2000 15:53:13 -0500 (EST) Date: Mon, 11 Dec 2000 15:53:13 -0500 From: Hal Evans To: Horst D Wahl Subject: Re: slides from Friday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: Hi Horst, I had a chat with Alice Bean at the airport for about 2 minutes on Friday. >From what I gather no official decision was taken at the meeting. The mail from Ron (that I forwared to you) seems to indicate that at least he is leaning toward the APV. Aside from that, I'm still in the dark. 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 | | 538 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 Mon, 11 Dec 2000, Horst D Wahl wrote: > Thanks -- I appreciate your help. > Have you heard anything about what happened at the AVP25 chip meeting > Friday afternoon? > Regards, > Horst > > +------------------------------------------------------------------+ > | Horst D. Wahl wahl@hep.fsu.edu | > | Physics Department, MS 4350 Tel. 850-644-3509 or 6809 | > | Florida State University FAX 850-644-6735 | > | Tallahassee, FL 32306-4350 | > -------------------------------------------------------------------+ > From heintz@bu.edu Mon Dec 11 17:31:47 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id RAA02716 for ; Mon, 11 Dec 2000 17:31:46 -0500 Resent-Message-Id: <200012112231.RAA02716@sg1.hep.fsu.edu> Resent-Date: Mon, 11 Dec 2000 16:26:54 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from buphy.bu.edu by FSHEB2.HEP.FSU.EDU with SMTP; Mon, 11 Dec 2000 16:28:03 -0500 Received: from papagena (PAPAGENA.BU.EDU [128.197.41.125]) by buphy.bu.edu ((8.9.3.buoit.v1.0)/8.9.3/(BU-S-10/28/1999-v1.0pre2)) with SMTP id QAA3312239; Mon, 11 Dec 2000 16:27:29 -0500 (EST) From: "Ulrich Heintz" To: , "Ronald Lipton" Cc: , "Hal Evans" , "j. linnemann" , , "sttpp group -- john hobbs" , "horst wahl" , "Ulrich Heintz" Subject: RE: clarification on STT buffering Date: Mon, 11 Dec 2000 16:30:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A350025.76EDC042@fnal.gov> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Status: RO X-Status: Hi all, It was my understanding that buffering in the FED would be essential, not because that makes the readout deadtimeless but because else the time used to process the APV data in the FED would come out of the STC processing time budget and we probably cannot afford that. Ulrich -----Original Message----- From: Marvin Johnson [mailto:mjohnson@fnal.gov] Sent: Monday, December 11, 2000 11:27 AM To: Ronald Lipton Cc: narain@bu.edu; Hal Evans; j. linnemann; nomerot@fnal.gov; sttpp group -- john hobbs; ulrich heintz; horst wahl Subject: Re: clarification on STT buffering While I agree that the output of the FED would be similar to the SVX, there would need to be some minimal changes such as putting in the event number. If the events are buffered in the FED, some way of matching to the correct event for the CFT road will be required. Marvin From heintz@bu.edu Mon Dec 11 17:41:45 2000 Received: from buphy.bu.edu (BUPHY.BU.EDU [128.197.41.42]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA02732 for ; Mon, 11 Dec 2000 17:41:44 -0500 Received: from papagena (PAPAGENA.BU.EDU [128.197.41.125]) by buphy.bu.edu ((8.9.3.buoit.v1.0)/8.9.3/(BU-S-10/28/1999-v1.0pre2)) with SMTP id QAA3338804; Mon, 11 Dec 2000 16:37:32 -0500 (EST) From: "Ulrich Heintz" To: "Richard Partridge" , "Regina" Cc: "Horst D Wahl" , "Hal Evans" , "Meenakshi Narain" , "Ronald Lipton" , "John Hobbs" , "Ulrich Heintz" , "James T. Linnemann" Subject: SMT2b and STT Date: Mon, 11 Dec 2000 16:40:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Status: RO X-Status: Hi all, recently, a lively e-mail discussion has ensued about the compatibility of various options for the SMT 2b upgrade and STT. That's certainly good. At some point - and before anybody signs off on compatibility with STT, we should organize a discussion with the entire STT group about these issues. I am not sure when is the best time to do this (before, during, or after the SMT design workshop? - before may be hard to schedule). These issues may well impact the STT design. Not my favorite thought since we are pressed for time as it is, but we also cannot ignore the needs for Run 2b, when the STT will really be crucial. I'd welcome your suggestions on how to proceed. Ulrich From evans@nevis1.nevis.columbia.edu Mon Dec 11 16:12:48 2000 Received: from FSHEW7.HEP.FSU.EDU (fshew7.hep.fsu.edu [128.186.110.57]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA02588 for ; Mon, 11 Dec 2000 16:12:48 -0500 Resent-Message-Id: <200012112112.QAA02588@sg1.hep.fsu.edu> Resent-Date: Mon, 11 Dec 2000 15:09:30 -0500 Resent-From: wahl@FSHEW8 Resent-To: wahl Received: from nevis1.nevis.columbia.edu by FSHEB2.HEP.FSU.EDU with SMTP; Mon, 11 Dec 2000 15:09:05 -0500 Received: from localhost (evans@localhost) by nevis1.nevis.columbia.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA08986; Mon, 11 Dec 2000 15:08:31 -0500 (EST) Date: Mon, 11 Dec 2000 15:08:31 -0500 From: Hal Evans To: STTpp Group -- John Hobbs , Hal Evans , Meenakshi Narain , Ulrich Heintz , Horst Wahl Subject: SVX4 vs APV (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: Hi Everyone, I just got this mail from Ron. It's a good indication of how people are thinking about the APV vs. SVX4 issue... Cheers - Hal ---------- Forwarded message ---------- Date: Mon, 11 Dec 2000 09:46:01 -0600 From: Ronald Lipton To: d0-run2b@fnal.gov Cc: lipton@fnal.gov Subject: SVX4 vs APV I have a few comments about the SVX4 vs APV question. Technical issues: SVX4: The SVX4 chip will be functionally similar to the SVX 3, but it will likely take considerable effort to understand the detailed characteristics and understand how the chip functions in the D0 readout system. The problem of 5V to 2.5V conversion, the location of this conversion, and study of the use of 2.5V single ended signals will all require effort. The 0.25 micron process is also intrinsically faster than the 1.2 micron process which may mean that we are even more sensitive to glitches on the clock lines, mode lines, and dvalid. Most of the current discussion involves readout of the staves at the far ends of the tracker. In this case the low mass cabling will have to be reconfigured and an additional jumper flex will likely be necessary. Ray estimated ~2 FTE physicists + x engineers to work on debugging the submissions. APV: The picture we came up with in Thursday's discussions has the D0 readout system with the sequencer replaced by a redesigned FED. The VRB and all downstream systems would be retained. Substantial readout system development work would have to be done for: - Power and control signal distribution (it is not clear if the existing low mass cables could be adapted for the APV) - D0-FED and FED controller design (a substantial effort which could be partially undertaken by IC/RAL) - Clock and trigger distribution. This is a very different clock than the standard D0 clock and utilizes PLLs on the hybrid. - Associated control software All of this is a substantial amount of work as well as a good deal of infrastructure that would be discarded. Schedule: This is really the crux of the matter. There is clearly a real schedule risk associated with using the SVX4. Any substantial technical problems would push the parts availability day beyond Feb, 2003. In addition much of the SVX4 development is assumed to be done by LBL engineering which is known to be volatile This schedule is already marginal since we could not expect to begin detector production until 4-6 months after production chips are available (chip testing, hybrid production, hybrid testing). This would put the start of production at 6-8/2003. Does the APV have a real advantage over the SVX4 given the time necessary for other work? We have some experience of detector delivery times so I will try to make a rough estimate assuming that the pacing item is detector delivery: - Define mechanical design - 4/2001 - Define detector layouts for bids, RFQ out - 7/2001 - Bids back, place order - 8-10/2001 - Production detectors available - 10/2002 If we choose the APV hybrids could be available at this point and production could begin. In this scenario the APV would give us a production head start of 8-10 months assuming that detector delivery is the limiting factor. I would also note that it might be possible to use the existing stock of SVX 2 chips to begin production of a layer earlier than 6/2003. This would have to be a layer at a radius appropriate to the radiation hardness of the chip. It would also imply a mixed system, since the SVX2's will have different characteristics than the SVX4's. I will now put my snowshoes on and try to go to work. I will send additional comments later, Ron From heintz@bu.edu Mon Dec 11 20:17:47 2000 Received: from buphy.bu.edu (BUPHY.BU.EDU [128.197.41.42]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA02902 for ; Mon, 11 Dec 2000 20:17:47 -0500 Received: from papagena (PAPAGENA.BU.EDU [128.197.41.125]) by buphy.bu.edu ((8.9.3.buoit.v1.0)/8.9.3/(BU-S-10/28/1999-v1.0pre2)) with SMTP id TAA3137579 for ; Mon, 11 Dec 2000 19:13:37 -0500 (EST) From: "Ulrich Heintz" To: "Horst D Wahl" Subject: RE: SMT2b and STT Date: Mon, 11 Dec 2000 19:16:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Status: RO X-Status: sometime early in January - I think the 9th, but I'm not 100% sure that was the final date. Ulrich -----Original Message----- From: Horst D Wahl [mailto:wahl@sg1.hep.fsu.edu] Sent: Monday, December 11, 2000 6:21 PM To: Ulrich Heintz Subject: Re: SMT2b and STT Hello Ulrich, when does the SMT design workshop take place? HDW From linnemann@kepler.pa.msu.edu Tue Dec 12 11:04:29 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA03744 for ; Tue, 12 Dec 2000 11:04:28 -0500 Resent-Message-Id: <200012121604.LAA03744@sg1.hep.fsu.edu> Resent-Date: Tue, 12 Dec 2000 9:59:36 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from kepler.pa.msu.edu by FSHEB2.HEP.FSU.EDU with SMTP; Tue, 12 Dec 2000 10:00:47 -0500 Received: from milesdavis (milesdavis.pa.msu.edu [35.12.162.180]) by kepler.pa.msu.edu (8.9.3+Sun/8.9.3) with SMTP id KAA04307; Tue, 12 Dec 2000 10:00:09 -0500 (EST) From: "J. Linnemann" To: "Ulrich Heintz" , , "Ronald Lipton" Cc: , "Hal Evans" , , "sttpp group -- john hobbs" , "horst wahl" Subject: RE: clarification on STT buffering Date: Tue, 12 Dec 2000 10:03:17 -0500 Message-ID: <000701c0644c$a8d13970$b4a20c23@pa.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Status: RO X-Status: If there are buffers before FED, then the processing time there is latency, not processing time, just as the STC processing time does not come out of the TFC budget. Jim -----Original Message----- From: Ulrich Heintz [mailto:heintz@bu.edu] Sent: Monday, December 11, 2000 4:31 PM To: mjohnson@fnal.gov; Ronald Lipton Cc: narain@bu.edu; Hal Evans; j. linnemann; nomerot@fnal.gov; sttpp group -- john hobbs; horst wahl; Ulrich Heintz Subject: RE: clarification on STT buffering Hi all, It was my understanding that buffering in the FED would be essential, not because that makes the readout deadtimeless but because else the time used to process the APV data in the FED would come out of the STC processing time budget and we probably cannot afford that. Ulrich -----Original Message----- From: Marvin Johnson [mailto:mjohnson@fnal.gov] Sent: Monday, December 11, 2000 11:27 AM To: Ronald Lipton Cc: narain@bu.edu; Hal Evans; j. linnemann; nomerot@fnal.gov; sttpp group -- john hobbs; ulrich heintz; horst wahl Subject: Re: clarification on STT buffering While I agree that the output of the FED would be similar to the SVX, there would need to be some minimal changes such as putting in the event number. If the events are buffered in the FED, some way of matching to the correct event for the CFT road will be required. Marvin From partridge@hep.brown.edu Tue Dec 12 18:31:26 2000 Received: from brserver1.hep.brown.edu ([128.148.63.2]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA03187 for ; Tue, 12 Dec 2000 18:31:26 -0500 Received: from partridge (partridge.hep.brown.edu [128.148.63.21]) by brserver1.hep.brown.edu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YK1XY9X0; Tue, 12 Dec 2000 17:27:13 -0500 Reply-To: From: "Richard Partridge" To: "Ulrich Heintz" , "Regina" Cc: "Horst D Wahl" , "Hal Evans" , "Meenakshi Narain" , "Ronald Lipton" , "John Hobbs" , "James T. Linnemann" Subject: RE: SMT2b and STT Date: Tue, 12 Dec 2000 17:27:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: Importance: Normal Status: RO X-Status: Hi Uli, Perhaps what would be best is to schedule an STT presentation during the workshop while also trying to understand the STT impact as designs evolve both during and after the workshop. Hopefully, by keeping STT parameters and constraints in mind at an early stage we can avoid incompatibilities with the present STT. Regards, Rich -----Original Message----- From: Ulrich Heintz [mailto:heintz@bu.edu] Sent: Monday, December 11, 2000 4:41 PM To: Richard Partridge; Regina Cc: Horst D Wahl; Hal Evans; Meenakshi Narain; Ronald Lipton; John Hobbs; Ulrich Heintz; James T. Linnemann Subject: SMT2b and STT Hi all, recently, a lively e-mail discussion has ensued about the compatibility of various options for the SMT 2b upgrade and STT. That's certainly good. At some point - and before anybody signs off on compatibility with STT, we should organize a discussion with the entire STT group about these issues. I am not sure when is the best time to do this (before, during, or after the SMT design workshop? - before may be hard to schedule). These issues may well impact the STT design. Not my favorite thought since we are pressed for time as it is, but we also cannot ignore the needs for Run 2b, when the STT will really be crucial. I'd welcome your suggestions on how to proceed. Ulrich From evans@nevis1.nevis.columbia.edu Wed Dec 13 10:18:35 2000 Received: from FSHEW8.HEP.FSU.EDU (fshew8.hep.fsu.edu [128.186.110.58]) by sg1.hep.fsu.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA04188 for ; Wed, 13 Dec 2000 10:18:34 -0500 Resent-Message-Id: <200012131518.KAA04188@sg1.hep.fsu.edu> Resent-Date: Wed, 13 Dec 2000 9:13:39 -0500 (EST) Resent-From: wahl@FSHEB1 Resent-To: wahl Received: from nevis1.nevis.columbia.edu by FSHEB2.HEP.FSU.EDU with SMTP; Wed, 13 Dec 2000 9:14:51 -0500 Received: from localhost (evans@localhost) by nevis1.nevis.columbia.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA77618; Wed, 13 Dec 2000 09:14:10 -0500 (EST) Date: Wed, 13 Dec 2000 09:14:10 -0500 From: Hal Evans To: STTpp Group -- John Hobbs , Meenakshi Narain , Ulrich Heintz , Horst Wahl Subject: Run 2b Silicon Readout Chip decision in D0. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: In case you missed it on D0 news.... ---------- Forwarded message ---------- Date: Tue, 12 Dec 2000 23:09:02 -0500 From: Harry Weerts To: d0-run2b@fnal.gov Cc: "Hugh Montgomery (E-mail)" , Mike Witherell , Mike Shaevitz , John Cooper , Stanfield Subject: Run 2b Silicon Readout Chip decision in D0. This has been posted on d0news. Fermilab, December 12, 2000 Dear colleagues: Several options for the Run 2B silicon readout chip have been considered over the last few months. We would like to thank everyone for the significant amount of work that went into reviewing and understanding each of the possible approaches. In the end, we believe that all were technically feasible solutions. The decision therefore has to be made on grounds of cost/schedule risk and likely manpower availability, which means it is somewhat subjective. Nonetheless, we feel there is a strong consensus among the D0 electronics experts. Therefore we accept the recommendation from Regina Demina and Rich Partridge that D0 participate in the SVX4 project and use the SVX4 chip, operated in SVX2 mode, for Run2B. Their recommendation is attached. The strategy we have chosen is not without risk. Schedule, funding and manpower all remain tight. We hope that everyone who has participated in the project so far will remain engaged, even if their favorite solution is not the one that D0 has chosen to pursue. John & Harry P.S. More information can be found on the D0 Internal Document Webpage: http://www-d0.fnal.gov/newd0/d0atwork/general/d0_private/d0_documents.html =========================================================== >From R. Demina and R.Partridge, received on Dec 12, 2000 Dear John, Harry, Over the course of the past several months, four different readout chip options have been explored for the Run 2b silicon upgrade: - use of the ~1500 SVX2e chips banked at UTMC, - development of an "SVX2'" chip based on the current SVX2 using the 0.7 um DMILL process, - use of the APV25 chip developed for CMS, and - development of an "SVX4" chip in collaboration with CDF based on the SVX3 design There has been a substantial effort to understand the advantages and disadvantages of these options, which culminated last week with a 2-day visit by the APV25 experts and a 3-hour meeting on Friday to hear status updates and discuss the technical merit and resource requirements for each option. To further assist us in making a recommendation, we have solicited advice from three of D0's electronics experts: Dan Edmunds, Marvin Johnson, and Dean Schamberger. Their comments are attached. Before presenting our recommendation, we summarize below the major advantages and disadvantages of each option. SVX2e ----- There is little enthusiasm in the Run 2b group for relying on the existing supply of SVX2e chips. The number of chips available is insufficient to have a high degree of confidence that even a minimal Run 2b upgrade could be successfully completed. We also note that some of these chips will be needed when the SIFT chips in the fiber tracker readout electronics are replaced. SVX2' ----- The major advantage of the SVX2' is that it provides a "drop-in" replacement for the SVX2. Production of the silicon tracker upgrade could even begin using SVX2e chips. Concerns with the SVX2' include questions about the accuracy of existing (paper) schematics, the potential for design flaws in the SVX2 leading to a non-working chip, and the long turn-around time for DMILL submissions. APV25 ----- The APV25 is an impressive device. It offers outstanding noise performance, excellent radiation hardness, and a simple clock and control interface. It has been developed for use in the CMS tracker and its properties are well understood. The chip is ready for production and could be used immediately in designing prototype detector modules. The major concern with the APV25 is the effort required to integrate it with the existing D0 DAQ system. The APV is quite different from the existing SVX2 chips, both in design philosophy and implementation. It has an analog signal output, which would require new down-stream electronics to digitize, sparsify, and buffer the data. It also has quite different timing and control signals, requiring new electronics to provide the trigger/slow control interfaces and generate a 38 MHz clock that is phase-locked to the beam crossing frequency. There are also concerns about the effect of the longer latency in transferring data from the APV25, particularly with regard to the STT. SVX4 ---- The SVX4 would be jointly developed by LBL, Fermilab, and Padova. The goal would be to produce a single chip based on the SVX3 design that could be used by both D0 and CDF. Like the APV25, the SVX4 uses a 0.25 um commercial process that is very radiation hard. Early discussions with CDF were not particularly encouraging: it looked like two different chips would be needed and there was no clear commitment from Fermilab to participate in the chip development. This situation changed dramatically following an early November meeting organized by John Cooper. Marvin Johnson developed a scheme for re-mapping SVX3 signals to emulate an SVX2 chip, allowing a single chip to serve both D0 and CDF needs. This has now been demonstrated to work. An SVX3 chip provided by CDF has been successfully readout using a reprogrammed D0 Sequencer and a small interface board designed by Mike Utes that does the signal re-mapping. The other significant change was an agreement by Ray Yarema of Fermilab and Henrik von der Lippe of LBL to serve as joint project managers, with Fermilab chip designers assisting in the SVX4 design. This significantly strengthens the SVX4 design team. The SVX4 will not fully emulate the SVX2 since it uses 2.5V logic levels and requires reprogramming of the D0 Sequencers. The current plan is to use a rad-hard level adapter chip originally designed for CDF to drive the 5V logic levels needed by the D0 Sequencer board. The major concern with using the SVX4 is the potential for schedule delays. The current schedule shows the initial chip submission occurring in August 2001, a second submission in early 2002, with production chips available in February 2003. Any delays in this schedule would adversely affect the Run 2b upgrade schedule. Recommendation -------------- Both the APV25 and SVX4 options are attractive. We believe both solutions are feasible and could be made to work. In both cases the greatest risk is the schedule risk: DAQ development time for the APV25 and chip development time for the SVX4. Overall, we believe the SVX4 is the more attractive option: - Given our existing commitments to bring up the Run 2a detector, we are concerned that insufficient engineering resources will be available (especially from existing SVX experts) to ensure a fast start in developing the APV25 DAQ components. - The SVX4 offers a common solution for D0 and CDF and has a high probability for strong lab support. - Since the SVX4 can reuse existing DAQ components, it has a much lower per-channel production cost than the APV25 solution. Furthermore, the SVX4 is likely to be developed for CDF independent of what D0 decides, so the incremental engineering effort is rather small. - SVX2 compatibility allows us to reuse existing test stands for development and testing of the Run 2b detectors. Thus, we recommend that D0 work with CDF to jointly develop a common silicon readout chip for use in the Run 2b upgrade. We believe that the attached comments by Dan, Dean, and Marvin also support this recommendation. Minimizing Schedule Risk ------------------------ We also recommend that D0 take steps to minimize the schedule risk associated with the SVX4 chip development. It is critical that D0 take an active role in the simulation and testing of the SVX4 design to ensure that the SVX4 meets D0's needs. Extensive design verification through simulation can reduce the time spent fixing bugs and increase the likelihood that the schedule can be advanced by eliminating the second test submission. We also recommend that the SVX4 footprint be as close as possible to the SVX2 footprint. This will allow hybrid design and testing to proceed using SVX2 chips. Finally, while the SVX4 development currently drives the schedule, we must make every effort to minimize other sources of delay in the construction of the tracker following SVX4 availability. Regina and Rich