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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
  • Date: Sun, 18 Mar 2012 17:01:45 +0000

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:
> http://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:     
>               http://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:
http://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:     
                http://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:
http://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:     
                http://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: