Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

SRAM Read/Write too slow

Altera_Forum
Honored Contributor II
1,191 Views

Hello, 

 

im using the nios development board (stratix edition) and the standard reference design delivered by altera. On the Nios i have the MicroCOs running. And in the Nios IDE (im using Nios IDE 9.0 sp2 and Quartus 9.0sp2) in the "System Library Properties" i set all the memory types ( Program mem, heap, stack etc).  

 

 

 

So now somewhere in the SRAM there a data that i have written into the SRAM before. And now i allocate memory via "malloc" and i want to write the data from the SRAM into my allocated memory. This is the following code 

 

char *wrpos = (char*) image->data; 

unsigned long nmb_pixel = image->width*image->height; 

 

IOWR( PIO_0_BASE, 0, 1 ); // used to measure the time 

 

for( i=0; i<nmb_pixel; i++ ) 

 

//value = IORD_32DIRECT( c_BaseAddrRam, img_addr_offset + (i*4) ); 

 

 

wrpos[i] = (unsigned char) (IORD_32DIRECT( c_BaseAddrRam, img_addr_offset + (i*4) )>>8); 

 

 

 

IOWR( PIO_0_BASE, 0, 0 ); // used to measure the time 

 

 

So now my problem is, that the the call of IORD_32DIRECT(), which does a read acces to the SRAM, needs about 300ns. Because my sysclk is 50Mhz this means that the access to the SRAM needs about 15 clock cycles. But when im writing the data into the SRAM via my own vhdl-module a write access only needs one clock cycle (as i expect it on a SRAM) 

 

So my question is: Can anybody explain me why the access to the SRAM from Nios C Code is so slow? Can i make the access more faster? Or is it typical that it is so slow?
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
478 Views

Hi, 

have you already checked, what code is generated by the compiler (e.g. in the disassembly window) ? Especially in the debug version the compiler produces a lot of code. For the loop itself and the IORD_DIRECT32 access it is easily possible that 10-15 instructions are generated. So I think it is not a slow access to the sram which makes this code slow, it is the number of instructions which are generated. The release version should be faster.
0 Kudos
Altera_Forum
Honored Contributor II
478 Views

In particular you need to compile everything with -O2 or -O3. 

IMHO this should be the default, and you need your head examined before doing anything else. 

 

The Avalon bus write will be at least 2 clocks, they are always synchronous, never 'posted' by the nios (they may be posted by the slave). 

Reads are also synchronous, they are also subject to a 2 clock delay before the value can be used (this is after the Avalon cycle completes). 

 

Also check that no 'clock crossing bridges' have been added by the sopc builder - this is rather hard since it won't tell you where it has put them!
0 Kudos
Reply