RE: 10G-BASE-T question
- To: stds-802-3-hssg@xxxxxxxx
- Subject: RE: 10G-BASE-T question
- From: Matt Knudstrup <mknudstrup@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 8 Jun 1999 13:44:44 -0700
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
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.
In my presentation last week I proposed a 32-bit interface running at
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
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 necessarily
mean that we should. I certainly don't want any 1.25GHz clocks anywhere
to my ASIC.