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 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] *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 150Fangyi-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 SteinbergerOn 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 150Fangyi, 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 150Walter; 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 #4Fundamentally, 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
