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

About this list Date view Thread view Subject view Author view

From: cadpro2k@dacafe.com
Date: Wed Apr 11 2001 - 15:10:36 PDT


---------Included Message----------
>From: "Sainath Nimmagadda" <sainath@lsil.com>
>Subject: Re: [SI-LIST] : Diff clocks length matching
>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?
>

As Lee Ritchey would say, and I like to quote as often as possible "Show
me the data." Let's see, if it takes me 3-4 days to layout a certain
"theoretical" geometry on a pcb (say 2 64 bit busses running 4-6" on a
board, at +/-.001" tolerance) because it's thought to be required, and a
simulator costs $10K, what are my options? Might I be able to use the
routing again, or might I use the simulator again? Humm... Was the
insistance based on factual data?

Yep... "Show me the data."

:) Mitch
_____________________________________________________________
Tired of limited space on Yahoo and Hotmail?
Free 100 Meg email account available at http://www.dacafe.com


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:doug@eskimo.com]
Sent: Wednesday, April 11, 2001 8:55 AM
To: Larry Miller; si-list@silab.eng.sun.com
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:alokbya@yahoo.com]
>Sent: Tuesday, April 10, 2001 6:34 PM
>To: Todd Westerhoff; Kim Helliwell; Anthony Davidson
>Cc: 'Dunbar, Tony'; si-list@silab.eng.sun.com
>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 <twester@hhnetwk.com> 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: owner-si-list@silab.eng.sun.com
> > [mailto:owner-si-list@silab.eng.sun.com]On Behalf Of
> > Kim Helliwell
> > Sent: Tuesday, April 10, 2001 4:19 PM
> > To: Anthony Davidson
> > Cc: 'Dunbar, Tony'; 'si-list@silab.eng.sun.com'
> > 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:tony_dunbar@mentorg.com]
> > > 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
>majordomo@silab.eng.sun.com. 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
>majordomo@silab.eng.sun.com. 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              doug@eskimo.com
UltraCAD Design, Inc.          http://www.ultracad.com

**** To unsubscribe from si-list or si-list-digest: send e-mail to
majordomo@silab.eng.sun.com. 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
majordomo@silab.eng.sun.com. 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