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

[Ubaid Abdullah]

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

 

[KJ]

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 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?

Yes, they can be equivalent.

Kevin Jennings

 

[Richard Damon]

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).

 

[Jim Lewis]

In synchronous systems, if we have two block that are communicating and both have registers on their output (common practice in design to control propagation delays), ready/valid can transfer data once per clock and request/ack can transfer data once every other clock.

If we remove the requirement for registers on block outputs, then request/ack may be able to transfer data once per clock - however with request/ack there is a wire based propagation delay from requester to responder and back to requester. Hence, as the clock frequency increases, this timing requirement will be harder to meet.

 

[Kevin Neilson]

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 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

It depends on the context, but I only think of a 4-way handshake protocol being used between asynchronous clock domains. It can guarantee safe data transfer 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 something 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 FIFOs built into the hardware, and all the domain-crossing work has already been 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 handshake, you can have either missed transfers or transfers too close to the sampling edge.