Interrupt signal sampling (Level or edge?)

It depends on the hardware that generates the interrupts, and nothing else.

If the interrupt is held until the service routine removes it, use level.

If the interrupt "just happens", and the device removes it automatically, use edge.

Priority is a different issue.

Thanks. This question came from other perspective, there are chances that noise might catchup on interrupt line connecting to FPGA which will be hosting the interrupt controller.

Under this condition what would be suitable method of sampling it.

We are thinking on clocked sampling.

That's a different issue. Let's back up a little.

You have an event, which you want to create an interrupt. And this event may be announced by a noisy signal.

If you have a "master clock" (you should) then the 1st thing to do is synchronize the signal with to the clock. (This is good practice for any signal.)

There are dozens of ways of removing noise from a signal. Debouncing is one way, and ony way to debounce is clocked sampling.

The issue boils down to response time. If you can wait, then you can filter out all sorts of noise. If you are in a hurry, then you cannot tolerate too much noise. If you have lots of noise, and want to react immediately, then you have a real problem... Peter Alfke, Xilinx Applications

I have one model in which i have sampled interrupt on main clock on both the edges and if the both edged samples match, i take them grated and proceed to initiate action. It gave me some noise immunity. (>2*Fclk)

Actually these are related to Power failure and critical fault conditions, when asserted will call for complete system switchover , the criticality is what matters here.

Just wanted to know is it a better practice to sample int on 'posedge' and 'negedge' and 'AND' them to get that noise immunity.

Thanks you for your inputs.

If this is an external signal, one thing to watch on level iterrupts, is you need to wait for the line to release, before re-enable of the interrupt - otherwise you simply re-enter the interrupt again.

-jg