What is the point of the IORD and IOWR macros? I can access my custom Avalon peripherals using them, but it seems like I can't access them like the following: volatile alt_u32 *DEV_PTR = DEV_0_BASE; alt_u32 data_in = 0; data_in = DEV_PTR[0]; However, I CAN access the Altera CFI flash memory peripheral using the simple memory access method shown above and read my flash! I do not understand the distinctions. I do understand that the macros avoid the cache. Thanks!

You just mentioned the difference. The macros avoid the cache - volatile does not - it only hints to the compiler that the value is volatile and not to optimize reads or writes to the variable. It works if you do this: volatile alt_u32 *DEV_PTR = alt_remap_uncached( DEV_0_BASE, sizeof( alt_u32 *) );Bill A

Volatile doesn't instruct the compiler to avoid the cache. It prevents the compiler from optimizing read/writes to the variable, ensuring that all read/write operations are indeed done by the compiled code. But it will still use the cache. The only ways to bypass the cache are the IORD/IOWR macros, and to map the accessed memory in uncached areas using alt_remap_uncached(), or the special uncached malloc functions. Edit: Sorry BillA, this is in fact exactly what you said... I should definitely NOT answer anything before my morning coffee...

Aren't there several ways to avoid issues with the data cache: 1) Don't add a data cache to the nios cpu 2) Get the compiler to use the ldio/stio instructions 3) Use addresses with the top bit set (MMU less systems) 4) If you are using the MMU, don't set the cacheable bit in the TLB What you do in the C source to get any of these does rather depend on your system. There is a compiler flag that is documented to use the ldio/stio instructions for volatile data - but you probably shouldn't use it!

To add to the list don't mix cached and non-cached accesses. For example don't do something like this: int * my_ptr = malloc (1024); for(i = 0; i < 1024; i+=4) IOWR_32DIRECT(*my_ptr, i, i); The reason why this is bad is that the memory returned from malloc came from the heap and you have no clue if it is cached or not. As a result if any of those IOWR accesses overlap a cached memory location you'll find that the cached value will be written out instead of the 'i' variable. Instead you should either flush the cache before the for loop or use the uncached macros since they'll perform the flush before performing cache bypass accesses.

Actually what might happen is that initially the code will write out the expected values, however at a later time any data lurking in the cache might be written out - overwriting the data written with IOWR_32DIRECT(). An example using malloc() is a bad one - since you need to ensure the data you are accessing uncached (or with specific cache flushes/invalidates) is cache line aligned, otherwise unexpected behaviour will happen at the ends of the area. This is especially true if you have other Avalon MM masters writing into the memory area. However, for areas like ethernet frame buffers it may be necessary to use cached accesses (to get adequate performance) even though the ethernet hardware writes into the data area. On x86 (and some others) processors this isn't a problem because the cache snoops the other memory accesses.

IORD IOWR macros vs. memory access to peripherals

15 Replies

Altera_Forum
Honored Contributor
15 years ago
You just mentioned the difference. The macros avoid the cache - volatile does not - it only hints to the compiler that the value is volatile and not to optimize reads or writes to the variable.

It works if you do this:

volatile alt_u32 *DEV_PTR = alt_remap_uncached( DEV_0_BASE, sizeof( alt_u32 *) );
Bill A
Altera_Forum
Honored Contributor
15 years ago
Volatile doesn't instruct the compiler to avoid the cache. It prevents the compiler from optimizing read/writes to the variable, ensuring that all read/write operations are indeed done by the compiled code. But it will still use the cache.
The only ways to bypass the cache are the IORD/IOWR macros, and to map the accessed memory in uncached areas using alt_remap_uncached(), or the special uncached malloc functions.

Edit: Sorry BillA, this is in fact exactly what you said... I should definitely NOT answer anything before my morning coffee...
Altera_Forum
Honored Contributor
15 years ago
Aren't there several ways to avoid issues with the data cache:
1) Don't add a data cache to the nios cpu
2) Get the compiler to use the ldio/stio instructions
3) Use addresses with the top bit set (MMU less systems)
4) If you are using the MMU, don't set the cacheable bit in the TLB

What you do in the C source to get any of these does rather depend
on your system.

There is a compiler flag that is documented to use the ldio/stio instructions for volatile data - but you probably shouldn't use it!
Altera_Forum
Honored Contributor
15 years ago
To add to the list don't mix cached and non-cached accesses. For example don't do something like this:

int * my_ptr = malloc (1024);

for(i = 0; i < 1024; i+=4)
IOWR_32DIRECT(*my_ptr, i, i);

The reason why this is bad is that the memory returned from malloc came from the heap and you have no clue if it is cached or not. As a result if any of those IOWR accesses overlap a cached memory location you'll find that the cached value will be written out instead of the 'i' variable.

Instead you should either flush the cache before the for loop or use the uncached macros since they'll perform the flush before performing cache bypass accesses.
Altera_Forum
Honored Contributor
15 years ago
Actually what might happen is that initially the code will write out the expected values, however at a later time any data lurking in the cache might be written out - overwriting the data written with IOWR_32DIRECT().

An example using malloc() is a bad one - since you need to ensure the data you are accessing uncached (or with specific cache flushes/invalidates) is cache line aligned, otherwise unexpected behaviour will happen at the ends of the area. This is especially true if you have other Avalon MM masters writing into the memory area. However, for areas like ethernet frame buffers it may be necessary to use cached accesses (to get adequate performance) even though the ethernet hardware writes into the data area.

On x86 (and some others) processors this isn't a problem because the cache snoops the other memory accesses.
Altera_Forum
Honored Contributor
15 years ago
A new quastion.
I d'like to find the documentation about the function can I use in Nios C code.
For esample: where can I find the IOWR documentation?

Thanks

Luca
Altera_Forum
Honored Contributor
15 years ago
here (http://www.altera.com/literature/hb/nios2/n2sw_nii52007.pdf), on page 9-4
Altera_Forum
Honored Contributor
15 years ago
Ok, I'm trying to write a simple code in order to write e read a register. I think about the interface of the register it is good. So when I write value it is perfect ( I test the writed data with signal tap) but, when try to read the data, the NIOS debug block: it isn't possible go on. If I put a break point on the line function IORD(...), and after press F6, the system stop.

Why? There is a problem? Where is?

Thanks

Luca
Altera_Forum
Honored Contributor
15 years ago
Sounds to me like the bus cycle isn't being terminated by your slave.
Altera_Forum
Honored Contributor
15 years ago
I can execute my program up to the IORD, but when it is execute the IORD line the progrma stop and return nothing. In the same time the signal tap run and I can see the chip_select, the readreq, the address and data signals: they are correct.

Why the read function fail?

Forum Discussion

IORD IOWR macros vs. memory access to peripherals

15 Replies

Recent Discussions

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

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

Nios-V on Cyclone IV

Debug Know-How: Ashling* RiscFree* NIOS® V debug using Command Line

NIOS SDK SBOM/FOSS info