[ibis-macro] Re: observations regarding dependency table BIRD 150
- From: Kumar Keshavan <ckumar@xxxxxxxxxxx>
- To: "fangyi_rao@xxxxxxxxxxx" <fangyi_rao@xxxxxxxxxxx>, "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 4 Dec 2012 09:24:01 -0800
You have to start separating the language portion (i.e the tree format) from
the ami model (specifically dll). Then thing can fall into their natural
logical place. For example the dependent variable of package model which is
driven by the independent variable , say corner will be done naturally at the
front and will have nothing to do with the dll parameters. For really complex
stuff (think future) , you may want to consider supporting functions with
fixed api and implemented in scripting languages
________________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx [ibis-macro-bounce@xxxxxxxxxxxxx] On
Behalf Of fangyi_rao@xxxxxxxxxxx [fangyi_rao@xxxxxxxxxxx]
Sent: Tuesday, December 04, 2012 12:04 PM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: observations regarding dependency table BIRD 150
Hi, Arpad;
Please see my answers below.
The second topic I hear is whether Dependency Table should
be done by the EDA tool or the model. This is a more
complicated problem, because there are cases when the
analog model parameters need to be synchronized with the
AMI DLL parameters and we treat these two as independent
models. How could a new AMI DLL function tell the analog
IBIS model what it should do?
The new function will be called before the analog channel is characterized. It
returns analog model parameter values and EDA tools will setup/adjust the
analog model accordingly.
I could see this done the
other way around, the analog model telling the AMI DLL what
parameters to use. This can actually be done already by the
[Model Selector] and each [Model] pointing to a different .ami
file, but my understanding is that this is cumbersome
You don’t need to. That’s why “model name” is a formal argument of the new AMI
function. The DLL can resolve parameters based on [Model] and other formal
arguments including bit_time, BAUD rate and corner.
Regards,
Fangyi
====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
radek_biernacki@xxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxx>
Sent: Friday, November 30, 2012 1:03 PM
To: msteinb@xxxxxxxxxx<mailto:msteinb@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: observations regarding dependency table BIRD 150
Hi All,
I believe Fangyi fairly clearly identified one example of potential
inconsistencies: handling the calculated values (from the last column of
independent variables) for checking whether they are equal or not (round-off).
Once the decision is pushed into the model (DLL) there will be no
inconsistencies between different EDA platforms in interpreting the
dependencies.
Furthermore, I have a feeling that trying to impose any specific interpolation
(even one-dimensional) algorithmic requirements on all EDA vendors might not be
feasible.
Radek
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Friday, November 30, 2012 10:22 AM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: observations regarding dependency table BIRD 150
Fangyi-
You have stated your opinion, but you have not proven your case. For those of
us sitting at the other end of the e-mail chain, there is a difference. Simply
restating your opinion doesn't add any information to the conversation.
Perhaps it would help if you could expand your assertions into a chain of
reasoning that more nearly resembles a mathematical proof.
Respectfully yours,
Mike Steinberger
On 11/30/2012 12:10 PM, fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx>
wrote:
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<mailto: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.
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 …
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
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.
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
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
