Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > 4-phase vs. 2-phase handshaking

Reply
Thread Tools

4-phase vs. 2-phase handshaking

 
 
Eli Bendersky
Guest
Posts: n/a
 
      01-21-2008
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
 
Reply With Quote
 
 
 
 
Jonathan Bromley
Guest
Posts: n/a
 
      01-21-2008
On Sun, 20 Jan 2008 22:25:28 -0800 (PST),
Eli Bendersky <(E-Mail Removed)> wrote:

>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
http://www.velocityreviews.com/forums/(E-Mail 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.
 
Reply With Quote
 
 
 
 
MikeShepherd564@btinternet.com
Guest
Posts: n/a
 
      01-21-2008
> 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
 
Reply With Quote
 
Eli Bendersky
Guest
Posts: n/a
 
      01-21-2008
On Jan 21, 12:02*pm, (E-Mail Removed) wrote:
> > 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.
>


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





 
Reply With Quote
 
MikeShepherd564@btinternet.com
Guest
Posts: n/a
 
      01-21-2008
>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
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      01-21-2008
Eli Bendersky wrote:

> 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
 
Reply With Quote
 
Dwayne Dilbeck
Guest
Posts: n/a
 
      01-21-2008
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.

"Mike Treseler" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Eli Bendersky wrote:
>
>> 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



 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      01-21-2008
On Jan 21, 10:39*am, Eli Bendersky <(E-Mail Removed)> wrote:
> On Jan 21, 12:02*pm, (E-Mail Removed) wrote:

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


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
 
Reply With Quote
 
Eli Bendersky
Guest
Posts: n/a
 
      01-22-2008
On Jan 21, 11:41*pm, KJ <(E-Mail Removed)> wrote:
> On Jan 21, 10:39*am, Eli Bendersky <(E-Mail Removed)> wrote:
>
> > On Jan 21, 12:02*pm, (E-Mail Removed) wrote:

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

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


 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      01-22-2008
On Jan 22, 1:32*am, Eli Bendersky <(E-Mail Removed)> wrote:
> On Jan 21, 11:41*pm, KJ <(E-Mail Removed)> wrote:
>
>
>
>
>
> > On Jan 21, 10:39*am, Eli Bendersky <(E-Mail Removed)> wrote:

>
> > > On Jan 21, 12:02*pm, (E-Mail Removed) wrote:

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

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


#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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How can I avoid multiple execution when handshaking operations? Anon Anon VHDL 5 04-18-2007 11:40 AM
TLS/SSL handshaking errors Dan Orzechowski Java 0 11-30-2005 03:22 PM
state machine handshaking fpgawizz VHDL 3 04-11-2005 05:43 PM
Will this "asynchronous handshaking" feasible in real circuits? HUANG Huan VHDL 2 02-24-2004 09:07 PM
USB 56K modem dont like handshaking in XP SP1 Goon-Heaven Computer Support 7 11-08-2003 06:32 AM



Advertisments