I've got a project coming up in which one of the things I'm going to need to do is take in the 1 PPS output from a GPS receiver and align it to the 100 MHz frequency reference clock. The problem here is that the phase relationship is static but undefined. There's plenty of time somewhere to not violate the setup time, but I have to find where it is. My thought had been to use one of the FPGA PLLs to spin up 8 phases (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on all of them. Then resychronize those to the 0� clock, read the thermometer code, and figure out what the data phase is. Then I can use the value opposite that and know I've got enough margin to park a semitrailer in. All well and good, except it dawns on me that I don't know how to convince the tools to make timing for that. Somehow my SDC file has to call for running the input signal from the input pin to 8 flops such that the clock/data skew is less than 1 ns. Anyone know how I'd do such a thing? Altera seems to support set_max_skew, which might do it if I can disentangle the arcana of the syntax from http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm But I'm not necessarily wedded to Altera on this project. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Constraining data to out-of-phase clocks
Started by ●May 13, 2016
Reply by ●May 14, 20162016-05-14
On 5/13/2016 7:18 PM, Rob Gaddi wrote:> I've got a project coming up in which one of the things I'm going to > need to do is take in the 1 PPS output from a GPS receiver and align it > to the 100 MHz frequency reference clock. > > The problem here is that the phase relationship is static but undefined. > There's plenty of time somewhere to not violate the setup time, but I > have to find where it is. > > My thought had been to use one of the FPGA PLLs to spin up 8 phases > (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on > all of them. Then resychronize those to the 0� clock, read the > thermometer code, and figure out what the data phase is. Then I can > use the value opposite that and know I've got enough margin to park a > semitrailer in. > > All well and good, except it dawns on me that I don't know how to > convince the tools to make timing for that. Somehow my SDC file has to > call for running the input signal from the input pin to 8 flops such > that the clock/data skew is less than 1 ns. > > Anyone know how I'd do such a thing? Altera seems to support > set_max_skew, which might do it if I can disentangle the arcana of the > syntax from > http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm > But I'm not necessarily wedded to Altera on this project.To make sure I understand your issue, you want to *measure* the phase of the clock the 1 pps is detected on to 1/8th the resolution of the 100 MHz clock itself? If you are not trying to measure that phase relationship, I'm not sure why you would want to use 8 phases. You can use the FFs in the I/O blocks to capture a true and inverted clocked version of the signal on that pin. Each of four pins can receive the same signal and be clocked by differently phased clocks. I don't know how much differential timing you will see between the four clocks as well as the true/inverted clocked FFs. Another way to do this is to use a SERDES which PLLs the clock up in frequency. But I don't think this lets you correlate the data received to the main clock in an absolute way. Otherwise I think you may need to do the sampling in external logic and read the thermometer code in parallel. A friend did something like this where he used a digital delay line that I think he delay locked to the 1 PPS so he was on the edge of detecting the 1 PPS on the same clock each cycle. I don't recall this for sure, but it was something like this. His circuit was generating a 1 PPS for an new atomic clock at the Naval Observatory. It sync'ed up to the existing 1 PPS for a while to find the right phase, then locked and ran. Sounds like what you are doing. -- Rick C
Reply by ●May 14, 20162016-05-14
On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote:> I've got a project coming up in which one of the things I'm going to > need to do is take in the 1 PPS output from a GPS receiver and align it > to the 100 MHz frequency reference clock. > > The problem here is that the phase relationship is static but undefined. > There's plenty of time somewhere to not violate the setup time, but I > have to find where it is. > > My thought had been to use one of the FPGA PLLs to spin up 8 phases > (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on > all of them. Then resychronize those to the 0° clock, read the > thermometer code, and figure out what the data phase is. Then I can use > the value opposite that and know I've got enough margin to park a > semitrailer in. > > All well and good, except it dawns on me that I don't know how to > convince the tools to make timing for that. Somehow my SDC file has to > call for running the input signal from the input pin to 8 flops such > that the clock/data skew is less than 1 ns. > > Anyone know how I'd do such a thing? Altera seems to support > set_max_skew, which might do it if I can disentangle the arcana of the > syntax from > http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm> But I'm not necessarily wedded to Altera on this project.There's not enough foreshadowing for me to figure out where the thermometer comes in. But I have lots of questions! How precisely do you really need to know the 1PPS? How can you know that the phase alignment is static, yet not know what it is? The only way I can think of that you'd have a static phase alignment is if there's a PLL locking to the 1PPS, and that implies a known phase alignment. Why not use a 100MHz clock that _is_ of known phase alignment? Seems to me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp with an integrator would add up to phase lock. Certainly if you're using a free-running oscillator, even a crystal one, your phase will, at best, be drifting all over the place, and it'll probably have enough of an offset to it that it'll be running away rather than exhibiting a random walk. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●May 14, 20162016-05-14
On 5/14/2016 12:48 AM, Tim Wescott wrote:> On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote: > >> I've got a project coming up in which one of the things I'm going to >> need to do is take in the 1 PPS output from a GPS receiver and align it >> to the 100 MHz frequency reference clock. >> >> The problem here is that the phase relationship is static but undefined. >> There's plenty of time somewhere to not violate the setup time, but I >> have to find where it is. >> >> My thought had been to use one of the FPGA PLLs to spin up 8 phases >> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on >> all of them. Then resychronize those to the 0° clock, read the >> thermometer code, and figure out what the data phase is. Then I can use >> the value opposite that and know I've got enough margin to park a >> semitrailer in. >> >> All well and good, except it dawns on me that I don't know how to >> convince the tools to make timing for that. Somehow my SDC file has to >> call for running the input signal from the input pin to 8 flops such >> that the clock/data skew is less than 1 ns. >> >> Anyone know how I'd do such a thing? Altera seems to support >> set_max_skew, which might do it if I can disentangle the arcana of the >> syntax from >> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/ > tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm >> But I'm not necessarily wedded to Altera on this project. > > There's not enough foreshadowing for me to figure out where the > thermometer comes in. > > But I have lots of questions! > > How precisely do you really need to know the 1PPS? > > How can you know that the phase alignment is static, yet not know what it > is? The only way I can think of that you'd have a static phase alignment > is if there's a PLL locking to the 1PPS, and that implies a known phase > alignment.I can answer that, the 100 MHz and 1 PPS are from two different, but both very stable sources... most likely. I expect this is like the circuit my friend designed, a 1 PPS generator, or at least an internal alignment to the external 1 PPS, but clocked from the local 100 MHz clock. You would figure at any given time the phase relationship is stable, but not known apriori. With a clock stability of 10^-... pick a number, the phase would not change very fast.> Why not use a 100MHz clock that _is_ of known phase alignment? Seems to > me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp > with an integrator would add up to phase lock.1 PPS from GPS, I expect clocked into the FPGA by a local atomic clock.> Certainly if you're using a free-running oscillator, even a crystal one, > your phase will, at best, be drifting all over the place, and it'll > probably have enough of an offset to it that it'll be running away rather > than exhibiting a random walk.How about rubidium or cesium? I think they get better than 10^-12, maybe 10^-15. -- Rick C
Reply by ●May 14, 20162016-05-14
On 05/13/2016 04:18 PM, Rob Gaddi wrote:> I've got a project coming up in which one of the things I'm going to > need to do is take in the 1 PPS output from a GPS receiver and align it > to the 100 MHz frequency reference clock. > > The problem here is that the phase relationship is static but undefined. > There's plenty of time somewhere to not violate the setup time, but I > have to find where it is. > > My thought had been to use one of the FPGA PLLs to spin up 8 phases > (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on > all of them. Then resychronize those to the 0� clock, read the > thermometer code, and figure out what the data phase is. Then I can > use the value opposite that and know I've got enough margin to park a > semitrailer in. > > All well and good, except it dawns on me that I don't know how to > convince the tools to make timing for that. Somehow my SDC file has to > call for running the input signal from the input pin to 8 flops such > that the clock/data skew is less than 1 ns. > > Anyone know how I'd do such a thing? Altera seems to support > set_max_skew, which might do it if I can disentangle the arcana of the > syntax from > http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm > But I'm not necessarily wedded to Altera on this project. >The 1PPS signals out of the GPS receivers that I have seen, advertise 50nS accuracy. Your 100MHz clock has a period of 10nS. From what I understand of your project, I would just put the 1PPS signal in through a couple of sync FF's and then compensate for an assumed delay of 2 clock cycles in the application of the sync'ed 1PPS signal downstream. The phase relationship between the 1PPS input and the local 100MHz clock won't be all that static unless you phase lock the 100MHz clock to the 1PPS. Even an exotic local oscillator is going to drift around with time and temperature compared to the 1PPS. Bobh
Reply by ●May 15, 20162016-05-15
On 5/14/2016 1:17 AM, rickman wrote:> On 5/14/2016 12:48 AM, Tim Wescott wrote: >> On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote: >> >>> I've got a project coming up in which one of the things I'm going to >>> need to do is take in the 1 PPS output from a GPS receiver and align it >>> to the 100 MHz frequency reference clock. >>> >>> The problem here is that the phase relationship is static but undefined. >>> There's plenty of time somewhere to not violate the setup time, but I >>> have to find where it is. >>> >>> My thought had been to use one of the FPGA PLLs to spin up 8 phases >>> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on >>> all of them. Then resychronize those to the 0° clock, read the >>> thermometer code, and figure out what the data phase is. Then I can use >>> the value opposite that and know I've got enough margin to park a >>> semitrailer in. >>> >>> All well and good, except it dawns on me that I don't know how to >>> convince the tools to make timing for that. Somehow my SDC file has to >>> call for running the input signal from the input pin to 8 flops such >>> that the clock/data skew is less than 1 ns. >>> >>> Anyone know how I'd do such a thing? Altera seems to support >>> set_max_skew, which might do it if I can disentangle the arcana of the >>> syntax from >>> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/ >> tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm >>> But I'm not necessarily wedded to Altera on this project. >> >> There's not enough foreshadowing for me to figure out where the >> thermometer comes in. >> >> But I have lots of questions! >> >> How precisely do you really need to know the 1PPS? >> >> How can you know that the phase alignment is static, yet not know what it >> is? The only way I can think of that you'd have a static phase alignment >> is if there's a PLL locking to the 1PPS, and that implies a known phase >> alignment. > > I can answer that, the 100 MHz and 1 PPS are from two different, but > both very stable sources... most likely. I expect this is like the > circuit my friend designed, a 1 PPS generator, or at least an internal > alignment to the external 1 PPS, but clocked from the local 100 MHz > clock. You would figure at any given time the phase relationship is > stable, but not known apriori. With a clock stability of 10^-... pick a > number, the phase would not change very fast. > > >> Why not use a 100MHz clock that _is_ of known phase alignment? Seems to >> me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp >> with an integrator would add up to phase lock. > > 1 PPS from GPS, I expect clocked into the FPGA by a local atomic clock. > > >> Certainly if you're using a free-running oscillator, even a crystal one, >> your phase will, at best, be drifting all over the place, and it'll >> probably have enough of an offset to it that it'll be running away rather >> than exhibiting a random walk. > > How about rubidium or cesium? I think they get better than 10^-12, > maybe 10^-15.Now that I have read JL's post, I understand. You have two signals provided by your customer and not enough information to know how they are related or how to use them. This will all depend on what you need to use the signals for. In other words, you have not provided enough info for us to know how to design your system. So how are you going to use these two signals? What are the requirements you need to meet? -- Rick C
Reply by ●May 16, 20162016-05-16
BobH wrote:> On 05/13/2016 04:18 PM, Rob Gaddi wrote: >> I've got a project coming up in which one of the things I'm going to >> need to do is take in the 1 PPS output from a GPS receiver and align it >> to the 100 MHz frequency reference clock. >> >> The problem here is that the phase relationship is static but undefined. >> There's plenty of time somewhere to not violate the setup time, but I >> have to find where it is. >> >> My thought had been to use one of the FPGA PLLs to spin up 8 phases >> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on >> all of them. Then resychronize those to the 0� clock, read the >> thermometer code, and figure out what the data phase is. Then I can >> use the value opposite that and know I've got enough margin to park a >> semitrailer in. >> >> All well and good, except it dawns on me that I don't know how to >> convince the tools to make timing for that. Somehow my SDC file has to >> call for running the input signal from the input pin to 8 flops such >> that the clock/data skew is less than 1 ns. >> >> Anyone know how I'd do such a thing? Altera seems to support >> set_max_skew, which might do it if I can disentangle the arcana of the >> syntax from >> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm >> But I'm not necessarily wedded to Altera on this project. >> > > The 1PPS signals out of the GPS receivers that I have seen, advertise > 50nS accuracy. Your 100MHz clock has a period of 10nS. From what I > understand of your project, I would just put the 1PPS signal in through > a couple of sync FF's and then compensate for an assumed delay of 2 > clock cycles in the application of the sync'ed 1PPS signal downstream. >You know how sometimes when you get started on a project, and you get some assumptions so firmly in your head that you don't even realize that they're just assumptions? I had a substantially better opinion of the jitter on the 1 PPS than is actually warranted. There are a _COUPLE_ of receivers out there with 1 PPS jitter down to 10 ns (RMS), but for the most part you're entirely correct. And even at 10, there's no static relationship against a PLL-locked 100 MHz; it's just every pulse for itself. You'd think with as many times as I've learned that lesson, one of these times it would stick.> The phase relationship between the 1PPS input and the local 100MHz clock > won't be all that static unless you phase lock the 100MHz clock to the > 1PPS. Even an exotic local oscillator is going to drift around with time > and temperature compared to the 1PPS. >Now that's a question I have no idea how to resolve. Is the exotic LO (let's assume cesium for fun) drifting and the PPS stable, or is it (I'd guess) that no matter how stable the LO that the PPS is walking around? Making claims of objective truth on these timescales is hard. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●May 16, 20162016-05-16
rickman wrote:> On 5/14/2016 1:17 AM, rickman wrote: >> On 5/14/2016 12:48 AM, Tim Wescott wrote: >>> On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote: >>> >>>> I've got a project coming up in which one of the things I'm going to >>>> need to do is take in the 1 PPS output from a GPS receiver and align it >>>> to the 100 MHz frequency reference clock. >>>> >>>> The problem here is that the phase relationship is static but undefined. >>>> There's plenty of time somewhere to not violate the setup time, but I >>>> have to find where it is. >>>> >>>> My thought had been to use one of the FPGA PLLs to spin up 8 phases >>>> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on >>>> all of them. Then resychronize those to the 0� clock, read the >>>> thermometer code, and figure out what the data phase is. Then I can use >>>> the value opposite that and know I've got enough margin to park a >>>> semitrailer in. >>>> >>>> All well and good, except it dawns on me that I don't know how to >>>> convince the tools to make timing for that. Somehow my SDC file has to >>>> call for running the input signal from the input pin to 8 flops such >>>> that the clock/data skew is less than 1 ns. >>>> >>>> Anyone know how I'd do such a thing? Altera seems to support >>>> set_max_skew, which might do it if I can disentangle the arcana of the >>>> syntax from >>>> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/ >>> tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm >>>> But I'm not necessarily wedded to Altera on this project. >>> >>> There's not enough foreshadowing for me to figure out where the >>> thermometer comes in. >>> >>> But I have lots of questions! >>> >>> How precisely do you really need to know the 1PPS? >>> >>> How can you know that the phase alignment is static, yet not know what it >>> is? The only way I can think of that you'd have a static phase alignment >>> is if there's a PLL locking to the 1PPS, and that implies a known phase >>> alignment. >> >> I can answer that, the 100 MHz and 1 PPS are from two different, but >> both very stable sources... most likely. I expect this is like the >> circuit my friend designed, a 1 PPS generator, or at least an internal >> alignment to the external 1 PPS, but clocked from the local 100 MHz >> clock. You would figure at any given time the phase relationship is >> stable, but not known apriori. With a clock stability of 10^-... pick a >> number, the phase would not change very fast. >> >> >>> Why not use a 100MHz clock that _is_ of known phase alignment? Seems to >>> me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp >>> with an integrator would add up to phase lock. >> >> 1 PPS from GPS, I expect clocked into the FPGA by a local atomic clock. >> >> >>> Certainly if you're using a free-running oscillator, even a crystal one, >>> your phase will, at best, be drifting all over the place, and it'll >>> probably have enough of an offset to it that it'll be running away rather >>> than exhibiting a random walk. >> >> How about rubidium or cesium? I think they get better than 10^-12, >> maybe 10^-15. > > Now that I have read JL's post, I understand. You have two signals > provided by your customer and not enough information to know how they > are related or how to use them. This will all depend on what you need > to use the signals for. In other words, you have not provided enough > info for us to know how to design your system. > > So how are you going to use these two signals? What are the > requirements you need to meet? >Exactly, and so it's not, as both you and Tim mentioned, about "measuring" the phase of the PPS signal per se. It's about being able to clock it in, either by delaying the PPS or rotating the clock, in such a way that you've guaranteed you're not sampling the PPS during the maybe/maybenot interval. If you did you'd get a one clock ambiguity in the sampling which would becomes period jitter. Always be early, or always be late, but don't keep changing your mind. Though as BobH pointed out, it's not quite so simple as that, either, since the PPS reference from any purchasable source has tens of nanoseconds of peak-to-peak period jitter. So my assumptions of phase stability are blown, and it's back to the customer, bucket o' questions in hand, to find out whether I'm supposed to faithfully replicate the PPS or jitter clean it. So this question, while still interesting, becomes moot for my actual application. I hadn't even realized JL put it out to s.e.d. Generally I stay off his groups and he off of mine, thus allowing both of us to maintain a careful mystique of omniscience by sneaking off and asking folks on the Internet. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●May 16, 20162016-05-16
On 5/16/2016 11:58 AM, Rob Gaddi wrote:> BobH wrote: > >> On 05/13/2016 04:18 PM, Rob Gaddi wrote: >>> I've got a project coming up in which one of the things I'm going to >>> need to do is take in the 1 PPS output from a GPS receiver and align it >>> to the 100 MHz frequency reference clock. >>> >>> The problem here is that the phase relationship is static but undefined. >>> There's plenty of time somewhere to not violate the setup time, but I >>> have to find where it is. >>> >>> My thought had been to use one of the FPGA PLLs to spin up 8 phases >>> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on >>> all of them. Then resychronize those to the 0� clock, read the >>> thermometer code, and figure out what the data phase is. Then I can >>> use the value opposite that and know I've got enough margin to park a >>> semitrailer in. >>> >>> All well and good, except it dawns on me that I don't know how to >>> convince the tools to make timing for that. Somehow my SDC file has to >>> call for running the input signal from the input pin to 8 flops such >>> that the clock/data skew is less than 1 ns. >>> >>> Anyone know how I'd do such a thing? Altera seems to support >>> set_max_skew, which might do it if I can disentangle the arcana of the >>> syntax from >>> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm >>> But I'm not necessarily wedded to Altera on this project. >>> >> >> The 1PPS signals out of the GPS receivers that I have seen, advertise >> 50nS accuracy. Your 100MHz clock has a period of 10nS. From what I >> understand of your project, I would just put the 1PPS signal in through >> a couple of sync FF's and then compensate for an assumed delay of 2 >> clock cycles in the application of the sync'ed 1PPS signal downstream. >> > > You know how sometimes when you get started on a project, and you get > some assumptions so firmly in your head that you don't even realize that > they're just assumptions? I had a substantially better opinion of the > jitter on the 1 PPS than is actually warranted. There are a _COUPLE_ of > receivers out there with 1 PPS jitter down to 10 ns (RMS), but for the > most part you're entirely correct. And even at 10, there's no > static relationship against a PLL-locked 100 MHz; it's just every pulse > for itself. > > You'd think with as many times as I've learned that lesson, one of these > times it would stick. > >> The phase relationship between the 1PPS input and the local 100MHz clock >> won't be all that static unless you phase lock the 100MHz clock to the >> 1PPS. Even an exotic local oscillator is going to drift around with time >> and temperature compared to the 1PPS. >> > > Now that's a question I have no idea how to resolve. Is the exotic > LO (let's assume cesium for fun) drifting and the PPS stable, or is it > (I'd guess) that no matter how stable the LO that the PPS is walking > around? > > Making claims of objective truth on these timescales is hard.It is still unclear to me what you wish to use the 1 PPS for exactly. But if you require a 1 PPS which is locked to a 100 MHz, both of which can be connected to the GPS signals, you would need to generate both yourself. In another thread John has indicated he doesn't want to wait for the synthesized 1 PPS to sync up to the GPS 1 PPS, but I don't see where you have a choice if you really need the two signals locked in the way you seem to want. The issue is not a design issue really. It is fundamental to the fact that the 1 PPS from the GPS has significant jitter. As I've said before, I know someone who designed exactly this circuit for one of the Naval Observatory's newer atomic clocks. I can put you in touch if you would like. His design also has a time of day clock display in case you need the time. lol -- Rick C
Reply by ●May 16, 20162016-05-16
On Mon, 16 May 2016 16:12:21 +0000, Rob Gaddi wrote:> rickman wrote: > >> On 5/14/2016 1:17 AM, rickman wrote: >>> On 5/14/2016 12:48 AM, Tim Wescott wrote: >>>> On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote: >>>> >>>>> I've got a project coming up in which one of the things I'm going to >>>>> need to do is take in the 1 PPS output from a GPS receiver and align >>>>> it to the 100 MHz frequency reference clock. >>>>> >>>>> The problem here is that the phase relationship is static but >>>>> undefined. >>>>> There's plenty of time somewhere to not violate the setup time, >>>>> but I >>>>> have to find where it is. >>>>> >>>>> My thought had been to use one of the FPGA PLLs to spin up 8 phases >>>>> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal >>>>> on all of them. Then resychronize those to the 0° clock, read the >>>>> thermometer code, and figure out what the data phase is. Then I can >>>>> use the value opposite that and know I've got enough margin to park >>>>> a semitrailer in. >>>>> >>>>> All well and good, except it dawns on me that I don't know how to >>>>> convince the tools to make timing for that. Somehow my SDC file has >>>>> to call for running the input signal from the input pin to 8 flops >>>>> such that the clock/data skew is less than 1 ns. >>>>> >>>>> Anyone know how I'd do such a thing? Altera seems to support >>>>> set_max_skew, which might do it if I can disentangle the arcana of >>>>> the syntax from >>>>> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/ >>>> tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm >>>>> But I'm not necessarily wedded to Altera on this project. >>>> >>>> There's not enough foreshadowing for me to figure out where the >>>> thermometer comes in. >>>> >>>> But I have lots of questions! >>>> >>>> How precisely do you really need to know the 1PPS? >>>> >>>> How can you know that the phase alignment is static, yet not know >>>> what it is? The only way I can think of that you'd have a static >>>> phase alignment is if there's a PLL locking to the 1PPS, and that >>>> implies a known phase alignment. >>> >>> I can answer that, the 100 MHz and 1 PPS are from two different, but >>> both very stable sources... most likely. I expect this is like the >>> circuit my friend designed, a 1 PPS generator, or at least an internal >>> alignment to the external 1 PPS, but clocked from the local 100 MHz >>> clock. You would figure at any given time the phase relationship is >>> stable, but not known apriori. With a clock stability of 10^-... pick >>> a number, the phase would not change very fast. >>> >>> >>>> Why not use a 100MHz clock that _is_ of known phase alignment? Seems >>>> to me that an VCXO plus some logic (possibly inside the FPGA) plus an >>>> op-amp with an integrator would add up to phase lock. >>> >>> 1 PPS from GPS, I expect clocked into the FPGA by a local atomic >>> clock. >>> >>> >>>> Certainly if you're using a free-running oscillator, even a crystal >>>> one, your phase will, at best, be drifting all over the place, and >>>> it'll probably have enough of an offset to it that it'll be running >>>> away rather than exhibiting a random walk. >>> >>> How about rubidium or cesium? I think they get better than 10^-12, >>> maybe 10^-15. >> >> Now that I have read JL's post, I understand. You have two signals >> provided by your customer and not enough information to know how they >> are related or how to use them. This will all depend on what you need >> to use the signals for. In other words, you have not provided enough >> info for us to know how to design your system. >> >> So how are you going to use these two signals? What are the >> requirements you need to meet? >> >> > Exactly, and so it's not, as both you and Tim mentioned, about > "measuring" the phase of the PPS signal per se. It's about being able > to clock it in, either by delaying the PPS or rotating the clock, in > such a way that you've guaranteed you're not sampling the PPS during the > maybe/maybenot interval. If you did you'd get a one clock ambiguity in > the sampling which would becomes period jitter. Always be early, or > always be late, but don't keep changing your mind. > > Though as BobH pointed out, it's not quite so simple as that, either, > since the PPS reference from any purchasable source has tens of > nanoseconds of peak-to-peak period jitter. So my assumptions of phase > stability are blown, and it's back to the customer, bucket o' questions > in hand, to find out whether I'm supposed to faithfully replicate the > PPS or jitter clean it. So this question, while still interesting, > becomes moot for my actual application. > > I hadn't even realized JL put it out to s.e.d. Generally I stay off his > groups and he off of mine, thus allowing both of us to maintain a > careful mystique of omniscience by sneaking off and asking folks on the > Internet.And we ratted you out. Sorry. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
