This File Is the Beginning of Thinking about Reading Out the L1 Calorimeter Trigger in Run II ---------------------------------------------------- Original Rev. 12-SEPT-1995 Latest Rev. 20-FEB-1996 From: MSUPA::EDMUNDS "Daniel Edmunds, MSU Physics Dept." 13-SEP-1995 14:33:50.67 To: CUSB::DEAN CC: EDMUNDS Subj: questions about 3 usec of TT data Hi Dean, I need to start thinking about how to read out 3 usec of Trigger Tower data from the L1 Cal Trig. But, before I start thinking about it I want to make sure that I understand exactly what is needed. It's clear that some kind of zero suppressed readout will be required. Do you have a feeling about what the threshold should be for the zero suppression ? Given this we can make a guess about how much data there will be. Because you really want Energy and we readout Et should the threshold be eta dependent ? This will be address-data type information, is there a preferred format for this information ? The data is 8 bits and the address needs to be at least 12 bits (there are 1280 x 2 Trig Towers), so this is over 16 bits but under 32 bits. Should it be packed into 24 bits ? A rational address might be: 1 bit for EM/Hd, 1 bit for sign eta, 5 bits for eta, 5 bits for phi. What about the order of readout ? Does this history information need to be packed in a certain way to make it useful in Level 3 Trigger where rapid access may be required ? For example do you want all Trig Towers over threshold form a given beam crossing followed by all the Trig Towers from another beam crossing, or do you want all of the history information for a given Trig Tower to come out together ? Right now we have nothing to implement the zero suppression / data formatting so go ahead and dream up any thing that you want to help make this data useful. I expect that for at least the beam crossing that caused the trigger we will need a full readout of all Trigger Towers. If for nothing else reading out all Trig Towers for this beam crossing would be used for: Feeding Level 2 in a fixed format Offline verifying that L1 Cal Trig is operating properly Do you need all of the Trig Towers readout for any other beam crossing in order to make the corrections to the precision readout ? Do you need anything fancy, e.g.: if a Trig Tower is over threshold for any history sample then you get values readout for all 3 usec of history samples ? zero suppress thresholds that varies with the age of the history samples ? Thanks for thinking about this. This is going to be new stuff so we might as well think twice and build once. Dan From: CUSB::DEAN "Dean Schamberger, SUNY at Stony Brook" 13-SEP-1995 18:07:55.04 To: MSUPA::EDMUNDS CC: DEAN Subj: RE: questions about 3 usec of TT data Hi Dan, There were a lot of questions, so I may miss the answer to some. I assume that this is only the start of a dialog, so some of my answers have only had a few seconds thought.... I have not really thought about what would be most efficient/convenient for level_3, or even if level_3 needs or will use this info. Someone working on level_3 algorithms and/or existing level_2 code might have a better feal for this (say JimL). But if I were doing it, and did not have to worry about how hard/easy it was to arrange the info, I would ask for one 32-bit number using the low byte for E_t value, next higher byte for "age" (probably only need 5 bits, but pad with zero's for easier unpacking), and high 16 bits for channel number. The data should then be presented on monotonically increasing order, ie all history for a given tower with present first (age=0) thru to the oldest time (max age), before going to next tower. I suspect that the software people will want the age=0 data,unsuppressed or not, in a separate location. Whether that info (somewhat suppressed) is also here is something to discuss with the software people. The encoding of the channel address is less clear. The precision readout is organized into 12 "crates", inside of which the eta value changes fastest, then the phi, but only over the range covered by that feedthru port. Using that might make sense, but a more global organization might be just as easy to search, and be much easier to understand. One thing is clear, the em/had bit should be the least significant bit of the high 16 bits. Whether the next bits should phi or eta is less clear, but if I were writing the software I would want eta to be monotonic (ie no separate out the sign bit) so the eta of +1 is near eta of -1. On the subject of suppression threshold, it is true that the effect we are sensetive to is in E not E_t, but almost all the PHYSICS only cares about the E_t, so even if it is wrong in E, as long as E_t is "ok" it can be lumped in with other "resolution" effects. So, I would not add the complication of eta dependence to the thresholds. On the other hand, adding time dependant threshold might be very helpful in keeping down the size of the data. At present I do not have a feal for what the size or time dependance of the threshold might be, so keeping it general (ie 1 byte per time ) is appropriate. In the precision readout we put in enough memory that we could individually suppress noisy channels. whether you need that in the history is not clear. In fact for noisy channels you might want to see the history of the noise, even if the channel is suppressed in the trigger decision part..... I can not think of any reason one would need unsuppressed history data, even on the "same" crossing, not to mention any other crossings. I realized while typing this that I also need upto 400ns AFTER the triggered crossing. for 36x36 this means only the present and previous crossings, but for 132ns timing this means not only the present and past, but also the NEXT two samples.....ie age=-1 and age=-2 Is this possible? Given that SVX-II kills (atleast) the next 2us I would think it was no big deal. Finally a question I forgot to ask last week. If/when we run at 400ns between crossings, will you be running the CAL trigger at 132ns, only allowing triggers on the third that have beam, or will you only sample every 400ns? The reason I ask, is that a finer sampling of the trigger, may give us a better insite into how the system is working, when we first turn on again. But I do not really know what I would learn, so I am NOT asking for this ability, only wondering what your plans are. Dean From: MSUPA::EDMUNDS "Daniel Edmunds, MSU Physics Dept." 14-SEP-1995 06:30:53.79 To: CUSB::DEAN CC: EDMUNDS Subj: Thanks for the Trig Tower data answers, 132 vs 396 Hi Dean, Thanks for the quick answer. Yes, this is certainly just the beginning of a dialog and not a final specification but I just wanted to get started thinking about what is needed and how to do this. Let us think about your answers for a couple of days and then I will send back another note. I will try to talk to Jim Linnemann today about the need to correct precision Cal readout data in L3. He is going away for a week and 1/2 this Friday. How big are the corrections going to be ? Deciding about the need to correct in L3 may be something funny anyway. If not correcting causes you to 2% of the time keep an event that L3 should have thrown away, who cares. If not correcting causes you to throw away events that you should have kept then this is a serious problem. How to operate in general at 396 nsec is a big question. Steve on I have it on our "needs to be discussed at ecb meeting" list. I expect that certainly the "Serial Command Link" updates every 132 nsec as we have described it. But, do the front-end systems actually store a history sample once every 132 nsec or just once every 396 ? Do the L1 Triggers actually cycle once every 132 nsec or just every 396 ? Its not clear to me. I'm still very confused about when the accelerator will operate at 132. From the talks at this summer's workshop it sounded like either: 1. Run II might actually start at 132 or 2. 132 nsec is very difficult and we may never run there ever. If we are never going to actually run at 132 then I expect that some of the front-ends may actually provide a better S/N ratio by sampling at 396 and just keep their 132 capability in reserve. Thanks again for your thought about the Trig Tower data, Dan From: CUSB::DEAN "Dean Schamberger, SUNY at Stony Brook" 14-SEP-1995 10:29:12.80 To: MSUPA::EDMUNDS CC: DEAN Subj: RE: Thanks for the Trig Tower data answers, 132 vs 396 Hi Dan, I wish I knew how large the corrections will be. They are not a function of the "real" signal, but only a fraction of the "off time" signal, and (at least for a few samples near the real one, can be a large fraction of the off time signal. The real question is how often does it happen that the off time signal is large enough to matter. If I had to guess right now, I would say that we might end up seeing a few percent of the events with enough "history" that a few towers need as much a 10% fixes. The only place I would feel "safe" in applying a correction at L3 would be in missing E_t (and maybe jet or electron energies?), nothing on a cell by cell basis since all we have is trigger tower values. I think I agree with your assessment of 132ns running.....if someone would promise me that we would not run at 132ns, I would probably not differenciate the trigger signal as much. I thought of two more things that you should think about a little. First, I do not know, and clearly will not know for atleast 1 year, but I can not (now) garrantee that I can shape the signal hard enough, that there will not be cases where a high E_t tower, does not cross a low E_t threshold 132ns before the real crossing. IE, you may need to look at the next 132ns sample to garrentee you have the correct crossing. I assume this is very hard for you, but I can not at this time give any promises about how uniform the signal shapes will be (and therefore how hard I can differentiate...) Second, right now your ped value is determined by the sum of switching transients from previous times. Since I have to differentiate the signal harder, I will attempt to keep the relative signal to "pedestal" atleast at its present level. Also, I will attempt to ensure the ped value is the same, for all real crossings. This may not be possible at 396ns, because of the non-uniform structure of the beam. Last time I heard, the 396ns timing was a multiple of 132ns intervals, but some spacings were NOT an integer multiple of 396ns..... Sorry to make you life more complicated, but I thought I should warn you now, rather than suprise you later. Dean \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////// How Much Data Movement is Required to Get the Trigger Tower Data ------------------------------------------------------------------ Let's think just about the CTFE data to start with. But remember, there is also: CHTCR Jet List data, CAT2 Large Tile data, and IMLRO Final Readout data. OK, so each L1 Cal Trig Tier 1 backplane has 16 phi by 4 eta of CTFE data. This is 64 Trigger Towers or 128 bytes of Trigger Tower data per history sample. Now Dean needs 3 usec of zero supressed data before the beam crossing, the full eta,phi array for the beam crossing that caused the trigger, and 400 nsec of zero supressed data after the beam crossing. So how much data is there to move from the CTFE's into a "Smart New" CTMBD, i.e. the SNCTMBD. Well, 3400 nsec at a beam crossing every 132 nsec is 26 beam crossings. So to get all of the data into the SNCTMBD would require 26 x 128 CBus read cycles. This is 3328 CBus read cycles. If each CBus read cycle requires 200 nsec then this would require 666 usec to move all of this data to the SNCTMBD. 666 usec is over budget by an order of magnitude. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////// Current speed of the Data Block Builder CBus Read Cycles -------------------------------------------------------- The COMINT Data Block Builder currently starts a CBus Read cycle once every 13 ticks of the MTG 37.66 nsec clock, i.e. once every 490 nsec. The cable run from M114 to M101 is about 75 nsec one way. The read cycle signal delay time in a MBD or CTMBD has never been measured but it is not very much. So the only "proof" that we have is that the Backplane part of the CBus Read Cycles work in 340 nsec i.e. 490 nsec - 150 nsec. Estimate of the Minimum Cycle Time for a Backplane CBus Read Cycle ------------------------------------------------------------------ SNCTMBD Address Drivers onto the Backplane CBus: 5 nsec Backplane Delay, Skew, and Bounce: 15 nsec Application Card Address Receivers from the Backplane CBus: 5 nsec Application Card Wake Up Decode (ALS520 + AS08 + AS04): 33 nsec Application Card AM29525 Select (ALS138): 22 nsec Application Card Address Fan-Out (ALS540, Parallel with Wake Up and Select): 12 nsec Application Card Target Register Access Time (AM29525): 23 nsec Application Card Data Path Delay (ALS541): 14 nsec Application Card Data Drivers Delay: 5 nsec Application Card Data P.C.B. Trace Delay: 10 nsec Backplane Delay, Skew, and Bounce: 15 nsec SNCTMBD Data Receivers from the Backplane CBus: 5 nsec --------------------- Total: 152 nsec Thus a 200 nsec Backplane CBus Read Cycle is about the practical lower limit. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////// 20-FEB-1996 Add some more background information. The L1 Cal Trig information comes from 4 different sources: CTFE, CHTCR, LTCC, and final readout IMLRO. Possible solutions for each of these data sources are: CTFE need 25 zero suppressed time samples readout. Must zero suppress on the CTFE because not enough backplane CBus bandwidth to get all of the data down to the Run II Fancy CTMBD. Can a THE Card be used for a Run II Fancy CTBMD. CHTCR Currently does normal Run I readout from AM29529's. Feed from TTL single ended short backplane signals. L2 would like these "Jet Masks". LTCC possible take the diff ECL input data that goes to the LTCC cards to separate Run II IMLRO cards. Final Readout Currently this is from IMLRO cards. In Run II it can be from "Run II IMLRO cards". Amount of data from the CTFE's: Recall that there are 64 TT per Tier 1 backplane or 128 bytes (EM and HD) of TT information per crossing. Well lets assume that there is a 10% hit rate above the zero suppress threshold per beam crossing. So typically a given TT will need to readout: This BX value, skip N BX's control, BX value, skip N BX's control, BX value, flag to start next TT. This is 6 bytes per channel or 6 x 128 = 768 bytes. Now if we want to read this into the Fancy CTMBD in 50 usec it means that the CBus will need to move 1 bytes every 65 usec; i.e. hard to do. 6 bytes per channel x 1280 TT's x EM&HD = 15,360 bytes of TT data per event. Is there a separate readout to feed L2 and L3. Is L2 feed from the ERPB's, or is L2 feed fromthe Fancy CTMBD, or is L2 just a tap on the L3 feed. During the first part of the superbunch we do not need to keep all 25 history slices (because there aren't 25 of them yet), thus smaller TT data event size. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////