[ibis-macro] Re: observations regarding dependency table BIRD 150
- From: <fangyi_rao@xxxxxxxxxxx>
- To: <msteinb@xxxxxxxxxx>
- Date: Tue, 4 Dec 2012 10:19:54 -0700
Mike;
Thanks for the review on the history of dependency table. My main concern is
future scalability, extensibility and flexibility, and I think a new dll
function is the right approach to assure them.
Regards,
Fangyi
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Saturday, December 01, 2012 7:56 AM
To: RAO,FANGYI (A-USA,ex1)
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: observations regarding dependency table BIRD 150
Fangyi-
As I understand it, your argument is that there are problems that a dependency
table can't solve, and so we should drop the whole idea and instead work on a
solution that is completely general. Have I understood you correctly?
I believe what we have here is what I like to call an :"ontogeny recapitulates
phylogeny" problem. The phrase originally came up as a Biology theory that the
development of an individual from a given species goes through all the stages
of development that the species itself went through. Thus, a human fetus starts
out looking like a bacterium, then looks a lot like a pig fetus, then looks
more like a monkey fetus, and eventually looks like a human being. Although
this theory is no longer widely held among Biologists, I do find that it
applies to the evolution of engineering solutions in the sense that in order to
understand a given engineering solution, it helps to understand all of the
earlier permutations that solution went through. I therefore believe it would
be useful to trace some of the permutations the dependency table solution went
through.
Back in 2009 when we started working on the problem of EDA tool parameters that
depend on AMI model parameters, the first idea that Adge Hawes and Walter Katz
came up with was the same one you're proposing now: an additional translation
function in the DLL or shared object library.
1. At that time, the idea of an additional library function was not appealing
because it would require an extension of the IBIS-AMI API, and would require
that a new function be compiled, tested, and distributed for each new model.
This was an additional step in that as it was (and is) possible to distribute a
single DLL or .so file and then customize it using AMI files that could be
distributed separately. The AMI is a very portable text file, and thus requires
less support than a compiled library. If the solution could be implemented in a
text file such as the AMI file, it would be easier to support a library of
models.
2. Adge and Walter then considered the possibility that the AMI file could
contain programming in the form of some interpreted programming language such
as Basic, PERL, or Python. They rejected this idea, however, because they
believed that adapting even an existing language for inclusion in an AMI file
would be too complex a task to work through a standards body.
3. When Walter came up with the idea of a dependency table, that was a bit of
breakthrough. Here was a text-only solution that was easy to understand, easy
to use, and was sufficiently general to do all of the things we really needed a
solution to do. It wasn't as general or flexible as the solutions we had
previously considered, but it was more than good enough, and it was eminently
practical.
4. In 2010, we offered this solution in several publicly available documents:
first in Opal(tm) and subsequently in a BIRD submitted to the IBIS ATM
subcommittee.
5. From 2010 onwards, we have used dependency tables to offer optional
extensions to IBIS-AMI models. All of those models were fully compliant with
IBIS 5.0 and used the constructs in that standard as effectively as possible,
but were more accurate if used with the optional extension. Our experience with
dependency tables now extends over a number of years and at least a dozen
models from at least a half dozen IP suppliers. In each and every case, the
dependency tables have given us the capabilities that we actually needed to get
the job done.
6. From our experience with dependency tables, we've come to appreciate some of
the detailed capabilities that need to be part of any solution to this problem.
Most importantly, we've come to realize that the EDA tool needs to know which
parameters are independent and which ones are dependent, so that it can display
to the user only the independent parameters without cluttering the display with
dependent parameters that the user can't change directly anyway.
7. We've also come to recognize that the interpretation of the dependency table
or its equivalent needs to occur very early in the overall analysis flow, and
much earlier than the contents of the DLL or .so file. For example, the
transfer function of the channel cannot be evaluated until the dependency table
has been interpreted. While in principle it would be possible to load the DLL
file at such an early stage of the analysis flow, this would not be as
convenient as interpreting a dependency table at that time. (If one were to
distribute a compiled translation function, would it be desirable to distribute
it in a file that is separate from the rest of the DLL?)
We agree that as a solution, the dependency table has its limitations. However,
it's been proposed to IBIS and in practical use for several years now, it's
proven to provide the capabilities needed in practice, and it's been refined
through the standardization process. Furthermore, the dependency table contains
features such as naming independent vs. dependent parameters that would be
needed in any solution to this problem.
We're willing to participate in pursuing a compiled translation function
solution in the future. We are concerned, however, that defining such a
solution in a standard will be a more complex and time consuming task than may
at first appear. Consider that it's taken at least two and a half years to
bring even a relatively simple idea like a dependency table to its current
state. We won't completely understand the complexity of a translation function
solution until we get into the work (take, for example, my question above about
one file vs. two), and so we can't offer a reliable estimated schedule at this
time. As the old saying goes, "the Devil is in the details".
We therefore suggest that we approve BIRD 150 at this time and then pursue a
more general solution such as the one you propose.
Respectfully yours,
Mike Steinberger
On 11/30/2012 01:02 PM, fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx>
wrote:
Mike;
There are plenty dependency relations that are not covered by the syntax in
BIRD150.
Example 1: jitter is a multi-dimensional function of other parameters, say
equalizer taps. Then we will need to add a new ad hoc syntax.
Example 2: Consider dependent parameter y is a function of two independent
parameters x1 and x2 with x2 being the last independent column. If y needs to
be resolved by Out_Range when x1 <0, but by Out_PWL when x1>=0, then you are
stuck, and need to add another ad hoc syntax.
Example 3: For different interpolation methods (e.g. cubic spline), we need to
add more ad hoc syntax.
Example 4: For different extrapolation methods, more ad hoc syntax.
We can't foresee all the possible dependency variations. A c/c++ function
handles them easily.
Regards,
Fangyi
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
Other related posts:
