RE: bit ordering on XSBI vs SFI-4
Pat:
I think the LSB versus MSB order on the output/input is not as important as
the bit numbers. I don't think the solution is actually proposing to change
what gets sent out on the serial bitstream. Rather, I proposed to change the
labelling of those bits on the XSBI interface to simplify customer
implementations that use this physical instantiation of the Clause 51 PMA.
This does not change the CRC generation at all, as far as I can see, as this
relabelling occurs on the output or input to Clause 49 (move the relabelling
operation in clause 50 to clause 49).
Cheers,
Dave
------
David Kabal
Picolight
Phone: 303-530-3189 ext. 272
Fax: 303-527-4968
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of
pat_thaler@xxxxxxxxxxx
Sent: Monday, March 26, 2001 9:47 AM
To: Jscquake@xxxxxxx; stds-802-3-hssg@xxxxxxxx
Cc: pat_thaler@xxxxxxxxxxx; tom_alexander@xxxxxxxxxxxxxx
Subject: RE: bit ordering on XSBI vs SFI-4
Justin,
There is a reason why it is important to preserve the Ethernet bit order as
LSB first. The Ethernet CRC provides absolute protection against error
bursts of 32 bits or less. That is, if 32 contiguous bits (as seen by the
CRC generator) are errored, the CRC will not match the packet contents. For
longer bursts, there is one chance in 2^32 that the error will be
undetected. If you reverse the order of bits in sets of 16 bits, then you
reduce the burst protection. Imagine the case where the first bit hit by the
burst is the last transmitted bit of a set of 16. Call that bit 1 and number
bits that went through the CRC generator consecutively from there. If the
burst hits a bit beyond bit 32, then in may produce an undetectable error.
What we would be transmitting if we reverse the bit order is:
16, 15, 14, ..., 2, 1, 32, 31, .... 18, 17, 33
Reversing the bit order reduces burst protection from 32 bits to 17 bits.
We should not make the change you suggest. Clause 51 shouldn't care whether
the MAC considers a bit as the MSB or the LSB. It should just send the bits
it gets in the primitive tx-data-group<15:0> with tx-data-group<0> sent
first.
Regards,
Pat
-----Original Message-----
From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
Sent: Friday, March 23, 2001 3:49 PM
To: stds-802-3-hssg@xxxxxxxx
Cc: pat_thaler@xxxxxxxxxxx; tom_alexander@xxxxxxxxxxxxxx
Subject: bit ordering on XSBI vs SFI-4
Hello All,
As the clause editor for clause 51, I have received feedback that the
present
bit ordering for the XSBI interface, i.e. LSB sent first, will cause
confusion to people that have used the SFI-4/SONET modules.
Background on this topic ... an OC192 serial stream has the MSB bit first
while Ethernet networks have the LSB bit sent first. Early 802.3ae
discussions, we decided to leave the LSB bit order as is so that the PCS
(clause 49) to XSBI will have no inversions. This leaves the WIS (clause
50)
to do the inversion. This is
the present status of draft 802.3ae rev 3.0.
The concern is that system people will be confused by the fact that XSBI
modules and SFI-4 modules have "reversed" ordering AND if they are not
careful the PCB layout will be reversed.
To reduce this risk, a change that CAN be made to make the XSBI bit ordering
consistent w/ SFI-4 and also send the MSB bit out first. This would result
in
three changes
1) clause 51 - reverse the order to MSB bit out first
2) clause 50 - remove section on reversing the bits from the PCS
3) clause 49 - "modify/add" section to send out the data with MSB bit first
My request to the reflector is to give some guidance here on the direction
for
a change or none change.
Comments please. Thanks in advance.
Justin Chang
Quake Technologies, Inc.
2880 Zanker Road, Suite 104
San Jose, CA 95134
Tel: 408-922-6888 x108
Fax: 408-922-6827
email: justin@xxxxxxxxxxxxx
internet: www.quaketech.com