>Everyone, Please see attached for several experiments that I expect will place >the greatest demands on the timing resolution of the RTIO. -Joe
None of the foregoing discussion has anything to do with the timing resolution of the RTIO core. It timestamps all events with a resolution of ~1 ns, IIRC - depends on the exact FPGA clock frequency used. One can use either a 32-bit timestamp (allowing for individual experiments up to ~4 seconds long before timestamps roll over) or a 64-bit timestamp, in which case the timestamps roll over every 14 millenia or so. For all of the experiments you have proposed, Joe, the desired resolution for the timestamps is well within the capabilities of the RTIO core. The question for the different experiments is really the count rate. If events arrive at the FPGA faster than the soft processor can read the timestamps in from the FIFO queue and send them off to their next location, then we need the FIFO to be deeper. For your experiments 1 and 2 the count rate is ~1 MHz and so the processor will probably not be able to read all the events out of the queue as fast as they come in. In that case, we need a FIFO that can hold timestamps for the desired number of events (~10k). Sebastien has stated that there is enough real estate on the FPGA for a 65k event FIFO if desired (with plenty of room to spare), which would work fine for these experiments. For experiments 3 and 5, the count rates are lower (~200 kHz) and so probably the processor will be able to keep up with them as they come in. Even if not, again a 65k event FIFO would be more than sufficient. For experiment 4, where timestamps are not required, the FIFO queue of timestamps could be allowed to overflow as long since you will only be reading a counter value from the RTIO channel, not looking at timestamps. Sebastien, how does the RTIO core handle overflow of the FIFO queue for inputs? Best, Daniel _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
