RE: D1.1 Clause 49 State Machine comments
From: Alex Deng [mailto:adeng@xxxxxxxxx]
Sent: Thursday, November 02, 2000 12:51 PM
Cc: stds-802-3-hssg@xxxxxxxx; Alex Deng; Sharat Prasad
Subject: D1.1 Clause 49 State Machine comments
1. You have changed Variables definition from "good_mt_eq_64, bad_mt_gt_32"
to " good_sh_eq_64, bad_sh_gt_32", then Figure 49-8 on page 184 should
use " good_sh
_eq_64" and "bad_sh_eq_32".
Response: Accept, I thought I fixed those.
2. Variables definition on page 183 should be "bad_sh_eq_32", not
3. Figure 49-9 on page 185 :
a.There are two " bad_mt_eq_32" should not be there.
b. No need for "frame_lock=true" be there
Response: Accept a. The frame_lock=true does need to be there. The 64_good
sets good_sh_eq_64 to true to cause the Lock state machine to move to the
state. If there was a UCT on the transition from 64_good, then it could go
to the SH_MT_INIT state where it would set good_sh_eq_64 back to false while
it again. When Frame_Lock goes true, then good_sh_eq_64 has done its job and
4. Basically I think your state diagram in Figure 49-9 is too confuse and
You can see from Figure 36-9 in 802.3-1998, they check if it's "cgbad"
"cggood" in every
state, but in your diagram in Figure 49-9, you only check sync_head in
that means if you implement this state machine, you need to run atleast
In my opinion, you even don't need a sync head monitor state machine,
if ( reset == true or
sh_cnt == 63 )
sh_cnt <= 0;
sh_cnt <= sh_cnt + 1;
sh_invalid_cnt <= sh_invalid_cnt +
good_sh_eq_64 <= ( sh_cnt == 63) and ( sh_invald_cnt == 0)
( sh_valid == true);
bad_sh_eq_32 <= (sh_invalid_cnt == 31) and (sh_valid ==
Response: The code you suggest is a state machine, it is just written in a
different language. Generally, we try to use one language for describing the
state machines in a chapter. Secondly, the state machines in 802.3 do not
define implementation. They define external behavior. This function can be
implemented in a wide range of ways to produce this external behavior and
the state machine diagram is not intended to say anything about what kind
of clocking is used in an implementation of the funcion. I think it is
looking at this machine how to remove the Test_SH state in an
for purposes of the standard, doing so would crowd more transitions and I
think it would add clarity.
5. Come back to Figure 49-8 on page 184:
I still prefer from 'NO_FRAME_LOCK" to "SLIP" should
a. You also can see from Figure 36-9 in 802.3-1998, before it enter
state, every time when they detect a single code error, it go
to the beginning state
b. In your reply to my last comment, you said "It is cleaner to have
controlled by one machine and the new machines are more closely
but in my proposal, there is only one state machine.
Response: The code you had above is another state machine even if it is
typed rather than drawn. The state machines I've put into 49-8 generally
execute the algorithms that were approved in the proposal for acquiring
lock. You are suggesting different algorithms. I think making a lower
threshold for the transition from NO_FRAME_LOCK to SLIP has merit, but
I feel that it is a substantive enough change from what 802.3ae voted to
adopt that it would need logic track agreement to modify it. I did make
substantive changes to the Transmit and Receive machines modifying the
conditions when /E/ was sent, but that was based on September's logic
track discussion and input.