Status Report of the ROD Demo Board Testing at BNL

1. This presentation will probably involve audience discussion, which will create action items. Use PowerPoint to keep track of these action items during your presentation • In Slide Show, click on the right mouse button • Select “Meeting Minder” • Select the “Action Items” tab • Type in action items as they come up • Click OK to dismiss this box • This will automatically create an Action Item slide at the end of your presentation with your points entered. Status Report of the ROD Demo Board Testing at BNL Give an update of what we have done with the ROD system at the BNL test stand Summarize our current understandings Kin Yip

2. By changing codes in the input FPGA/DSP of PU, we can take data with 32 samples.

3. We have used 2 PU to read all 128 channels of a FEB successfully. Capacitor underneath

4. 1 Features or problems • The Output Controller (OC) can be configured to transfer and store 16 Mbytes of data in the SDRAM on the ROD motherboard • In the 5 sample operation, regardless of the trigger frequency, when we read the data out from the RAM, we have found: • the 183rd event misses the last word “0xe0f00000” • the following event is full of “0x00000e0e” plus header/trailer  a total of 3613 words • then it recovers with normal events • the same problem occurs again (almost regularly) after every 251 events • For 32 samples, • the same data corruption happens at the 125th event • Differences: • it never recovers and the event size varies from event to event afterwards • EOE “LED” turns on at about the 125th event (which means that OC does not find the end-of-event word in an event from the PU) • … remind you that data are formatted in a slightly different way in PU for the 32 sample operation

5. 1 Features or problems Some understandings : • For 5 samples, data corruption happens 0.5% of the events. • We have seen similar big events of “e0e” when we ran in the offline mode. • FEB is not to be blamed. • At the beginning of each PU event, there is a word which tells OC the no. of words are in each event. • OC reads “0x00000e0e” and interprets it as the no. of words in the event (0xe0e  3598). This explains why we see about 3600 words (including header and trailer put by the OC) for the faulty event. • Using oscilloscopes/probes, we see that OC probably intends to read event(s) even when the FIFO in the PU is empty ( when the FIFO_EvtRdy signal is low) • What makes OC do that ? • Even when the input data hadproblem, we’d still get the right length/format of data • PU/OC format and pass the data even though the data is not completely right

6. 2 Pushed to the limit • Running in the mode that OC passes data to the RAM : • Normally, you would not see the BUSY signal until the RAM is full (16 Mbytes) as data are not taken away from the PU by the OC • However, at trigger frequency > ~10 kHz, we see the BUSY signal well before the RAM is full  a frequency limit for us • Running in the mode that OC passes data to the non-existent SLINK: • We do not see the BUSY signal; but we see the “EOE” LED on, which reflects data reading error, at trigger frequency > ~11.1 kHz  another kind of frequency limit for us • Probably not a limit, but we see VME read errors when we try to probe the status of register at high trigger frequency (~kHz) • CERN setup has also seen this

7. 2 Pushed to the limit • A genius explanation by S. Simion for the “11.1 kHz threshold” for the EOE problem: • When the empty FIFO in the PU is read, OC sees 0xe0e (the last word in the FIFO) and interprets it as the no. of words in the event. • 0xe0e  25 ns = 89.95 s. • At low trigger rate, OC would finish reading an ~3600 word event as there is no other event coming in and 0xe0e would be seen as the end of a PU event (as it should be). • At trigger rate > 1/(89.95 s), ie. ~ 11.1 kHz, a new event would be written to the FIFO before a complete event is read. This prevents the OC from finishing reading a full event (not seeing 0xe0e at the end)  prompts the EOE error status • This may not explain everything but it sounds very plausible for the EOE problem.

8. Personal thoughts: • As a quick fix, can the “e0e” word be cleared (to 0) when the FIFO is empty ? • Is it possible for the PU not to allow OC from reading anything when its FIFO is empty ? • Should PU have better hand-shaking mechanism with the OC ?

9. Plans … • Find solutions to the problems we’ve seen • Integrate with the rest of the read-out chain of the BNL LAr electronics mock-up • Write more sophisticated calibration codes in the DSP to do calibration (J. Ye from SMU is helping us with this)