Re: [SI-LIST] : Diff clocks length matching

About this list Date view Thread view Subject view Author view

From: Sainath Nimmagadda ([email protected])
Date: Wed Apr 11 2001 - 18:32:24 PDT


It appears that I was mistaken by some. The message was about the laws
of physics. No reference to a particular situation. I did not imply
that physical laws change. All I meant was the possibility of
new/additional laws (which do not violate existing laws) as we
understand science.

Sainath

Larry Miller wrote:

> I think that pushing the envelope is OK if appropriate. I certainly
> never expected to be running digital logic signals around at microwave
> frequencies-- cheaply at that.The operative word is "appropriate".Most
> physical laws have not changed within my memory. Certainly not these,
> anyway.As a physicist friend of mine at Cambridge once said, "the more
> we measure the speed of light the more constant it gets".I do think
> there is a lot of BS physics in the last 20 years. I don't believe in
> any of these so-called demonstrations of hyper-light signal
> information propagation (every test setup looks "rigged"). And I think
> that most of the popular explanations of chaos theory are bunk written
> by people who don't seem to realize that nonlinear finite-state
> systems naturally have limit cycles, which is NOT new and certainly
> nothing like the "magic" ascribed to it. Anyone who has had to deal
> with digital servo systems has contemplated this phenomenon for many
> hours. (BTW, I was an alpha tester along with Mr. James Gleick on Word
> For Windows <1.0.)See http://www.badscience.com/.Larry
>
> -----Original Message-----
> From: Sainath Nimmagadda [mailto:[email protected]]
> Sent: Wednesday, April 11, 2001 12:19 PM
> To: Signal Integrity
> Subject: Re: [SI-LIST] : Diff clocks length matching
> Hey Larry,
>
> Don't you think we keep adding new laws to physics as we
> push the envelope. I believe that pushing the envelope
> happens when somebody *insists* on something. Don't you
> agree with me?
>
> Sainath
>
> Larry Miller wrote:
>
> > ...and when I was in the professional audio business
> > (Ampex in its Days of
> > Glory) I had guys tell me they could hear 30 kHz.
> >
> > 0.002" = 0.3 picoseconds with your own calculator (which I
> > use frequently,
> > thanks!). I don't believe you can measure that in a video
> > system, much less
> > see any effects from it. How much of a pixel is that in
> > any analog system,
> > let alone a digital one that is clocked?
> >
> > Rich Hollywood nuts may demand it and even pay for it, but
> > it doesn't mean
> > it is necessary. Personally, I stand by the laws of
> > physics, not psychics.
> >
> > Regards,
> >
> > Larry Miller
> >
> > -----Original Message-----
> > From: Doug Brooks [mailto:[email protected]]
> > Sent: Wednesday, April 11, 2001 8:55 AM
> > To: Larry Miller; [email protected]
> > Subject: RE: [SI-LIST] : Diff clocks length matching
> >
> > Actually we had a customer once that wanted a large number
> > of bus's ALL
> > matched to within a spec like that. The bus's were for a
> > matrix of video
> > signals. The argument was that you couldn't measure the
> > differences in
> > time, but you could SEE it on the display matrix. It cost
> > them a lot in
> > time and in layers to get that, but they insisted it was
> > important.
> >
> > Doug Brooks
> >
> > At 07:06 PM 4/10/01 -0700, you wrote:
> > >2 mils (0.002") is a ridiculous spec unless you are
> > operating at 200 GHz.
> > >
> > >0.1" is close enough for 2 GHz at anything like normal
> > propagation
> > >velocities (in the vicinity of 5.6" per ns).
> > >
> > >Search on polar.com to get tutorials on differential
> > pairs or search on
> > Eric
> > >Bogatin or just search on differential pairs. National
> > Semi has quite a
> > >tutorial in their LVDS literature, You have the right
> > idea, but you are not
> > >looking at the correct parameters. When you find it, show
> > it to whomever
> > >asked for 0.002" phase matching!
> > >
> > >Larry Miller
> > >
> > >
> > >-----Original Message-----
> > >From: AA [mailto:[email protected]]
> > >Sent: Tuesday, April 10, 2001 6:34 PM
> > >To: Todd Westerhoff; Kim Helliwell; Anthony Davidson
> > >Cc: 'Dunbar, Tony'; [email protected]
> > >Subject: [SI-LIST] : Diff clocks length matching
> > >
> > >
> > >
> > >This questions concern routing fast differential
> > >clocks pairs from a clock driver to chipset. The pair
> > >is series terminated and the termination resistor set
> > >near the clock driver. I learned that the pair needs
> > >to be length matched to within 2 mills.
> > >- First questions is which trace do we need to
> > length
> > >match is the one between the chipset and the
> > >termination resistor or is the entire trace length
> > >(between clock drive and chipset) and why?
> > >- Second it was suggested that the spacing between
> > >the pair should be set to 12 mills ( a multiplier of
> > >the distance to the GND plane). This was based on
> > >simulation. How does one come up with the ideal
> > >spacing and what factors impact this? I thought
> > >separating the differential pair to far would be
> > >counter intuitive since it impacts their common mode
> > >noise rejections? But then getting them to close may
> > >present cross talk issues!!
> > >
> > >Your input is very much appreciating it.
> > >
> > >Adan
> > >
> > >--- Todd Westerhoff <[email protected]> wrote:
> > > > "So I think the accuracy issue is illusory."
> > > >
> > > > I like that. Truer words were never typed ;-).
> > > >
> > > > The argument of IBIS vs. HSPICE is a recurring one.
> > > > While I think there is
> > > > a lot of substance to it, I also think the whole
> > > > issue is incredibly
> > > > over-hyped. We're talking about analog analysis
> > > > after all; error is
> > > > inherent. It *cannot* be avoided, and therefore,
> > > > the real issue is keeping
> > > > the "accuracy" of the analysis in perspective. It
> > > > doesn't do you much good
> > > > to go after the last 1% of accuracy with your
> > > > simulator algorithms when your
> > > > models are only +/- 5% to start with. However,
> > > > understanding how models
> > > > correlate back to reality is difficult, at best.
> > > >
> > > > The real problem, I suspect, is that "HSPICE is more
> > > > accurate than IBIS"
> > > > makes for a good sound bite, and "you really have to
> > > > understand what you're
> > > > modeling, and how" doesn't. After all, modeling
> > > > isn't fun. Right?
> > > >
> > > > I think there are lots of places where the "SPICE or
> > > > not to SPICE" arguments
> > > > have merit. But I've also spent enough time
> > > > trudging through models and
> > > > data where the most basic things were wrong, to know
> > > > that until we have a
> > > > firm, common foundation, arguing about details
> > > > doesn't make much sense. And
> > > > guess what - we're not there yet!
> > > >
> > > > The disguised blessing with IBIS is that by
> > > > standardizing the model format,
> > > > it made it easier for users to find problems with
> > > > the models they use, and
> > > > to correlate those models against test load
> > > > conditions and datasheets.
> > > > HSPICE models, in contrast, are often encrypted and
> > > > have unique interface
> > > > requirements (control pins, voltages and slew
> > > > rates). Bottom line, an IBIS
> > > > model is a lot easier to check and use than a
> > > > corresponding HSPICE model.
> > > >
> > > > If you're analyzing phenomena that only a SPICE
> > > > model can represent, then
> > > > there's no choice. But I'd use IBIS as the "first
> > > > line of defense" in any
> > > > situation where I could, and only back that analysis
> > > > up with SPICE when
> > > > needed.
> > > >
> > > > My $0.01 (only worth half of a typical opinion).
> > > >
> > > > Todd.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email protected]
> > > > [mailto:[email protected]]On Behalf Of
> > > > Kim Helliwell
> > > > Sent: Tuesday, April 10, 2001 4:19 PM
> > > > To: Anthony Davidson
> > > > Cc: 'Dunbar, Tony'; '[email protected]'
> > > > Subject: Re: [SI-LIST] : Hspice: Windows vs Unix
> > > >
> > > >
> > > > Actually, accuracy isn't really the issue, or at
> > > > least not in the
> > > > sense your management probably means it, Anthony.
> > > >
> > > > SpecctraQuest uses a spice-like simulator, TLSIM, to
> > > > do the work.
> > > > This simulator is a derivative of SPICE (I don't
> > > > know which flavor),
> > > > and therefore has all the usual accuracy plusses and
> > > > minuses of
> > > > any SPICE, including HSPICE.
> > > >
> > > > In addition, TLSIM has a coupled transmission line
> > > > model, and the
> > > > diode and transistor models have been removed, and
> > > > the whole simulator
> > > > has been optimized for the problem it's intended to
> > > > solve.
> > > >
> > > > The question of whether TLSIM's coupled transmission
> > > > line is more
> > > > or less accurate than HSPICE's W-element is one of
> > > > the issues, and
> > > > I cannot quantify it, except that I've never seen
> > > > any reason to
> > > > distrust either one. From that I conclude that they
> > > > are probably
> > > > equally good.
> > > >
> > > > The real issue you face is the classical conundrum
> > > > of SPICE: that accuracy
> > > > of results depends on accuracy of the models. So
> > > > the issue is: what's
> > > > more accurate: the manufacturer's original BSIM
> > > > models of their buffers,
> > > > or their IBIS models? The answer is obvious, since
> > > > presumably the IBIS
> > > > models derive from the SPICE buffer models (almost
> > > > no one creates IBIS
> > > > models from lab measurements, you see). But IBIS
> > > > models can be very
> > > > close to the buffer models they derive from, and
> > > > it's possible to lose
> > > > very little accuracy in using them. Whereas you
> > > > might not be able to even
> > > > get the buffer model. And then you are forced to
> > > > use HSPICE's IBIS buffer
> > > > model, at which point the accuracy of the two is on
> > > > an even footing, and
> > > > it's *MUCH* harder to use HSPICE in this way than to
> > > > use SpecctraQuest.
> > > >
> > > > So I think the accuracy issue is illusory. If your
> > > > management has enough
> > > > confidence in you, you have a chance to educate
> > > > him/her/them as to the
> > > > realities of the situation.
> > > >
> > > > Personally, I've used SpecctraQuest a lot in the
> > > > last 2 years, and HSPICE
> > > > only
> > > > occasionally. I use it for 2 things: as a field
> > > > solver when the problem is
> > > > not easily expressible in terms that SQ understands,
> > > > and perhaps to create
> > > > an IBIS model when the vendor provides an HSPICE
> > > > buffer model but no IBIS
> > > > model.
> > > > A third possibility is when IBIS doesn't accommodate
> > > > a particular type of
> > > > buffer.
> > > >
> > > > So I think Tony has a good question, and it's also
> > > > not clear to me what
> > > > value-added HSPICE provides in your management's
> > > > view. There is some, but
> > > > perhaps not where they are looking for it.
> > > >
> > > > Kim
> > > >
> > > > Anthony Davidson wrote:
> > > > >
> > > > > Perhaps that's where I have seen your name.
> > > > >
> > > > > I am a new user to Hspice, and SpecctraQuest for
> > > > that matter. But the
> > > > > opinions of my team leaders is that the tools that
> > > > are able to do analysis
> > > > > on complete boards and board-to-board
> > > > interconnects are not as accurate as
> > > > > Hspice. And Hspice is more accurate, however, the
> > > > analysis of complex
> > > > (many
> > > > > connections) boards is very difficult.
> > > > >
> > > > > Note that the "less accurate" and "more accurate"
> > > > statements are the
> > > > > opinions of others and not necessarily
> > > > quantifiable.
> > > > >
> > > > > Anthony Davidson
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dunbar, Tony
> > > > [mailto:[email protected]]
> > > > > Sent: Tuesday, April 10, 2001 11:18 AM
> > > > > To: 'Anthony Davidson'
> > > > > Subject: RE: [SI-LIST] : Hspice: Windows vs Unix
> > > > >
> > > > > Hi Anthony,
> > > > >
> > > > > No, neither Nortel, nor Univ of Western Ontario.
> > > > Maybe you've seen my name
> > > > > on the list or something.
> > > > >
> > > > > The reasoning behind my question is that the
> > > > platform on which you're
> > > > > running the other tools might give some pointers
> > > > to the H-SPICE platform
> > > > > choice. Actually, since you're going with
> > > > SPECCTRAQuest, I don't really
> > > > see
> > > > > the need for H-SPICE for the so-called "fewer,
> > > > critical nets". On these
> > > > > nets, what is it you're looking for SPICE to
> > > > provide that SPECCTRAQuest
> > > > > can't? I'm not saying there is never room for
> > > > co-existance,
> > >=== message truncated ===
> > >
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Get email at your own domain with Yahoo! Mail.
> > >http://personal.mail.yahoo.com/
> > >
> > >**** To unsubscribe from si-list or si-list-digest: send
> > e-mail to
> > >[email protected]. In the BODY of message put:
> > UNSUBSCRIBE
> > >si-list or UNSUBSCRIBE si-list-digest, for more help, put
> > HELP.
> > >si-list archives are accessible at
> > http://www.qsl.net/wb6tpu
> > >****
> > >
> > >**** To unsubscribe from si-list or si-list-digest: send
> > e-mail to
> > >[email protected]. In the BODY of message put:
> > UNSUBSCRIBE
> > >si-list or UNSUBSCRIBE si-list-digest, for more help, put
> > HELP.
> > >si-list archives are accessible at
> > http://www.qsl.net/wb6tpu
> > >****
> >
> > .
> > *
> > **********************************************************
> >
> > Doug Brooks' book "Electrical Engineering for the
> > Non-Degreed
> > Engineer" is now available. See our web site for details.
> > .
> > Doug Brooks, President [email protected]
> > UltraCAD Design, Inc. http://www.ultracad.com
> >
> > **** To unsubscribe from si-list or si-list-digest: send
> > e-mail to
> > [email protected]. In the BODY of message put:
> > UNSUBSCRIBE
> > si-list or UNSUBSCRIBE si-list-digest, for more help, put
> > HELP.
> > si-list archives are accessible at
> > http://www.qsl.net/wb6tpu
> > ****
>

**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:32 PDT