Eric,
There is another good reason to use distributed package modeling (.pkg) data
with IBIS - if the edge rates are fast enough, and the package is large
enough, the ability to represent the package parasitics with a lumped model
breaks down.
This is just the traditional tranmission line rule as it applies to
packages. You can compute the value of the delay from the lumped package
model [Td=sqrt(LC)] and compare it to the expected signal edge rate. That
should tell you whether a lumped package model will suffice, or you need to
consider a transmission line style package description instead.
Microprocessors, FPGAs, ASICs and other large package devices tend to fall
into this category.
As an aside, having the .pkg data reside in the IBIS file itself (as opposed
to an external .pkg file) makes for one less piece of data for the user to
manage (and one less piece of data to misplace...).
Hope that helps,
Todd.
Todd Westerhoff
High Speed Design Specialist
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:twesterh@cisco.com
ph: 978-936-2149
============================================
"You raise me up, so I can stand on mountains;
You raise me up, to walk on stormy seas;
I am strong, when I am on your shoulders;
You raise me up ... to more than I can be"
- Josh Groban, "You Raise Me Up"
-----Original Message-----
From: si-list-bounce@freelists.org
[mailto:si-list-bounce@freelists.org]On Behalf Of Eric Hsu
Sent: Thursday, March 11, 2004 7:06 PM
To: Ibis-Users (E-mail); Si-List (E-mail)
Cc: Frank Dunlap
Subject: [SI-LIST] Which package model is more useful and practical?
Hi Expert,
Has anyone ever really used *.pkg with IBIS model to do some =
simulation, such as SSN? If so, can anyone let me know what's benefit we =
can get from it? Myself prefer choosing IBIS model with package data for =
pin R/L/C from itself, to any other package model like *.pkg or =
S-parameter. If go to IBIS open forum to search all the ibis model, so =
far I did not find any of them really using .pkg model with their ibis =
model. If the chip get low pin count, I think it is easy to handle *.pkg =
model because it is possible to verify accuracy for all the parasitic =
effect. But for big chip, I don't know is there any way can handle that?
For most of the application, I guess, probably it is not necessary to =
provide .pkg model with ibis, because it may only provide one or two =
order accuracy than per-pin R/L/C format in ibis. Tool compatibility may =
be another issue.
Best Regards,
Eric Hsu
Interface Technologies
Netlogic Microsystems, Inc.
450 National Ave.
Mountain View, CA 94043
650-961-6676 x198
This e-mail contains Netlogic Microsystems, Inc. Confidential =
information
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@freelists.org with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@freelists.org with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
http://www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
Received on Fri Mar 12 05:54:22 2004
This archive was generated by hypermail 2.1.8 : Fri Mar 12 2004 - 05:56:15 PST