[ibis-macro] Re: observations regarding dependency table BIRD 150

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Tue, 04 Dec 2012 11:31:02 -0600

Arpad-

Please be aware that for a tranmitter, both the output impedance and the output wave shape are usually both a function of the swing setting. This is the case regardless whether the model is LTI or not. Therefore, your last paragraph is based on a premise that is entirely false, and can be easily proven false from measured data.

There are both nonlinear and time varying behaviors in high speed serial channels that do need to be addressed; however, they are not in the analog channel unless that channel has very low loss. On the rare occasions when we've observed nonlinear effects in a lossy analog channel, those effects have been so small as to be negligible.

Hope this helps.
Mike Steinberger

On 12/04/2012 10:42 AM, Muranyi, Arpad wrote:

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> [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: