Subject: Re: Changes to COOR resource programming protocol From: Philippe Laurens Date: Tue, 25 Apr 2006 15:50:00 -0400 To: mverzocc@fnal.gov Hi Marco, Thank you, thank you, thank you, for helping to organize and focus this process. > but reference set 0 cannot be used in a trigger, since the corresponding object count is not transferred from the TAB to the GAB. 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). > is modified as > > - If the lowest Reference Set allocated by COOR is #N, with N>0, TCC > will program all Reference Set #M, with 0 < M < N to the same threshold > as the one COOR defined for Reference Set #N. I am not sure that we would need to change the rules for un-allocated refsets, as Refset #0 would now become allocated, as far as TCC is concerned... but we can postpone that discussion. > POSSIBLE SIMPLIFICATION: > ------------------------ > > Reference thresholds 0 both for EM and jets are set in the TCC configuration > files to 3 GeV for the EM and 5 GeV for the Jet triggers. No modifications to > the XML and COOR download are needed. Yes, as you describe, L1Cal-TCC already includes the concept of automatically ingesting a TCC command file as part of the end of the official initialization sequence. This command file can indeed make TCC send to itself (i.e. preload) some COOR requests, e.g. defining ref set #0. This is how we have been managing the trigger tower explicitly excluded from participating in the trigger. This is a viable option if these Refset #0 thresholds are not envisioned to change often, and do not need to be recorded in the run dependent information (besides logbooks) but still need to be accessible via editing an ascii file. One must also make sure we don't confuse COOR, but I don't think this would. > b) The EM isolation ratio and the EM/HD fraction ratio both require one additional parameter to be transferred from TCC to the TAB. This parameter ... > "L1CAL_Ref_Set EM_Isolation TT_Eta(-20:20) TT_Phi(1:32) Ratio EM_Et_Ref_Set " > "L1CAL_Ref_Set EM_HD_Fraction TT_Eta(-20:20) TT_Phi(1:32) Ratio EM_Et_Ref_Set " That sounds good to me. > At the cost of some flexibility (which current studies indicate is NOT needed) > we could decide to use "lowthres" as "objthres" and have a single parameter > transferred from COOR to TCC. We could do this without modifying the message sent from COOR to TCC and have the TCC code send the reference set 0 to the > TABs as the reference threshold used for selecting the EM objects which are > used for setting the EM isolation and EM/HD fraction ratio flags. ok too. > 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. > (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 ? > "L1CAL_to_L1FW Global_Sums minTower_ET " If this is not tied to And-Or Term sent to the L1FW, nor a GAB resource, the first keyword should probably be something else, i.e. for sake of consistency. How about "L1CAL_Global_Sums Min_Tower_Et TT_Eta(-20:20) TT_Phi(1:32) Energy_Threshold " > where the minTower_ET is an energy in GeV (steps of 250 MeV, this gets > transformed into an 8 bit number which TCC sends to the TAB - beware of > pedestals !!!!) ... > where the optional parameter mintowerET is set to the default value > of -2 GeV in case it is not specified in the triggerlist (this corresponds to 0 ADC counts). 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. > 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]? > "L1CAL_Ref_Set Tau_Ratio_Ref_Set TT_Eta(-20:20) TT_Phi(1:32) Ratio_Threshold Jet_Et_Ref_Set " no problem. > (Apply to the Tau_Ratio_Ref_Set the same rules used for the EM_Et_Ref_Set and Jet_Et_Ref_Set) You mean for the un-allocated Tau_Ratio_Ref_Set? and for the same motivation as the EM and Jet refsets? Does this imply/require that the Jet_Et_Ref_Set instance used in the computation is the same for all the Tau_Ratio_Ref_Set instances? > The tau triggers will be formed in the GAB by requiring a phi-coincidence between > the jet threshold and the ratio threshold. I got a bit lost here. Are you saying the GAB *also* need to know which Jet_Et_Ref_Set was used with the Tau_Ratio_Ref_Set? No change is needed in the message sent > from COOR to the TCC: > > "L1CAL_to_L1FW Tau_All_Term Use_Ref_Set Count_Threshold Tau_Ratio " But, but, but... you added "Tau_Ratio", right? *If* I understand correctly, and for consistency, "Use_Ratio_Set" may be a better keyword here: "L1CAL_to_L1FW Tau_All_Term Use_Ref_Set Use_Ratio_Set Count_Threshold " > POSSIBLE SIMPLIFICATION: > ------------------------ > > Specify the value of rsratio (or Jet_Et_Ref_Set) in the TCC configuration > file (use reference set 1 or 0, most likely 1). If we use #0 and it is also pre-loaded, then no problem. If we use #1 and it is not preloaded, then TCC must not try to verify that the reference set has already been defined, or maybe delay this consistency check until an actual ratio_set definition. That's ok too. > Specify the values of the tau ratios in the TCC configuration file and > use only the tau ratio reference set number in the COOR download. Ok, and whichever the trigger meisters and Scott decide makes no difference with respect to what TCC needs to be prepared to parse, right? Same thing for all these initialization-time pre-loading of resource definition. > 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? But wait, you said *and in the missing ET/total ET sums* 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? > POSSIBLE SIMPLIFICATION > ----------------------- > > Set this flag in the TCC configuration files. That sounds reasonable too. I can't picture you are going to be flipping back an forth, except for special runs. Using the initialization-time-TCC-command-file has the advantage of not hardcoding these defaults into the TCC software itself, so that such parameters can "evolve" or be accessible for special runs. As far as I am concerned, you must be in the best position to weigh the inconvenience of burdening COOR, Scott, and the trigger database with these cumbersome details, versus the inconvenience of having to do funny things offline to recognize that such a run was taken with a non-standard configuration. This makes no difference to TCC or me, as we still need to define and parse the syntax to program these resources. > * 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 :-) Philippe