RE: 10G-BASE-T question

["Booth, Brad" <bbooth@xxxxxxxxxx>]

I agree with Matt.  If you wanted to use the 156 MHz clock to drive the
receive MAC, you'd either have to go 64 bits wide or add a PLL.  The PLL
is very ugly.  The other concern I have with a wide, high speed bus is
SSO (simultaneous switched outputs).  Switching 32 outputs at 156 or 312
MHz increases the power/ground requirements and the possible noise.

I'm curious why we seem to be talking about pumping the raw data across
the mii (media independent interface), instead of performing some form
of data compression scheme, or possibly re-using some of the techniques
used in 1000BASE-T.  Data compression is not my area of expertise, so if
anyone else has ideas to contribute, please do.

Thanks,
Brad

Brad Booth
bbooth@xxxxxxxxxx
Level One Communications, Austin Design Center
(512) 407-2135 office
(512) 589-4438 cellular


	-----Original Message-----
	From:	Matt Knudstrup [SMTP:mknudstrup@xxxxxxxxxxxxxxxxxxx]
	Sent:	Tuesday, June 08, 1999 3:45 PM
	To:	stds-802-3-hssg@xxxxxxxx
	Subject:	RE: 10G-BASE-T question


	I agree with Shimon in all respects except the part about the 32
bit or 64
	bit MAC internal data path.  I think if you have a 156MHz clock
you will
	need to have a 64 bit MAC internal data path.  I don't think
anyone would
	use both edges internally or use a PLL to generate a 312MHz
clock.  So
	therefore I would like to see a 32 bit interface running at
312MHz and would
	probably run the MAC at the same speed.

	Matt Knudstrup
	Extreme Networks

	In my presentation last week I proposed a 32-bit interface
running at
	156.25MHz
	clock and using both edges of the clock for data transfer.

	I believe that this is a reasonable compromise:
	- Only 25% faster than the GMII --- the electrical spec (if we
choose to
	have
	  one) should be less of a challenge.
	- Dealing with both edges of the clock (on the interface only)
should not be
	  rocket science.
	- Fits well with either a 32- or a 64-bit internal MAC data path
	(implementor's
	  choice).
	- Still allows a fairly decent level of integration without
going to exotic
	  clock rates.
	- Does not affect the MAC frame format (same IPG and Preamble).
	  
	Implementations that are pin (rather than die) limited, can
either choose to
	integrate the PCS and the SerDes (and "fill up" the die), or use
the GMII at
	1.25GHz rate (as Bob suggested). I don't think we need a
standard for that.

	The fact that we can run an interface at exotic speeds does not
necessarily
	mean that we should. I certainly don't want any 1.25GHz clocks
anywhere
	close
	to my ASIC.


								Shimon.