1 / 16

XFEL Meeting, DESY 5 May 2011 Erdem Motuk, Martin Postranecky, Matt Warren, Matthew Wing

XFEL 2D Pixel Clock and Control System. XFEL Meeting, DESY 5 May 2011 Erdem Motuk, Martin Postranecky, Matt Warren, Matthew Wing. OUTLINE. Test card A progress RTM card progress Firmware progress Veto logic Future plans. Test card A progress.

piper
Download Presentation

XFEL Meeting, DESY 5 May 2011 Erdem Motuk, Martin Postranecky, Matt Warren, Matthew Wing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. XFEL 2D Pixel Clock and Control System XFEL Meeting, DESY 5 May 2011 Erdem Motuk, Martin Postranecky, Matt Warren, Matthew Wing

  2. OUTLINE • Test card A progress • RTM card progress • Firmware progress • Veto logic • Future plans

  3. Test card A progress • The manufactured boards (PC3461M) are received • 8 boards in total • Initial test (voltages, LEDS) carried out – all working order • Each board provide 1 channel TX and 1 channel RX • 1 channel -> FAST clock, FAST data, Status, Veto -> 1 RJ45 conn. • AC coupling circuitries on the RX channel (clock,data,veto) • Further tests are carried out • A pair of boards used for telegram RX/TX and FAST RX/TX tests • 1st board -> Telegram TX – FAST RX • 2nd board -> Telegram RX – FAST TX • Tests were running successfully – without errors

  4. Test card A progress • Stress testing the boards to verify the AC coupling circuitry • Random data pattern (LFSR generated) sent in between long durations of zeros or ones • Clock (99 MHz) is sent along with the data on a separate channel • Tests were run overnight using shielded cables (~5m) • No errors observed due to the AC coupling and the transmission • Results observed by ChipScope • A few errors observed due to the test firmware • The choice of the sync word is the cause – one random sequence is lost • Tests carried out on all 8 boards • Boards available to FEE developers if needed

  5. Test card A progress

  6. UTCA crate progress • The purchased uTCA crate (xTCA) is kitted with the TR and the DAMC2 boards • SUSE Linux is installed on the crate • The boards were powered without any problems • IPMI tools detected the boards presence and the board information can be read • A simple test firmware to test the PCIe functionality of the DAMC2 board generated • DAMC2 board showed up on the PCIe tree without any problems • A simple test driver is generated for the board • Was able to access memory mapped registers on the board

  7. RTM card progress • Schematic design for the RTM prototype is finished • The board provides 16 channels • 1 channel -> FAST clock, FAST data, Veto, Status Feedback • 1 spare channel (RJ45 connector) could also be fit • 2 pairs input (with the AC-coupling circuitry) • 2 pairs output (with the LVDS buffer) • Designed to provide maximum flexibility for testing • On-board (~9 MHz) oscillator • Clock multiplexers to select between on board clock and DAMC2 supplied clock • User programmable LEDs (on the 2x8 RJ45 connector) • Clock feedback to the DAMC2 board • Extra prototyping area

  8. RTM card progress

  9. RTM card progress • RTM card designed according to the uTCA specs • Mechanical details to fit double width, full height faceplate • An I2C extender (PCF8574) • A temperature monitor () • An EEPROM () • Currently in the layout stage • Liaising with the RAL DO

  10. Firmware progress • Joined the DESY-wide effort for standardising FPGA development for DAMC2 – FPGA Experts Group • A unified firmware/software framework to use the DAMC2 • A central project/core repository • Will use cores from the repository and contribute to it if needed • First aim is to provide a startup project for the DAMC2 • A general UCF file • PCIe block that is common to all cards • II Interface – A versatile bus/register interface between different cores on the FPGA • Cores for using SFP links, DDR2 RAM on board • Cores for using different peripherals – e.g. Clock MUX

  11. Firmware progress • What this means for the CC card • The standard PCIe core for the DAMC2 is used • Based on Xilinx’s PCIe endpoint block + programmable memory access core • Standard Vendor ID + device ID for the DAMC2 card • Basic driver already been developed • A GUI to access individual registers (defined according to application) • II Bus/Interface will be used to integrate PCIe to CC related modules in the system • Individual registers + memory area defined in a VHDL package file • Use of internal and external registers and methods to access them

  12. Firmware progress • Firmware block diagram with the II Interface • Control and clocking part involves cores for the clock MUX, synthesiser etc. on DAMC2 • The registers block on the old firmware diagram is replaced by II

  13. Firmware progress • Telegram data transfer • Being redeveloped according to the latest • Basic serial transmit and receive module based on a UART like handshaking and synchronising is in the repository for the TR firmware • The telegram clock changed to 130 MHz • A protocol on top of this physical layer has to be defined for getting CC related information from the TR board • On-going work with P. Gessler and H. Kay • FAST data transmit • The existing module will be modified to integrate to the II interface

  14. Veto logic • Use of the TPS (Toroid Protection System) for a possible VETO source • Developed by M. Werner and D. Noelle • A distributed system consisting of coils detecting the charge along the beam line plus their backend electronics • The analogue charge data is digitised and processed to provide information for MPS and other systems • A chain-like topology using digital fibre transmission lines to see how much charge has reached the next charge monitors Toroids Guns Undulator Undulator Linac Sections

  15. Veto logic • Each toroid backend consists of a DAMC2 board and a custom RTM • SFPs on the DAMC2 are used for fibre communication to other toroids and other systems • Single-mode fibre – exact bit rate / protocol to be defined • One TX channel is available for the VETO system • Data from minimum two toroids envisaged for the VETO system • At the beginning and end of the undulators • Exact data to be determined (normalised charge data + train/bunch ID?) TX only @ 1.083 Gb/s (2.16 Gb/s ?) DAMC2 TPS SFPs (4 in total) TPS To FEEs VETO LOGIC on FPGA VETO FANOUT (RTM) Charge data from the TPS + Bunch ID ?

  16. Future plans • RTM manufacture • Reception of the RTMs and initial testing • Card power-up important • Firmware debug/development • II Bus integration • Drivers • Testing the RTM + DAMC2 in the crates • Testing Standalone Operation • Testing with the TR (telegram/trigger/…) • Testing with the Test Card A (FAST data + clock) • VETO logic • TPS feasibility document • Initial work on VETO logic • Work on TPS data RX/TX ?

More Related