Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: bit ordering on XSBI vs SFI-4




David,

What I think you and Justing are suggesting is that we call the bit we are
now calling bit 0 on the XSBI to bit 15 and vice-versa. This would mean that
the 10GBASE-R PMA service interface would number bits using a convention
opposite that used for every other service interface in 802.3. I think that
will cause as much confusion as having XSBI and SFI use different bit
numbering conventions. 

There is no cost impact to differing labeling between SFI-4 and XSBI and I
don't understand why you are suggesting there is. There need not be any
difference between a physical instantiation of an XSBI and an SFI-4
interface. It would just be that a particular pin would have two names. For
instance, the pin that is tx_data-group<0> would also be
SFI's_transmit_pin_name bit 15 and that would be the first transmitted bit.

It is not that hard and we aren't complicating anything. We are stuck with a
world where since the beginning of logic and computers, some people have
chosen to number bits starting with 0 and others have chosen to number
ending with 0. We have a case where those worlds are coming together and
there has to be a transition explained somewhere. We can either keep our
standard internally consistant and explain to people how to translate to the
other world or we can put a transition in an arbitrary location within our
standard. 

Given a confusing world that can't agree on conventions, it is less
confusing to keep our standard internally consistant and put the transitions
at its boundary.

Regards,
Pat

-----Original Message-----
From: David Kabal [mailto:dkabal@picolight.com]
Sent: Monday, March 26, 2001 10:54 AM
To: stds-802-3-hssg@ieee.org
Subject: RE: bit ordering on XSBI vs SFI-4



Pat:

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.

Cheers,
Dave

------
David Kabal
Picolight

Phone:	303-530-3189 ext. 272
Fax:	303-527-4968


-----Original Message-----
From: owner-stds-802-3-hssg@ieee.org
[mailto:owner-stds-802-3-hssg@ieee.org]On Behalf Of
pat_thaler@agilent.com
Sent: Monday, March 26, 2001 9:54 AM
To: vipul.bhatt@finisar.com; stds-802-3-hssg@ieee.org
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.

Pat

-----Original Message-----
From: Vipul Bhatt [mailto:vipul.bhatt@finisar.com]
Sent: Saturday, March 24, 2001 9:33 AM
To: stds-802-3-hssg@ieee.org
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@finisar.com
408-542-4113

=========

> -----Original Message-----
> From: owner-stds-802-3-hssg@ieee.org
> [mailto:owner-stds-802-3-hssg@ieee.org]On Behalf Of David Kabal
> Sent: Saturday, March 24, 2001 12:21 AM
> To: stds-802-3-hssg@ieee.org
> 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