Re: 10 Gbit PHY, HARI
Roy,
I agree with you 100%. Hari, with its 4-wide signals between the MAC/PHY and transceiver
enables the highest level of 10 GbE product integration, port count per PCB and lowest
cost per port.
Roy Bynum wrote:
> Rich,
>
> I recognize the technical merit of Hari, particularly from the backplane side of the
> PCB. As a former system designer, I have seen that the tighter the density, (in this
> case, the closer the transceiver and the PHY (PCS/PMA/PMD) is) then the lower the
> tolerance requirements, and the higher port count per PCB, and thus the lower the
> manufacturing cost per port. Many of the newer technology, lower cost vendors, that
> bring their equipment to me for evaluation, are using that concept. It may seem novel
> to some, but it is a technique that was used years ago before the PCB manufacturing
> and device technology improved so that it was not needed for the current given signal
> frequencies.
>
> Thank you,
> Roy Bynum
>
> Rich Taborek wrote:
>
> > Patrick Gilliland wrote:
> >
> > > Joel,
> > >
> > > Thanks for sharing your thought on this issue.
> > > I think I am beginning to understand what this
> > > is all about. Your concern is about handling of
> > > the 10G signal on a circuit board. Why not back
> > > the interface chip right up against the PHY? If
> > > it is an optical transceiver, a 10G signal will be
> > > fine through a short length of microstrip or stripline.
> >
> > Pat,
> >
> > I assume that when you said PHY above, you meant PMD/Transceiver Module. It seems
> > that you're taking a very transceiver centric view of a 10 GbE system
> > implementation and assuming that the "interface" chip can be located anywhere
> > including near the transceiver.
> >
> > This will typically not be the case for 10 GbE LAN equipment, as well as routers
> > and such supporting the MAN/WAN infrastructure. These devices are typically used
> > to aggregate or direct traffic. As such, these devices support a high number of
> > ports, and if slower speed ports are supported on the same equipment, will
> > generally support even more slower speed ports. The "heart" of these devices is
> > typically a switch or router core, memory, networks processors, MACs, etc. Many of
> > these components will be discrete for early 10 Gbps, systems, but the discrete
> > components must still be in very close proximity to each other due to interface
> > requirements. As time goes on, higher levels of integration will occur, and
> > eventually, even the PHY gets integrated into the "heart". This heart gets hot and
> > may need to be cooled, much like the CPU in your PC.
> >
> > Similarly, early 10 Gbps transceivers may be large daughter card sized units
> > containing multiple large and high power chips including O/E. Once again, many of
> > these would be used in 10 GbE equipment along with a slew of 1 Gbps downlinks. My
> > point is: Which of the interface chips are you going to back up to transceiver?
> > Furthermore, what are you going to do with the other ones?
> >
> > What technology requirements are you imposing on the "interface" chip? If this
> > chip signals @ 10-12.5 Gbps on a single serial signal, then it CAN'T be CMOS.
> >
> > What about the integrity of the 10-12.5 Gbps signal when it finally gets to the
> > PMD? Do you believe that you'll simply be able to repower it for transmission over
> > the media. I'll wager (Guinness?) that you'll have clean it up significantly once
> > inside the PMD before you can forward it. You'll need to derive a clean clock from
> > the data or supply a RefCLK to the PMD in order to retime. BTW, is the RefCLK the
> > same frequency as the local system oscillator? If not, you'll have to do
> > insert/delete at 10-12.5 Gbps in the PMD. These are all issues that have been
> > considered for Hari. The cost of the Hari CMOS die to do this is about the price
> > of a Guinness in a restaurant. Of course, it may cost a bit more than this upon
> > introduction :-)
> >
> > Hari, with 4 serial signals @ 3.125 Gbps, solve all the above system problems and
> > enables the development of flexible and cost effective 10 GbE equipment.
> >
> > I acknowledge that there is a huge market for single port MAC/PHY/PMDs. In the
> > year 2008, your kids will likely be dragging you down to Fry's for a 10 GbE NIC
> > card so they can play some interactive Pokemon (or whatever the money sink that
> > year is) game with their friends across town :-)
> >
> > One huge market is the WAN access market where the "optical infrastructure" side
> > may require lots of single port 10 GbE devices.
> >
> > However, all 10 GbE market objectives must be considered together when developing
> > the architecture for 10 GbE equipment. 10-12.5 Gbps ASIC interconnects are well
> > beyond the capabilities of today's cost-effective technologies. Heck, Hari is
> > right on the hairy edge of these capabilities!
> >
> > > My concern is we are all too willing to make the
> > > optical transceiver the catch-all for all the truly
> > > difficult problems; i.e. the managing of four or eight
> > > lanes of traffic. Simpler is better from the standpoint
> > > of optical transceiver design. Most successful gigabit
> > > designs of today have the SERDES butted right up against
> > > the transceiver (<1") anyway.
> >
> > Most SerDes today are being integrated into their associated (multi-port)MAC/PHY
> > chip.
> >
> > > As a person who will ultimately have to make these optical
> > > transceivers, I am much happier with the simple job of
> > > turning electrical bits into optical bits albeit at 10 times
> > > the rate we are accustomed. The components are already out
> > > there. We just need to keep working on the price, packaging,
> > > and volume issues. I don't mind if there is HARI on the
> > > board somewhere. I would very much prefer that HARI is not
> > > the optical PMD interface. I would very much prefer a serial
> > > optical PMD interface at the full line rate.
> >
> > You're just pushing the problem back into the system. Hari offers a system
> > solution to the problem.
> >
> > > Best Regards,
> > >
> > > Pat Gilliland
> > > patgil@xxxxxxxxxxx
> > >
> > > --------------------------------------------------------------
> > >
> > > At 05:47 AM 12/2/99 -0600, you wrote:
> > > >
> > > >Pat,
> > > >
> > > >Thinking back to all my comments, I don't believe I have indicated that I
> > > would
> > > >use HARI as a backplane/midplane inter-connect. Actually, I never planned
> > > too.
> > > >In a midplane application, I would tackle the 10gig problem, as you
> > > indicate. I
> > > >don't know about the power, but the switching frequency will be harder to
> > > deal
> > > >with from an EMI perspective then you think it will - just from my lab
> > > tests. And
> > > >as far as the inter-connect, the connector is not the main problem, but
> > > rather the
> > > >construction of the through-hole barrel. From the work I have been
> > > pursuing, the
> > > >blade type connector with shields works just fine slightly past 7ghz
> > > before the
> > > >S-params 'look bad'.
> > > >
> > > >The reason I think HARI is interesting is from the following scenario (ie,
> > > >undecided standard): Assume the phy and mac are seperate pieces. And
> > > assume a
> > > >traditional design approach where the mac and the phy are on the same board.
> > > >
> > > >Okay, because of the features, asic designs, etc, the boards I see every
> > > day are
> > > >getting very dense. Smaller BGAs, etc, along with bigger pin counts and
> > > finer
> > > >pitch - combine to create difficult and time exhaustive rounting attempts.
> > > The
> > > >last thing I think I want to do (and it is dependent on the board layout
> > > how I
> > > >tackle a problem) is deal with the glass and copper layer structure for a
> > > 10gig
> > > >geometry. My personal experience indicates in this scenario that the
> > > lower speed
> > > >geometry would be easier to integrate, ie I can make more trade offs with the
> > > >lower speed then the higher. And if I where able to add a cdr in there, I
> > > can now
> > > >move the phy where it needs to be and the mac where it needs to be. This is
> > > >important at this point because the HARI interface uses 8b10b and I
> > > understand
> > > >what factors effect that data pattern in copper geometry. I do not know the
> > > >effects of long lengths on a sonet like data stream, so I am not very
> > > comfortable
> > > >running this on very long lengths until I understand the problems. Same
> > > with some
> > > >of the encoding schemes introduced the last few meetings.
> > > >
> > > >I reckon a 10gig rebuffering/cdr specification would allow me some of the
> > > same
> > > >benifits as the HARI, but I just don't know what will happen when I get
> > > 'layer
> > > >bound' / 'hight bound' in a mother board application. Experience tells me
> > > to go
> > > >with the wider path and deal with the less glass and smaller copper geometry.
> > > >
> > > >So I guess what I really am trying to say is that between the xcvr/phy and
> > > the mac
> > > >(physical packages I am talking about here and through-out this email), I
> > > would
> > > >really like something defined that is not 10gig, but not wider then eight
> > > lines,
> > > >either. Hence, my thougths for using HARI.
> > > >
> > > >Take care
> > > >Joel
> > > >
> > > >
> >
> > --
> > Best regards,
> > Rich
> >
> > ----------------------------------------------------------
> >
> > 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
--
Best regards,
Rich
----------------------------------------------------------
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