Re: PHYs with 10.000 and 9.584640
Hi Jaime,
The idea of having the PHY signal the MAC to extend its IPG was
intended to allow a single rate at the MAC/PLS interface of 10.0000
while allowing a PHY that could attach to existing SONET infrastructure
with a data rate of 9.58464Gbps.
Obviously, the efficiency of such a system would be slightly lower than
that of a system running at a pure 10G, but it would not be much different
than a 10.0000Gbps interface that was getting an occasional
flow-control frame from the other end of the link.
Putting the flow control into the PHY was simply a mechanism that
allows the PHY designer to optimize their FIFO structures based on
their own design requirements.
There are complexities of this proposal that have yet to fleshed out
within the MAC, and I expect there will be some in the PHY as well.
For example, running on a 32 bit wide bus at a reduced clock rate will
mean that the IPG will only last 4 clock cycles. Will the latency of
this interface allow signaling at the de-assertion of TXEN? I don't
think so. Does this render the idea moot? No. We just have to come up
with a straight-forward solution that lends itself to ease of
implementation. I can think of three;
1) PHY asserts HOLD signal anywhere during the first 64 bytes of a frame
and the MAC will continue to send the entire packet, but increment its
IPG by the number of clock cycles HOLD was held true.
+ This allows flexibility in PHY implementations down the road. One
could possibly do a 2.5,5,7.5,10 Gig copper design that rate adapts
by increasing IPG.
- Some people may not consider the above a +.
2) PHY asserts HOLD signal anywhere during the first 64 bytes of a frame
and the MAC will continue to send the entire packet, but increment its
IPG by a fixed number of clock cycles.
+ Less complicated implementation than the above.
- Less flexible.
3) MAC and PHY exchange information prior to link establishment that extends
IPG for every packet.
+ Doesn't require a HOLD signal.
- Probably more complicated for the MAC.
When I initially brought this concept up at the HSSG, I was hoping that it
would allow us to have 10.0000 MACs AND 9.58464 PHYs AND 10.0000 PHYs
because I see value in all of those. I oppose a 9.58464 MAC/PLS interface
and hope we can bring approval of this proposal to a consensus.
Dan Dove
--
___________ _________________________________________________________
_________ _/ ___________ Daniel Dove Principal Engineer __
_______ _/ ________ dan_dove@xxxxxx LAN PHY Technology __
_____ _/ ______ Hewlett-Packard Company __
____ _/_/_/ _/_/_/ _____ Workgroup Networks Division __
____ _/ _/ _/ _/ _____ 8000 Foothills Blvd. MS 5555 __
_____ _/ _/ _/_/_/ ______ Roseville, CA 95747-5555 __
______ _/ ________ Phone: 916 785 4187 __
_______ _/ _________ Fax : 916 785 1815 __
__________ _/ __________________________________________________________
kardontchik.jaime@xxxxxxxxxxx wrote:
>
> Hello Brad and other 10G'ers:
>
> This looks to me like throwing the problem to the subset of PHY
> implementers,
> since the HSSG (read subset of marketing, system and MAC engineers) does
>
> not know how to solve the impasse and get the 75 % approval to either
> 10.000 or 9.584640 Gbps.
>
> Are these PHYs going to be capable of sending/receiving both at
> 10.000 and 9.584640 Gbps ? This would appear to contradict the
> accepted idea in the HSSG that the future standard should be
> either 10 or 9.584640 (exclusive, but not both).
>
> Are we going to define separate PHYs, one for 10.000 and another
> for 9.584640 Gbps ? Then perhaps it would be better to define two
> separate PARs and working groups, since behind these two different
> clock rates are hidden many additional differences (it is not just
> choosing between short-wave or long-wave laser PHYs).
>
> Jaime
>
> Jaime E. Kardontchik
> Micro Linear
> San Jose, CA 95131
> email: kardontchik.jaime@xxxxxxxxxxx
>
> >
> > -----Original Message-----
> >From: Booth, Brad [mailto:bbooth@xxxxxxxxxx]
> >Sent: Wednesday, July 21, 1999 9:22 PM
> >To: HSSG
> >Subject: RE: 9.584640
> >
> >
> >
> >I really liked the proposal that Kevin Daines put on the overhead. One
> of
> >the reasons that I liked the proposal is that it matched what I
> pictured in
> >my mind. :-) But there were other technical reasons why I liked it.
> The
> >proposal for those that missed it was to leave the MAC/PLS data rate at
> 10.0
> >Gb/s, but to have the PHYs determine what data rate was required. In
> the
> >case of a LAN PHY, the data rate would be 10.0 Gb/s... a direct match
> to the
> >MAC/PLS data rate. In the case of a WAN (or OC-192) PHY, the data rate
>
> >would be 9.58464 Gb/s and the PHY would obtain that data rate by either
> some
> >form of flow control or buffering scheme.
> >
> >I like this because it allows the LAN architectures to remain cost
> effective
> >while offering the ability to easily concentrate links (i.e. ten 1 GbE
> links
> >map nicely into one 10 GbE link). This architecture puts a bit of a
> cost
> >burden on the WAN PHY, but I think that this still results in a cost
> >effective solution for OC-192. The WAN solution may not be as low cost
> as
> >the LAN solution, but show me a Gb/s WAN solution today that is as cost
>
> >effective as a Gb/s LAN solution.
> >
> >The other part that I like is that the only real difference between the
> WAN
> >and LAN solutions in Kevin's proposal is the PHY. Everything above the
> PHY
> >(including interface to PHY) remains relatively unchanged. Yes, it's
> all
> >going much faster, but that's an implementation issue, not a standards
> >issue. At least that's my impression. :-)
> >
> >Just my 2 cents worth,
> >Brad
> >
> >Brad Booth
> >Level One Communications, Austin Design Center
> >(512) 407-2135 work
> >(512) 589-4438 cell