Forum Discussion
19 Replies
- Altera_Forum
Honored Contributor
Mapping it to an address over 2^31 should do.
Note that the physical address (in SOPC etc) needs to have the top bit clear. - Altera_Forum
Honored Contributor
dsl -
Not certain I understand this - will NIOS be able to set up a table in this ram? isn't 2^31 above 0x8000 0000? I need the processor to parse queue fill levels and build a descriptor chain accordingly upon receipt of an aggregated interrupt... I am having all kinds of @$$-ache trying to get the pointers to function correctly and am surmizing (since sometimes the table is build half-correctly) that I am seeing a cache coherency issue... Is there a way to disable data caching during operations to memory? - Altera_Forum
Honored Contributor
If you haven't enabled the MMU, then a31 acts as a 'cache bypass' when accessing Avalon MM addresses rather than as an address line. You may need to ensure the bit is masked if other Avalon masters use the addresses.
Another way is to use the ldio/stio instructions (which is what the IORD macros do). The third way is to remove the data cache entirely and put all your data (including the rodata sections) into tightly coupled data areas. This is only really an option for small systems though. - Altera_Forum
Honored Contributor
But SOPC builder gives me an error when I try to map this... do you mean that I should place it at a physical address in SOPC builder - say 0x2000 0000 as an example but when I access is address it as 0xA000 0000 from nios?
- Altera_Forum
Honored Contributor
Yes, that is what I mean.
You might have to fight the linker script if you are building with the IDE. I tend to avoid IDEs as much as is physically possible. - Altera_Forum
Honored Contributor
Why don't you use the alt_remap_uncached() function at run time? If you use it on a pointer to the descriptors, it will force the CPU to avoid the cache.
Another alternative could be to flush/invalidate the cache when needed, as is done in the Altera HAL functions that handle the descriptors. - Altera_Forum
Honored Contributor
Isn't alt_remap_uncached() only relevant to systems with an MMU?
Or does it return an address with the top bit set when the mmu isn't enabled. - Altera_Forum
Honored Contributor
@dsl - no and yes. And it also loops through the amount of data you tell it is at the pointer flushing cache which is costly time-wise.
Bill A - Altera_Forum
Honored Contributor
Using alt_remap_uncached() is supposed to make code more portable than changing bit 31 because it works with both MMU and non-MMU systems. I just say "supposed" because I never tested it myself
- Altera_Forum
Honored Contributor
you don't need to avoid IDE for this one. For ALL of my memory mapped SOPC components, I declaire a pointer to my HW\memories in C code like this:
#define data_cache_bypass_mask 0x80000000volatile alt_u32 * uart_pointer = (volatile alt_u32*)(avalon_uart_0_base|data_cache_bypass_mask); then you can access your block\memory like uart_pointer[0] = 0xDEADBEEF; and the datacache bypass mask is already applied by the compiler.