RE: D1.1 Clause 49 State Machine comments
-----Original Message-----
From: Alex Deng [mailto:adeng@xxxxxxxxx]
Sent: Thursday, November 02, 2000 12:51 PM
To: pat_thaler@xxxxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx; Alex Deng; Sharat Prasad
Subject: D1.1 Clause 49 State Machine comments
Hi Pat,
1. You have changed Variables definition from "good_mt_eq_64, bad_mt_gt_32"
in D1.0
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
"bad_sh_gt_32"
Response: Accept.
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
state
sets good_sh_eq_64 to true to cause the Lock state machine to move to the
Frame_Lock
state. If there was a UCT on the transition from 64_good, then it could go
immediately
to the SH_MT_INIT state where it would set good_sh_eq_64 back to false while
it tested
it again. When Frame_Lock goes true, then good_sh_eq_64 has done its job and
the transition
can occur.
4. Basically I think your state diagram in Figure 49-9 is too confuse and
not
accurate.
You can see from Figure 36-9 in 802.3-1998, they check if it's "cgbad"
or
"cggood" in every
state, but in your diagram in Figure 49-9, you only check sync_head in
"TEST_SH" state,
that means if you implement this state machine, you need to run atleast
2x
frame clock.
In my opinion, you even don't need a sync head monitor state machine,
it's
quite simple:
if ( reset == true or
Lock_State_Machine==SLIP or
sh_cnt == 63 )
begin
sh_cnt <= 0;
sh_invalid_cnt <=0;
end
else
begin
sh_cnt <= sh_cnt + 1;
sh_invalid_cnt <= sh_invalid_cnt +
(sh_valid
== false);
end
then
good_sh_eq_64 <= ( sh_cnt == 63) and ( sh_invald_cnt == 0)
and
( sh_valid == true);
bad_sh_eq_32 <= (sh_invalid_cnt == 31) and (sh_valid ==
false);
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
obvious
looking at this machine how to remove the Test_SH state in an
implementation, but
for purposes of the standard, doing so would crowd more transitions and I
don't
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
use"sh_valid=false",
not
"bad_sh_eq_32=true".
a. You also can see from Figure 36-9 in 802.3-1998, before it enter
"SYNC_ACQUIRED"
state, every time when they detect a single code error, it go
back
to the beginning state
"LOSS_OF_SYNC".
b. In your reply to my last comment, you said "It is cleaner to have
the
counter
controlled by one machine and the new machines are more closely
interlinked."
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.
Regards,
--Alex Deng
-----------------------------------------
Alex Deng
Cisco
408-853-8170
adeng@xxxxxxxxx
-----------------------------------------