Hello Franco, Jack's email explained more explicitly what I tried to convey. Did it make it clear?
Regards, James On Sat, Mar 9, 2019 at 12:44 AM Jack Hickish <jackhick...@gmail.com> wrote: > 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 <francocuro...@gmail.com> 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 <jsm...@ska.ac.za> 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 <francocuro...@gmail.com> 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 "casper@lists.berkeley.edu" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to casper+unsubscr...@lists.berkeley.edu. >>>> To post to this group, send email to casper@lists.berkeley.edu. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> To post to this group, send email to casper@lists.berkeley.edu. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
