RE: bit ordering on XSBI vs SFI-4
I think things are getting close. Justin and I just talked. I don't mind
providing the information about XSBI vs. SFI-4 bit ordering, as long as it
is informative text and doesn't confuse the general flow of the document.
My suggestion would be to create Annex 51A which is an informative annex
that briefly explains the mapping of the bit ordering. Annexes are good
spots for things like this because it doesn't interrupt the flow and it's
easy to indicate to the reader that the text is informative not normative.
Cheers,
Brad
-----Original Message-----
From: David Kabal [mailto:dkabal@xxxxxxxxxxxxx]
Sent: Wednesday, March 28, 2001 3:19 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: 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