"readyfordata" won't work

I have found the solution for this issue. You guys told really the keyword. So the point uis that the master must support flow control, and yes, the cpu itself does not support that (except the waitrequest, what is really also a signal for FC, never mind...). The solution is to insert some Master/Slave component what supports the FC on the master side, and does not need FC on the slave side, for example DMA. I have done this, and now it works perfectly. "readyfordata" is not ignored now.

So, you guys were helpful again, thank you!

To answer your previous question, there is a difference between waitrequest and readyfordata.

waitrequest is checked *after* a transfer has begun, whereas readyfordata is asserted *before* a transfer occurs.

That's why there aren't seperate read/write wait requests. Once the avalon transfer cycle begins and is frozen by waitrequest, both the master and the slave are stuck until waitrequest is de-asserted, and no other master can access the slave. Its purpose is really more a "wait cycles" signal than actual flow control.

On the other hand the readyfordata can be read by the avalon switch fabric before a transfer starts. Now I never tested this, but in theory, if you imagine two masters connected to a slave that asserts dataavailable but not readyfordata, and the following events:

[list][*]master 1 wants to write to the slave, but readyfordata isn't asserted, so it must wait. The avalon switch fabric doesn't lock the slave yet.

[*]master 2 wants to read from the slave. dataavailable is asserted, so it performs the read

[*]the slave asserts readyfordata, and the master 1 performs the write.[/list]

If you do flow control with waitrequest, master 1 and slave would have been blocked on step 1 and master 2 wouldn't be able to read before master 1 is finished.

I haven't tested it, but I think this is how the avalon switch fabric works in this case.

Nevertheless this feature is seldom used. It is better to either use software flow control (as you suggested) for slow peripherals, or a DMA with fast peripherals.

A couple of things.

First, software based flow control can't use readyfordata nor dataavailable. Even for masters that do support control, the master does not have access to the readyfordata or dataavailable signals -- it's all managed by the fabric.

The master -- in the case, NIOS -- will always stall waiting for the slave.

In order to have software based flow control, the slave needs to have a register that can always be read and whose contents say if the "data" registers can be written to or read from without delay.

Which brings us to the reason why -MM flow control isn't so great in general: in slaves with multiple read/write registers, dataavailabe/readyfordata quickly become useless.

For example, if your slave has a status register that can always be read, dataavailable is always asserted.

-MM flow control is only useful for slave interfaced dedicated to streaming. Having status/control registers in the same interface quickly makes -MM flow control useless.

And if one is going to add a dedicated interface for streaming, it's better if it's a -ST interface.