Re: Question about Link Fault Signalling
Yariv,
I believe that your interpretation is correct and based on state machine
operation in D2.0. However, I also believe that this operation is too
complex and and undesirable. The original intention, outlined in
taborek_2_1100.pdf is for the RF condition going away to be handled
without requiring a minimum number of Idles preceding packet. Even
though the underlying PHY sublayers may require timers and counters to
handle Fault conditions, I'd prefer that the MAC be kept simple and
insulated from the complexities of the PHY.
I certainly hope someone caught this with a comment!
Happy Holidays,
Rich
--
Yariv Anafi wrote:
>
> Hi all,
> There is something missing in your description. At the last stage
> (7) MAC1 was transmitting RF
> and move to transmit IDLE or packets. At the same time MAC2 is in a
> state of detecting RF and will soon see
> what MAC1 is sending. We must guarantee that MAC1 will transmit enough
> cycles of IDLE before it start to send packets
> otherwise MAC2 will not clear the RF state since it do not detect
> enough IDLE bytes. Remember that some IDLE column are
> lost due to lane alignment.
>
> We need to add that when clearing a fault condition by detecting 8
> bytes of IDLE, one must send at least 12 bytes of IDLE
> before clearing the link fail status, and enable the transmit of
> packets
>
> Stephen.Finch@xxxxxx wrote:
>
> > David,
> >
> > let me take a swing at this ball....
> >
> > Power up
> > 1. Both sides send idles until idles are received, packets
> > can be sent only if Idles and/or packets are being received.
> >
> > |--(Idle)--> PHY |
> > MAC1 | | MAC2
> > | PHY <--(Idle)--|
> >
> > 2. Since we're starting up, the links aren't locked yet, so
> > somewhere in the phy on the receive path in both directions
> > someone is generating LF. This probably happens in both
> > directions, so both sides are generating LFs somewhere in the
> > PHY layer.
> >
> > |--(Idle)--> PHY ----(LF)-->|
> > MAC1 | | MAC2
> > |<--(LF)---- PHY <--(Idle)--|
> >
> > 3. Both MAC/RS's see LF and start send RF (instead of just
> > Idle's). We
> > stay here until a link comes up.
> >
> > |----(RF)--> PHY ----(LF)-->|
> > MAC1 | | MAC2
> > |<--(LF)---- PHY <--(RF)----|
> >
> > 4. One or the other of the links obtain sync and starts working
> > (you
> > can work out what happens if both come up simultaneously). We'll
> > assume
> > its on the top path. When a link comes up, it stops generating LF
> > and
> > passes through what is being sent, i.e., the RF that is being sent
> > by
> > the MAC (with RS) in its direction.
> >
> > |----(RF)--> PHY ----(RF)-->|
> > MAC1 | | MAC2
> > |<--(LF)---- PHY <--(RF)----|
> >
> > 5. A MAC2 receives the RFs. This causes MAC2 to stop sending RF
> > and
> > start sendin Idles. (No packets yet)
> >
> > |----(RF)--> PHY ----(RF)-->|
> > MAC1 | | MAC2
> > |<--(LF)---- PHY <--(Idle)--|
> >
> > 6. When the other link comes up, the PHY element that was
> > generating
> > LFs stops generating LF and passes through what is being sent, i.e.,
> >
> > Idles.
> >
> > |--(RF)----> PHY ----(RF)-->|
> > MAC1 | | MAC2
> > |<--(Idle)-- PHY <--(Idle)--|
> >
> > 7. When MAC1 receives Idles (not LF and not RF), it can send packets
> > or
> > Idles.
> >
> > |-(Idle/P)-> PHY -(Idle/P)->|
> > MAC1 | | MAC2
> > |<--(Idle)-- PHY <--(Idle)--|
> >
> > 8. When MAC2 receives Idles or packets, it too can start sending
> > packets
> > or continue to send idles.
> >
> > AND WE'RE UP.
> >
> > Hope this makes it clear.
> >
> > Steve Finch
> >
> > "David Gross" <dgross@xxxxxxxxxxxxxxxxxx> on 01/03/2001 02:35:27 PM
> >
> > To: "Grow, Bob" <bob.grow@xxxxxxxxx>
> > cc: rtaborek@xxxxxxxxxxxxx, HSSG <stds-802-3-hssg@xxxxxxxx>
> > Subject: Re: Question about Link Fault Signalling
> >
> > Thanks for the response Bob,
> >
> > I'd just like to make one clarification which I think might be
> > necessary. I'd like to see "In the case of a Local Fault
> > condition..."
> > rather than "Upon detection of a Local Fault condition..." (and
> > likewise
> > for Remote Fault). The reason for this is that since upon start-up,
> > one
> > can assume that both devices will be in LF and transmitting RF. This
> >
> > implies that once a device can start recieving data (i.e.: no longer
> >
> > have a LF) it will be recieving RF. As a result, as the definition
> > seems
> > to imply, the Fault conditions won't be cleared (The IDLE control
> > words
> > won't be detected for 2 clock edges), but instead Remote Fault will
> > be
> > detected. Since RF and LF cannot be detected at the same time (LF
> > prevents the transmission of recieved RF), it is logical that LF
> > will be
> > cleared while RF will be achieved. There should be something in
> > there
> > which allows for the clearing of LF in such a case, and jumping from
> > the
> > LF condition immediately to the RF condition. Let me know what you
> > think.
> >
> > -Dave Gross
> >
> > Grow, Bob wrote:
> > >
> > > Shimon submitted a comment proposing changing the entry to link
> > down
> > (eitner
> > > RF or LF) from 3 to 4 status messages, with exit on 8 consecutive
> > idle
> > > bytes. While I am open to discussion on the numbers, I think his
> > proposed
> > > text with improved description of the protocol is a great starting
> >
> > point for
> > > discussion. Since this has come up again, here is a slightly
> > edited
> > version
> > > of his proposed text.
> > >
> > > "46.2.6 Link fault signaling
> > >
> > > "Two link fault conditions are specified for 10Gb/s operation:
> > Local
> > Fault
> > > and Remote Fault. The Local Fault condition at the Reconciliation
> > Sublayer
> > > indicates that a link failure has been detected on the receive
> > path by
> > a
> > > local DTE sublayer. The source of the failure could be at the
> > remote
> > > transmitter, the interconnect between the two DTEs, at one of the
> > local
> > > DTE's devices or the interconnect between the local DTE's devices.
> > The
> > > Remote Fault condition is generated by the Reconciliation
> > Sublayer,
> > and when
> > > received by at a Reconciliation sublayer indicates that a link
> > failure
> > has
> > > been detected by the remote DTE. The source of the failure could
> > be
> > at the
> > > local transmitter, the interconnect between the two DTEs, at one
> > of
> > the
> > > remote DTE's devices or the interconnect between the remote DTE's
> > devices.
> > >
> > > " Fault conditions are conveyed over the XGMII using status
> > messages.
> > All
> > > status messages are four bytes in length, and are sent on a single
> >
> > XGMII
> > > clock edge. A status message is indicated by a Pulse control
> > character
> > > aligned to lane 0, with the status condition encoded in the three
> > data
> > bytes
> > > of lanes 1, 2 and 3. The status encodings are shown in Table
> > 46-4."
> > >
> > > <Table 46-4>
> > > <For the sake of completeness, also show Lane 0 encoding>
> >
> > >
> > > "A PHY indicates Local Fault conditions to the Reconciliation
> > sublayer
> > by
> > > alternating the corresponding status message with Idle control
> > characters on
> > > RXC<3:0> and RXD<31:0>. The Reconciliation sublayer sends the
> > Remote
> > Fault
> > > indication to the remote DTE by alternating the Remote Fault
> > message
> > with
> > > Idle control characters on TXC<3:0> and TXD<31:0>.
> > >
> > > "The PHY repeats a Remote Fault indication received from the
> > remote
> > DTE
> > > unless a Local Fault condition is detected resulting in the PHY
> > over
> > writing
> > > the received data with the Local Fault indication.
> > >
> > > "The Reconciliation sublayer continuously monitors RXC<3:0> and
> > RXD<31:0>
> > > for status messages. The reception of four status messages of the
> > same
> > type
> > > shall indicate that the corresponding fault condition has
> > occurred.
> > The
> > > reception of four Idle control characters on successive RX_CLK
> > edges
> > (eight
> > > consecutive Idle control characters) shall clear all fault
> > conditions.
> > >
> > > " Upon detection of a Local Fault condition, the Reconciliation
> > sublayer
> > > shall:
> > > 1) Set the link_fail status indication.
> > > 2) Inhibit the transmission of MAC frames.
> > > 3) Continuously send alternating Remote Fault messages and Idle
> > control
> > > characters.
> > >
> > > "Upon detection of a Remote Fault condition, the Reconciliation
> > sublayer
> > > shall:
> > > 1) Set the link_fail status indication.
> > > 2) Inhibit the transmission of MAC frames.
> > > 3) Continuously send Idle characters.
> > >
> > > "After detecting that the Fault condition has cleared (both Local
> > and
> > > Remote), the Reconciliation sublayer shall:
> > > 1) Clear the link_fail status indication.
> > > 2) Enable the transmission of MAC frames."
> > >
> > > --Bob Grow
> > >
> > > -----Original Message-----
> > > From: David Gross [mailto:dgross@xxxxxxxxxxxxxxxxxx]
> > > Sent: Wednesday, January 03, 2001 8:48 AM
> > > To: rtaborek@xxxxxxxxxxxxx
> > > Cc: HSSG
> > > Subject: Re: Question about Link Fault Signalling
> > >
> > > Hi Rich,
> > >
> > > I have a quick question about Remote Fault I was hoping you could
> > > answer. In 46.2.6, it says:"Reception of multiple local fault
> > messages
> > > causes the Reconcilliation Sublayer to inhibit the transmission of
> >
> > > frames by MAC, and to encode remote fault status messages on
> > TXC<3:0>
> > > and TXD<31:0>" It goes on to specify that reception of three LF
> > messages
> > > sets link_fail to 1, and none n 6 clock periods clears link_fail.
> > >
> > > My question is this: I believe we said that upon recieving RF, the
> > RS
> > > will output an IDLE stream until it no longer recieves RF. If this
> > is
> > > so, how many RF messages set this condition to be true, and in how
> >
> > many
> > > clocks do we say that this condition is cleared if no RFs are
> > detected.
> > > Is it similar to LF, or do we only require that one RF be detected
> >
> > (and
> > > then for how long before we reset this IDLE output condition of
> > the RS
> > > Tx?)
> > >
> > > Thanks in advance.
> > >
> > > -Dave Gross
>
> --
> thanks,
> Yariv Anafi
> Galileo Technology Ltd.
> Moshav Manof, D.N. Misgav 20184
> Email - mailto:yariv@xxxxxxxxxxxxx
> Tel Haifa - + 972 4 8225046 ext. 414
> Tel Manof - + 972 4 9999555
> FAX - + 972 4 8326420
> WEB SITE - http://www.GalileoT.com
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com