FPGA Interrupts: Buffered?

[A.E.M]

Hi All.

When using interrupts from FPGA to RT Host (IRQ), is it then buffered?

Say the FPGA is not waiting for the Host to acknowledge the IRQ. Then the FPGA can send multiple interrupts to the Host, if the Host loop is running slower than the FPGA loop for a moment.

Will the host received all interrupts send, or only the latest one?

[Sam_Sharp]

I couldn't find anything relevant in the documentation, but my understanding is that they are essentially interrupt flags - raising the interrupt on the FPGA sets a flag in memory somewhere and the 'Wait on IRQ' function looks for that flag going high. You can then reset the flag with the 'acknowledge IRQ' method which clears the flag. I'm not sure what happens on the FPGA if you try to assert an IRQ which is already asserted but the interrupt node has an option to 'wait until cleared' if you want to make sure you handle each one.

In short - they're not buffered.

If you want to use multiple interrupts - use different IRQ numbers.

[A.E.M]

Thank you for your reply.

No, I was hpoing to find it in the documentation, but couldn't find anything in the Help or in KBs.

The reason I want buffered is:

I use a DMA to transfer data to RT Host. Generally speaking, the datarate is really slow, but all the data is important so I use a DMA to make sure nothing get lots. For each datapackage, I sent an interrupt to the RT Host. When the RT Hosts receives the interrupt, it reads the package.

==> 1 interrupt = 1 package send (fpga) and 1 package read (host).

Sometimes, it could happen that the FPGA sends 10 packages in a row, thus generating 10 interruts very quickly. My fear is, that the RT Host will not be able to read all those packages fast enough, and therefore don't read all the elements in the DMA buffer.

I see 3 solutions to this issue:

1) If the interrupt is buffered, the RT Host would simply receive all the interrupts at the rate the RT Host can manage. This seems not to be an option.

2) Make sure the FPGA waits for the RT Host to acknowledge the interrupts before continuing.

3) The FPGA can send aditional interrupts every 500ms (or so), and then RT Host can check if the DMA contains any data.

I'm not really sure I'm a fan of option 2, since it will make the FPGA wait (potentially), but I guess that is the 'normal' solution?

[crossrulz · Accepted solution]

---

@A.E.P wrote:

I see 3 solutions to this issue:

1) If the interrupt is buffered, the RT Host would simply receive all the interrupts at the rate the RT Host can manage. This seems not to be an option.

2) Make sure the FPGA waits for the RT Host to acknowledge the interrupts before continuing.

3) The FPGA can send aditional interrupts every 500ms (or so), and then RT Host can check if the DMA contains any data.

---

The fourth option is to just have the RT read as many packets that are in the DMA whenever it gets to it.  You could then process them in a FOR loop.

[A.E.M]

Hmm, true.

4) Simply use the DMA read function, 0 wired into the Number of Elements to Read, thus just asking how many elements are availble. If enought elements are availble, do the actual read.

Only thing is: Doesn't that take up a lot of ressources? What whould you recommend to loop rate to be, if implementing the protocal like this?

Any comments on solution #2?

[Sam_Sharp]

Yeah, you're kind of right here. I'm not really sure what the purpose of the interrupt is?

If you want buffered (and lossless) data - you need to use a DMA FIFO as you are doing. How are your datapackets formed? Is each one an array of values packaged up etc.? I guess you're using the interrupt to synchronise the packets (i.e. to know when one starts and another finishes)? I think the key thing to remember here is that an interrupt doesn't have any data - it's just used as a timing/synchronisation/handshaking mechanism. Think of it like a trigger. One use case is to use it for handshaking when reading data from FPGA front panels. You write to a front panel indicator in your FPGA, then raise an interrupt so that you can read it on RT.

The way I use FIFOs for sending 'packets' of values (for streaming multiple data values) is to add a header/footer (e.g. a particular start/end byte(s)) to the 'packet' being transferred - I use this for finding the start/end of each packet. This means I can continuously push my packets into the FIFO and then read out the whole lot and process them on the RT side - all you need to is read through the individual bytes until you find your header + N bytes + footer and read that off as an individual packet.

[A.E.M]

Again, Thanks for your replies.

Actually, I know my packages always consist of 3 elements in the DMA. I used the interrupt to signal that 3 elements has been written to the DMA.

I just tried to change that, so I doesn't use the interrupt anymore, but the host simply asks if 3 or more elements are availble. If so, the host reads 3 elements.

I think this is the most simple solution, but actually, I also think it is better than any oth the other proposed solutions? Any cavecats that I haven't thought of?

Regarding the interrupt I found the following in the "The NI LabVIEW High-Performance FPGA Developer's Guide".

"LabVIEW FPGA devices can synchronize with the host using hardware interrupts. Interrupts are useful in applications where the host waits for a signal from the FPGA, such as when you poll the status of an indicator to see if an event has occurred. This requires some host processing power to continually read from the indicator. Interrupts provide a polling-free method where the host does not need to query the device for its status, and, in turn, frees up CPU and bus resources.
Interrupts do have a higher cost per use than polling because of OS overhead. When an interrupt occurs, the OS often queries several devices to find the source of the interrupt, making interrupt latency dependent on your choice of bus, CPU, or OS.
Average interrupt latency is lowest on PXI systems with a high-performance embedded controller, where it typically is in the range of a few microseconds. CompactRIO controllers usually feature interrupt latency in the tens of microseconds, up to a hundred microseconds. Using LabVIEW Real-Time on the controller provides consistent interrupt latency, thanks to the deterministic OS response."

In conclusion, it could seem like my initial interrupt based method has a higher latency, than just keep asking if enough elements are availble in the DMA.

And that interrupts are great for Read/Write control actions, where you want to make sure the FPGA got the meassage.

[Sam_Sharp]

---

@A.E.P wrote:

I think this is the most simple solution, but actually, I also think it is better than any oth the other proposed solutions? Any cavecats that I haven't thought of? 

---

1) You can simplify it further by not even checking how many items are there, if you know the rate the data is being generated then just set the 'number of elements to read' to 3 with a longish timeout then you save the overhead of actually checking how many items are there

2) The only caveat to think about is what happens if you miss an element (e.g. because of an overflow / timeout / FPGA starting before your RT controller) - your data would become out of sync/shifted and you'll get the data in the wrong order/places. That shouldn't be a problem if you're careful about checking for overflows and at startup. This is why I add a header/footer to my data so if I go out-of-sync, I can find the start of the next set of data and read from there.

[A.E.M]

Thanks for your comments.

I do not know the rate, as it varies a lot. So I need to perform the check.

Good point about overflow. It is not something I'm too worried about, since the rate is so slow, that if an overflow should occour, it is because something else has gone completly wrong

Thanks for your help!

[A.E.M]

I just found an old example I made some time ago. Would you recommand to not use the interrupt in this example, and simply just make the host polling for the correct amount of samples?

This example works well, using only limited amount of resources on the host.

FPGA

HOST