[ibis-macro] Re: observations regarding dependency table BIRD 150
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <fangyi_rao@xxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 29 Nov 2012 21:53:06 -0500 (EST)
Fangyi,
Comments bellow.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Thursday, November 29, 2012 5:59 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] observations regarding dependency table BIRD 150
IBIS Experts;
I'd like to share my observations on dependency table proposed in BIRD
150.
1. Why do we need dependency table? If the dependent variables are
model specific parameters, then these parameter are redundant. They should
be internal to models and resolved inside models. They should not be
exposed to model users in the first place. The only sensible dependent
variables are reserved parameters.
WMK> I essentially agree. They are currently being used to define Jitter
parameters and analog parameters such as impedance, voltage swing,
Touchstone file. Some of these parameters are becoming reserved
parameters, and some will be passed to the EDA tool through mechanisms
similar to those described in BIRDs 116 .
2. The multi-dimensional independent variable syntax is, in my view,
too specialized and not a true multi-dim solution. It only allows
interpolation of the last independent variable column. It may fit one
vendor's need, but is too limited to address general multi-dim dependency.
WMK> Single dimensional range, closest and PWL is what is currently needed
and used in a number of AMI models. Multi-dimensional interpolations is
very difficult to document and implement for both IC Vendors and EDA
tools. If you think multi-dimensional interpolation is useful and required
then I suggest you propose a method to define it, and document it.
3. Fundamentally, resolving parameter dependency, even for reserved
parameters, is a job that belongs to models. Asking EDA tools to perform
this task for models is not a good practice and can easily lead to
inconsistency (e.g. round-off and interpolation method) and loss of
flexibility, as we already saw in the multi-dimensional independent
variable case. Dependency relations have too many variations to be
standardized within a simple syntax. It's better to leave them to models.
Ad hoc standardization will open doors to many problems in the future.
WMK> How do you propose telling the model what analog parameters to use to
generate th impulse response of the channel when these analog parameters
are a function of the programming of the model.
4. Resolving parameter dependency can be done much more cleanly and
flexibly by introducing a new AMI function, say AMI_Resolve. In this
function models will resolve and return reserved parameters to simulators.
Bit-time, BAUD rate, corner and model name can be formal input arguments
to the function and there is no need to introduce the confusing "intrinsic
parameters".
WMK> Then I suggest you submit such a BIRD, and then we can have the user
community (IC Vendors and Users of IBIS models) decide if they what to
complicate the ami DLL with an additional entry, and the additional cost
of maintaining the DLL. Also, please note that this will require the
analog simulator to access the DLL to determine the analog model to use to
generate the impulse response.
WMK> Finally, although there are many ways to skin a cat, what is wrong
with what I have proposed and what problems are you trying to solve that
are not are not being solved by my proposal.
Regards,
Fangyi
Other related posts:
