ready/valid vs 2-way handshaking vs 4-way handshaking

I am confused about whether ready/valid handshaking is functionally equival
ent to req/ack (2-way) handshaking? By being functionally equivalent, I mea
n that we can perform data transfers with ready/valid handshaking in all th
e cases in which we can do with req/ack (2-way) handshaking and vice versa?
Are there any scenarios in which one scheme will work while the other will
not?
As an extension to the same question, is req/ack (2-way) functionally equiv
alent to req/ack (4-way) handshaking? Mostly, I have found the difference t
o be in terms of hardware required and of course speed. Are there any scena
rios in which we are bound to use req/ack (4-way) or req/ack (2-way) for th
at matter.
In summary, I want to build a connection between the three schemes -- where
will one scheme fail and the other scheme will work.
The question is in the context of both synchronous and asynchronous designs
PS:
I asked the following question on stackoverflow.
formatting link

ng-vs-4-way-handshaking
I later realized that the forum has little experts available related to har
dware design, so reposting it here on comp.arch.fpga.
formatting link

Reply to
Ubaid Abdullah
Loading thread data ...
alent to req/ack (2-way) handshaking? By being functionally equivalent, I m ean that we can perform data transfers with ready/valid handshaking in all the cases in which we can do with req/ack (2-way) handshaking and vice vers a? Are there any scenarios in which one scheme will work while the other wi ll not?
Yes, they can be equivalent.
Kevin Jennings
Reply to
KJ
First, the terms are not fully standardized, so I will explain my interpretation of the terms. First the difference between 'Ready' and 'Request', this is somewhat ambiguous, but most often in my experience is 'Ready' is a signal from the receiver saying it is ready to accept data, and 'Request' is a signal from the transmitter saying it has data that it wants, but sometimes it is reversed, and the receiver asserts a 'Request' or the Transmitter asserts 'Ready'. Acknowledgement is always the other side signalling that it also is ready and the transfer can occur.
Perhaps better terms (though wordier) are transmitter initiated and receiver initiated transactions.
While both transmitter initiated and receiver initiated will transfer data, there are some conditions where what data gets transmitted might change. The case where we get a difference is if the transmitter incurs a 'cost' or has a desire to send the 'latest' value, then a receiver initiated protocol may be better. Otherwise the transmitter needs to incur the data acquisition cost without knowing if the receiver wants this data, and may need to hold it until the receiver does want it, and it possibly getting stale. Here the receiver initiated protocol gets fresher data, and the system only incurs the acquisition cost when it needs it.
On the other hand, a receiver initiated system may have lower through put, especially if cascaded as you describe, as a request needs to propagate from the ultimate destination to the ultimate source and then back, and only then can the next request be issued, while with a source initiated system, if the source is fast enough, can keep the pipe fairly full.
As to 2 way vs 4 way, my understanding of this is a 2-way (or 2-phase) system works by sending a chunk of data by both sides signalling their readyness to transfer, and as long as they stay in that state, you keep transmitting data on a data clock. This is almost by definition a synchronous protocol. A 4-way (4-phase) transaction requires for each data chunk to pass, each side needs to go ready, and then not ready. This allows data to be sent without the need for a clock, as the protocol is self-timing, but it also is slower as each data chunk requires a handshake (but it could be a synchronous system where one hand shake means one block of data is sent, and some system might allow a handshake for the next block while the previous block is still in transit, allowing full data pipe usage).
Reply to
Richard Damon
In synchronous systems, if we have two block that are communicating and bot h have registers on their output (common practice in design to control prop agation delays), ready/valid can transfer data once per clock and request/a ck can transfer data once every other clock.
If we remove the requirement for registers on block outputs, then request/a ck may be able to transfer data once per clock - however with request/ack t here is a wire based propagation delay from requester to responder and back to requester. Hence, as the clock frequency increases, this timing requi rement will be harder to meet.
Reply to
Jim Lewis
alent to req/ack (2-way) handshaking? By being functionally equivalent, I m ean that we can perform data transfers with ready/valid handshaking in all the cases in which we can do with req/ack (2-way) handshaking and vice vers a? Are there any scenarios in which one scheme will work while the other wi ll not?
ivalent to req/ack (4-way) handshaking? Mostly, I have found the difference to be in terms of hardware required and of course speed. Are there any sce narios in which we are bound to use req/ack (4-way) or req/ack (2-way) for that matter.
re will one scheme fail and the other scheme will work.
ns
ardware design, so reposting it here on comp.arch.fpga.
It depends on the context, but I only think of a 4-way handshake protocol b eing used between asynchronous clock domains. It can guarantee safe data t ransfer between domains, even when you don't know which clock is the faster . You wouldn't need it for synchronous transfers. It's a general-purpose design, but normally you know the speeds of the clocks, so you can use some thing more efficient. Often it's just easiest to use an asynchronous FIFO to get data across domains, and that is also the highest-throughput method. If you are using, say, a Xilinx part, there are plenty of asynchronous FI FOs built into the hardware, and all the domain-crossing work has already b een done and verified.
If you are looking for a scheme that fails, I think if you are transferring data from a fast domain to a slow one and only using a simple 2-way handsh ake, you can have either missed transfers or transfers too close to the sam pling edge.
Reply to
Kevin Neilson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.