| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Vipul, David, Justin, I do not support this change. I agree with Tom Alexanders point (not included) that a note in clause 51 is better than changes to clauses 51, 50, and 49. If XSBI/SFI-4 haromization is desired, propose the change to SFI-4 in the OIF.
Give Caesar what is Caesar's: Ethernet networks have the LSB bit sent first. OC192 serial stream has the MSB bit first. Let each of their PCS's handle it accordingly.
Shawn
s-rogers@xxxxxx
-----Original Message-----
From: Vipul Bhatt [mailto:vipul.bhatt@xxxxxxxxxxx]
Sent: Saturday, March 24, 2001 11: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