4-phase vs. 2-phase handshaking

Discussion in 'VHDL' started by Eli Bendersky, Jan 21, 2008.

  1. 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
     
    Eli Bendersky, Jan 21, 2008
    #1
    1. Advertising

  2. On Sun, 20 Jan 2008 22:25:28 -0800 (PST),
    Eli Bendersky <> 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.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, Jan 21, 2008
    #2
    1. Advertising

  3. Eli Bendersky

    Guest

    > 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
     
    , Jan 21, 2008
    #3
  4. On Jan 21, 12:02 pm, 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
     
    Eli Bendersky, Jan 21, 2008
    #4
  5. Eli Bendersky

    Guest

    >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
     
    , Jan 21, 2008
    #5
  6. 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
     
    Mike Treseler, Jan 21, 2008
    #6
  7. 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" <> wrote in message
    news:...
    > 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
     
    Dwayne Dilbeck, Jan 21, 2008
    #7
  8. Eli Bendersky

    KJ Guest

    On Jan 21, 10:39 am, Eli Bendersky <> wrote:
    > On Jan 21, 12:02 pm, 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
     
    KJ, Jan 21, 2008
    #8
  9. On Jan 21, 11:41 pm, KJ <> wrote:
    > On Jan 21, 10:39 am, Eli Bendersky <> wrote:
    >
    > > On Jan 21, 12:02 pm, 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
     
    Eli Bendersky, Jan 22, 2008
    #9
  10. Eli Bendersky

    KJ Guest

    On Jan 22, 1:32 am, Eli Bendersky <> wrote:
    > On Jan 21, 11:41 pm, KJ <> wrote:
    >
    >
    >
    >
    >
    > > On Jan 21, 10:39 am, Eli Bendersky <> wrote:

    >
    > > > On Jan 21, 12:02 pm, 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
     
    KJ, Jan 22, 2008
    #10
  11. On Jan 22, 3:20 pm, KJ <> wrote:
    > On Jan 22, 1:32 am, Eli Bendersky <> wrote:
    >
    >
    >
    >
    >
    > > On Jan 21, 11:41 pm, KJ <> wrote:

    >
    > > > On Jan 21, 10:39 am, Eli Bendersky <> wrote:

    >
    > > > > On Jan 21, 12:02 pm, 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.
    >


    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
     
    Eli Bendersky, Jan 22, 2008
    #11
  12. Eli Bendersky

    KJ Guest

    On Jan 22, 8:42 am, Eli Bendersky <> wrote:
    > On Jan 22, 3:20 pm, KJ <> wrote:

    <snip>
    > 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
     
    KJ, Jan 22, 2008
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. HUANG Huan
    Replies:
    2
    Views:
    718
    Dave Higton
    Feb 24, 2004
  2. fpgawizz

    state machine handshaking

    fpgawizz, Apr 11, 2005, in forum: VHDL
    Replies:
    3
    Views:
    874
    Mike Treseler
    Apr 11, 2005
  3. Dan  Orzechowski

    TLS/SSL handshaking errors

    Dan Orzechowski, Nov 30, 2005, in forum: Java
    Replies:
    0
    Views:
    1,094
    Dan Orzechowski
    Nov 30, 2005
  4. Anon Anon
    Replies:
    5
    Views:
    472
    Brian Drummond
    Apr 18, 2007
  5. Piter_
    Replies:
    0
    Views:
    462
    Piter_
    Jun 18, 2009
Loading...

Share This Page