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.

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

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.

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.

--- Quote Start --- What's the size of your SDRAM? --- Quote End --- The SDRAM on my DE2-115 is 128MB.

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

SDRAM problem in SOPC builder | Altera Community

16 Replies

Altera_Forum
Honored Contributor
14 years ago
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
14 years ago
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
12 years ago
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
11 years ago
--- 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
11 years ago
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
11 years ago
--- 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.

Forum Discussion

SDRAM problem in SOPC builder

16 Replies

Recent Discussions

JTAG_UART stuck in printf

NIOS SDK SBOM/FOSS info

NiosV µC/OS-II

Recommended Quartus Prime Standard Edition for Nios V Development on MAX 10 FPGA (10M25DAF4817G)

AshlingRISCFree IDE Build system: 'source directory does not appear to contain CMakeLists.txt"