**From:** Daniel, Erik S. (*[email protected]*)

**Date:** Wed Apr 18 2001 - 12:06:24 PDT

**Next message:**Sreejith Varma: "RE: [SI-LIST] : 2.5ghz simulations"**Previous message:**Jeff Seeger: "[SI-LIST] : Boston area IPC/DC mtg, 24-Apr 6pm"**Next in thread:**Dagostino, Tom: "RE: [SI-LIST] : Re: ADC jitter specs (formerly Diff clocks length matching)"**Maybe reply:**Dagostino, Tom: "RE: [SI-LIST] : Re: ADC jitter specs (formerly Diff clocks length matching)"

Larry-

Part of my confusion may have been that you were apparently mixing the

separate 10 bit 10 MHz case and the 7.5 bit 1.5 GHz case that Tom mentioned.

Also, I do not understand why you bring the ADC amplitude into it -- as is

evident by the equations, the LSB-limited jitter spec depends only on the

sampled frequency and the effective number of bits, as the LSB is defined

relative to the ADC full scale. In any event, it sounds like we agree on

the equations.

Regarding the followng comment:

*> [Larry Miller] -->> Yes, I get that number. And you are talking p-p jitter
*

with a

*> noise bandwidth of at least 0.75 GHz.
*

I'm not sure exactly what you mean by "p-p jitter with a noise bandwidth of

at least 0.75 GHz". Jitter specs seems to be somewhat fleeting. I'm more

comfortable with jitter defined as an integration of phase noise spectral

density over some frequency range of carrier offsets -- the particular

choice of offset frequency range is very much application specific and is

somewhat independent of the sampled frequency. Typically, the high end of

the integration would be the clock frequency (relating to deviations in

timing from one clock cycle to the very next one), and the low end would be

dictated by the longest coherent time cycle required by the system (relating

to deviations in timing from one clock cycle to another one very much later

-- perhaps 1 millisecond => 1 kHz offset frequency for our applications of

interest). If this integration over the desired frequency range yields a

"jitter" that is larger than ~ 2^(-N)/(2 Pi f), then this will appear as

broadband noise which will limit an ADC's effective number of bits to less

than N for sampled frequencies f for that application.

Regarding fs jitter clock sources and our results to date on the 16

effective bit, 350 MHz center frequency ADC system, I can't tell you too

much as many of the details are proprietary to one of our collaborators, but

I can tell you they have developed a custom clock source that has low enough

jitter for the target system (again, on the order of 10 fs), and system

demonstrations to date have shown about 13 effective bits at a 350 MHz

center frequency, believed not to be limited by timing jitter.

Commercially, the best low phase noise sources seem to be made by Poseiden

(www.psi.com.au). The specs on their web page are given in terms of phase

noise spectral density instead of jitter, as the definition of "jitter" is

somewhat loose as I mentioned above, but integrated jitters in the 10s of fs

are possible, again depending on your required integration band.

Regarding measurements of "jitter" of this order, I agree one would never

try to measure it with a scope. In my opinion, the best way to measure

phase noise is with a (aptly named) phase noise test set, which measures

phase noise spectral density versus frequency offset from the carrier for a

clock source input.

- Erik

==================================================================

Erik Daniel, Ph.D. Mayo Foundation

Voice: (507) 284-1634 Guggenheim 1011B

Fax: (507) 284-9171 200 First Street SW

E-mail: [email protected] Rochester, MN 55905

==================================================================

-----Original Message-----

From: Larry Miller [mailto:[email protected]]

Sent: Wednesday, April 18, 2001 9:43 AM

To: 'Daniel, Erik S.'; Larry Miller

Cc: [email protected]; [email protected]

Subject: RE: [SI-LIST] : Diff clocks length matching

My responses are below (-->>)

-----Original Message-----

From: Daniel, Erik S. [mailto:[email protected]]

Sent: Wednesday, April 18, 2001 5:16 AM

To: [email protected]

Cc: [email protected]; [email protected]; Daniel, Erik S.

Subject: RE: [SI-LIST] : Diff clocks length matching

Larry-

I have to agree with Tom somewhat, although the discussion has moved from

that of absolute timing (line matching) to timing uncertainty (jitter).

Jitter (or more accurately, phase noise) is a big deal for ADCs. We have

been working on some high bandwidth, high effective number of bit ADCs that

require clocking with jitter (or more accurately, integrated phase noise) in

the low fs range.

The numbers you threw out in your e-mail did not make sense to me.

[Larry Miller] -->>

What does not make sense? I am using the very formulae you have below, with

Tom's example plugged in and adjusted for the Maxim data sheet claims and

voltages.

His original example was for a 1 volt sine wave at 10 MHz. Reducing the

amplitude to 0.25 volt reduces the slew rate by 4 (the dV in dV/dt). I hope

there is no disagreement about this at least.

He was talking about a 10-bit, 1V p-p system (1 LSB is approximately 1 mV).

The Maxim one was 7.5 bits. Therefore, an LSB is represented by a larger

voltage fraction of full scale (1/(2^7.5) = 0.0055 full scale. That turns

out to be 0.0055 * 0.250 * 2 <--(for p-p) = 2.76 mV. Do you agree with that?

I was just trying to keep apples with apples.

Anyway, I have not seen any femtoseconds appear yet in these numbers, except

in globs of 1000's.

-------------------

Tom's seemed to be more reasonable. In the simplest sense, the argument

goes like this: for a signal with a slew rate of dV/dt, a timing

uncertainty of DT causes a voltage error of DV. For a sine wave of

frequency f and amplitude V0, dV/dt = 2 Pi V0 f. Therefore,

DV

---- = 2 Pi f DT

V0

Assuming the sine wave was a full scale input to an ADC, DV is equal to an

LSB when it equals V0 2^(-N) where N is the effective number of bits.

Therefore, For an N-bit ADC with input frequency f, we require

2^(-N)

DT < --------

2 Pi f

[Larry Miller] -->> I do not disagree with your math. And I do understand

it. Honest.

For the Maxim example given (N=7.5 ENOB, f = 0.75 GHz), this leads to a

required maximum jitter of 1.2 ps.

[Larry Miller] -->> Yes, I get that number. And you are talking p-p jitter

with a noise bandwidth of at least 0.75 GHz.

--------

To be precise, a few other factors of 2 and sqrt(12) are thrown in which

change this number a bit, but it's in the right ballpark. Try testing one

of these parts with a poor clock source and you will immediately see the

noise floor rise up in the frequency domain plots. One of our projects was

aimed at N=16 ENOB, f = 350 MHz input frequency (though only a 100 MHz

bandwidth) requiring jitter on the order of 10 fs.

[Larry Miller] -->> 16 bits at 350 MHz. A mind boggler. Note that the

timing accuracy requirement is due to the 1/65536 full scale size of an LSB.

Did you actually achieve this?

Anyway, I claim that you cannot measure this except on a statistical basis--

at least not with the mentioned $40,000 to $80,000 equipment. And by your

definition ALL of the clock sources I have ever had access to are "poor".

What did you use for a) clock and b) test equipment?

--------

The *absolute* timing requirements (e.g., line matching) for this system

were not nearly so stringent, though.

[Larry Miller] -->> Line length matching was indeed the topic, at least

originally. But topic drift is not totally unknown here. This thread went:

line length matching for logic --> video requirements (I do not know of any

350 Mhz BW ones, but then radar dudes used to call 70 MHz "video") -->

limits of ADC performance.

I have yet to see a system that requires absolute timing with these kinds of

tolerances.

[Larry Miller] -->> Me, neither, and I have never seen one that achieves

it on even a cycle-to-cycle (sample-to-sample) basis. If it did, would not

know it: I could not measure it.

- Erik

==================================================================

Erik Daniel, Ph.D. Mayo Foundation

Voice: (507) 284-1634 Guggenheim 1011B

Fax: (507) 284-9171 200 First Street SW

E-mail: [email protected] Rochester, MN 55905

==================================================================

-----Original Message-----

From: Larry Miller [mailto:[email protected]]

Sent: Tuesday, April 17, 2001 9:36 PM

To: 'Dagostino, Tom'; Larry Miller; 'Scott McMorrow'; [email protected]

Cc: Sainath Nimmagadda; Signal Integrity

Subject: RE: [SI-LIST] : Diff clocks length matching

Hi, Tom,

Well, I used a Tek 11801C for four years, and we are looking forward to a

CSA8000 with fins & fog lights. Additionally, we used (still do) a Tek 694C

with the Amherst jitter analysis software which in fact calibrates out the

scope jitter caused by trigger level uncertainty, one of two components (the

vertical one) of aperture jitter. The CSA8000 advertises a couple of

picoseconds of short term jitter, not femtoseconds. Factor of 1000 there....

I have never seen anything in the femtosecond area in any of these

instruments. For one thing, you cannot begin to see that on the screen at

the highest sweep rate on the 11801C. The 694C/Amherst combo gets such

numbers by mathematically mulching boucoup samples-- the scope only has a 10

G sample/sec (Gsps) maximum rating, if I read the front panel correctly on

the one we have. If I remember correctly, it has something on the order of 6

to 7 ps of residual absolute time base error.

To date, in my femtosecond-challenged locations, whenever we started talking

about fractional picoseconds we were talking about averages of large numbers

of samples to allow statistics to work for us.

Now, using your own example and ratcheting down to a realizable (by Maxim)

7.5 bits you open up your window from 15.9 ps (time is a strange unit for

phase, BTW, but I get the idea, or at least think I do, that you mean sample

time uncertainty) by 5.6568542494923801952067548968388 (as long as we are in

this realm, what the hey, let's have ALL the decimals) to 89.94 ps. Take it

down by the fact that this ADC only handles +/- 0.25 V signals-- that cuts

the slew rate by another factor of 4 by your method-- and that would mean

that 0.3 ps of board mismatch would be 0.08% of the ADC uncertainty.

Negligible, I think.

The aperture jitter in the Maxim spec sheet seems to mainly indicate that

they have a very high slew rate input amplifier (which they brag about) and

a fast sampler switch, which is swell. Note that this jitter number is

relative to the clock (which I surely cannot afford if it is this accurate

on a single sample basis). Even so, this spec is foot-noted (note 11) to

invoke a best-fit curve; oh, dang it, there is that averaging thing again!

(Don't get me wrong, this is a very impressive ADC by the specs.)

Now, the scopes referred to by you are 20 GHz to 50 GHz instruments, which

is in line with the number I said (31 GHz) your calculation implies. The

Maxim ADC is only 1.5 Gsps and the effective number of bits falls off a

cliff above that. You *could not use it* in the scopes mentioned, even the

694C. Why not?

0.3 ps resolution is not fast to me (0.3 ps absolute accuracy is another

matter entirely), and it is indeed necessary in the 50+ GHz arena, which I

think is where we ended up on this (see below), at least to us

skeptics--->"wow, you must be looking at really high frequency signals!".

....whole lotta specmanship goin' on... (sing in Jerry Lee Lewis mode).

Sorry about the planetary reference, I'm rather new here myself.

Larry Miller

-----Original Message-----

From: Dagostino, Tom [mailto:[email protected]]

Sent: Tuesday, April 17, 2001 5:45 PM

To: 'Larry Miller'; Dagostino, Tom; 'Scott McMorrow'; [email protected]

Cc: Sainath Nimmagadda; Signal Integrity

Subject: RE: [SI-LIST] : Diff clocks length matching

Don't confuse bandwidth with phase. This is a phase error problem, making

sure all ADC's are sampling at the same phase of the input. 15.9 psec of

phase error of a 10 MHz is 1 LSB of a 10 Bit ADC.

Look at the Maxim Max108 1.5GS/sec ADC.

http://pdfserv.maxim-ic.com/arpdf/2092.pdf

It is rated at 7.5 effective bits at its Nyquist of 750 MHz. See page 5 and

you will see it has an aperture jitter of 0.5 psec typical.

0.3 psec may seem fast to you but Tek and -hp-/Agilent have been making

oscilloscope time bases with femtosecond resolution for years. You have to

be able to do this to digitize 50 GHz signals to any kind of accuracy. See

http://www.tek.com/Measurement/cgi-bin/framed.pl?Document=/Measurement/scope

s/index/prodindex_sampling.html&FrameSet=oscilloscopes

I am on earth, where are you?

Tom Dagostino

IBIS and Tau Modeling Manager

SDD

Mentor Graphics Corp.

503-685-1613

[email protected]

-----Original Message-----

From: Larry Miller [mailto:[email protected]]

Sent: Tuesday, April 17, 2001 5:05 PM

To: 'Dagostino, Tom'; 'Scott McMorrow'; [email protected]

Cc: Sainath Nimmagadda; Signal Integrity

Subject: RE: [SI-LIST] : Diff clocks length matching

*>>Do the same exercise at 100 MHz input signal and you would get 1.59 psec.
*

That would be the

*>>total budget for timing errors. Of that, how much do you want the board
*

to contribute?

---Show me an ADC that has timing errors down in this region and I will go

along with 0.3 ps making a difference somehow.

What your time resolution calculation implies is a video system bandwidth of

62.893081761 * 0.5 GHz.

Nahhhhh........ Come back to Planet Earth.

Fine time granularity implies high bandwidth and vice-versa.

Larry Miller

-----Original Message-----

From: Dagostino, Tom [mailto:[email protected]]

Sent: Thursday, April 12, 2001 11:24 AM

To: 'Scott McMorrow'; [email protected]

Cc: Sainath Nimmagadda; Signal Integrity

Subject: RE: [SI-LIST] : Diff clocks length matching

There are very common applications where much tighter timing than you would

expect is required.

For example digitizing video signals presents some interesting timing

constraints. Let's assume

there are the R, G and B signals getting to 3 10 Bit ADCs at the same time.

Each of these

converters will run at 20 MS/sec. Let's assume the worst case, a 10 MHz

sine wave input of 1 Volt

amplitude. We want to digitize all the components at the same time. In

this case the same time

will be defined as there will be no more than 1/2 bit in amplitude

difference between the three

signals due to time differences in sampling.

The math is straight forward.

signal = 1sin2Pi10^7

the slew rate is the derivative

2Pi10^^7cos2Pi10^7

evaluated at the max slope

2Pi10^7 V per sec

The amount of time it takes for this slew rate to travel 1/2 LSB of the ADC

is

1mV/2Pi10^7

or about 15.9 psec

Do the same exercise at 100 MHz input signal and you would get 1.59 psec.

That would be the

total budget for timing errors. Of that, how much do you want the board to

contribute?

Tom Dagostino

IBIS and Tau Modeling Manager

SDD

Mentor Graphics Corp.

503-685-1613

to[email protected]

-----Original Message-----

From: Scott McMorrow [mailto:[email protected]]

Sent: Wednesday, April 11, 2001 3:36 PM

To: [email protected]

Cc: Sainath Nimmagadda; Signal Integrity

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

There's no magic here. As Larry Miller correctly points out, 1 mil is

only 300fs in delay. A state of the art 10Gbps driver can launch a

25ps edge, due to impedance mismatches and loss effects you are

lucky to be able to keep the edge rate across a board to less than

50 ps. A 1 mil differential skew (300fs) is 0.6% of the duration of the

edge. This is an insignificant skew relative to other effects on the board

and in the system.

I'd be generally very happy to have differential skews matched to

within 5% of the edge rate for most systems.

10Gbps - about 10 mils

3.2 Gbps - about 20 mils

2 Gbps - about 25 mils

1 Gbps - about 50 mils

622 Mbps - about 100 mils

Then, on a board with 100's of differential pairs, if the layout misses

the mark by a factor of 2:1 on each of the 3 boards in the total end to

end path (driver --- backplane --- receiver), there is still enough

headroom to still work.

regards,

scott

-- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com [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."

:) 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]] 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 ****

**Next message:**Sreejith Varma: "RE: [SI-LIST] : 2.5ghz simulations"**Previous message:**Jeff Seeger: "[SI-LIST] : Boston area IPC/DC mtg, 24-Apr 6pm"**Next in thread:**Dagostino, Tom: "RE: [SI-LIST] : Re: ADC jitter specs (formerly Diff clocks length matching)"**Maybe reply:**Dagostino, Tom: "RE: [SI-LIST] : Re: ADC jitter specs (formerly Diff clocks length matching)"

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