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

[Xband]

You’re making a PET coincidence counter?  You could use the ADC modules possibility for the input.  Even though I’m trying to use the same hardware for another application I haven’t gotten to the point that I can help.  The fastest digitizers should work or even the 1410, again I’m not sure on the delay in this board.

The FPGA should be adequate, I found a youtube video a guy made on a cheap oscilloscope that uses this exact chip.

 

I’ll follow the conversation.

[zygot]

4 hours ago, Xband said:

You could use the ADC modules possibility for the input

Sampling frequency is one factor to consider with an ADC converter. A 15 ns pulse may involve only couple of 125 MHz samples, assuming that the pulse makes to the converter. Before thinking about whether or not this is a good idea understand the analog bandwidth of the circuit that precedes the converter. The theory of design information provided by Digilent for their more recent ZMODs is less complete than for the original ones.

Cheap digital oscilloscopes likely have a sample operating at a much higher rate than anything that Digilent sells, and those scope are probably inadequate for such a task.

This is just my gut reaction to the post, I don't see a reason to spend much time thinking about it.

 

[Guest]

Hi @Chris Weber

What is the per-channel pulse count rate that we're talking about? And what brand/model of SPDs are you using? Can you share a scope picture of what the SPD pulses look like? And what information do you want to output, precisely?

We're doing similar things in our lab. If budget is available, I'd recommend that you get a proper event timetagger (we're using Swabian devices for this kind of application). They cost upward of 10k, but that's the proper off-the-shelf device for an application like this.

If you want to go the FPGA route, I don't think you need to go via an ADC; you can trigger the digital input pins on an FPGA either directly or with a voltage level converter. That saves you a lot of hassle.

Even on a humble Artix-7 it is possible to sample digital pins at 1 GHz, so that gives you 1 ns resolution. In fact I implemented a timetagger doing precisely that based on a very humble CMOD A7 and it works like a charm; but it's quite a bit of effort to get that working. You need to be pretty experienced with Xilinx FPGAs and their software to do that. For me, it was more-or-less a hobby challenge to see if I could get 1 ns resolution working, but if you need to pay someone to do it, it could get expensive.