[SI-LIST] Re: IBIS - Worst Case Corner package values

  • From: Hermann Ruckerbauer <hermann.ruckerbauer@xxxxxxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Tue, 20 Mar 2012 17:33:00 +0100

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
  

Other related posts: