Re: Hari
Rich,
As a XGMII, replacing the parallel GMII, Hari would be in place to directly interface
between the MAC and PCS. As an interconnect between the PMA and the PMD, Hari adds
additional code translations, jitter, and inherent delay between any pacing function at
the PMD level PCS and the MAC. That inherent jitter and delay will require fifo buffers,
buffer control, frame queuing, queue control, isolated timing recovery, timing control,
and other functions that are really inherent to a two port MAC bridge, in order to
implement the objective of a WAN PHY. It was my understanding that the proposal in York
was for the MAC bridge between the LAN PHY and the WAN PHY to be at the MAC layer, not
the PMD layer.
As a system implementation function, Hari can be independently implemented by designers
for their LAN PHY implementation. Hari, as a PMA/PMD device interconnect should NOT be
part of the P802.3ae standard. Hari should be part of a different standard as a PHY
specific to PC Boards and backplanes. I believe that Hari has the potential to increase
backplane capacity well beyond the requirements of 10GbE.
As for my concerns about how it was presented, I am referring to it being presented first
as an XGMII between the MAC and the PHY, then shifting to be between the PMA and the
PMD. This tells me that certain vendors have already designed their MAC/PCS/PMA ASICs
with Hari and now have to cover themselves. They are attempting to force this
implementation practice within the P802.3ae standard, limiting other vendors with other
implementation practices. They are doing this of the expense of the agreed on WAN PHY,
which they really don't want anyway.
I understand that this type of attempted standardization has happened before, at the
eventual expense of the vendor that made the attempt. I realize that the SAN Fiber
Channel people would like to see Hari standardized on by the 802.3 to keep up with SCSI,
but this is not part of the Fiber Channel standards organization. I realized that
optical device vendors would like to have a common optical transceiver interface, but
with the WAN PHY, this will not happen, even with Hari. I realize that as a
backplane/bus interconnect PHY, Hari would work well as a high speed replacement for PCI,
but this is not the forum to address that issue. I think that I am well aware of the
real issues with Hari. I also think that P802.3ae is not the place to address those
issues.
Thank you,
Roy Bynum
Rich Taborek wrote:
> Roy,
>
> - Hari has been proposed as a 10 GbE interface in Kauai. What exactly is your concern
> with the process?
> - Hari is not being proposed as a backplane interconnect 10 GbE. However, it is for
> at least InfiniBand.
> - Hari is the same as the Serial 10 GMII proposed by Howard Frazier of Cisco in
> Montreal. I assume that this is what you mean by "XGMII". Why do you say that the
> XGMII did not preclude the existence of other PHY's and Hari does?
> - Hari can easily support a pacing mechanism. Would you like me to architect one for
> you?
> - Which PHY do you believe is being "back doored" before the 802.3ae Task Force is in
> place? Is it the LAN PHY? If this is the case I have to disagree on the grounds that
> Hari is equally applicable as a PMA to PMD interface for 4 quite disparate LAN PMD
> alternatives, 2 of those which may strip off the Hari 8B/10B code and apply a
> significantly different and scrambled line code to a serial stream.
> - The interface for which Hari is proposed may well we the only non-internal chip
> interface in a mature 10 GbE products. As such, this interface is clearly one which
> should be considered for standardization.
>
> Best regards,
> Rich
>
> --
>
> Roy Bynum wrote:
>
> > Rich,
> >
> > I saw a lot of confusion in the presentations of what Hari is intended
> > for. One presentation used Hari as a backplane interconnect. There is
> > confusion on the reflector. There IS a lot of "support" for Hari from
> > vendors that want to stay on the good side of a particular vendor.
> > Otherwise, I suspect that there is a lot of concern about the way that
> > Hari has been brought to the HSSG.
> >
> > When Hari was first introduced at York, I thought that it was a proposal
> > for a an XGMII. While I did not actively support it, as a XGMII it did
> > not preclude the existence of other PHYs. It could be modified to
> > incorporate a pacing mechanism between a PHY and the MAC. The PHY would
> > still implement the PCS/PMA/PMD for what ever standard the Task Force
> > decided on, even the one from Korea.
> >
> > As far as I am concerned, any chip maker/system designer that wants to
> > use Hari can. I just don't want to see it standardized as the PCS to
> > PMD interconnect, even as an optional. The HSSG is not the correct
> > forum to be doing implementation practices or standards. That was one
> > of the things that was impressed on me at the June meeting. There is
> > enough disparity between the PHYs to cause a major rift if a PHY
> > implementation standard is decided on before the PHYs are even defined.
> > Unless a particular vendor is doing their best to back door a PHY
> > standard before the Task Force is even in place, there is no need to
> > decide on implementation practices before the PHYs are fully defined.
> >
> > Thank you,
> > Roy Bynum
> >
> > Rich Taborek wrote:
> >
> > > Roy,
> > >
> > > Multiple proposals aired in Kauai and I have already explained that
> > > Hari is simply a "better" interface for attaching a MAC/PCS/PMA to a
> > > PMD. As Dan Dove of HP has explained, Hari would at most be an
> > > optional interface as was the case with both the TBI (closest Hari
> > > equivalent in GbE) and GbE's GMII. Hari is a serial-based interface,
> > > and as such requires a transmission code. 8B/10B was deemed to be the
> > > best choice for Hari. That's it! I encourage you to propose a better
> > > interface than Hari for its intended purpose or a better transmission
> > > code for Hari. In the absence of either, I saw an awful lot of support
> > > for Hari in Kauai and will continue to do my best to improve upon the
> > > current proposal.
>
> ----------------------------------------------------------
>
> Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
> Tel: 408-330-0488 or 408-370-9233 Cell: 408-832-3957
> Email: rtaborek@xxxxxxxxxx or rtaborek@xxxxxxxxxxxxx