All,
The current statement in BIRD 189
If this parameter (Unused_port_termination)is not defined, the EDA tool
may connect terminals to terminations as needed to prevent numerical
instability in simulation (EDA tools are recommended to alert users when
this occurs and document the termination value used). Note that the
terminals remain technically open, and terminations connected by the EDA
tool are intended to approximate open-circuit conditions.
Can be confusing (as indicted by how Andrey interprets it, see below).
We all need to remember that IBIS is an ASCII representation of a model
(I/O model, interconnect model, Touchstone file) based on "measurements"
made on the I/O model or interconnect. "Measurement" here can be based on
actual test bench measurements, SPICE simulations, extraction, .
If the component is sitting on a table in the "dead bug" position, then
technically all of the pins of the component are in open-circuit
condition. As soon as the package is inserted in a board (or the die is
mounted in the package) the model maker has no ideas how the pin (or die
pad is terminated). It is the User/EDA too who knows this.
We continually make the mistake of telling the EDA tool how to use IBIS
models, rather than just describing the format of the data describing the
models and how to generate this data. This is so aptly demonstrated by the
recent debates over BIRD 166 and BIRD 190.
I suggest the following change:
If this parameter (Unused_port_termination)is not defined, the EDA tool
may connect terminals to terminations as needed to prevent numerical
instability in simulation (EDA tools are recommended to alert users when
this occurs and document the termination value used). The terminations
connected by the EDA tool are determined by what the unused component pins
are connected to.
Some other unfortunate statements about how AMI models shall be used are:
System simulations will commonly involve a transmitter (Tx) and a receiver
(Rx) executable model file, each of which may perform filtering in the
AMI_Init function, the AMI_GetWave function, or both (i.e., a "dual"
algorithmic model). In the case of a "dual" algorithmic model, the
filtering functionality in the AMI_Init and AMI_GetWave functions are each
intended to be independent representations of the device's equalization.
Users of a dual model can elect to use either the AMI_Init or AMI_GetWave
filtering functionality, but not combine both simultaneously.
While the primary purpose of the AMI_Init function is to perform the
required initialization steps, it may also include LTI signal processing
algorithms. Therefore, statistical simulations may be performed using the
AMI_Init function alone.
Even though time domain simulations may also be performed with the LTI
AMI_Init and/or LTI AMI_GetWave functions, AMI_GetWave functions
containing non-LTI algorithms may only be simulated in the time domain.
How does a User or EDA tool know that a models AMI_GetWave is LTI or
non-LTI. No AMI Model can be perfectly LTI, so who makes the judgment that
a AMI Model can be used as an LTI model? Even if a model is truly LTI, it
is straightforward for a model make to include an AMI_GetWave as a
convenience for EDA tools when doing time domain simulations with other
models in the channel that have an AMI_GetWave - this eliminated
deconvolution steps.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
From: Matvienko, Andrey [mailto:andrey_matvienko@xxxxxxxxxx] ;
Sent: Thursday, July 20, 2017 11:45 AM
To: Walter Katz <wkatz@xxxxxxxxxx>
Subject: RE: [ibis-interconn] Re: Question about references in BIRD189
HI Walter,
Thanks for comments. Yeah, with the current requirement currently put in
BIRD (requirement for open-circuit approximation for unused port) the only
reasonable thing is exactly "ignore all of the rules on how to deal with
unused terminals" :)
Btw I don't try to "blame" nobody, by some reason I myself noticed it only
yesterday, at that I have been reviewing this BIRD quite regularly as it
has been evolved. Yesterday I was literally shocked finding that we sort
of "enforce" open- circuit for unused ports in this BIRD, by default. We
also have been using "advanced package" features in our tools almost
"forever" (our solution have been based on extensions to IBIS external
circuit) so we are very well familiar with topics of terminating of unused
ports and of course we will continue doing it properly despite of direct
"recommendation" to use open-circuit in the BIRD.
Still I think that that controversial require would be removed from the
spec.
Thanks,
Andrey
