Multiple AI reads cause timing violation

[I.Ray]

Hi,

I have a simple piece of FPGA code that writes to 8 digital outputs and reads from 72 AI channels (spread across three 9205 modules) in one while loop. This code refuses to compile because of timing violation. While disabling parts of the read, I found that this violation occurs for more than 36 AI reads. However, I could not find any information on limits for how many channels can be simultaneously read. I have tried using separate I/O nodes for each module, separating into two loops, and increasing the wait time. Nothing seems to solve this problem. There is not a lot of scope for pipelining in parallel reads and writes. Any help is appreciated.

Thanks

[altenbach]

You only mentioned the modules. What controller is this running on? Just curious.

[I.Ray]

By controller do you mean cRIO? It's the 9039 (Sync).

[TheOtherKid]

So you have a 9039 with three 9205's. What module are you using to do the analog output? Do you have any other modules?

When you say that the issue shows up for more than 36 reads, were you able to get it working with 36 but not 37? Is this with the analog output code included? Do you see a change if you remove that?

What's your sample rate on the AI and AO channels? I'm assuming you're using a 40 MHz FPGA clock?

Does your code do anything besides analog I/O? Would you be able to post it?

A couple of things I would try at this stage:

Try replicating the AI behavior by editing the "NI 9205 Basic IO" example in the example finder.

Try changing to a derived clock with a little higher frequency and see if the behavior changes.

[I.Ray]

I am using a 9476 for digital output. I am not providing analog output or using any other modules.

I have tried the code with two modules being read instead of three, and with the digital output removed, among other things. They only change the violation by some pico seconds but do not solve the problem. I haven't gotten to figuring out the exact threshold for AI reads that causes this issue.

I can't say for sure what the sampling rate is. I am using a 40MHz FPGA clock. I just tried using a 80MHz clock, and that did not help either. Is there a way to find what the sampling rate for each module is? 

I am also attaching my code for you to have a look.

Thanks!

[TheOtherKid · Accepted solution]

Oh, sorry, I misread that as analog out for some reason.

Looking at your code, it looks like you're using read/write controls for all of the channels. This is probably part of the problem. If you don't put in a delay value into the loop, it's going to try and run at the 9205's max speed, which I believe is about 200KHz aggregate. The read/write controls probably just can't keep up with that much throughput.

You could maybe try and make the current setup work by lowering the loop rate to a really low value. However, the better approach is going to be using the DMA FIFO. This will make your code more expandable and improve maintainability. The 9205 Basic IO example that I mentioned uses this approach. I would start from that base and expand it to meet your needs.

[I.Ray]

That makes sense, and I was looking at the example thinking about that. This is probably a dumb question but what would I do if I wanted to display the readings, instead of just storing them in the FIFO? I know I can read from the FIFO, but will that not cause the same loop rate problem again? Or would collecting the data in the FPGA layer and displaying it in the RT solve this problem?

[TheOtherKid]

Not at all. That can actually become fairly complicated depending on the circumstances.

What it really depends on is how much post-processing you're doing to the signal.

Essentially, the benefit of the fifo is that it enables a producer-consumer architecture where the FPGA produces the data at the rate that it needs to and then the RT host can process (or consume) the data at its leisure. It does this by creating a buffer between them, and the RT host can read all or part of the buffer in a single read. This gives you more breathing room for processing, but in some applications, the RT host could still have trouble keeping up.

However, in your application, as I understand it,I think the example will function as needed. It actually reads everything up to the last full cycle of the buffer and sends it to a graph. I think that will be good enough to get you moving. If you end up needing to do more processing at some point and run into more trouble, I'd make another post at that time.

[I.Ray]

I changed it to read into a DMA FIFO and it finally compiled! I will try reading it in the RT now. But yes, the data will not just be displayed but also processed. I was hoping to do some of that in FPGA but hopefully I'll be able to make it work in the RT code. 

Thank you for all your help, Bill!

[crossrulz]

---

@I.Ray wrote:

But yes, the data will not just be displayed but also processed. I was hoping to do some of that in FPGA but hopefully I'll be able to make it work in the RT code.

---

Use a target defined FIFO.  Then you can really do the Producer/Consumer inside of the FPGA where your acquisition loop reads the data and throws it into the FIFO and another loop gets the data from the FIFO and processes it.  You can then use a DMA FIFO to pass that processed data to the RT if you want.