Re: 10 Gbit PHY, HARI
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.
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.
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.
At 05:47 AM 12/2/99 -0600, you wrote:
>Thinking back to all my comments, I don't believe I have indicated that I
>use HARI as a backplane/midplane inter-connect. Actually, I never planned
>In a midplane application, I would tackle the 10gig problem, as you
>don't know about the power, but the switching frequency will be harder to
>with from an EMI perspective then you think it will - just from my lab
>as far as the inter-connect, the connector is not the main problem, but
>construction of the through-hole barrel. From the work I have been
>blade type connector with shields works just fine slightly past 7ghz
>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
>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
>getting very dense. Smaller BGAs, etc, along with bigger pin counts and
>pitch - combine to create difficult and time exhaustive rounting attempts.
>last thing I think I want to do (and it is dependent on the board layout
>tackle a problem) is deal with the glass and copper layer structure for a
>geometry. My personal experience indicates in this scenario that the
>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
>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
>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
>running this on very long lengths until I understand the problems. Same
>of the encoding schemes introduced the last few meetings.
>I reckon a 10gig rebuffering/cdr specification would allow me some of the
>benifits as the HARI, but I just don't know what will happen when I get
>bound' / 'hight bound' in a mother board application. Experience tells me
>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
>(physical packages I am talking about here and through-out this email), I
>really like something defined that is not 10gig, but not wider then eight
>either. Hence, my thougths for using HARI.