Delayed Interrupt

[Altera_Forum]

Nios-II response to Continuous interrupt is delayed (sometime), due to this i am loosing my data  

 what precaution should i take to handle this issue  please have a look on print screen of my LA   earlier i am struggling with missing interrupt now i am getting interrupt but  their response time vary even though i have given best possible priorities  Regards  kaushal

[Altera_Forum]

It's not easy to help you without knowledge of your system implementation. I can only make a few guesses. 

First of all, the delay is in the 2us range. This short time is very difficult to manage in software.  You excluded this delay is due to higher priority interrupts, but common hw processes, like bus arbitration, memory burst accesses or other unpredictable events can lead to a non neglectable delay in this range. What's you processor system clock frequency? Is Nios the only bus master or do you have dma? Please also specify where the irq comes from. Is this a PIO interrupt? And how do you read the data being lost?

[Altera_Forum]

Is there any other sources of interrupt in your system? In that case there isn't a lot you can do, when the CPU is already processing an interrupt it won't be interrupted again. 

Do you realise that your CPU is spending more than 50% of its time in interrupt processing? It's not really what I would call an efficient design.

[Altera_Forum]

--- Quote Start ---  Is there any other sources of interrupt in your system? In that case there isn't a lot you can do, when the CPU is already processing an interrupt it won't be interrupted again. Do you realise that your CPU is spending more than 50% of its time in interrupt processing? It's not really what I would call an efficient design.  --- Quote End ---    No, this is the only interrupt source in my system

[Altera_Forum]

Use signaltap to monitor the code addresses, they might show what is happening.

[Altera_Forum]

--- Quote Start ---  It's not easy to help you without knowledge of your system implementation. I can only make a few guesses. First of all, the delay is in the 2us range. This short time is very difficult to manage in software.  You excluded this delay is due to higher priority interrupts, but common hw processes, like bus arbitration, memory burst accesses or other unpredictable events can lead to a non neglectable delay in this range. What's you processor system clock frequency? Is Nios the only bus master or do you have dma? Please also specify where the irq comes from. Is this a PIO interrupt? And how do you read the data being lost?  --- Quote End ---    What's you processor system clock frequency? 165mhz Is Nios the only bus master or do you have dma? yes, nios the only bus master i do not have any dma Please also specify where the irq comes from. Is this a PIO interrupt? yes this is a pio interrupt  And how do you read the data being lost? its visiable on la and at receiver i am not getting data also At every interrupt I read 2D array ImgBuff[460][640] do { if(edge_capture) { //Clear generated interrupt edge_capture = 0; IOWR_ALTERA_AVALON_PIO_DATA(TEMP_OUT_BASE,1); //(shown on LA) IOWR_ALTERA_AVALON_PIO_DATA(DATA_BASE,ImgBuff);//(shown on LA) Count++; } if(Count == PktSize) //check end of packet-data { Count = 0; //Point to Start of packet data LPktCount++; //Increment packet Count } IOWR_ALTERA_AVALON_PIO_DATA(TEMP_OUT_BASE,0); //(shown on LA) }while(LPktCount != (PktCount+1));

[Altera_Forum]

Is below code is correct for using Enhanced Interrupt ....as while compiling there is no error but during porting this code to nios downloading process stuck at 80% and nothing will happen afterword 

 i found through altera literature that using enhance interrupt we may significantly improve our interrupt response time   //------------------------------------------- //#ifdef LOAD_DATA_BASE # ifdef ALT_ENHANCED_INTERRUPT_API_PRESENT static void handle_load_data_interrupts(void* context)# else static void handle_load_data_interrupts(void* context, alt_u32 id)# endif { /* Cast context to edge_capture's type. It is important that this be declared volatile to avoid unwanted compiler optimization. */ volatile int* edge_capture_ptr = (volatile int*) context; // IOWR_ALTERA_AVALON_PIO_IRQ_MASK(LOAD_DATA_BASE, 0xf ); /* Store the value in the Button's edge capture register in *context. */ *edge_capture_ptr = IORD_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE); /* Reset the Button's edge capture register. */ IOWR_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE, 0XF); /* Read the PIO to delay ISR exit. This is done to prevent a spurious interrupt in systems with high processor -> pio latency and fast interrupts. */ IORD_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE); } /* Initialize the load_pio. */ static void init_load_pio() { /* Recast the edge_capture pointer to match the alt_irq_register() function prototype. */ void* edge_capture_ptr = (void*) &edge_capture; /* Enable all 4 button interrupts. */ IOWR_ALTERA_AVALON_PIO_IRQ_MASK(LOAD_DATA_BASE, 0xf); /* Reset the edge capture register. */ IOWR_ALTERA_AVALON_PIO_EDGE_CAP(LOAD_DATA_BASE, 0xF); /* Register the interrupt handler. */ # ifdef ALT_ENHANCED_INTERRUPT_API_PRESENT alt_ic_isr_register(VIC_IRQ_INTERRUPT_CONTROLLER_ID, VIC_IRQ, handle_load_data_interrupts, edge_capture_ptr,0x0); # else alt_irq_register( VIC_IRQ, edge_capture_ptr, handle_load_data_interrupts); # endif } //#endif /* LOAD_DATA_BASE */ Main() { printf("\nInitillize the Enhanced Interrupt..\n"); init_load_pio(); }

[Altera_Forum]

--- Quote Start ---   i found through altera literature that using enhance interrupt we may significantly improve our interrupt response time   --- Quote End ---   I think you could get much better speed improvement if you place ImgBuff, isr and other time critical code in onchip memory and connect to Nios with Tightly Coupled ports.

[Altera_Forum]

--- Quote Start ---  I think you could get much better speed improvement if you place ImgBuff, isr and other time critical code in onchip memory and connect to Nios with Tightly Coupled ports.  --- Quote End ---    Sorry i haven't much idea about how to put "ImgBuff, isr and other time critical code in onchip memory and connect to Nios with Tightly Coupled ports" in onchip memory though i have onchip memory in my sopc  please give some clue or literature which guide me in this direction.

[Altera_Forum]

Open Qsys and go to Nios properties.  

Add a tightly coupled (TC) code port and possibly a TC data port. Close Nios properties. Add 2 onchip memories and connect one of them to Nios TC code port and the other to TC data port. In your case I believe 4kByte for TC code memory is enough. TC data must be large enough to store ImgBuff, then size >= (460 x 640 x 4) if you need 32bit data; this would be more than 1MByte and probably exceeds your fpga resources, so you can not use TC data and you have to keep data in ddr2. Now, let's say you named tc_code your TC memory component.  Then place the following directive just after the declaration of a function you want to be executed in TC memory:  int main(void) __attribute__ ((section (".tc_code"))); The same can be done with variable you want to be accessed very very fast:  int fastBuffer[256] __attribute__ ((section (".tc_data")));

[Altera_Forum]

You could also monitor the CPU avalon master's waitrequest signal. The stall you are seeing could come from a peripheral that is freezing the CPU, the SDRAM controller doing a refresh cycle for example.

[Altera_Forum]

Actually, if you look at the timing trace you'll see that there is a relatively long time between the interrupt request and your ISR running. 

Throw away the Altera interrupt code and write your own. Even if you have to save/restore the registers it shouldn't take anywhere near the length of time that code takes. If you can use an 'alternate register set' then you should be able to get interrupt entry/exit down to a few clocks. (even without it you might manage to write an asm ISR that doesn't use any registers that the main code uses)   I also presume you are not running the JTAG debugger at all - it wouldn't surprise me if that doesn't take some interrupts.  You might also want to look at adding a short fifo (a couple of items) on the input and output - that will mean that the system will handle a longer interrupt latency.

[Altera_Forum]

--- Quote Start ---  Open Qsys and go to Nios properties.  Add a tightly coupled (TC) code port and possibly a TC data port. Close Nios properties. Add 2 onchip memories and connect one of them to Nios TC code port and the other to TC data port. In your case I believe 4kByte for TC code memory is enough. TC data must be large enough to store ImgBuff, then size >= (460 x 640 x 4) if you need 32bit data; this would be more than 1MByte and probably exceeds your fpga resources, so you can not use TC data and you have to keep data in ddr2. Now, let's say you named tc_code your TC memory component.  Then place the following directive just after the declaration of a function you want to be executed in TC memory:  int main(void) __attribute__ ((section (".tc_code"))); The same can be done with variable you want to be accessed very very fast:  int fastBuffer[256] __attribute__ ((section (".tc_data")));  --- Quote End ---   my Qsys not opening my sopc file it display only clock is it some kind of license issue i am using quartus 11.0 sp1

[Altera_Forum]

--- Quote Start ---  my Qsys not opening my sopc file it display only clock is it some kind of license issue i am using quartus 11.0 sp1  --- Quote End ---   How did you design your system before? IIRC Qsys in Quartus 11.0 doesn't open automatically the design and presents you the basic clock+reset default system; you simply have to load your actual design from File menu. If the TC solution is not enough for you I'd follow dsl's tips, especially the alternate register set and the fifo.

[Altera_Forum]

You probably also want to arrange for the 'small data segment' to be in the on-chip memory and use section names ".sdata.*" so that the compiler will generate %gp relative addressing for the accesses. 

Unfortunately the Altera builds of the compiler will not use %gp relative addressing for members of structures or arrays allocated to the 'small data' section. There are some gcc patches on the wiki that will make gcc use %gp relative addressing for structure members (constant offset from %gp), but not for arrays. An alternative is to put all the global data inside a single structure (max 32kb) and use a global register variable to access it. gcc can generate better code for this than when using 'small data'. With care you can use %gp for the global register!