From: Bill Owsley ([email protected])
Date: Wed Apr 11 2001 - 15:24:46 PDT
At 02:10 PM 04/11/2001 -0800, [email protected] wrote:
>---------Included Message----------
> >From: "Sainath Nimmagadda" <[email protected]>
> >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."
no way - job security... ps. where'd you get a $10K simulator that you'd
believe?
;) - Bill
>:) 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:[email protected]>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]>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]>mailto:[email protected]
>> un.com]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]>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/>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>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>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>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>http://www.qsl.net/wb6tpu
>>****
>
>
>
----------------------------
Bill Owsley, [email protected]
919) 392-8341
Compliance Engineer
Cisco Systems
7025 Kit Creek Road
POB 14987
RTP. NC. 27709
**** 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
****
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:32 PDT