RE: bit ordering on XSBI vs SFI-4
Brad:
I think that Justin's post ("A simple solution: bit ordering on XSBI vs
SFI-4") is indicating that there is some degree of consensus emerging:
1) The PMA service interface should maintain Ethernet bit ordering relative
to the serial stream
2) Bit labelling could be different for the physical instantiation of a
service interface than it is for the service interface itself (easier if
names are RADICALLY DIFFERENT, I think).
3) XSBI was intended to be the same as SFI-4
4) Nobody wants to make changes to 3 clauses to make the bit order the same.
With that, I propose the following changes be made to Clause 51 (only):
Create a mapping between the XSBI naming and the PMA service interface. This
would be something like the following (with, of course, a pretty diagram):
tx_data-group<15:0> map to xsbi_tx<0:15>
rx_data-group<15:0> map to xsbi_rx<0:15>
This mapping would be at the beginning of the XSBI section (sorry, don't
have the section number in D3.0)
In diagrams and text referring the the electrical instantiation of the PMA
service interface, only refer to the xsbi_tx/rx names. No mention need be
made in the description of the interface to the bit ordering from parallel
to serial, as the XSBI section is only a description of the parallel
interface.
Thus, the optional instantiation, and the optional instantiation only, will
have bits which have a name that matches the intended bit order. The service
interface will preserve Ethernet bit ordering in this proposed change.
Et voila?
I think this may satisfy most concerns:
1) My concern is that an implementer will screw up their board because of
the bit order, no matter how carefully the difference between two seemingly
identical interfaces is written out (application notes, addendums, etc.).
The SFI-4 and XSBI are a little TOO close for someone NOT to screw up their
board, IMHO.
2) Your concern, if you allow me to paraphrase, is to preserve Ethernet bit
ordering on the service interfaces, out through to the serial interface. I
think you're also worried about making changes all over P802.3ae next draft.
Are we there yet?
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 Booth, Bradley
Sent: Wednesday, March 28, 2001 9:37 AM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: bit ordering on XSBI vs SFI-4
Dave,
What you're proposing is to change the standard to match an implementation.
To me, it is merely how companies implement/document the bit ordering that
is the key focus of this discussion. I personally feel that the standard
should avoid performing any bit order swapping, as the standard could easily
outlive implementations and documentation of the interface. Don't forget
that 2 years from now, 802.3ae will be merged into the collective 802.3
document, and we should maintain consistency with that document.
I know that this could cause some confusion about how to connect a component
with an XSBI to a component with an SFI-4 interface, but I believe that can
easily be alleviate in a note, an annex or in a white paper. My choice
would be for the latter. It's simpler, it's cleaner, and it keeps the
Ethernet standard consistent.
Thanks,
Brad
-----Original Message-----
From: David Kabal [mailto:dkabal@xxxxxxxxxxxxx]
Sent: Wednesday, March 28, 2001 2:01 AM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: bit ordering on XSBI vs SFI-4
Brad:
Actually, I think SFI-4 and XSBI were always intended to be
the same. The
divergence is unfortunate, but only really caused by the bit
ordering
change.
XSBI is new to Ethernet, but has been around the rest of the
industry for a
while. Let's borrow the bit ordering since we borrowed the
interface as
well. I think our early mistake was not to recognize and
enshrine the
origins of this interface by copying it faithfully.
Since changes to clause 49, 50, and 51 seem very to be less
palatable, I
would like to propose an alternate approach which I think
would satisfy the
ultimate desire of every module vendor: not to confuse our
customers....
Since the XSBI is a physical instantiation of a service
interface, can we
not name the bits differently on the physical interface than
they are named
on the logical one? For instance:
logical service interface -> physical instantiation
tx_data-group<15:0> map to xsbi_tx<0:15>
rx_data-group<15:0> map to xsbi_rx<0:15>
Thus, the physical instantiation, and the physical
instantiation only, will
have bits which have a name that matches the intended bit
order. The service
interface will preserve Ethernet bit ordering in this
proposed change. I
think this satisfies the original purpose behind the change
proposed by
Justin and then alternately by me. This would only affect
clause 51, and a
short explanation and diagram would show the mapping between
the two,
differently named sixteen bits.
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 Booth,
Bradley
Sent: Tuesday, March 27, 2001 9:04 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: bit ordering on XSBI vs SFI-4
I've remained quiet on this, but I support Pat's position.
This is an
Ethernet standard, and we should work to maintain Ethernet
consistencies
throughout. This may lead to some confusion with products
specified for
SFI-4, but XSBI is not SFI-4. There is no standard that we
can reference
for SFI-4, so we should maintain Ethernet bit ordering. The
10 Gigabit
Ethernet draft should remain consistent with previous
versions of Ethernet,
and companies building SFI-4 and XSBI compliant parts will
need to figure
out how to address this in their product literature. Or in
other words,
it's an implementation issue.
Cheers,
Brad
-----Original Message-----
From: pat_thaler@xxxxxxxxxxx
[mailto:pat_thaler@xxxxxxxxxxx]
Sent: Tuesday, March 27, 2001 4:01 PM
To: Jscquake@xxxxxxx;
Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: RE: bit ordering on XSBI vs SFI-4
Justin,
The XSBI should not be labeled in terms of MSB and LSB. bit
significance has
no meaning at that interface.
Originally Ethernet was defined to send most significant
byte, least
significant bit first. That is still the way the length
field is sent. On
the other fields, we now leave defining byte order
significance up to the
protocols obove Ethernet. If you look at the payload of a
64B/66B data
block, the MSB is may the 8th data bit and the LSB may the
57th data bit.
There is no meaning to bit significance when one looks at
quantities larger
than a byte because it depends on the byte significance.
When looking at the XSBI, bit significance becomes even more
irrelevant
because byte boundaries may fall anywhere in the 16 bits.
The terms LSB and
MSB have no relevance to the XSBI.
It seems that there are two ways of handling this and both
result in
inconsistancy that will confuse some readers. 802.3 has
always numbered bits
in primitives so that bit 0 was the first bit to be
transmitted and the
highest numbered bit was the last bit transmitted. If we
make
tx_data-group<0:15> and rx_data-group<0:15> work the
opposite way, we will
be likely to confuse readers who are accostumed to the
convention used in
the rest of the standard.
If SFI-4 numbers bits in the opposite order, then we have
two choices.
Number tx_data-group and rx_data-group opposite of the way
the other
primitives such as TXD and RXD.
or
Leave the tx_data-group and rx_data-group numbering as it is
and add a note
that explains that tx_data-group<0> is the same as SFI's bit
15 and
tx_data-group<15> is the same as SFI's bit 0. Does SFI
actually call their
signals tx_data-group and rx_data-group? The explanation
will be clearer if
the names are not exactly the same.
It is less confusing to be consistant in bit numbering
within the standard
and explain the difference between bit numbering of this
standard vs other
related standards than to change our bit numbering order
somewhere in the
PCS.
Regards,
Pat
-----Original Message-----
From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
Sent: Monday, March 26, 2001 1:28 PM
To: Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: Re: bit ordering on XSBI vs SFI-4
In a message dated 3/26/01 12:28:50 PM Pacific Standard
Time,
Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx writes:
Subj: RE: bit ordering on XSBI vs SFI-4
Date: 3/26/01 12:28:50 PM Pacific Standard Time
From: Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx (Jonathan
Thatcher)
Sender: owner-stds-802-3-hssg@xxxxxxxx
To: stds-802-3-hssg@xxxxxxxx
Before offering any opinion on this, I would like to know
what impact there
would be on measurement and test equipment, if any.
Clearly, a piece of equipment expecting a serial PRBS
pattern would need the
bits in a specific order. No?
jonathan
Hello All,
Let me state again that any changes (if any) would only be
in relabeling and
is purely a logical construct. There was/is neven intention
to actually have
Ethernet packets sending bit stream data out on a serial
link in a MSB first
manner. If Pat (clause 49) or anyone else does see this as
becoming the case
then I would back off from this effort and just leave things
as is. This
leaves the
user (customers of modules makers) to be careful in knowing
which bit is
actually
sent out first on the link. Leaving things as is OR
relabeling the XSBI to
MSB should
never stop implementers. The serial PMA is a "dumb" device
...
Just a try here to make a simple suggestion ...
If I relabeled the XSBI to have MSB transmitted first then
Pat coming out
from her clause could possible reword saying that the LSB
should be mapped
to
the MSB of the XSBI in the case of a serial link.
Justin Chang
Quake Technologies, Inc.
2880 Zanker Road, Suite 104
San Jose, CA 95134
Tel: 408-922-6888 x108
Fax: 408-922-6827
email: justin@xxxxxxxxxxxxx
internet: www.quaketech.com