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.
Pat
-----Original Message-----
From: Vipul Bhatt [mailto:vipul.bhatt@xxxxxxxxxxx]
Sent: Saturday, March 24, 2001 9:33 AM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: bit ordering on XSBI vs SFI-4
I support the change proposed by Justin. If cost-effectiveness is a hallmark
of
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
types
of modules in the open market. And they won't have to bear the unnecessary
cost
of potential confusion or the cost of making their PCS capable of
bit-flipping
on command.
Vipul
vbhatt@xxxxxxxxxxx
408-542-4113
=========
> -----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
implementation
> 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
industry,
> before OIF adopted it. XSBI is a interface that is new to Ethernet, so
prior
> Ethernet bit-ordering convention should not be an issue.
>
> I propose that the bit-ordering should match between XSBI and SFI-4, as
this
> interface represents a simple, common transceiver module interface that
can
> 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
now
> 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
of
> 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
D3.0).
>
> 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
> implementation.
>
> Cheers,
> Dave
>
> 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
> Picolight
>
> Phone: 303-530-3189 ext. 272
> Fax: 303-527-4968