hi franko: i think jack meant "<100ns" in his email below. (not "<100us").
here's another description of the technique used in casper instruments to get accurate time stamps: from peter mcmahon's thesis, section C.5: https://arxiv.org/pdf/1109.0416.pdf C.5 Precise Timing using ARM and 1PPS The purposes of the inclusion of a counter value in output packets are to enable the detection of packet loss, and to enable accurate timing of spectral data. When the IBOB is powered up, an internal counter starts counting with every clock cycle (nominally at 200MHz). Because the startup time is in general not known with precision, the counter value is, on its own, not very useful for time-tagging. However, we provide a means to reset the counter at a precisely known time, and this enables the user to determine the time a spectrum arrived very accurately. The scheme is fairly simple: the control computer (the one connected to the IBOB via the 100MbitE port) must be set up to use NTP so that its clock is accurate to within a few tens of milliseconds. At approximately half-way through a chosen second (e.g. at approximately the time 14:26:53.5) the control computer should toggle the register 110 reg arm over telnet (i.e. call the command regwrite reg arm 0, and then immediately follow this with regwrite reg arm 1; the computer should be connected to the IBOB via telnet before doing this, so that it is guaranteed that this toggle will happen within approximately 0.4 seconds). This will arm the IBOB, which means that it is set to a state such that when the next 1PPS signal arrives (i.e. on the next second), the internal counter will reset to value 0. The counter will then not be reset until the next time the IBOB is re-armed and another 1PPS signal arrives. In our example, this means that at precisely (with the accuracy of the 1PPS signal and the IBOB clock source) the time 14:26:54.0, the counter will be reset. The data recorder computer can be informed that this is the case, and thus it will be aware of the precise time-stamp of each spectrum from that point on, based on the counter value dan On Fri, Mar 8, 2019 at 2:44 PM 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.
