Re: HARI Systems Design
Richard:
Thanks for the FR4 waveform in your March presentation.
First, I like to clarify that I am not blindly skeptical about Hari, but I am
also a network, and circuit designer dealt a lot of waveforma distortion and
BER problems in the past. As a result, I realy like to have a better
feeling about the performance of Hari specification.
I believe we are all familiar with FR4 material, which is not a new to most
of us. FR4 has dielectric constant 4.7, and dissipation factor 0.02 at 1
MHz. While the commonly used PCB material, Polyimide has the dielectric
constant of 3.10, and dielectric disipation factor 0.003 at 1 Mhz Comparing
these two numbers, FR4 has slightly higher values of both, than Polyimide.
Highert dielectric constant meeans, higher capacitance, and higher
dissipation factor means higheer loss. It seems to me, these two parameters
are not quite making FR4 a faverable high frequency candidate, which bypasses
more signal away from the PC path. Probably, we should not overly count on
FR4 to lift us to make 3.125 Gbps design easier.
I also revisited your March presentation, slide 11, 2.5 Gbps PCB performance.
The eye opening of FR4, 4"-long is very healthy, which I, believe, will meet
BER 10^-12,or -13, without any question. But the 24 "long, FR4 eye opening
is very much deterated, which I do not believe will have a chance to meet BER
10^-12. I guess, it amy pass 10^-9 BER or higher.
Besides, you tested with 2.5 Gbps, but not 3.125 Gbps, which is about 20%
easier.
I have seen many eye patterns, while I worked on DMD fibers. I am pretty
sure the 24" FR4 eye opening is very doubtful to pass 10^-12 BER.
Nevertheless, from your both eye diagrams of 4" and 24," I guess, we may have
a chance of passing BER 10^-12 at 10" strip, or less.
In other words, we need more test data from everyone to be able to assure how
long we will have at the laboratory environment. In a real system, there are
more noise to reduce the length further.
Regards,
Ed Chang
NetWorth Technologies, Inc.
EChang@xxxxxxxxxxxxxxx
> Larry,
>
> Look also at the first HSSG meeting in Austin:
> http://grouper.ieee.org/groups/802/3/10G_study/public/march99/index.html
>
> I have a presentation showing measured data of 2.5GBaud and 10GBaud links
> that is made on FR4 as well as some other slightly more exotic materials.
> Remember that the highest frequency on the FR4 is really only half the baud
> rate, so we're really talking about 1.5GHz. Many RF/microwave circuits are
> made on FR4 at those frequencies.
>
> Check also Ali Ghiassi et al's presentation at the Kaui meeting (Hari the
> univeresal electronic interface). Both stripline and microstrip were
> measured and modelled to obtain the results.
>
> Operation on FR4 (including connectors) is reasonable at this speed.
>
> Regards,
>
> - Richard
>
> -----Original Message-----
> From: Larry Miller [mailto:ldmiller@xxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, November 24, 1999 9:42 AM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: Re: HARI Systems Design
>
>
>
> How long of traces are you getting on FR-4? Have you actually fabricated
> these?
>
> Our network analyzer tests indicate that FR-4 dies horribly (lossy) above
> about 1.5 Gb/s. By the time we get to 3 GHz all the analyzer is displaying
> is the analyzer receiver input noise, looking in vain for signals......
> (HP8752C)
>
> Your Tricks & Tips look like they would help, but I would be very
> interested in hearing from anyone who claims to have successfully used FR-4
> in 5+ GHz circuits over more than 3-4 inches and, if so, what kind of
> signals.
>
> Thanks,
>
> Larry Miller
>
> At 08:49 AM 11/24/99 -0800, you wrote:
> >
> >Edward
> >
> >I agree with Joel on this. I am presently designing 2 GBS traces on FR4
> and see no
> >problem with 3.125 GBS or there-abouts.
> >
> >As Joel has indicated one must pay careful attention to the geometrys,
> further one
> >must use good connectors that stay at 50 ohms up to several Ghz.
> >
> >Of special intrest:
> > 1. relieve ground/power planes under all component pads to the
> height
> > required for the pad to look like a 50 ohm line.
> > 2. relieve the ground/power planes far enough out to eliminate
> fringing
> > capacitance to a unimportant consideration, or relieve the
> ground/power
> > planes all the way through and depend on the fringing capacitance.
> It may
> > be necessary to use a field solver to simulate it or to make a
> model and
> > measure impedances.
> > 3. relieve via ground/power layers far enough away to keep them
from
> > being less than 50 ohms.
> > 4. pay careful attention to via stubs. Blind vias and the like may
> be
> >required.
> > 5. pay careful attention to power line bypassing, simulate on-chip
> >capacitance,
> > package capacitance, PCB capacitance and discrete bypass
> capacitors.
> >
> >Do these all well and you should be ok. Note that the Hari interface was
> designed
> >to meet the need to provide a geometry that works using FR4 to 10 GBS
with
> >real-world PCB traces. The frequency dependent loss and reflections at 10
> GBS
> >raw would be nearly impossible to compensate. At 3.125 GBS we still have
a
> >workable solution.
> >
> >Ron Miller
> >
> >Joel Goergen wrote:
> >
> >> 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 a 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.
> >>
> >> > 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 mis-match 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.
> >>
> >> > 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. 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.
> >>
> >> > 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
> >> >
> >> > -----Original Message-----
> >> > From: owner-stds-802-3-hssg@xxxxxxxx
> >> > [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Joel Goergen
> >> > Sent: Tuesday, November 23, 1999 8:59 AM
> >> > To: HSSG
> >> > Subject: HARI Systems Design
> >> >
> >> > Hello all and Happy Holidays.
> >> >
> >> > I am very perplexed about a few issues that really bother me. First,
> >> > and for most, the comment: "Don't you think that this is either a
> >> > little early, or does someone have a hidden agenda?" from Roy's email
> >> > this morning in one of the many HARI threads. Unless I am mistaken, I
> >> > have not viewed this, nor any proposal by anyone as a hidden agenda.
> If
> >> > you did call HARI a hidden agenda, then you could call two phys a
> hidden
> >> > agenda, SONET a hidden agenda, etc, etc. Correct me if I am wrong,
> >> > people, but I thought all the presentations were from people who
> believe
> >> > they have a good idea to offer to the standard, might benifit them a
> >> > little, but still a good presentation - or have I just stayed on the
> >> > farm a little too long?
> >> >
> >> > In terms of systems design, "As for real estate on the PC board.
> >> > Vendors need to think about reducing the size
> >> > of their boards and systems. More and more floor space is being taken
> >> > by these systems as well as power and cooling. Reducing the size of
> the
> >> > boards, reducing the amount of electronics, reducing power
> requirements,
> >> > and increasing the density of the connections is becoming an issue in
> >> > large installations, like those that will use P802.3ae. Hari tends to
> >> > take exactly the opposite direction in system design. Hari makes it
> >> > easy for the system designer to become sloppy, not requiring them to
> >> > become tighter and better." I think I would like to take this line by
> >> > line.
> >> >
> >> > Vendors need to think about reducing the size of their boards and
> >> > systems : Well, how about customers should require less features.
Then
> >> > I wouldn't have to go to extraordinary means to get all the components
> >> > shoved into a small bucket. If you want less power, less space, less
> >> > connections, then drop some features.
> >> >
> >> > Board Size: We fit more onto boards today on a gate per sq in level
> >> > then we ever have at a lower price. We are beginning to abandon fr-4
> >> > for newer materials at less cost per route length and more routing
> >> > density.
> >> >
> >> > Thermal and power: Reducing voltages to 2.5v and 3.3v have helped.
> >> > Power bricks are getting much more efficient. Using CMOS over GaAs
and
> >> > Bipolar have helped. We are all required to meet Telcordia
> >> > requirements, so there is only so much heat per sq foot we are allowed
> >> > to produce. Space and thermal and weight ARE already a standard.
> >> >
> >> > Hari makes it easy for the system designer to become sloppy, not
> >> > requiring them to become tighter and better: Wow! Hari or something
> >> > similar does no such thing. It allows the designer the ability to
> >> > re-partition the problem. But, on the other hand, maybe I should be
> >> > against Hari because then that would force most people to think about
> >> > 10gig serial streams for long distances on copper traces ( which most
> >> > companies can not aford to develop ) and go with very wide 622mhz data
> >> > paths so my boards get thicker and more expensive - this allows the
> >> > designer the greater headache of routing and board fab issues. I
don't
> >> > know, if sloppy were true, all of us would be out of business. I have
> >> > seen most of the systems available today and we all pretty much design
> >> > the same, have the same issues, and make the same trade-offs to supply
> >> > the customer all the features they require to make the sale.
> >> >
> >> > So, in summary, Hari is a starting place, as I have mentioned before.
> >> > Even the GMII and MII, etc have issues. But we have a proposal(s) of
a
> >> > start .... how about we try to constructively look at what hari solves
> >> > or doesn't solve. So how do we design Hari to be 'phy independent'?
> >> > Because at the moment, Hari solves most of my SI issues. Oh yeah, the
> >> > job description for the SI guy is as follows : Comes up with last
> minute
> >> > desperate solutions to impossible problems caused by the System
> >> > Architect.
> >> >
> >> > Joel
> >>
> >> --
> >> Joel Goergen
> >> Lucent Technologies
> >> High Performance Networking Division
> >> 10250 Valley View, Suite 113
> >> Eden Prairie, MN, 55344
> >>
> >> Email: goergen@xxxxxxxxxx http://www.lucent.com
> >> Phone: (612) 943-8990 Cell: (612) 670-5930
> >> Direct: (612) 996-6932 Pager: (800) 200-0586
> >> Fax: (612) 996-6695
> >
>
>
> ----------------------- Headers --------------------------------
> Return-Path: <owner-stds-802-3-hssg@xxxxxxxx>
> Received: from rly-zd03.mx.aol.com (rly-zd03.mail.aol.com
[172.31.33.227])
> by air-zd02.mail.aol.com (vx) with ESMTP; Wed, 24 Nov 1999 20:51:54 -0500
> Received: from ruebert.ieee.org (ruebert.ieee.org [199.172.136.3]) by rly-
> zd03.mx.aol.com (v65.4) with ESMTP; Wed, 24 Nov 1999 20:51:33 -0500
> Received: by ruebert.ieee.org (8.9.3/8.9.3) id UAA18450; Wed, 24 Nov 1999
> 20:23:50 -0500 (EST)
> Message-ID: <85501B062BABD211A57E00A0C9E95C834C603D@xxxxxxxxxxxxxxx>
> From: "DUGAN,RICHARD (HP-SanJose,ex1)" <richard_dugan@xxxxxxxxxxx>
> To: "'Larry Miller'" <ldmiller@xxxxxxxxxxxxxxxxxx>,
stds-802-3-hssg@xxxxxxxx
> Subject: RE: HARI Systems Design
> Date: Wed, 24 Nov 1999 17:41:59 -0700
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2650.21)
> Content-Type: text/plain;
> charset="iso-8859-1"
> Sender: owner-stds-802-3-hssg@xxxxxxxx
> Precedence: bulk
> X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> X-Listname: stds-802-3-hssg
> X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
>
>