1394B Bport task group report, Feb. 9/10 1998, Santa Cruz
---------------------------------------------------------
Chair: Alistair Coles

We met twice during the 1394b meeting:

Monday 9th Feb. 98:

1) PHY detectable packet errors.

We discussed at length the action that a 1394b port should take when detecting
that an error has occured in a received packet, and that packet is to be
forwarded to a 1394a/DS port. 1394a Data/Strobe provides no mechanism for a
port to indicate that a packet is known to be errored, and 1394a relies on the
error to be detected by the CRC32 checksum. The 8B10B coding used on 1394b
ports can cause some error patterns that are detectable on DS links to become
undetectable by CRC32, but still detectable by the 1394b port, due to the
disparity check built in to 8B10B coding.

Specifically, we discussed the scenario where a packet received on a bport
appears correct, until the DATA_END symbol is received and reveals a disparity
error.

The group has not agreed upon a technique for forcing this error to be
observed by a peer node connected via a 1394a/DS port.

Eric Deliot has provided a calculation showing that the probability of this
specific error pattern occuring that would be undetectable by CRC32 is approx.
10^-24 for BER=10^-10.

It was observed that this probability might be smaller still, since some
single bit errors would cause an immediately observable code violation. Also,
Eric's calculation covered the worst case packet length at S3200. Only shorter
S400 packets would be forwarded on a DS port.

Motion: "Move that a 1394b PHY does not forward detected error information to
DS ports, nor to a 1394a Link"

Moved by Jerry Hauck
Second: Colin Whitby-Strevens

Noted that this motion does not prohibit a 1394b PHY reporting these errors to
other 1394b ports or 1394b Links.

Yes:12 No: 0 Abstain: 6


We also discussed the related issue of what action should be taken when an
errored codeword is received during the packet (and detected during the
packet). Should we forward data or overwrite the remainder of the packet with
Data Prefix?

If forwarding data, should it be a specified default value or unspecified?

Comments that should not overwrite packet as the errored info may still be
useful to some applications.

[Note: outside of meeting it was pointed out that this won't happen anyway as
a Link must discard any errored packets].

Concensus that we should specify the default data value. No concenus on what
the specification should be. Could be 00, FF, AA or 55 perhaps.

[Note: outside of meeting it was suggested that a high transition density
might be most likely to cause a CRC error i.e. AA or 55 would be better
choice.]

Tuesday 10th Feb. 98:

2) We discussed action that should be taken if an invalid control codeword is
received. Proposal is that the last known control state is maintained, at
least initially. This led to a discussion of when and how the port determines
that the error rate is such that retraining would be desirable.

One problem identified is the undesirability of long timers in the PHY. Should
PHY report errors in a register and Link examine register periodically?

Fibrechannel has a scheme that works as follows:

For every error (invalid codeword) increment error counter by 1.

For every valid codeword decrement error by 1 (I think).

If error counter reaches X, retrain link.

3) Test modes/loopback

Continued discussion from previous meeting of provision for test modes.

We may need to specify a mode in which the PHY disables its scrambling
function, so that a known worst case sequence can be sent from a higher level
application and result in a known pattern on the wire.

We may want to specify a mode in which a PHY returns a packet on the revere
channel (i.e. return same packet on port it was received). This would allow a
remote (intelligent) test device (e.g. PC) to prompt a PHY to transmit a worst
case sequence, without that PHY needing to generate that sequence locally.

4) Provision of other arbitration states

Suspend resume will require an control state for:

TX_SUSPEND
TX_DISABLE_NOTIFY

Dave LaFollettes new BOSS oriented arbitration scheme will require an
ARB_RESET signal, separate REQUEST and GRANT, and a number of REQUEST
differentiators (e.g. for priorities).

Proposals are solicited for providing these signals in our control space.

5) review of draft

Alistair highlighted changes to latest version of draft - see slides on web
site.

6) Polarity inversion

Support for UTP has raised the issue of automatic correction of crossed wires
in a pair, by polarity detection and inversion.

Proposals are solicited for dealing with this.

7) Next meeting will be during 1394b meeting in Tempe.


--
******************************************************
Alistair Coles           Hewlett-Packard Laboratories
                         Filton Rd,Bristol,BS12 6QZ,UK
                         Direct Dial: +44 117 922 8750
anc@hplb.hpl.hp.com      Fax:         +44 117 922 9286
******************************************************