Pulse coincidence counting

[Chris Weber]

I would like advice on which FPGA would be appropriate for my application. I need to use an FPGA to enable coincidence-counting of electrical pulses from three single-photon detectors. The pulses have height of about 1-2 V (into a 50-Ohm load) and duration of about 15 ns. The coincidence window should be in the range of 20 ns or so. (Until recently I was using Altera's DE2 board for this experiment, but then we replaced the single-photon detectors. The Altera's threshold for detecting pulses is 4-5 V, so it cannot detect the 1-2 V pulses from our newer detectors.)

Thanks.

[zygot]

What you have is a logic standard compatibility problem, not an FPGA problem.

If I were to consider connecting a sensor to an FPGA I'd never think about a direct connection to an FPGA pin. Unless, by some miracle, the sensor had a standard logic output signal compatible with one of the FPGA supported standards for the IO bank Vccio driving the pin, and I knew that the signal NEVER exceeded specification. I'd create a simple circuit to take in the sensor signal output and convert to an appropriate one suitable for the FPGA device. In the old days programmable logic supported Schmitt-trigger type inputs which is nice when an external signal doesn't exceed the maximum specified input levels of the FPGA IOSTANDARD but doesn't necessarily meet the minimum voltage levels either. There are some analog comparator devices available that are fast enough for your needs ( I suppose, since I don't have enough information to say for sure ). Anyway, it should (might ??) be easy to create a simple PCB that connects to your DE2 and makes the new sensors compatible.

You can find out what logic types any particular FPGA family supports. For AMD/Xilinx Series 7 devices UG471 is a good place to start. The details of the specifications are in the datasheet for the device family you might be interested in.

Traditionally, some logic families have a decision point about midway between the highest voltage that is considered a logic 0 and the lowest voltage that is considered a logic high. Some families, notably TTL have a min-max range for logic 0 and another one for logic 1, and a zone between them that is undefined. If the connection between an external logic driver and an FPGA pin has poor transmission line signal integrity characteristics for that driver then you can easily see overshoot, which is when the input pin sees logic levels that are too far below GND and too far above Vccio. This is a good enough reason for having a logic level conversion circuit, if protecting the FPGA device isn't a good enough one already. FPGA devices support a wide range of logic families, but they aren't designed to accommodate signals that don't conform to specific behavior. The voltage that powers the IO bank for a particular FPGA pin will restrict the choice of logic even if the external signal is within specifications for a particular logic type. What I'm trying to say is that you probably want to condition any external signals before driving an FPGA input pin regardless of the family or device. You'll need to consult the FPGA board vendor schematic to see what voltage poweres the IO bank for a particular FPGA pin or connector pin.

I really don't understand what a 20 ns coincidence window actually means, particularly for 15 ns wide pulses, but there are logic, or analog comparators with logic outputs, that are fast enough... though there's quite a bit of detail work to go through to be sure. I'd think that It's quite possible to miss detection or have false detection simply due to ill-conditioned logic input signals for such an application. How important that might be is beyond my speculation.

[edit] Designing programmable logic, or an interface connecting multiple unrelated sensors to an FPGA is a lot more complicated than many people would assume.  A big problem is meta-stability which  can result when you try and clock a signal where the transition between states is in the vicinity, in time, of the clock edge being used. Your sensor is kind of a digital version of the nested doll problem in that they have the same meta-stability possibility. Meta-stability isn't something that you can avoid when dealing with lots of unrelated clocks or signals that transition between states at random times unrelated to clock edges. You have to detect, account for and accommodate meta-stability. There are certainly digital design best practices  practices for mitigating the phenomena though.

Edited August 19, 2022 by zygot