IORD IOWR macros vs. memory access to peripherals

[Altera_Forum]

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!

[Altera_Forum]

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]

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]

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]

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]

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]

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]

here (http://www.altera.com/literature/hb/nios2/n2sw_nii52007.pdf), on page 9-4

[Altera_Forum]

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]

Sounds to me like the bus cycle isn't being terminated by your slave.

[Altera_Forum]

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?

[Altera_Forum]

do you have a waitrequest signal from your peripheral?

[Altera_Forum]

Yes, but I'm sure the waitrequest of the peripheral it is always low. 

The only particuliarity of the slave peripheral is the latency: in the read process the data is registered. There is same problem if the read latency is different to 0 ?

[Altera_Forum]

If you have a waitrequest signal, I don't think that the read latency parameter is used by the switch fabric anyway. 

If the waitrequest signal is low there is really no reason why the CPU should freeze. Are you sure that the address that you use in the IORD macro is actually the right one? Are the CPU data master and your custom component on the same clock domain? If not, could you check if the clock for your component's slave interface is actually running? Is your design properly constrained and does it meet all timing requirements?

[Altera_Forum]

hey guys im new to sopc,nios design.. 

my intention is to instantiate nios2 n sram .do read write operations via c program.  i configured FPGA with nios2 processor and SRAM from university programm(DE1 BOARD,CYCLONE). IF WE HAVE MACROS TO ACCESS MEMORY THEN what about the pins of sram. how do i write into those pins in C language. we suppose to write in memory mapped memory adresses of pins assigned by SOPC . but it wont giv address map for those controll pins of sram. it only states initial address of sram.  pls help..  this is instantiated VHDL code.  component rams is   port (  -- 1) global signals:  signal clk_0 : IN STD_LOGIC;  signal reset_n : IN STD_LOGIC;  -- the_income  signal in_port_to_the_income : IN STD_LOGIC_VECTOR (7 DOWNTO 0);   -- the_outgo  signal out_port_from_the_outgo : OUT STD_LOGIC_VECTOR (7 DOWNTO 0);   -- the_sram_0  signal SRAM_ADDR_from_the_sram_0 : OUT STD_LOGIC_VECTOR (17 DOWNTO 0);  signal SRAM_CE_N_from_the_sram_0 : OUT STD_LOGIC;  signal SRAM_DQ_to_and_from_the_sram_0 : INOUT STD_LOGIC_VECTOR (15 DOWNTO 0);  signal SRAM_LB_N_from_the_sram_0 : OUT STD_LOGIC;  signal SRAM_OE_N_from_the_sram_0 : OUT STD_LOGIC;  signal SRAM_UB_N_from_the_sram_0 : OUT STD_LOGIC;  signal SRAM_WE_N_from_the_sram_0 : OUT STD_LOGIC  ); end component rams;   it gives mem mapped adress of income n outgo(these r pio_0 n pio_1). but not for other signals out there.

[Altera_Forum]

You don't directly control the pins from the software. Just access the memory from your code through pointers and/or the IOWR/RD macros and the hardware will control the sram pins accordingly.