1 / 9

“High speed” FEB-ROD Testing at BNL

“High speed” FEB-ROD Testing at BNL. Short report for our FEB-ROD system at BNL taking data at ~ 100 kHz: Data Integrity Noise Continuity Further studies …. Kin Yip. 1. OC firmware problem solved ….

newman
Download Presentation

“High speed” FEB-ROD Testing at BNL

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. “High speed” FEB-ROD Testing at BNL • Short report for our FEB-ROD system at BNL taking data at ~ 100 kHz: • Data Integrity • Noise • Continuity • Further studies … Kin Yip

  2. 1 OC firmware problem solved … • Daniel La Marra has provided the latest and greatest version of the firmware for the OC (Output Controller) on the ROD demo board. • Repetitive testing  NO more data corruption in using all the 16 MBytes of SDRAM for storing data ! • Seems to be the most reliable version so far … and make it possible for us to do what I am going to show here. • 16 Mbytes can hold up to 15947 events, each of 263 words --- including some redundant words. These are already many events for one to check data integrity etc. • I have used it to read data at ~100 kHz (which we have checked and verified using an oscilloscope)

  3. Testing at 100 kHz : Noise/Pedestal Run

  4. Testing at 100 kHz : Fixed Pattern of 0x111

  5. 2 No missing events … • I have checked that the BCID’s (Bunch Crossing ID) from OC & PU agree with those of FEB except the famous difference of “1” • The BCID would be reset at ~0xdef and one has to take that into consideration when making comparison • All BCID’s come from the same TTC system • For the time being, we use a clock divider to generate triggers at ~100 kHz from the ~40MHz and the trigger of course is synchronous with the clock. I start/stop the trigger by plugging/unpluging a wire. • At trigger rate  100 kHz, we see regular intervals of BCID’s (such as 400 for ~100 kHz) between consecutive events, ie. • eg. BCID(i+1)– BCID(i) = 400 ( in this example and taking care of the 0xdef resetting etc.)  No missing or skipped events • At trigger rate  100 kHz, we occassionally see irregular intervals of BCID’s  There are events skipped by the FEB because FEB needs ~9.6 µs for digitization

  6. 2 Incidences of discontinuities vs trigger rate • At trigger rate  100 kHz, FEB is quite unstable but I have managed to measure at certain rates • Apparently, events are just skipped at higher rates but the data do not seem to be over-written

  7. 3 Noise  RMS of the pedestals Comparion of noise measurements Not at all surprising because our events are separated by the same time interval and there is no overlap between events

  8. 4 “Further studies” … • Our more advanced trigger handling system is coming which would give us significantly more flexibility to control the rates and patterns of triggers through software, and stop the trigger upon BUSY(from ROD) etc. • Two ways for us to take data in sustained mode • Take data at trigger rate of 100 kHz and use just the 16 Mbytes of SDRAM, stop the trigger when the SDRAM is full and start over again when all data in SDRAM is transferred to the disk • Use SLINK and connect it to a PCI board • Develop the necessary calibration codes in the DSP of PU to carry out real calibration using the LAr electronics mock-up at BNL (including FEB, calibration boards etc.)

More Related