From: [email protected]
Date: Fri Jan 19 2001 - 07:03:33 PST
I agree with many, if not all, at least to some degree, of your points
However, in particular I wanted to address your concern about package
parasitics. This is a timely topic as I was going through, in excruciating
detail, the "Package Modeling" section of the IBIS 3.2 spec yesterday. I'm
wondering if you've had the opportunity to review this addition to IBIS.
It seems to me that it may address at least some of your concerns. It seems
to provide an implementation somewhat along the lines of a TOPSPEC type
model in XTK (if your familiar with that). It provides the capability to
specify transmission line length, coupling between pins, forking sections,
You can provide RLC matrices in full, banded, or sparse formats.
This is a somewhat new area for me, so I'm by no means proclaiming this a
panacea for the issues you describe, but if you have an opportunity to
review that portion of the IBIS 3.2 spec (the package model stuff is in
Section 7) I'd be curious to get your thoughts on how well this might
address your concerns on the package parasitic issues.
Now, of course assuming this is an improvement, the challenge still lies in
getting semiconductor folks to provide that level of detail (perhaps
non-trivial for a 300, 400 or greater pin part?) and then getting all the
various simulators to use the data in an intelligent manner.
Again, I agree with your concerns on IBIS shortcomings (especially with
respect to SSO phenomena). However, I guess I have an interest in hoping
that it continues to improve because in many cases HSPICE (or any transistor
level data) is simply not an option provided to us by many (actually, most)
I'd be curious to get anybody's feedback on the shortcomings or strengths of
the IBIS 3.2 package modeling capabilities.
Dell Signal Integrity Group
From: Zabinski, Patrick J. [mailto:[email protected]]
Sent: Friday, January 19, 2001 7:47 AM
To: [email protected]
Subject: RE: [SI-LIST] : SI analysis: IBIS vs. HSpice
We simulate using both IBIS (behavioral) and Hspice (transistor-level)
models. However, because we do not have an IBIS-only simulator,
we use Hspice for IBIS simulations. So, if I can read into your
question a bit, I think what you're really asking is "when do
we use IBIS *models* versus transistor-level models (regardless of
If my assumption is correct, then here's my response.
We use IBIS (behavioral) models only when we absolutely have to. If we
can get transistor-level models (what I believe you're calling
Hspice models), we use them.
When IBIS first starting becoming available, we talked about it
within our group, we studied the standards, and we studied the
information available within the models, and we determined IBIS
was sufficient for lower-frequency, lower-performance, more-forgiving
systems that we were dealing with. I haven't kept up to date
with all the IBIS developments, but I don't believe much
More specifically, packaging parasitics are MUCH more complicated
than the simple discrete L, R, and C models that IBIS allows. What
about crosstalk between package leads/traces? What about leads/traces
that are significantly long compared to an edge rate (where a
transmission line model is more appropriate)?
Also, what about SSN? Will an IBIS model behave differently
if I have have 1,000 simultaneous switching outputs (per ground
pin) vs just one SSO?
What about the non-ideal transistor behavior, like Miller
capacitance effects when the reflected wave hits the driver?
How do IBIS models get affected with different loads? What if
I don't supply the ideal/intended voltage supplies?
In short, after looking at IBIS models and standards, these issues
were not addressed to our satisfaction, and we've (i.e., all the engineers
in our group that I've talked with) have decided to avoid IBIS models
That said, for some technologies/vendors, IBIS models are the only
models available, and we're often stuck using them (within Hspice).
**** 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 : Tue May 08 2001 - 14:30:39 PDT