[jhersh]

Hi Daniel,

I think we first need to get on the same page about what the primary programming model I was looking for... that will help to illustrate some of the trade-offs. The fundamental goal was a system that could run critical processes in the FPGA at high speeds and allow the user code to not need to keep up with those rates. This is a departure from a system that has no FPGA for I/O support or otherwise tightly couples the execution of the processor with the I/O. As such, the interface to the FPGA is designed to be single-point in all cases feasible. This means that you can read the current position of an encoder any time you want or you can read the state of an accumulator any time you want without needing to ensure that you don't miss a sample. When you get the sample rate and see a number like 50kHz, that is the rate that the accumulator and the analog triggers and other systems are handling analog data in the FPGA. It makes the programming task easier for students, but it does take away the flexibility to do things like run a custom filter at 2kHz.

In a system that provides high throughput to the processor, you would not initiate a read over PCI to the FPGA for every sample. In order to achieve those rates you need to employ DMA and buffers of samples. I anticipated some advanced users wanting this capability, so I implemented a DMA engine in the FPGA to move samples to the PowerPC in a more efficient and lossless way. Because it must work within a design that is primarily single-point, it is not as efficient as you may expect, but it is much better than calling read for each point. Unfortunately, it is only implemented as a top level API in LabVIEW, so if you are using C++ or Java, you will have more work ahead of you to interface the FPGA classes directly. In LabVIEW, take a look at the DMA examples.

Best Regards,
-Joe