Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.

Nios f / Custom MM Slave

Honored Contributor II

Hi all, 


I know this has been asked several times on the forum but I must be missing the point as I'm still at encountering the issue. I have tested my SoPC fine with the nios e.  

The problems occur when using the nios f. I have the data and instruction caches set to 4kb's, and after a bit of reading(and testing) I know I need to bypass my data cache to successfully test my system with my custom MM slave. The address of my MM slave in Qsys is 00081_1100 - 0x0081_117f.  


In my header file avs.h, the base address matches that of system.h(and Qsys of course) 


#define avs_base 0x811_1100 


As I'm using HAL, I know there are 3 methods to bypass the cache: 


1. Bypass by using IORD and IOWR. 

2. Set bit 31 

3. Use alt_remap_uncached() 


As I have my program written, I was hoping to implement# 3 in my avs.c file by the following method: 

# include "aes.h"# include <stdio.h># include <sys/alt_cache.h> ........................# define avsrange 177 int main{ // insert alt_remap_uncached ....... }  


Would I be correct so far, and in saying this would be the most straightforward method to implement? 

I have reviewed the documentation but it's not becoming any clearer in my mind. 


Going by this document ( the function is defined as 


volatile void* alt_remap_uncached (void* ptr, alt_u32 len);  

where 'ptr' is starting address and 'len' is the memory range. 


So, would this translate, in my example, to: 


alt_remap_uncached((void*)AVS_BASE, avsrange); 


Edit: I know the last piece of code does not work. Also, I am not using the nios MMU so perhaps option 2 is workable.
0 Kudos
2 Replies
Honored Contributor II

alt_remap_uncached() simply returns a new pointer with bit 31 set. Your code fragment doesn't show you are doing anything with the return value, so perhaps this is the piece you are missing? 


alt_u32 *my_block = alt_remap_uncached( AVS_BASE, avsrange ); my_block = foo;
Honored Contributor II

Thanks, I resolved this by ANDing my custom components base address with 0x8000_0000 to set MSB to 1. Still having issues but data is no longer cached. 

I'm debugging at the moment so I think this resolved the caching issue. 

In the header file, avs.h: 


#define AVS_BASEADDR (0x811100 | 0x80000000)