Walter,
Regarding:
"TWMK> the order of convolutions do matter if any of the blocks is not LTI. An
Rx with DFE is not LTI.",
Up until now I was under the impression that the statistical flow was an "LTI
flow",
and the GetWave flow was where we had non-LTI capabilities. When did that
change?
Regarding:
"WMK> Not true. It, in fact, corrects the statistical flow answers. The time
domain answers are problematic when one of the models has AMI GetWave=False,
and correct that flow by generating a correct time domain waveform by ignoring
all of the AMI GetWave."
For one, I don't think we agreed to the "by ignoring all of the AMI GetWave"
part of BIRD166 yet
in the ATM discussions. Second, these are the cases ("The time domain answers
are problematic")
which I was referring to that are made worse by BIRD166... So "Not true" is
actually true as far as
I can tell...
Are you going to be able to attend the ATM meeting tomorrow? It would be good
to finally get
over this debate, and come up with a decision...
Thanks,
Arpad
============================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 1:34 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Response to BIRD-190
Arpad,
See comments below:
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, June 19, 2017 2:25 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Response to BIRD-190
Walter,
Regarding:
"Do you disagree with my proof that BIRD 190 and IBIS 6.1 gives the wrong
answer for statistical flow in this case when all of the models have
Init_Returns_Impulse=True?"
At this point I can't answer this question because I don't fully understand
what you are
saying. I thought that in the statistical flow we only do convolutions (not
summations),
and being an LTI flow, the order of convolutions did not matter (other than the
changes
in the settings due to optimization results, if there are any). But I will
need to study this
some more...
TWMK> he order of convolutions do matter if any of the blocks is not LTI. An Rx
with DFE is not LTI.
Regarding:
"Does anyone disagree that we should not put into the standard any flow that
WILL give the wrong answer?"
I think no-one disagrees with that. And I think that is the reason for the
reluctance
towards BIRD166, since it introduces wrong answers in some cases which didn't
have
the wrong answers before...
WMK> Not true. It, in fact, corrects the statistical flow answers. The time
domain answers are problematic when one of the models has AMI GetWave=False,
and correct that flow by generating a correct time domain waveform by ignoring
all of the AMI GetWave.
Sorry to repeat myself, but the fundamental problem I see here is that we have
conflicting requirements, and BIRD166 alone can't solve them all. As a result,
we go
around in circles trying to prove which BIRD would be more acceptable than
another
BIRD, while none of them really solve ALL of the problems. One person wants to
solve
this problem, the other person wants to solve that problem, and ultimately the
argument becomes which problem is more important to solve. Since we can't seem
to agree on that, we keep going around in circles.
As I said before, BIRD190 doesn't attempt to solve any technical problems, it
just
documents the current state of the art, raising awareness to the issues which
exists in the spec. That's better than leaving the reader/model maker
uninformed.
BIRD166 seems to try solving some technical problems, but it does so at the
expense
of introducing other technical problems, some of which did NOT exist before. Is
that desirable? Also, if we are planning to address the problems with a real
solution
at a later time, we should be careful to NOT add "temporary fixes" to the spec
now
in a way that makes the full solution harder to add/support. I stated many
times in
the ATM meetings that I would only support BIRD166 if it can be an incremental
step
towards a complete solution added on later. I do not want to add something to
the
spec now that will have to be undone when we implement the full solution. If
you
can make BIRD166 a subset of Fangy's "full solution" proposal, I would have
nothing
against it. I just don't want it to get in our way later, or let it add more
varieties of
flows and unnecessary complexities.
WMK> I disagree with this because of my previous comments.
Thanks,
Arpad
==================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, June 19, 2017 11:38 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>;
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Response to BIRD-190
Arpad,
I have demonstrated that BIRD 190 fails to give the right result when all
models have Init_Returns_Impulse=True.
If any model has Init_Returns_Impulse=False, then Init processing requires
that EDA tools generate an AMI_Init proxy using AMI_GetWave results, and in
this case BIRD 190 gives the wrong answer.
Ambrish and Cadence have reputably stated that AMI Models should be Init-Only
or GetWave-Only. So for the case that all of the models are Init-Only then both
IBIS 6.1 and BIRD 190 give the wrong answer.
IBIS is clearly deficient for channels that do not have all Dual Models (except
for the terminal Rx).
BIRD 190 only re-affirms the fact that IBIS 6.1 give the wrong answer for
statistical flow in Redriver channels since it requires that the upstream
equalization is applied to the output of Rx2, not the input of Rx2.
Do you disagree with my proof that BIRD 190 and IBIS 6.1 gives the wrong answer
for statistical flow in this case when all of the models have
Init_Returns_Impulse=True?
Does anyone disagree that IBID 6.1 and BIRD 190 give the wrong answer for
statistical flow in this case when all of the models have
Init_Returns_Impulse=True?
Does anyone disagree that BIRD 166 gives the right answer for statistical flow
in this case when all of the models have Init_Returns_Impulse=True?
Does anyone disagree that we should not put into the standard any flow that
WILL give the wrong answer?
If we cannot get agreement on this, we should simply table BIRD 166 and BIRD
190. I think we have clearly document the problems in IBIS 6.1, that the IBIS
6.1 Redriver flow gives the wrong answer when either the Rx2 optimizes itself
based on its input impulse response and/or when Rx2 has a DFE.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
