60% performance loss when using µC/OS-II?

[Altera_Forum]

Hi all, 

 my application doesn't work anymore after integrating it into the Webserver template.  In trying to find the cause, I'm using the Altera-provided Dhrystone test. When run in a stand alone example, it reports 119DMips (as you'd expect from a 100MHz NIOS-II/f). When run from a µC/OS-II template, it reports only ~35DMips. Even if called right after main(), before the creation of any Task and calling OSStart(), I don't get above 40 DMips. I already tried disabling all interrupts and disabling hardware initialisation in alt_main(), but no change.  The hardware has a NIOSII, ICache, SDRAM, EPCS and CFI running at 100MHz, and some periphereals including UART, TSE&SGDMA, PIO, EPCS running at 50MHz. Periphereals are separated using Clock crossing resp. pipeline bridges, where it made sense to me. I changed the system to a minimal one (NIOS2/f, ICache, SDRAM, EPCS, JTAG-Uart, SysclkTimer, TimestampTimer), but the preformance impact doesn't change.  Can someone point me to what I am missing? Thanks!

[Altera_Forum]

Have you placed program code and stack into onchip memory as recommended?

[Altera_Forum]

No, I don't plan to use onchip RAM, as I have plenty of SDRAM running at cpu_clk. 

 I will need the onchip RAM for DCache and ICache, periphereal FIFOs aso. I have no idea how much onchip RAM will be left after completing the system.  Anyway, I'll try it and report back.

[Altera_Forum]

I took a look at the Dhrystone sample and they recommend: 

- 4KB I-cache - 2KB D-cache - 64KB onchip memory - program code and stack mapped to onchip memory. Even is sdram runs at cpu_clk it will never be as fast as onchip memory because it generally needs multiple cycles to access data.

[Altera_Forum]

from experimentation, SDRAM and the SDRAM controller provided in SOPC can only provide about 10% throughput to NIOS.  

 This is a SOPC problem, not SDRAM controller.   The SDRAM controller in SOPC is actually quite well written and can provide about 98% throughput if you write your own master to read and write to it.   Your best option for running code in an FPGA seems to stick to on chip memory for any time critical code.