> SI List,
>
> About this IBIS thing....
>
> There is one other drawback (as compared to SPICE) of TODAY's IBIS
> modeling options... mutiple coupled transmission lines....
>
> As of the present IBIS specification, there is not a method of defining
> multiple coupled line connector or PC board L,C, k matrices... Some IBIS
> solver vendors do provide vendor specific solutions... but as of yet there
> is not a "standard" method for multiple couple transmission lines such as
> those found on PC boards and connectors....
>
> Yes, it is possible to describe 1st order LC effects in the current IBIS
> specification... which may (or may not) be good enough for semiconductor
> package models or PC boards... I let you be the judge for your
> application. But, if you need LC (and k) for greater than a single
> adjacent line (i.e. a connector) you might want to better understand what
> the present version of IBIS leaves out....
>
Few clariffications:
IBIS is a behavioral data container and not a simulator. So comparing IBIS and Spice does not make sense. However you can have macro model implementations in Spice which utilize IBIS data. You can compare the results of these macro models with their transistor structural model counterparts.
The primary motivations for IBIS standard are:
1. IBIS contains behavior data and does not reveal structural details which are more likely properietary. It makes it much easier for manufacturaers to disseminate accurate model data.
2. IBIS data is a neutral standard while structural transistor parameters are, in actual practice, simulator dependent.
3. Macro model implementations of IBIS data are more efficient than their structural counter parts. They are suited for both design exploration and verifications which may require hundreds or thousands of simulations.
Also note IBIS standard is evolving (version 2 is current and version 3 is in the pipeline). With proper formulation the behavioral data can evolve to include complicated behavior like feed back.
A note about package models:
IBIS format provides data holder for package data in the form of lumped LC matrices. Version 3 will add support for "large" interconnets which can include transmission lines and distributed passive L and C but as noted no coupling yet. These passives are not peculier "IBIS" beasts and you should be able to include it in standard Spice simulations.
Alternatively if you already have spice models (including coupled transmission lines) for these packages, some vendors (e.g. like us Cadence's Signoise) will allow you to drop these in as part of the device model.
- kumar
> Now, this leads to another bit of not so good news, multiple coupled
> transmission line models (if they consist of an LCk matrix from a feild
> extractor) are generally quite larger..... These "passive" components will
> greatly extend the solve times..... I have not been able to do comparisons
> between SPICE or IBIS yet.... I do beleive that once the coupled line
> spec. is finalized, this comparison might prove very interesting.... I do
> believe it is possible that the solve times will be VERY vendor
> dependent.....
>
> Also, I'd like to take a moment to say that I am not involved with the
> creation of IBIS solvers.. .. so I'm really out of my inference space.....
> but I beleive (please correct me here if I am wrong) that the algorithhms
> used to process the IBIS "passive" component model information are vendor
> dependent (when not using a SPICE based solver)..... if this is true...
> users of IBIS mods will need to understand EACH IBIS solver... and maybe,
> IBIS model accuracy for "passive" components might be solver dependent.....
> :(
>
> Good news is that there will be a face to face meeting of the IBIS
> committee around January 20th... and there are teleconferences for the
> IBIS committee that are generally held once a week to ince every other week
> (so the IBIS committee is actively trying to resolve the coupling issue)
>
>
> My opinion is presently equiv. to that of Fred Balistreri:
>
> >... lastly because of the above and more I would tend not to trust IBIS
> >models at 100Mhz or above. There are some redeeming factors to IBIS. >If
> one can get the IBIS models it is a good starting point to at least check
> >the designs in a rather fast manner. The data can be incorporated into a
> >higher level simulator as mentioned previously. Again accuracy is the
> >key. Crosstalk at the hundreds of millivolt levels is ok with IBIS.
> Critical >timing and ground bounce issues need to be resolved by using a
> more >robust model such as Spice transistor level.
>
> if someone needs better than 100 mv level crosstalk resolution a SPICE
> solution and model might have an edge... ..
>
> Best Regards,
>
> Gus Panella
> [email protected]
>