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