Again, please see #3.
Fangyi
*From:* Walter Katz [mailto:wkatz@xxxxxxxxxx]
*Sent:* Thursday, November 29, 2012 7:29 PM
*To:* RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
*Subject:* RE: [ibis-macro] observations regarding dependency table
BIRD 150
Fangyi,
Again, I ask the question:
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?
Walter
*From:* fangyi_rao@xxxxxxxxxxx <mailto:fangyi_rao@xxxxxxxxxxx>
[mailto:fangyi_rao@xxxxxxxxxxx] <mailto:[mailto:fangyi_rao@xxxxxxxxxxx]>
*Sent:* Thursday, November 29, 2012 10:05 PM
*To:* wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
*Subject:* RE: [ibis-macro] observations regarding dependency table
BIRD 150
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
