List of Questions for the CTP Upgrade Review

and some initial answers by Uli and Sam

Below is a list of question/issues that need to be addressed during the CTP upgrade review. The list is categorized by sub-system or activity.

L1Topo

1. How many trigger bits will be sent from L1Topo to the CTP?

At the L1Topo PDR it was decided to limit the physical interface to 32 LVDS signals per L1Topo module, for up to two L1Topo modules operated in parallel. The actual bit count depends on the algorithms to be implemented.

2. What is the definition/information content of these trigger bits? In particular are they independent single-bit flags (e.g. per algorithm and threshold) or are they groups of several bits (e.g. multiplicities)?

In general these are conceived to be flags of algorithm results, with the threshold criteria already set in L1Topo. A single algorithm might have more than one output bit, but this would represent (for instance) a list of different thresholds passed for the same algorithm. To reduce bits used, an ordered list of thresholds passed should be used if possible (i.e. 2 bits for 3 thresholds….)

3. How many of these bits will be used at the same time in a given trigger menu?

Unclear. From the CTP perspective it would be important to be able to use ALL of the bits in a trigger menu if necessary. It will be up to us (L1Calo, L1Topo) to make the best use possible of the available output bits, so that bandwidth is not wasted.

4. Will the electrical outputs to the CTP be operated at 40 MHz or will they be overclocked by default? If yes, what is the maximum speed, 80 MHz of 160 MHz?

That depends on the maximum envisaged bit count. Is there any reason to build a system not capable of 160 Mb/s?

I think over clocking needs to be assumed. From what I understand, 128 bits is probably the upper limit of what we could ask the CTP to accept from L1Topo. This could be two L1Topo modules (64 lines) running at 80 Mbit/s or one module (32 lines) running at 160Mb/s. So we may want to ask whether 160 Mbit/s can be built into the CTP inputs.

5. How many optical links will need to be connected from L1Topo to the CTP (if any)?

Additional bandwidth at slightly higher latency seems useful. For ease of fibre routing we should allow for one 12-way connector per L1Topo module (for up to two of them). That was the conclusion at the L1Topo PDR, I believe. But can be re-discussed if there were problems with front panel or board real estate.

6. If optical transmission is used, is the proposed line rate of 6.4 GBaud (with 8B10B) acceptable?
Yes, that was decided at the L1Topo PDR already.

7. How many bits per BC will each optical link carry (assuming some idle characters also need to be sent)?

There are up to 128 bit per BC per fibre available at the chosen rate and encoding. Within L1Calo a suggestion had been made long ago, to encode zeroes into comma characters, so as to allow for re-alignment after possible link losses. If we agree on such a scheme, unused words on the links should be zeroed. If it is felt that a well-defined fraction / number of consecutive words needs to be zeroed (and such transmitted as comma characters) it should be agreed on now. It should be noted that in addition to word alignment (automatically handled by comma characters) we will require frame alignment within a 25ns / 8 word frame. To that end we might possibly require more than one kind of comma character. For the L1Calo-to-L1Topo data transmission that holds true as well and we should agree on a common scheme.   

L1Calo

1. How many additional trigger bits are expected to be sent from the CMX modules to the CTP after LS1? Is anything known yet about the information content of the additional bits? 

This depends on whether extra thresholds need to be added to the multiplicity-based triggers. I don't know exactly what is envisioned, but the extra bits would likely be additional 2- or 3-bit multiplicities like the current CMM outputs. I suspect we will also drop the Jet ET threshold bits from the current Jet CMM output.

2. The proposed CTP upgrade assumes that the input cables will carry 31 bits at 40 MHz as before. Additional trigger inputs can be fed to the CTP through unused bits on the existing cables as well as through additional cables. How many additional cables are expected to be connected from the CMX to the CTP? 
Depends whether those inputs can be overclocked as well. If so, then the CMX could fit more multiplicities on the same number of lines.

3. Are there plans to connect any of the optical outputs from the CTX modules to the CTP? If yes, how many links and how many bits are foreseen? 
Not clear. In my opinion, not unless CMX performs topology triggers. And even so I am not sure what the best way to send the results to CTP. Comments from MSU?

4. What are the plans to connect the new digital L1Calo trigger to the CTP after the Phase-I upgrade? Will the connections be optical or electrical? How many optical or electrical cables will be needed? How many trigger bits will be sent over these cables? Will the information content still follow the existing model of multiplicities per threshold plus flags?

To my understanding, the FEXes will send their trigger objects (TOBs) to L1Topo, which will then report results to the CTP. Is anyone else considering direct FEX->CTP output?

Trigger menu

1. How many trigger items are foreseen in the trigger menu after LS1 and after the Phase-I upgrade?

2. Is the number of 16 bunch group masks (now 8) considered sufficient? If not, what additional bunch groups will be required?

3. Assuming the topological trigger inputs are simple flags, will they be directly mapped to trigger items (with bunch group masking and pre-scaling per item) or will they need to be combined (logical OR/AND) with other trigger inputs in the menu?

4. The trigger menu for commissioning and calibration running will have to be shared between the four trigger partitions. However since the number of trigger items will be doubled, this is assumed to be acceptable.