[ibis-macro] Re: observations regarding dependency table BIRD 150
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 4 Dec 2012 16:42:16 -0500 (EST)
. and Todd's response makes three: the impetus behind the development of
Dependency Tables had nothing to do with non-LTI model behavior.
It had to do with, well, Dependencies (sorry - couldn't resist).
Todd ;-)
Todd Westerhoff
VP, Software Products
Signal Integrity Software Inc. . www.sisoft.com
6 Clock Tower Place . Suite 250 . Maynard, MA 01754
(978) 461-0449 x24 . twesterh@xxxxxxxxxx
"I want to live like that"
-Sidewalk Prophets
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, December 04, 2012 11:42 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: observations regarding dependency table BIRD 150
Hello Everyone,
I am sensing two categories of issues here.
One is the question of interpolation, how many variants are
we defining and whether different tools will give the same
results. This could be solved easily by removing the
interpolating column types and keep the rest.
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? 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 and this
is what the Dependency Table wanted to simplify and beautify.
But there is a completely different aspect to this. If we look
at the real reason for why we need so many dependent parameters,
we could say that this is needed mostly because there are non-LTI
effects in the models. For example, if the analog model is LTI,
we wouldn't need a table of impedances which depend on the voltage
swing values, etc. Shouldn't we fix the real problem and address
the non-LTI challenges instead of applying band aids to the
symptoms?
Thanks,
Arpad
====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
radek_biernacki@xxxxxxxxxxx
Sent: Friday, November 30, 2012 1:03 PM
To: msteinb@xxxxxxxxxx; 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] On Behalf Of Mike Steinberger
Sent: Friday, November 30, 2012 10:22 AM
To: 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 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
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]
Sent: Thursday, November 29, 2012 10:05 PM
To: wkatz@xxxxxxxxxx; 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
Other related posts:
