Re: HARI Systems Design
Joel:
Thanks for comment. I believe the circuit issue is equally important to the
other issues. Therefore, I think I should clear some disagreements we have.
The PC board layout technology is a mature technology, and the people
involved in the PCB business are all familiar with all the pros and cons of
issues. The issue here is more of the cost-effective issue than the
technical feasibility issue.
With target price of 3xGbE, 10GbE has to be cost effective to be able to be
embraced by the market. In order to achieve the aggressive low-cost goal, we
have to design a product based on the mass manufacturability across the US
and oversee PCB houses.
Besides many other things, I also involved in the high frequency PCB design
and vender qualification for Unisys and my company for those PCB houses in US
and oversee. All up-to-dated PCB houses use similar well known PCB
equipment, and there is not much differences of where the PCB is made from
performance point of view.
The tolerance of +/- 20% PC-run characteristic impedance is equipment
dependent (consistency of maintaining an even thickness of each layer), and
not technology dependent. It is universally acknowledged that the actual PC
impedance tolerance is +/- 20%, to cause transmission line impedance
mismatch. The system designer has to take that in consideration to add PCB
jitter in the system design. It is possible as you mentioned to minimize the
+/- 2-0% issue by a specifying tighter tolerance, which will not only raise
the cost, but also limit the available manufacturing facilities. The result
is more cost, which is not what we need.
I also like to comment on each item below.
r
>
> I am not sure Ed got the right name in here, because I don't agree with
most
> of
> it. :)
>
> > However, it violates a lot of high-frequency circuit design rules; as a
> > result, it may make HARI an unreliable block in a system.
>
> I don't see it violating any rules.
>
> > Furthermore, additional circuit, HARI, is working against our successful,
> > Ethernet practice of keeping it simple, and low-cost -- unless we prove
> HARI
> > is a "MUST" for 10GbE product, it should be an optional block.
> >
> > For an extremely high frequency PC layout, the path-length should be
kept
> as
> > short as possible. The PCB characteristic impedance has about +/- 20%
> > tolerance which will cause waveform distortion being severe enough at 2.5
> > Gbps data rate to cause excessive errors. Even the skew is minimized by
> > deskew circuit, the waveform distortion by reflection will cause
excessive
> > JITTER by altering the bit-timing information of each bit (bit-cell
timing
> > near 300 ps), which provides the deskew circuit a wrong data. This is
one
> > of the reasons that high frequency transceiver and PLL are preferred to
be
> > in one chip.
>
> I really think what this boils down to if you agree with the above
statement
> is
> that you don't have a current understanding of circuit board geometry, how
> it is
> developed, and what kind of control can be used to over come these issues
in
> 'the circuit board of today'. From my point of view, I can remove all the
> issues
> in this email through careful understanding of the PCB construction. ie,
Ed'
> s
> points are mostly true if you through the gerber over the wall and take
what
> the
> board shop sends back.
>
As I metioned, I have visited and qualified many PCB houses in many years,
not only in US, but also oversee. Thers is no magic in PCB manufacturbility,
unless it is specially made at any cost, which is not we need to compete in
the market place. To ignor all these issue is not practical.
> > Over 2.5 Gbps, and at 20" PC run length, the signal amplitude will be
> > drastically reduced for each inch the signal travels to cause the
> > destination data without sufficient Signal-to-Noise ratio -- inviting for
> > excessive errors. In addition, the rise time will be drastically
> increased
> > to add further jitter to cause wrong data into deskew circuit.
> >
> > The higher the data rate, the capacitive and inductive coupling noise are
> > higher which are linearly proportional to data rate, and the parallel
> > length (20" parallel is excessive at 2.5 Gbps). A ground plan between
two
> > adjacent signals may reduce crosswalk but not necessarily eliminate it
--
> no
> > absolute assurance of eliminating the crosswalk effect. Furthermore, the
> > radiation issues will much tougher to resolve.
> >
> > The PC runs through the backplane have to go through connectors to create
> > waveform distortion caused by impedance mismatch of connectors. At 300
> pc
> > cell time, any glitch could be the sauce of errors.
> >
> > Unfortunately, circuit problems are very difficult to debug, which show
up
> > as excessive random errors. Some time, it takes over six months to find
> > it, then there is no simple cure.
>
> Not sure about this .... all of the issues I have seen in high speed
> differential resulting in the failures listed above have been the result
of
> poor
> power design at the source and destination. The only high frequency desing
> rules
> I have followed are: modeling, good power design, test cards, good power
> design,
> trace and via geometry testing/verification, and good power design.
>
While power design is one of the important parameters, there are many others.
Waveform distortion is the key factors most of engineers cannot appreciate
to deal with. The PCB design model only deals with the most fundamental,
straight forward issues, which cannot express the nonlinear, complex waveform
distortion, and the impact to the system performance. The model will provide
the ideal case performance, but hot the actual case performance with all
sources of noise, and imperfection of the PCB , which is quite deviated from
the ideal model. Nevertheless, I agree to use a model to design the basic
layout, then further enhance the performance by past experiences.
I believe you are one of a few fortunate engineers who have not to face a
tough BER deficiency problems.
> > I further agree with Joel, that HARI will unnecessarily use up the most
> > valuable area of a PC board; namely, high frequency area. I also agree
> that
> > HARI will add more power consumption to what we are struggling to reduce.
> > All of these are counter productive, unless HAIR is "MUST" for the
product.
>
> > Perhaps, HARI can be an option feature.
>
> Not sure I agree with this, either. I don't see the power consumption
being
> an
> issue because I don't know what it is yet, but I have not seen what the
SiGe
> technology is going to consume, either.
If we do not need Hari circuit at all, the Hari circuit is a waste, and
whatever the power is, it is just a waste. I do not think you understood my
reasoning..
As far as the 'high frequency area',
> I
> stand by this statement -> The lower the speed between connection points,
> the
> less board fabrication design I have to develop. So, I would rather deal
> with a
> few more longer pairs of 3.125 then one long run of 10 because the board
fab
> is
> much easier to implement. The cost for me will be the same, either way,
but
> one
> is a lot less work.
>
I agree the lower speed is much easier to handle, but 3.125 GBaud is not low
frequency, which is also a very high frequency to give you a lot of headache.
To ignore or minimize the possible connector impedance mismatch issue, and
high frequency area problem (to be kept noise free) will not help us
delivering the product to market.
Edward S. Chang
NetWorth Technologies, Inc.
EChang@xxxxxxxxxxxxxxxx
> > The system architecture are flexible. There are so many ways to achieve
> the
> > same result. I am not sure that to integrate all channels which are
> > inherently distributed in one big chip is the most cost-effective way to
> do
> > it, considering all the potential problems. I would think a modular
> > approach with scalability may prove to be more cost-effective and more
> > flexible to use from architecture point of view.
> >
> > I would hope some one will present test data to assure the performance,
> > before we have to vote with some reservations.
> >
> > Regards,
> >
> > Ed Chang
> > NetWorth Technologies, Inc.
> > EChang@xxxxxxxxxxxxxxxx
> >