Subject: Re: Changes to COOR resource programming protocol From: Marco Verzocchi Date: Mon, 01 May 2006 17:56:04 -0500 To: Philippe Laurens Hi Philippe I'm sorry for the delay in replying to this E-mail..... You ha > Your proposal is ok with me, but Scott is the authority here. > He may think of, or prefer, some other method that would > generate messages to TCC for Refset#0 without a clear > association to an existing run2b.xxx And-Or Term. > > The downsides of the extra parameter added to all trigger > terms is that it clutters the trigger list, and has to > be maintained the same number repeated everywhere. If we can > manage to make this threshold appear only once in the trigger > list, wouldn't we be better off? maybe we can attach > this no-effect term to one of the non-physics specific > triggers, like the min-bias or monitoring, or something else > (and we could still provide a specific default value in TCC). I think that we can put this in the triggerlist in an hidden way (there are parameters which are default in all the triggers and do not need to appear in the triggername). An alternative which was also suggested to me is to put it in the XML generator. And the final alternative is to put it in the TCC initialization. Let's see what Scott prefers (this applies to several parameters). >> The new TAB firmware contains a new downloadable parameter which sets a threshold >> in ADC counts for the inclusion of a trigger tower in the sums used for the >> calculation of the missing ET and total ET. TCC must transfer this parameter >> to each TAB > I imagine this will actually have to be downloaded into each TAB FPGA, > which means each 4x4 patch of trigger towers. Can you think of > any excuse we would want different thresholds at higher/lower etas? > > It just as easy anyway for TCC to allow the Eta/Phi syntax and > for COOR to use the default no-range=full-range as needed. Actually right now we are thinking of using the same parameter for all eta/phi. You are right we should maybe foresee the Eta/Phi syntax... But then I wouldn't know how to download it from the triggerlist..... > (a single parameter is used both for the EM and HAD towers). > > you mean the same number is applied to EM and HAD, > or one number is applied to Tot=EM+HAD ? > The same threshold is applied separately to EM and to HAD. > I am not too worried about the pedestals, but we need to decide > if TCC should allow a negative energy value. That would be > the first time, but it is not a show stopper if you think we > need this. > > That may also be something that could be handled outside of COOR > via the initialization command file. In Run I & IIa, this was > a very fixed threshold: it was burned into lookup PROMs. You are right there is an issue with pedestals. This is one case where TCC should allow in input a negative energy and then transform it to ADC counts. I think that in the new version of the document I explain this very carefully.... >> d) New requirement: tau triggers. > ... >> * the 7 tau ratio cut values (use a number between 0 and 1 encoded >> in 8 bits) > > How does that work? Is that a 1/N ratio with N=1...255 ? > Are we going to specify a decimal number and > TCC turns it into the nearest 1/N? > Or is it some other kind of mapping N vs [0..1]? There is just going to be a mapping: cut 1 corresponds to a ratio cut r_1 cut 2 corresponds to a ratio cut r_2 ....................................................... In the triggerlist we will be able to specify only 1......6....... >> e) New requirement. Flags to turn on/off the use of the ICR towers in the >> EM/Jet sums and in the missing ET/total ET sums (2 flags). >> >> We have two (or three ????) new downloadable parameters which control the >> inclusion of the ICR towers in the formation of the EM/Jet and missing ET/total ET >> sums inside the TABs. This requires either new messages of the type: >> >> "L1CAL_Ref_Set EM_Use_ICR <0/1>" >> "L1CAL_Ref_Set Jet_Use_ICR <0/1>" >> "L1CAL_Ref_Set Global`_Use_ICR <0/1>" >> >> or the addition of a Use_ICR flag to all the following mesages: >> >> "L1CAL_Ref_Set EM_Et_Ref_Set ......." >> "L1CAL_Ref_Set Jet_Et_Ref_Set ......." >> "L1CAL_to_L1FW Global_Sums ......." > > Either way is probably ok. > > Is this something that needs to or can be programmed in *all* TAB FPGAs? > or is it something that Mike and I will need to sort out which > FPGAs is told what... do you know? I believe that this message is sent to all TAB FPGAs (even if only a few of them will actually use it). > > But wait, you said *and in the missing ET/total ET sums* There is a flag for controlling the inclusion of the ICR trigger towers in the jet triggers and a second separate flag for controlling the inclusion of the ICR trigger towers in the global sums. As such those flags should be part of all the jet and of all the global sum triggers. The two messages however can be sent only once, and therefore the values of the useICR parameters have to be consistent throughout the entire triggerlist... > > If this is not solely part of the reference sets, > and cannot be different for different reference sets anyway, > maybe we should use a separate message. COOR can > notice that this needs to be sent before the first > usage of a reference set or global sum, and generate > one message at that time. > > This also sounds like it should be part of the > COOR resource for run2b.l1miss_et and .l1tot_et, No? > Yes, with some default values.... >> * assignment of trigger framework bits (need to count again bits and >> reassign map of bits send from GAB to trigger framework, surely need more tau terms). > > Yes, I bet :-) > Yes this is going to be the next thing to be solved. I hope it can be done quickly.... Cheers Marco