Minimal pulse duration for VIC to recognize an interrupt?

--- Quote Start ---

You should keep your IRQ asserted until it is cleared by the software ISR routine. I'm not sure the VIC's behaviour is defined or guaranteed if you clear the IRQ yourself before that.

--- Quote End ---

Yes, normally I would agree on this. In my case the periferal is an ethernet controller (LAN9211), programmed to send an interrupt as soon as new data is available. The controller asserts the irq high until the data is read by the Nios. If I don't want to read the data inside the interrupt routine (because of runtime determinism), I can't reset the irq and because the "Interrupt Sender" component is level sensitive, the isr will be called non stop.

So what I did was implementing a vhdl edge-detector on the irq input that generates a pulse of 1 clock cycle which, as stated above, is not long enough to be caught by the VIC.

Therefore I'm trying to figure out how long I would have to stretch the pulse to be caught.

What is usually done in that case is that the interrupt service routine reads the interrupt status register, stores its value somewhere, clears it and then returns, asking the scheduler to run a DSR when possible. If the operating system you use doesn't supports DSR's, you can have the same behaviour by having the ISR release a semaphore before returning, waking up a task that would handle the communication.

You don't have to wait until you actually read the data to clear the interrupt.

--- Quote Start ---

...the interrupt service routine reads the interrupt status register, stores its value somewhere, clears it and then returns...

--- Quote End ---

Yes, that's what I would normally do with an edge-triggered PIO interrupt source, but in this case I can't clear the interrupt status register, because this would mean (if I'm not mistaken) I had to clear the logical signal on the interrupt pin too, which is impossible as this pin only goes low after all pending data has been read from the LAN9211.

But - writing this answer - I just had an idea:

What about disabling the interrupt source inside the isr. In this case the LAN9211 can drive the irq pin high for as long as it wants, without the Nios reacting on it. And when I actually have time to read the data I can re-enable the interrupt source.

Does this sound reasonable, or will I get other problems by disabling and re-enabling interrupt sources inside an isr?

I had a look to the datasheet before sending my reply, and if I'm not mistaken you can clear the IRQ signal from the LAN9211 just by writing to the interrupt status register. You don't have to actually read the data. That's why I suggested that way of doing it.

Disabling the interrupt from the isr should be possible (I assume you want to mask the interrupt source in the VIC?) without any problem, but I think it is better to disable the source directly in the LAN chip. That way you won't have any trouble porting your code to a system without VIC one day, if required.

Thanks a lot for all your effort on my problem

Yes, you're right, you can clear the interrupt signal from the LAN9211, that's the first thing I tried - but as the condition for the interrupt is still met (data level >= 1 eth-packet), the LAN9211 will just assert the interrupt again next clock cycle.

There are 2 solutions I see:

1. Disable the interrupt either in the Nios or in the LAN9211.

2. Route the interrupt signal to a PIO component (or similar) which can handle edge-triggered interrupts.

Anyways, thanks for your help, I got some new ideas for my problem now I can try. :)

Oh ok. That was what I was missing ;)

It is strange they did it that way, because deferred interrupt handling is necessary in real time OSes...

In that case instead of just clearing it, you could disable it in the "Interrupt Enable Register" until you read the data, as you suggest in (1)