Nios interrupt response time

[Altera_Forum]

I have a custom SOPC component which has an interrupt sender (irq_n) in it's avalon interface. In my SOPC component HDL I set the irq_n line low, which causes a Nios interrupt handler to fire. In the ISR I perform an avalon read of the custom component. As soon as the avalon read occurs I cancel the interrupt by setting irq_n high in the HDL. 

 This all works fine and as I would expect.   I then did some interrupt response timing by running a counter to see the number of clock cycles between irq_n low and irq_n high. This is taking 10,000 clock cycles or about 200us as my clock is 50MHz.  Does this figure look reasonable?   I thought 10,000 clocks seemed a long time. I measured it using SignalTap but I was JTAG debugging the Nios uP at the same time, could that affect the result? I would not expect so as the JTAG uart interrupt was lower priority than the custom component.  Thanks.

[Altera_Forum]

how is your nios system designed ? -e -s -f Nios ? if you have data cache what about cache flush if the irq occurs ? what memory type do you use whats its latency ?  

 of course 10000 clocks are a lot, it depends upon how fast nios can realy enter the irq, save the stack and registers and clear your irq

[Altera_Forum]

It's a standard Nios (-s). There is an instruction cache but no data cache. The memory is SDRAM (part no = MT48LC16M16A2P-75) clocked at 80MHz. The sdram settings in SOPC builder are: 

 CAS latency cycles = 3 Initialization refresh cycles = 2 Issue one refresh command every = 15.625us Delay after powerup, before initialization = 100us t_rfc = 66ns t_rp = 20ns t_rcd = 20ns t_ac = 6ns t_wr = 20ns

[Altera_Forum]

I have the same problem, I use Nios 2 /f 9.1 with EIC and shadow registers enabled, I also add a VIC in the SOPC system. My memory is a 512MB DDR2-400 unbuffered DIMM. Still, it can't respond to USB setup package interrupt on time, which leads to the USB interface to be suspended by the host. Somebody help!

[Altera_Forum]

I'm investigating a similar problem under 9.1.  

 NIOS loses uart interrupts (characters) if data cache is turned off.  Either standard or fast cores.  Either standard interrupt controller or vectored interrupt controller.  I took "hello_world.c" and put a "gets()" in a loop and it drops characters like crazy.  It works fine if the data cache is turned on at 512.  I've lost a lot of time to this.  Mike

[Altera_Forum]

Take a look at the vic an example designs (http://www.altera.com/literature/an/an595_vic_collateral.zip) to get a reference point for Nios II interrupt performance. 

 I'm not sure what (exactly) could be causing the large delays that you're all seeing, but these are largely system dependent. I recommend starting with small, simple systems (like what's included in the examples) and building (interface-by-interface) from there.  @mikebray: What speed is your UART? The Altera supplied UART has no internal buffering, so I'd expect dropped data if the CPU's not able to keep up.  @All: External memory can cause large and unavoidable latencies. Be aware of this and design your hardware and/or hardware interfaces appropriately.  Cheers,  - slacker

[Altera_Forum]

Finally I use EIC+Shadow Register+VIC+Tightly Coupled Memory achieved a 30-90 cycles interrupt response time, which means the first instruction in the ISR is executed(finished) 30-90 cycles after the corresponding IRQ is asserted. 

To make the full use of TCM, I assign the whole .exception section to TCM. Then I assign the ISR funtion and VIC vectior table to .exception section.

[Altera_Forum]

I'm having the same problem. I have a Nios /e with only a jtag uart. And there it's loosing also interrupts, as I see it doesn't always receive the characters I type in. For example: If I type 1234 it shows sometimes 234 and sometimes 1234. 

 I was wondering if it's possible to generate only a jtag uart and connect this to some fifo buffer and feed that buffer to the nios.   Or is there something to priorities the jtag uart interrupt in a nios /e?

[Altera_Forum]

Me too. Just 28 cycles for nios/f +EIC+VIC+SDRAM+shadow rsgister+1K cache with 100Mhz Clock. Used to be 1600 cycle for nios/s +IIC +SDRAM with 50MHz Clock. I use the SignalTap II logic analyzer to measure the interrupt response time. Obviously EIC comes with much better performance than the IIC and could be implemented for the real time applications.