Arpad,
Although not limited to the AMI Parameter Tstonefile, it is the only real
problematic example of the reason for the Out, InOut BIRD that has been
discussed in the 10 years history of AMI modeling. I point out that in
section 10.1, IBIS says:
"The "analog" portion of the channel is characterized by means of an
impulse response leveraging the IBIS constructs for device models defined
in Sections 6.1, 6.2 and 6.3."
Therefore, if a model maker supplied an IBIS file and AMI model that
requires an on-die S-Parameter model, then unless that on-die S-Parameter
model is included as an IBIS-ISS subckt in the [Model] [Executable Model]
section of an IBIS 6.0 file, the [Model]/AMI Model is clearly
non-compliant.
The In InOut BIRD wants the model advertise that it is using the AMI
Parameter Tstonefile in a non-standard way to notify the User and the EDA
tool that a Touchstone file is required to be used to generate an impulse
response of the channel:
Should we also want the model advertise that IBIS analog [Model] is not
sufficient to generate a useful impulse response of the channel?
I therefore propose amending your In InOut BIRD to includes an new
[Algorithmic Model] IBIS subparameter IBIS_Analog_Model_Incomplete this
advertises to the User and EDA tool that the EDA tool should use another
analog model not included in the IBIS [Model] to generate the impulse
response of the channel.
I know the horse is out of the barn already on this, but I think this
should make it clear to model makers that the intent of the IBIS standard
is for IBIS to be a complete description of an I/O Buffer model, and the
model maker should make it clear in a documented way when an IBIS model is
not a complete description of an I/O Buffer model, and that therefore
different EDA tools may present different results.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
