read and write timings on avalon interface

Are you running code out out internal (tightly coupled M9K) memeory?

If you are running from anything else (via the i-cache) that could easily cause 'random' timings.

If you avoid calls into libc, and sort out the fubar of main() v int_main() you should be able to get a very small object image.

You also want to have all other data areas tightly coupled - exept for anything that has to be external (in which case the d-cache may also be pointless). Otherwise cycle times will not be deterministic.

Also, you peripheral needs to expose a 32bit interface, otherwise there are likely to be multiple cycles - even for a byte access.

The difference between writing zero and non-zero could well be in the object code, the non-zero value needs to be generated, the zero is in r0.

14 cycles sound more like the time for a sdram access - especially a full burst for a cache line.

With no other avalon bus cycles, I believe the cpu will continue exection following the write until another avalon cycle is requested. Similarly it will continue after issuing a read until an instruction needs the value.

A 'lateral thought' option is to use custom instructions to interface with the peripheral, not the Avalon bus .....