[ibis-macro] Re: Fundemental concerns over the the new AMI flows that have been introduced since March.
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 28 Jun 2010 16:16:07 -0400
Vladimir,
And what test input would you apply to hAC(t)xhTEI(t)xhREI(t) to get
hREI(t)?
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: Dmitriev-Zdorov, Vladimir [mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx]
Sent: Monday, June 28, 2010 4:01 PM
To: Walter Katz; Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Fundemental concerns over the the new AMI
flows that have been introduced since March.
Walter,
I realize that DFE is a non-LTI thing. However, the original problem stated
in your earlier email: ".would have to determine hREI(t) by the
deconvolution of hAC(t)xhTEI(t)xhREI(t)/hAC(t)xhTEI(t)" assumes that hRei(t)
exists in a certain LTI manner and once it does exist, there is a
possibility to find appropriate test input to extract it directly.
If the original assumption were different, i.e. no REI(t) could be found
that appropriately characterizes DFE, then yes, my proposal wouldn't work
either. But we cannot say 'yes' to one and 'no' to the other since the
existence of linear response or our assumption on its existence necessitates
the possibility of its extraction by way of applying a *certain* test input.
My point is that the AMI developer has enough data to easily construct such
a test input.
Having said that, I'm not sure the example with DFE is quite relevant to the
preceding discussion about deconvolution.
Vladimir
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 28, 2010 1:40 PM
To: Dmitriev-Zdorov, Vladimir; Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Fundemental concerns over the the new AMI
flows that have been introduced since March.
Vladimir,
Because the filter may not be built. Take the example of a DFE. The waveform
at the decision point is the analog waveform that is built by from the
Tx_Stimulus, Channel, Rx LTI equalization plus an equalization waveform
which might be a linear three tap filter that is applied to a digital signal
generated from the sampled signal at the decision point.
What is the filter that applied to the signal at the Rx Pad will give the
sum of these two waveforms at the decision point.
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 Dmitriev-Zdorov,
Vladimir
Sent: Monday, June 28, 2010 3:11 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: [ibis-macro] Re: Fundemental concerns over the the new AMI flows
that have been introduced since March.
Why the problem finding REI(t) inside Rx AMI without deconvolution?
Once the filter is built, and believed linear, the developer can apply a
short test input to this filter (inside AMI Init) and get the required clean
output.
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 28, 2010 12:26 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Fundemental concerns over the the new AMI flows
that have been introduced since March.
Walter,
Thanks for the explanation. This example makes me feel
that the carrot is held in front of my nose on a stick
and no matter how fast I run, I will never be able to
reach it.
First it was having to find a flow that doesn't use
de-convolution. When I thought I solved that, it
was to find a flow that also supports optimization
in the Rx AMI_Init function. Now that I thought I
figured that out, it is to find a flow that also
supports DFE in the AMI_Init function (which up to
now I thought was only supposed to be done in GetWave).
I wonder if I could miraculously find a solution for
even this one, what would be the next challenge that
would be brought up...
Regarding "This algorithm does not compute hREI(t) directly, but
computes ~hAC(t)xhTEI(t)xhREI(t). So if the Optimization Matrix contains
hAC(t)xhTEI(t)), and the Data Matrix contains anything else (e.g. hAC(t)),
then in order to create (hAC(t))xhREI(t)) the DLL would have to determine
hREI(t) by the deconvolution of hAC(t)xhTEI(t)xhREI(t)/hAC(t)xhTEI(t)."
the model maker will has a choice to either revise
their algorithm so that they can operate on hAC(t)
with hREI(t) one way or another, or implement
deconvolution in their model. They have a choice
to find the most appropriate solution they see fit
for this situation if they absolutely need or want
to do DFE in the Init function. My latest flow
proposal does NOT FORCE them to do de-convolution,
it it their choice to do so.
Arpad
=======================================================
_____
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 28, 2010 11:26 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Fundemental concerns over the the new AMI
flows that have been introduced since March.
Arpad,
On several occasions Fangyi described an Rx Init model that contains a DFE.
He specifically stated that the algorithm that was used to determine the
optimum DFE equalization had as its input the output of Tx Init
(~hAC(t)xhTEI(t)). The optimization of the Rx is not determining by the
impulse response of just the DFE. The output of this DFE optimization
routine is an approximation using proprietary methods that Fangyi has not
disclosed. This algorithm does not compute hREI(t) directly, but computes
~hAC(t)xhTEI(t)xhREI(t). So if the Optimization Matrix contains
hAC(t)xhTEI(t)), and the Data Matrix contains anything else (e.g. hAC(t)),
then in order to create (hAC(t))xhREI(t)) the DLL would have to determine
hREI(t) by the deconvolution of hAC(t)xhTEI(t)xhREI(t)/hAC(t)xhTEI(t).
If the Rx had an optimizing FFE filter, then calculation the impulse
response of the FFE filter is straightforward, but DFE equalizers do not
apply there tap coefficients directly to the incoming signal, but to a
digital signal that is created from the digital sampled data and then used
to update the analog signal that is being sampled.
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: Monday, June 28, 2010 11:53 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Fundemental concerns over the the new AMI flows
that have been introduced since March.
Walter,
I do not understand why you say that my latest proposed flow
"in fact does not eliminate the need for deconvolution, it just moves it
from the EDA
platform to the AMI model AMI_Init function, and makes existing models work
incorrectly".
Existing models (which have optimization in Rx AMI_Init) work
incorrectly in the existing spec, and my proposed flow doesn't
fix that problem. Such models will have to be changed to work
properly. But my proposed flow provides a way for a solution,
while the existing spec doesn't.
But I am completely lost about why my latest flow proposal
moves the de-convolution to the model from the EDA tool.
That was not my intension, and I don't see how that would
be necessary. Please explain what you mean.
Thanks,
Arpad
=================================================================
_____
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 28, 2010 8:13 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Fundemental concerns over the the new AMI flows
that have been introduced since March.
All,
Sorry, this is an important e-mail thread, and it unfortunately had the
wrong subject.
SiSoft is totally opposed to the Flows that have been developed by the
IBIS-ATM committee since the 4:3 vote to reject the Flows developed last
November. SiSoft's position is that the Flows agreed to last November are
correct, and will support them being modified to assume that
Init_Returns_Filter is always False.
Since deconvolution is required in certain circumstances, Arpad has
introduced a Flow that changes the way that the AMI_Init function is called.
This in fact does not eliminate the need for deconvolution, it just moves it
from the EDA platform to the AMI model AMI_Init function, and makes existing
models work incorrectly.
This is an e-mail thread between Arpad and myself on this subject.
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 Walter Katz
Sent: Monday, June 28, 2010 9:01 AM
To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: Question about cross talk with AMI models
Arpad,
Response by paragraph:
P1) You have not changes the signature of the call to the DLL, and found a
neat trick that will cause existing models to not fail with memory
exceptions. But existing models do not know about the second input. They
only know about the first one. If you added a new reserved parameter (e.g.
Dual_Impulse_Matrix) that defaulted to False, but when True said this model
supported the second matrix, this would at least not make existing models
invalid, and the tool can decide what to do based on that switch. This does
not eliminate the need for deconvolution; it just moves it from the task of
the EDA tool to the task of the model. I personally do not want to rely on
AMI model maker to be forced to implement a reliable deconvolution, as we
and several other EDA vendors have. I point out again Fangyi's example of a
DFE model that he developed that the Rx Init function generates a combined
impulse response. He would need to deconvolve in the model in order to apply
the equalization he generated using the Optimizer input to apply the
equalization to the Data Input. It is clearly much better to implement
Init_Returns_Filter, with a recommendation that Init_Returns_Filter=True for
models that are capable of reliably determining the impulse response of the
filter alone. But as Fangyi points out, the EDA tool will still need to
support deconvolution because of existing models, and because there will be
some models that are unable to determine this impulse response.
P2) The whole flow in 2.3 was perverted due to the Analog Input to the Tx
GetWave. Once the input to Tx GetWave included the both the hAC(t) and the
hTEI(t), then LTI was required, and as one see in more detail, optimizing Rx
was not allowed - the unintended consequences are really nasty aren't they.
P3) BIRD 107 (excluding the perverted paragraph 2.3) only direct the EDA
tool to modify the input to Tx GetWave (violates non-LTI Tx GetWave), and
the input to Rx GetWave. It does not direct the EDA tool to modify the input
to Rx Init based on its value.
P4) But your flows give different impulse response in the Data Input
section. Since existing models do not know about the Optimizer Input, and
since the EDA tool has no way of knowing if a model is 5.0 or your new
method, existing models will not work correctly. This is serious and
unacceptable.
P6) Reconsider applying what you propose to EXISTING AMI models.
P7) Again, reconsider applying what you propose to EXISTING AMI models.
P8) My intention would be to present it directly to the Open Forum and call
for a vote at the earliest allowed time.
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: Monday, June 28, 2010 2:09 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Question about cross talk with AMI models
Walter,
I will answer your email paragraph by paragraph, indicated by
a letter "p" for "paragraph" (not page).
p1) I know that the Rx AMI_Init function needs a modified
channel impulse response from Tx AMI_Init for its optimizer
(if it has any). This is what the second input to Rx AMI_Init
is doing in my latest proposed flow. It is there in the
proposed flow, it works exactly the way you want it to work.
p2) Regarding analog vs. digital input, I thought the issue
was the input to Tx GetWave, not to Tx AMI_Init. You are
now talking about Tx AMI_Init. I hope this is only a typo...
Assuming it is a typo, my proposed flow addresses this also.
Read Section 2.4 Step 5 in the proposed BIRD (Flow_BIRD_2e.pdf).
So by fixing this and by fixing the Use_Init_Output logic
in the proposed flow, we should end up with a logical spec,
correct?
p3) That is not stated anywhere in the spec or BIRD 107.
SiSoft was a co-author of both... In this area I tend to
agree with Bob, that slapping together a specification in a
big hurry tends to result in a lower quality spec and we
are reaping the consequences of that. I am not saying that
I enjoy dragging out the discussions and argue over
meaningless topics, but certain things must be hammered
out and written down unambiguously in the spec. We can't
expect people to guess what was going through the minds
of the authors years later from ambiguous text to find
out what the intent was...
p4) My proposed flow does exactly that. Please look at
slides 1-4 and 5-8 and tell me if you see any difference
in the way I drew the Rx AMI_Init box. I might need
better glasses, but I don't see any differences, and while
my memory is not perfect at times, I don't recall drawing
them differently either...
p6) I am not proposing what you say I propose. Please
spend a little more quality time with the flow diagrams
and the draft BIRD in which I think I made it crystal clear
what I am proposing. (In my latest flow and BIRD draft
the input of your Rx model doesn't depend on how the Rx
GetWave function is written, and there is no mention of
a Dirac-Delta function anywhere in my documentation.
I just had to stop to think to spell it right...). But
in case I didn't succeed in getting across what was in
my mind at the time I wrote it, please point out the areas
which need better wording or drawing.
p7) Both of those issues have been addressed in my latest
flow proposal and BIRD draft. It is stated in Note #2 in the
flow diagram and also in the BIRD draft that when GW = F both
IRI and UIO must be T. This is effectively the same as ignoring
UIO, because when you ignore it you actually act as if it was
set to TRUE. And the input to Rx AMI_Init always gets the
modified Tx AMI_Init output in the second impulse_matrix,
regardless of whether you are in a statistical simulation or
time domain simulation or what the settings of the Boolean
switches are.
p8) I don't see why you feel that you have to write another
BIRD, since you have not mentioned anything yet about my latest
flow proposal and BIRD draft that doesn't work correctly with it.
However, if you feel compelled to write one, you are certainly
welcome to do so. Considering our track record, I predict that
it might take another few months to discuss it, which I expect
will get all the IC vendors even more turned off regarding what
is going on in the ATM meetings. On the other hand, if you feel
confident about it, you may submit it to the IBIS Open Forum
directly.
Sincerely,
Arpad
=================================================================
_____
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Sunday, June 27, 2010 1:37 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Question about cross talk with AMI models
Arpad,
The whole logic of the existing 2.3 is flawed, period end of story. In order
for an Rx Init function to properly work, it must have the impulse response
of the channel modified by the Tx equalization, if available. There can be
no other logical explanation. How else is an Rx Init function to optimize
itself? We always new the logic in 2.3 was flawed, and we repeatedly said so
during the discussions of BIRD 107.
Yes the current spec is incorrect and is in error, deprecation does not mean
that there cannot be errata, and this is currently errata material. The
existing 2.3 is clearly full of errors because of the introduction of the
analog instead of digital input to Tx Init. Complicating this fundamental
error in IBIS 5.0, the logic of Use_Init_Output was put into the flows in a
totally illogical way to because analog input to Tx GetWave was totally
illogical to begin with.
When Use_Init_Ouput was introduced, it was only to be used when
GetWave_Exists was True. It had no meaning when GetWave_Exist was False!
Please remember that when Rx Init is being called, it does not know if it is
being used in a statistical flow or in a time domain flow. Since it does not
know what flow the EDA tool is attempting, it must behave identically the
same way in both cases; it must have the same inputs and the same outputs.
Let me give you a simple gedankenexperiment.
Suppose I had a channel with an hAC(t) with significant loss and
impairments. I can easily create a Tx model that will absolutely correct for
all channel impairments, and the output of the Tx model will generate a
perfectly equalized waveform at the Rx input. (No, this will not make me
rich, I can create a Tx model in C++, but implementing this in silicon is
another story.) You propose that in some cases (depending on how the Rx
GetWave is written, and what flow I choose to make), the input to my Rx
model will either be hAC(t), or a Dirac-Delta function.
So the error in IBIS 5.0 (and it is an error that needs to be corrected), is
that if GetWave_Exist is False, the EDA tool is instructed to ignore the
value of Use_Init_Output, and the input to Rx Init must always be the
channel modified by the Tx equalization (i.e. the output of Tx Init).
You leave me no other choice then to prepare an independent BIRD to deal
with this.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com <http://www.sisoft.com>
Other related posts:
