RE: 10G-BASE-T question
- To: stds-802-3-hssg@xxxxxxxx
- Subject: RE: 10G-BASE-T question
- From: "Booth, Brad" <bbooth@xxxxxxxxxx>
- Date: Tue, 8 Jun 1999 16:18:51 -0500
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
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.
Level One Communications, Austin Design Center
(512) 407-2135 office
(512) 589-4438 cellular
From: Matt Knudstrup [SMTP:mknudstrup@xxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, June 08, 1999 3:45 PM
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
need to have a 64 bit MAC internal data path. I don't think
use both edges internally or use a PLL to generate a 312MHz
therefore I would like to see a 32 bit interface running at
312MHz and would
probably run the MAC at the same speed.
In my presentation last week I proposed a 32-bit interface
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
one) should be less of a challenge.
- Dealing with both edges of the clock (on the interface only)
should not be
- Fits well with either a 32- or a 64-bit internal MAC data path
- Still allows a fairly decent level of integration without
going to exotic
- 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
mean that we should. I certainly don't want any 1.25GHz clocks
to my ASIC.