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.
>Hello,
>We've been taking a close look at the state diagrams in:
><http:grouper.ieee.org/groups/802/3/ae/public/may00/walker_1_0500.pdf>
>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
>synchronized
>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
(this
>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
(but
>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
the
sync_done signal, and continue waiting till the hi_ber condition clears
or
atleast 32 invalid syncs in 64 frames occurs - upon which condition it
should
try to reacquire sync.
This operation can be succintly captured in the following state diagram.
hiber
------- ------------> -------
| LOCK | / | HIBER |
------- < _____________ / -------
^ \ ~hiber |
| \ |
| \ ______ | unlock
| unlock \ |
| lock \ |
| unlock \ --> V
--------- ---------> --------
| UNLOCK | / | SLIP |
--------- <--------- --------
^ slip_done
|
|
Start
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
resume
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
read
>rx_err <= rx_decoded so that if an error is found, the next phase
(being
>the error phase) will not send the MAC 2 error codes and no T code
(even
>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
forward
the error to kill the previous packet in order to maintain 3-bit
protection.
Thus after receving the T frame, you have to receive a clean Z frame for
the
previous packet to be considered valid.
To illustrate further, consider the scenario where you have the
following
data frames arrive:
01_DDDDDDDD 01_XDDDDDDD 01_DDDDDDDD
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:
01_UDDDDDDD 10_XDDDDDDD 01_VDDDDDDD
If we go through the rx state m/c from the time it received the middle
frame:
Step 1:
curr_state=D
rx_tobe_decoded = 10_XDDDDDDD
rx_decoded = DECODE(01_UDDDDDDD)
rx_err = rx_decoded = DECODE(01_UDDDDDDD)
TYPE(10_XDDDDDDD) = T
step 2:
curr_state=T
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
curr_state=E
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
10_SDDDDDDD 01_XDDDDDDD 01_DDDDDDDD
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.
Regards
birdy