Most of my questions center on the user requirements and how they interact with the board specifications, and the number of boards used. In general, it seems that the user requirements should also specify a bit more about the expectations of the L1Topo of its interfacing neighbors.

 

 1.  This board will be used in a several contexts, but it must be a user requirement that it accept currently envisioned data for Phase 0 and Phase 1 applications.  What are expectations for:

 # of input fibers from CMX's in Phase 0

 # of input fibers from L1Muo in Phase 0

 

 2. For phase 1:

 # of input fibers from efex in Phase 1

 # of input fibers from jfex in Phase 1

 # of input fibers from L1Muo in Phase 1  (including New Small Wheel etc)

 

 3. Does either Phase 0 or Phase 1 force you to more than 1 L1Topo board just to receive all inputs?  If so, what does that imply about implementation and CTP interface of topo algorithms using both efex and jfex inputs, for example?  Are there any mechanism for data sharing across L1Topo boards with expected Phase 1 latency constraints?  What requirements does the l1Topo board in these uses place on signal duplication at the source? 

 

 4. How many L1Topo CTP output bits are foreseen for Phase 0?  In electrical and optical format?  How does this compare with the number CTP plans to provide?  This smaller of these is an important parameter, as it may constrain the number of L1topo algorithms which can be simultaneously active, and must be known to the menu system and perhaps to L1TopoSim as well.  I have some concerns that 32 electrical inputs only (do they exist only on the X mezzanine?) may be very constraining.

 

 5. Same CTP interface questions for Phase 1.  At a minimum, Phase 1 L1Topo should be able to provide all the phase 0 bits (CMX + L1Topo). 

 

 6. In Phase 1, L1Topo will probably for a time coexist with the CMX's while the fex's are commissioned.  During this period, the L1Topo may also be producing answers to CTP in parallel with CMXs; are there enough CTP inputs to support that, or will they need to be compared/tested without reporting to CTP?

 

 7. How many L1Calo RODs are foreseen for the phase 0 application?  Do we own that many boards or must they be manufactured? 

 

 8. What is  the expected data volume per event L1Topo produces for  the DAQ and ROI RODs in phase0? For example, either L1Topo or L1TopoSim will be required to guide HLT on which TOBs were used in decisions.  Will standard L1Calo RODs (1 for DAQ, 1 for RoI)  be adequate for Phase 0? 

 

 9. What are the firmware-ROD data buffering and reporting requirements for Phase 1?  Is buffering until L1A foreseen in the Virtex 7's, in external memory, or on the Kinetex?  Will the foreseen Kinetex FPGA have sufficient buffering and I/O capacity to replace the ROD(s)?  I note that the efex ROD was felt to be quite complex and require a Virtex-7, not a Kinetex.

 

 10. It might be worthwhile to post a specific response to this summer's L1Topo review, indicating how the outcomes and recommendations were addressed, and which still need to be dealt with.  I agree that some issues raised were of organizational nature, and this seems a more hardware-oriented review which does not really have firmware/software/commissioning in its scope, but at the very least the hardware items should be addressed.

 

 11.  Who is in charge of the non-hardware items of the project, and when will be the next major update on plans and response to review items?

 

 12. Are there any issues with receiving a critical signal such as the future optical LHC clock on a mezzanine?

 

 13. Are flexible "bare" fibers unclad after input shroud, and do they require darkness to operate properly?

 

 14.  It might be nice to give the physical size of the ATCA card (mm height x depth)

 

 15.  Why are the MTP front panels male?  Is this the usual convention?  Users need to be aware, in any case.

 

 16.  p17 section 5.4, mention of 32 differential lanes of electrical I/O per FPGA, but then "the electrical port width is up to 22 signal pairs".  A typo?

 

 17.  section 5.5  worth mentioning that these data formats don't include full CMX ID, which will have to be deduced positionally to produce global eta and phi positions?  Firmware and simulation development will require agreement on a next-level format with global coordinates.

 

 18. Maybe include GCK HP and HR in glossary

 

 19. This document does not address project scheduling.  Is there agreement about required dates of CMX and L1Topo delivery for respective foreseen uses in testing?  Do the pauses in cooling foreseen in Point 1 cooling impact commissioning significantly?