How the avalon mm slave "address alignment" works?

The reason why I suggested 1 cycle of read latency is so that when the read event occurs you'll get the data exactly when it's been registered in your component. If these read events are infrequent then 5 would probably work but if that's not the case you might accidentally read old data when posting multiple accesses that are 5 cycles or closer together.

So there are two formats for these cache bypassing macros:

Native (IORD, IOWR) <-- Which I don't recommend for any new custom components since native addressing is deprecated.

Dynamic (IOWR_8DIRECT, IOWR_16DIRECT, IOWR_32DIRECT, IORD_8DIRECT, IORD_16DIRECT, and IORD_32DIRECT) <-- Dynamic means that the component is byte addressable (has byte enables).

The native macros use offsets based on word addressing of the slave port. So in this case IORD(base, 0), IORD(base, 1), IORD(base, 2) access words at addresses 0, 4, and 8 in your component. One key thing is that these offsets are based on the word size of the slave port and not the master so the bytes they access depend on the slave. This is why native addressing is deprecated since having the byte mapping change based on the slave width is a bit cumbersome.

The dynamic macros use offsets based on byte addressing. So because your component is 32 bits wide each word is located on a 4 byte boundary. This means to access each 32 bit register in your component you need to access byte addresses 0, 4, and 8. Using the dynamic macros should be accompanied by slave ports that have a byte enable signal for data widths greater than 8 bits.

So you are attempting to use dynamic addressing macros to access a native addressing component. Switching to 4 byte aligned offsets should correct any addressing issue so perhaps changing the read latency to 1 will solve whatever other issue you are facing.