[time-nuts] GPSDO with a RaspberryPi

Tom Van Baak tvb at LeapSecond.com
Fri Mar 1 06:38:38 EST 2013

Consider also using two identical 24-bit counters. While one is rapidly counting up the other is leisurely shifted out with zeros shifting in. When the next 1PPS (synchronized) occurs you simply gate the clock to the other counter. This freezes the number in one counter and begins counting in the other counter. If done carefully you never lose any clock cycles as you swap between counters. Now if they only made a 8-pin CPLD or FPGA I'd be happy.


----- Original Message ----- 
From: "Azelio Boriani" <azelio.boriani at screen.it>
To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
Sent: Friday, March 01, 2013 1:40 AM
Subject: Re: [time-nuts] GPSDO with a RaspberryPi

> Javier:
> CSelect after PPS -> yes, the CSelect must occur after the PPS has loaded
> new data. This is managed using the GPS serial NMEA output. The NMEA
> strings are output after the PPS, timing the sequence of events.
> Two registers and data transfer-> well, I have two registers: the data gets
> transferred using SClockIn, generated internally and then shifted out using
> SClockIn generated externally by the SPI, sort of oring the two clock
> sources? Or, using the 10MHz as a clock and then gating the various sources
> to enable this (loading) or that (shifting)... this last seems the correct
> one but in my opinion more suitable for an FPGA environment. With this CPLD
> I tried to implement something that can be made out of dicrete logic too.
> The metastability from the PPS latching the counter is indeed a problem:
> rarely do I see out of range numbers and have to filter them out.
> On Fri, Mar 1, 2013 at 9:22 AM, Javier Serrano <
> javier.serrano.pareja at gmail.com> wrote:
>> On Fri, Mar 1, 2013 at 12:47 AM, Azelio Boriani
>> <azelio.boriani at screen.it> wrote:
>> > Javier:
>> > the 24bit counter is clocked only by the 10MHz and is running
>> continuously,
>> > the PPS is the most important signal. The LSClock is the clock for the
>> > latch: this latch has to be clocked to shift out its content serially and
>> > has to be loaded with the PPS from the GPS (PPSReference). I see no other
>> > way to deal with this other than selecting the two clock sources for this
>> > latch/shifter.
>> You need two registers:
>> - One that takes a snapshot of the counter value when the
>> Clk10MHz-synchronized PPSReference arrives.
>> - One that gets read out using SClockIn.
>> Ideally you would sequence things so:
>> - Once the snapshot is taken you drive a data valid strobe
>> (Clk10MHz-clocked) which gets detected in the SClockIN domain.
>> - Then the snapshot is transferred to the second register mentioned
>> above, using SClockIn.
>> - Only then it gets read out, using SClockIn.
>> > When the chip select (CSelect) line is high, the PPS is
>> > selected as a clock, when the CSelect is low (SPI trying to read) the
>> > SClockIN is selected as a clock. I know it is not a good practice to use
>> > gated clocks but at times it seems there is no way out and the CPLD is
>> only
>> > 64 cells wide...
>> I am sorry I did not have time to read the whole material. I just went
>> quickly through the VHDL. Seen in isolation, there are things that can
>> go wrong if you don't control when the read-out happens, e.g. if
>> CSelect goes to '1' in the middle of the PPSReference pulse you will
>> have a spurious rising edge and a bad time stamp. But if you control
>> when CSelect goes high then this could be a non-issue. I also did not
>> consider CPLD gates available.
>> Anyway, the biggest problem I see with the code as it stands is the
>> clocking of the 24-bit counter output with an asynchronous signal
>> (PPSReference). I think that really needs to be fixed in any event.
>> Cheers,
>> Javier

More information about the time-nuts mailing list