I'm looking to implement a phase lock in an FPGA without using any external components (other than the ADC). For simplicity locking to a simple binary pulse is adequate. The frequency of the signals is ~0.1-1% of the clock. I can't use the onboard clock PLL's because they are typically:

  1. Not configurable (set during synthesis).
  2. Jittery.
  3. Don't support the frequency I need.

I've been sorting through the literature and found a few binary phase locked loops. Most notable a "pulse steal" design that I can post a link to if desired. I have implemented and synthesized with some success, but its jitter and lock range was not as good as advertised. I've also had success using a external DVCO, but I would prefer if I can implement everything on chip.

A digital circuit design or even a hint in the right direction would be helpful (I've been banging my head against this for a while), a proven FPGA implementation would be wonderful but not expected.

ADDED 10-27-2010

The actual DPLL design that I used has a "Random Walk Filter" as the loop filter (not the "pulse steal" described earlier, going through my notes that didn't work to well), which then drives the clock pulses to the DCO. The lock-in range is set via divider in the DCO. The sensitivity of the loop is established by varying the length of the random walk.

The paper in which this is found is cited at the end of this post. After implementing parts of it myself, I found that it was actually already implemented on OpenCores, however it turns out that in the last few months the project was deleted but I have the Verilog files saved if anyone wants them.

Yamamoto, H.; Mori, S.; , "Performance of Binary Quantized All Digital Phase-Locked Loop with a New Class of Sequential Filter," Communications, IEEE Transactions on , vol.26, no.1, pp. 35- 45, Jan 1978

doi: 10.1109/TCOM.1978.1093972

URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1093972&isnumber=23895

  • 1
    \$\begingroup\$ Please do link to the 'pulse steal' design-there's no reason not to. \$\endgroup\$ Oct 27, 2010 at 14:36

2 Answers 2


Can you post more details regarding the target frequency, jitter and loop bandwidth (required settling time)? Also, what kind of oscillator do you want to use (external with a DAC, with/without dithering?, an on chip digital counter/accumulator)?

If you're happy with a digital "oscillator" (i.e. an overflowing accumulator) and its jitter then the rest of the circuit can be fairly simple:

  • a counter (PFD) counting number of cycles between the reference and the (optionally divided) PLL output,
  • a digital filter - anything will do assuming it does the integration (an accumulator) and it has a zero (minus (or plus?) a scaled PFD output) to stabilize the loop, optionally one or more poles above the loop bandwidth to reduce the control value "ripple" at reference frequency (only matters if fref
  • most significant bits of the digital filter output (DVCO control value) are given as an input to the overflowing accumulator (DVCO).

As for the loop bandwidth, if not enforced by settling time, decide it based on the noise contributions of all components.

  • If the jitter comes mainly from the reference or from PFD - use a smaller bandwidth,
  • If the noise comes from the oscillator - increase it.

In case if the reference signal is phase or frequency modulated - use a loop bandwidth lower than the smallest frequency of the signal modulating the reference.

Trickier techniques are used if the output frequency is close or equal to clock frequency and/or if the low jitter or very fast locking range is required. Maybe in your case they are not needed, besides they may not be well suited to an FPGA implementation.

  • \$\begingroup\$ If one wants to e.g. multiply the frequency of a stable incoming signal by 16 and one has a clock which is fast relative to that, what advantage is there to using a digital filter as opposed to measuring the number of clocks between each edge and the previous one, and figuring out what frequency one should output so that the output pulse which should coincide with the next input clock edge will do so? If the input clock jitter is no more than a clock cycle, the output jitter should be about as good. Such a scheme could start producing a clean output as soon as it got the second input pulse. \$\endgroup\$
    – supercat
    Sep 4, 2013 at 19:40

If you can tolerate a bit of jitter but mostly just need precise clocking against a drifty clock for data recovery you might want to implement something like the CAN Standard PLL (starts on page 67 of that PDF). This works based on an overflow counter which should be tuned nominally correctly, but synchronizes up to edges in the incoming pulse stream.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.