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=
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 by Jim Lewis●October 28, 20202020-10-28
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
Reply by Richard Damon●October 28, 20202020-10-28
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).
Reply by KJ●October 28, 20202020-10-28
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
Reply by Ubaid Abdullah●October 28, 20202020-10-28
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