RE: Clause 49 comments
-----Original Message-----
From: Alex Deng [mailto:adeng@xxxxxxxxx]
Sent: Monday, October 09, 2000 12:15 PM
To: stds-802-3-hssg@xxxxxxxx
Cc: Sharat Prasad; Alex Deng
Subject: Clause 49 comments
1. Figure 49-4--" PCS Receive Bit Ordering".
I think the direction arrows should be :
from Serial transmission order --> rx_data_unit<15>,
from rx_data_unit<0> ----> the left side of "Gearbox",
from the right side of "Gearbox" ----> RxB<65> (the right
side of "Receive block"),
from bit0 of S0 ----> Descrambler ----> bit7 of D7(the
right side of Ouput of descramblerfunction).
Response: Arrows have been corrected.
2. Figure 49-8--"Lock state machine" .
a. I think come out of the state "SLIP", you should reset the
64frames_timer and 125us_timer. Because in the
"SLIP" state and the states before "SLIP", mt_inalid_cnt and
hi_ber_cnt should not be carried over.
b. The condition for the "NO_FRAME_LOCK" --> "SLIP", I think it's
better to use !mt_valid, rather than
"bad_mt_gt_32=true", we can acquire Frame_Lock much faster.
Response: First item no longer applies because the state machines have
been redone. Also, prefer to not have one state machine resetting a counter
while another may be incrementing it. It is cleaner to have the counter
controlled
by one machine and the new machines are more closely interlinked.
The second point has merit but as suggested, it would break the interlink
between the
machines. If we wish to do this, my preferred method would be to add a
variable
sh_invalid_thresh (sync header invalid threshold)that is set to 32 when in
FRAME_LOCK
and set to a lower number, perhaps 1, while in NO_FRAME_LOCK. bad_sh_eq_32
should in
that case be renamed to something like excess_bad_sh.
Making this change should speed the acquisition of lock by spending less
time on
bad lock candidates.
3. Figure 49-9--"BER Monitor State Machine"
a. This diagram is not clear.
I think "M1" should not be an independent state. Assume using
frame clock toimplement, that means every
clock you need to see if "mt_valid" is true or false, then M1
and M2, or M1 and M3 must happend in a
single clock. Further, mt_valid = true or false,
64frames_time_done and 125us_timer_done, these 3 events
could happend at the same clock, that means M2, M3, M4 and M5
can not be independent state.
b. I think there is no need for mt_valid_cnt. Because you already
have mt_invalid_cnt and 64frames_timer,
when 64frames_timer_done, mt_invalid_cnt==0 means good_mt_eq_64
= true.
c. My suggestion:
if ((mt_invalid_cnt == 32) && (!mt_valid)), then set
bad_mt_gt_32 = true, reset 64frames_timer, reset
mt_invalid_cnt.
if ((hi_ber== 15) &&(!mt_valid)), then set hi_ber=true, reset
125us_timer, reset hi_ber_cnt.
Response: It had already been noted that BER Monitor State Machine
had transitions that could occur simultaneously. The BER monitor function
and Sync Header monitor funtions have been split into two state machines
and the new state machines should not have the problem noted in a. I
agree that one does not need mt_invalid_cnt and it has been rmoved.
The first part of your suggestion c is pretty much how the new state
machines work.
I thought about restarting a new hi_ber period
when the hi_ber_cnt exceeds 16, but did not do it for two reasons.
The 125 us counter is a fairly slow counter and it will be easiest for
implementations to implement it if they can make redundant use of it.
Therefore, it should be allowed to be a continuous clock tick at a
125 us rate and requiring it to reset and restart would prevent this.
Also, it may be more useful as a link quality monitor if it is measured
over a regular period and hi_ber isn't used for anything else.