[ibis-macro] Re: observations regarding dependency table BIRD 150
- From: <fangyi_rao@xxxxxxxxxxx>
- To: <wkatz@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 29 Nov 2012 20:05:06 -0700
Walter;
My comments are inserted.
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.
FR> see my proposal in #4
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.
FR> see #4. The new function will be called before analog channel impulse
characterization.
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.
FR> I don't see why the simulator can't access the DLL before impulse
calculation.
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.
FR> see #3
Regards,
Fangyi
Other related posts:
