Reality is as Reality does. Hari is very preferential to an 8B10B PHY. With this as the device
interconnect, any other encoding method would be VERY un-economical. This eliminates the
consideration of any other encoding, even before the Task Force has started. Don't you think that
this is either a little early, or does someone have a hidden agenda?
Joel Goergen wrote:
> I am not necessarily excited about HARI either, but you are a touch away from reality on a few
> of your points.
> Roy Bynum wrote:
> > Rich,
> > I'm not sure what gave you the idea that Hari was favorable to serial PHYs. I do know that
> > it is not favorable to anything other than the legacy fiber channel 8B10B LAN PHY. Hari is
> > NOT a PHY neutral device interconnect. Some LAN vendors have very huge boards and they want
> > something that will support their 8B10B encoding over the distance of their board, and also
> > the back plane if needed. By introducing Hari as the standard for device interconnect
> > between the PMA and the PMD, they are specifically, and possibly knowingly, hampering the
> > development of the agreed on WAN PHY. There is no mechanism for rate controlling over
> > Hari. This is in violation of the agreed objective in this regard. Hari is an attempt by a
> > specific camp to control the development of 10GbE and limit development of anything other
> > than the 10.0 only rate PHY.
> Your focus is the operation of the phy, the features that go along with that, and your customer
> base. As always, most in your shoes forget about 'signal integrity'. The HARI interconnect
> allows the board designer to partition the board logic in an efficient manor to the ASICs and
> FPGAs with minimal considerations to the geometry of the circuit board. If I interconnect my
> system at 10gig from point to point to allow the logic designer to use the 'perfect phy', I will
> tripple the system cost .... and the marketing guys will tell you what that means to the end
> cost - not my area.
> I don't really like the interface, either, but you know what .... for the design of most systems
> currently in or soon to be under development, the interconnect scheme seems to really fit well
> and solve a lot of issues. Is it perfect? No, but I'll be damned if I have been able to come
> up with something better given all the variables of the problem.
> > As you will remember, I called the presenters and floor on the issue of what Hari really
> > was. It was admitted that it was a LAN extension interconnect by the individual that
> > responded. For those of us that are attempting to bring 802.3 into the 20th century by
> > making a truly ubiquitous MAC, we have been astounded by the brazen push of this
> > "interconnect". Chip makers will confirm that Hari specifically makes the WAN PHY
> > extremely difficult to implement. Since Hari truly is not common to all of the PHYs as
> > specified in the objectives, I suggest that it be withdrawn from consideration as part of
> > the 10GbE standard.
> I have not heard anyone say this, and I have been involved with several of them. I have heard
> individuals admit that they do not care for this interface, but each of them has also said they
> can not think of anything better.
> I would offer that we look at the pros and cons of what this interconnect can provide in our
> designs, and then stand back and decide where to improve it. And if you still don't like it,
> well, I would ask you think about the signal integrity aspect of it for a while and not a
> network manager ...... How would you like two or four card chassis that are inefficient in your
> rack spaces? What if the board size had to drop to 5in by 5in - the network processor won't be
> what you would like to use .... The bottom line is this - 12.5gig is very easy to implement in
> the lab with a controlled setup. Production is very different. The board sizes, the parts
> used, the power sub-system, the connectors - all combine to impose some very impossible hurdles
> to jump. A 'HARI' scheme allows someone in SI to pick apart the problem into manageable
> Joel Goergen