Hi,
Just wanted to know if in your sdram measurements you had both the on-chip memory and the sdram present in the qsys system? If yes, then one possible explanation for your timings is that the nios compiler is placing its reset and exception handling code in the on-chip memory (even if you have an sdram). If you truly want to test what the interrupt latency, response, and recovery times are with an sdram, you need to be sure that the nios compiler is placing its reset and exception handling code in the sdram as well.
You can check if this is happening by right-clicking on the BSP project in eclipse and checking the "linker script" tab (or something like that, unfortunately I don't have the tools installed on my machine to check myself). In the "linker script" tab there should be some entries that are grayed out and that you cannot change, and other entries that you can change. For the entries you can change, it should give you the option between on-chip and sdram. But for the reset and exception vectors, the options should be grayed out. If you want to change those entries, you need to go in qsys and select the nios processor, then change its reset and exception vectors there to point to the sdram. Then rebuilding the BSP project should give you a linker script where those 2 previously-grayed-out interrupt vectors point to the sdram.
Check the stuff above, then re-measure your timings when everything is running on the sdram. It should be much slower (I can't explain why your cache/no cache timings are not different though).
