Re: Comment 1121: TX_INIT state assignment of tx_coded
David, the names remote_fault and local_fault are a bit of a misnomer.
What local_fault really means is : this direction of the link is broken
What remote_fault really means is: the other direction of the link is
broken.
I hope with this interpretation, the initial state assignments should
become clear.
regards,
Birdy
------------------------------------------------------------
I'm a bit confused about comment #1121. Since it has been accepted, I
was hoping you could answer a question of mine: I'd like to know why
tx_coded <= L_FRAME_T instead of tx_coded <= R_FRAME_T.
The reason I ask this question is that even though this is a fault local
to the device (call it device A), the message will be forwarded along
the TX path so that it is eventually read by a remote device (call it
device B). Since Device B's RS layer interprets Local Fault messages as
being a fault "local" to device B this would be wrong. The fault
originated in device A. Wouldn't device A's TX path want to send the RF
message in this case to clarify which device is at fault?
I beleive I already asked Pat if the TX_INIT state should default to a
remote fault message instead of IDLE:
"
RE: clause 49 comments and questions
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?
<PAT> RF is sent by the RS in response to receiving an LF. I assume you
are
referring to slide 18 of Rich's slides. In that case, there is no
received
signal so the RS will be receiving LF and will send RF. Note that the TX
machine is only in this state during power on or reset. Once it is up,
it
will be sending on whatever it is receiving from above. <PAT>
"
>From the response I gathered it wasn't that big an issue, but since the
comment has been accepted to change it to L_FRAME_T, I'm curious why
this is preferable to R_FRAME_T?
Thanks,
Dave Gross