[ibis-macro] Re: Fundemental concerns over the the new AMI flows that have been introduced since March.
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: "Walter Katz" <wkatz@xxxxxxxxxx>, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 28 Jun 2010 14:00:59 -0600
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
Other related posts:
