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

RE: bit ordering on XSBI vs SFI-4




As one who hates the proliferation of Annexes, mostly because they do
interrupt the flow, I'd say we don't need to create another annex.  We
already have one that has excruciatingly detailed diagrams of bit order
(44A).  If something more needs to be said, we should say it there.  If
we're concerned about people not finding pertinent information because it's
buried in an annex, then we whould say it in clause 51.  Or we can do both
44A and 51.  But let's not do 51A.

Steve

-----Original Message-----
From: Booth, Bradley [mailto:bradley.booth@xxxxxxxxx]
Sent: Wednesday, March 28, 2001 2:10 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: 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