8

How to measure phase difference of two signals of the same frequency in an FPGA?

For instance, say I have two 150 MHz signals (internal to the FPGA) that are synchronous to each other, but they are offset by some constant phase difference, how would I be able to measure this?

I have researched existing methods of a time-to-digital converter on an FPGA, but those mostly concern two one-time start and stop signals and measuring the time between those two events. I wonder if there's better method if we know that the signals are repeating with a constant phase difference?

cksa361
  • 3,834
  • 7
  • 35
  • 49

6 Answers6

5

Use one of the FPGA's PLL clock blocks to generate a slightly different frequency, perhaps 140 MHz or whatever you can do. XOR this with each of the signals of interest (paying some theoretical heed to possible metastability issues, but satisfying yourself it will work enough of the time). Compare the phases of the two lower frequency results.

In effect, this is the same as how a hetrodyne radio receiver works - you mix the incoming signal with a local oscillator and generate a lower frequency result more convenient for detailed processing.

Since you basically have a one-bit digital system, your result will be in discrete steps determined by the frequency difference - the closer your LO frequency is to the input frequency, the finer the result, but the less frequently you will produce an answer. Phase and duty cycle stability of the PLL block at various ratios would be worth researching. Averaging multiple measurements will presumably get you a better answer.

Chris Stratton
  • 33,491
  • 3
  • 44
  • 90
  • You're going to need some sort of low-pass filter in there to separate the lower beat frequency from the upper one. – Dave Tweed Sep 24 '12 at 11:31
  • @DaveTweed Actually you won't - the higher frequency is theoretically present if you interpret the 140 or 150 Msps per second data stream by working backwards through the Nyquist rule, but it's literal representation would be as a negative frequency, which in this case is indistinguishable. It may be easier to think about it in terms of digital logic, where you will get an output that is 1's for a while, until it rolls across to 0's and then eventually back to 1's. – Chris Stratton Sep 24 '12 at 15:32
  • 1
    I suggest you run your idea through any standard logic simulator. What you'll see at the output of the XOR gate is a waveform that basically has a frequency of 290 MHz, but whose duty cycle varies from 0% to 100% and back again with a 10 MHz period. If you're resampling this signal (with what clock?), then you need to say that. – Dave Tweed Sep 24 '12 at 16:11
  • I probably should have explicitly said resample; effectively it is implicit in the assumption of using logic synchronous (to either of the clocks) to evaluate the result. – Chris Stratton Sep 24 '12 at 17:38
  • I can understand what Dave said. How do i "resample" the XOR'ed signal (i.e. resample with which clock?) ? – cksa361 Sep 25 '12 at 08:31
  • You don't need to - assuming you are processing in a block synchronous to either of the clocks, the resampling is already done for you since, you are only actually "looking" at the signal at the clock edge (plus/minus setup/hold times) – Chris Stratton Sep 25 '12 at 18:27
4

You're looking for a phase detector. Almost all FPGAs have a PLL module designed mostly for generating clock signals. Some of those can be driven with an internal signal. I'm not sure if you can pull the phase detector signal off of the PLL, but I highly doubt it.

You can implement a phase detector in a high-end FPGA (see this Vertex app note), but that seems like a lot of work, especially for something that's a relatively easy analog operation, for which off-the-shelf ICs exist, like the Analog Devices AD8302. But you know your platform better than I do -- maybe you don't have access to hardware changes.

Jay Carlson
  • 2,869
  • 1
  • 15
  • 21
4

Xilinx FPGA's have a feature in the "Digital Clock Manager" block which allows for a programmable output skew. That output skew can be changed at run-time in small increments (10's of pS if I remember correctly).

You have 2 clocks, we'll call them A and B. Clock A is your main clock that almost all of your logic is ran off of. Clock B is ran through a DCM w/skew and then to a T-Flip-Flop, creating a signal that toggles on each edge of B. That toggling output is then ran to a D-Flip-Flop that is clocked with A.

What you do now is sweep the skew on B and look at the results when it is sampled by A. As you sweep the clock skew setting, the output of that D-Flip-Flop will start out at one value and then switch to another.

In some ways, this method is similar to what @JasonMorgan proposed-- but doesn't require lots of tweaky logic delays to make sure that those 360 buffers have a consistent delay from compile to compile (it won't).

I have done something very similar to this in a Xilinx Spartan-3 and it worked very well.

  • why would you need the T-flip-flop? – cksa361 Sep 25 '12 at 11:04
  • 2
    @cksa361 FPGA's typically have clock routing resources and signal routing resources and (almost) never shall the two be mixed up. It just avoids a lot of problems. The T-Flip-Flop is basically a way to move the clock "information" from a clock net to a signal net without having to do something weird (like mixing clock and signal routing resources) –  Sep 25 '12 at 13:53
1

I'm not sure if this would work, it's just an idea. But it avoids the need for a high speed sampling clock to measture the distance in time between your signals.

You could make use of the (fairly) deterministic delays within the device and the large number of gates, expecially if you are running within a restricted or controlled temperature environment. You will need an external loop filter, a CR circuit and perhaps a schmidt buffer should do the job. You will need to tell your fitter to not optimise the gates.

Take your reference and apply it to an XOR gate. Take the measured signal and delay it though, e.g. 360 buffers in series. Take the 360 outputs of the buffers and (with appropriate constraints) pass it through a 360:1 mux (360 AND gates and a decoder). Pass the output of the mux into the XOR gate. Pass the output of the XOR gate into the loop filter, then take the input and use it to clock a counter. A control block ascynronously resets the counter with some rate, e.g. 1ms. The control circuit steps through the mux every 1ms, looking for the smallest count. The state of the mux at that time is the phase angle in degrees.

Jay M
  • 3,771
  • 15
  • 30
0

Say you have a 600MHz clock, and a counter. Start counting with the leading edage of one signal, stop counter [read result] with leading edge of second signal.
The resolution is a function of the difference between sample and clock frequencies.
600/150 = 4 so you get 4 steps [or 90 degrees] phase resolution.

You want better resolution, while staying with an FPGA? OK, but this gets a bit funky...

First, you need 2 circuits, "lead" and "lag". We also need to label our signals "T" [Test] and "R" [Reference]. The "lead" is: T AND (NOT R). "Lag" is: R AND (NOT T)
Depending on lead or lag, one of these will produce a signal with a pulse width proportional to the phase difference. Put each output through separate low pass filters, probably about 1MHz.
Finally, read: http://www.latticesemi.com/~/media/Documents/WhitePapers/AG/CreatingAnADCUsingFPGAResources.PDF?document_id=36525
This details how to implement an SAR ADC within an FPGA. Digitise the filtered "lead" and "lag" signals: the largest one will give you phase magnitude and sign.

EDIT: My logic gate description is not correct. Look up a phase detector for a proper schematic

Alan Campbell
  • 1,039
  • 6
  • 11
0

Use two PLL. Generate as low frequency as possible, from both of the high frequency signal. Let's say 150MHz -> 15MHz. The phase difference will remain the same between the two low frequency signal. Then measure the phase of these slow signals. (XOR them or use any other logic)

betontalpfa
  • 615
  • 1
  • 7
  • 21