Honored Contributor
Honored ContributorI forget if Nios II really performs a 16 bit access with IORD_16DIRECT. I know a while back it always asserted all four byte enables no matter the width of the read and it just ignored the unwanted byte lanes. So if you use IORD_16DIRECT with your component it may see two 16-bit accesses and the upper 16 bits get tossed away when the 32-bit data returns to the CPU. IOWR_16DIRECT will only issue the upper or lower two byte enabled depending on the alignment of the access. So those might solve the problem (should for writes at least) I think it would be easier if you just made your slave match the CPU data width (32-bit). The upper 16 bits you can just leave disconnected on the write data and for the read data you can ground them out, shove some random 16-bit value and ignore them in software, etc...
I always use the 'DIRECT' macros just as a preference thing. One thing to keep in mind is that the offset you pass to the macro is a byte offset and not a word offset like it is for IORD and IOWR. So if you wanted to use IOWR_16DIRECT to write to a bunch of registers you would use offsets 0, 2, 4, 6, 8, etc... This is one of the reasons why I stick to the 'DIRECT' macros, I've seen others mix and match IORD/IOWR with the DIRECT macros and ended up messing up the offsets between the two sets of macros.
