Summary of January 30, 2008 meeting with PHENIX DAQ/ONCS groups:

• * Presentation by Sergey Butsky providing overview of FVTX integration into the PHENIX DAQ/Online systems.
• * Numerology:
  • o IR Region:
    • + Number of Endcaps: 2
    • + Number of Disks per Endcap: 4
    • + Number of Wedges: 48 per disk
    • + Total Number of Wedges: 384
    • + Number of Wedges per ROC: 16
    • + Number of ROCs per Endcap: 12
    • + Total number of ROCs: 24
    • + Number of ROCs per Clock Distribution Board: 6
    • + Number of Clock Distribution boards per Endcap: 4
    • + Total number of Clock Distribution Boards: 8
    • + Number of data fibers per ROC: 1
    • + Total number of fibers per Endcap: 144
    • + Total number of fibers: 288
    • + Number of fibers per bundle: 12
    • + Number of active fibers per bundle: 8
    • + Number of fiber bundles per endcap: 24
    • + Total number of fiber bundles: 48
    • + Number of slow control fibers per ROC: 2
    • + Number of slow control fibers per endcap: 24
    • + Total number of slow control fibers: 48
    • + Number of Clock fibers per endcap: 4
    • + Total Clock fibers: 8
  • o Rack Room:
    • + Number of FEMs per ROC: 2
    • + Total number of FEMs: 48
    • + FEMs per Crate: 12
    • + Total number of crates: 4
    • + FEM Interface Cards: 4
    • + DCM-II channels(fibers): 48
• * Discussion/Comments:
  • o Down load of operating parameters should incorporate a readback mechanism to verify that there was no data corruption in the transfer process.
  • o Reprogamming of FPGA's on ROC's should be rare occurance, and will be done via slow control.
  • o Calibration will be done at most daily. Requires download of a few constants to set the pulse height. Currently no readback implemented.
  • o Discussion that a read back might be useful if the calibration results do not match the expected results. How do you know if it was an error in the transfer of calibration constants or hardware?
  • o Discussion of what happens if the reprogramming of the eeproms fails or is interupted? Does it leave the system in a non-operational state?
  • o Monitoring of Voltage, current and temperature will be built into the ROC. Expect that there will be a small, 1 KByte, of data every minute or so. Can come up either in the slow control or data streams.
  • o Slow control communications is expected to be via ethernet using a Digilent ethernet module. Some questions about what the communications protocol is and how easy it will be to implement in ONCS. Documentation on the module will be circulated for evaluation.
  • o Discussion of power and power supply needs. Expect that LV and Bias be segmented at the wedge level. Power is fused and monitored on the power distribution card. Regulation is done on the ROC for both the ROC and wedge.
• * Additional Comments:
  • o We should estimate read-back times for anything that we propose to read back on slow controls. This will give us a check on what reasonable periodicity should be for reading our slow controls data. --There was some discussion about how we can test that all of our interfaces are really working properly, i.e. if a data stream is sent how do we know that it arrived at its destination properly, that a data stream comes back from a particular point properly. One thing that came out of this was that we need to make sure that our VME interface board has appropriate loop-back capabilities for testing the interface chains. May have implications on our design in other areas too.
  • o There was discussion about criticality (or not) of power-up sequences. We should make sure that the ROC has built into it any power-up sequence protection that might be needed so that if power supplies are brought up in some non-standard way that there is no chance for putting us into an improper state or damaging our system(s).
  • o On the ethernet card software protocol, it would also be helpful if we could get a more detailed list of constraints/suggestions from ONCS. Martin said he had definite ideas but we didn't discuss it in detail. We understand that we should be able to run on LINUX, and assume that if we had something like a C interface then this would be acceptible (?), but are there more specific requirements that they would like us to meet? Also, I think Dave asked if it would be possible to get more details about the other systems that we were told are developing VME-based slow controls interfaces. If there really is a design which has advanced further than we have, it would be very helpful to arrange a presentation from someone in the group that could give details.