Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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