Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: questions on PCS synchronization

Hi Erik,

You have touched upon some of the holes in those slides (my bad).
Having gone through one revision of a verilog implementation since
then,  let me try to answer your questions.
My replies are interspersed below.


>We've been taking a close look at the state diagrams in:
>on pages 14, 16 & 17 and we've come up with some detailed questions.

>1) In the synchronization state machine, the only way to become
>is to wait for 64 continues frames with valid preambles and ensure that

>a good
>BER is met (ie: <16 preamble errors in 125us).  It has been mentioned
>that the
>32/64 preamble error signal was intended for synchronization purposes,
>and the hi_ber signal was meant to ensure a good BER.  But, the diagram

>shows that both kinds of errors will lead to the out of sync state
>is ok - and a little redundant as only the BER signal would be needed).

>The question is this:  When a hi_ber causes loss of synchronization
>there aren't 32/64 frames with invalid preambles) will the machine try
>and sync up to a new position for the preambles?

The m/c should sync up to a new position iff there are atleast
32 invalid syncs in 64 frames. Thus on hi_ber, the m/c should deassert
sync_done signal, and continue waiting till the hi_ber condition clears
atleast 32 invalid syncs  in 64 frames occurs - upon which condition it
try to reacquire sync.
This operation can be succintly captured in the following state diagram.

-------    ------------>   -------
| LOCK  |  /                                 | HIBER |
-------  < _____________ /   -------
    ^         \             ~hiber                   |
     |           \                                         |
     |              \  ______                        |  unlock
     |                 unlock  \                      |
     |  lock                       \                    |
     |                    unlock   \ -->         V
---------     --------->    --------
| UNLOCK |   /                           |  SLIP       |
---------    <---------     --------
     ^                        slip_done

lock      : signal is set high when there are 64 contiguous frames with
               valid sync patterns "01" or "10"
unlock  : Signal is set high if there are >=32 invalid sync patterns in
               64 contigues frames
hiber     : Set high if >= 16 invalid sync patterns in ~125us.

slip_done: Implementation dependant signal which tells that you can
                  the sync acquisition process.

Also the sync_done variable is true iff the m/c is in LOCK state
  i.e. sync_done = (sync_state == LOCK) ? true : false

>2) In the TX state machine, shouldn't a requirement for leaving the
>I (initialization) phase be that tx_tobe_decoded = Z? (otherwise a
>non-error message would be transmitted when there would be an error)

You are right. This can be handled by eliminating the I state (even in
the RX state m/c) and on power  up or reset you enter the E state. Then
you will enter the Z state iff
initialize_done = true  && TYPE(tx_tobe_coded)=Z. (for TX)
sync_done = true  && TYPE(rx_tobe_decoded)=Z (for RX)

>3) The RX state machine in the Walker 64b/66b slide deck shows that
>rx_err <= rx_EFRAME_G in the T (termination) phase.  Shouldn't this
>rx_err <= rx_decoded so that if an error is found, the next phase
>the error phase) will not send the MAC 2 error codes and no T code
>though the T phase was valid) - but will send the T code followed by an

>error frame?

This is to handle the subtle error condition where we need to feed
the error to kill the previous packet in order to maintain 3-bit
Thus after receving the T frame, you have to receive a clean Z frame for
previous packet to be considered valid.

To illustrate further, consider the scenario where you have the
data frames arrive:

 Imagine there is a two bit error in the middle frame's sync bits  and
the bit pattern
in the data octet X just happens to encode a valid type byte which
indicates a
T frame (end of packet frame).
i.e this is what you receive:
If we go through the rx state m/c from the time it received the middle

Step 1:
rx_tobe_decoded = 10_XDDDDDDD
rx_decoded = DECODE(01_UDDDDDDD)
rx_err = rx_decoded = DECODE(01_UDDDDDDD)


step 2:
rx_to_gmii = DECODE(01_UDDDDDDD)
rx_tobe_decoded = 01_VDDDDDDD
rx_decoded = DECODE(10_XDDDDDDD)
rx_err = EFRAME_G

TYPE(01_VDDDDDDD) = D (therefore an error)

step 3
rx_to_gmii  = rx_err = EFRAME_G (this kills the previous packet)
rx_decoded = EFRAME_G (errors out the current frame)
rx_err = rx_decoded = EFRAME_G

You continue to be in this E state till you get a clean Z frame.

Incidentally, by insisting on a clean Z frame before a S frame, we
again avoid getting fooled by another set of 3-bit errors.
e.g: What is sent is
X is a data octet which has the bit  pattern of the type byte of a
Start of packet frame.
If there is a single bit error in sync bits of the first frame and a two

bit error in the sync of the second frame, there is a potential for
accepting the subsequant frames as a valid packet. This is avoided by
requiring a S frame to always be preceded by a Z-frame.

There is a typo in the slide:
rx_err <= rx_EFRAME_G
should read as
rx_err <= EFRAME_G

>4) Also, in the RX state machine, should loss of sync require that you
>go back to the I (initialization / sync) phase?

With the modification in the state diagram suggested for answer 2, the
loss of
sync should cause the decoder to go to the E state.