Hello Arpad, thanks for your very good feedback. This answered my questions! sorry for the delay, but I was on business trip .. Hermann Our next Events: ================ Visit us on Embedded World 2012 Our location Hall 1 / Booth 509 "Open the Black Box of Signal Integrity" Seminar on 07. May 2012 "Open the Black Box of Memory" Seminar on 09/10. October 2012 Check our website or contact us for details EKH - EyeKnowHow Hermann Ruckerbauer www.EyeKnowHow.de Hermann.Ruckerbauer@xxxxxxxxxxxxx Veilchenstrasse 1 94554 Moos Tel.: +49 (0)9938 / 902 083 Mobile: +49 (0)176 / 787 787 77 Fax: +49 (0)3212 / 121 9008 schrieb Muranyi, Arpad: > Hermann, > > Theoretically, IBIS was intended to provide a complete > model for a chip (or "[Component]", as IBIS calls it). > As you stated, quite often people would only make a > subset for that for a certain interface. Less frequently > people might put multiple [Component]-s into the same .ibs > file. There is nothing in the specification that makes > these "habits" illegal. > > Regarding your question: > > "My understanding was, that this was the intention of the [Package] > definition." > > The intent was that the [Package] keyword would describe the > typ/min/max package parasitics of the [Component] and the > itemized values in the [Pin] list would give you the detail > for each individual pin. Note that this was the intent for a > [Component]. If someone decides to put a subset of the entire > device under the [Component] keyword, it would make sense to > derive the typ/min/max values in [Package] for only what is > included in the [Component] and not the entire device, but > the IBIS specification doesn't spell out any rules on this. > So this is left up to the model maker's best judgment. However, > I would encourage that the model maker should document what they > did in the model so that the users would have a better understanding > of what they got in that model. > > Regarding your observation that "In this case the global > [Package] parameter does not make sense any more", you are > correct, it doesn't. But IBIS doesn't say that you must use > that [Package] data. The hierarchy of package modeling in IBIS > is such that the better package descriptions override the less > accurate descriptions. I am not sure why we made the [Package] > keyword required, even if it is useless, but that's a rule. > But you can always put zeroes into the typ values of [Package]... > > When the [Package] keyword was defined for the specification, > the thinking was that the manufacturing tolerances of the > packages are so small that they can be neglected. The idea > of using typ/min/max on the [Pin] list was therefore not > put into the specification. The purpose of typ/min/max in the > [Package] keyword was to account for the length variations in > the package between a pin in the center or corner of the package. > This was sufficient in the mid 90's when this was defined for > the specification. > > Note that the [Define Package Model] keyword allows for more > detail, but this is also lacking important capabilities, such > as dielectric losses, frequency dependencies, etc... Unfortunately > this area was neglected in the specification and we still do not > have a better way of making IBIS models for packages. I guess > one of the reasons this was not a burning need is that most > simulators allow the user to make S-parameter based package models > and add it in the schematic editor to the design, while zeroing > out all the IBIS package values. But I think it would be beneficial > for the users to be able to have the package model inside the .ibs > file and provide a little more automation in the tools for their > usage. There is a proposal in BIRD 125 which addresses these > problems, and hopefully it will be discussed in the ATM task group > soon. > > So, to answer your questions at the end of your message: > > #1) The model can have 0 NA NA for the [Package] > #2) Depends on what you mean by fast/slow. If you mean fast/slow > across the interface (for example D0-D64) then you can read the > numbers across D0-D64 from the [Pin] keyword. But I would not take > the min L from one pin and the min C from another pin, that doesn't > make sense... On the other hand, if you mean fast/slow for just one > signal, for example D17, then you don't have the information for > the typ/min/max variation of that package trace, because the data > is not there. Any mathematical massaging of that data is just a > guess. > #3) I don't think it would make much sense to add min/max to the > [Pin] keyword. In today's simulations a lumped LRC model is usually > not sufficient. If we did anything with the package modeling in IBIS, > I would propose to do it right, and define mechanisms to use S-parameter > models, and/or W-element style models with dielectric losses, frequency > dependent L/R/C values, and coupling. In addition, we also need to have > the capability to do splits and joins inside the package (i.e. the > number of pads should not have to be the same as pins), and, of course > do this so that typ/min/max could also be defined in the model. I > think all of this is addressed in BIRD 125. > > http://www.eda.org/pub/ibis/birds/bird125.1.txt > > Thanks, > > Arpad > ========================================================================== > > > -----Original Message----- > From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On > Behalf Of Hermann Ruckerbauer > Sent: Saturday, March 17, 2012 3:28 AM > To: si-list@xxxxxxxxxxxxx > Subject: [SI-LIST] IBIS - Worst Case Corner package values > > Hello all, > > it would be great if somebody could help me with a question for IBIS > models (package related). > > In the past I got very often IBIS models that have been specific for any > special interface (e. g. the data bus of a memory Controller). > In the file there are RLC values for each pin individually ([PIN] > KeyWord). In addition there are the global package parasitics that cover > Min/typ/Max values of all the Signals included in the IBIS model > ([Package] KeyWord). Of course there is the additional [Package Model] > possible, but currently I'm talking about an IBIS file that does not > contain this feature. If only the Data bus interface is included the > [Package] min/max values allowed to do a corner case simulation with the > worst/best case values between all Signals of this interface. My > understanding was, that this was the intention of the [Package] definition. > > Over the years this changed and suppliers make IBIS files with all pins > and even different Components in one IBIS file. In this case the global > [Package] parameter does not make sense any more, because it is > containing values that are not related to the specific simulated > signals. E. g. there is one pin that is somehow connected to a plane one > get easily 30pF package parasitics. So for such packages the global RLC > min/typ/max values do not make any sense at all. > For Min and Max values the supplier could use NA in the IBIS, but > according to the spec 5.0 "Typically" must be specified. If this is the > mean value between PCIE, I2C, memory signals, planes ... this should not > be used in any simulation. > > If I'm running now a slow/fast corner case variation the simulator can > take either the [PIN] values, but these would not contain any > Manufacturing tolerances. If it is using the min/typ/max values from the > [Package] definition it might be completely off as it is using the > capacitance of a VDD plane. > > My questions would be: > - How should the models be done in case a complete device model with all > kinds of different interfaces is generated: > - Leave [Package] min/max with NA? What do do with the typical value ? > - How should the Simulator handle Fast/Slow corner case simulation ? > - I expect the package manufacturing tolerances are small, so just > take the given ("mean") RLC per pin ? > - For any Package Corner Case simulation one need anyhow a better > package model > - Would it make sense to include some variation at the per pin package > RLC (e. g. a forth column stating +-5% variation) in the IBIS file ? > This would allow to calculate a per pin Slow/Fast corner value > > Thanks for any feedback and insight how the IBIS model should be handled > in this topic. > > Best Regards > > Hermann > > > Our next Events: > ================ > > Visit us on Embedded World 2012 > Our location Hall 1 / Booth 509 > > "Open the Black Box of Signal Integrity" > Seminar on 07. May 2012 > "Open the Black Box of Memory" > Seminar on 09/10. October 2012 > > Check our website or contact us for details > > EKH - EyeKnowHow > Hermann Ruckerbauer > www.EyeKnowHow.de > Hermann.Ruckerbauer@xxxxxxxxxxxxx > Veilchenstrasse 1 > 94554 Moos > Tel.: +49 (0)9938 / 902 083 > Mobile: +49 (0)176 / 787 787 77 > Fax: +49 (0)3212 / 121 9008 > > > schrieb Peterson, James F (Chief Engineers): >> Hey IBIS Wizards, >> >> Now that our rise times are close to the interconnect prop time between the >> die and the package I/O pin, how does IBIS represent this interconnect delay? >> >> Is the first order approximation of interconnect delay between die and IO >> pin suppose to be L_pin, R_pin, and C_pin? >> >> Is the IBIS "Package Model" the more accurate answer? If so, is there more >> info on this? (also, I don't see this being used much in the IBIS models.) >> >> Thanks. >> Jim Peterson >> Honeywell >> ------------------------------------------------------------------ >> To unsubscribe from si-list: >> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field >> >> or to administer your membership from a web page, go to: >> //www.freelists.org/webpage/si-list >> >> For help: >> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field >> >> >> List technical documents are available at: >> http://www.si-list.net >> >> List archives are viewable at: >> //www.freelists.org/archives/si-list >> >> Old (prior to June 6, 2001) list archives are viewable at: >> http://www.qsl.net/wb6tpu >> >> >> > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > > or to administer your membership from a web page, go to: > //www.freelists.org/webpage/si-list > > For help: > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > > List forum is accessible at: > http://tech.groups.yahoo.com/group/si-list > > List archives are viewable at: > //www.freelists.org/archives/si-list > > Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu > > > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > > or to administer your membership from a web page, go to: > //www.freelists.org/webpage/si-list > > For help: > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > > List forum is accessible at: > http://tech.groups.yahoo.com/group/si-list > > List archives are viewable at: > //www.freelists.org/archives/si-list > > Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu > > > ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List forum is accessible at: http://tech.groups.yahoo.com/group/si-list List archives are viewable at: //www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu