RE: bit ordering on XSBI vs SFI-4
Pat,
I fully agree with your reasoning. We should maintain consistency within
the set of 802.3 standards, or there will be more confusion than we are
trying to prevent.
Yonadav
At 03:13 PM 27/3/01 -0700, pat_thaler@xxxxxxxxxxx wrote:
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@xxxxxxxxxxxxx]
Sent: Monday, March 26, 2001 10:54 AM
To: stds-802-3-hssg@xxxxxxxx
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@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On
Behalf Of
pat_thaler@xxxxxxxxxxx
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.
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
Yonadav Perry
Tel: 09-765-2417
Fax: 09-767-8829
yonadav@xxxxxxxxxxxxxxxx