clause 49 comments and questions
Hi Pat,
I've just been reading the new draft, and I have a few questions
concerning clause 49. I was hoping you could clarify some of them:
1) In figure 49-11, the condition for going to the 32_BAD state has been
updated to include "+ frame_lock = false". This seems to imply that if a
slip occurs (causing frame_lock to go false) and the new sync_header is
tested for validity before achieving frame lock (must get 64
contiguous), if only 1 error occurs in the sync_header during this time
bad_sh_eq_thresh will be true again (frame_lock is still false) and
another slip will occur. This seems much more restrictive, and I was
wondering why it is now chosen to be implemented this way.
2) In figure 49-13, the TX state machine's initial condition is to
output IFRAME_T. However, in the November slide deck from Rich Taborek
et al. concerning Link Status, upon initialization the TX outputs RF.
Now, eventually LF will be translated into RF and sent out of the TX
path, but I'm wondering why it should be the default condition of the TX
state machine?
Additionally, it seems possible that if device 1 outputs I_FRAME on
start_up, then device 2 might not receive a signal (at first), generate
an RF, receive the I_FRAME from device 1's start_up, and then begin
sending out normally. Meanwhile, device 1 will detect a LF, send a RF to
device 2 (when device 2 recieves this it will stop transmitting data and
will also send RF) and will eventually detect Device 2's idle followed
by it's data (it will then stop sending RF and start sending data). The
problem is that Device 2 will have sent RF once Device 1 sends it, and
vice versa, and so on and so on. I'm hoping that by initially having the
TX state machine send out RF we can avoid this possibilty...
3) Also in figure 49-13, I noticed the TX state machine is now longer
worried about 3-bit hamming protection as it was in D1.1. Why is this no
longer a concern?
Thanks.
Dave Gross