In my defence, <100ns is also <100us :) On Fri, 8 Mar 2019, 2:54 pm Dan Werthimer, <d...@ssl.berkeley.edu> wrote:
> > 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. > -- 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.
