RE: bit ordering on XSBI vs SFI-4
I think there is a cost impact to allowing XSBI and SFI-4 interfaces to
diverge in their bit order, as it is clear that customer boards may be
designed to support both SFI-4 and XSBI interfaces. Why complicate this
implementation of what is intended to be the same physcial interface by
reversing the bit labels?
From a transceiver module vendor point of view, it is clear that some
customers may get this interface wrong if a module vendor would be able to
produce a part that could support both "standards" for the sixteen bit
interface. It is difficult to support this change for historical (Ethernet)
reasons, when it is so easy to harmonize at this stage. This is the first
and only instance of this interface for Ethernet, so let's make it that
small bit easier for implementers.
Again, the change should not be a "fundamental" bit ordering change, but
rather a labelling change on the bits that allows both Ethernet and OIF
interfaces (not to mention SONET) to share the same bit order.
Fundamentally, this is a no-op that prevents customer confusion.
Let's make bit 15 go out first, ONLY ON THE XSBI INTERFACE.
Phone: 303-530-3189 ext. 272
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of
Sent: Monday, March 26, 2001 9:54 AM
To: vipul.bhatt@xxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
Subject: RE: bit ordering on XSBI vs SFI-4
There should not be any cost impact to the bit order chosen. Once a module
layout is chosen by the fiber optic community, then it is easy to produce
devices that put the bits out in an order that allows straight through wires
to the modules. What we call the bits doesn't matter to the modules. People
just need to know which of the 16 inputs to the module is transmitted first.
From: Vipul Bhatt [mailto:vipul.bhatt@xxxxxxxxxxx]
Sent: Saturday, March 24, 2001 9:33 AM
Subject: RE: bit ordering on XSBI vs SFI-4
I support the change proposed by Justin. If cost-effectiveness is a hallmark
Ethernet standards, then we have an obligation to stay focused on it. By
harmonizing the SFI-4 and XSBI bit ordering, we are reducing the customer's
cost. With this change, they will gain the freedom to choose between both
of modules in the open market. And they won't have to bear the unnecessary
of potential confusion or the cost of making their PCS capable of
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of David Kabal
> Sent: Saturday, March 24, 2001 12:21 AM
> To: stds-802-3-hssg@xxxxxxxx
> Cc: Stuart Robinson (E-mail)
> Subject: RE: bit ordering on XSBI vs SFI-4
> I agree with Justin's solution and analysis.
> Some further arguments:
> It is clear that SFI-4 and XSBI were intended to be harmonized from the
> inception, but SFI-4 could not be referenced because it is an
> agreement, not a standard, so it was copied, and then diverged in the
> bit-ordering. Even SFI-4 was the result of common practice in the
> before OIF adopted it. XSBI is a interface that is new to Ethernet, so
> Ethernet bit-ordering convention should not be an issue.
> I propose that the bit-ordering should match between XSBI and SFI-4, as
> interface represents a simple, common transceiver module interface that
> be used to support multiple standards. I think this was the original
> intention of specifying this optional physical instantiation. Bit
> relabelling to cause reordering on XSBI represents only a renaming of the
> bits, and this operation is not without precedent, as this is done right
> in the WIS (clause 50).
> Lastly, I think it is useful to point out the utility of getting this
> harmonized, when all we're really talking about is the names of the bits:
> Any implementer using a 16 bit LVDS interface with forward clocking for a
> transceiver module will be presented with the same bit order, regardless
> whether such a module is a XSBI or SFI-4 interface.
> I recommend the following changes, very similar to those suggested by
> Justin, but perhaps slightly simplified (and will submit comments for
> 1) Move the "relabelling" operation from Clause 50 to Clause 49 (this
> relabels this bits "on their way out" and "on their way in" respectively)
> 2) Change the bit order in Clause 51
> This seems to me to still be a EDITORIAL change as relabelling (renaming)
> bits should not a technical change at the interface. The alternative is to
> explain to implementers why the bit labels are different between SFI-4 and
> XSBI, when they were intended to be the same, and guide them laboriously
> through Ethernet and SONET bit-order conventions towards a successful
> PS: This suggested change will remove any possible Bit Ordering Anxiety
> (BOA) and possibly reduce the design review time. I, myself have been the
> victim of BOA, which is a terrible affliction, so I would not wish this on
> any implementer. BOA must be stopped.
> David Kabal
> Phone: 303-530-3189 ext. 272
> Fax: 303-527-4968