Radovan, Thank you for your questions on IBIS. Both you and Weston have highlighted approaches that are available under IBIS 4.1. I would like to add a few details, to illustrate some of the concerns about packages under IBIS and how improvements now in planning will address your concerns. 1) You are correct that the approaches under IBIS may not address all possibilities. A simple description of the options is: a) [Pin] - each pin may have a lumped RLC circuit; does not cover corner cases, distributed t-lines or coupling b) [Package] - the entire component may have lumped RLC package circuit descriptions; covers corners, but not distributed t-lines or coupling c) [Package Model] - through .pkg, pins have distributed frequency-independent t-lines as packages, but without coupling. The same keyword can also support .pkg files with matrix data for coupling; however these matrices are frequency-independent and permit only one matrix for the entire path from pad to pin. All of the above formats assume a 1-to-1 mapping between die pads and package pins. ICM supports frequency-dependent RLGC tables along with S-parameter data, and is not limited to any particular endpoint-to-endpoint mapping scheme. You can see more information on the history of IBIS package solutions, along with ICM as a new option, at: http://www.eda.org/ibis/summits/oct03/mirmak2.pdf 2) At this point, ICM represents the best option for long-term support of complex package structures in a behavioral, standard way. Today, connections between ICM and IBIS files are left to individual tools to support. The IBIS Futures Task Group is working weekly on an update to directly link the two specifications, anticipated for IBIS 5.0. I should note that IBIS 4.1's multilingual extensions (in this case, [Circuit Call] and [External Circuit]) were intended for use with Berkeley SPICE. Proprietary SPICE variants are not supported by the parser or the specification. 3) Note that, while the [Package] keyword is required under IBIS 4.1, the data can consist of zeroes. In many cases, model authors who use [Package Model] and/or .pkg data do just that, as [Pin] and [Package] data is overridden when [Package Model] is present. Also, note that the package information listed in the [Pin] keyword is optional as well; it does not have to be listed at all. As Weston noted, your proposal for removing the package data under [Pin] and replacing it with [Circuit Call]/[External Circuit] is perfectly valid. If you were to "zero out" the [Package] keyword, you could include all package details in such a set of External Circuits, modeled in Berkeley SPICE or the AMS languages. Please consult your EDA tool vendor(s) for information on how IBIS 4.1 is supported within their products. The IBIS community recognizes that today's package options under IBIS may not be appropriate for all applications. IBIS 4.1 and ICM are specifically targeted, along with the IBIS 4.2 and IBIS 5.0 drafts in progress, to enable package interconnect solutions for today's needs and for the future. I hope this helps! - Michael Mirmak Intel Corporation Chair, EIA IBIS Open Forum -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Radovan.Vuletic@infineon.com Sent: Thursday, March 23, 2006 8:15 AM To: ibis-users@eda.org Subject: [IBIS-Users] How to replace RLC package Hi experts, once again (almost) the same question, but now other way around ... Recently I am getting lot of pressure to figure out how (in which format) to generate reasonable package model for IBIS models of our components. Possible solutions: ============== 1.) [Sparse Matrix] - contra: tools that generate [Sparse Matrix] models can't generate models for multidrop networks (i.e. one pin one the input, more than one pads on output), sloppy support from simulation tools 2.) ICM - contra: no available tool for automated extraction (and nobody wants to do it manually :-(((() 3.) Simple RLC parameters - contra: no information about cross-coupling RLC elements (coupling capacitances, mutual inductances, etc.) Workaround: use HSpice model of package, but how to "connect" it with IBIS model? IBIS 4.1 provides new keywords [External Circuit], [End External Circuit], [External Model], [End External Model] [Node Declarations], [End Node Declarations], [Circuit Call] and [End Circuit Call] to support multi-lingual models - nice! Main question: Is there a possibility to replace package description in [Pin] section of [Component] with some [External Circuit] or [External Model] or [Node Declarations]? So what I want to do is to replace: [Pin] signal_name model_name R_pin L_pin C_pin | A1 VDD POWER 210m 4.07nH 0.27pF A2 NF NF_INPUT 168m 2.70nH 0.19pF . . . T8 VSS GND 127m 1.45nH 0.23pF T9 VSSQ GND 151m 2.18nH 0.13pF With a call to HSpice netlist [Circuit Call] Pointer to HSpice model of package [End Circuit Call] Or [External Circuit] Pointer to HSpice model of package [End External Circuit] Allows IBIS 4.1 something like that - is IBIS 4.1 planed for something like that at all? When I take a look (please see below) on a Figure 1 provided in IBIS specs, I am not sure that it is possible. | The placement of these keywords within the hierarchy of IBIS is shown in the | following diagram: | | | |-- [Component] | | | ... | | |-- [Node Declarations] | | |-- [End Node Declarations] | | | ... | | | ... | | |-- [Circuit Call] | | |-- [End Circuit Call] | | | ... | | ... | |-- [Model] | | | ... | | |-- [External Model] | | |-- [End External Model] | | | ... | | ... | |-- [External Circuit] | |-- [End External Circuit] | | ... Has anybody some idea about it? Many thanks for every answer! Best regards / Mit freundlichen Grüßen / S po¹tovanjem Radovan Vuletiæ Infineon Technologies AG MP PD PDE MUC/10.2.236 AP 3 Am Campeon 1-12 D-85579 Neuebiberg Phone: +49 (0)89 234 20108 Fax (PC): +49 (0)89 234 955 5305 E-mail: radovan.vuletic@infineon.com |------------------------------------------------------------------ |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 |------------------------------------------------------------------ |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 1993Received on Thu Mar 23 13:53:51 2006
This archive was generated by hypermail 2.1.8 : Thu Mar 23 2006 - 13:54:32 PST