Electronic – I’m trying to measure relativistic speeds with an FPGA — are the results legit

fpga

I've been teaching myself FPGA programming in Verilog over the past year during the COVID-19 lockdown.

I found a discussion of whether it was possible to measure the speed of light using an Arduino or other microcontroller and the consensus was that the processor speed was too slow and there were too many outside factors like system interrupts.

I figured an FPGA would be well suited to this task and it would be cool to see if I could directly measure the speed of a signal through a wire, which moves at something like 0.85 the speed of light. I've gotten code working on a DE10-lite development board that does this, but I'm having some issues understanding the results. I'm really looking for feedback on whether my approach works at all and what to look out for.

My code is very straightforward. A state machine starts in IDLE until a button press moves it to state "COUNTING." In COUNTING an output wire "measure_outW" is raised from 0 to 3.3 V and then a 100 MHz always block increments a register ("measure_counterR)." This always cycle continues until an input wire (measure_inW), which is pulled down to ground by a 12 kΩ resistor, goes high. Measure_outW and measure_inW are connected through the test object, a long spool of wire. So the number of 100 MHz cycles it takes for the signal to travel from measure_outW to measure_inW (through the long spool of wire) is recorded by measure_counterR.

The state then moves to "REPORT" and the binary value in measure_counterR is converted to binary-coded decimal and fed to a UART which displays it on a PC. (I chose this setup just to get practice using a UART in Verilog.)

I used a fresh roll of 24-gauge wire-wrapping wire as a test object. It's advertised as being approximately 305 meters in length. I get values around 264 clock cycles for the travel time. Now this is with a PLL clock of 100MHz. Another roll of the same wire gives me values around 274 so I feel I'm really measuring something.

Question 1. Does an always block, that runs at posedge of a 100MHz clock, occur at 100 MHz or at 50 MHz (because it's just the posedge)? Sorry, I don't have a scope that can handle these speeds. If it's 100 MHz then in each clock cycle the signal moves 0.85 x (3×10⁸ m/s) * 1×10^-8 s) = 2.55 m. It takes 264 cycles to get through the spool so 2.55 m x 264 = 673 m. This is more than twice what I'd expect.

Question 2. Is it legit to measure very short time intervals this way? Does the PLL clock synchronize itself across the FPGA so everything is simultaneous? Or does it keep the phase across the device, at the expense of the actual absolute number of cycles?

Question 3. The values I get move around a bit, and are affected by the position of the spool of wire and its feed-in wires. I'm surprised it isn't a fixed number of clock cycles. Why does it vary by about + or – 10 cycles? I know oscillators can vary ("jitter"), but does this manifest over such short intervals (i.e., only 264 cycles)?

Question 4. I've measured two different spools of wire with different values. But when I combine them into one long test object the resulting time is a somewhat less than the sum of their individual times. Is there a capacitive or inductive effect happening? I'm just turning the line from low to high– not sending pulses so it's not an AC signal.

Best Answer

You're measuring how long

The source current of your output pin

takes to charge up

The capacitance of your input pin

through

The inductance of your coil of wire

until it reaches

The threshold voltage of your input pin.

Number 3 is related to the length of your wire, but not as directly as you would think. It's also influenced by the geometry of the wire (the value you get with it laid in a coil like that is very different from the value you would get if it made a single 100m-diameter circle) and by the presence of any conductive objects nearby. Numbers 1, 2, and 4 have nothing to do with the wire you're testing; mostly they're fixed properties of the FPGA chip, but they are liable to vary several percent depending on things like your supply voltage and the ambient temperature.

Your experiment isn't impossible, but there are several things you would have to change before you stand any chance of measuring the thing you're trying to measure. Replacing the wire with coax (to reduce interaction with the outside world) and impedance-matching the whole system would be a first step.

You may also be interested in looking up time-domain reflectometry (in which only one end of the cable is connected to the measurement device, and the length can be found by looking for the reflection of the signal from the far end) and frequency-domain reflectometry (in which, instead of sending a single pulse down the cable, we send various frequencies of sine waves, and measure the magnitude and phase of the reflected signals relative to the original). The cost of that last one has come down quite a bit in recent years.

Related Solutions

Electronic – Pipelining and clock frequency issue

Your design will not function correctly if it runs at 100 MHz but is only spec'd (by the tools) to run at 50 MHz. If it does, then it's a one-off miracle that wouldn't work when you make a change and rerun the tools. Don't do it. Don't even do it if your clock is 100 MHz and the tools tell you the design can run at 99.5 MHz.

To solve your problem you can either write a simple 'divide by power of 2' clock divider to reduce the clock frequency (something like this in Verilog):

reg [n:0] count; 

always @(posedge CLK_100) begin
  count <= count + 1;
end

BUFG bg_0 (.I(count[m]), .O(CLK_DIV));

(where 'm' <= 'n' and 'bufg' is a global clock buffer, and must be used for synchronous designs) or use a Digital Clock Manager (DCM).

Hopefully that solves your pipelining issues as well unless you absolutely have to run the entire design at 100 MHz. Other than pipelining you can consider using FIFOs if you have part of the design running at 50 MHz and the other at 100 MHz, but you'll have to say a bit more about what you're doing to get more meaningful help here.

Electronic – timing constraint for bus synchronizer circuits

I don't have experience with Quartus, so treat this as general advice.

When working on paths between clock domains, timing tools expand the clocks to the least common multiple of their periods and select the closest pair of edges.

For paths from a 36 MHz clock (27.777 ns) to a 100 MHz clock (10 ns), if I did my quick calculations correctly, the closest pair of rising edges is 138.888 ns on the source clock and 140 ns on the destination clock. That's effectively a 900 MHz constraint for those paths! Depending on rounding (or for clocks with no relationship), it could come out worse than that.

There are at least three ways to write constraints for this structure. I am going to call the clocks fast_clk and slow_clk as I think that's clearer for illustration.

Option 1: disable timing with set_false_path

The easiest solution is to use set_false_path to disable timing between the clocks:

set_false_path -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_false_path -from [get_clocks slow_clk] -to [get_clocks fast_clk]

This is not strictly correct, since there are timing requirements for the synchronizer to work correctly. If the physical implementation delays the data too much relative to the control signal, then the synchronizer will not work. However, since there isn't any logic on the path, it's unlikely that the timing constraint will be violated. set_false_path is commonly used for this kind of structure, even in ASICs, where the effort vs. risk tradeoff for low-probability failures is more cautious than for FPGAs.

Option 2: relax the constraint with set_multicycle_path

You can allow additional time for certain paths with set_multicycle_path. It is more common to use multicycle paths with closely related clocks (e.g. interacting 1X and 2X clocks), but it will work here if the tool supports it sufficiently.

set_multicycle_path 2 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -setup
set_multicycle_path 1 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -hold

The default edge relationship for setup is single cycle, i.e. set_multicycle_path 1. These commands allow one more cycle of the endpoint clock (-end) for setup paths. The -hold adjustment with a number one less than the setup constraint is almost always needed when setting multi cycle paths, for more see below.

To constrain paths in the other direction similarly (relaxing the constraint by one period of the faster clock), change -end to -start:

set_multicycle_path 2 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -setup
set_multicycle_path 1 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -hold

Option 3: specify requirement directly with set_max_delay

This is similar to the effect of set_multicycle_path but saves having to think through the edge relationships and the effect on hold constraints.

set_max_delay 10 -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_max_delay 10 -from [get_clocks slow_clk] -to [get_clocks fast_clk]

You may want to pair this with set_min_delay for hold checks, or leave the default hold check in place. You may also be able to do set_false_path -hold to disable hold checks, if your tool supports it.

Gory details of edge selection for multi-cycle paths

To understand the hold adjustment that gets paired with each setup adjustment, consider this simple example with a 3:2 relationship. Each digit represents a rising clock edge:

1     2     3
4   5   6   7

The default setup check uses edges 2 and 6. The default hold check uses edges 1 and 4.

Applying a multi-cycle constraint of 2 with -end adjusts the default setup and hold checks to use the next edge after what they were originally using, meaning the setup check now uses edges 2 and 7 and the hold check uses edges 1 and 5. For two clocks at the same frequency, this adjustment makes sense — each data launch corresponds with one data capture, and if the capture edge is moved out by one, the hold check should also move out by one. This kind of constraint might make sense for two branches of a single clock if one of the branches has a large delay. However, for the situation here, a hold check using edges 1 and 5 isn't desirable, since the only way to fix it is to add an entire clock cycle of delay on the path.

The multi-cycle hold constraint of 1 (for hold, the default is 0) adjusts the edge of the destination clock uesd for hold checks backwards by one edge. The combination of 2-cycle setup MCP and 1-cycle hold MCP constraints will result in a setup check using edges 2 and 7, and a hold check using edges 1 and 4.

Best Answer

Related Solutions

Electronic – Pipelining and clock frequency issue

Electronic – timing constraint for bus synchronizer circuits

Related Topic