[ibis-macro] Re: Deconvolution Options
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 3 Aug 2010 09:24:42 -0700
Walter,
I must disagree.
1) The possibility for a tool to input a Dirac-Delta function to get
the Filter response from the Init function does not make my proposal
equivalent to your proposal "Approve Init_Returns_Filter". These two
proposals are implemented in different ways and operate differently
in the EDA tool as well as in the model. This is like saying that a
motorcycle and a truck are the same thing, because I can get from
point A to point B with either one of them...
2) Arguing over my proposal needing software change is a mute point,
because your proposal requires the same thing, in fact no matter what
we do for IBIS v5.1, it will require a software change, since we are
all in agreement that the input the Tx GetWave will be different, and
the order of the Tx GetWave call and the EDA tool convolution is
reversed.
3) Regarding the necessity of model changes and the deprecation rule,
I need to remind you that an existing spec compliant model will work
the same way in the existing spec as my proposed flow. Please read
the spec carefully and you will see what I mean. No changes are
required from the model, it will give you the same results in the new
flow as it does in the old flow. So my proposed flow does not violate
any of the deprecation rules in IBIS and doesn't require any model
changes to get the same results as in the past.
4) "If the IBIS Version was changed to 5.1, and you proposal was
excepted the model would work incorrectly in simulators that support
5.1, since they would put the wrong (by 5.0 rules) Impulse Response in
the first Impulse Matrix" Dead wrong, it seems that you still don't
understand my proposed flow...
Arpad
========================================================================
________________________________
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, August 03, 2010 11:01 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Deconvolution Options
Arpad,
Actually not. Your proposal was equivalent to
4. Approve Init_Returns_Filter, with requirement that optimizing Rx Init
models implement it.
Pro
Does eliminate problem if model supports it
Con
Forces model makers to implement Init_Returns_Filter in optimizing Rx
Init models.
This may simply move deconvolution problem from EDA Tool to model maker
implementation in DLL.
The reason that 4 is equivalent to your proposal is as follows:
In your proposal, the Impulse response that was to be used for
optimization was to be placed in the copy of the Impulse Matrix, and
that the Modified Impulse response returned in the first impulse Matrix
would be the Impulse Response that the EDA tool put in the first Impulse
Matrix convolved with the Impulse Response of the Filter. If the EDA
tool put into the first Impulse Response a Dirac-Delta function, then
what would be returned would be the Impulse Response of the Filter.
Your proposal would have required existing EDA software to change, and
existing models to change. Please let me remind you of the IBIS
non-deprecation rule: If you change the rev of an IBIS file to a higher
level, then the IBIS file must still be valid. A legal model under IBIS
5.0 only looks in the first Impulse Matrix. If the IBIS Version was
changed to 5.1, and you proposal was excepted the model would work
incorrectly in simulators that support 5.1, since they would put the
wrong (by 5.0 rules) Impulse Response in the first Impulse Matrix.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Tuesday, August 03, 2010 11:25 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Deconvolution Options
Sorry guys, but this discussion makes me feel that
we should have picked my BIRD draft which would
have solved the flow problems without any of these
issues... Reading this list of options I am getting
the feeling that we were lured into something with
nice promises and now that we made the decision to
go with it we are getting hit by the not so nice
reality.
Arpad
======================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, July 30, 2010 8:37 AM
To: IBIS-ATM
Subject: [ibis-macro] Deconvolution Options
All,
Here are the following options, along with what I think are the pluses
and minus of each. I suggest that after discussing these options, the
committee vote their preference, and decide to either incorporate that
preference in the proposed Flow just approved, or as a separate BIRD.
Others in this committee may have additional options. Since this is a
large list of options, I suggest that we all rank order the solutions.
My personal rank ordering is 4, 3, 6, 2, 1, 5, although SiSoft will
accept any of these options.
1. Do nothing, and state that deconvolution may be necessary in
the problem case.
a. Pro
i. No change to proposed Flow just approved
b. Con
i. Can have numerical accuracy problems
2. Approve Init_Returns_Filter.
a. Pro
i. Does eliminate problem if model supports it
b. Con
i. EDA tools will still need to implement Deconvolution if they
want to support optimizing Rx Init models that do not use
Init_Returns_Filter with Tx Dual models
3. Approve Init_Returns_Filter, with recommendation that
optimizing Rx Init models implement it.
a. Pro
i. Does eliminate problem if model supports it
b. Con
i. EDA tools will still need to implement Deconvolution if they
want to support optimizing Rx Init models that do not use
Init_Returns_Filter with Tx Dual models
4. Approve Init_Returns_Filter, with requirement that optimizing
Rx Init models implement it.
a. Pro
i. Does eliminate problem if model supports it
b. Con
i. Forces model makers to implement Init_Returns_Filter in
optimizing Rx Init models.
ii. This may simply move deconvolution problem from EDA Tool to
model maker implementation in DLL.
5. Explicitly do not define a time domain reference flow for Rx
Init models with Tx Dual models (but still allow EDA tools to do what
they want).
a. Pro
i. Removes the word "Deconvolution" from proposed Flow.
ii. Advertises that Dual Tx with Optimizing Init Rx combination is
problematic.
b. Con
i. Advertises that Dual Tx with Optimizing Init Rx combination is
problematic.
6. Do not allow optimizing Rx Init models.
a. Pro
i. Removes the word "Deconvolution" from proposed Flow.
b. Con
i. May not be acceptable to developers of Optimizing Rx Init
models.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
Other related posts:
