Re: Local Fault/Remote Fault
Rich,
Rich Taborek wrote:
>
> Stephen.Finch@ti.com wrote:
> >
> > 1. Any device, in either its transmit or receive paths, could
> > detect a fault condition. The fault may be that the data
> > being received is invalid or that some internal problem
> > is causing the problem. Some/many faults may go
> > undetected. If a device detects a fault condition (i.e.,
> > a locally detected fault) it should set its link status
> > to zero and not forward what is received, but should,
> > at its output, either:
> >
> > a. generate a local fault pulse ordered set if it is
> > capable of doing so,
> > or
> > b. generate all zeros or all ones, making it probable that
> > the next device in the link will detect the problem and
> > (hopefully) generate a local fault pulse ordered set.
>
> I disagree with (b). The response to a detected fault condition should
> be consistent. It's just as easy to generate a local fault pulse
> ordered-set as it is to generate all zeros and ones. Generating multiple
> responses at a transmitter results in multiple interpretations at the
> receiver. (a) should be the only response to a detected fault. The (a)
> response only is implied in the accepted baseline proposal in
> taborek_2_1100.pdf.
I think the point Mr. Finch is trying to make here is that
some devices, e.g. the PMD, PMA & WIS, don't have the capability
to generate an ordered set. I don't agree with the "all zeros or
all ones" part but, if you replace that with "signal detect", I
would say that part b is very valid.
>
> > 2. All devices not detecting fault conditions should forward
> > whatever is received. Local fault pulse ordered sets and
> > remote fault pulse ordered sets may be generated by other
> > devices and, when received, must be forwarded on. With the
> > exception of the RS layer, receiption of a Local fault
> > ordered set or a remote fault ordered set must have no
> > effect on the device receiving these pulse ordered sets.
>
> This is not strictly true. Any fault condition will bring down the
> entire link. The link remains down until the fault condition abates. The
> Link Status protocol should protect against false fault detection
> conditions such as those caused by random bit or signal errors. A fault
> condition recognition process is implemented whereby a detected fault
> conditions are validated. A device which recognizes a fault condition
> essentially operates in "fault" mode rather than "normal data" mode. In
> this sense, the reception of a fault ordered-set DOES have impact on the
> device receiving these pulse ordered sets.
There is nothing currently in clause 49 which restricts data
flow when it receives ordered sets. Other than decoding, it
knows nothing about the ordered set protocol and leaves that
up to the RS. I understand that clause 48 restricts data flow
after detecting the right combination of ordered sets but I
think that is out of necessity for the generation of the proper
IDLE sequence.
> > I think we need some standardized terms used through out.
> > And I think we need a basic description (better written than what
> > I did above) place somewhere in the intro and not in one of
> > the "component" pieces where it could be missed by others.
> >
> > Before I start on what I think should be done, I'd like confirmation
> > that my description above is correct. I'll then start on my proposed
> > fixes.
>
> Go for it!
I agree. A good set of comments is what the task force needs
to solve this problem.
Enjoy,
Ben
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@amcc.com
-----------------------------------------