avalon memory mapped protocol

[Altera_Forum]

Hello, 

I have a question regarding the avalon memory mapped(mm) protocol. we're going to use avalon-mm in pipeline mode (master), while the sopc builder generates the slave part to which we connect. we're concerned of problems with the wait_request signal. since the wait_request may be asserted by the slave at the same time of the write, it can't be the out of a Flip-Flop. and since the master side must not send the next data, it can't sample this signal before using it. Therefore, the wait_request may have a very long path and will cause timing violations. why doesn't the avalon-mm protocol defines wait_request latency, like the ready_latency in the avalon streaming protocol? how should we handle these problems?

[Altera_Forum]

This signal can't have any latency because the master must know right away if it can send a new operation. You can avoid having a long path on that signal by defining it as a simple combination of the read/write signals and the output of a flip-flop that you control.

[Altera_Forum]

Hi, 

Even If I do as you say, I may still have long paths, simply because of the distance between the source of the wait_request signal to the desitination of the wait_request signal (which is probably near a memory element which has fixes locations.(assuming high clock frequencies) This may be even more difficult in case the source of the wait_request signal is logic-locked to certain location which is remote from the destination of the wait_request signal.  If there whould be a wait_request latency(at least for the pipeline mode) like in the avalon streaming protocol, the master could treat the wait_request signal at more ease(sampling it to ensure timing), since it has some spair clocks in which it could still send data.

[Altera_Forum]

Just let the fitter do its job, the delays don't always come from you expect. If you have trouble meeting timing requirements, you can add an Avalon MM pipeline bridge between the master and the slave. It will do something similar to what you describe here, adding one latency cycle (in both directions) to the transfer.