1 / 9

The DAQ for the PLT

A modest system to read out and configure the Pixel Luminosity Telescope tasks, providing clocks, triggers, data readout, health monitoring, state recording, and calibration. Smaller, simpler, and less data compared to CMS Pixels. Supports histogramming, event spying, and dedicated supervisors for FEDs, FECs, and TTC. Requires prototype system development and dedicated team for code development and testing.

lindardavis
Download Presentation

The DAQ for the PLT

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. The DAQ for the PLT A modest system to read out and configure the Pixel Luminosity Telescope

  2. Tasks for the DAQ • Download parameters to pixel detectors • Set parameters for the readout system • Provide clocks and triggers • Readout and summarize detector data • Monitor the health of the DAQ/detector • Record the state DAQ/detector • Calibration

  3. Simpler system than CMS pixels • No Trigger Throttling system • No Tracker FEC, only Pixel FEC • No Slink for DAQ from Front Ends • Probably a single crate for FEDs/FECs • Smaller number of channels and modules • More like the test system at the TIF • No Active cooling • No staged start up of detector

  4. Less Data than CMS Pixels • Histograms of PLT coincidences read out at ~Hz • Event spying is done at ~kHz • Bandwidth is small enough to use VME and have space left for monitoring tasks • Number of constants to download is much less • Again, more like testing, say, parts of the Forward Pixel detectors at the TIF

  5. PLT data Flow (minimum estimate) Can be read out ~ 3 MB/s Nowhere near the full VME bandwidth is used Standard FED (x1) PLT PC(1 or more) 1 kHz (~200 kB/s) Spy Data PLT Pixel Data (Addr. Pulse Ht.) Telescope (X16) PLT Trig (1 kHz) TTC FEC Custom FED (x2) Raw FO 1 kHz (~16 kB/s) strip out raw data Fast OR Outputs 40 MHz 16 Histograms 2.7 Hz (~312 kB/s) Histogram 3-fold coincidences (3564 channels) X 16 Can be read out > 10 MB/s ~528 kB/s Total VME Data rate

  6. PLT DAQ proposal • Take components of the working Pixel DAQ hardware and software and modify them as needed, such as is done for the Test stands at the TIF, Cornell, and PSI. • There is some subtlety in the triggering • Spying is done on the last triggered event • Triggers must be serial with the readout to maintain synchronicity • Need trigger signals from TTC for BC0 etc. • L1A triggers probably limited by messaging (soap?) speed to ~100’s Hz (may need occasionally) • Otherwise can send our own simply with a NIM signal from FED/FEC crate (from controller)

  7. PLT DAQ proposal • Other scenarios are of course possible, but will likely require new FED firmware. • Also, need to add new software for the flash ADC histogramming FEDs • Some overhead in keeping the Pixel Software • Separate supervisors for FEDs and FEC and TTC (and one overall supervisor) • May be easier for PLT to have 2 supervisors • Elaborate Pixel database is likely overkill for the PLT • Would be good to have a prototype system soon • Experience shows trying to get things working at P5 as soon as possible is important • I.e. probably need to share a TTC crate

  8. PLT DAQ proposal • Developing the PLT DAQ is essentially constructing a PLT test bench from existing software and hardware • A basic system can consist of one crate with a PxlFED, FEC, one detector, and a TTCci with an opto-splitter • More desirable, separate TTC crate • More TTcci’s available this spring • Crates and Controllers on order • ETA this spring for a prototype system • No kidding, we’ve done this before, just need the stuff

  9. PLT DAQ Proposal • Experience with the pixel detector shows that there needs to be a dedicated group working on code all the time • The early testing phase will require less people (spring 08) • Several of us working part time should be ok • Working on getting software components working at institutions with a few hardware components • Whole system test will be harder (spring-summer 08) • Several of us working half time or more • The goal is to have a working system with the XDAQ based DAQ • Some components can be missing at this point • Integration into CMS at P5 will probably be the hardest (???) • There will be several of us working full time until all our issues are resolved for running at P5 • Estimate 3.5 FTE’s to get system installed and functional (for check out, initial calibration and test running) at P5. • Having a partial test system available for integration tests would be useful if we can manage it.

More Related