Subject: Signal Integrity engineers, Cref, etc.

From: "J. C. (Jay) Diepenbrock ((919)-543-8804)" <[email-masked]>
Date: Fri, 13 May 94 12:19:30 EDT

Greetings IBISers,

I have a couple of comments on recent discussions.  I agree wholeheartedly
with Greg Canright's comments regarding the need for "Signal Integrity
Engineers" and the difficulty in selling that need to management.  The
common belief seems to be that the realm of signal integrity management is
something that can be picked up whenever it's needed by the average logic
designer, rather than a specialty that should be developed and kept around
to prevent problems before they happen rather than fix them after the fact.
The latter of course causes missed system announcments, blown budgets and
schedules, etc., etc.  I hope that Greg Doyle is mistaken when he says that
one of the primary uses of SI tools is for what I'll call "learning by
fooling around," but perhaps not.

On the need for Cref, I can see how it would be useful to be able to generate
a test waveform using an IBIS model that one could compare to hardware with
the same standard test load (typically 500 Ohms and 50 pF to Ground), but
IBIS models as I understand them are really not intended to provide what
might be called Block Delay information anyway, just the Net Delay due to
transmission line effects and such.  My understanding was that if one wanted
real PATH delays that a timing analysis tool such as Motive (tm) from Quad
was required, to add the intrinsic block delay to the output net delay.

I see no real benefit in doing SI analysis on a real board with any lumped
load other than checking the SI/timing tools against a databook (debugging
models?), since there's no such thing as a board with a 50 pf, 500 Ohm load
to Ground except characterization boards deliberately built that way.  Input
thresholds are a different matter, since they are needed to calculate the
net delays, check for multiple threshold crossings, etc.  Did I miss some-
thing here?

Jay Diepenbrock