instruction master address range only 256Mbyte ?

Hello Michael,

If bit 31 of the address is set the data cache won’t be used during this access. So if you read from 0x80000000 you will get the data from 0x00000000 (not 0x80000000) directly.

Regards,

niosIIuser

--- Quote Start ---

originally posted by niosiiuser@Feb 20 2006, 08:40 AM

hello michael,

if bit 31 of the address is set the data cache won’t be used during this access. so if you read from 0x80000000 you will get the data from 0x00000000 (not 0x80000000) directly.

regards,

niosiiuser

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12823)

--- quote end ---

--- Quote End ---

Hello niosIIuser,

so my information about bit 31 of the addressline was correct. Access to any data above 0x80000000 will not delive data from the cache. we still have the datacache problem with ldwio delivering old data even with q51sp1 & nios51sp1

But what i do not understand is the end of your posting. why does a read from 0x80000000 deliver data from 0x00000000 ???

And how can i do the address setup inside sopc without the 256MByte boundary ? i want to have the datacache for sdram, flash etc but not for my ip-modules. if i setup one of my ip modules to have its starting address at 0x80000000 i cannot re-generate the design as the button is greyed out.

Regards

Michael Schmitt

Hello Michael,

During a read or write access only the address bits 0 to 30 will be decoded. Bit 31 is used as a flag for using the data cache (0) or not using (1) it. So you only can address a space of 2 GByte. The behaviour is like mapping the addresses from 0x80000000 to 0x00000000. I think if you setup up a component to an address over 0x7FFFFFFF you will never reach it. If you want to access your own component without data cache then setup up the address of the component for e.g. to 0x10000000 and access it with 0x90000000.

Sorry I don’t know something about the 256 MByte boundary.

Regards,

niosIIuser

I had the same problem with the 256mByte thing. My local FAE gave me the following reply when I asked about this issue. Note however that this was back in Sep 05, so it may be out of date.

"This error is due to an issue with the global pointer and the linker script used in the Nios toolchain. Because the global pointer is only 16 bits long, it can only address a maximum of 256Mb of memory. if the instruction master is connected to memory greater than 256Mb, it flags this error. the global pointer is used to point to data located in the bss, .sbss, and .text reigons.

The work around is an unsupported feature in Nios 2, called allow_full_address_range, located in the /components/altera_nios2/class.ptf file, which overcomes the warning about crossing address boundaries.

Using this, and ensuring your program code (.text .rodata .rwdata) are all located in the same 256Mb segment will allow you to have a Nios system with >256 Mb of SDRAM, and allow you to execute code and store large amounts of data in the same SDRAM component. (dynamic data stored on the heap can be greater than the 256Mb limit: you must ensure all pre-initialised variables and structs are within the 256Mb limit)

you will also have to locate your stack within the 256Mb boundary too, using the following linker switches in the IDE

-Wl,-defsym -Wl,__alt_data_end=_0x0000FFF0

__alt_data_end is the name of the linker variable used to position the top of stack, as used in the generated linker script file. if you alter this, you can use it as a custom linker script.

I must stress the allow_full_address_range is an unsupported feature, and Altera wont support issues related to its use. (linker settings obviously not included in that!)"

I hope this helps