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