Slide 1

Development of UW Pixel DAQ System Final Report : Winter 2015 Jimin Kim University of Washington Department of Mathematics/Physics March 20 th 2015 Slide 2 Table of Contents Objective/Motivation Approach Results Summary Outlook 2 Slide 3 Projects Objective Deploy identical DAQ System for the ATLAS Pixel Detector at LHC in the UW Lab (Similar to SR1 Pixel Lab at CERN) Use the system setup for the DAQ Software development and various pixel DAQ tasks in an effort to understand and improve the Pixel Detector for its future upgrades Test of Pixel Calibration performances Pixel ROD FEI3 Module IBLROD FEI4 Module Development of Robust DAQ Firmware FEI3 IBLROD (Higgs set) FEI4 IBLROD (Current Insertible B-Layer upgrade) ITK - ?? (2022 upgrade for entire Pixel Detector) 3 Slide 4 Pixel Detector Innermost detector of the ATLAS Made out of Pixel Modules Modules store important information about the charged particles Pixel DAQ System Filters/processes raw data and transfer to the off detector storage Calibrate the pixel modules to the best operational setting Provides precise information for the particles of interest Pixel DAQ System Filters/processes raw data and transfer to the off detector storage Calibrate the pixel modules to the best operational setting Provides precise information for the particles of interest Use the data to reconstruct the circular trajectories of the particles Momentum Direction Pixel DAQ System Slide 5 UW Pixel DAQ System Setup Pixel Module ePP0 eBOC ROD Host Computer SBC Pixel Module : FEI3 Pixel Module with MCC. Stores data from the initial events and send it to the readout chain ePP0 (Electrical Patch Panel): Replaces Opto-board in LHC, routes the data from the module and send out to the eBOC eBOC (Electrical Back of Crate Card) : Replaces Back of Crate Card. Acts as interface between the ROD and ePP0. Also synchronizes the timing between the module and the ROD ROD (Readout Driver) : Pixel ROD Rev D. It accepts the serial link from the eBOC and processes them into a single set of data called an event fragment. Also carries out pixel calibration processes. Core hardware of the project. SBC (Single Board Computer) : Model VP-110. Controls the ROD with the DAQ Software. Acts as a interface between the user and the ROD (VME interface) TIM (Trigger & Timing Control Module) : Identical hardware as CERNs. Receives various signals including L1A trigger and distributes to RODs 5 Simulated input data Output data Data TransmissionData Processing TIM Slide 6 Hardware Pictures 6 Pixel Module ePP0 eBOC Readout Driver Single Board Computer Host Computer Slide 7 Objectives during Winter 2015 Operate Pixel Infrastructure on ROD crate Bring the Pixel ROD to the Ready state with proper firmware Establish the proper connection and power setup for transmission hardware Slide 8 Approach (Pixel Infrastructure) Modify the LabDB configurations and PixRCD configurations Local UW LabDB and PixRCD configurations have been established during Fall 2014 In order to operate Pixel Infrastructure on SBC, one should modify LabDB and PixRCD configurations so that PixActionServer runs on SBC instead of Host LabDB Modify pl_LOCAL.dat so that the controller is now SBC instead of the host computer. Change the IP address and HW address of the controller to those of SBC as well PixRCD Modify PixHW_LAB.data.xml so that it contains both the host computer name and the SBC name. Modify Segment_PixelInfrastructure.data.xml so that PixActionServers run on SBC instead of Host computer. Slide 9 Result PixActionServers initializations in SBC are failing Slide 10 Failure Analysis The exact location in the code of the failure is the constructor for IsInfoReceiver. Any service initialization that requires a call to the ISInfoReceiver constructor fails on SBC. PixActionServers are the services that require this constructor. These services are successfully initialized when Pixel Infrastructure is running entirely on the Host Failure to run PixActionServers on crate is independent to the hardware present in the crate since the same illegal instruction error occurs when using Dummy controller The investigations for this error is still ongoing Slide 11 Approach (VME Interface and Pixel ROD) The VMEBus error from Fall 2014 has been resolved by following the sequence Load the MDSP firmware onto memory (Done once) Reset the ROD (Every time the crate powers up) Load the slave software via master Confirm the ROD state with GetRodStatus The SBC has been upgraded from VP-CP1 VP-110 The connectivity between the crate and the host was completely lost sometime due to the VP-CP1 sporadic malfunction VP-110 is very similar to VP-CP1 (Supports same VME drivers) VP-110 has larger memory (1GB) compared to VP-CP1 (256MB) VP-110 doesnt come with internal VGA thus one should communicate with SBC using minicom at Host Slide 12 GetRodStatus Result We've got a live one! Print the status: ================== R O D S T A T U S ==================== Slot : 7 Base adress : 0x07000000 Byte order OK : Yes Serial Number : 527 ROD rev. : e MDSP program rev. : c0ffee FMT program rev. : f418 EFB program rev. : 8f33 RTR program rev. : 8f2f RCF program rev. : f39 Number of slave DSPs : 4 Primitive state : Idle ============================================ ============== ==================== MASTER VERSION ====================== Image MD5 sum: 91d23910a8826e47c7813796183c2ec1 Link Time: 101212@1112 CVS Tag: D_undefined =============== SLAVE Number 0: Version ================= Image MD5 sum: fd5570eb29df7381913c0d4b7b958b4f Link Time: 210710@0034 CVS TAG: R_RodDaq-2-5-11 =============== SLAVE Number 1: Version ================= Image MD5 sum: fd5570eb29df7381913c0d4b7b958b4f Link Time: 210710@0034 CVS TAG: R_RodDaq-2-5-11 =============== SLAVE Number 2: Version ================= Image MD5 sum: fd5570eb29df7381913c0d4b7b958b4f Link Time: 210710@0034 CVS TAG: R_RodDaq-2-5-11 =============== SLAVE Number 3: Version ================= Image MD5 sum: fd5570eb29df7381913c0d4b7b958b4f Link Time: 210710@0034 CVS TAG: R_RodDaq-2-5-11 Deleting VmeInterface... Releasing DMA buffer Unmapping port 0 Deleting VmePort, start = 7000000 0 VmePorts still allocated Also, when the firmware are loaded, 4 LED lights on ROD blinks which imply the ROD is properly configured Slide 13 Approach (Hardware connectivity) After ROD was properly set up with correct firmware, the remaining goal was to establish the proper connectivity between the transmission hardware along with the operation of Pixel Infrastructure on crate Schematics of each hardware (eBOC, ePP0, PP0 test board) was analyzed in order to establish the correct orientations for wires and power required for each hardware Pixel Module PP0 Test Board ePP0 eBOC Crate 3.3V GND Prom outputs 3.2V when measured with voltmeter Ribbon Cable 2.0V VDDA 1.6V VDDD PSU Slide 14 Hardware connection eBOC ePP0 FEI3 Module PP0 Test board Firmware identifications for ePP0 and eBOC still remains Slide 15 Outlook Resolve the IsInfoReceiver Constructor error and successfully operate Pixel Infrastructure on Crate Identify the firmware on ePP0 and eBOC and test their functionality Using the calibration console of Pixel Infrastructure, send configuration signals to the hardware and identify three pairs of LVDS signal to module When all the inputs into the module is correct, connect the module to the system and perform Pixel Calibration or Data processing analysis Slide 16 Summary/Conclusion The Pixel ROD is now fully functional with proper firmware. SBC has been upgraded from VP-CP1 to VP-110. Proper hardware connectivity has been established but few more clarifications are needed before connecting the module to the system. The attempt to operate Pixel Infrastructure on SBC fails due to the constructor ISInfoReceiver failure on SBC. Investigation is still ongoing. Once the Pixel Infrastructure successfully operates on crate and the proper connection between the hardware is established, the pixel module can be connected to the system for the DAQ simulation and software development. Slide 17 Q/A