4-phase vs. 2-phase handshaking

[Eli Bendersky]

Hello,

I'm sure the details of these protocols are familiar to most of you,
but I will repeat them here shortly for the completeness of my
question:

4-phase handshaking for transferring enables/data between asynchronous
domains:

Sender and Receiver are the participants. Sender has a "req", Receiver
a "ack". The "quiet state" is req = 0, ack = 0.

1) Sender wants to transfer data / enable to receiver. Raises req
2) Receiver detects rise in req, raises ack
3) Sender detects rise in ack, lowers req
4) Receiver detects low req, lowers ack
5)... Back to the initial state.

Now, with "req" enables and/or data can be transferred from the sender
to the receiver or back. This is a robust protocol, but it has a high
overhead.

So 2-phase is a simplification. The key: two quiet states: req/ack =
0/0 or 1/1

1) Sender wants to transfer data / enable to receiver. Raises req
2) Receiver detects rise in req, raises ack
3) Sender detects rise of ack - transaction ended.

Next time:

1) Sender wants to transfer data / enable to receiver. Lowers req
2) Receiver detects fall in req, lowers ack
3) Sender detects fall of ack - transaction ended.

The 2-phase protocol has less overhead than the 4-phase, but it also
has some deficiencies. And we finally reach my question. What are
those deficiencies ? I know of one: when we want transfer data
bidirectionally between the sender and the receiver using this
protocol, we need two separate data lanes, as opposed to 4-phase where
a single data lane is enough. This is because in "pull" operations
where the sender reads data from the receiver, the receiver doesn't
know it has to release the data lane before the next transaction
starts.

Are you aware of any other disadvantages of the 2-phase protocol as
opposed to the 4-phase ?

Thanks in advance
Eli

 

[Jonathan Bromley]

Are you aware of any other disadvantages of the 2-phase protocol as
opposed to the 4-phase ?

I'm not sure whether this really counts as a disadvantage,
but... 2-phase or "xor" handshake does not require the
handshake flip-flops to be initialized (not in hardware,
anyway). Consequently, you can build a valid hardware
design that lacks a reset. Such a design will be tricky
to simulate because of the unknown values in the flops
at startup.

In practice, I always use a reset anyhow.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[MikeShepherd564]

4-phase...2-phase...

The "two-phase" protocol is enough to provide flow control where there
is a common clock. The signal from the data source could be named
"DataReady" and that from the data acceptor could be named
"ReadyForData". Data is considered (by either side) to be transferred
when both signals are set in the same clock.

That is, if both signals are set, then on the next clock the data
source should clear its control signal (unless it presents further
data immediately) and the data acceptor should clear its control
signal (unless it can accept further data immediately).

The "four-phase" protocol is used where there is no common clock e.g.
in communication with a distant peripheral device.

How does this concern VHDL?

Mike

 

[Eli Bendersky]

The "two-phase" protocol is enough to provide flow control where there
is a common clock.  The signal from the data source could be named
"DataReady" and that from the data acceptor could be named
"ReadyForData".  Data is considered (by either side) to be transferred
when both signals are set in the same clock.

That is, if both signals are set, then on the next clock the data
source should clear its control signal (unless it presents further
data immediately) and the data acceptor should clear its control
signal (unless it can accept further data immediately).

The "four-phase" protocol is used where there is no common clock e.g.
in communication with a distant peripheral device.

In fact, I was referring to the case in which there is no common
clock. 2-phase will work there as well, similarly, since ack and req
can be synchronized by double FFs in the relevant domains. Is 2-phase
somehow more difficult to synchronize than 4-phase ?

How does this concern VHDL?

In truth, I thought hard about where this question belongs. There is
no newsgroup on logic design, as far as I know, so c.l.vhdl is the
closest I could think of. I'll happily accept suggestions on
alternatives, though. And I hope this question is not completely
irrelevant here...

Eli

 

[MikeShepherd564]

In fact, I was referring to the case in which there is no common

clock. 2-phase will work there as well, similarly, since ack and req
can be synchronized by double FFs in the relevant domains. Is 2-phase
somehow more difficult to synchronize than 4-phase ?

Sorry...I didn't read your original question properly.

You say "...2-phase is a simplification...". It's not clear that the
implementation is any simpler. The "two-phase" system still has four
phases, but you transfer two data words over the four phases.

It does appear that, for the same maximum transition rate, the data
throughput is doubled. Perhaps this is equivalent to DDR ?

Mike

 

[Mike Treseler]

The 2-phase protocol has less overhead than the 4-phase, but it also
has some deficiencies. And we finally reach my question. What are
those deficiencies ?

Let's see, does 'active' mean high or low right now. Hmmm.

Note that for a common clock,
the sender can just set a one cycle ready bit with the data
and expect the receiver to see it without a handshake.


-- Mike Treseler

 

[Dwayne Dilbeck]

I agree with mike the biggest potential issue with the two state process is
if the slave and master get out of sync. How do you get them back and when
to do it.

 

[KJ]

On Jan 21, 12:02 pm, (e-mail address removed) wrote:

In fact, I was referring to the case in which there is no common
clock. 2-phase will work there as well, similarly, since ack and req
can be synchronized by double FFs in the relevant domains.

If there is no common clock then in order to implement the 2-phase
version, you must do one of the following...

1. Both sender and receiver must bring req and ack in as the clock to
a flip flop so that edges do not get missed due to clock sample time
differences between sender and receiver.
2. Both sender and receiver must be designed to de-assert req and ack
long enough to guarantee that the other see the de-assertion.

#1 can be clumsy in FPGA land. Timing verification gets trickier as
well usually.
#2 is a brittle version of the 4 phase since it replaces the second
part of the handshake with some hard coded time delay for no good
reason.

Failure to implement #1 or #2 with a two phase protocol will result in
occasional missed transactions due to one side or the other missing a
rapid de-assertion/assertion of the other's signal...that's why what
you call 4-phase exists as a fairly robust protocol.

In either situation though you also have to concern yourself with
recovery from a timeout situation (i.e. req set and ack never comes
back).

Is 2-phase
somehow more difficult to synchronize than 4-phase ?

No...if you mean synchronizing to some clock.
Yes...if you mean synchronizing the handshake with 2 phases and a hard
coded delay instead of the simple 4 phase version.

Kevin Jennings

 

[Eli Bendersky]

If there is no common clock then in order to implement the 2-phase
version, you must do one of the following...

1. Both sender and receiver must bring req and ack in as the clock to
a flip flop so that edges do not get missed due to clock sample time
differences between sender and receiver.
2. Both sender and receiver must be designed to de-assert req and ack
long enough to guarantee that the other see the de-assertion.

#1 can be clumsy in FPGA land.  Timing verification gets trickier as
well usually.
#2 is a brittle version of the 4 phase since it replaces the second
part of the handshake with some hard coded time delay for no good
reason.

Failure to implement #1 or #2 with a two phase protocol will result in
occasional missed transactions due to one side or the other missing a
rapid de-assertion/assertion of the other's signal...that's why what
you call 4-phase exists as a fairly robust protocol.

Sorry, but I fail to follow on #2. Suppose both req and ack are
synchronized with a double FF at the relevant side.
Now, what is wrong with simply detecting a change (rise or fall) on
req by the receiver and ack by the sender. Why is a timeout needed ?

Eli

 

[KJ]

Sorry, but I fail to follow on #2. Suppose both req and ack are
synchronized with a double FF at the relevant side.

#2 is about having some 'agreed upon' minimum de-assertion time that
is baked into sender and receiver's designs. What happens if sender
has a 100 MHz clock and can generate a 10ns de-assertion before
setting req again to start up another transaction but receiver has a
75 MHz clock (13 ns period). You can synchronize it all you want in
the receiver but you've got a decent chance that the receiver will
simply miss the start of the next transaction because the de-assert
occurred fully within one clock cycle.

Now, what is wrong with simply detecting a change (rise or fall) on
req by the receiver and ack by the sender.

Nothing, it comes down to how are you going to detect those edges?
Three ways that I know of are:
- The agreed upon minimum de-assertion time (#2)
- Clocking a gray code counter with 'req' and 'ack' to determine when
a new edge has occurred (#1).
- 4 phase protocol where sender must wait until it sees ack deasserted
before starting again.

Why is a timeout needed ?

It might not, depending on your system. But what if sender asserts
'req' and receiver is on some other board that is supposed to be
connected by a cable but the cable isn't there...there will be no
'ack'. Obviously the interface will lock up, but you wouldn't
necessarily want the entire system to lock up also. If the interface
is completely within a single chip, lockup doesn't occur (unless there
is yet another downstream interface that is also being depended on).

The implications of lockup due to a handshake signal not being there
simply have to be considered. If it means that the interface should
timeout and then report this back to the rest of the system than it
must add some timeout, if it's OK to lockup indefinitely then no
timeout is needed. Since your question was more of a general nature
about interfaces, then specific about a particular design I thought it
prudent to mention about considering what to do when the handshake can
not complete due to some fault in the system.

Kevin Jennings

 

[Eli Bendersky]

#2 is about having some 'agreed upon' minimum de-assertion time that
is baked into sender and receiver's designs.  What happens if sender
has a 100 MHz clock and can generate a 10ns de-assertion before
setting req again to start up another transaction but receiver has a
75 MHz clock (13 ns period).  You can synchronize it all you want in
the receiver but you've got a decent chance that the receiver will
simply miss the start of the next transaction because the de-assert
occurred fully within one clock cycle.

Maybe you're referring to the version of 2-phase where req/ack = 0/0
is the only idle state. I was not. The protocol I described has 1/1 as
an idle state too. Here's the description again:

1) Sender wants to transfer data / enable to receiver. Raises req
2) Receiver detects rise in req, raises ack
3) Sender detects rise of ack - transaction ended.

Note that at stage (2), the receiver is already ready for a new
transaction (before the sender...) so I can't see how a fast new
transaction from the sender can go amiss. Can you ?

1/1 is also an idle state, which means that if the sender wants to
initiate a new transaction and sees that the state is 1/1 it will
lower 'req' instead of rising it, and the receiver, equipped with
similar knowledge, will know to look for the fall of 'req' and in its
turn lower 'ack'.

Eli

 

[KJ]

On Jan 22, 3:20 pm, KJ <[email protected]> wrote:

Maybe you're referring to the version of 2-phase where req/ack = 0/0
is the only idle state. I was not. The protocol I described has 1/1 as
an idle state too. Here's the description again:

1) Sender wants to transfer data / enable to receiver. Raises req
2) Receiver detects rise in req, raises ack
3) Sender detects rise of ack - transaction ended.

Note that at stage (2), the receiver is already ready for a new
transaction (before the sender...) so I can't see how a fast new
transaction from the sender can go amiss. Can you ?

1/1 is also an idle state, which means that if the sender wants to
initiate a new transaction and sees that the state is 1/1 it will
lower 'req' instead of rising it, and the receiver, equipped with
similar knowledge, will know to look for the fall of 'req' and in its
turn lower 'ack'.

You're correct about my misinterpretation of the protocol, the last
paragraph in your last post clicked in my head better than the
original post for whatever reason. In that case, from a logic
perspective it should work just as well as the 4 phase.

The disadvantage then is going to be that req and ack are now going to
have to be nice, controlled edge signals just like a clock and they
are still (most likely) going to need to interface with a system clock
on each end anyway which will require synchronizers as you're already
aware. So there is a cost of having two more controlled impedance
properly terminated signals for each and every interface that uses
this protocol. I'm thinking though that simply synchronizing the
interfaces to one or the other clock could most likely be a higher
performance solution at lower cost (i.e. one additional clock load per
device, will support any number of logical interfaces).

Kevin Jennings