Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorSDRAM problem in SOPC builder
Hi,
I get this warning message in SOPC builder saying: "Warning: cpu: The address range of the slaves connected to the NIOS 2 instruction master exceeds 28 bits. Attempts to call function across 28 bit boundary is not supported by GCC and will result in linker errors" when i try to add a SDRAM to my NIOS2 system which already has 128KB on-chip memory, and 2MB SRAM. But the warning message dissapears after i disconnect the instruction master bus from NIOS2 to the SDRAM. what is the significant of having instruction master bus connected to SDRAM? if i don't connect it, what disadvantage/advantage will i get? the obvious advantage is that, i can generate HDL, since there is no more warning message after disconnecting. i also found out that, if i define the base memory of SDRAM to be 0x00000000, and SRAM to be 0x0a800000, and lock them both without disconnecting any buses, the warning message will not appear... im confussed.. Someone please answer my question.. i really appreaciate it. Thank you. regards, Michael PS: I'm not a real ALTERA teacher... the forum tries to make fun of me after i asked too much questions here.16 Replies
Altera_ForumMichel,
if you disconnect the SDRAM from instruction master Nios processor cannot execute code from SDRAM. What's the size of your SDRAM? --- Quote Start --- "Warning: cpu: The address range of the slaves connected to the NIOS 2 instruction master exceeds 28 bits. Attempts to call function across 28 bit boundary is not supported by GCC and will result in linker errors" --- Quote End --- This warning means if you want use the SDRAM as program memory, the address span should be less then 28 bits. Jens- Altera_Forum
The nios's call (and jump) instruction encodings only have 26bits for the target address (the least significant bits are always zero) so a direct call (ie not through a register) cannot cross a 28bit boundary as the high 4 address bits aren't changed.
Without special code (which could, in theory, be added by the compiler or linker) this limits a program to 256MB. Within Linux (or similar) it will also stop shared libraries being loaded with code crossing a 256MB boundary). To get the warning you must either have instruction memory in more than one 256M block of address space - eg more than 256M of DRAM or DRAM and internal code memory. This warning itself can be ignored, but you have have to use function pointers if you need to call between the code areas. The linker will error these attempts. - Altera_Forum
A 'window bridge' could be created to limit the CPU visibility into the memory. They are pretty easy to implement, you make one side of the bridge have fewer address bits than the other and for the most part it acts as a passthrough. There are other reasons for using a window bridge but limiting how much address span is exposed to the instruction master happens to be one of them.
- Altera_Forum--- Quote Start --- What's the size of your SDRAM? --- Quote End --- The SDRAM on my DE2-115 is 128MB.
- Altera_Forum
It turns out when i defined the base memory of SDRAM to be 0x00000000, and SRAM to be 0x0a800000, and lock them both without disconnecting any buses, everything works fine, SOPC builder can proceed with HDL generation.
I then conducted a memory test using the following code on SRAM, SDRAM, and on-chip RAM; alt_u32 test_sram( void ) { alt_u32 i, val; alt_u32 errors = 0; alt_u32 buffer[SRAM_MAX_WORDS]; /* write data to sram */ for( i = 0; i < SRAM_MAX_WORDS; i++ ) { buffer = i + 1000;}
/* Check output from SRAM */[/I] for( i = 0; i < SRAM_MAX_WORDS; i++ ) { if( buffer != (i+1000) )
errors++;
}
return( errors );
}
and it works!!, and now similarly for sdram(does not work:cry:), and on-chip ram (works!)
alt_u32 test_sdram( void ) {
alt_u32 i;
alt_u32 errors = 0;
alt_u32 *buffer = (alt_u32 *)sdram_base;
/* Write data to SDRAM */[/I] for( i = 0; i < SDRAM_MAX_WORDS; i++ ) { buffer = (i );
}
/* Check output from SDRAM */[/I] for( i = 0; i < SDRAM_MAX_WORDS; i++ ) { if( buffer[i] != (i) ) errors++; } return( errors );} Any idea why? something wrong with my code here? the program will just stall during SDRAM memory test... it is trapped in the writing loop. I just can't figure out why, maybe it is something to do with chip select?, since i have 2 separate 64MB chips combined to form a 128MB SRAM chip on DE2-115, that different command for memory allocation should be used?:confused: Thanks! Michael
- Altera_Forum
Michel,
the size of your SDRAM should not be a problem. I doubled the SDRAM in my SOPC from 64Mx32 to 128Mx32 and I didn't receiver any SOPC builder errors (see attached JPGs). Did you typed in a correct memory profile and timing parameters for the SDRAM in SOPC builder? You could refer the DE2-115 System Builder which is able to generate a Quartus project. In your code the memory allocation for SDRAM is not complete. You should use:
Jensbuffer = ( alt_u32* )malloc( SDRAM_MAX_WORDS * sizeof(alt_u32)) - Altera_Forum--- Quote Start --- Did you typed in a correct memory profile and timing parameters for the SDRAM in SOPC builder? You could refer the DE2-115 System Builder which is able to generate a Quartus project. --- Quote End --- I copied the timing characteristics settings for SDRAM from terasic's example file(audio). so i think that should be fine. why did you ask me to refer to the system builder? to look at the auto-generated .sdc file ? or look for something else? Michael
- Altera_Forum--- Quote Start --- why did you ask me to refer to the system builder? to look at the auto-generated .sdc file ? or look for something else? --- Quote End --- It could be that the systembuilder tool generates a Quartus project file and a SOPC which you can use as a starting point for your design. Did you change the memory allocation in your code? You still have warnigs about address range? Jens
- Altera_Forum--- Quote Start --- It could be that the systembuilder tool generates a Quartus project file and a SOPC which you can use as a starting point for your design. Did you change the memory allocation in your code? You still have warnigs about address range? Jens --- Quote End --- I used the files generated from system builder from the very beginning. I was going to try the code you gave me, but then i realised, there is no SDRAM_BASE address given to the compiler? so how do i know the software initialize memory in the SDRAM and not in the processor cache, SRAM, RAM, or somewhere else? regards, Michael.
- Altera_Forum
Michel, if the SDRAM is not connected to the Nios processor (instructions or data master ports), the SDRAM_BASE will not defined in system.h.
Please have a look to that pdf: ftp://ftp.altera.com/up/pub/altera_material/9.1/tutorials/verilog/de2-115/using_the_sdram.pdf (ftp://ftp.altera.com/up/pub/altera_material/9.1/tutorials/verilog/de2-115/using_the_sdram.pdf) There is a tutorial how to use the SDRAM on DE2-115. --- Quote Start --- so how do i know the software initialize memory in the SDRAM and not in the processor cache, SRAM, RAM, or somewhere else? --- Quote End --- Memory initialization is done for the address range you give as parameters in the malloc() funtion. Cache is used to speed up execution if code and data access from slow external memory. Just parts of the data are stored temporary in the cache. If you need uncached access (e.g. if other masters have access to the SDRAM and manipulate data) there are special functions to do that (alt_uncached_malloc() or alt_remap_uncached()), see: http://www.altera.com/literature/hb/nios2/n2sw_nii52010.pdf?gsa_pos=3&wt.oss_r=1&wt.oss=alt_remap_uncached (http://www.altera.com/literature/hb/nios2/n2sw_nii52010.pdf?gsa_pos=3&wt.oss_r=1&wt.oss=alt_remap_uncached) By default Nios/e and /s don't use data cache. regards, Jens
