Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
798 Views

SDRAM 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.
0 Kudos
16 Replies
Altera_Forum
Honored Contributor I
81 Views

Michel, 

 

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
Honored Contributor I
81 Views

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
Honored Contributor I
81 Views

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
Honored Contributor I
81 Views

 

--- Quote Start ---  

 

 

 

What's the size of your SDRAM? 

 

 

--- Quote End ---  

 

 

 

The SDRAM on my DE2-115 is 128MB.
Altera_Forum
Honored Contributor I
81 Views

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
Honored Contributor I
81 Views

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: 

 

buffer = ( alt_u32* )malloc( SDRAM_MAX_WORDS * sizeof(alt_u32)) 

 

Jens
Altera_Forum
Honored Contributor I
81 Views

 

--- 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
Honored Contributor I
81 Views

 

--- 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
Honored Contributor I
81 Views

 

--- 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
Honored Contributor I
81 Views

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_un... (http://www.altera.com/literature/hb/nios2/n2sw_nii52010.pdf?gsa_pos=3&wt.oss_r=1&wt.oss=alt_remap_un...

 

By default Nios/e and /s don't use data cache. 

 

regards, 

Jens
Altera_Forum
Honored Contributor I
81 Views

Thanks!! my SDRAM finally works now. 

 

I was using SDRAM to store .bss, .heap, .stack, and etc.. i found this when i navigate to the linker in the BSP editor. 

 

Then i changed them to SRAM, and everything works now. Except the SDRAM passed the DMA test, which i find it very strange. I did not include any DMA core that involves SDRAM, so how can it passed the DMA test? 

 

I used the memory test template code provided in Eclipse. 

 

Michael
Altera_Forum
Honored Contributor I
81 Views

Congrats! 

I don't know that memory test example. You may step through the code in debugger to get 

clarification. 

 

Jens
Altera_Forum
Honored Contributor I
81 Views

FWIW, I noticed some really strange nios2 runtime failures today, and after tracking it down I doscovered that the root cause was in fact that the instruction master's code address span was allowed to grow to cross more than 28 bits. It appears that we are actually limited to 25 bits of address times 32 bits for the external ram given that there must be room also for the debugger port, and also tigtly coupled code in on-chip ram. 

 

However, what was truely alraming (from my perspective) was that this _didnt_ produce any GNU ld linker errors at all as the QSYS warning suggests. Instead, in my observation this results only in production of defective object code which is only detected ultimately via runtime failures, but only if the processor jumps sufficently far in the address span. In my situation I was seeing bizarre jumps into unexpedted parts of the code but the code linked on the host just fine. 

 

I _am_ building with an older version of the GNU tools which _are_ specially configured to target the RTEMS RT OS so YMMV. 

 

$ nios2-rtems-ld --version 

GNU ld (GNU Binutils) 2.20 

Copyright 2009 Free Software Foundation, Inc. 

This program is free software; you may redistribute it under the terms of 

the GNU General Public License version 3 or (at your option) a later version. 

This program has absolutely no warranty.
Altera_Forum
Honored Contributor I
81 Views

 

--- Quote Start ---  

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. 

--- Quote End ---  

 

 

(Sorry for not being more active here; Altera keeps me pretty busy.) 

A few updates on this sort of stuff: 

 

nios2-elf-gcc 4.7 supports -Wa,-relax-all that allows 2GB programs at the cost of using multi-instruction sequences for every call (i.e. callr in place of call). Nobody is very happy with this solution, but it is there and is believed to work. 

 

nios2-elf-gcc 4.8 has 2GB-codespace support that basically Just Works, no special switches needed. This is done via linktime optimization (no relationship to -lto please note) which redirects out-of-range calls to local trampolines which then do the required multi-instruction callr dance. (nios2-elf-gcc should be available from Mentor within a week or so at http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/, and later in ACDS 14.1) 

 

nios2-elf-gcc 4.8 will have -mno-gpopt support again (present in nios2-elf-gcc 4.1.2 but missing from nios2-elf-gcc 4.7.3). Useful if your 64K .sdata segment is overflowing; bypasses the small-data optimization for the current compilation unit. 

 

nios2-linux-gnu-gcc 4.8 will have the -fpic/-fPIC distinction where the latter supports a > 64K GOT table. (Nios2 Linux c++ hackers have been hitting this limit.) Also -fpic supports 64K GOT table where 4.7 -fpic supported 32KB -- pointer is biased by 32K to allow use of negative offsets as well as positive offsets. 

 

Yesterday I discovered that apparently post-4.1.2 nios2-elf-gcc thinks that Nios2 builtins can throw exceptions; this can result in very small nios2-elf-g++ programs trying to fit into onchip RAM no longer fitting due to pulling in lots of exception-handling baggage. -fno-exceptions is a workaround for this problem. 

 

(BTW, on other fronts, Nios2-linux support is in the tubes for *crossfingers* mainline linux kernel 3.15 (https://lkml.org/lkml/2014/4/18/216) and nios2 support for mainline gcc 4.9. We're well on the way to having full nios2 support out-of-the-box in the complete Linux/GNU world. (Whee!!) And you didn't hear this from me, but Nios2R2 should allow full 4GB codespaces when it eventually trickles out to the wider world. No I can't, so don't ask. But if you look closely you'll be seeing "Nios2R2" starting to creep into opensource Altera releases from here on out. :-) )
Altera_Forum
Honored Contributor I
81 Views

On that note, we have been checking periodically at this site to see when the source code for the new tools (you referred to) might be available, but nothing has appeared so far.  

 

http://www.altera.com/support/ip/processors/nios2/ide/ips-nios2-ide-tutorial.html  

 

Any rumors on when this can be made available? We use the source code to build a cross compiler configured specifically RTEMS RTOS. 

 

Thanks, 

 

Jeff
Altera_Forum
Honored Contributor I
81 Views

 

--- Quote Start ---  

On that note, we have been checking periodically at this site to see when the source code for the new tools (you referred to) might be available, but nothing has appeared so far.  

 

http://www.altera.com/support/ip/processors/nios2/ide/ips-nios2-ide-tutorial.html  

 

Any rumors on when this can be made available? We use the source code to build a cross compiler configured specifically RTEMS RTOS. 

 

Thanks, 

 

Jeff 

--- Quote End ---  

 

 

Apologies -- my bad. I've been swamped with TOP! PRIORITY! interrupts and background processing has been getting starved. :-( I've moved that one up the jobqueue, alas not all the way to the top.
Reply