All,
Yep, it is generally standard laziness on the model makers
side. The logic goes like this:
1) all the i/o buffers on the device are exactly the same.
2) i have specified the min/max/typ package parasitics.
3) all i need to do is provide the data for one pin
4) the user can figure out the rest.
I hate doing this just as much as the rest of you. Fortunately
I have software to extract the pin mappings in IBIS format
of all parts in my simulation database. It is provided by my
simulator vendor. With this it is easy to fix the sins of
a poor model supplier.
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
Syed Huq wrote:
> Mike, > > You are correct. All pins should be specified under the [Pin] keyword. > I have come across 'one' company that is consistently doing this. Most > do provide a full [Pin] list. > > Regards, > Syed > Cisco Systems, Inc > > > X-SMAP-Received-From: outside > > Date: Thu, 26 Aug 1999 08:47:52 -0500 (CDT) > > From: Mike Mayer <[email protected]> > > To: [email protected] > > Subject: [SI-LIST] : IBIS models > > > > I have found several IBIS models that use the [Pin] keyword but only > > model a couple of pins. For example, an octal buffer in a 20-pin > > package that only includes statements for one buffer input pin, one > > buffer output pin, Vcc and Gnd. My reading of the IBIS spec would say > > that this is non-compliant. In Section 5 under "Usage Rules" for the > > [Pin] keyword the first sentence states "All pins on a component must > > be specified.". > > > > 1) Am I correctly interpreting the IBIS specification? > > > > 2) How common are models of this type? > > > > -- > > ============================================================================= > > Mike Mayer Artesyn Communication Products, Inc > > Madison, WI > > http://www.artesyn.com/cp > > ============================================================================= > > > > > > **** To unsubscribe from si-list: send e-mail to [email protected]. > In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. > si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list **** > > > > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****
--------------5FAA414CCFB7291C9FF1B673 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf"
begin:vcard n:McMorrow;Scott tel;work:503-708-4320 x-mozilla-html:FALSE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:[email protected] title:Principal Engineer note:asdfsdaf fn:Scott McMorrow end:vcard
--------------5FAA414CCFB7291C9FF1B673--
**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****