I have two incoming signals that I want to test the coincidence between. But, I first want to delay all of the signals from one channel by the period at which the signals are being sent (2 ms) and compare the coincidence this way. So basically, I want to store the real-time information for 2 ms and then replay it as soon as it finishes collecting, and continue this process on and on. Is this feasible using an FPGA? I was thinking of using one of the following:

outputA <= inputA after 2 ms; outputA <= inertial inputA after 2 ms; outputA <= transport inputA after 2 ms;

but from what I understand, these are only used for simulation? What other method(s) would be better to accomplish such a task? Using a shift register, or something similar?


In my setup, I have two detectors (single photon counting modules) that convert photons of light into a digital signal (3.3V, about 50 ns pulse width). The signals are then being sent to an Altera DE2 board, where they are tested with AND gates for coincidence (note, the signals are being shortened from 50 ns to around 15 to 25 ns beforehand, with internal logic and no timing loss). The clock on this board runs at 50 MHz, which has a rising edge every 20 ns. The laser sends a pulse every 2 ms. The real counts and random noise counts from these detectors follow no clock, so they will not necessarily share a rising or falling edge exactly the 50 MHz clock. Testing the coincidence is not the issue I'm having, what I need to do now is delay one of the signals by the period of the laser and test the coincidence then. Because the laser is so slow, it is impractical to delay the signal phisically (it would require around 1 km of optical fiber). So, I am trying to do this delay through the FPGA itself. Now to rephrase my questions:

(1) Is it possible to maintain temporal accuracy (down to very few nanoseconds) when using a FIFO buffer to delay one of the incoming signals, or will sending the signals into the buffer lose that accuracy and only share rising/falling edges with my clock? (Does the buffer say that block of data is either entirely zero or entirely 1, depending on whether the signal was in a high or low state at the rising edge of the clock when it collects the data?)

(2) How would I begin to write code for such a buffer, is this something I can find a copy of online or would there be any "buffer wizards" that I can create using a VHDL program like Quartus II?

  • 1
    \$\begingroup\$ Do you have a 0.5 kHz clock, synchronized with your data, available? \$\endgroup\$
    – The Photon
    May 15, 2017 at 20:15
  • 2
    \$\begingroup\$ what's your data rate or sampling rate? \$\endgroup\$ May 15, 2017 at 20:16
  • \$\begingroup\$ How many bits in your shift register and what will the clock frequency be? \$\endgroup\$ May 15, 2017 at 20:21
  • \$\begingroup\$ The delayed assignments in VHDL are purely a convenience provided in simulation. Remember VHDL is not a programming language for running instructions on a CPU but a descriptor language for designing digital logic circuits, like a circuit diagram does. So you need to imagine the digital logic circuit that can produce your delay operation, then write the VHDL to implement that circuit. Shift register running from a divider circuit that produces a shift enable seems sensible. Remember, don't make a clock by dividing down your logic clock - make an enable. Hope your experience makes this familiar. \$\endgroup\$
    – TonyM
    May 15, 2017 at 20:37
  • 1
    \$\begingroup\$ "I want to test the coincidence" - how closely do you want to 'test' the coincidence, ie. what timing resolution do you want? \$\endgroup\$ May 16, 2017 at 5:07

1 Answer 1


Any time value is not synthesizable by an FPGA, because an FPGA is not aware of the concept "time". Actually no electronic circuit is aware of our concept of time. In computers and such specific libraries were developed to ease programming with time.

However, synchronous electronics -like an FPGA- are usually clocked: driven by an oscillator. This oscillator has a certain intrinsic period: the clock frequency. You can use this frequency to measure a certain time period. I.e. an oscillator of 50 MHz will have oscillated 100000 times in 2 ms.

If you want to delay a signal, you will need to introduce memory into the system, which holds the information for a specific period. In this case 100000 clock cycles. You have a number of options there, one being a column of 100000 n-bit registers. However, using separate FPGA registers is quite inefficient.

Another solutions would be to use a feature of FPGA's that has been introduced not so long ago: it is possible to use the LUTs (look-up tables) as shift registers. This is much more efficient then using separate registers. However, in the case of 100000 clock cycles, this is still likely not so inefficient.

You are in fact making a FIFO (first-in first-out) buffer with a fixed delay. Seeing the delay is on the larger side, it is quite common to use a dual-port RAM block in this case: on the A-side you write the input data in an infinite loop and on the B-side you read this data with an address offset of 100000.

after your edit:

Ok, so it seems you are trying to determine the time between two pulses. That is something different -and much simpler- then determining the time-shift of data. This is actually done a lot in radar and lidar etc applications. The component that does that is a Time-to-Digital converter. It simply determines the time between pulse 1 (start) and pulse 2 (stop), like a stopwatch does.

If you want to determine the time more accurately, i.e. with a sub-clock period interval, I suggest you look at the hybrid solution (i.e. the Nutt method). That one combines a simple counter with a vernier interpolator. A. Aloisio et al. have suggested a nice FPGA implementation in "FPGA Implementation of High-Resolution Time-to-Digital Converter" (I hope you have access to IEEE).

  • \$\begingroup\$ a 50 MHz clock actually has 100,000 rising edges in 2 ms, will this large size still be feasible using a dual-port RAM block? \$\endgroup\$
    – Cody495
    May 26, 2017 at 21:13
  • \$\begingroup\$ @Cody495 100k doesn't sound large for a RAM, does it? Of you really want to keep all data, you have no choice. But are you really sampling at 50 MHz? You should explain your problem better. For instance, what is "the signal"? \$\endgroup\$
    – JHBonarius
    May 27, 2017 at 7:48
  • \$\begingroup\$ I have edited my original post, hopefully this explanation is more useful \$\endgroup\$
    – Cody495
    May 30, 2017 at 6:41
  • \$\begingroup\$ To a very limited extent, "time value" actually is synthesizable, not from the HDL itself, but in terms of minimum and maximum constraints that may be placed for the later place & route stage. The software has a model of the performance of the FPGA, and tries to find a path that will satisfy the need. But this is not going to offer any obvious solution to the apparent problem of the question. \$\endgroup\$ May 30, 2017 at 7:11
  • \$\begingroup\$ @ChrisStratton true, altough the FPGA still does not know the concept of "time" using that. The synthesis, place&route tool solves that for you. Furthermore, like you said: 2 ms is unachievable that way. \$\endgroup\$
    – JHBonarius
    May 30, 2017 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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