Forums

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

Started by Ubaid Abdullah October 28, 2020
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.

https://stackoverflow.com/questions/64559045/ready-valid-vs-2-way-handshaki=
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.
https://stackoverflow.com/a/5564577/1056976
On Tuesday, October 27, 2020 at 11:52:39 PM UTC-4, Ubaid Abdullah wrote:
> I am confused about whether ready/valid handshaking is functionally equiv=
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?=20
>=20
Yes, they can be equivalent. Kevin Jennings
On 10/27/20 11:52 PM, Ubaid Abdullah wrote:
> I am confused about whether ready/valid handshaking is functionally equivalent to req/ack (2-way) handshaking? By being functionally equivalent, I mean 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 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 equivalent 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 scenarios in which we are bound to use req/ack (4-way) or req/ack (2-way) for that 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. > > https://stackoverflow.com/questions/64559045/ready-valid-vs-2-way-handshaking-vs-4-way-handshaking > > I later realized that the forum has little experts available related to hardware design, so reposting it here on comp.arch.fpga. > https://stackoverflow.com/a/5564577/1056976 >
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).
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.  =20

On Tuesday, October 27, 2020 at 9:52:39 PM UTC-6, Ubaid Abdullah wrote:
> I am confused about whether ready/valid handshaking is functionally equiv=
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?=20
>=20 > As an extension to the same question, is req/ack (2-way) functionally equ=
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.=20
>=20 > In summary, I want to build a connection between the three schemes -- whe=
re will one scheme fail and the other scheme will work.=20
>=20 > The question is in the context of both synchronous and asynchronous desig=
ns=20
>=20 > PS:=20 > I asked the following question on stackoverflow.=20 >=20 > https://stackoverflow.com/questions/64559045/ready-valid-vs-2-way-handsha=
king-vs-4-way-handshaking=20
>=20 > I later realized that the forum has little experts available related to h=
ardware design, so reposting it here on comp.arch.fpga.=20
> https://stackoverflow.com/a/5564577/1056976
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.