Caputring Multiple Event times with 78xxR

[deskpilot]

I started a thread here: http://forums.ni.com/ni/board/message?board.id=40&thread.id=8336, but then came across the 7811R. I want to check the feasibility of this system.

There will be 381 lines. Line 1 will receive an event (voltage drop from 5 to 0), and then the other 380 lines will beginning pulsing 1 ms later for up to 20 ms. The pulses will be of unknown pulse width, and I do not need to know the pulse width, only when they go low. I need to measure the time between the Line 1 event and the rest of the events with about 1 microsecond accuracy.

Having only a little experiencing with the FPGA, I am worried about two things. Can I store all of the pulse times on the FPGA, because I don't think I can get the information off quick enough even wtih RT?  There will be maybe a dozen pulses per line and I will need to save the number of tick counts since Event 1 for each pulse, along with the channel it occurred on.

Also, I 'm not sure about the level of the counter. The signal will be dropping from 5 to 0, but can I set the level at, say, 3.3 so that anything below that is false and above that is true? Or is the TTL level already set for each line?

[Pcorcs]

deskpilot,

Would you mind describing a bit more about the application?

I have reviewed the other thread , and agree that an FPGA solution would be the best approach. You are obviously dealing with a large amount of data transfer, which will require very well optimized code. 

With regard to the timing parameters, the single point I/O nature of the FPGA and true parallel execution implies that each acquisition point across all channels will maintain the same time data. If you stream back a constant time stamp, could you establish the timing information you need in post processing? This would assist in reducing the logic implemented on the FPGA, and the required amount of data transfer. 

On the FPGA PXI cards, the digital inputs are pre-configured for 0-0.8V low, and 2.0-5.5V high. These thresholds will determine the boolean output on the FPGA target. 

Please post additional questions you have reagrding the setup. I believe we will also need to review the FPGA size in order to accomodate the demands of this application.

Cheers!

[deskpilot]

I don't think I need a timestamp exactly. I will have one event (Event One) that determines the zero time. I can send this signal to all three cards. I would then count clock ticks since Event One (by using a shift register on a SCTL?). The clock could be slowed down to 5 or 10 MHz if necessary. I'm thinking there are two ways I could capture and store the data, not sure which one would be more efficient.

First guess is to create four single cycle loops per card, each loop containing thirty two channels. Put these channels into an array, carry the array in a shift register, so that I always have the present data and the last iteration. Any time the array changes, I would need to save the previous array, the current array, and the number of clock ticks since Event one.  This will give me all of the information I need to post process.  Hopefully I can communicate the event time between loops (not sure if I can use FGs or something similar in FPGA)? The only reason I suggest four single cycle loop is so that I could create a 32 bit number out of the inputs at some point (probably right after building the array).

The second option is to determine which channels changed each loop inside of the FPGA, and only send the channel numbers and the corresponding "ticks since event one".

I think option one is much more efficient, especially if I can just carry the 32 bit number in the shift register and send it to the host.

Again, the scenario is as follows. Event one will go high to low, this marks the zero time. About one millisecond later, all of the channels will begin pulsing. Each channel will probably pulse around a dozen times, although some may not pulse at all and some may pulse a few dozen times.  The last pulses of real interst happen at around T+10 ms, but I would like to capture everything through about T+20 ms. Since the channels are pulsing randomly, I could end up recording data on every loop. This is highly unlikely, but the density will be pretty high between T+1 ms and T+2 ms or T+3 ms.  

I think we are okay with the trigger levels. The remaining question there is, will a signal between .8 and 2.0 register? The way I understand it, the trigger level is actually 1.4 +/- .6, so signals in that range will still register as either true or false, there is just uncertainty which way they will be interpreted?

SO, is this feasible? Do I need more cards so that there are less channels per card? Will I need an RT host, or will windows be sufficient? Should I build the code I described above to explain better, or does this make sense?

[deskpilot]

Edit to the last message: I said I could end up recording data every loop, but its unlikely. Actually, its very close to impossible. I will try to do some investigation into what is likely. I'm fairly confident I won't have more than 5000 total pulses in the time of interest.

[Pcorcs]

Thank you for the additional information,

I believe your plan is a good one. Based on the information provided I believe that this system can be successfully deployed using the 7813R, with the Virtex II 3 M-Gate FPGA chip. As you had discussed, we will need to utilize bit packing to compile the channel comparison data as integer values for transfer back to the host. With the R-Series devices, we will have 3 available DMA FIFOs for data transfer to the target. The SCTL will need to incorporate a shift register system to detect the pulse inputs. Likely given the amount of throughput, the expected performance would be using the standard 40 MHz clock, i.e. the pulse widths must be larger than the 25 ns between loop iterations. If an 80 MHz derived clock would be employed, likely there would exist FPGA timing violations.

Utilizing 2 of the available FIFOs bit-packed as 64-bit integers indicating the channel pulse received, we may utilize the third FIFO to forward the loop time stamp (a 32-bit tick count) back to the hosted system. The maximum number of channels per card then results in 128, meaning 3 R-Series devices will need to be employed. On a single 128 channel card with 2 FIFOs forwarding 64-bit integers at 40 MHz, the throughput will be roughly 100MB/s, slightly under the DMA limit of 118 MB/s. 

You will certainly be pushing the limits of the FPGA space, and data streaming specifications with this application; however, I believe an FPGA solution is a feasible approach. 

Please post any additional information, or questions you may have.

Cheers! 

[deskpilot]

I am very encouraged that you think we are headed down the right track. However, I am having a little trouble following your math. Is the 118 MB/s the limit of one DMA channel, or the total of all three channels on one card, or the total of all DMAs streaming to memory?  

If I stream two 64 bit FIFO's per card, I come up with (128 bits/sample) X (40,000,000 samples/second) X (1 byte/8 bits) = 640 MB/s ?

If 118 MB/s is a limit on each DMA channel, isn't that also about the limit on the PXI/PCI bridge? If this is the case, the PCIe-7841R would take care of the bus problem, and I could possibly slow down to around 5 MHz to get the single card streaming rate under 118 MB/s.

There are a few more outs as well. If I stream every data point, I don't even need to keep track of tick counts, I know the dt between samples is (close enough to) 1/clock rate.