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