Re: 10 Gbit PHY, HARI
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
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.
> 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
> > 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,
> 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