Hi Franco, The general principle is generally this --
We assume that the system has 1. A CPU-based control computer (a laptop / desktop / posh server / whatever) which has a standard NTP client running. NTP allows this computer to know the time good to some number of milliseconds. 2. FPGAs in the system have an GPS pulse-per-second (PPS) input, which sends a pulse on each UTC second, good to 10s of nanoseconds. 3. Some firmware on your FPGAs which allows an arm signal to be generated by software, causing some internal counter to be generated from the next PPS pulse edge. You then do the following: On your control computer you sleep until a second boundary passes. Then you issue an arm of the FPGA boards. You don't know exactly when this arm arrives -- NTP isn't that accurate, and the latency of issuing an FPGA write is unknown -- this is why you can't use this signal alone for defining timing. But... you *do* know the next second boundary that will follow the arm. On this second, a PPS (which is good to <100us) triggers the reset of your FPGA's counter logic. You can then use this counter to indicate time in FPGA cycles since reset. Since you know the reset time, if you use this counter to stamp data packets you can figure out the time associated with the data in these packets. You can probably do something in python like: from time import * sleep(1 - (time() % 1)) # Sleep until the next second boundary sleep(0.1) # sleep until 100ms past this second my_fpga.arm() # Arm the sync generator logic arm_time = int(time()) + 1 # The next second tick will pass at this time and reset your boards # write the arm_time somewhere, so that when you get a packet timestamped with some counter, you can do # time_of_this_packet = arm_time + (counter_value / counter_ticks_per_second) Maybe that was helpful. Maybe it will add to your confusion. Probably the above pseudo code doesn't work in real life :) Cheers Jack On Fri, 8 Mar 2019 at 10:50, Franco <[email protected]> wrote: > Hi James, > > Thank you for your answer. Yes, I use and ADC for data acquisition. I > understand the general idea of your system. What I don't understand is > where you get the start time of the ROACH2. Is generated by the TRF? Is > there a different system that initialize all the synchronized devices and > that record the start time? Sorry if it is basic question. > > Thanks, > > Franco > > On Thu, Mar 7, 2019 at 3:52 AM James Smith <[email protected]> wrote: > >> Hello Franco, >> >> As I understand it, PTP wasn't terribly useful in our application (though >> I wasn't involved with this directly). You can probably sync the little >> Linux instance that runs on the ROACH2, but getting the time information >> onto your FPGA may prove somewhat tricky. >> >> Are you using an ADC card in the ROACH2? Or is the data digitised >> separately? >> >> What we've done with ROACH and ROACH2 designs in the past is more or less >> this: >> >> - FPGA's clock comes from a timing & frequency reference (TFR). >> - ROACH2 gets a 1PPS input from the same TFR. >> - In the FPGA logic there's a counter which is reset as part of the >> initialisation, and some logic that starts the counter going after a set >> number of 1PPS pulses (two to three, I forget exactly now). >> - The output of this counter is pipelined along with the data and >> then sent out as part of the SPEAD data on the 10GbE network. >> >> The idea here being that you know with a fairly high degree of precision >> which pulse your ROACH was initialised on. The counter that comes through >> on the SPEAD packet counts in FPGA clock cycles (or multiples thereof, >> perhaps you might want to count in spectra), and then you can use the start >> time to calculate the timestamp of each packet (Unix time, MJD, whichever >> your preferred reference is). >> >> Hope that helps. >> >> Regards, >> James >> >> >> On Wed, Mar 6, 2019 at 7:41 PM Franco <[email protected]> wrote: >> >>> Dear Casperiites, >>> >>> I was given the task of timestamping ROACH2 spectral data in a telescope >>> that uses PTP (precision time protocol) as a synchronization protocol. I >>> understand that ROACH's BORPH come preloaded with NTP (network time >>> protocol) libraries/daemos, but PTP is preferred because is already in use >>> in the telescope, and it achieves greater time precision. >>> >>> Does somebody know if it is feasible to compile/install PTP libraries in >>> BORPH? >>> >>> Alternatively, we have though of sending the ROACH the current time >>> through a GPIO pin using IRIG-B timecode standard. Has anybody done >>> something similar in the past? >>> >>> Thanks, >>> >>> Franco >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
