D1.1 Clause 49 State Machine comments

[Alex Deng <adeng@xxxxxxxxx>]

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".

2. Variables definition on page 183 should be "bad_sh_eq_32", not
"bad_sh_gt_32"

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

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);

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.

Regards,

--Alex Deng
-----------------------------------------
Alex Deng
Cisco
408-853-8170
adeng@xxxxxxxxx
-----------------------------------------